Dynamic serving（動的配信）

要点 — Dynamic serving（動的配信）は、ウェブサイトが1つのURLを使いながら、スマートフォンとデスクトップへ異なるHTMLを返す方式です。サーバーが端末を判定して別のページを配信します。利用はできますが、誤設定しやすいため、Googleは画面幅に合わせて1つのページを組み替えるレスポンシブデザインを推奨しています。動的配信を使う場合は、キャッシュが別端末向けの版を返さないよう、サーバーがVary: User-Agentヘッダーを送信する必要があります。

Dynamic servingとは

モバイル訪問者へ対応する構成は3種類あります。

1. レスポンシブデザイン — 1ページ、1組のHTMLを使い、画面に合わせてレイアウトを組み替えます。Googleの推奨方式です。
2. Dynamic serving — URLは1つですが、サーバーがスマートフォンとデスクトップへ異なるHTMLを返します。同じURLの内側でページが変わります。
3. 別URL — m.example.comのように、モバイルサイトを別のURLで運用します。

Dynamic servingは中間の方式です。ブラウザーがページを要求すると、ユーザーエージェントを通じてスマートフォン、タブレット、デスクトップのどれかをサーバーへ伝えます。サーバーはその情報を読み、返すページの版を選びます。そのため、同じURLを入力しても、スマートフォンとノートパソコンで実際に異なるHTMLを受け取る場合があります。

Vary: User-Agentヘッダー

問題は、端末によってページが変わってもURLは変わらないことです。ブラウザー、CDN、ISPなどのキャッシュがデスクトップ版を保存し、次のモバイル利用者へ誤って返す可能性があります。これを防ぐため、サーバーは各レスポンスで**Vary: User-Agent**を送ります。これは「このページの内容は端末に応じて変わるので、異なる端末間で同じキャッシュを再利用しない」という通知です。ヘッダーがなければ、利用者やGoogleが誤った版を見るおそれがあります。

Googleが推奨しない理由

Dynamic servingでは、サーバーがユーザーエージェントから端末を正しく推測し続ける必要があります。新しい端末が登場し、タブレットをスマートフォンと誤認し、デスクトップ版とモバイル版の内容が静かにずれることもあります。するとGoogleが壊れた版や誤った版を見る可能性があります。Googleがレスポンシブデザインを勧める理由は単純で、管理する版が1つなら同期ずれが起きないからです。

よくある誤解

Dynamic servingと「dynamic rendering」を混同しないでください。 どちらもサーバーがユーザーエージェントを確認するため名称は似ていますが、解決する問題が異なります。Dynamic servingはスマートフォンとデスクトップへ異なるHTMLを返す方式です。Dynamic renderingはJavaScript依存ページの事前レンダリング版を検索エンジンのボットへ返す方式です。別の概念で、Googleの資料も別です。詳細はAdvancedタブで説明します。

2026年のDynamic servingは、新規構築で推奨される方式ではなく、古いサイトや大規模な企業サイトから引き継いで監査することが中心です。Varyヘッダーの2つの役割、見落とされがちなCDNコスト、クローキングとの関係、利用状況の確認方法はAdvancedタブで説明します。

要点 — Dynamic servingは、同じURLからユーザーエージェント別に異なるHTML/CSSを返すサーバー側の方式で、レスポンスの**Vary: User-Agentヘッダーで通知します。モバイル構成には、Google推奨のレスポンシブデザイン**、Dynamic serving、別URL（m-dot）の3種類があります。Varyには、(1) キャッシュが別端末向けの版を返すのを防ぐ、(2) 歴史的にはGooglebotによるモバイル版の発見を助ける、という2つの役割があります。一方、Vary: User-AgentはUA文字列ごとにCDNキャッシュキーを分断し、オリジン負荷を増やします。古いUA一覧やタブレットの誤判定など、端末判定は失敗しやすく、判定不良やVary欠落によってGoogleが誤った版を見ることがクローキング上の実害につながります。クローラー向けにJavaScriptページを事前レンダリングするdynamic renderingとは別の概念です。2026年には新規採用ではなく、既存構成からの移行を検討するレガシーパターンです。

Dynamic servingの正確な定義

