HTTPSのSEO

TL;DR — HTTPSは、HTTPを安全に暗号化したバージョンで、ブラウザーに表示される鍵アイコンにあたります。GoogleはHTTPSのページをわずかに後押ししますが、切り替える本当の理由は、Chromeが平文HTTPのサイトを「安全ではありません」と表示することと、いまやHTTPSがWebの前提になっていることです。正しく移行すれば安全です。古いhttp://のURLをすべて対応するhttps://版へリダイレクトし、その途中で何も壊さないでください。

HTTPSとは

Webサイトを読み込むと、ブラウザーがサーバーと通信します。通常のHTTPでは、その会話が公開状態で行われるため、途中のネットワーク（ISP、コーヒーショップのWi-Fi、攻撃者）は内容を読んだり改ざんしたりできます。HTTPSは同じ会話を暗号化したものです。「S」は「Secure」を表します。サーバーにTLS証明書（今でも「SSL証明書」と呼ばれます）をインストールすると利用できます。

アドレスバーを見ると、そのページがHTTPSかどうか分かります。https://で始まるURLと、通常は鍵アイコンが表示されます。Chromeで平文のhttp://ページを開くと、代わりに「安全ではありません」と表示されます。

HTTPSが保護するのは接続そのものだけで、ページの内容を保証するものではありません。鍵アイコンは転送中のデータが暗号化されていることを示しますが、サイトのコンテンツが信頼できるか、ページのフォームが正当か、その背後の事業者が実在するかは示しません。フィッシングサイトも有効なHTTPS証明書で運用できますし、実際に運用されています。

HTTPSはSEOに役立ちますか？

歴史的には、少しだけです。Googleは2014年にHTTPSをランキングシグナルとして使うと確認しましたが、非常に小さなシグナルで、当時のGoogleチームは同点の決着要因と説明しました。ほかの条件が同じ2ページなら、安全な方がわずかに先行するかもしれないという意味です。弱いページを強いページより上げるものではなく、Googleの現在のガイダンスもHTTPSによる直接的なランキング向上を改めて述べてはいません。「SSLを追加するだけで」大きく順位が上がると約束する人は、効果を誇張しています。

実際に重要な理由は次のとおりです。

• Chromeが「安全ではありません」と表示します。 2018年以降、すべてのHTTPページに警告が出ます。Googleの見解に関係なく、訪問者を怖がらせます。
• いまや標準です。 推定で10サイト中9サイトがすでにHTTPSを使っています（W3Techs、2026年）。対応していないサイトは壊れているように見えます。
• 現代的な機能に必要です。 多くのブラウザー機能（HTTP/2による高速な接続を含む）は、HTTPSなしでは動きません。

切り替えるとランキングに悪影響がありますか？

慎重に行えばありません。HTTPからHTTPSへの移行はサイト移行の一種で、黄金律は他の移行と同じです。古いURLをすべて、新しい安全なURLへ301リダイレクトします。 正しく行えばランキングを維持できます。雑に行うと、リダイレクト漏れや画像・スクリプトへのリンク切れによってトラフィックを失います。移行自体は安全で、害を生むのはその周辺のミスです。 Evidence for this claim Google recommends permanent server-side redirects during site moves and says HTTP-to-HTTPS moves do not use the Change of Address tool. Scope: Google's site-move guide supports redirect and Search Console handling; it does not guarantee that a migration with implementation errors retains traffic. Confidence: high · Verified: 2026-07-14 Google Search Central: Site moves with URL changes

シグナルの実際の重み、段階的な移行、混在コンテンツ、HSTSまで詳しく知りたい場合は、Advancedタブに切り替えてください。

TL;DR — Googleの現在のページエクスペリエンスガイダンスは、Core Web Vitals以外の要素は*“don’t directly help your website rank higher”* (翻訳)「ウェブサイトの順位を直接高くすることには役立たない」と述べています。したがって、HTTPSによる現在のランキング向上を約束しないでください。確認されているのは歴史的な事実です。Googleは2014年8月、HTTPSを「非常に軽い」ランキングシグナル（クエリの1 %未満）として発表し、Gary Illyesは2015年に同点の決着要因と表現しました。これは日付のあるコメントであり、現在の仕組みが文書化されたものではありません。一方、Googleのcanonical化ガイダンスは、現在、条件付きでHTTP版と同等のHTTPSページをcanonicalとして積極的に優先します。ただし、無効な証明書、安全でない依存関係、HTTPSからHTTPへのリダイレクト、HTTPを指す余計なcanonicalタグがあると、その優先は反転します。HSTSでも上書きできません。HTTPSを使う本当の理由は、Chromeの「安全ではありません」ラベル、（主要ブラウザーすべてで使える）HTTP/2、現代的なブラウザーAPI、そしていまや最低条件であることです。成長のレバーではありません。移行はサイト移行です。すべてのURLを301にし（301でPageRankは失われません）、アクティブとパッシブの混在コンテンツを直し、canonical・サイトマップ・内部リンクを更新し、Search Consoleを再確認します。プロトコル変更にChange of Addressツールはありません。HSTSとそのブラウザー内部の307リダイレクトは、サーバー側の301の代替ではなく、その上に加わるブラウザー層の保護です。

