SSL/TLS証明書

TL;DR — SSL/TLS証明書は、サーバー上で南京錠とhttps://を可能にするファイルです。安価でも高価でもSEO上は同じで、Googleが確認するのはURLがhttps://で始まるかどうかです。Let’s Encryptの無料証明書も高価な証明書と同じようにランキングされます。実際に問題を起こすのは壊れた証明書で、期限切れや設定ミスがあると警告が表示され、訪問者は離脱します。

SSL証明書とは実際には何か

最新のHTTPSでは、TLS証明書でドメインを認証し、暗号化された接続を確立します。 Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 8446: TLS 1.3 GoogleはHTTPSを推奨し正規化のシグナルとして使いますが、証明書の価格や検証レベルがランキングを押し上げるとは文書化していません。 Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTPS

タップして展開

The chart groups observed certificate issuance by duration, from three days or less through more than 200 days. The 47-to-100-day bucket dominates this captured period.

安全なサイトを読み込むと、ブラウザーとサーバーは暗号化を設定する短いハンドシェイクを行います。そのときサーバーが渡すのが証明書です。サイト所有者をある程度証明し、接続をスクランブルする鍵を運びます。

「SSL証明書」と呼ばれますが、現代のプロトコルはTLSです。「SSL」という名前だけが残りました。HTTPSハブでは名称の事情と「HTTPSはランキングに役立つか」を扱います。このページではHTTPSがせいぜい小さなタイブレーカーにすぎない前提で、証明書を掘り下げます。

高価な証明書はSEOに役立つか？

いいえ。最もよくある俗説です。GoogleはHTTPSが有効な限り、証明書の種類、発行者、価格によるランキング差を文書化していません。年額300ドルの証明書と無料の証明書を区別できません。John Muellerは “this does not ‘Boost your website’s SEO’, sorry.” (翻訳) 「これはあなたのウェブサイトのSEOを『押し上げる』ものではありません。すみません」と述べました。

したがって、Let’s Encryptの無料証明書も最も高価な選択肢と同じようにランキングされます。余分な費用で得られるのは人間向けの信頼シグナルで、ランキング上の優位性ではありません。

証明書にはどのような種類があるか

違いが出るのは2つの点で、分けて考えると理解しやすくなります。

• どこまで検証するか。 基本的な証明書はドメインを管理していることだけを証明します。高価な証明書は会社の法的な身元を検証しますが、Googleにとって差はありません。
• 何をカバーするか。 1枚で1つのホスト名、サブドメイン全体（「ワイルドカード」、または特定の名前のリスト（「SAN」証明書）をカバーできます。

SEOで実際に重要な部分

正常に機能する証明書は意識されません。壊れた証明書は問題になります。

• 期限切れの証明書は全画面警告を表示させ、訪問者はページを見る前に離脱します。
• **ひどく壊れた証明書は、GoogleがHTTPS版でなくHTTP版を優先する原因にもなります。**悪い証明書がその優先を覆すことはGoogleのガイダンスにもあります（HSTSでも止められません）。
• 問題が十分に多い場合、 GoogleはHTTPSページのクロールを停止し、ページを検索から押し出すことさえあります。

経験則は簡単です。安い（または無料の）証明書を購入し、決して期限切れにしないこと。自動更新を設定して忘れましょう。

DV、OV、EV、ワイルドカードとSAN、証明書チェーン、短くなる有効期間、証明書が壊れたときのクロールへの影響を詳しく知りたいですか？ Advancedタブへ。

TL;DR — GoogleはDV／OV／EVの検証の深さや無料発行と有料発行にランキング差があるとは文書化していません。高価な証明書がもたらすのは人間や組織からの信頼で、ランキングではありません。検証の深さ（DV／OV／IV／EV）とカバレッジ（単一／ワイルドカード／SAN）は別の判断で、どちらも文書化されたランキング要因ではありません。Let’s Encryptや無料のACME発行は妥協でなく、暗号化も扱いも同じです。証明書がSEOに影響するのは障害時です。期限切れ、自己署名、ホスト名不一致、チェーン切れはユーザーにページを壊し、GoogleのHTTPS優先をHTTPへ戻すことがあり、HTTPSの問題が多いと「HTTPSページのクロールを停止するようGoogleに促す」ことさえあります。2029年までに最大有効期間が47日に短縮されるため、自動更新は必須です。

HTTPSハブではHTTPSはせいぜいタイブレーカーで、Googleが見るのは証明書でなくURLのスキーム、無料のDVも高価なOV／EVと同じシグナルだと説明しています。この記事はDV／OV／EVの意味、範囲、無料証明書、チェーン障害、証明書が悪化したときのクロールへの影響を扱います。

「SSL証明書」は実際にはTLS証明書

SSLは現代のTLS展開では古い用語です。 Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 RFC 8446: TLS 1.3 検索ガイダンスが重視するのは商用証明書の階層でなく、有効でアクセス可能なHTTPSです。 Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: 2026-07-14 Google: HTTPS

SSL（Secure Sockets Layer）は非推奨のプロトコルで、現在発行されるものはすべてTLS（Transport Layer Security）で動作します。「SSL証明書」は通称として残り、GoogleのSearch Consoleにも「SSL certificate problems」とあります。ここでは「証明書」と呼びます。

検証の深さ：DV、OV、IV、EV