Googleのモバイルファーストインデックスのベストプラクティスでは、次のように定義されています。“Dynamic serving: Uses the same URL regardless of device. This configuration relies on user-agent sniffing and the Vary: user-agent HTTP response header to serve a different version of the HTML to different devices.” (翻訳) 「Dynamic servingは端末にかかわらず同じURLを使い、ユーザーエージェント判定とVary: user-agent HTTPレスポンスヘッダーによって、端末ごとに異なるHTMLを配信する構成です。」廃止済みの専用ページでは、さらに具体的に、“a setup where the server responds with different HTML (and CSS) on the same URL depending on which user agent requests the page (mobile, tablet, or desktop).” (翻訳) 「ページを要求するユーザーエージェント（モバイル、タブレット、デスクトップ）に応じて、同じURLから異なるHTML（およびCSS）を返す構成」と説明されていました。

3種類のモバイル構成を比較すると、違いが明確になります。

3方式のうち2つはVaryヘッダーに依存します。Googleは別URLについても、“like dynamic serving, this configuration relies on the user-agent and Vary HTTP headers.” (翻訳) 「Dynamic servingと同様に、ユーザーエージェントとVary HTTPヘッダーに依存する」と明記しています。同期ずれの要因がないのはレスポンシブデザインだけであり、Googleが推奨する理由もそこにあります。詳しくはレスポンシブデザインとモバイルSEOを参照してください。

仕組み：ユーザーエージェント判定とVaryヘッダー

サーバーは各クライアントが送る識別子であるユーザーエージェント文字列を調べ、モバイル、タブレット、デスクトップのどれかを判定して対応するHTMLを返します。URLは全員で共通なので、レスポンスがユーザーエージェントによって変わることも通知しなければなりません。それがVary: User-Agentヘッダーです。Googleのアーカイブ資料は、このヘッダーに異なる2つの役割があると説明しています。

“It signals to caching servers used in ISPs and elsewhere that they should consider the user agent when deciding whether to serve the page from cache or not. Without the Vary HTTP header, a cache may mistakenly serve mobile users the cache of the desktop HTML page or vice versa. It helps Googlebot discover your mobile-optimized content faster, as a valid Vary HTTP header is one of the signals we may use to crawl URLs that serve mobile-optimized content.” (翻訳) 「ISPなどのキャッシュサーバーへUAを考慮するよう通知し、モバイルとデスクトップのキャッシュ取り違えを防ぐ。有効なVary HTTPヘッダーはGooglebotによるモバイル最適化コンテンツの発見も早める。」

役割1は検索エンジンと独立したUX・正確性の問題であるキャッシュの正しさ、役割2はクロール時の発見です。競合する多くの用語解説は前者だけを扱うか、両者を混同しています。実際のHTTPレスポンスは次のようになります。

HTTP/1.1 200 OK
Content-Type: text/html
Vary: User-Agent
Content-Length: 5710

サーバーがAccept-Encodingなど別の目的ですでにVaryヘッダーを送っている場合は、置き換えずにUser-Agentを一覧へ追加します。

Vary自体は通常のHTTPキャッシュ機構であり、SEO固有の仕組みではありません。適切な版を保存するため、キャッシュキーへ含めるリクエストヘッダーをキャッシュへ伝えます。端末判定やSEOの理解は行わず、端末判定はサーバー側のUAロジックが別に担います。前述のクロール発見での利用は、Googleが監視するシグナルとして説明したもので、すべてのキャッシュが同じ方法で従うプロトコル要件ではありません。304 Not Modifiedや既定・フォールバックのレスポンスを含め、同じURLでは一貫して送信しないと、保存対象のメタデータがキャッシュ内で不整合になります。

多くのガイドが見落とすコスト：CDNキャッシュの分断

Vary: User-Agentは無償ではなく、キャッシュを分断します。キャッシュキーの一部にVary指定ヘッダーが使われるため、サイトへ来たブラウザー版、OSビルド、ボットなど、異なるユーザーエージェント文字列ごとに別のキャッシュコピーが作られます。実際の表示版が2～3種類でも、文字列は数千種類に増え得ます。ただし再利用率の低下はCDN独自のキャッシュキー処理に左右されます。似たUAを正規化・分類するCDNもあるため、普遍的なヒット率低下を示す単一の数値はありません。SiteGroundを含む具体的な倍率は、利用中の構成を保証する値ではなく、1ベンダーの推定として扱ってください。

SiteGroundは実務上のコストを、“With the User-Agent [header] enabled, the system will keep different copies for each combination of OS and browser version visiting your site… you will have 5-30 dynamic requests for the same 100 visits. So the very same site will use 5-30 times the resources.” (翻訳) 「User-Agentヘッダーを有効にすると、OSとブラウザー版の組み合わせごとにコピーを保持する。同じ100訪問でも5～30件の動的リクエストとなり、同じサイトが5～30倍のリソースを使う」と説明しています。クローラーについても、“If such [a] bot starts crawling your site and you have the Vary: User-Agent header, each request it makes to your site would be a dynamic one and will eat up your resources.” (翻訳) 「そのようなボットがクロールを始め、Vary: User-Agentがあると、各リクエストが動的処理となりリソースを消費する」としています。