Googleは現在、HTTPSによるランキング向上を約束していますか？

2014年ではなく、現在Googleが述べていることから始めましょう。現在のページエクスペリエンスの文書 は、Core Web Vitals以外のページエクスペリエンス要素（HTTPSもその中に挙げられています）は、“don’t directly help your website rank higher in search results.” (翻訳)「検索結果でウェブサイトの順位を直接高くすることには役立たない」と述べています。これは現在入手できる最も直接的で新しいガイダンスであり、HTTPSであることによる現在のランキング向上を約束する根拠にはなりません。

2014年のシグナルと「同点の決着」— 現在の仕組みではなく歴史

確認されているのは歴史です。 Googleは2014年8月6日にHTTPSをランキングシグナルとして発表し、開始時の重みがどれほど小さいかを珍しく率直に説明しました。元の表現は、*「非常に軽いシグナルで、世界のクエリの1 %未満に影響し、高品質なコンテンツなど他のシグナルより重みが小さい」というものでした。記事は、導入を促すために時間とともに「強化することを決めるかもしれない」*とも付け加えました。SEOメディアが言い換えがちな「ブースト」ではなく、「強化」です。 Evidence for this claim Google announced HTTPS as a very lightweight ranking signal affecting fewer than one percent of global queries at launch. Scope: Google's 2014 announcement establishes the signal and its weight at launch; it does not quantify the signal's current weight. Confidence: high · Verified: 2026-07-14 Google Search Central: HTTPS as a ranking signal

1年後の2015年9月、Gary Illyesはこのシグナルを同点の決着要因と表現しました。“it acts more like a tiebreaker. For example, if all quality signals are equal for two results, then the one that is on HTTPS would get … or may get … the extra boost.” (翻訳)「より同点の決着要因に近い働きをします。たとえば2つの結果の品質シグナルがすべて同じなら、HTTPS上にある方が必要な追加の後押しを得る、または得るかもしれません。」同じ年、優先順位については*“you should switch to HTTPS for users, not as a ranking signal.”* (翻訳)「ランキングシグナルとしてではなく、ユーザーのためにHTTPSへ切り替えるべきです」と率直に述べました。同時期のJohn Muellerの説明も、切り替えだけで目に見える順位変化を期待するなという同じ方向を示しています。

「同点の決着」は、2015〜2016年のIllyesによる日付付きで代表的な説明であり、Googleが現在アクティブなランキングの仕組みとして文書化しているものではない、と扱ってください。したがって、現在形でより保守的な出典は上のページエクスペリエンスの表現です。「HTTPSはSEOに役立つか」への正直で日付のある答えは、Googleが2014年に小さなシグナルを確認し、Google社員が2015年に同点の決着要因と表現したが、現在のガイダンスはその仕組みを直接言い直していない、です。努力の使い道を選ぶなら、HTTPSは衛生項目であり成長のレバーではありません。今日の歴史的シグナルの重みが正確にどうであれ、これは変わりません。

GoogleのHTTPS canonical優先 — 条件付きであり、スキームだけではない

2014年のランキングシグナルとは別に、Googleが現在文書化しているcanonical化の優先があります。“Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals such as” (翻訳)「問題や、次のような矛盾するシグナルがある場合を除き、Googleは同等のHTTPページよりHTTPSページをcanonicalとして優先します」。例として、無効なSSL証明書（画像以外の）安全でない依存関係、ユーザーをHTTPページへリダイレクトするHTTPSページ、HTTP版を指すrel="canonical"があります。