証明書は異なる検証レベルで発行されます。認証局（CA）が保証する前にどれだけ確認したかを示します。SSL.comの整理によれば次のとおりです。

• **DV（Domain Validation）**は “the lowest level of validation, and verifies that whoever requests the certificate controls the domain that the certificate protects.” (翻訳) 「最も低い検証レベルで、証明書が保護するドメインを申請者が管理していることを確認する」です。高速で安価または無料で、通常は自動化されています。
• **OV（Organization Validation）**は “verifies the identity of the organization (e.g. a business, nonprofit, or government organization) of the Subject listed in the certificate, along with the location where the organization operates.” (翻訳) 「証明書のSubjectに記載された組織の身元と活動場所を確認する」ものです。
• **IV（Individual Validation）**は “verifies the identity of the individual person listed as the Subject of the certificate.” (翻訳) 「証明書のSubjectに記載された個人の身元を確認する」ものです。
• **EV（Extended Validation）**は “like OV, verifies the identity of an organization. However, EV represents a higher standard of trust than OV and requires more rigorous validation checks.” (翻訳) 「OVと同様に組織の身元を確認するが、OVより高い信頼基準で、より厳格な検証を必要とする」ものです。

SEOに関係する点は、Googleが検証レベル間のランキング差を文書化していないことです。Illyesは基本シグナルがURL前方の最初の5文字を見ると表現しました。HTTPSが有効ならDV、OV、EVは同じ扱いです。価格差はCAの審査作業と責任を反映し、Googleの好みではありません。web.devも “different CAs charge different amounts of money for the service of vouching for your public key.” (翻訳) 「異なるCAは公開鍵を保証するサービスに異なる金額を請求する」と明記しています。

EVを選ぶ人間向けの主張もほぼ消えました。EV専用のブラウザー表示は事実上なくなっています。 ChromeはChrome 77（2019年）から緑色の会社名UIを削除し、Firefox 70も追随しました。購入判断では現在のブラウザー動作を確認してください。

カバレッジの範囲：単一ドメイン、ワイルドカード、SAN

検証の深さとは別に、証明書が実際に保護するホスト名を示すカバレッジの範囲があります。通常、どの範囲でもDVまたはOVで発行できます。

• 単一ドメイン — www.example.comという1つのホスト名だけをカバーします。
• ワイルドカード — DNSラベル1つ分のホスト名パターンをカバーします。“In wildcard certificates, the wildcard applies to only one DNS label. A certificate good for *.example.com works for foo.example.com and bar.example.com, but not for foo.bar.example.com.” (翻訳) 「ワイルドカードは1つのDNSラベルにだけ適用され、第1レベルでは機能するが第2レベルでは機能しない」。
• SAN／マルチドメイン（UCC） — Subject Alternative Namesに特定のホスト名を列挙します。web.devは、“options for mapping your key to more than one DNS name, including several distinct names (e.g. all of example.com, www.example.com, example.net, and www.example.net).” (翻訳) 「複数の異なる名前を含め、鍵を複数のDNS名へ割り当てる選択肢がある」と説明しています。SAN証明書はまったく異なるドメインにもまたがれます。

実務上のSEOの失敗はワイルドカードの1ラベル制限に隠れています。*.example.comを使ってstaging.blog.example.comを作ると、範囲外なので証明書エラーか不一致の証明書になります。Googleまたはユーザーがアクセスすると、カバー済みと思ったページで壊れた証明書の体験になります。

**apexホスト名でテストに合格しても、どこでもカバーされているとは限りません。**クライアントは接続先の正確なホスト名をリクエストし、SNI経由でその名前を記載した証明書を受け取る必要があります。CDNやロードバランサーではエッジ、地域、オリジンが異なる証明書を返すことがあります。example.comの結果だけでwww.や別オリジンのサブドメインまで保証されたと考えず、各公開ホスト名を個別にテストしてください。

Let’s Encryptと無料の自動発行

Let’s Encryptなどの無料CAは、ACMEプロトコルを通じてDV証明書を発行します。これはCertbotなどが実行する自動化されたリクエスト／チャレンジ／発行のループです。

1. 無料だから弱いわけではありません。 Let’s Encryptは有料証明書と同じTLS暗号強度を提供し、Googleのシグナルはスキームベースなのでランキング上の扱いも同じです。違いはDVのみ（OV／EVの身元検証はない）で短期間なことです。
2. 自動化すれば短い有効期間はメリットです。 短命なら鍵が侵害された場合の露出期間が短く、人間が更新を覚える必要もありません。

この2つ目の点は、Let’s Encrypt利用者だけでなくまもなく誰にとっても重要になります。

証明書の有効期間の変化（2026～2029年）— 今すぐ自動化を

業界では固定スケジュールに沿って証明書の有効期間が短くなっています。CA／Browser ForumはBallot SC-081v3（投票終了日は2025年4月11日）を可決し、TLS証明書の最大有効期間を段階的に短縮します。

• 398日：現在
• 200日：2026年3月15日から
• 100日：2027年3月15日から
• 47日：2029年3月15日から

Let’s Encryptもより速いペースで進んでいます。2026年2月の更新によれば、今後2年間でデフォルト有効期間を2段階で短縮し、“from 90 days to 64 days, and then 45 days” (翻訳) 「90日から64日へ、次に45日へ」とします。90日証明書の更新時期は約60日目ですが、45日になれば約30日目へ移ります。各段階の正確な日付はまだ確定していないため、具体的な日付に依存する前にLet’s Encryptの変更履歴を確認してください。