問題は新しくありません。2013年にCindy KrumはSearch Engine Landで、企業向けCDNがこのヘッダーを、コンテンツは*“cannot be cached or served from the CDN and must be fetched directly from your server”* (翻訳) 「キャッシュもCDN配信もできず、サーバーから直接取得する必要がある」というシグナルとして扱い、動的配信ページでは*“rendering your CDN completely useless”* (翻訳) 「CDNを完全に無用にする」可能性があると警告しました。2013年当時のベンダー挙動は変化しましたが、Vary: User-Agentがキャッシュキーを分断するという技術的な緊張は残り、SEO以外でもDynamic servingが廃れた主因です。SiteGroundも、“most of the sites don’t actually serve different HTML for their mobile versions. It’s the responsive CSS that does all the heavy lifting” (翻訳) 「多くのサイトはモバイル版へ異なるHTMLを配信せず、レスポンシブCSSが主要処理を担う」と指摘しています。実際にはレスポンシブなのにVary: User-Agentだけが残る誤設定も少なくありません。

Dynamic servingはクローキングか

本質的にはクローキングではありません。問題は技法ではなく、結果と意図です。端末を検出して端末に適した内容を返すこと自体は問題ありません。危険なのは、(a) 判定不良やVary欠落によってGooglebotへ壊れた版・誤った版を返すこと、または(b) 検索エンジンへ利用者とは実質的に異なる内容を意図的に返すことです。Googleのアーカイブ資料も明確に警告しています。

“Be very careful of cloaking when detecting user agents… it should not be looking specifically for Googlebot. All Googlebot user agents identify themselves as specific mobile devices, and you should treat these Googlebot user agents exactly like you would treat these devices.” (翻訳) 「UAを検出するときはクローキングに注意し、Googlebotだけを特別に探してはならない。Googlebot UAは特定のモバイル端末として識別されるため、その端末と同じように扱うべきである。」

関連するJavaScriptレンダリングについては、現在も公開されているGoogleのdynamic rendering資料 が一般原則を示しています。“As long as your dynamic rendering produces similar content, Googlebot won’t view dynamic rendering as cloaking,” (翻訳) 「動的レンダリングが同様の内容を生成する限りGooglebotはクローキングと見なさない」一方、“serving completely different content to users and crawlers can be considered cloaking.” (翻訳) 「利用者とクローラーへ完全に異なる内容を返すことはクローキングと見なされ得る」としています。Dynamic servingも同じで、端末ごとに実質同一の内容を返すのは問題ありません。クローキングに見える誤設定が本当の危険です。

Dynamic servingとdynamic renderingを混同しない

競合記事で最も明確に誤られやすい点なので、違いをはっきり分けます。

• Dynamic serving = 端末による差分。同じURLからモバイルとデスクトップへ異なるHTMLを返します。本稿の対象で、Googleの案内はモバイルファーストインデックス資料へ統合されました。
• Dynamic rendering = ボット向けのJavaScriptレンダリング差分。JavaScript依存ページの事前レンダリング／サーバーレンダリング版をクローラーへ返し、利用者にはクライアントレンダリング版を返します。Googleには現在も専用資料があり、Bingも2018年のbingbot記事 で、“Dynamic rendering is about detecting user agent and rendering content differently for humans and search engine crawlers” (翻訳) 「Dynamic renderingはUAを検出し、人と検索エンジンのクローラーへ異なる方法で内容をレンダリングすること」と説明しています。これはbingbot向けJSレンダリングであり、端末別配信ではありません。

どちらもユーザーエージェント判定を使い、クローキングの論点があるため混同されますが、問題も資料も異なります。

ユーザーエージェント判定が失敗しやすい理由

Googleのアーカイブ資料が挙げた典型的な失敗は今も当てはまります。UA一覧は継続的な保守が必要で、新しいUAには対応できません。“sometimes detecting a desktop user agent as a mobile one or detecting a mobile user agent as a desktop” (翻訳) 「デスクトップUAをモバイル、またはモバイルUAをデスクトップと誤判定する」ことがあり、“a common mistake for sites is to inadvertently treat tablet devices as smartphones.” (翻訳) 「タブレットを誤ってスマートフォンとして扱う」のも典型例です。Googleの要約、“Use the Vary HTTP header to signal your changes depending on the user agent. Detect user agent strings correctly.” (翻訳) 「UAによる変更はVary HTTPヘッダーで通知し、UA文字列を正しく検出する」は簡潔ですが、この2文が保守負担の全体です。