これは、ほとんどの他のガイドが見落とすニュアンスで、よくある単純化（Illyesが2016年に言った「ランキングシグナルは*“basically looking at the first five characters in front of the URL”* (翻訳)「基本的にはURLの前にある最初の5文字を見ている」という説明を含む）にも反します。この短い説明は2014年のランキングシグナルを指しており、今回のcanonical化の判断ではありません。Google自身のガイダンスは、悪い証明書やダウングレードのリダイレクトがHTTPSの優先を上書きすると明記しています。“Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly.” (翻訳)「悪いTLS/SSL証明書とHTTPSからHTTPへのリダイレクトは、GoogleがHTTPを非常に強く優先する原因になるため避けてください」。そしてHSTSでも直せません。“Implementing HSTS cannot override this strong preference.” (翻訳)「HSTSを実装しても、この強い優先を上書きできません」。

実際の帰結は、期限切れまたは設定不良の証明書はUXの問題にとどまらず、Googleが、順位を取りたいHTTPSページではなくHTTPページをインデックスする方向へ進む原因にもなることです。証明書の失敗の種類と診断方法はSSL/TLS証明書を、今回の判断に関するSearch Console専用レポートはHTTPSレポートを参照してください。

HTTPSが実際に重要な理由

ランキングの話をいったん外すと、1つの注意点を最初に示す必要はあるものの、HTTPSを使う理由は圧倒的です。HTTPSが保護するのは、ブラウザーとサーバーの間の転送チャネルです。アプリケーションコードを監査したり、エンドポイントを保証したり、ユーザーの意図を保証したりはしません。HTTPSで侵害されたサイト、HTTPSで配信されるフィッシングフォーム、復号後のデータ侵害は、いずれも起こり得ます。HTTPSは必要な衛生対策ですが、接続の先にあるすべてのもののセキュリティ保証ではありません。

範囲を明確にしたうえで、実務上の理由は次のとおりです。

• Chromeの「安全ではありません」警告。 Chrome 68（2018年7月）以降、ChromeはすべてのHTTPページを「安全ではない」と表示します。実際の訪問者の前にアドレスバーで表示されるため、どんなランキングの小さな後押しより大きなコンバージョン問題です。
• HTTP/2（およびHTTP/3）の実務上の前提。 主要ブラウザーで平文HTTP上のHTTP/2を提供するものはなく、HTTP/2仕様自体は暗号化を必須としていないにもかかわらず、主要ブラウザーはTLS上でしかネゴシエートしません。Google自身の文書が述べるように、“in some cases, TLS can improve performance, mostly as a result of making HTTP/2 possible.” (翻訳)「場合によってはTLSが性能を改善することがあり、その主な理由はHTTP/2を可能にすることです」。これは「可能性がある」であって保証ではありません。TLSのオーバーヘッド、サーバー設定、接続の再利用も関係します。それでもHTTP/2の多重化とヘッダー圧縮によって、HTTPS + HTTP/2のサイトは平文HTTP/1.1より速くなることが多く、昔の「TLSは遅延を加える」という心配とは逆です。
• 現代のブラウザー機能に必要です。 Service Worker、位置情報・カメラ・マイクのAPI、プログレッシブWebアプリは、通常、安全なコンテキストを必要とします（localhostのような例外は機能とブラウザーごとに確認してください）。Googleは*“HTTPS is required for many new browser features, especially those required for progressive web apps.”* (翻訳)「HTTPSは多くの新しいブラウザー機能、特にプログレッシブWebアプリに必要です」と述べています。
• 参照データと「ダークトラフィック」— デフォルトであり、普遍的ではありません。 現代のデフォルトReferrer-Policy（strict-origin-when-cross-origin）で動くブラウザーは、HTTPSページからHTTPの宛先へリンクをたどると、Refererヘッダーを完全に落とします。同一スキームまたはアップグレードのナビゲーションなら、少なくともオリジンは送ります。したがってHTTPのままだと、外へ送るトラフィック（と流入元のアトリビューション）がデフォルトで「ダイレクト」に崩れる可能性があります。ただしサイト独自のReferrer-Policyヘッダーで両方向に上書きできるため、他社の分析データの欠落を監査するときに絶対則として扱わないでください。
• 最低条件です。 推定で約89 %のサイトがHTTPSを使っています（W3Techs、2026年。正確な現在の件数ではなく方向性の推定として扱ってください）。SEO上の話は切り替えによる利益ではなく、目に見える未対応サイトになるリスクです。

HTTP → HTTPSの移行

