エッジA/BテストSEO（CDNでの分割テスト）

要点 — エッジA/Bテストは、自社serverやbrowser内ではなく、サイトの前段にあるCDNでsplit testを実行する方法です。エッジの小さなscriptが、ページが訪問者へ届く前にどの版を返すか決めます。SEOにとっては、JavaScriptによる差し替えではなく実際のHTMLをGoogleが見られる点が利点です。重要なのは一貫性です。Googleへユーザーと異なる版を見せず、テストを永久に残さないでください。テストは問題ありませんが、Googleと人に違う内容を見せる行為はクローキングで、規則に反します。

エッジA/Bテストとは

エッジA/Bテストでは、すべてのバリエーションをoriginアプリケーションで描画せず、配信層で割り当てて変更します。 Evidence for this claim Cloudflare Workers can execute code and modify requests or responses at the network edge. Scope: Cloudflare Workers; other edge platforms have different runtimes and controls. Confidence: high · Verified: 2026-07-14 Cloudflare: Workers overview Googleはウェブサイトテストを認めていますが、クローキングを避け、一時的で管理された実験にするよう求めています。 Evidence for this claim Google permits website testing, warns against cloaking, and recommends appropriate canonicals or temporary redirects and limited test duration. Scope: Google Search guidance for website testing; it applies regardless of whether assignment occurs at the edge or origin. Confidence: high · Verified: 2026-07-14 Google: Website testing and Search

A/Bテストは、訪問者の一部にページA、別の訪問者にページBを表示し、どちらの成果が高いかを測る方法です。エッジA/Bテストでは、表示する版を訪問者のブラウザーや自社ウェブサーバーではなく、CDN（Cloudflare、Akamai、Fastly、またはエッジで動くOptimizelyやVWOなど）で選びます。

テストを実行できる場所は3つあり、その違いはSEOに大きく影響します。

1. Client-side — browser内のJavaScriptがページ読込後に内容を差し替えます。設定は速い一方、Googleが遅いJavaScriptを待たず変更を見ない場合があります。
2. Origin server-side — application serverが選択した版を構築し、実際のHTMLとして送ります。
3. Edge — CDNが選択版を実際のHTMLとして構築・書き換え、リクエストが自社serverへ届く前に返します。Googleが実HTMLを得るserver-sideと同じSEO上の利点に加え、高速でcode deployも不要です。

エッジでのテストがSEO上より安全な理由

最大の利点は、エッジが実際のHTMLを送るため、検索エンジンとユーザーが同じ種類のページを受け取ることです。Googleがテスト版を認識できないことがあるclient-sideテストの主要な問題を回避できます。

唯一の原則：Googleと人に異なる内容を見せない

GoogleはA/Bテスト自体を公式資料で認めています。認めていないのは、順位操作のために検索エンジンへ実際のユーザーとは異なるコンテンツを意図的に見せるクローキングです。安全なエッジテストでは、Googlebotにも実際のユーザーが受け取り得る正当で一貫した版を見せ、特別な「ボット版」を用意しません。

エッジでは、次の2点が原因でこの原則を誤って破ることがあります。

• Cookie。 多くのedge testは訪問者の版をcookieで記憶します。Googlebotは通常cookieを保持しないため、訪問のたびに別版へ無作為に再割り当てされ、Googleから不安定に見える可能性があります。
• 別URLへのリダイレクト。 ?variant=bのような別URLへ送ると、Googleが独立ページとして扱い両方をインデックス登録する場合があります。

どちらも修正できます。上級タブでは具体的な方法、テストを安全に続けられる期間、「ボットには通常版だけを返す」という近道が妥当か危険かまで説明します。

要点 — エッジA/Bテストは、originがリクエストを受け取る前にCDN worker層からバリエーションHTMLまたはリダイレクトを返します。検索エンジンもclient-side JavaScriptによる差し替えではなく実際のHTMLを受け取るため、テスト場所としては安全ですが、エッジ固有のリスクがあります。同一URLのHTML書き換えでは、Googlebotが通常cookieを保持しないため、cookieによる振り分けでクロールごとに別版を返す危険があります。バリエーションURLへのリダイレクトでは、重複コンテンツとcanonicalの混乱が問題になります。cookieのないトラフィックを決定論的に扱い、バリエーションからcontrolへrel=canonicalを向け、実施中は301ではなく302を使い、勝者が決まったら直ちに撤去します。Googleの境界は「テストはよいがクローキングは不可」であり、ボットが一度Bを見たことではなく意図と非対称性が問題です。

エッジテストで実際に変わること