Googleは10年以上この誤りへ対応してきました。2015年1月にはGoogleのPierre Farが、Varyヘッダーだけでなく、端末間でJavaScript、CSS、画像の版を正しく処理できない問題を主要な実装ミスとして挙げています。「ヘッダーを追加する」だけで十分だったことはありません。

レスポンシブデザインが標準になった理由

2つの要因がDynamic servingをレガシーパターンにしました。第1に、Googleは少なくとも2015年から、レスポンシブデザインを*“because it’s the easiest design pattern to implement and maintain”* (翻訳) 「実装と保守が最も容易な設計パターンだから」と推奨しています。版は1つで、端末判定の危険がありません。第2に、モバイルファーストインデックスが2023～2024年に完了し、誤配信の影響が大きくなりました。Googleが主にクロール、インデックス登録、順位付けするのはモバイル版なので、誤設定は単に悪いモバイルページを返すのではなく、主要なインデックス対象を誤って返します。別のm-dot URLと同様、1つのレスポンシブURLへ統合すれば、この問題群をまとめて取り除けます。

コンテンツ同等性、モバイルのCore Web Vitals、ユーザビリティ、インタースティシャル、AMPを含む全体像は、モバイルSEOとモバイルSEOチェックリストを参照してください。

Dynamic servingを確認する方法

手早い確認方法は、異なるユーザーエージェント文字列で同じURLを2回要求し、比較することです。HTMLが異なり、レスポンスにVary: User-AgentがあればDynamic servingです。HTMLが同一でCSSにより組み替わるだけならレスポンシブです。Scriptsタブにはcurl、DevTools、ブックマークレットの手順があります。端末ごとにHTMLが異なるのにVaryがない場合は、キャッシュとクローラーが誤った版を見るおそれがある誤設定です。

AI要約

Advanced版の要点です。

• Dynamic servingは同じURLからユーザーエージェント別に異なるHTML/CSSを返す方式で、サーバー側で判定し、**Vary: User-Agent**レスポンスヘッダーで通知します。
• 3つのモバイル構成： レスポンシブデザイン（同じURL・HTMLとCSSメディアクエリで、Google推奨）、Dynamic serving（同じURL・異なるHTML）、別URL／m-dot（異なるURL・HTML）。後者2つはVaryに依存します。
• Vary: User-Agentの2つの役割： (1) ブラウザー、CDN、ISPのキャッシュによる端末版の取り違えを防ぐ、(2) 歴史的にはGooglebotによるモバイル版の発見を助ける。競合記事は前者だけを扱いがちです。
• 実コスト： Vary: User-Agentはブラウザー、OS、ボットのUA文字列ごとにCDNキャッシュキーを分断し、オリジン要求を増やします。SiteGroundの推定は5～30倍です。移行が進んだ一因です。
• クローキングの危険は技法ではなく結果です。 端末向け内容の配信は問題ありません。判定不良やVary欠落でGooglebotへ誤った版を返すこと、クローラーだけへ別内容を返すことが危険です。「Googlebot」を特別扱いせず、申告された端末として扱います。
• UA判定は誤りやすい： 古いUA一覧、デスクトップとモバイルの取り違え、タブレットのスマートフォン扱いがあります。
• Dynamic renderingとは別物： 後者はボット向けのJS事前レンダリングで、Google／Bingの資料も別です。
• 2026年にはレガシーパターンです。 Googleは約2015年からレスポンシブを推奨し、2023～2024年に完了したモバイルファーストインデックスで誤設定の影響が増しました。既存の企業サイトから移行する対象です。
• 検出方法： デスクトップとモバイルのUAで同じURLを要求し、HTMLとVary: User-Agentヘッダーを比較します。

公式資料

検索エンジンの一次資料です。

Google

• モバイルファーストインデックスのベストプラクティス — Dynamic servingと別URLの定義が移された現行資料で、レスポンシブデザインの推奨も示します。
• Dynamic Serving（旧専用資料のアーカイブ） — 2021年1月更新の廃止済み詳細資料です。Varyの2つの役割とUA判定の失敗例の出典です。現行URLは301で前項へ転送され、詳細の多くは省かれています。
• 回避策としてのDynamic Rendering — 関連はあるものの別のJSレンダリング概念で、「内容が同様ならクローキングではない」という説明があります。違いを示すためだけに引用します。
• ウェブ全体へのモバイルファーストインデックス導入告知（2020年3月） — 端末別配信が現在さらに重要な理由の背景です。