HTTP→HTTPSの移行はサイト移行であり、同じ規律が必要です。Googleのサイト移行ガイダンス から直接分かる良いニュースは、“301 and other permanent redirects don’t cause a loss in PageRank.” (翻訳)「301などの恒久的なリダイレクトでPageRankが失われることはありません」ということです。切り替えでリンクの評価が失われるという古い恐れは神話です。実際のリスクは実行にあり、301漏れ、混在コンテンツ、古いcanonical、Search ConsoleでHTTPSプロパティを確認していないことがトラフィックを失わせます。

要点を1段落でまとめると、まず稼働中のHTTPサイトをベンチマークします（クロール、ランキング、Search Consoleのエクスポート、被リンクプロファイル）。TLS証明書を取得します（無料のLet’s Encrypt DV証明書も、有料のOV/EV証明書と同じシグナルを持ちます）。すべてのHTTP URLを対応するHTTPSへ1対1で301リダイレクトし、内部リンク、サイトマップ、hreflangを含め、HTTPSをどこでもcanonicalにします。古い内部リンクをリダイレクトで覆い隠さないでください。切り替え前に混在コンテンツを直し、4つのSearch Consoleプロパティをすべて再確認します（プロトコル変更にChange of Addressツールは不要）。少なくとも1年間はリダイレクトを稼働させます。一時的な順位変動は想定してください。回復する下落は移行が落ち着く過程ですが、下落が続くなら何かが壊れています。

これはリスクマップであり、手順書ではありません。段階的な手順、ステージングでのリハーサル、大規模なリダイレクト対応表、ロールバック計画、完全な移行チェックリストはHTTPからHTTPSへの移行を参照してください。このページは、より詳しいガイドと同期しなくならないよう、簡潔な概要に留めています。

混在コンテンツ

混在コンテンツとは、HTTPSページがHTTP経由でサブリソースを読み込むことです。2種類があり、その違いが優先順位を決めます。

• アクティブな混在コンテンツ — スクリプト、スタイルシート、iframe、XMLHttpRequest。改ざんされたスクリプトがページ全体を書き換えられるため、ブラウザーは完全にブロックします。移行後にサイトを実際に壊すのはこちらなので、先に直してください。
• パッシブな混在コンテンツ — 画像、音声、動画。ブラウザーは通常表示しますが、安全性の表示を下げて警告します。

HTTPSサイトをクロールして（Ahrefs Site Audit、Screaming Frog）、Chrome DevToolsのコンソールを監視するか、CSPレポートを集めて見つけます。先回りした最もきれいな修正はContent-Security-Policy: upgrade-insecure-requestsヘッダーです。ブラウザーに、サブリソースのhttp://リクエストを送信前に黙ってhttps://へ書き換えさせます。移行中と移行後の安全網として役立ちます。HTTPページへの通常のアンカーリンクは混在コンテンツではなく、単に移動するだけです。

HSTS（恒久リダイレクトの代替ではない理由）

HSTS（HTTP Strict Transport Security）は、ユーザーがhttp://リンクを入力またはクリックしても、ドメインでは常にHTTPSを使うようブラウザーに伝えるレスポンスヘッダー（Strict-Transport-Security）です。「最初のリクエスト問題」を閉じます。301しかない場合、新しい訪問者の最初のリクエストはリダイレクトが発生する前にHTTPで送られ、その瞬間をSSLストリッピング攻撃者が狙います。Googleの文書の表現では、HSTSは再訪問者について*“avoid the cost of the 301 redirect”* (翻訳)「301リダイレクトのコストを避け」、“defeats attacks like SSL Stripping.” (翻訳)「SSLストリッピングのような攻撃を打ち破ります」。

SEO担当者が区別すべき点は2つです。

• HSTSはサーバー側の301を置き換えません。 ブラウザーがHSTSを尊重すると、HTTPSへの内部 307リダイレクトを実行します。しかしこれはクローラーが見られないブラウザー内部の処理です。検索エンジンには、移行を理解してリンク評価を引き継ぐため、実際のサーバー側301が必要です。両方が必要です。
• HSTS preloadはほぼ永久です。 ドメインをブラウザー組み込みのpreloadリストへ送信できます（少なくとも1年のmax-age、includeSubDomains、preloadが必要）。初回訪問者にも隙間がなくなりますが、リストから外れるのは遅く困難です。Googleは*“Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.”* (翻訳)「証明書検証エラーのあるHTTPSを決してデプロイしないほどサイト運用が堅牢だと確信するまで、HSTSを有効にしないでください」と警告しています。preloadは一方通行の扉として扱ってください。