結論は明快です。**更新が自動化されていないなら、2027年になる前に直してください。398日で維持できた手動更新は、47～100日ではほぼ確実に障害を起こします。DigiCertの説明どおり、手動再検証は可能でも”doing so would be a recipe for failure and outages.” (翻訳) 「そうするのは失敗と障害を招く処方箋になる」からです。

証明書チェーン／中間証明書の障害

これは十分に説明されていません。実際の動作を見てみましょう。

ブラウザーが信頼するルート証明書はトラストストアに組み込まれた集合です。サーバーのリーフ証明書がルートに直接署名されることはほぼありません。通常は、リーフ → 1つ以上の中間証明書 →信頼されたルートというチェーンです。クライアントがリーフを信頼するには、サーバーがリーフと中間証明書を送り、信頼済みルートまでの経路を構築できるようにします。

典型的な設定ミスはサーバーがリーフだけを送り、中間証明書を省略することです。厄介なのは、デスクトップ版Chromeでは動作することが多い点です。別サイトで遭遇した中間証明書をキャッシュして隙間を埋めるからです。一方、モバイルブラウザー、多くのAPI／HTTPクライアント、キャッシュを持たないツールはハンドシェイクに失敗します。 TLS層の「自分のマシンでは動く」バグです。

検出するにはデスクトップChromeのスポットチェックを信頼せず、チェーンをゼロから構築するツールを使います。

• SSL LabsのServer Test は「extra download」や不完全なチェーンを明示的に検出します。
• コマンドラインのopenssl s_client -connect example.com:443 -showcertsは、サーバーが実際に送信するすべての証明書を表示します。

証明書が無効、期限切れ、または自己署名の場合に起きること

ここが最も重要な部分です。ユーザーとクローラーでは、壊れた証明書の体験が異なります。

ユーザーとブラウザーの動作。期限切れ、自己署名、ホスト名不一致、信頼されないCAなどの重大な失敗は全画面のインタースティシャル警告を表示させます。ユーザーは離脱します。Glenn Gabeの “A Wolf in Panda’s Clothing” (翻訳) 「パンダの服を着たオオカミ」というケースでは、Panda更新と同日にECサイトのトラフィックが急落しましたが、実際の原因は期限切れ証明書でした。Gabeは “There are times that SEO problems aren’t really SEO problems. Technical issues that appear at the same time algorithm updates hit can be confusing.” (翻訳) 「SEOの問題が実はSEOの問題ではないことがあります。アルゴリズム更新と同時に現れる技術的な問題は混乱を招くことがあります」と述べています。更新すると約8日以内に回復しました。自己署名証明書も公開本番では決して使わないでください。

**Googleの動作。**Googleの正規化ガイダンスは、壊れた証明書が検索に不可視ではないと明示します。“Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals,” (翻訳) 「Googleは問題や競合するシグナルがない限り、同等のHTTPページよりHTTPSページをcanonicalとして優先する」とし、“Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly. Implementing HSTS cannot override this strong preference.” (翻訳) 「悪いTLS／SSL証明書とHTTPSからHTTPへのリダイレクトは避けること。GoogleがHTTPを非常に強く優先し、HSTSでも覆せない」と述べています。壊れた証明書はGoogleがcanonicalとして扱う版をHTTPへ戻すことがあります。

GoogleのSearch Console文書は、証明書失敗にはクロール上の影響もあると説明します。無効な証明書は*“typically affects an entire site,”* (翻訳) 「通常、サイト全体に影響する」うえ、“if a site has a lot of HTTPS issues, it can prompt Google to stop crawling your HTTPS pages.” (翻訳) 「HTTPSの問題が多いと、GoogleがHTTPSページのクロールを停止するよう促すことがある」とされています。残りのURLには*“HTTPS not evaluated.”* (翻訳) 「HTTPSは評価されていません」というラベルが付きます。canonicalの反転とクロールアクセス制限は、基礎となるhttps://ランキングシグナルとは別の仕組みです。

Googleが挙げる原因は、ホスト名が証明書の名前と一致しないこと、つまり*“The host name of your site does not match any of the Subject Names in your SSL certificate”* (翻訳) 「サイトのホスト名がSSL証明書のSubject Namesのいずれとも一致しない」や、自己署名、信頼されないCA、破損、期限前などで*“not recognized by major web browsers”* (翻訳) 「主要なウェブブラウザーに認識されない」証明書です。

期限監視と自動更新

期限切れは最も一般的で防ぎやすい障害です。通常は1ページでなくサイト全体を一度に壊します（Google：“Typically this affects an entire site” (翻訳) 「通常、サイト全体に影響する」）。カレンダーのリマインダーでなく、実際の自動化を設定します。

• ACME／Certbotを自分のサーバーで使う、またはプラットフォームの同等機能を使う。
• ホストまたはCDN管理の証明書（Cloudflare、マネージドホスト、多くのPaaS）で自動発行・更新する。
• 第三者の証明書／稼働時間モニターで、更新が自動でも期限接近とハンドシェイク失敗を通知する。

有効期間が47日に近づくほど手動リマインダーは維持できなくなります。規模に対応できるのは自動化だけです。

サブドメイン間で証明書が混在する構成