Bing／Microsoft

• bingbotシリーズ：JavaScript、Dynamic Rendering、クローキング（2018年10月） — 端末別Dynamic servingではなく、ボット向けJSのdynamic renderingに関する案内です。BingにはGoogleの旧資料に相当する端末別Dynamic serving／Vary専用資料は見当たらず、概してレスポンシブ／単一URL構成を支持しています。

出典からの引用

Googleと業界関係者による記録上の発言です。Googleの現行資料は引用箇所へ移動するディープリンクで、アーカイブや二次資料はその旨を明記します。

Google — 定義と推奨 (現行資料)

• “Dynamic serving: Uses the same URL regardless of device. This configuration relies on user-agent sniffing and the Vary: user-agent HTTP response header to serve a different version of the HTML to different devices.” (翻訳) 「Dynamic servingは端末にかかわらず同じURLを使い、UA判定とVary: user-agent HTTPレスポンスヘッダーによって端末別のHTMLを返します。」 — Google Search Central資料。 引用箇所へ移動
• “Separate URLs: Serves different HTML to each device, and on separate URLs. Like dynamic serving, this configuration relies on the user-agent and Vary HTTP headers to redirect users to the device-appropriate version of the site.” (翻訳) 「別URLは端末ごとに別のURLとHTMLを使い、Dynamic servingと同様にUAとVary HTTPヘッダーへ依存して適切な版へ転送します。」 引用箇所へ移動
• “Google recommends Responsive Web Design because it’s the easiest design pattern to implement and maintain.” (翻訳) 「実装と保守が最も容易な設計パターンであるため、GoogleはレスポンシブWebデザインを推奨します。」 引用箇所へ移動

Google — Varyヘッダーの2つの役割 (旧専用資料、最終更新2021年1月)

• “The Vary HTTP header has two important and useful implications: It signals to caching servers used in ISPs and elsewhere that they should consider the user agent when deciding whether to serve the page from cache or not. Without the Vary HTTP header, a cache may mistakenly serve mobile users the cache of the desktop HTML page or vice versa. It helps Googlebot discover your mobile-optimized content faster.” (翻訳) 「Vary HTTPヘッダーは、キャッシュ利用時にUAを考慮するよう通知し、端末版の取り違えを防ぐ。またGooglebotによるモバイル最適化コンテンツの発見を早める。」 — Google Search Central、Dynamic Serving（アーカイブ）。
• “Be very careful of cloaking when detecting user agents… it should not be looking specifically for Googlebot. All Googlebot user agents identify themselves as specific mobile devices, and you should treat these Googlebot user agents exactly like you would treat these devices.” (翻訳) 「UA検出時はクローキングに注意し、Googlebotだけを特別扱いしない。Googlebot UAが示す端末と同じように扱う。」 — Google Search Central、Dynamic Serving（アーカイブ）。

Google — 別概念のdynamic rendering (現行資料)

• “As long as your dynamic rendering produces similar content, Googlebot won’t view dynamic rendering as cloaking.” (翻訳) 「Dynamic renderingが同様の内容を生成する限り、Googlebotはクローキングと見なしません。」 引用箇所へ移動

SiteGround — Vary: User-AgentのCDNコスト (業界資料)

• “With the User-Agent [header] enabled, the system will keep different copies for each combination of OS and browser version visiting your site… you will have 5-30 dynamic requests for the same 100 visits. So the very same site will use 5-30 times the resources.” (翻訳) 「User-Agentヘッダーを有効にするとOSとブラウザー版ごとにコピーを保持し、同じ100訪問で5～30件の動的要求、5～30倍のリソースを使う。」 — SiteGround「Vary HTTPヘッダーが問題になる理由」

どのモバイル構成を使うべきか

ほぼすべてのケースでレスポンシブデザインが結論になります。この判断ツリーでは、Dynamic servingや別URLを検討する例外と、既存構成を引き継いだ場合の対応も扱います。

要点は、ほぼすべてのケースでレスポンシブが答えということです。Dynamic servingとm-dotは、既存サイトで減らしていく対象であり、新規採用する方式ではありません。

Dynamic serving監査チェックリスト