よくある神話

• 「HTTPSは現在の大きなランキング向上である」 いいえ。2014年の「非常に軽い」クエリの1 %未満のシグナルと、2015年の「同点の決着」という表現は日付のあるコメントです。現在のガイダンスは、Core Web Vitals以外のページエクスペリエンス要素は「順位を直接高くすることには役立たない」と述べています。
• 「切り替えるとランキングが急落する」 リダイレクトを正しく行えば、そうなりません。恒久リダイレクトでPageRankは失われません。害を生むのは雑な移行であり、プロトコルの切り替えではありません。
• 「Change of Addressツールが必要だ」 HTTP→HTTPSでは必要ありません。ドメイン変更のためだけのものです。
• 「期限切れ証明書はUXだけを壊し、SEOには関係ない」 いいえ。悪い証明書は、GoogleのHTTPS canonical優先をHTTPページへ反転させる条件の1つであり、ユーザー向けのページも壊します。
• 「HTTPSはチェックアウトページだけで重要だ」 いいえ。ChromeはすべてのHTTPページに警告を出し、現代的なAPIは通常、安全なコンテキストを必要とします。
• 「TLSはサイトを遅くする」 実際には通常逆です。HTTPSによってHTTP/2が使えるようになるためです。ただしTLSは性能を「改善することがある」のであって、保証するわけではありません。

HTTP→HTTPSの移行は、より広いサイト移行の規律の中にあります。同時にドメインやプラットフォームも変えるなら、先にそちらを読んでください。移行を重ねるとリスクが増幅します。

AIによる要約

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

• 現在のGoogleガイダンスはランキング向上を約束しません。 ページエクスペリエンス文書は、Core Web Vitals以外の要素は*“don’t directly help your website rank higher”* (翻訳)「ウェブサイトの順位を直接高くすることには役立たない」と述べ、HTTPSもその中に挙げています。
• 2014年のシグナルと2015年の「同点の決着」という表現は歴史です。 2014年は「非常に軽い」、クエリの1 %未満。2015年はIllyesの同点の決着発言です。現在の仕組みを改めて述べたものではありません。いずれにしてもHTTPSを成長のレバーとは考えないでください。
• GoogleのHTTPS canonical優先は別のもの、かつ条件付きです。 Googleは現在、無効な証明書、安全でない画像以外の依存関係、HTTPS→HTTPリダイレクト、HTTPを指す余計なcanonicalタグがない限り、HTTPSページをcanonicalとして優先します。HSTSでは上書きできません。悪い証明書はUXだけでなくcanonical化のリスクです。
• HTTPSが保護するのはトランスポートだけです。 アプリケーションのロジック、エンドポイント、ユーザーの意図は保護しません。有効なHTTPSでもフィッシングページは運用できます。
• HTTPSを使う本当の理由： すべてのHTTPページに出るChromeの「安全ではありません」ラベル（2018年7月以降）、主要ブラウザーすべてのHTTP/2（TLSは性能を「改善することがある」が保証ではないものの、HTTP/1.1より速いことが多い）、安全なコンテキストのブラウザー機能/PWA、デフォルト（ただし上書き可能）の参照データ動作、推定でWebの約89 %に達する最低条件です。
• 移行はサイト移行です。 すべてのURLを1対1で301（301でPageRankは失われない）にし、HTTPSをcanonicalにし、内部リンク・サイトマップ・hreflangを更新し、混在コンテンツを直し、GSCで再確認します（HTTPとHTTPSは別プロパティ）。リダイレクトは1年以上維持し、プロトコル変更にChange of Addressツールは使いません。完全な手順は専用の移行ページにあります。
• 混在コンテンツ： アクティブ（スクリプト/iframe）はブロックされるため先に直し、パッシブ（画像）は警告されます。upgrade-insecure-requests CSPが先回りの安全網です。
• HSTSは最初のリクエストの隙間を閉じますが、クローラーが見ないブラウザー専用の307を使います。サーバー側301の上に置くもので、代わりではありません。preloadはほぼ永久なので急いで有効にしないでください。

公式ドキュメント

検索エンジンとブラウザーチームによる一次資料です。

Google