edge workerは訪問者に近い場所でレスポンスを振り分けたり変換したりします。割り当て場所は変わりますが、実験の基本ロジックは変わりません。 Evidence for this claim Cloudflare Workers can execute code and modify requests or responses at the network edge. Scope: Cloudflare Workers; other edge platforms have different runtimes and controls. Confidence: high · Verified: 2026-07-14 Cloudflare: Workers overview 検索上の安全性は、検索クローラーを狙って実質的に異なる内容を返すのではなく、正当なテスト版を一貫して配信できるかで決まります。 Evidence for this claim Google permits website testing, warns against cloaking, and recommends appropriate canonicals or temporary redirects and limited test duration. Scope: Google Search guidance for website testing; it applies regardless of whether assignment occurs at the edge or origin. Confidence: high · Verified: 2026-07-14 Google: Website testing and Search

エッジA/Bテストはedge SEOの用途の一つです。Cloudflare Workers、Akamai EdgeWorkers／EdgeKV、Fastly Compute、OptimizelyやVWOのedge／server-side統合などのCDN workerで、originへ届く前に振り分けとHTML書き換え（またはリダイレクト）を行います。SearchPilotはedge SEOを*“any SEO changes that are made after the HTML is created by your CMS or origin server before it is served to the user,”* (翻訳) 「CMSまたはoriginサーバーがHTMLを生成した後、ユーザーへ配信される前に行うSEO変更」と説明し、“They appear to all users and googlebot as server side HTML changes, so there are no risks or downsides from an indexation point of view.” (翻訳) 「全ユーザーとGooglebotにはserver-sideのHTML変更として見えるため、インデックス登録上のリスクや欠点はない」と述べています。検索エンジンもorigin側と同じ実際のHTMLを受け取れることが基本的な利点です。

エッジが安全でも、SEO固有の落とし穴はエッジでの振り分け方にあります。この方式にほぼ固有で、一般的な「A/BテストとSEO」の記事が見落としやすい問題が2つあります。

Googleの実際の立場：テストはよいがクローキングは不可

GoogleはA/Bテストと多変量テストを明示的に認め、ベストプラクティスも公開しています。境界はクローキングです。スパムポリシーでは、“presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” (翻訳) 「検索順位を操作してユーザーを欺く意図で、ユーザーと検索エンジンに異なるコンテンツを提示すること」と定義しています。重要なのは操作の意図とユーザー／検索エンジン間の非対称性であり、「ボットが一度バリエーションを見た」ことではありません。Optimizelyも、“Google encourages constructive testing and does not view the ethical use of testing tools such as Optimize to constitute cloaking.” (翻訳) 「Googleは建設的なテストを奨励し、Optimizeなどを倫理的に使うことをクローキングとは見なさない」と説明しています。

Googleの実務上の境界は明快です。“Don’t show one set of URLs to Googlebot, and a different set to humans.” (翻訳) 「Googlebotに1組のURL、人に別のURLを見せてはいけません。」ボットを含む全員が同じ正当なバリエーションの対象となり、それを一貫して受け取れるならポリシーに適合します。

エッジテストの2方式と、それぞれ異なるリスク

この2方式は失敗の仕方も修正方法も異なるため、区別して考えてください。

方式1 — 同一URLのHTMLをエッジで書き換える

workerはURL（/product/123）を変えず、見出し、CTA、価格表示形式などをHTML Rewriterで差し替えます。Cloudflare Workersの「同一URLへ直接アクセスするA/Bテスト」方式であり、新規訪問者について*“Choose a group and set the cookie (50/50 split)”* (翻訳) 「グループを選び、cookieを設定する（50/50分割）」と説明されています。

エッジ固有のリスクはcookieです。 Googleは、“Googlebot generally doesn’t support cookies. This means it will only see the content version that’s accessible to users with browsers that don’t accept cookies.” (翻訳) 「Googlebotは通常cookieに対応せず、cookieを受け付けないブラウザーのユーザーがアクセスできる版だけを見る」と明記しています。多くの実装は再訪者を同じグループに保つためcookieへ振り分けを保存します。Akamaiの例も、“Client bucket selection will be persistent via a cookie value to ensure a client is locked to the same URL on subsequent visits” (翻訳) 「以後も同じURLへ固定するため、bucket選択をcookie値で永続化する」としています。Googlebotはcookieを持ち越さないため、クロールごとにrandomizerへ入り、前回とは別bucketになる可能性があります。欺く意図のあるクローキングではありませんが、Googleが同じURLの不安定な版を時間とともにインデックス登録する原因になります。

方式2 — エッジからバリエーションURLへリダイレクトする

