HTTP/2とHTTP/3

TL;DR — HTTP/2とHTTP/3は、ブラウザーとWebサイトのサーバーが通信に使う「言語」の新しいバージョンです。多数のファイルを複数の接続ではなく1つの接続で取得するため、ページの読み込みが速くなります。Googleでのランキングを直接押し上げるわけではありませんが、サイトが速くなれば間接的な効果はあります。大半のサイトでは、大規模なプロジェクトではなくCDNで設定を有効にするだけです。

タップして展開

The chart compares HTTP/1.x, HTTP/2, and HTTP/3 request share worldwide over four weeks. It is a Cloudflare traffic view, not a census of all websites.

HTTP/2とHTTP/3とは

Webページを開くたびに、ブラウザーとサイトのサーバーはHTTPというプロトコルを使って会話します。長年使われてきたのはHTTP/1.1でしたが、そこには大きなボトルネックがありました。ファイルを基本的に1つずつ取得するため、ブラウザーは通常のページを読み込むだけでも、複数の並列接続を開かなければならなかったのです。

HTTP/2（2015年）は、その最大の問題を解決しました。ブラウザーとサーバーが同じ1つの接続上で、多数のリクエストとレスポンスを同時に送れるようにしたのです。この仕組みを多重化（multiplexing）と呼びます。また、各リクエストに付く繰り返しの多いヘッダー情報も圧縮します。その結果、余分な処理が減り、ページの読み込みが速くなります。

HTTP/3（2022年）は、そこからさらに一歩進みます。HTTP/2の機能を保ちながら、下層の通信方式を変えました。HTTP/2はTCPというトランスポートの上で動きますが、TCPには、データのパケットを1つ失うと、その接続上のすべてが再送を待たなければならないという性質があります。HTTP/3はTCPを新しいトランスポートであるQUICに置き換えます。失われたパケットが接続上のすべてのストリームではなく、該当するファイルのストリームだけを止める仕組みです。すべてのファイルが完全に独立するわけではなく、接続自体は共有しますが、パケットの欠落によってページ全体が引きずられることはなくなります。電波の弱い場所で使うスマートフォンのような不安定な接続ほど、この効果が大きくなります。

SEOのために何かする必要はありますか？

短い答えは、ランキングのためなら、ほとんど何も必要ありません。

• どちらも直接的なランキング要因ではありません。 GoogleはHTTP/2によるランキング向上はないと明言しています。HTTP/3は、Googleのクローラーの仕組みにまだ含まれていないため、そもそもこの問いがほぼ当てはまりません。
• 本当のメリットは速度であり、速度は間接的に役立ちます。 サイトが速くなると、Core Web Vitalsが改善する可能性があります。Core Web VitalsはGoogleのページエクスペリエンスシグナルの一部です。したがって効果は実在しますが、1段階離れた間接的なものです。
• すでにHTTP/2を使っている可能性が高いでしょう。 Webの大半がHTTP/2上にあります。CDN（CloudflareやFastlyなど）を使っていれば、HTTP/2、そして多くの場合HTTP/3も、通常はスイッチを入れるだけです。ただし、その後に簡単な確認をする価値はあります。スイッチがすべての訪問者に効いたと決めつけず、ブラウザーのNetworkパネルで実際にどのプロトコルがネゴシエートされたかを確認してください。

多くの人が間違える、たった1つのこと

HTTP/2 Server Pushという古い機能について、今でも質問する人がいます。これを前提に構築してはいけません。実際には終わった機能です。ChromeはChrome 106からデフォルトで無効にし、利用者はほとんどおらず、サイトを速くするどころか遅くすることもありました。ブラウザーにリソースを早めに取得するよう知らせたいなら、代わりに103 Early Hintsや<link rel=preload>タグのような現代的な手段を使ってください。

QUICの実際の動き、現在のGooglebotの挙動、実際の普及率、そして有効化の方法まで知りたい場合は、Advancedタブに切り替えてください。

TL;DR — HTTP/2は、1つのTCP接続上での多重化、HPACKヘッダー圧縮、RFC 9218の優先度ヒントです。HTTP/3は同じ意味論をTCPではなくQUIC/UDP上で実現し、一方のストリームで失われたパケットが他方のストリームを止めることを防ぎます。ただし、ストリームは接続の輻輳制御とQPACKの状態を共有するため、ファイルごとの完全な独立ではなく、実際の問題を解決する仕組みです。どちらも直接的なランキング要因ではありません。GoogleはHTTP/2でクロールしてもランキング向上はないと説明しており、Googleのクローラー文書はHTTP/3を対応プロトコルとして記載していません。GooglebotはデフォルトでHTTP/1.1を使い、対象サイト（HTTPS + h2対応）ではHTTP/2を使います。文書化されたオプトアウトは421ステータスです。SEO上の効果は、実ユーザーの速度がCore Web Vitalsに反映されるという間接的なものです。新しいプロトコルをネゴシエートしただけでCore Web Vitalsや検索パフォーマンスが改善する保証はありません。Webの大半はHTTP/2上にありますが、HTTP/3は実際のリクエストではまだ少数派です。CDNが「対応」していても、発見やフォールバックのため、すべての訪問がHTTP/3になるとは限りません。避けるべきものは2つです。ランキング向上を追いかけることと、Server Pushです（Chrome/Chromiumではv106以降デフォルトで無効）。代わりに103 Early Hintsまたはrel=preloadを使ってください。