• HTTPSをランキングシグナルとして使う（2014年の発表） — 元の「非常に軽いシグナル」の記事。
• サーバーでHTTPSを有効にする（web.dev） — 証明書、リダイレクト、canonical、HSTS、Cookie。
• HTTPSが重要な理由（web.dev） — セキュリティとブラウザー機能の理由。
• 混在コンテンツを直す（web.dev） — アクティブとパッシブの混在コンテンツ、upgrade-insecure-requests。
• URL変更を伴うサイト移行 — リダイレクトと、HTTPSにChange of Addressツールが不要なことを含む移行手順。
• ページエクスペリエンスを理解する — ページエクスペリエンスにおけるHTTPSの位置付けと、「直接的なランキング向上を期待しない」ための現在の出典。
• canonical URLの指定方法 — 条件付きのHTTPS対HTTPのcanonical優先と、それを上書きする悪い証明書、安全でない依存関係、ダウングレードリダイレクト。

Chrome / Chromium

• より安全なWebへ（2016年） — 「安全ではありません」展開の始まり。
• 安全なWebは定着する（2018年） — Chrome 68がすべてのHTTPを「安全ではない」と表示すること。

Bing / Microsoft

• Bing Webmaster Guidelines — 一般ガイドライン。現在のHTTPSの表現はブラウザーで確認してください。

出典からの引用

Googleによる記録に残る声明です。各リンクは出典ページの引用箇所へ直接移動します。

Google — 2014年のランキングシグナル発表

• “We’re starting to use HTTPS as a ranking signal. For now it’s only a very lightweight signal—affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content.” (翻訳)「HTTPSをランキングシグナルとして使い始めます。現時点では非常に軽いシグナルで、世界のクエリの1％未満に影響し、高品質なコンテンツなど他のシグナルより重みが小さいものです。」— GoogleのZineb Ait BahajjiとGary Illyes。 引用箇所へ移動
• “But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS.” (翻訳)「ただし、すべてのサイト所有者にHTTPからHTTPSへ切り替えてほしいため、時間とともにこのシグナルを強化する可能性があります。」— 同じ記事。 引用箇所へ移動

Gary Illyes — 同点の決着という説明

• “With the HTTPS ranking boost, it acts more like a tiebreaker. For example, if all quality signals are equal for two results, then the one that is on HTTPS would get … or may get … the extra boost that is needed to trump the other result.” (翻訳)「HTTPSのランキング上の後押しは、同点の決着に近い働きです。たとえば2つの結果の品質シグナルがすべて同じなら、HTTPS上にある方がもう一方を上回るために必要な追加の後押しを得る、または得るかもしれません。」— GoogleのGary Illyes（Search Engine Land経由）。 記事を読む
• “You should switch to HTTPS for users, not as a ranking signal.” (翻訳)「ランキングシグナルのためではなく、ユーザーのためにHTTPSへ切り替えるべきです。」— Gary Illyes、SMX East 2015（Search Engine Land経由）。 記事を読む
• “Basically looking at the first five characters in front of the URL, and if it’s HTTPS … it will get a minimal boost.” (翻訳)「基本的にはURLの先頭5文字を見ていて、それがHTTPSなら最小限の後押しを得ます。」— Gary Illyes、2016年（Search Engine Land経由）。 記事を読む

Google — HTTPS canonical優先（現在のガイダンス）

• “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals such as the following.” (翻訳)「問題や次のような矛盾するシグナルがある場合を除き、Googleは同等のHTTPページよりHTTPSページをcanonicalとして優先します。」— Google Search Central。 引用箇所へ移動
• “Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly.” (翻訳)「不適切なTLS/SSL証明書とHTTPSからHTTPへのリダイレクトは、GoogleがHTTPを非常に強く優先する原因になるため避けてください。」— Google Search Central。 引用箇所へ移動
• “Implementing HSTS cannot override this strong preference.” (翻訳)「HSTSを実装しても、この強い優先を上書きできません。」— Google Search Central。 引用箇所へ移動

Google — 移行とHSTSのガイダンス

• “301 and other permanent redirects don’t cause a loss in PageRank.” (翻訳)「301などの恒久的なリダイレクトでPageRankは失われません。」— Google Search Central。 引用箇所へ移動
• “If you’re moving your site from HTTP to HTTPS, you don’t need to use the Change of Address tool.” (翻訳)「サイトをHTTPからHTTPSへ移行する場合、Change of Addressツールを使う必要はありません。」— Google Search Central。 引用箇所へ移動
• “Don’t enable HSTS until you’re certain your site operation is robust enough to avoid ever deploying HTTPS with certificate validation errors.” (翻訳)「証明書検証エラーのあるHTTPSを決してデプロイしないほどサイト運用が堅牢だと確信するまで、HSTSを有効にしないでください。」— web.dev（Google）。 引用箇所へ移動
• “In some cases, TLS can improve performance, mostly as a result of making HTTP/2 possible.” (翻訳)「場合によってはTLSが性能を改善することがあり、その主な理由はHTTP/2を可能にすることです。」— web.dev（Google）。 引用箇所へ移動