• 代表的なデスクトップとモバイルのUAで同じURLを要求し、意図的にHTMLが異なるか確認する。
• 端末クラスで表現が変わるすべてのレスポンスで、該当するキャッシュ済み・エラーレスポンスを含めVary: User-Agentを送る。
• 主本文、見出し、内部リンク、画像とalt、メタデータ、robotsディレクティブ、構造化データを版間で同等にする。
• Googlebot Smartphoneが通常のモバイルブラウザーと同じ版を受け取ることを確認し、クローラーを特別扱いしない。
• CDNキャッシュキーとヒット挙動を確認し、ある端末クラスへ別クラスのキャッシュ文書を返さないようにする。
• オリジンへの単発要求だけでなく、CDN／キャッシュエッジを通じてデスクトップ、モバイル、タブレット、ボットの要求を数回繰り返す。キャッシュ汚染は版のウォームアップ後に初めて現れる。
• タブレット、未知のUA、UAヘッダー欠落をフォールバック試験へ含める。
• サイトが完全にレスポンシブ化し、レスポンスが変わらなくなったらVary: User-Agentを削除する。
• Dynamic servingが要件ではなくレガシーなら、レスポンシブへの移行経路を文書化する。

Dynamic serving早見表

定義： 同じURLからUA別に異なるHTML/CSSを返し、Vary: User-Agentで通知する方式。

3つのモバイル構成

Vary: User-Agentヘッダーの2つの役割

1. キャッシュの正しさ — ブラウザー／CDN／ISPが別端末向けのキャッシュを返すのを防ぐ。
2. クロール時の発見 — 歴史的にはGooglebotによるモバイル版の発見を助けた。

レスポンス例

HTTP/1.1 200 OK
Vary: User-Agent

隠れたコスト

• Vary: User-Agentはブラウザー／OS／ボットの各UA文字列でCDNキャッシュキーを分断する。
• SiteGroundの推定：同じトラフィックでオリジン要求が5～30倍。
• 端末間でHTMLが同一なら、ヘッダーは残存する誤設定なので削除する。

クローキングの規則

• 端末に適した内容の配信は問題ない。
• 判定不良／Vary欠落でGooglebotへ誤った版を返すことが本当の危険。
• 判定で**「Googlebot」を特別扱いせず**、申告された端末として扱う。

典型的な判定ミス

• 古いUA文字列一覧で新端末を見落とす。
• デスクトップをモバイル、またはその逆に誤認する。
• タブレットをスマートフォンとして扱う。

混同しないこと： dynamic renderingはボット向けのJS事前レンダリングで、概念も資料も異なります。

2026年の実情： レガシーパターンです。Googleは約2015年からレスポンシブを推奨し、2023～2024年に完了したモバイルファーストインデックスで誤設定の影響が増しました。新規採用せず、既存構成から移行します。

任意のURLでDynamic servingを検出する

中心となる試験は、デスクトップとモバイルのUAで同じURLを要求し、HTMLを比較してVary: User-Agentヘッダーを確認することです。HTMLが異なればDynamic serving（URLも変わればm-dot）です。レスポンスが変わるのにVaryがなければ、指摘すべき誤設定です。

curl — デスクトップとモバイルのレスポンス比較（macOS／Linux）

URL="https://example.com/"
DESKTOP="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0 Safari/537.36"
MOBILE="Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0 Mobile Safari/537.36"

# Fetch both, hash the body — different hashes = different HTML per device
curl -sA "$DESKTOP" "$URL" | shasum
curl -sA "$MOBILE"  "$URL" | shasum

# Is the site even sending Vary: User-Agent? (headers only)
curl -sI "$URL" | grep -i '^vary:'

curl — Googlebot Smartphoneを再現し、クローラーが受け取る内容を確認

GBOT="Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
curl -sA "$GBOT" "https://example.com/" | shasum
# Compare to the $MOBILE hash above — they should match. If Googlebot gets the
# desktop version, that's the misconfiguration that can look like cloaking.

Windows（PowerShell）— 同じ比較

$Url = "https://example.com/"
$Desktop = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0 Safari/537.36"
$Mobile  = "Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0 Mobile Safari/537.36"

(Invoke-WebRequest $Url -UserAgent $Desktop).RawContentLength
(Invoke-WebRequest $Url -UserAgent $Mobile ).RawContentLength
(Invoke-WebRequest $Url -Method Head).Headers["Vary"]

Chrome DevTools — ターミナル不要