各プロトコルが実際に変えるもの

この2つのアップグレードを区別できれば、他のことも理解しやすくなります。

**HTTP/2（2015年、RFC 7540）**はHTTPの意味論を保ちながら、バイトの移動方法を大きく改めました。

• 多重化。 HTTP/1.1の「接続ごとに1つずつ」というモデルとは異なり、1つの接続上で多数のリクエストとレスポンスをインターリーブします。HTTP/1.1ではブラウザーが複数の並列接続を開く必要がありました。
• HPACKヘッダー圧縮。 各リクエストに付く繰り返しのヘッダーを圧縮して、オーバーヘッドを減らします。
• ストリームの優先順位付け — ただし、元の方式ではありません。RFC 7540の優先度ツリーはHTTP/2の更新仕様であるRFC 9113によって非推奨になりました。現在のシグナルはRFC 9218の拡張可能な優先順位付け方式で、単純なurgency/incrementalヒントを使います（HTTP/2とHTTP/3の両方で利用可能）。これは助言的なもので、サーバーは尊重しても、一部だけ尊重しても、無視しても構いません。
• もともとはServer Pushもありました。HTTP/2とHTTP/3の仕様では今も技術的に定義されていますが、ブラウザーは実際には対応を取りやめています（詳細は後述）。
• 実際にはHTTPSが必要です。主要なブラウザーで、暗号化されていないHTTP/2をネゴシエートするものはありません。

**HTTP/3（2022年、RFC 9114）**はHTTP/2の意味論を保ちながら、トランスポートを置き換えます。

• TCPではなく、UDP上に構築されたトランスポートであるQUICを使います。
• HTTP/2のトランスポート層のヘッドオブラインブロッキングを狭めますが、あらゆる形態を消すわけではありません。HTTP/2では、多重化されたすべてのストリームが1つのTCP接続に乗るため、パケットを1つ失うと、再送されるまですべてのストリームが止まります。QUICでは各HTTPリクエストが自分のストリームを持ち、一方のストリームで失われたパケットが他方のストリームを止めなくなります。これが本当の修正です。ただし、すべてのファイルを完全に独立させるわけではありません。同じQUIC接続のストリームは輻輳制御とフロー制御を共有するため、ネットワーク経路が悪ければ、ストリーム間の停止はなくてもすべてが遅くなります。1つのストリーム内のバイトは順序どおりに届くため、複数のパケットにまたがるリソースは自分の失われたパケットを待ちます。また、QPACKのヘッダー復号は、他のストリームが依存できる共有制御ストリーム上で動きます。「損失がストリーム間に漏れなくなる」と考えてください。「各ファイルが完全に隔離されて送られる」という意味ではありません。
• QUICにはTLS 1.3が組み込まれており、暗号化は必須です。セッション再開による接続確立の高速化もサポートし、再訪問時には任意の0-RTTモードも使えます。0-RTTは条件付きで、常に速い専用レーンになるわけではありません。送信する「早期データ」は攻撃者によって再生される可能性があるため、ブラウザーとサーバーは安全に送れるリクエストを制限します。サーバーは拒否して通常のハンドシェイクに戻ることもできます（425 Too Earlyを参照）。
• QUICは接続移行もサポートします。クライアントは新しいネットワーク経路を検証することで、WiFiから携帯回線への変更をまたいで接続を維持できます。ただしQUIC v1ではクライアント開始のみです（サーバーが単独で接続を移行することはできません）。経路検証、アドレス変更、輻輳状態のリセットがあるため、継続性は条件付きであり、保証されません。

正直に言うと、HTTP/3の最大の効果が現れるのは低速またはパケット損失の多い接続です。高速で安定したネットワークを使うユーザーは、違いをあまり感じません。トラフィックの中で最も遅い層ほど大きな恩恵を受けるという点を、Will NyeはSearch Engine Journalでうまく説明しています 。閲覧者が全員光回線を使うサイトにHTTP/3の効果を過大に売り込む必要はありません。

これはランキングに影響しますか？（いいえ — 正確な表現はこちらです）

ここに来るSEO担当者が最も知りたいのはこの点です。まずGoogle自身のクローラー文書を確認しましょう。Googleクローラーの概要 で、GoogleはクローラーがHTTP/1.1とHTTP/2に対応し、クロール性能が最もよくなる方を選ぶと説明しています。そして次のように述べています。

“The default protocol version used by Google’s crawlers is HTTP/1.1; crawling over HTTP/2 may save computing resources (for example, CPU, RAM) for your site and Googlebot, but otherwise there’s no Google-product specific benefit to the site (for example, no ranking boost in Google Search).” (翻訳) 「Googleのクローラーがデフォルトで使うプロトコルはHTTP/1.1です。HTTP/2でクロールすると、サイトとGooglebotの計算資源（CPUやRAMなど）を節約できる場合がありますが、それ以外にGoogleの製品に固有のメリット（Google検索でのランキング向上など）はありません。」

これほど明確な説明は、Googleとしても珍しいほどです。HTTP/2は接続の両側にとってトランスポート層の効率化手段です。サーバーとGooglebotの処理を少し減らせる可能性はありますが、ランキングシグナルではありません。

実際のSEO上の関係は間接的であり、明確に述べる価値があります。実ユーザーのページ読み込みが速くなると、**Core Web Vitals**に反映されます。これはGoogleのページエクスペリエンスシグナルの一部です。したがって、SEOにおけるHTTP/2とHTTP/3の価値は、Googleが実際に測定する指標に現れるユーザー体験への投資です。スイッチを入れるだけでランキングが上がるわけではありません。