Chrome — 「安全ではありません」の展開

• “Beginning in July 2018 with the release of Chrome 68, Chrome will mark all HTTP sites as ‘not secure’.” (翻訳)「2018年7月のChrome 68リリース以降、ChromeはすべてのHTTPサイトを『安全ではない』と表示します。」— Chromium BlogのChrome Security、Emily Schechter。 引用箇所へ移動

HTTP → HTTPS移行チェックリスト

簡略化した事前確認版です。完全な実行チェックリスト、ステージングでのリハーサル、ロールバック計画はHTTPからHTTPSへの移行を参照してください。

実施前

• 稼働中のHTTPサイトを完全にクロールして保存した（すべての200と既存のすべてのリダイレクト）。
• ランキングのスナップショット、Search Consoleのエクスポート、被リンクプロファイルを保存した。
• TLS証明書を取得してテストした（シグナルとしては無料のDV証明書で十分）。

切り替え

• すべてのHTTP URLを、サーバー側で1対1に対応するHTTPSへ301リダイレクトする。
• リダイレクトチェーンがない（古いURLから最終HTTPS URLへ直接移動する）。
• 対応先がないURLをホームページへ一括リダイレクトしない。
• 各ページがHTTPS URLへrel="canonical"で自己参照する。
• 内部リンク、XMLサイトマップ、hreflangをHTTPSへ更新する（リダイレクト任せにしない）。
• アクティブな混在コンテンツ（スクリプト、スタイル、iframe）を修正する — これらはブロックされる。
• パッシブな混在コンテンツ（画像、メディア）を修正し、upgrade-insecure-requests CSPを設定する。

Search Consoleと移行後

• GSCでHTTPSプロパティを確認した（または全バリエーションを対象とするドメインプロパティ）。
• 新しいHTTPSサイトマップを送信した。
• Change of Addressツールを使っていない（ドメイン変更だけに使う）。
• Disavowファイルがあれば、HTTP URLについて確認した。
• リダイレクトを少なくとも1年間、理想的にはサイトが存続する限り維持する。
• インデックス登録とクロール統計を監視する。回復しない下落は何かが壊れたサイン。

メンタルモデル

1. HTTPSは衛生対策であり、成長のレバーではない。 「非常に軽い」、クエリの1 %未満、同点の決着要因です。ランキングの努力はコンテンツとリンクに使い、Webが必要としているからHTTPSにして先へ進みます。

2. 2014年のランキングシグナルと現在のcanonical優先を分ける。 2014年のランキングシグナルは歴史的にスキームに基づくもので、「最初の5文字」というIllyesの説明は日付のあるコメントであり、現在文書化された仕組みではありません。Googleの現在のHTTPS canonical優先は別で条件付きです。悪い証明書、安全でない依存関係、ダウングレードリダイレクトで、GoogleがHTTPページをインデックスする方向へ反転することがあります。証明書の不具合はUXの緊急事態であるだけでなく、HTTPS canonicalを失う原因にもなります。

3. 移行を運ぶのは恒久リダイレクトで、他は補助シグナル。 PageRankを失わないリダイレクトが、ランキングを実際に移します。canonical、サイトマップ、内部リンクの更新、GSCの再確認は、Googleが移行をより速くきれいに処理する助けにすぎません。

4. 「HTTPSを強制する」2つの層があり、両方必要。 サーバー側の301はクローラーとリンク評価のためです。HSTS（ブラウザー専用の307）は、再訪する人間の訪問者とSSLストリッピング保護のためです。別の問題を解決するもので、HSTSが301の代替になることはありません。

5. 混在コンテンツは、ブラウザーの動作で優先順位を付ける。 アクティブ（スクリプト/スタイル/iframe）はブロックされるため、機能修正として先に対応します。パッシブ（画像/メディア）は警告だけなので次に直します。upgrade-insecure-requestsは見落としを拾う安全網です。

SEOのためのHTTPS — チートシート

ランキングの現実

リダイレクトと移行の事実

混在コンテンツとHSTS

HTTPSを強制し、HSTSを設定する