これはmixed content（HTTPSページがHTTPサブリソースを読み込むこと。ハブで扱います）とは別物です。Mixed-certとは、サイトの部分ごとに異なるスケジュールやプラットフォームの証明書で保護される状態です。メインドメインは堅牢でも、blog.example.comは別プラットフォームで独自証明書を使い別日程で期限切れになることがあります。別CDNのマーケティングサブドメインがワイルドカードの1ラベル制限外だったり、SNIホスティングがメインドメインのスポットチェックでは見えない更新障害を起こしたりもします。

**ホームページの有効な南京錠は、他の場所のカバレッジを何も証明しません。**サブドメインを棚卸しし、すべてのホストが有効で監視された証明書（独自証明書、到達可能なワイルドカード、またはSAN）で保護されていることを確認してください。1つのホスト名のSSL Labsチェックだけでプロパティ全体を証明できるとは考えないでください。

よくある俗説

• **「有料またはEVは無料のDVより上位にランクされる。」**いいえ。シグナルはスキームベースで検証の深さはGoogleから見えません。
• **「ワイルドカードはサブサブドメインもカバーする。」**いいえ。DNSラベル1つだけなので*.example.comはfoo.bar.example.comをカバーしません。
• **「期限切れ証明書はランキングを直接下げる。」**基礎ランキングシグナルを通じてではありませんが、canonicalをHTTPへ戻し、HTTPSの問題が多いとクロール停止を招くことがあります。
• **「Let’s Encryptは有料より低品質だ。」**いいえ。暗号化もランキング上の扱いも同じで、違いはDVのみの検証と短い有効期間です。
• **「ホームページが有効ならサイト全体も安全だ。」**いいえ。サブドメインには別の証明書があります。
• **「チェーンエラーはまれだ。」**いいえ。リーフだけを配信する構成で一般的で、Chromeのキャッシュがテストから隠します。

これは証明書レベルの詳しい解説で、HTTPSハブの下にあります。移行手順、mixed content、HSTSについてはまずハブを参照してください。

AIによる要約

Advanced版の要点をまとめます。

• Googleは証明書の階層間のランキング差を文書化していません。HTTPSが有効ならDV、OV、IV、EVは同じ扱いで、無料のLet’s Encryptも有料と同じです。高価な証明書が買うのは人間／組織の信頼であってSEOではありません。John Mueller：“this does not ‘Boost your website’s SEO’, sorry.” (翻訳) 「これはあなたのウェブサイトのSEOを『押し上げる』ものではありません。すみません」
• **独立した2軸：**検証の深さ（DV＝ドメイン管理→OV／IV＝身元→EV＝厳格な組織審査）とカバレッジ（単一／ワイルドカード／SAN）。どちらもGoogleから見えません。
• ワイルドカードはDNSラベル1つだけ。*.example.comはfoo.example.comをカバーしますが**foo.bar.example.comは対象外**です。SANはホスト名を列挙してドメインをまたげます。
• EVのブラウザーUIは消滅（Chrome 77／Firefox 70、2019年）。
• **無料の自動発行（ACME／Certbot）は妥協でない。**暗号化もランキングも同じで、短い有効期間は自動化すればメリットです。
• **有効期間の変化：**CA／B ForumのBallot SC-081v3は398日→200日（2026年3月）→100日（2027年3月）→**47日（2029年3月）**へ短縮します。Let’s Encryptも90→64→45日へ移行中です。今すぐ自動化してください。
• **チェーン障害は隠れます。**サーバーがリーフだけを送り、Chromeはキャッシュで動いても、モバイル／APIクライアントは失敗します。SSL Labsまたはopenssl s_client -showcertsで診断します。
• **ユーザーとGoogle：ユーザーは全画面警告で離脱します。ランキングシグナルは変わらなくても、壊れた証明書はcanonicalをHTTPへ戻し、Googleが”stop crawling your HTTPS pages” (翻訳) 「HTTPSページのクロールを停止する」こともあります。
• 期限切れはサイト全体を一度に壊します。更新を自動化し監視してください。サブドメイン間のMixed-certではホームページの南京錠だけで範囲を判断できません。

公式ドキュメント

検索エンジンと標準化団体による証明書の一次資料です。

Google

• HTTPSレポート（Search Consoleヘルプ） — “invalid certificate,” (翻訳) 「無効な証明書」、“affects an entire site,” (翻訳) 「サイト全体に影響する」、“stop crawling your HTTPS pages” (翻訳) 「HTTPSページのクロールを停止する」という文言。
• SSL certificate problems (Search Console Help) — ホスト名不一致と信頼されない／自己署名証明書のエラー。
• Enable HTTPS on your servers (web.dev) — CA、CSR、ワイルドカードの範囲、複数名のマッピング。
• Consolidating duplicate URLs (Google Search Central) — Googleは「問題や競合するシグナルがある場合を除き」HTTPSを優先し、悪い証明書を問題の1つとして挙げ、HSTSでも覆せないと説明しています。

認証局と標準

• DV, OV, IV, and EV Certificates (SSL.com) — 検証レベルの定義。
• Let’s Encrypt — 無料で自動化されたDV証明書の認証局。
• ACME protocol / Certbot — 多くのセルフホスト構成で使われる自動化クライアント。
• 証明書の有効期間短縮とレート制限（Let’s Encrypt） — Let’s Encryptの有効期間短縮計画。
• CA/Browser Forum — 証明書の最大有効期間を定める団体。