Googlebotは現在どのように動作するか

これは多くの競合解説が省いている部分で、このページで最も役立つセクションです。Google自身のクローラー文書は具体的です。

• デフォルトはHTTP/1.1です。 クローラーの概要によれば、デフォルトのプロトコルはHTTP/1.1です。Googlebotは過去のクロール統計に応じて、クロールセッションの間にHTTP/2へ切り替える場合があります。

• HTTP/2でのクロールは、オンデマンドではなく適格性に基づきます。 Googlebotは2020年11月中旬に一部サイトのHTTP/2クロールを開始しました（GoogleのGooglebot will soon speak HTTP/2 (翻訳) 「GooglebotがまもなくHTTP/2を話すようになります」 という記事で発表）。サイトが適格になるには、HTTP/2対応のHTTPSで提供し、アップグレードの効果が出るほどクロールされている必要があります。自分で強制するものではありません。

• 421でオプトアウトできます。 Googleはクローラーの概要 でオプトアウト方法を説明しています。

  “To opt out from crawling over HTTP/2, instruct the server that’s hosting your site to respond with a 421 HTTP status code when Google attempts to access your site over HTTP/2.” (翻訳) 「HTTP/2でのクロールをオプトアウトするには、GoogleがHTTP/2でサイトへアクセスしようとしたとき、サイトをホストしているサーバーが421 HTTPステータスコードを返すように指示します。」

• HTTP/3はGoogleのクローラー文書に記載されていません。 この記事の執筆時点で、現在のクローラー概要は対応バージョンとしてHTTP/1.1とHTTP/2を挙げ、HTTP/3について何も述べていません。したがって、文書化されたクロールプロトコルとしては提供されていません。これはGoogleが公開した（または公開していない）内容についての説明であり、どこかのリクエストが絶対にHTTP/3に触れないという約束ではありません。Barry SchwartzもSearch Engine Roundtable で同じ不在を報告しており、Will NyeのSEJガイドもGooglebotは現在HTTP/3をサポートしていない と記しています。

HTTP/2の公開（2015年）からGooglebotが対応するまでには、およそ5年の空白がありました。HTTP/3が最終化されたのは2022年なので、このパターンに従えば、クローラー対応にはまだ時間がかかるかもしれません。私の見方はこうです。HTTP/3クロールを気長に待つ必要はありませんが、サイト改善をHTTP/3に依存して先延ばしにもしないでください。HTTP/3を導入する理由はGooglebotではなく、ユーザーです。

先に進む前に、2つ指摘しておきます。1つ目は、2021年のGoogle I/Oの頃、John MuellerがGoogleはすでに全URLの半数以上をHTTP/2でクロールしていると述べたことです。多重化とヘッダー圧縮によって接続数と帯域幅が大きく減り、Googleのクロールインフラとサイト側の配信インフラの両方に有益だったと説明しました。2つ目はBingについてです。Microsoftが公開したHTTP/2またはHTTP/3のクロールポリシーについて、同等のものは見つけられませんでした。Bingにはクロール効率全般（IndexNow 、Crawl Control、サイトマップ処理）に関する資料はありますが、Googleのようにプロトコル対応を明示した文書はありません。推測で補うつもりはありません。Bingに固有の答えが必要なら、Bing Webmaster Blog を直接確認してください。

Chromeのツールが示すもの（そして示さないもの）

ChromeのLighthouseにはModern HTTPというインサイトがあります。古いHTTPバージョンでサイトが配信されている場合に知らせるもので、基本的にはファイルがHTTP/2またはHTTP/3で届いているかを確認します。ただし、知っておくべき注意点があります。このインサイトが表示されるのはChrome DevToolsのパフォーマンストレースであり、多くのSEO担当者が確認する標準の公開PageSpeed Insightsレポートではありません。Lighthouseには以前、専用のuses-http2監査もありましたが、すべてのリクエストについてh1とh2とh3を確実に判定するのが難しかったため無効化されました。通常のPSIレポートで現在も使える「HTTP/2を使用」合否表示を探してはいけません。確実には表示されないからです。実際のプロトコルを確認するには、ブラウザーのNetworkパネルのProtocol列を見るか、WebPageTestのようなツールを使ってください。

2026年の実際の普及状況

一般に公開されている最良のデータセットは、（AkamaiのRobin Marxが執筆した）2024 Web AlmanacのHTTP章 です。Webの構成は次のようになっています。

• ホームページ： デスクトップではHTTP/1.1が約22%、HTTP/2が約71%、HTTP/3が約7%です（モバイルも近く、約21% / 約70% / 約9%）。
• すべてのリクエスト合計： およそ**85%**がHTTP/2以降で、HTTP/1.1のままなのは約15%です。
• HTTP/3に対応可能なサイトは、実際に使うサイトより多いです。 ホームページの約26〜28%がalt-svcヘッダーでHTTP/3対応を通知していますが、実際にHTTP/3で配信されるリクエストははるかに少数です。
• CDNが大部分を担っています。 Almanacのデータでは、CDN経由のリクエストの約**96%**がHTTP/2以降を使う一方、CDNを使わないリクエストの約29%は依然としてHTTP/1.1です。この差が、「CDNを使えばよい」という議論を1つの統計で表しています。