1. DevTools（F12／Cmd+Opt+I）を開き、Network conditionsタブ（⋮ → More tools → Network conditions）を開く。
2. 「Use browser default」を解除し、モバイルUAを選ぶ（またはGooglebot Smartphone文字列を貼る）。再読み込みして表示ページを比較し、Networkパネルの文書リクエストのResponse HeadersでVaryを確認する。
3. デスクトップUAへ戻して再読み込みする。同じURLでHTMLが異なれば判別できる。

ブラウザーコンソール — 現在のページのVaryヘッダーを確認

// Paste in the DevTools Console on the page you're testing
fetch(location.href, { method: "HEAD", cache: "no-store" })
  .then(r => console.log("Vary:", r.headers.get("vary") || "(none)"));

ブックマークレット — ワンクリックVary確認

javascript:(async()=>{const r=await fetch(location.href,{method:"HEAD",cache:"no-store"});alert("Vary: "+(r.headers.get("vary")||"(none set)"));})();

注：fetchで取得できるクロスオリジンのレスポンスヘッダーは、サーバーがCORSで許可したものに限られます。コンソール／ブックマークレットは閲覧中と同じオリジンで最も確実です。最終確認にはcurl -IまたはDevToolsのNetworkパネルを使います。

端末依存レスポンスを監査するツール

• curl： デスクトップ、モバイル、Googlebot SmartphoneのUAを明示して同じ要求を繰り返し、ヘッダー、ステータス、本文サイズ、コンテンツハッシュを比較します。
• Chrome DevTools Networkパネル： UAを上書きしてキャッシュを無効化し、端末エミュレーションだけで変わると仮定せず、実際の文書レスポンスを調べます。
• Search Console URL検査： 代表URLでGooglebot Smartphoneが受け取ったレンダリング済みHTMLを確認します。
• UA設定可能なクローラー： モバイルとデスクトップを別々にクロールし、タイトル、見出し、canonical、ディレクティブ、構造化データ、内部リンクを大規模に比較します。
• CDNキャッシュ分析： 端末クラス別にヒット、ミス、キャッシュキーを分け、キャッシュ分断や端末間の漏れを見つけます。

Dynamic servingのアンチパターン

Dynamic servingを「動作する」状態から「積極的に害を与える」状態へ変える失敗例です。

1. Vary: User-Agentヘッダーなしで異なるHTMLを返す。 最も重大な誤りです。キャッシュがデスクトップ版を保存してスマートフォンへ返す、またはGooglebot Smartphoneへデスクトップ版を返す可能性があります。内容が変わることをキャッシュやクローラーへ伝えられません。端末別HTMLを返すなら、このヘッダーは必須です。

2. 実際はレスポンシブなサイトへVary: User-Agentを追加する。 逆方向の典型的な誤りです。端末間でHTMLが同一なら役に立たず、UA文字列ごとにCDNキャッシュを分断します（SiteGround推定で要求5～30倍）。念のため追加するのではなく、端末別に本当に異なるHTMLを返す場合だけ使います。

3. 判定ロジックで「Googlebot」を特別扱いする。 端末クラスの判定は問題ありませんが、Googlebotだけを検出して別内容を返すと意図しないクローキングになります。Googlebotは特定のモバイル端末として自己申告するため、その端末と同じように扱います。

4. デスクトップとモバイルのHTML同等性を崩す。 2つの版は2つの同期対象です。モバイルファーストインデックスではモバイル版がインデックス対象なので、デスクトップだけにある本文、構造化データ、画像／alt、リンクはインデックス上存在しないのと同じです。

5. 古いUA一覧とタブレットのスマートフォン誤認。 UA判定一覧は劣化します。新端末を認識できず、デスクトップとモバイルを取り違え、タブレットをスマートフォンとして扱います。一度設定して見直さない判定は、時間とともに多くのトラフィックを誤分類します。

6. Dynamic servingを新規に選ぶ「選択肢」と考える。 2026年に3方式は同格ではありません。Googleは約2015年からレスポンシブを推奨し、モバイルファーストインデックスで誤設定の影響も増えました。新規ならレスポンシブを選び、Dynamic servingは減らすべきレガシー負債として扱います。

7. Dynamic renderingと混同する。 JS事前レンダリング資料やBingのbingbot記事を端末別配信の設定に使う誤りです。問題も解決策も異なり、混ぜるとどちらにも適合しない案内になります。

Dynamic servingのよくある障害

モバイル利用者へ断続的にデスクトップ版が返る