出典からの引用

記録に残る発言です。各リンクは引用箇所へ直接移動するディープリンクです。

Google — Search Consoleの証明書エラー

• “The HTTPS URL has an invalid SSL certificate. Typically this affects an entire site.” (翻訳) 「HTTPS URLには無効なSSL証明書があります。通常、サイト全体に影響します」 — Google Search Console Help、HTTPSレポート。 引用へ移動
• “If a site has a lot of HTTPS issues, it can prompt Google to stop crawling your HTTPS pages.” (翻訳) 「HTTPSの問題が多いと、GoogleがHTTPSページのクロールを停止するよう促すことがある」 — Google Search Console Help、HTTPSレポート。 引用へ移動
• “The host name of your site does not match any of the Subject Names in your SSL certificate.” (翻訳) 「サイトのホスト名がSSL証明書のSubject Namesのいずれとも一致しません」 — Google Search Console Help、SSL certificate problems。 引用へ移動
• “Your site uses an SSL certificate which is not recognized by major web browsers.” (翻訳) 「サイトは主要なウェブブラウザーに認識されないSSL証明書を使用しています」 — Google Search Console Help、SSL certificate problems。 引用へ移動

Google — canonicalの優先と悪い証明書

• “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals.” (翻訳) 「Googleは問題や競合するシグナルがない限り、同等のHTTPページよりHTTPSをcanonicalとして優先します」／“Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly. Implementing HSTS cannot override this strong preference.” (翻訳) 「悪いTLS／SSL証明書とHTTPSからHTTPへのリダイレクトは避けてください。GoogleがHTTPを非常に強く優先し、HSTSでも覆せません」 — Google Search Central、Consolidating duplicate URLs。 出典を読む

Google／web.dev — 証明書の範囲とコスト

• “In wildcard certificates, the wildcard applies to only one DNS label. A certificate good for *.example.com works for foo.example.com and bar.example.com, but not for foo.bar.example.com.” (翻訳) 「ワイルドカードは1つのDNSラベルにだけ適用されます。*.example.comは第1レベルでは機能しますが第2レベルでは機能しません」 — web.dev、Enable HTTPS on your servers。 引用へ移動
• “Different CAs charge different amounts of money for the service of vouching for your public key.” (翻訳) 「異なるCAは公開鍵を保証するサービスに異なる金額を請求します」 — web.dev、Enable HTTPS on your servers。 引用へ移動

SSL.com — 検証レベル

• “Domain Validation (DV) is the lowest level of validation, and verifies that whoever requests the certificate controls the domain that the certificate protects.” (翻訳) 「Domain Validation（DV）は最も低い検証レベルで、証明書が保護するドメインを申請者が管理していることを確認します」 引用へ移動
• “Extended Validation (EV), like OV, verifies the identity of an organization. However, EV represents a higher standard of trust than OV and requires more rigorous validation checks.” (翻訳) 「Extended Validation（EV）はOVと同様に組織の身元を確認しますが、OVより高い信頼基準で、より厳格な検証を必要とします」 引用へ移動

John Mueller、Google Search Relations (Search Engine Journalが2023年5月に伝えたソーシャルメディア上の返信)

• “@EncryptedFence this does not ‘Boost your website’s SEO’, sorry.” (翻訳) 「@EncryptedFence、これはあなたのウェブサイトのSEOを『押し上げる』ものではありません。すみません」 MuellerのMastodon返信をSearch Engine Journal経由で引用。公式のスキームベースの説明を裏付ける業界資料であり、Google所有ページではありません。直接引用する場合は元の投稿で確認してください。 記事を読む

Glenn Gabe、GSQi (期限切れ証明書のケーススタディ、2013年9月)

• “There are times that SEO problems aren’t really SEO problems. Technical issues that appear at the same time algorithm updates hit can be confusing.” (翻訳) 「SEOの問題が実はSEOの問題ではないことがあります。アルゴリズム更新と同時に現れる技術的な問題は混乱を招くことがあります」 業界ケーススタディ。2013年のブラウザーUI詳細は古いものですが、診断上の教訓は現在も通用します。 ケーススタディを読む

どの証明書を取得すべきか？

上から順に考えます。最初の2つの質問ですべての重要事項が決まり、残りは範囲の計算です。

1. Googleにサイトをランキングしてもらう必要がありますか？ それはそもそもhttps://で公開することで処理されます。有効な証明書ならどれでも同じランキングシグナルです。高価な証明書を選ぶ理由にはなりません。

2. 検証済みの組織としての身元を人間に表示する必要があり、法律またはコンプライアンス上求められていますか？

• いいえ（ブログ、コンテンツサイト、ほとんどのEC） → DV証明書。 Let’s Encryptの無料証明書を自動化すれば完了です。
• はい（銀行、一部の規制対象／企業環境でOV／EVが必要） → OV（要件に明記される場合はEV）。EVには特別なブラウザー表示がないため、目に見えるバッジでなく検証記録に料金を払います。

3. いくつのホスト名を保護しますか？（カバレッジ。ステップ2とは独立）