他の場所で引用される統計について、1つ注意があります。「上位1,000万サイトの25%がHTTP/3に対応している」という古い数字は、Almanacの「実際のリクエストの7〜9%がHTTP/3で配信される」という数字とは別のものを測っています。大規模ドメインのサイト単位の対応率と、実際のリクエストのシェアは異なります。両方が同時に真であり得るので、一方が他方と矛盾すると考えないでください。

実際に有効にする方法

圧倒的多数のサイトでは、これはサーバー移行ではありません。ただし、HTTP/3は発見される必要があり、気付かないままフォールバックする可能性もあるため、「スイッチを入れる」だけがすべてではありません。

• CDNを使う。 CDN（Cloudflare、Fastly、Google Cloud CDNなど）でHTTP/2とHTTP/3を有効にするのは、通常チェックボックスを1つ選ぶだけで、はるかに簡単な方法です。その後、ブラウザーのNetworkパネルまたはcurl --http3でネゴシエートされたプロトコルを確認し、チェックボックスが最初から最後まで機能したと決めつけないでください。TLS/ALPNの設定、オリジンからエッジまでの対応、エッジからクライアントまでの対応がすべて一致する必要があります。
• HTTPSで配信する。 これは両プロトコルの実務上の前提です。主要なブラウザーで、暗号化されていないHTTP/2またはHTTP/3をネゴシエートするものはありません。
• HTTP/3の発見とフォールバックを理解する。 サイトへのブラウザーの最初の接続は、通常まだTCP（HTTP/2またはHTTP/1.1）でネゴシエートされます。サーバーまたはCDNがAlt-Svcヘッダー、あるいはDNSのHTTPS/SVCBレコードでHTTP/3の利用可能性を通知し、ブラウザーがそれをキャッシュして、次の接続でQUICを試します。ネットワークがUDPをブロックしている場合やQUICのハンドシェイクが失敗した場合、ブラウザーは自動的にHTTP/2またはHTTP/1.1へ戻ります。これは設計どおりの動作ですが、「オリジンがHTTP/3に対応している」ことは、特に初回訪問で、すべての訪問が実際にHTTP/3を使うことを意味しません。100%だと決めつけず、実際の比率を測ってください。
• 自前ホスティングならサーバーソフトウェアの対応を確認する。 特にHTTP/3のWebサーバー対応は歴史的に遅れていました（変化が速いため、スタックの現在の状態を確認してから対応済みと判断してください）。CDNを使う方法が実務的なデフォルトである理由はここにもあります。

気にしなくてよいもの：Server Push

誰かがHTTP/2 Server Pushの実装を提案したら、答えは「いいえ」です。HTTP/2とHTTP/3の両仕様には今も技術的に定義されていますが、重要なブラウザーでは終わっています。ChromeのチームはRemoving HTTP/2 Server Push （Barry Pollard）で削除を説明しました。要点は次のとおりです。

“support of HTTP/2 Server Push will be disabled by default in Chrome 106 and other Chromium-based browsers.” (翻訳) 「HTTP/2 Server Pushのサポートは、Chrome 106およびその他のChromiumベースのブラウザーでデフォルト無効になります。」

普及率はすでに急落していました。PollardによればHTTP/2サイトでの利用は*“dropped to 0.7%”* (翻訳) 「0,7 %に落ちた」そうです。さらに重要なのは、性能面の根拠が成立しなかったことです。記事では、Pushが*“without a clear net performance gain and in many cases performance regressions.”* (翻訳) 「明確な純粋な性能向上なしに、そして多くの場合は性能低下を伴って」結果を出していたと説明されています。これはChrome/Chromiumが文書化した削除です。他のブラウザーエンジンも実際には同じ方向へ進んでいますが、「すべてのエンジンのソースコードからPushが消えた」という主張ではなく、設計上は「Pushはどこでも終わった」という実務上の現実を前提にしてください。

文書化されている代替手段は次のとおりです。

“103 Early Hints is a much less error-prone alternative with many of the same upsides as Push, and a lot less of the downsides” (翻訳) 「103 Early Hintsは、Pushと同じ利点の多くを持ちながら、問題点がはるかに少ない、エラーの起こりにくい代替手段です。」

加えて、必要になると分かっているリソースには標準の<link rel=preload>を使います。これらはresource hintsでも説明しています。結論として、2026年にServer Pushを前提に設計しないでください。

セキュリティ上の注意点（正直な1段落）

HTTP/2の大きな強みは、短期間ながら弱点にもなりました。2023年、HTTP/2を速くする多重化が、記録を更新するDDoS手法であるHTTP/2 Rapid Reset（CVE-2023-44487）の仕組みになりました。Cloudflareのエンジニアが説明した ように、多数のストリームを素早く開いてキャンセルできることは*“an obvious vector for denial-of-service,”* (翻訳) 「サービス拒否攻撃の明白なベクトル」であり、主要プロバイダーは毎秒数億リクエストに及ぶ攻撃を緩和しなければなりませんでした。これはHTTP/2を避ける理由ではありません。現代のサーバーとCDNにはパッチが適用されています。ただし、プロトコルを良い面だけのものとして売り込みすぎないためにも、正直な一文として触れておく価値があります。自前でホストしているなら、サーバーソフトウェアを最新に保ってください。

Webパフォーマンスにおける位置付け