よくある2つのスタックの例です。まずステージングでテストしてください。HSTSヘッダーは粘着性があり、壊れたリダイレクトループは人を締め出します。

Apache (.htaccess)

# 301 every HTTP request to HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# HSTS — only add once you're confident HTTPS is solid
<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

Nginx

# Redirect HTTP → HTTPS
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

# On the HTTPS server block, add HSTS
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

HSTSヘッダーに; preloadを追加するのは、hstspreload.org へ登録するつもりのときだけです。ほぼ元に戻せません。

コマンドラインから混在コンテンツを探す

HTTPSページをクロールし、HTMLに残ったhttp://サブリソースをgrepします。

macOS / Linux

# Pull a page and flag insecure script/img/link/iframe sources
curl -s https://example.com/ \
  | grep -Eo '(src|href)="http://[^"]+"' \
  | sort -u

Windows (PowerShell)

# Same idea in PowerShell
(Invoke-WebRequest -Uri "https://example.com/").Content `
  | Select-String -Pattern '(src|href)="http://[^"]+"' -AllMatches `
  | ForEach-Object { $_.Matches.Value } | Sort-Object -Unique

サイト全体を調べるなら、ページごとにスクリプトを使うより、クローラー（Ahrefs Site Audit、Screaming Frog）またはChrome DevToolsのコンソールの方が速いです。

時間をかける価値のある資料

私の講演

• HTTPSで後悔しないために — SMX East 2016 （SlideShare）— TLS、HTTPS実装でよくある失敗、移行の注意点を詳しく説明します。（継続的な免責事項：「これはこれらのシステムについての私の理解であり、含まれる普及統計は2016年のものです」）

私の関連記事

• テクニカルSEO入門 — より大きな全体像の中でHTTPSが占める位置。

他者による資料（公式）

• GoogleのサーバーでHTTPSを有効にする と混在コンテンツを直す — 実装文書を集中的に確認できる最も有用な資料です。
• hstspreload.org — preloadを確定する前に適格性を確認します。
• SSL Labs Server Test — TLS設定を評価します。

業界の資料

• ランキング要因としてのHTTPS — Search Engine Journal — シグナルの説明、実際の重み、レバーではなく同点の決着要因であり続ける理由。
• GoogleのGary Illyes：HTTPSは同等の検索結果の決着要因になり得る （Search Engine Land）— Illyesの「同点の決着」という説明を最初に報じた記事。
• Google、安全なHTTPS/SSLサイトをランキングで後押し （Search Engine Land）— 2014年の発表と当時の業界の反応。
• HSTSとは何か、どう使うか （Kinsta）— preloadリストのリスクと固定化の警告を含む実装ガイド。
• Let’s Encrypt — 無料で自動化されたDV証明書の認証局。OV/EVに料金を払わずhttps://スキームが必要なサイトで広く使われています。
• HTTPSは簡単 （Troy Hunt）— TLS設定をゼロから始める人向けの短い動画シリーズ。

引用する価値のある統計

• HTTPSは「非常に軽いシグナルで、世界のクエリの1 %未満に影響する」。 HTTPS is “a very lightweight signal—affecting fewer than 1% of global queries.” (翻訳)「HTTPSは非常に軽いシグナルで、世界のクエリの1 %未満に影響します」。 2014年の開始時にGoogle自身が示したランキングの重みです。期待値を適正にするための歴史的な数字としては最良ですが、現在の仕組みを言い直したものではありません。 出典
• Chrome 68（2018年7月）以降、すべてのHTTPページに「安全ではありません」と表示。 “Beginning in July 2018 with the release of Chrome 68, Chrome will mark all HTTP sites as ‘not secure’.” (翻訳)「2018年7月、Chrome 68のリリース以降、ChromeはすべてのHTTPサイトを『安全ではない』と表示します」。切り替える最も目に見える実務上の理由です。 出典
• 現在、Webサイトの約89 %がHTTPSを使う。 最低条件であり、SEO上のリスクは切り替えの利益ではなく未対応側に残ることです（W3Techs、2026年。現在の数字を確認してください）。
• 301リダイレクトでPageRankは失われない。 “301 and other permanent redirects don’t cause a loss in PageRank.” (翻訳)「301などの恒久的なリダイレクトでPageRankは失われません」。Googleの明確な説明であり、「切り替えるとリンク評価を失う」という神話を終わらせます。 出典

HTTPSのSEOをテストする

HTTPSとSEOについて、5つの簡単な質問です。それぞれ回答を選んでから、確認してください。

変更履歴