• 1つのホスト名（www.example.comだけ）→単一ドメイン。
• 多数の第1レベルサブドメイン（shop.、blog.、app. example.com）→ワイルドカード（*.example.com）。第2レベル（api.staging.example.com）は対象外です。
• 特定の混在リスト（example.com＋example.net＋brand.ioなど）→名前を列挙するSAN／マルチドメイン（UCC）。
• ワイルドカードが届かない第2レベル→そのレベルのワイルドカードか、SANへの明示的追加。

4. どの鍵アルゴリズムを使い、このホスト名を実際に配信するエッジ／オリジンはいくつありますか？ RSAとECDSAはセキュリティとクライアント互換性のトレードオフで、ランキング要因ではありません。古いクライアントはECDSAをサポートしないことがあるため、CDNやロードバランサーが提供するものを確認してください。複数のエッジ、地域、オリジンの前段にあるなら各経路を個別にテストします。1つの成功では他を保証できません。

5. 更新は自動化されますか？

• はい →短い有効期間でも大丈夫です（2029年までに最大47日）。
• いいえ →まず直してください。手動更新は有効期間が短くなると運用できません。ACME／Certbotまたはホスト／CDN管理証明書を使います。

稼働中の証明書エラーをデバッグする場合、どの症状ですか？

• デスクトップChromeでは動くがモバイル／ツールでは失敗 →ほぼ確実に中間証明書がない（チェーン）エラーです。SSL Labsまたはopenssl s_client -showcertsでテストし、完全なチェーンをインストールします。
• サイト全体が突然警告または停止 →まず期限切れを確認します。
• 1つのサブドメインだけ警告 →Mixed-cert／カバレッジ不足です。
• 警告が別サイト名を示す →ホスト名不一致です。

証明書の健全性チェックリスト

証明書が有効で、必要な範囲をカバーし、知らないうちに期限切れにならないことを確認します。

• すべての公開ホスト名（apex、www、各サブドメイン）が、有効で信頼された証明書で配信されている。
• 完全なチェーン（リーフと中間）がインストールされ、SSL Labsまたはopenssl s_client -showcertsで検証されている。
• 更新が自動化されている。人間のリマインダーに頼る更新がない。
• 証明書／稼働時間モニターが期限接近とハンドシェイク失敗を通知する。
• **ホスト名の不一致がない。**すべての配信ホストがSANに記載されるか、ワイルドカードでカバーされている。
• ワイルドカードの1ラベル制限を確認し、第2レベル（a.b.example.com）が*.example.comの範囲外に落ちていない。
• 公開本番ホストに自己署名証明書がない。
• 検証の深さはSEO期待でなく人間／コンプライアンス上の必要性で選んでいる。
• Google Search ConsoleのHTTPSレポートで*“invalid certificate”* (翻訳) 「無効な証明書」／“HTTPS not evaluated” (翻訳) 「HTTPSは評価されていません」を確認している。
• 異なるプラットフォーム／CDN上のサブドメインを棚卸ししている。

メンタルモデル

1. 軸は1つではなく2つ。 証明書には検証の深さ（DV／OV／IV／EV）とカバレッジ（単一／ワイルドカード／SAN）があり、独立しています。DVワイルドカードやOV単一ドメインも可能です。Googleにはどちらも見えません。

2. ランキングシグナルは証明書の階層を区別しない。 有効な証明書でhttps://を使えば、発行者、価格、検証レベルに関係なく同じシグナルです。「どの証明書がSEOに役立つか」は階層間のカテゴリーエラーです。ただし有効であること自体が見えないという意味ではありません。#3を参照してください。

3. 証明書の問題はcanonical、クロールアクセス、UXの緊急事態であり、ランキング階層の問題ではない。 証明書が壊れるとユーザーは警告で離脱し、GoogleのHTTPS優先canonicalがHTTPへ戻ることがあり、HTTPSの問題が多ければGoogleがHTTPSページのクロールを停止することもあります。どれもランキングシグナル自体を経由しませんが、「スキームは変わらなかった」ことは無害と扱う理由にはなりません。

4. 有効期間が短くなるほど、自動化がすべて。 業界は47日証明書へ向かっています。更新が自動化されれば短い有効期間は安全です。唯一の本当のリスクは自動化しないことです。

5. ホームページの南京錠が証明するのは1つのホスト名だけ。 サブドメインごとに範囲、有効期限、プラットフォームが異なります。すべてのホストを監視し、1つの緑の南京錠から推測しないでください。

6. ノートパソコンではなくチェーンをテストする。 デスクトップChromeは中間証明書をキャッシュします。SSL Labsやopenssl s_clientで検証し、中間証明書の欠落を隠さないようにします。

SSL/TLS証明書 — チートシート

検証の深さ（CAが確認した内容）

カバレッジの範囲（保護するホスト名）

有効期間の変化（CA／Browser Forumの最大有効期間）

証明書が壊れたとき

要点

• 無料のDV（Let’s Encrypt）＝有料と同じ暗号化＋同じランキング。
• Googleのシグナルが読むのは証明書でなくスキーム。
• HTTPSの問題が十分に多いと、GoogleはHTTPSページのクロールを停止できます。
• ACME／Certbotまたはホスト／CDN管理証明書で更新を自動化します。

証明書と完全なチェーンを調べる

証明書のデバッグに役立つコマンドです。-showcertsはサーバーが実際に送信するすべての証明書を表示し、中間証明書の欠落を最速で見つけられます。

macOS／Linux

# Show the full chain the server sends (leaf + intermediates)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