HTTP/2とHTTP/3はトランスポート層のレバーであり、他のWebパフォーマンスクラスターと同じ下流の指標に影響します。配信が速くなるとTTFBとLCPが改善するため、このプロトコルの話は**Core Web Vitalsにつながります。CDNは通常、これらのプロトコルを有効にする方法であり、実際の普及を最も大きく後押ししたものでもあります。キャッシュとresource hints**（Server Pushを置き換えたEarly Hintsやpreloadを含む）は、リソースをブラウザーへ届ける速さをさらに整えます。HTTP/2/HTTP/3は配信層の一部として適切に設定する価値がありますが、ユーザーのためのものであって、ランキングボタンではありません。

AIによる要約

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

• **HTTP/2（2015年）**は、1つのTCP接続上で多重化、HPACKヘッダー圧縮、RFC 9218の優先度ヒントを使います（古いRFC 7540の優先度ツリーは非推奨です）。HTTP/3（2022年）はTCPの代わりにQUIC/UDP上で同じ意味論を実現し、一方のストリームで失われたパケットが他方のストリームを止めることを防ぎます。ただしストリームは接続の輻輳制御とQPACKヘッダー状態を共有するため、ファイルごとの完全な独立ではなく、ストリーム間のヘッドオブラインブロッキングを本当に修正する仕組みです。
• 直接的なランキング要因ではありません。 Googleは、HTTP/2でクロールしてもランキング向上はないと明言しています。これはシグナルではなく、トランスポート層の効率化手段です。新しいプロトコルをネゴシエートしただけでCore Web Vitalsや検索パフォーマンスが改善する保証もありません。
• Googlebotの実際のポリシー： デフォルトはHTTP/1.1、適格な場合（HTTPS + h2対応 + 十分なクロール量）はHTTP/2で、421でオプトアウトできます。**Googleのクローラー文書は、この記事の執筆時点でHTTP/3を対応プロトコルとして記載していません。**これは文書化された内容についての説明であり、どのリクエストも一切HTTP/3に触れないという証明ではありません。
• SEO上の効果は間接的です： 実ユーザーの読み込みが速くなる → Core Web Vitals → ページエクスペリエンス、という流れです。HTTP/3は低速またはパケット損失の多い接続に最も役立ちます。
• QUICの他の利点は条件付きで、自動ではありません。 0-RTTの再開は再生に注意が必要な「早期データ」を送り、拒否されることがあります（425 Too Early）。また、WiFiから携帯回線への変更に耐える接続移行は、QUIC v1ではクライアントが開始して経路を検証するもので、継続性を保証しません。
• 普及状況（2024 Web Almanac）： すべてのリクエストの約85%がHTTP/2以降です。HTTP/3は依然として少数派（リクエストの約7〜9%）ですが、対応を通知するサイトはもっと多く（約26〜28%）あります。CDNのリクエストは約96%がHTTP/2以降です。
• CDNのスイッチで有効化できます（Cloudflare、Fastly、Google Cloud CDN）。その後、ネゴシエートされたプロトコルを確認してください。HTTP/3はAlt-Svc/DNSレコードで発見され、UDPがブロックされるとHTTP/2またはHTTP/1.1へフォールバックします。「対応している」ことと「すべての訪問で使われる」ことは同じではありません。両プロトコルでHTTPSが前提です。
• Server Pushは実質的に終わっています。 Chromeはv106以降デフォルトで無効にしました（仕様上は残っていますが、デフォルトでは実装されていません）。HTTP/2サイトでの普及率は約0,7 %まで下がり、性能低下を起こすこともありました。代わりに103 Early Hintsまたは<link rel=preload>を使います。
• セキュリティ上の注意： HTTP/2の多重化は、2023年のRapid Reset DDoS（CVE-2023-44487）の仕組みになりました。パッチは存在しますが、サーバーソフトウェアを最新に保ってください。
• Bing固有のHTTP/2/HTTP/3クロールポリシーは見つかりませんでした。 推測で補わないでください。

公式ドキュメント

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

Google

• Googleクローラーとフェッチャーの概要 — GooglebotがHTTP/1.1とHTTP/2に対応すること（デフォルトはHTTP/1.1、HTTP/2によるランキング向上はないこと）と、421によるオプトアウトを示す、現在の権威ある説明です。HTTP/3への言及はありません。
• Googlebot will soon speak HTTP/2 (翻訳) 「GooglebotがまもなくHTTP/2を話すようになります」 （2020年9月）— HTTP/2クロールを2020年11月中旬に開始すること、適格性、オプトアウトを発表した記事です。

Chrome / web.dev

• ChromeからHTTP/2 Server Pushを削除 （Barry Pollard）— 削除の時期（Chrome 106以降）、普及率と性能に関する理由、推奨される代替手段（103 Early Hints、rel=preload）を説明しています。

Bing / Microsoft

• この調査では、HTTP/2またはHTTP/3のクロールポリシーについて同等の声明は見つかりませんでした。Bingのクロール効率全般の指針については、Bing Webmaster Blog とIndexNow を参照してください。

標準規格とデータ