症状： キャッシュ前は正しいモバイルレスポンスですが、キャッシュヒット後にデスクトップHTMLが現れます。主な原因： UAでレスポンスが変わるのに、対応するキャッシュキーまたはVary: User-Agentがありません。修正： オリジンヘッダーとCDN構成を直し、対象オブジェクトをパージして、ウォーム済みキャッシュへ端末横断要求を繰り返します。

Googlebot Smartphoneが少ない内容しか見ない

症状： URL検査に、デスクトップにはある本文、リンク、構造化データ、画像がありません。主な原因： モバイルテンプレートのずれ、または端末判定によるGooglebotの誤経路です。修正： 共通コンテンツソースから同等性を戻し、正確なスマートフォンクローラーUAと通常のスマートフォンUAを並べて試験します。

レスポンシブサイトのキャッシュ効率が悪い

症状： 端末間でHTMLは同一なのに、CDNが多数のUA版を保存します。主な原因： レスポンシブ移行後も古いVary: User-Agentが残っています。修正： レスポンスが変わらないことを確認してヘッダーを削除し、各版をパージしてキャッシュ統合を確認します。

Dynamic servingの変更を検証する

表現とヘッダーの一致を試験する

試験： デスクトップとモバイルのUAで同じURLを要求し、本文ハッシュとVaryヘッダーを記録します。期待結果： 意図的に本文が異なる場合は両方がVary: User-Agentを宣言し、同一のレスポンシブ本文には不要な端末差分がありません。失敗の意味： キャッシュ通知とオリジン挙動が不一致です。監視期間： 即時。ロールバック条件： 異なる本文が同じ非分岐キャッシュオブジェクトを共有できる状態です。

ウォーム済みキャッシュの分離を試験する

試験： 一方の端末クラスでURLをウォームアップし、両方の順序でもう一方から要求します。期待結果： 毎回それぞれの対象版を受け取ります。失敗の意味： CDNキャッシュキーが端末差分を無視しています。監視期間： CDNまたはヘッダー変更直後。ロールバック条件： モバイル要求がデスクトップHTMLを受け取る、またはその逆です。

モバイルのコンテンツ同等性を試験する

試験： デスクトップとモバイルのレンダリング結果から標本を取り、主本文、メタデータ、ディレクティブ、リンク、構造化データを比較します。期待結果： レイアウトは異なっても、インデックス可能な意味とシグナルは同等です。失敗の意味： テンプレートのずれがモバイルファーストインデックスで利用できる情報を変えています。監視期間： リリース時と、再クロール後のURL検査。ロールバック条件： モバイル版がインデックス可能な要素を落とす、または制限ディレクティブを追加します。

理解度確認：Dynamic Serving

Dynamic servingとVaryヘッダーに関する5問です。各問の答えを選んで確認してください。

参照する価値のある資料

関連する自分の記事

• The Beginner’s Guide to Technical SEO — モバイル構成とクロール／インデックス登録を技術SEO全体の中で説明します。
• JavaScript SEO Issues & Best Practices — Dynamic servingと混同されるdynamic rendering、つまり端末別配信ではなくボット向けJSの概念に関連します。

自分の講演

• How Search Works (SlideShare) — Googlebotがスマートフォンとしてクロールする点を含め、クロール、レンダリング、インデックス登録、順位付けを説明します。これがモバイルファーストインデックスで端末別配信の誤設定が問題になる理由です。（恒常的な免責：“This is my understanding of systems… not going to be 100% complete or accurate.” (翻訳) 「これは私のシステム理解であり、100%完全または正確とは限りません。」）

業界の資料

• モバイルファーストインデックスのベストプラクティス (Google) — Dynamic serving、別URLの定義とレスポンシブ推奨の現行資料。
• Dynamic Serving（Google旧資料のアーカイブ） (Google、Wayback Machine経由) — Varyの2役とUA判定失敗を説明する廃止済みの詳細資料。
• 回避策としてのDynamic rendering (Google) — 「同様の内容ならクローキングではない」と説明する別のJSレンダリング概念。
• モバイルサイト構成とVary HTTPヘッダー (Search Engine Land、Cindy Krum、2013年) — 企業CDNとVaryの衝突。古いもののキャッシュ分断の緊張は今も残ります。
• Vary HTTPヘッダーが問題になる理由 (SiteGround) — Vary: User-Agentによるキャッシュ分断と5～30倍のリソース推定を平易に説明します。
• GoogleがDynamic servingのモバイルサイトで確認した3つの主要問題 (Search Engine Roundtable、2015年) — Pierre Farが示したJS／CSS／画像の実装ミスで、Googleもこの問題に対応していた初期記録です。

変更履歴