# Just the expiry dates (notBefore / notAfter)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates

# The hostnames the cert actually covers (Subject Alternative Names)
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

-servernameフラグはSNIを設定します。1つのIPが複数の証明書を配信する共有／CDNホスティングで重要です。

Windows（PowerShell） — 有効期限とカバー対象の名前を確認する

# Pull the served certificate and read its expiry + Subject Alternative Names
$req = [Net.HttpWebRequest]::Create("https://example.com")
$req.GetResponse().Dispose()
$cert = $req.ServicePoint.Certificate
$cert2 = [System.Security.Cryptography.X509Certificates.X509Certificate2]$cert
"Expires: " + $cert2.NotAfter
$cert2.Extensions | Where-Object { $_.Oid.FriendlyName -eq "Subject Alternative Name" } |
  ForEach-Object { $_.Format($true) }

Chrome DevToolsコンソール — 安全でないサブリソースURLを検出する

任意のページのコンソールに貼り付けると、HTML内で参照されているhttp://サブリソースを一覧表示できます。証明書監査中のmixed-contentの簡易チェックです。

[...document.querySelectorAll('[src],[href]')]
  .map(el => el.getAttribute('src') || el.getAttribute('href'))
  .filter(u => u && u.startsWith('http://'))
  .forEach(u => console.warn('insecure:', u));

すべてのホスト名をカバーするには外部バリデーター（SSL Labs）のほうがホストごとのスクリプトより優れています。ただし、これは目の前の環境で行う簡易チェックです。

証明書のアンチパターン

繰り返し目にする失敗モードです。

「SEOのためにEV／OVを購入する」 Googleは検証の深さを見ることができません。存在しないランキング利益のために多く支払うのは無駄です。検証の深さは本当の人間向け信頼またはコンプライアンス上の理由がある場合だけ購入してください。

デスクトップChromeだけで証明書を検証する Chromeは中間証明書をキャッシュし、他では失敗する壊れたチェーンの上に緑の南京錠を表示します。必ずクリーンなビルダー（SSL Labs、openssl s_client -showcerts）から検証してください。

手動更新のリマインダー カレンダーの予定は更新システムではありません。誰かが休暇中にサイト全体を一度に停止させます。有効期間が47日に向けて短くなるほど悪化します。自動化してください。

ワイルドカードがドメイン配下のすべてをカバーすると考える *.example.comはDNSラベル1つで止まります。staging.api.example.comはカバーされず、ユーザーやGooglebotがアクセスするまで気づかれないエラーを返します。

ホームページだけをスポットチェックする 別プラットフォーム／CDN上のサブドメインには独自の証明書とスケジュールがあります。有効なapexの南京錠はblog.やマーケティング用サブドメインの期限切れについて何も示しません。

公開本番環境で自己署名証明書を使う 全画面のブラウザーインタースティシャルを表示し、ほとんどのバリデーターとクローラーで失敗します。内部／開発／ステージングでは構いませんが、公開サイトでは使わないでください。

壊れた証明書をランキング階層の問題、または無害なものとして扱う ランキング要因ではありませんが無害でもありません。壊れた証明書はGoogleのcanonical優先をHTTPSからHTTPへ戻し、クロールアクセスの制限を起こし、ユーザーの離脱でコンバージョンを落とす可能性があります。証明書を直し、「スキームが変わらなかった」から何も起きなかったと考えないでください。

証明書の更新とデプロイのSOP

1. ホスト名の棚卸しを維持する。 apex、www、サブドメイン、深いサブドメイン、CDNまたはロードバランサーのエンドポイント、発行者、範囲、更新担当者、自動化経路を記録します。
2. 発行者とは独立して期限を監視する。 自動化の失敗を調査できる早さで通知します。カレンダーのリマインダーだけでは更新システムになりません。
3. 自動更新を実行して試す。 ACME、ホスト、CDNのワークフローが手動操作なしで発行、検証、インストール、有効化を行い、古い証明書を保持するすべての配信プロセスを再読み込みできることを確認します。
4. 候補を検証する。 ホスト名／SAN、ワイルドカードの深さ、発行者、有効期間、完全な中間チェーンを確認します。
5. すべての配信層にデプロイする。 各エッジ、プロキシ、ロードバランサー、TLS終端オリジンを更新します。
6. 外部からテストする。 クリーンなチェーンバリデーターとSNI付きのopenssl s_clientを代表ホストで使い、ブラウザーのキャッシュを共有しないクライアントも含めます。
7. ループを閉じる。 監視が新しい期限を確認していることを確かめ、デプロイを記録し、まだ旧証明書を配信するエンドポイントを調査します。

更新の失敗は可用性インシデントとして扱います。HSTSホストでは、訪問者は証明書エラーを安全にクリックして通過できません。

証明書の検査ツールキット

• SSL Labs Server Test — 配信証明書、チェーン、ホスト名範囲、プロトコル対応、エンドポイント差異を外部検証します。
• openssl s_client — SNIでホスト名が実際に配信するものを調べ、完全なチェーンを表示します。日付とSubject Alternative Namesにはopenssl x509を組み合わせます。
• ブラウザーの証明書ビューアーとDevTools — 影響を受けるクライアントでユーザー向けのホスト名、信頼、期限切れエラーを再現します。
• 独立した証明書監視 — 発行者やCDNが自動更新を主張していても、棚卸し済みの全ホスト名を通知します。
• Google Search ConsoleのHTTPSレポート — 広いHTTPS配信問題を監視し、エンドポイント診断には証明書ツールを使います。