• RFC 9114 — HTTP/3 とRFC 9113 — HTTP/2 — 現在のプロトコル仕様です（RFC 9113は元のRFC 7540に取って代わり、その優先度方式を非推奨にしています）。
• RFC 9000 — QUIC とRFC 9001 — TLSによるQUICの保護 — ストリームのフロー制御と接続移行を含む、QUICのトランスポートとTLS 1.3統合を説明します。
• RFC 9218 — HTTPの拡張可能な優先順位付け方式 — HTTP/2とHTTP/3で使う、現在の助言的なurgency/incremental優先度シグナルです。
• RFC 8470 — HTTPでの早期データの利用 — 0-RTTの再生リスクと425 Too Earlyレスポンスを説明します。
• RFC 7838 — HTTP Alternative Services とRFC 9460 — DNSによるサービスバインディングとパラメーター仕様（SVCBおよびHTTPSレコード） — クライアントがHTTP/3の利用可能性を発見する方法（Alt-Svc、DNSレコード）を説明します。
• Web Almanac 2024 — HTTP章 （Robin Marx、Akamai）— 実際の普及状況を知るための最良の公開データセットです。

出典からの引用

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

Google — ランキング向上なしとクロールポリシー

• “The default protocol version used by Google’s crawlers is HTTP/1.1; crawling over HTTP/2 may save computing resources (for example, CPU, RAM) for your site and Googlebot, but otherwise there’s no Google-product specific benefit to the site (for example, no ranking boost in Google Search).” (翻訳) 「Googleのクローラーがデフォルトで使うプロトコルはHTTP/1.1です。HTTP/2でクロールすると、サイトとGooglebotの計算資源（CPUやRAMなど）を節約できる場合がありますが、それ以外にGoogle製品固有のメリット（Google検索でのランキング向上など）はありません。」 — Googleのクロールインフラ文書。 引用箇所へ移動
• “To opt out from crawling over HTTP/2, instruct the server that’s hosting your site to respond with a 421 HTTP status code when Google attempts to access your site over HTTP/2.” (翻訳) 「HTTP/2でのクロールをオプトアウトするには、GoogleがHTTP/2でサイトへアクセスしようとしたとき、サイトをホストするサーバーが421 HTTPステータスコードを返すようにします。」 引用箇所へ移動

Chromeチーム（Barry Pollard）— Server Pushは終了

• “support of HTTP/2 Server Push will be disabled by default in Chrome 106 and other Chromium-based browsers.” (翻訳) 「HTTP/2 Server Pushのサポートは、Chrome 106およびその他のChromiumベースのブラウザーでデフォルト無効になります。」 — Chrome for Developersのブログ。 引用箇所へ移動
• 普及については、HTTP/2サイトでの利用が*“dropped to 0.7%”* (翻訳) 「0,7 %に落ちた」とされ、分析ではPushが*“without a clear net performance gain and in many cases performance regressions.”* (翻訳) 「明確な純粋な性能向上なしに、そして多くの場合は性能低下を伴って」結果を出していたことが示されました。 引用箇所へ移動
• 推奨される代替手段は、“103 Early Hints is a much less error-prone alternative with many of the same upsides as Push, and a lot less of the downsides.” (翻訳) 「103 Early Hintsは、Pushと同じ利点の多くを持ちながら、問題点がはるかに少ない、エラーの起こりにくい代替手段です。」 引用箇所へ移動

Cloudflare（Lucas PardueとJulien Desgats）— セキュリティ上の注意点

• HTTP/2が大量の並列処理を開始できることにより、ストリームを素早くキャンセルする行為が*“an obvious vector for denial-of-service,”* (翻訳) 「サービス拒否攻撃の明白なベクトル」になりました。これが2023年のRapid Reset攻撃（CVE-2023-44487）の基礎です。 技術的な解説を読む

HTTP/2またはHTTP/3について何かするべきですか？

「これについて対応する必要があるか」という問いへの簡単な手順です。

開始：すでにCDNを使っていますか？

• はい → すでにHTTP/2を使っている可能性が非常に高く、HTTP/3もスイッチで有効にできる可能性があります。HTTP/2がオンになっていることを確認し、CDNが提供していればHTTP/3を有効にします。これで完了です。これはUX/Core Web Vitalsの改善であり、ランキングを動かすレバーではありません。次へ進みます。
• いいえ → 続けます。

自前でホスティングし、HTTPSで配信していますか？

• HTTPSではない → まずそこを直してください。HTTPSは両プロトコルの実務上の前提です（他の理由でも重要です）。その後、もう一度確認します。
• HTTPS上の自前ホスティング → 最も簡単なアップグレード方法は、Webサーバーを再設定するより、前段にCDNを置くことです。サーバーを直接設定したい場合は、利用可能だと決めつける前に、サーバーソフトウェアが現在HTTP/2（そして別途HTTP/3）に対応していることを確認してください。

目的はランキング向上ですか？

• はい → 期待値をリセットしてください。GoogleはHTTP/2によるランキング向上はないと述べ、Googleのクローラー文書にはHTTP/3自体が記載されていません。メリットは速度からCore Web Vitalsへつながる間接的なもので、プロトコルを切り替えただけで保証されるものでもありません。直接的なシグナルではなく、ユーザーとページエクスペリエンスのために導入してください。

閲覧者はおもに低速または不安定な接続（モバイル中心、新興市場）を使っていますか？

• はい → HTTP/3を優先する価値があります。QUICのストリーム単位の損失分離と、（クライアントが開始する条件付きの）接続移行は、まさにこのような環境で最も役立ちます。
• いいえ、ほとんどが高速で安定 → HTTP/2で効果の大部分を得られます。HTTP/3は追加的な効果が小さくなります。CDNで有効にするのは問題ありませんが、過剰に投資しないでください。