workerが/product/123から別URLの/product/123?v=bまたは/product/123-bへ302を返します。検索エンジンが独立して発見し、インデックス登録できる実在の別URLができます。

エッジ固有のリスクは重複コンテンツとcanonicalの混乱です。 GoogleがバリエーションURLを独立ページとしてインデックス登録すると、シグナルが分散し、重複ページが生まれる可能性があります。

方式1の修正：クローラーへの出力を決定論的にする

修正方法は「ボットを検出してテストを隠す」ことではありません。cookieのないリクエストを無作為に振り分けないことです。人はcookieでbucket分けしても構いませんが、Googlebotを含むcookieなしのリクエストは、URLのhash、安定したkeyによる固定、常にcontrolを返す方法などで決定論的に処理します。同じURLがcookieなしのクライアントへ常に同じ版を返せば、Googleはクロールごとのコイントスではなく安定した1ページを見ます。

Cloudflareは、“Enable Passthrough to allow direct access to control and test routes.” (翻訳) 「Passthroughを有効にし、controlとtestのrouteへ直接アクセスできるようにする」と説明しています。Passthroughを使えば、bot、QA担当者、stakeholderの誰でも再抽選されず/control/*または/test/*へ一貫して到達できます。ボット専用コードを作らずクローラーへ一貫した版を返す公式手段です。

SearchPilotは別の粒度で分割します。“When doing SEO A/B testing, there is only one version of the page. We are not showing different versions of the same page to users or Google. This isn’t cloaking and doesn’t create any duplicate versions of the same page.” (翻訳) 「SEO A/Bテストではページは1版だけです。同じページの異なる版をユーザーやGoogleへ見せないため、クローキングではなく重複版も生まれません。」ユーザーを無作為に分けず、ページを決定論的に分け、あるページは全員へ同じ版を返します。Cloudflareのcookie 50/50方式とは逆で、SEOリスクも異なります。さらに、“There is only one Googlebot. You also can’t make two versions of a single page because it would cause problems like duplicate content.” (翻訳) 「Googlebotは1つしかなく、重複コンテンツなどの問題になるので、1ページを2版にはできない」と説明しています。

方式2の修正：canonicalとリダイレクトを規律化する

テストを別URLで行う場合は、Googleのテスト資料にある3つの原則を直接適用します。

• バリエーションからcontrolへcanonicalを向ける。 Googleは、“you can use the rel=“canonical” link attribute on all of your alternate URLs to indicate that the original URL is the preferred version.” (翻訳) 「すべての代替URLでrel=“canonical” link属性を使い、元のURLが優先版だと示せる」と説明しています。各バリエーションURLのcanonicalをcontrol URLへ向けます。
• テスト中は301ではなく302を使う。 Googleは、“use a 302 (temporary) redirect, not a 301 (permanent) redirect.” (翻訳) 「301（恒久）ではなく302（一時）リダイレクトを使う」としています。302は一時的な移動、301は恒久移動を意味します。301は勝者を選び恒久的に切り替えた後に使います。
• 終了したら撤去する。 Googleは、“Once you’ve concluded the test, update your site with the desired content variation(s) and remove all elements of the test as soon as possible… we may interpret this as an attempt to deceive search engines and take action accordingly.” (翻訳) 「テスト終了後は希望する版でサイトを更新し、テスト要素をできるだけ早く削除する。長く残すと検索エンジンを欺く試みと解釈し、措置を取る場合がある」と説明しています。

canonicalは命令ではなくhintです。バリエーションとcontrolの内容が大きく違えば、Googleはcanonicalを無視して両方をインデックス登録できます。そのため方式2は同一URL書き換えより危険で、大規模な構造変更はユーザーごとのバリエーションURLではなくページ単位の分割で扱うほうが安全です。

クロール予算：多変量による乗算問題

単一のA/Bテストはクローラーが見る可能性のある状態を1つ増やします。多変量テストでは状態が乗算され、独立した3変数に各2版があれば最大8通りです。URLごとの振り分けが固定的かつ決定論的でなければ、1つのURLが変動する状態群になり、クロール可能な各状態がクロール予算を消費します。決定論的でstickyな振り分けは、クローキングだけでなくクロール効率にも重要です。背景としてGoogleの2024年「Crawling December」にあるCDNとクロール予算のガイダンスを参照してください。

「ボットにはcontrol版だけを返す」— 近道か落とし穴か

この助言は半分正しいため注意が必要です。クローラーへ安定したcontrol版を返すことは、その版が実際のユーザーへ常に返してもよく、Googleにインデックス登録してほしい正当な版なら問題ありません。安全性はボット検出ではなく、一貫性と正当性から生まれます。

検索エンジンにだけ実ユーザーと異なる現実を見せるために「ボット経路」を作った時点でクローキングになります。Googleの原文は*“Don’t show one set of URLs to Googlebot, and a different set to humans”* (翻訳) 「Googlebotに1組のURL、人に別のURLを見せてはいけない」です。正しい考え方は、クローラーにも、どのユーザーが常に見ても差し支えない同じ決定論的な版を返すことです。審査を避けるためのボット専用routeではありません。UA判定でボットをテストから除外する方法が安全なのは、たまたま正当な1版に固定できる場合だけで、一般的に安全な手法ではありません。

エッジテストを実行できる期間

Googleは日数を定めていません。一方、「テスト」が勝者を決めないまま恒久状態にならないよう、“remove all elements of the test as soon as possible” (翻訳) 「テスト要素をできるだけ早く削除する」と警告しています。John Muellerは、実験を次々に行うこと自体は問題ないが、単一テストを無期限に残して事実上の恒久ページにする状態は、もはやテストに見えなくなると述べています。（この発言はGoogle Webmaster Central Hangoutの業界記事による要約であり、Googleの一次資料ではないため、文言はparaphraseとして扱います。） またサイト移行中のA/Bテストは、Googleが移行を認識するためのリダイレクトシグナルを曖昧にするので、両者を重ねないでください。

OptimizelyはGoogleの方針を、“If you are running an experiment for an unnecessarily long time, Google may interpret this as an attempt to deceive search engines and take action accordingly.” (翻訳) 「不必要に長く実験を続けると、Googleが検索エンジンを欺く試みと解釈して措置を取る可能性がある」と説明しています。勝者の展開では、301リダイレクトによるlink equity損失を*“a small loss of link equity (around 10%)”* (翻訳) 「約10%の小さな損失」と見積もっていますが、これはOptimizelyの目安でありGoogle確認値ではありません。

Bingのガイダンスは限定的 — Googleを既定にする

BingにはGoogleほど詳しいエッジ／CDN A/Bテスト専用ページがありません。一般的なクローキング基準では、“as long as you make a good faith effort to return the same content to all visitors, with the only difference being the content is rendered on the server for bots and on the client for real users, this is acceptable and not considered cloaking” (翻訳) 「全訪問者へ同じ内容を返すよう誠実に努め、違いがボット向けserver-side描画と実ユーザー向けclient-side描画だけなら、クローキングではない」としています。また、“significant structural changes, we recommend hosting each version on separate URLs, or split URL testing,” (翻訳) 「大きな構造変更では各版を別URLに置くsplit URL testingを推奨する」とし、IndexNowでバリエーションURLを迅速に発見させます。Bingの基準はGoogleと両立するため、canonical、302、期間はGoogleの規則を両エンジン向けの保守的な既定にします。

関連記事での位置づけ

この記事は、同じクラスターにある一般的なedge SEO記事のテスト特化版です。プラットフォームの種類やエッジの他用途は一般記事が扱い、ここではsplit testingのリスクだけを扱います。方式2のcanonicalと重複コンテンツはcanonicalizationとduplicate contentの記事、クロール予算はcrawlingとcrawl budgetの記事で詳しく説明しています。

AI要約

上級版の要点をまとめます。

• エッジA/BテストはCDN worker層（Cloudflare Workers、Akamai EdgeWorkers、Fastly Compute、Optimizely／VWO edge）で実行し、originより前にバリエーションHTMLまたはリダイレクトを返します。検索エンジンも実際のHTMLを受け取るため、client-side JS差し替えより安全です。
• Googleの立場: テストはよいがクローキングは不可。問題は操作の意図とユーザー／ボット間の非対称性であり、ボットが一度Bを見たことではありません。
• 2方式と2リスク: 同一URL書き換えでは、cookieを保持しないGooglebotがクロールごとに再抽選され、内容が不安定になります。バリエーションURLへのリダイレクトでは、重複とcanonicalの混乱が起きます。
• 修正: cookieなしのトラフィックをURLごとに決定論的にし、バリエーションURLからcontrolへrel=canonicalを向け、実施中は301ではなく302を使い、勝者が決まれば撤去します。
• ページ分割とユーザー分割: SearchPilot式の決定論的なページ分割はcookie問題を回避します。ユーザーごとの無作為振り分けには決定論的fallbackが必要です。
• クロール予算: 多変量テストは、stickyで決定論的にしないとクロール可能状態を乗算します。
• ボットへcontrolを返す方法: controlが本当にインデックス登録してほしい正当な版なら安全です。ボット検出そのものが安全性を作るわけではありません。
• 期間: 固定上限はありませんが恒久状態にせず、移行中は避けます。Bingの資料は限定的なのでGoogleの規則を既定にします。

実行中の方式と必要な修正を判定する

エッジテストのSEO問題は、URLが変わるか、クローラー向けバリエーションが決定論的かという2問に集約できます。順にたどり、該当する修正を確認してください。

公式ドキュメント

検索エンジンとプラットフォームベンダーによる一次資料です。

Google

• 検索向けA/Bテストのベストプラクティス — この記事が用いるcanonical、302、期間、cookieの指針です。
• スパムポリシー — クローキング — 操作意図と非対称性に基づくクローキングの定義です。

Bing／Microsoft

• IndexNowとMicrosoft Clarityで検索性能を改善するA/Bテスト — 構造変更では別URLを使い、IndexNowで発見させるBingの説明です。
• bingbotシリーズ：JavaScript、Dynamic Rendering、クローキング — 誠実に実質同等の内容を返すというBingの基準です。

CDN／テストプラットフォーム

• Cloudflare Workers — 同一URLへ直接アクセスするA/Bテスト — cookieによる50/50例と、一貫した版へアクセスするpassthrough方式です。
• Akamai — EdgeWorkersとEdgeKVでA/Bテストを構築 — エッジでcookieへ固定する振り分け例です（資料にSEO／botの説明はありません）。
• Optimizely — A/Bテストと検索エンジン最適化 — Googleの規則を顧客向けに説明するベンダー資料です。

原文からの引用

Google、Bing、プラットフォームベンダーの公式発言です。Google／Bing／Cloudflareの各リンクは引用箇所へ直接移動します。

Google — A/Bテストのベストプラクティス

• “Don’t show one set of URLs to Googlebot, and a different set to humans.” (翻訳) 「Googlebotに1組のURL、人に別のURLを見せてはいけません。」 引用箇所へ
• “Googlebot generally doesn’t support cookies. This means it will only see the content version that’s accessible to users with browsers that don’t accept cookies.” (翻訳) 「Googlebotは通常cookieに対応せず、cookieを受け付けないブラウザーからアクセスできる版だけを見ます。」 引用箇所へ
• “you can use the rel=“canonical” link attribute on all of your alternate URLs to indicate that the original URL is the preferred version.” (翻訳) 「すべての代替URLでrel=“canonical” link属性を使い、元URLが優先版だと示せます。」 引用箇所へ
• “use a 302 (temporary) redirect, not a 301 (permanent) redirect.” (翻訳) 「301（恒久）ではなく302（一時）リダイレクトを使います。」 引用箇所へ
• “Once you’ve concluded the test, update your site with the desired content variation(s) and remove all elements of the test as soon as possible… we may interpret this as an attempt to deceive search engines and take action accordingly.” (翻訳) 「テスト終了後は希望する版で更新し、テスト要素をできるだけ早く削除します。残し続けると検索エンジンを欺く試みと解釈され、措置を受ける場合があります。」 引用箇所へ

Google — クローキング（スパムポリシー）

• “Cloaking refers to the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” (翻訳) 「クローキングとは、検索順位を操作してユーザーを欺く意図で、ユーザーと検索エンジンに異なるコンテンツを提示する行為です。」 引用箇所へ

Bing／Microsoft

• “as long as you make a good faith effort to return the same content to all visitors, with the only difference being the content is rendered on the server for bots and on the client for real users, this is acceptable and not considered cloaking.” (翻訳) 「全訪問者へ同じ内容を返すよう誠実に努め、違いがボット向けserver-side描画と実ユーザー向けclient-side描画だけなら、クローキングではありません。」 引用箇所へ
• “If you’re creating significant structural changes, we recommend hosting each version on separate URLs, or split URL testing.” (翻訳) 「大きな構造変更を行う場合は、各版を別URLでホストするsplit URL testingを推奨します。」 引用箇所へ

Cloudflare Workers — 同一URLの例

• “Enable Passthrough to allow direct access to control and test routes.” (翻訳) 「Passthroughを有効にし、controlとtestのrouteへ直接アクセスできるようにします。」— クローラー、QA担当者、stakeholderを無作為なcookie抽選ではなく、一貫した版へ到達させる公式手段です。 引用箇所へ

Akamai — EdgeKVの例

• “Client bucket selection will be persistent via a cookie value to ensure a client is locked to the same URL on subsequent visits.” (翻訳) 「以後の訪問でも同じURLへ固定するため、クライアントのbucket選択はcookie値によって永続化されます。」 （Akamaiの資料はconversion engineeringだけを扱い、SEO、bot、crawlerの観点はありません。SEOの評価は実装者が別途行う必要があります。）

Optimizely — 顧客向けベンダー指針

• “Google encourages constructive testing and does not view the ethical use of testing tools such as Optimize to constitute cloaking.” (翻訳) 「Googleは建設的なテストを奨励し、Optimizeなどのテストツールを倫理的に使うことをクローキングとは見なしません。」
• “If Google determines that the variation of your page is substantially different from the original in scope and content, then they may construe this change as cloaking.” (翻訳) 「ページのバリエーションが範囲と内容の点で元ページと大幅に異なるとGoogleが判断すれば、その変更をクローキングと解釈する可能性があります。」 （OptimizelyがGoogleポリシーの解釈を顧客へ示したベンダー指針であり、独立した権威ではありません。「301でlink equityが約10%失われる」という数値も、Google確認値ではなくOptimizelyの目安です。）

SearchPilot — ページ分割方式

• “When doing SEO A/B testing, there is only one version of the page. We are not showing different versions of the same page to users or Google. This isn’t cloaking and doesn’t create any duplicate versions of the same page.” (翻訳) 「SEO A/Bテストではページは1版だけです。同じページの異なる版をユーザーやGoogleへ見せないため、クローキングではなく重複版も生まれません。」 （server-side／edgeテストベンダーのSearchPilotが、自社のページ分割方式を説明した発言です。無作為なcookie振り分けとの方法論的な違いとして引用しています。）

エッジA/BテストのSEOチェックリスト

インデックス登録済みページに影響するエッジテストを公開する前に実行します。

• 実行方式を把握している。同一URLのHTML書き換えか、バリエーションURLへのリダイレクトか。
• cookieなしのリクエストが決定論的である。通常cookieを持たないGooglebotがURLごとに常に同じ版へ解決され、毎回無作為抽選されない。
• バリエーションURLなら、各版にcontrol URLへ向くrel=canonicalがある。
• テスト中のリダイレクトは301ではなく302である。301はテスト後の勝者だけに使う。
• クローラーが見る版は、インデックス登録してよい正当で代表的な版であり、実験を隠すボット専用経路ではない。
• 審査を避けるため、UA判定でボットへ実ユーザーとは異なる内容を見せていない。
• 多変量テストではURLごとの振り分けがstickyかつ決定論的で、クロール可能状態を乗算しない。
• 勝者を選ぶ時点とテスト基盤を直ちに削除する計画があり、事実上の恒久ページとして放置しない。
• サイト移行と重ねていない。リダイレクトシグナルが曖昧になるため。
• CDNのWAF／bot ruleがtest workerより前にGooglebotを遮断・迂回していない。
• URL Inspection／logでGooglebotが実際に受け取る版を確認した。

判断の枠組み

1. テストはよいがクローキングは不可。 GoogleはA/Bテストと多変量テストを奨励します。危険なのはテスト自体ではなく、操作意図を伴うbot／userの非対称な扱い、または事実上の恒久サイトになるまで放置することです。すべての判断をこの原則に結び付けます。

2. 2方式と2つの修正。

• 同一URLのHTML書き換え → cookie振り分けとcookieを持たないGooglebotによりクロールごとに内容が揺れる危険。cookieなしtrafficの版を決定論的にします。
• バリエーションURLへのリダイレクト → 重複コンテンツ／canonicalの混乱。実施中はcontrolへのcanonical + 302にします。

3. 安全性を作るのはボット検出ではなく、一貫性と正当性です。 クローラーへ安定したcontrolを返してよいのは、それが本来インデックス登録する正当な版だからです。安全性は一貫性に由来します。コンテンツを隠すボット専用経路はクローキングそのものです。

4. ページ分割とユーザー分割。 ページごとに1版を全員へ返す決定論的なページ分割はcookie問題を回避します。ユーザーごとの無作為なcookie振り分けにはcrawler向けの決定論的fallbackが必要です。どちらもedge A/B testingと呼ばれますが、リスクは大きく異なります。

5. クロール可能状態はクロール予算を使う。 URLが取り得る各状態が予算を消費します。A/Bテストは状態を1つ増やし、多変量テストはURLごとの振り分けがstickyかつ決定論的でなければ状態を乗算します。

6. SEO上の可視性はclient-side < origin server-side ≈ edge。 Client-side JSの差し替えは検索エンジンに見落とされる場合があります。origin server-sideとedgeはいずれも実際のHTMLを返します。edgeはoriginより前に高速に処理する一方、cookieとredirectに固有の危険があります。

エッジA/Bテスト早見表

2つの方式

テスト中のリダイレクト規則

「ボットにはcontrolを返す」— 安全か

• 安全：controlが本当に代表的で、いずれにしてもインデックス登録する版である。一貫性が目的。
• 危険：検索エンジンへユーザーと異なる現実を見せるボット専用経路である。これはクローキング。

要点

• Googlebotは通常cookieを保持しないため、cookieだけの振り分けはbotに不安定です。
• canonicalは命令ではなくhintなので、大きな構造差があれば両URLがインデックス登録されることがあります。
• 期間の固定上限はありませんが、恒久状態にせず移行中も避けます。
• Bingには専用のedge A/B testing資料がないため、Googleの規則を既定にします。
• Optimizelyの**「301でlink equityが約10%失われる」**という値はベンダーの目安で、Googleの数値ではありません。

エッジテストで避けるべき誤解と失敗

頻出する落とし穴と、訂正すべき広く流布した誤解をまとめます。

• 「テスト自体が危険で規則違反だ」 いいえ。Googleは建設的なA/Bテストと多変量テストを奨励しています。リスクは実装にあります。
• 「ボットをテストから完全に除外すれば安全だ」 半分だけ正しいです。正当なcontrolへ安定して固定するなら問題ありませんが、審査回避のボット検出はクローキングです。
• 「広告技術と同じcookie振り分けでよい」 SEOでは違います。Googlebotは通常cookieを持たないため、決定論的fallbackがなければ挙動が不安定です。
• 「勝者への301とテスト中の302はほぼ同じだ」 違います。302は一時的で元URLを維持し、301は恒久移動を示します。301は勝者確定後だけに使います。
• 「canonicalがあればバリエーションURLは絶対にインデックスされない」 canonicalはhintです。内容差が大きければGoogleが無視して両方を登録する可能性があります。
• 「edge、origin server-side、client-sideのSEOリスクは同じだ」 client-side JS差し替えは検索エンジンに見落とされる場合があります。edge／originは実際のHTMLを返し、edgeにはcookieを持たないbot、バリエーションURL、CDN cache、WAFという固有リスクがあります。
• 「数か月続けてもテスト中なら問題ない」 勝者を決めず事実上の恒久ページにすると、Googleが欺く試みと解釈する可能性があります。終了し、勝者を選び、基盤を撤去します。
• 「CDNベンダーのA/Bテスト資料にSEO観点もある」 通常はありません。AkamaiのEdgeKV例にもSEO、bot、crawlerの説明はなく、実装者が別途評価します。

クローラーが実際に受け取る版を確認する

Googlebotの一般的な挙動を再現するcookieなしのリクエストが、一貫した版へ解決されることが重要です。次の方法で、cookieがないときにエッジが返す内容を確認します。

cookieなしのクライアントとして取得する（shell／curl）

# No cookie sent — this is closest to how Googlebot hits you.
# Run it a few times: the variant should be the SAME every time (deterministic),
# not a fresh 50/50 roll.
for i in 1 2 3; do
  curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
    https://example.com/product/123 | grep -o 'data-variant="[^"]*"'
done

# Show the response headers too — look for Set-Cookie (bucketing),
# Vary, and any redirect (302 good / 301 bad while testing).
curl -sI -A "Googlebot" https://example.com/product/123

バリエーションURLへのリダイレクトとstatusを確認する（shell）

# -L follows redirects; -w prints the chain of status codes.
# A live test should show 302, never 301.
curl -sIL -o /dev/null \
  -w "%{http_code} -> %{redirect_url}\n" \
  https://example.com/product/123

DevTools consoleで配信版とcanonicalを確認する（bookmarklet対応）

テスト中のページでbrowser consoleへ貼り付けます。または、javascript:に本文を続けてbookmarkletとして保存すれば、どのページでも1回の操作で確認できます。

// What variant am I seeing, and does the page canonical to the control?
(() => {
  const variant = document.querySelector('[data-variant]')?.dataset.variant
    ?? 'no data-variant attr found';
  const canonical = document.querySelector('link[rel="canonical"]')?.href
    ?? 'no canonical';
  const hasCookie = /(?:^|; )ab_bucket=/.test(document.cookie);
  console.log({ url: location.href, variant, canonical, hasCookie });
})();

エッジlogを正規表現で調べ、決定論的な振り分けを確認する

workerがリクエストごとのbucketをlogへ記録する場合は、cookieなしのリクエストとbucketを抽出し、同じURLが常に同じバリエーションへ対応するか確認します。

# Match log lines with no ab_bucket cookie, capture URL + assigned variant.
# Group by URL: every URL should show ONE variant, not a mix.
grep -vE 'ab_bucket=' edge.log \
  | grep -oE '"(GET|HEAD) [^"]+".*variant=[AB]' \
  | sort | uniq -c | sort -rn

cookieなしのリクエストで1つのURLにvariant=Aとvariant=Bの両方が現れるなら、クローラー向けの振り分けは決定論的ではありません。Googlebotが変動する対象をインデックス登録する前に修正してください。

エッジテストの実行・確認ツール

• Cloudflare Workers — 同一URLのHTML Rewriterと、一貫したcontrol／testアクセスを可能にするpassthrough方式。
• Akamai EdgeWorkers + EdgeKV — cookieへ固定するedge振り分け。SEOのguardrailは実装者が追加します。
• Fastly Compute — 同じ書き換え／redirect方式に使えるedge compute。
• Optimizely／VWO — client-sideではなくedgeで動かせる商用実験platform。
• SearchPilot — ページごとに1版を全員へ返す決定論的ページ分割でcookie問題を回避するserver-side／edge SEO A/B testing。
• Google Search Console — URL Inspection — GooglebotがテストURLをどうcrawl・renderし、どの版を見たか確認する。
• Server log解析 — 実crawlerが受け取った版、頻度、cookieなしrequestの一貫性を確認する一次データ。
• curl／DevTools console — cookieなし版、canonical、redirect statusを手動確認する。
• IndexNow — URL分割テストでバリエーションURLをBing／Yandexへ迅速に通知するprotocol。

クローラー向け振り分けが決定論的か監査する

Review this edge A/B test implementation. First classify it as:
A. Same-URL HTML rewriting, or
B. Redirect to a separate variant URL.

Then trace assignment for: a normal first visit, a returning visitor with a cookie,
Googlebot without a cookie across repeated crawls, and a request whose cache key is reused.
Return:
1. Every source of randomness or unstable assignment
2. Whether the same URL can show a crawler different indexable versions over time
3. Whether cache keys mix control and variant responses
4. For redirected variants, the redirect status and canonical relationship
5. User-agent branches that show bots content users cannot receive
6. A deterministic replacement and a repeat-request test plan
7. The cleanup required when the test ends

Do not assume crawlers retain cookies. Do not call a test safe merely because bots receive
the control; verify that control is genuinely available to users and is the intended
indexable version. Do not invent CDN settings or experiment data.

Worker/middleware code, routes, cache configuration, and test design:
[PASTE INPUT]

バリエーションURLを使うテスト案をレビューする

Check this edge redirect test for temporary-test hygiene. Verify that the variant URL
canonicalizes to the control, the redirect is temporary, internal links and sitemaps do
not multiply the test URLs, crawler assignment is stable, and an end date/winner-removal
plan exists. Return pass/fail per condition and the smallest safe correction.

Inputs:
[PASTE REDIRECT RULES, HEAD OUTPUT, CANONICALS, AND TEST WINDOW]

時間を使う価値がある資料

関連記事

• テクニカルSEO初心者ガイド — テストとcrawlabilityの全体像、およびエッジテストが越えてはいけないクローキングの境界を説明します。

講演

• 検索の仕組み — SlideShareで公開した、crawling、rendering、indexing、rankingの講演です。cookieを持たないクローラーの挙動を理解する背景になります。免責事項は原文どおり、“This is my understanding of systems… not going to be 100% complete or accurate.” (翻訳) 「私のシステム理解であり、100%完全または正確とは限りません」です。

業界資料

• 検索向けA/Bテストのベストプラクティス — Google Search Centralによるcanonical、302、期間、Googlebotとcookieの一次資料です。
• Cloudflare Workers — 同一URLへ直接アクセスするA/Bテスト — cookie 50/50例とpassthrough方式です。
• EdgeWorkersとEdgeKVでA/Bテストを構築 — Akamaiによる、エッジでcookieへ固定する例です。SEOの説明はありません。
• A/Bテストと検索エンジン最適化 — OptimizelyによるGoogleの規則と301での「約10%」という目安です。
• SEO A/B testingとは — SearchPilotによるページ分割とユーザー分割、「Googlebotは1つ」という考え方です。
• エッジでのSEOとSEOテスト — SearchPilotによる、edge変更がユーザーとGooglebotへserver-side HTMLとして見える理由です。
• IndexNowとMicrosoft Clarityで検索性能を改善するA/Bテスト — Bing Webmaster BlogによるA/BテストとIndexNowの指針です。

確認テスト：エッジA/BテストとSEO

エッジでsplit testを実行し、SEO問題を避けるための5問です。回答を選んで確認してください。

変更履歴