IPやホームページだけでなくホスト名でテストします。共有インフラではSNI、地域、エッジノードによって異なる証明書が配信されます。

証明書のリリーステスト

テスト1：ホスト名とチェーンのカバレッジ

• **目的：**すべての公開ホスト名が、その名前を記載した信頼できる証明書を受け取ることを証明する。
• 方法： SSL Labsとopenssl s_client -servernameをapex、www、各サブドメインの種類、1ラベルのワイルドカードでカバーできない深いホストに対して実行する。
• **期待する結果：**ホスト名がSANと一致し、チェーンが完全で、クリーンなクライアントがキャッシュを提供せず検証できる。
• **失敗のきっかけ：**名前の不一致、自己署名リーフ、中間証明書の欠落、またはエンドポイントごとの異なる証明書。
• **次のアクション：**範囲または配信チェーンを直し、再デプロイして全エンドポイントを再テストする。

テスト2：更新自動化のリハーサル

• **目的：**更新が思い込みでなく運用プロセスであることを確認する。
• **方法：**対応するステージングまたはドライランの更新経路を実行し、各TLS終端層で置換証明書をインストールして有効化できることを確認する。
• **期待する結果：**検証、発行、デプロイ、監視が手動救済なしに完了する。
• **失敗のきっかけ：**ドメイン検証失敗、権限エラー、古いエッジノード、または以前の証明書を報告し続ける監視。
• **次のアクション：**自動化を直し、本番の更新期間が緊急になる前に繰り返す。

テスト3：デプロイ後のクライアントチェック

• **目的：**1つのブラウザーでは隠れるエンドポイントとクライアントの違いを見つける。
• **方法：**複数のネットワークとクリーンなクライアントでテストし、配信シリアル番号と期限を比較し、影響をSearch ConsoleのHTTPSレポートで確認する。
• **期待する結果：**全テスト済みエンドポイントが意図した証明書を配信し、ページがHTTPSでクロール可能なままになる。
• **失敗のきっかけ：**地域差、証明書警告、HTTPSレポート悪化、またはクロール失敗。
• **次のアクション：**欠落エンドポイントを前に進めるか、デプロイ経路を直す間は最後に有効だった証明書を復元する。

SSL/TLS証明書について理解度を確認する

証明書とSEOの関係についての5つの短い質問です。それぞれ答えを選んでから確認してください。

時間をかける価値のあるリソース

私の講演

• HTTPSで後悔しないために — SMX East 2016 （SlideShare）— TLS、証明書／実装の失敗、移行の落とし穴についての詳しい解説です。BingとBaiduにおけるTLS SNIの非インデックス化リスクも指摘しました。（免責：これは私の理解に基づく説明で、資料の導入率統計は2016年のものです。現在の数値として引用しないでください。）

私の関連する記事

• The Beginner’s Guide to Technical SEO — 証明書とHTTPSが技術SEOの全体像のどこに位置付くかを説明します。

他者による公式／権威ある資料

• GoogleのHTTPSレポート とSSL証明書の問題 — Search Consoleの証明書エラーの決定版。
• GoogleのEnable HTTPS on your servers (web.dev) — CA、CSR、ワイルドカード／複数名の範囲。
• GoogleのConsolidating duplicate URLs — 悪い証明書がHTTP優先の原因になるcanonicalガイダンス。
• SSL Labs Server Test — TLS設定と不完全なチェーンを検査します。

業界全体の資料

• DV、OV、IV、EV証明書 （SSL.com）—各検証レベルの定義。
• パンダの服を着たオオカミ — 期限切れSSL証明書がオーガニック検索トラフィックに与える影響 （Glenn Gabe、GSQi）—期限切れ証明書をPandaペナルティと取り違えた事例。
• Google：SSL証明書はSEOを向上させない （Search Engine Journal）—John Muellerの明確な返答。
• 証明書の有効期間短縮とレート制限 （Let’s Encrypt）—有効期間短縮の更新。
• TLS証明書の有効期間は正式に47日へ短縮 （DigiCert）—Ballot SC-081v3の段階導入。
• SEOに影響するSSLエラー （SISTRIX）—証明書問題の実務整理。
• Certbot （EFF）—発行と更新を自動化するACMEクライアント。

引用する価値のある統計

• **証明書の最大有効期間は2029年までに47日に短縮されます。**Ballot SC-081v3は398日→200日（2026年3月）→100日（2027年3月）→47日（2029年3月）へ短縮します。 出典
• **Let’s Encryptはデフォルト有効期間を90日から64日、45日へ短縮します。**正確な実施日は発表で指定されていません。 出典
• **壊れた証明書は「通常、サイト全体に影響します」。**期限切れやチェーン障害は1ページでなく一度にすべてを壊します。 出典
• **HTTPSの問題が十分に多いと、GoogleはHTTPSページのクロールを停止できます。**基礎ランキングシグナルとは別のクロールアクセス上の影響です。 出典
• **悪い証明書はGoogleのHTTPSのcanonical優先を覆すことがあり、HSTSでも止められません。**悪いTLS／SSL証明書はGoogleにHTTPを強く優先させます。 出典

変更履歴