HTTP/2 Server Pushを検討していますか？

• やめてください。 Chromeはv106以降デフォルトで無効にしており、他のエンジンも実際には同じ方向へ進んでいます。代わりに103 Early Hintsまたは<link rel=preload>を使ってください。

HTTP/2とHTTP/3チートシート

HTTP/1.1、HTTP/2、HTTP/3の比較

Googlebotの動作

要点

• HTTP/2によるランキング向上はない — Googleが明示しています。新しいプロトコルをネゴシエートしただけで、Core Web Vitalsや検索パフォーマンスが改善する保証もありません。
• SEO上のメリットは間接的です： 速度 → Core Web Vitals → ページエクスペリエンス。
• 普及状況（2024 Web Almanac）： リクエストの約85%がHTTP/2以降、HTTP/3はリクエストの約7〜9%、CDN経由のリクエストの約96%がHTTP/2以降です。
• 有効にする最も簡単な方法： CDNのスイッチです。その後、ネゴシエートされたプロトコルを確認してください。HTTP/3の発見（Alt-Svc/DNS）とUDPのフォールバックがあるため、「対応している」ことと「すべての訪問で使われる」ことは同じではありません。
• Server Push： 実務上は終了しています（Chrome 106以降、デフォルトで無効。ほかのエンジンも同じ方向）が、仕様には残っています。103 Early Hintsまたは<link rel=preload>を使ってください。
• セキュリティ： HTTP/2の多重化は2023年のRapid Reset DDoS（CVE-2023-44487）を可能にしました。パッチを適用し、サーバーを最新に保ってください。

避けるべき間違いと神話

神話：「HTTP/2またはHTTP/3に切り替えればランキングが上がる」 直接には上がりません。GoogleはHTTP/2でクロールしてもランキング向上はないと述べ、Googleのクローラー文書にはHTTP/3が記載されていません。SEO上の価値があるとしても、実ユーザーの読み込みが速くなりCore Web Vitalsに反映されるという間接的なものです。新しいプロトコルをネゴシエートしただけで、それさえ保証されるわけではありません。シグナルのためではなく、ユーザーのために導入してください。

神話：「Googlebotは、サーバー/CDNが対応しているプロトコルなら、HTTP/3を含めて何でも使ってクロールする」 Googleが公開した文書によれば、そうではありません。GooglebotはデフォルトでHTTP/1.1を使い、適格な場合はHTTP/2を使います。現在のクローラー文書には、HTTP/3が対応プロトコルとしてまったく記載されていません。CDNが人間の訪問者にはHTTP/3で配信しながら、GooglebotはHTTP/1.1またはHTTP/2で取得することは可能です。2つの事実は同時に成り立ちます。

神話：「性能を高めるためにHTTP/2 Server Pushを実装すべき」 実務上は終わっています。Chromeはv106以降デフォルトで無効にし、HTTP/2サイトでの普及率は約0,7 %まで下がりました。開発元のデータでも、性能低下が頻繁に起きていました。代わりに103 Early Hintsまたは<link rel=preload>を使ってください。

アンチパターン：「失われたパケット1つが止めるのは1ファイルだけ」と絶対視する QUICはHTTP/3ストリーム間の損失を分離します。HTTP/2の共有TCP接続とは異なり、一方のストリームで失われたパケットが関係のないストリームを止めることはありません。ただし、同じQUIC接続のストリームは輻輳制御とフロー制御を共有し、QPACKのヘッダー復号は共有制御ストリーム上で動きます。ネットワーク経路が悪ければページ全体は依然として遅くなります。QUICが止めるのは、1つのパケット損失が他のすべてのストリームへ連鎖することです。

アンチパターン：「0-RTTと接続移行は必ず機能する」と考える 0-RTTは再生に注意が必要な「早期データ」を送り、サーバーが拒否してフォールバックできます（425 Too Early）。すべての訪問で必ずゼロラウンドトリップの開始になるわけではありません。QUIC v1の接続移行はクライアントが開始し、経路検証が必要です。サーバーだけで接続を移行することはできず、ネットワーク変更をまたぐ継続性は条件付きで、自動ではありません。

アンチパターン：「GooglebotをオンデマンドでHTTP/2に強制する」 できません。適格性はGoogle自身のクロールヒューリスティクスに基づくGoogleの判断です。自分でできるのは、HTTPS + HTTP/2対応によって適格になることです。421によるオプトアウトは文書化されていますが、オンデマンドでオプトインする方法は文書化されていません。

アンチパターン：「上位サイトの25%がHTTP/3に対応」と「リクエストの7〜9%がHTTP/3を使う」を混同する これは異なるものを測っています。大規模ドメインにおけるサイト単位の対応と、実際に配信されたリクエストのシェアです。両方が真であり得るため、一方が他方を否定するかのように提示しないでください。

アンチパターン：高速接続の閲覧者に対してHTTP/3へ過剰投資する HTTP/3の効果は低速またはパケット損失の多い接続に集中します。ユーザーの大半が高速で安定したネットワークなら、HTTP/2ですでにメリットの大部分を得ています。CDNでHTTP/3を有効にするのは構いませんが、大規模プロジェクトとは考えないでください。

アンチパターン：標準のPageSpeed Insightsで「HTTP/2を使用」の合格表示を探す 古いLighthouse監査は無効化され、現在の「Modern HTTP」インサイトは公開PSIレポートではなくChrome DevToolsのトレースにあります。ブラウザーのNetworkパネル、またはWebPageTestのようなツールでプロトコルを確認してください。

HTTP/2とHTTP/3チェックリスト

神話を追いかけずに配信上のメリットを得られているか、簡単に確認します。

• サイトがHTTPSで配信されている（両プロトコルの前提）。
• HTTP/2が有効であることを確認した — ブラウザーのNetworkパネルのProtocol列、またはWebPageTestで確認する（標準のPSIレポートではない）。
• CDNが対応している場所でHTTP/3を有効にした（低速/モバイルの閲覧者にはより大きな効果）— スイッチを入れただけでなく、実際にネゴシエートされていることを確認する（curl --http3またはNetworkパネルで確認。UDPをブロックするネットワークでは自動的にフォールバックする）。
• 特別な理由がない限り、ゼロからのサーバー移行ではなくCDNのスイッチを使っている。
• 自前ホスティングなら、サーバーソフトウェアのHTTP/2 / HTTP/3対応が最新であることを確認した。
• HTTP/2 Server Pushを実装していない — 必要な場所では103 Early Hintsまたは<link rel=preload>に置き換えている。
• 社内で期待値を設定した。これはUX / Core Web Vitalsの改善であり、直接的なランキング要因ではない。
• GooglebotをHTTP/2から外す必要が生じた場合の仕組み（421ステータスコード）を知っている — ほとんどのサイトでは不要。
• サーバー/CDNにHTTP/2 Rapid Reset（CVE-2023-44487）へのパッチを適用した。

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

私の関連記事

• テクニカルSEO入門 — サイト速度と配信が、より大きなテクニカルSEOの全体像のどこに位置付くかを説明します。
• Core Web Vitals完全ガイド — 速い配信をランキングに近いシグナルへ実際に変える指標と、HTTP/2およびHTTP/3の間接的な効果を説明します。

私の講演

• How Search Works （SlideShare）— Googlebotがページを取得する仕組みを含め、クロール、レンダリング、インデックス登録、ランキングについて説明します。（私の継続的な免責事項：「これはシステムについての私の理解です……100%完全または正確ではありません」）

公式

• Google — Googleクローラーとフェッチャーの概要 — 「ランキング向上なし」の説明、HTTP/1.1のデフォルト、421によるオプトアウト。
• Google — Googlebot will soon speak HTTP/2 (翻訳) 「GooglebotがまもなくHTTP/2を話すようになります」 （2020年9月）。
• Chrome — HTTP/2 Server Pushの削除 （Barry Pollard）。

業界の資料

• Web Almanac 2024 — HTTP章 （Robin Marx、Akamai。Barry PollardとChris Böttgerがレビュー）— HTTP/2が優勢でHTTP/3はまだ少数派であること、そしてCDNの大きな効果を示す実際の普及データです。
• “How HTTP/3 Helps Feed SEO’s Need For Speed” (翻訳) 「HTTP/3がSEOのスピード需要を満たす仕組み」 （Search Engine Journal、Will Nye、Builtvisible）— Core Web Vitalsへの間接的な効果と、HTTP/3のメリットが低速接続に集中する理由を実務的に説明します。
• “Google: Googlebot Not Crawling Over HTTP/3 Yet” (翻訳) 「Google：GooglebotはまだHTTP/3でクロールしていない」 （Search Engine Roundtable、Barry Schwartz）— GooglebotがHTTP/3をクロールしていないことを裏付けます。
• “Google: We’re Crawling Half Of The URLs Over HTTP/2” (翻訳) 「Google：URLの半数をHTTP/2でクロールしている」 （Search Engine Roundtable、Barry Schwartz）— Google I/OでのJohn MuellerによるHTTP/2クロール統計です。
• “HTTP/2 Rapid Reset: deconstructing the record-breaking attack” (翻訳) 「HTTP/2 Rapid Reset：記録的な攻撃を分解する」 （Cloudflare、Lucas PardueとJulien Desgats）— CVE-2023-44487のセキュリティ上の注意点と技術解説です。
• “High Performance Browser Networking” (翻訳) 「ハイパフォーマンス・ブラウザネットワーキング」 （Ilya Grigorik、O’Reilly）— HTTP/2、QUIC、基盤となるネットワークについての無料の詳細な資料です。

ネゴシエートされたHTTPバージョンを確認する

curlのプロトコル別フラグを使って、エンドポイントが各プロトコルをネゴシエートできるか確認します。ローカルのcurlビルドによって、対応するプロトコルは異なる場合があります。

curl -sS -o /dev/null -w 'HTTP/%{http_version}\n' --http2 https://example.com/
curl -sS -o /dev/null -w 'HTTP/%{http_version}\n' --http3 https://example.com/

ブラウザーのリソースプロトコルを調べる

ページの読み込み後にDevTools Consoleへ貼り付けると、各リクエストに記録されたプロトコルを確認できます。

console.table(
  performance.getEntriesByType('resource').map((entry) => ({
    resource: entry.name,
    protocol: entry.nextHopProtocol,
    duration: Math.round(entry.duration),
  }))
);

HTTP/3の結果はブラウザーへの配信を証明するものであり、Googlebotのクロールを証明するものではありません。この記事のGooglebotに関する説明は別のものです。

HTTP/2とHTTP/3をテストする

プロトコルとSEOにとっての意味について、5つの簡単な質問です。それぞれ回答を選んでから、確認してください。

変更履歴