エッジSEO

要点 — エッジSEOとは、Webサイト自体を編集する代わりに、その前段にあるCDNで技術的SEOを変更する方法です。CDN上の小さなscript（worker）が、pageが訪問者やGoogleへ届く前にredirectを追加し、tagを修正し、robots.txtを書き換えます。編集できないplatformやdeveloper待ちの状況で、SEO担当者が修正を素早く公開できます。絶対的な原則は、変更を全員に適用することです。Googleに実ユーザーと異なるものを見せればクローキングとなり、規則に反します。

エッジSEOとは

多くのWebサイトはCDN（content delivery network）の背後にあります。CDNはsiteをcacheし、素早く配信するglobalなserver networkで、Cloudflareがよく知られています。CDNは実際のserver（origin）と外部世界の間にある最後の層なので、外へ向かうすべてのresponseを確認し、変更できます。 Evidence for this claim A CDN edge worker can execute in the request and response path and transform an origin response before delivery. Scope: Cloudflare Workers as a concrete edge implementation. Confidence: high · Verified: 2026-07-14 Cloudflare Workers: How Workers works

エッジSEOはこの位置を利用します。開発者にWebサイトのcode変更を依頼する代わりに、CDNへ小さなprogram、つまりworkerを置き、通過するpageを編集します。redirectの追加、欠けたtagの注入、titleの交換、robots.txt fileの置換が可能です。実際のWebサイトには触れず、数分で変更を公開できます。

workerは管理対象のserverではなくCDNのinfrastructure上で動くため、serverless SEOとも呼ばれます。

エッジSEOが使われる理由

大きな理由は2つあります。

• 開発キューで止まっている: SEOの推奨事項は実装まで数か月待つことがあります。エッジSEOなら変更を自分で出荷できます。
• プラットフォームを編集できない: Shopifyや一部のエンタープライズシステムでは、robots.txt、カスタムリダイレクト、特定のタグを変更できません。前段のworkerなら変更できます。

最も重要な1つのルール

覚えておく点はこれです。Googleには訪問者と同じページを見せなければなりません。

workerが全員に同じ変更を行う限り、edge SEOは問題ありません。canonical tagを注入するならbotと人間の両方に返します。workerが「これはGoogleか」と確認して、実際の人々と異なるものをGoogleへ返した瞬間、それはクローキングとなり、Google policy違反です。 Evidence for this claim Google prohibits intentionally presenting different ranking-manipulative content to search engines and users. Scope: Google Search spam policy. Confidence: high · Verified: 2026-07-14 Google: Spam policies — cloaking

したがって、pageは全員向けに編集します。検索エンジンだけを対象に編集してはいけません。

知っておくべきその他の点

• CDNが誤ってGoogleを遮断する場合もあります。firewallや「悪質なbotをblockする」設定などのsecurity機能がGooglebotを脅威として扱うことがあるため、有効にした後もGoogleがaccessできるか再確認してください。
• Googleだけを対象にedgeでpageを「pre-render」しないでください。Googleが公式に距離を置いた古い手法です。詳しくはAdvancedタブで説明します。

workerがリクエストをどう処理するか、プラットフォームの選択肢、実際のユースケース、リスクの所在まで確認するには、Advancedタブへ切り替えてください。

要点 — エッジSEO（serverless SEO）とは、レスポンスがユーザーやクローラーへ届く前にCDN／エッジworker層で書き換え、originやCMSをデプロイせずに、リダイレクト、canonical、hreflang、robots.txt、X-Robots-Tag、JSON-LD、ページ分割A/Bテストなどの技術的SEOを実装することです。workerは、受信リクエスト、送信ヘッダー、レスポンス本文という3段階で変更を行います。開発待ちが長い場合や、Shopify、Salesforce Commerce Cloudのように変更が制限されたプラットフォームで役立ちます。絶対に越えてはいけない境界はクローキングです。すべての変更を全トラフィックに適用し、Googlebotだけにユーザーと異なる内容を返してはいけません。エッジ固有の落とし穴も2つあります。CDNのWAF／ボットルールはworkerが動く前にGooglebotを静かに遮断できるため、GoogleのIP範囲と照合して監査します。また、ボットだけを対象とする事前レンダリングは構造的にdynamic renderingであり、Googleは非推奨としています。workerはすべてのリクエスト経路にある単一障害点でもあるため、バージョン管理し、適用範囲を絞り、ワンクリックで戻せるようにしてください。

エッジSEOの実態

エッジSEOは、metaタグ、canonical、hreflang、リダイレクト、robots.txt、構造化データ、A/Bテスト、慎重な事前レンダリングなどの技術的SEO変更を、CDN／エッジ層で実装する方法です。バックエンドやCMSのデプロイを待たず、レスポンスがoriginから返る前に変更します。

重要なarchitecture上の洞察は、Googleが見るのはCDNが配信するものだけだということです。workerが介在したかどうかは見えません。edge responseこそが、page上にあるものの正式な真実です。だからこそedgeは強力なSEO layerであり、クローキングとの境界が非常に重要です。2つの異なるものを配信する行為を止めるのは規則だけです。

私はこの方法を実際の大規模サイトで扱ってきました。Marketing Speakのインタビュー では、Cloudflare Workersでできることを端的に説明しています。基本的にはJavaScriptを実行して、ほぼあらゆる変更を行えます。タグマネージャーとの違いはタイミングです。エッジで行えばユーザーが見る前にページを書き換えますが、Google Tag Managerはまずページ上で読み込まれ、その後クライアント側で変更します。非常に大規模なサイトではHTML Rewriterをサイトに向け、誤ってnoindexになったページ、followにすべきnofollow、書き換えるべきタイトルやmeta descriptionなどを規模横断で検出し、コードをデプロイせずにルールで修正できます。

誇張を避けるため、経緯も押さえておきましょう。「edge SEO」という用語を作ったのはSALT.agencyのDan Taylorです。2018年にボストンで開催されたTechSEO Boostで公に紹介され、SALTはCloudflare WorkersをSEOに活用する研究で第1回の研究賞を受賞しました。Danが示した狙いは、Cloudflare Workersのようなworkerを使って、古いウェブサイト基盤、混み合った開発待ち行列、協力を得にくい開発体制といった障害を減らすことでした。彼の代表的な定義では、edge SEOとはCDNのエッジサーバー上でserverlessアプリケーションを使い、SEO施策や技術修正を実装し、プラットフォームの制約を乗り越える手法です。

開発キューの問題が現実的な理由

動機となる問題は現実的です。SALTはWill Critchlowによる2016年のMoz調査を引用し、SEO担当者の多くが推奨事項を作成してから実装されるまでおよそ6か月待っていたと説明しました。

特に重要なのは、Shopify、Salesforce Commerce Cloud、編集できないレガシーなエンタープライズ構成など、制限の強いプラットフォームです。robots.txtや必要なリダイレクトを編集できない場合、前段のworkerが実装経路になります。

エッジworkerがリクエストとレスポンスを処理する方法

workerはrequest／response pathに入り、結果を返す前に、組み合わせ可能なrequest変換とresponse変換を適用できます。 Evidence for this claim Cloudflare Workers can compose request and response transformations at the edge. Scope: Cloudflare Workers; not a universal three-phase standard. Confidence: high · Verified: 2026-07-14 Cloudflare Workers: How Workers works

フェーズ1 — リクエスト変更: ユーザーまたはGooglebotが送ったリクエストをorigin到達前にCDNが受け取ります。workerはURLを書き換えたり、エッジから3xxリダイレクトを即時返したりできます。

Phase 2 — response headerの変更。 originがresponseを返した後、workerはX-Robots-Tag、Link: rel=canonical、cache header、security headerなどのresponse headerを追加または変更できます。

フェーズ3 — レスポンス本文の変更。 workerでHTMLをストリーム解析しながら書き換えます。たとえば、<link rel="canonical">、hreflangの代替リンク、<title>、<meta name="robots">、<meta name="description">、<script type="application/ld+json">を挿入したり、コンテンツを削除・置換したりできます。CloudflareではHTML Rewriterが標準的な手段です。SALTが公開したインターフェース（RequestFilter、ResponseFilter、BodyFilter）は、それぞれ独立して組み合わせられます。

性能について、SALTのテストでは追加レイテンシーは平均約10msで、極端な場合は約50msでした。本文フィルタリングを本番で使っても、統計的に有意な本番レイテンシー変化は報告されていません。

プラットフォームとツール

エッジworkerのエコシステムは広範です。短くまとめると、用途とSEO上の制約を各プラットフォームの仕様に合わせて選びます。

Cloudflare SnippetsとWorkersの違いは、他では十分に説明されていない重要な点です。SEOでの目安は、リダイレクトとヘッダー変更にはSnippetsを使うことです。軽量で、有料プランでは無料ですが、永続ストレージはありません。canonical、hreflang、JSON-LDなどのHTML本文への注入、大規模なKVリダイレクト表、永続性を伴うA/BテストにはWorkersを使います。

enterprise A/B toolについて補足します。SearchPilotのJetStreamはWASM binaryで、同社によればweb stackへ新しいlayerを追加せずedge上に置かれ、ユーザーではなくページを分割します。そのため、後述するクローキングとの境界の安全側にとどまります。

よくあるユースケース

• エッジでのリダイレクト。 KV／EdgeKVにリダイレクト表を置き、workerが受信URLを照合してCDNから直接301／302を返します。Fastlyも、リダイレクトを可能な限り高速に配信できるエッジが最適な場所だと説明しています。301に対応しないプラットフォームや、大規模移行のリダイレクトマップにも有効です。
• meta tag、canonical、hreflangの注入。 <head>をストリーム解析し、CMSでは設定できない要素を注入します。
• robots.txtの変更。 /robots.txtをインターセプトし、変更済みまたは合成したレスポンスを返します。ShopifyやSalesforce Commerce Cloudの典型的な制約を回避できます。
• X-Robots-Tagヘッダー。 meta robotsを持てないPDFや画像などの非HTMLファイルに、index制御ディレクティブを追加または変更します。
• 構造化データ（JSON-LD）の注入。 プラットフォームが対応していない場合やコードフリーズ中に、レスポンス本文のschemaを追加または変更します。
• 正しい方法で行うSEO A/Bテスト。 controlとvariantはページ単位で分け、各ページではGooglebotとすべてのユーザーに同じ版を見せます。ページ分割はGoogle上安全な方法ですが、ユーザー分割はクローキングです。
• JavaScriptサイトの事前レンダリング。ただし注意。 エッジから事前レンダリング済みHTMLのsnapshotを配信できますが、クローラーだけに配信すればdynamic renderingになります。詳しくはクローキングの節を参照してください。
• 制限の多いプラットフォームでのログ収集。 サーバーログを公開しないプラットフォームでも、Cloudflare LogpushとWorkersでリクエスト／レスポンスデータを取得できます。
• クロールバジェットの衛生管理。 レスポンスから追跡パラメータを除き、薄いvariantからcanonicalへクローラーをリダイレクトします。

最大のリスク：クローキング

ここは明確に理解する必要があります。Googleのスパムポリシーでは、検索順位を操作してユーザーを欺く意図で、ユーザーと検索エンジンに異なるコンテンツを提示する行為をクローキングと定義しています。 Evidence for this claim Google's spam policy defines cloaking as presenting different content to users and search engines with an intent to manipulate rankings and mislead users. Scope: Google Search spam policy. Confidence: high · Verified: 2026-07-14 Google: Spam policies — cloaking たとえば、人ではなく検索エンジンのユーザーエージェントがアクセスしたときだけ、ページに文章やキーワードを追加する行為です。

したがって、エッジSEOに当てはめると次のようになります。

• 安全: すべての<head>へ同じcanonical tagを注入し、botとユーザーに同一のHTMLを返す。
• 危険: User-Agent: Googlebotを検出し、botには見えてユーザーには見えないcontentを注入する。
• グレー: JavaScript contentをクローラーだけに事前レンダリングする。構造的にはdynamic renderingと同じです。

考え方として、一般的な端末の通常のログアウトユーザーがGooglebotと同じ主要コンテンツやリンクに到達できないなら、クローキングの領域に近づいています。

補足すると、John Muellerは、CDN経由でコンテンツを配信することは通常の配信と本質的に同じだと説明しています。たとえば動画用に別のCDNを使うことはごく一般的です。ユーザーに問題なく届き、コンテンツがインデックス登録のために正しくアクセス可能であれば、Googleの観点でも差し支えありません。問題はCDNそのものではなく、ボットに異なるコンテンツを配信することです。

Dynamic renderingとエッジ事前レンダリング。 Googleはdynamic renderingを非推奨にしています。公式資料では、検索エンジンがJavaScript生成コンテンツを扱う際の回避策であって長期的な解決策ではないとし、代わりにserver-side rendering、static rendering、hydrationを推奨しています。クローラーだけを対象にエッジで事前レンダリングする方法は、dynamic renderingをCDNへ移したにすぎません。JavaScriptサイトの健全な長期策として扱わないでください。全員が受け取る実際のHTMLをエッジで変更する方法はSSRと同等で問題ありませんが、ボット限定の事前レンダリングには非推奨手法と同じ問題が残ります。

その他のリスクとエッジ特有のリスク

WAFとbot blocking（エッジ固有の注意点）。 CDNのsecurity layerはworkerより前に動くため、そこで遮断されたrequestはworkerへ届きません。CloudflareのWAF ruleとAI-bot control（以前の単一の「Block AI Bots」toggleは「Configure AI bot policies」にあるSearch／Agent／Training別のpolicyへ置き換えられましたが、一部accountには従来のtoggleも残ります）は、robots.txtより優先され、Googlebotを含む正規crawlerをnetwork levelで遮断する可能性があります。これはGoogleの2024年12月「Crawling December」guidanceとも一致します。GoogleはCDNを検出するとcrawl rateを自動的に上げますが、WAF ruleやbot interstitialがGooglebotを誤って遮断する場合もあります。一時的に利用できないときはsoftなbot verification interstitialではなく、明示的な503／429を返してください。network timeoutは重大なerrorとして扱われ、長引けばURLが削除される可能性があります。WAF blocklistをGoogle公式のGooglebot IP範囲と定期的に照合し、正規botはreverse DNSで検証します。

単一障害点。 workerは今やすべてのリクエスト経路にあります。バグ1つで全ページが同時に停止する可能性があり、edge環境はoriginのコードよりデバッグしにくい場合があります。route matchingでworkerを特定のURLパターンに限定し、stagingでテストし、ワンクリックのrollbackを用意し、workerをversion controlに入れてリスクを抑えてください。

cacheの落とし穴。 CDNがworker前のresponseをcacheすると、後続requestに未変更版が配信される場合があります。workerの出力自体もcacheされ、反映が遅れることがあります。contentを注入するworkerでは、cache purgeをdeploy手順へ組み込んでください。

実行制限: Cloudflare WorkersのCPU時間上限はプランとリクエストによって異なります。Snippetsにも独自の制限があるため、本文書き換えや大きな表の処理前に現行仕様を確認します。

規模に応じたコスト: 無料枠は小規模サイトに適していても、高トラフィックのエンタープライズではリクエスト量とWorkersの課金を見積もる必要があります。

ガバナンス: Dan Taylorが述べるとおり、エッジSEOは通常の開発実務を回避するためのものではありません。変更管理なしではworkerが既存のデプロイ、キャッシュ、チーム運用と衝突します。

退けるべきいくつかの俗説

• “Cloudflare is bad for SEO.”（日本語訳：CloudflareはSEOに悪い） Dan Taylorはこの誤解を直接取り上げています。CloudflareなどのproviderがSEOに悪いという見方は、経験上正しくありません。GoogleはCDNを検出するとcrawl rateを上げます。riskはCDN自体ではなく、設定を誤ったWAF ruleです。
• “Edge SEO is cloaking.”（日本語訳：Edge SEOはクローキングだ） workerへ入れたlogicがbotへ異なるcontentを返す場合に限ります。全員に同一の変更を行うことはクローキングではありません。
• “You need to code.”（日本語訳：codeを書く必要がある） Cloudflare dashboardではcustom applicationを書かなくても、一般的なredirect、header、security ruleを変更できます。

どの領域に当てはまるか

エッジSEOは、JavaScript SEOやレンダリングに関する問題（エッジで補える場合もあれば、補うべきでない場合もあります）、非推奨になったdynamic rendering、移行時にエッジから返すリダイレクト、挿入できるhreflangとcanonical、書き換えられるrobots.txtとX-Robots-Tagなど、多くの隣接領域に関わります。それぞれは独立した深いテーマですが、エッジSEOの軸は共通です。レスポンスがエッジを出る前に変更し、その変更を全員に適用し、Googlebotにユーザーとは異なるページを決して返さないことです。

AI要約

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

• エッジSEO（serverless SEO） とは、レスポンスがユーザーやクローラーに届く前にCDN／edge worker層で、redirect、canonical、hreflang、robots.txt、X-Robots-Tag、JSON-LD、A/B testなどの技術的SEO変更を行うことです。originやCMSをdeployする必要はありません。
• 目的: 開発queueによる遅れ（SEO上の推奨事項は歴史的に約6か月待つことがありました）を解消し、ShopifyやSalesforce Commerce Cloudのように変更が制限されたplatformを編集します。この用語はDan Taylor（SALT.agency）がTechSEO Boost 2018で提唱しました。
• 動作方法（3段階）: 受信requestを変更（redirect、URL rewrite）→ response headerを変更（X-Robots-Tag、canonical Link）→ response bodyを変更（HTML Rewriterでtag、hreflang、JSON-LDを注入）します。latencyは約10msで、本番では測定できないことも多くあります。
• platform: Cloudflare Workers（最も成熟）とSnippets（軽量）、Akamai EdgeWorkers、Fastly Compute、AWS Lambda@Edge、Vercel／Netlify edgeです。redirect／headerにはSnippets、HTML本文への注入、大規模redirect表、A/B testにはWorkersを使います。
• 厳守事項 — クローキング: Googleにはユーザーと同じcontentを見せます。変更は全員に適用し、Googlebotだけに異なる内容を返してはいけません。ページ分割A/B testは安全ですが、ユーザー分割はクローキングです。
• Dynamic renderingの注意: ボットだけを対象にするedge pre-renderingはdynamic renderingであり、Googleは非推奨としています（“a workaround, not a long-term solution”。日本語訳：回避策であり、長期的な解決策ではない）。JavaScript問題への健全な長期策ではありません。
• エッジ固有の落とし穴: CDNのWAF／AI-bot control（CloudflareのSearch／Agent／Training別policy、または従来の「Block AI Bots」toggle）は、workerが動く前にGooglebotを静かに遮断し、robots.txtより優先される場合があります。blocklistをGoogleのIP範囲と照合し、Googleの2024年12月CDN guidanceに従ってbot interstitialより503を優先します。一方、CDNが検出されるとcrawl rateは上がります。
• 運用上のrisk: 単一障害点になる可能性があるため、scope、version、ワンクリックrollbackを管理します。deploy時のcache purge、CPU制限、規模拡大時の費用、governanceにも注意し、開発チームを関与させ、workerをshadow ITにしないでください。

公式ドキュメント

エッジSEOに直接関係する一次資料です。

Google

• Spam policies — Cloaking — ランキング操作のためにユーザーと検索エンジンへ異なる内容を返す行為、という境界線を示す定義です。
• Dynamic rendering (deprecated) — Googleは現在、“a workaround and not a long-term solution,“（日本語訳：回避策であり、長期的な解決策ではない）とし、代わりにSSR、static rendering、hydrationを推奨しています。エッジ事前レンダリングに直接関係します。
• Crawling December — CDNとクロール（2024年） — CDNはクロール速度を高める一方、WAFやボットルールでGooglebotを遮断する場合があります。soft blockではなく503を優先します。
• Crawling December — HTTP caching (2024) — worker出力をcacheする場合に関係する、cache headerとGooglebotの再取得の関係です。
• Crawling December series overview (2024) — クロール解説シリーズの全資料です。
• AI botをblockする場合のAI bot／Googlebot crawler一覧 — CDNのボットルールを設定するときに、許可すべきGoogle user agentを確認できます。

Cloudflare／Fastly（実装に重要なベンダー資料）

• Cloudflare — SnippetsとWorkersの使い分け — どの作業にどちらのツールが合うかを示す公式説明です。
• Fastly — SEO use cases — リダイレクトとmetadataの実装場所としてedgeを明示するCDNベンダー資料です。

Bing／Microsoft

• Bing Webmaster Guidelines — Bingにはedge固有の指針はありませんが、performance向上のためCDNを推奨しています。
• IndexNow — edge SEOを自然に補完します。workerの変更をdeployした時点で、変更URLをBingへ通知できます。

出典からの引用

エッジSEOに関係する記録済みの発言です。Googleのリンクは引用箇所へ移動する深いリンクです。引用文は原文を保持し、日本語の意味を添えます。

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.” _(翻訳)_日本語訳：クローキングとは、検索順位を操作しユーザーを欺く意図で、ユーザーと検索エンジンに異なるcontentを提示する行為を指す — Google Search Central、Spam policies。 引用箇所へ移動

Google — dynamic renderingの非推奨（エッジ事前レンダリングに関連）

• “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.” _(翻訳)_日本語訳：dynamic renderingは、検索エンジンでJavaScript生成contentを扱う問題への回避策であり、長期的な解決策ではなかった — Google Search Central、Dynamic rendering。 引用箇所へ移動

Dan Taylor、SALT.agency — 「edge SEO」の命名者

• “Edge SEO refers to the technique of implementing SEO recommendations, technical fixes, and navigating platform restrictions through using a serverless application (Cloudflare Workers) on a CDN edge server.” _(翻訳)_日本語訳：Edge SEOとは、CDNのedge server上でserverless application（Cloudflare Workers）を使い、SEO上の推奨事項や技術的修正を実装し、platformの制約を乗り越える手法を指す — Dan Taylor、SALT.agency。出典
• “By using workers, like Cloudflare Workers, we can reduce the obstacles of legacy website platforms and tech stacks, congested development queues, and unhelpful developers.” _(翻訳)_日本語訳：Cloudflare Workersのようなworkerを使うことで、legacy website platformやtech stack、混雑したdevelopment queue、協力を得にくいdeveloperによる障害を減らせる — Dan Taylor、SALT.agency。出典
• “Edge SEO isn’t designed to be a circumvention of traditional development practices.” _(翻訳)_日本語訳：Edge SEOは従来のdevelopment practiceを迂回するためのものではない — Dan Taylor、SALT.agency。出典

SearchPilot — エッジA/Bテスト

• “JetStream sits on the edge without adding new layers to your web stack.” _(翻訳)_日本語訳：JetStreamはweb stackへ新しいlayerを追加せずedge上に置かれる — SearchPilot。出典

Fastly — リダイレクトの場所としてのエッジ

• “Ensuring URLs never die is one of the most important aspects of a good SEO strategy, and the edge is the best place for redirects, so that they can be served as fast as possible.” _(翻訳)_日本語訳：URLが決して消えないようにすることは優れたSEO戦略の最重要事項の1つであり、redirectを可能な限り高速に配信できるedgeが最適な場所である — Fastly。出典

エッジSEOの展開と安全性チェックリスト

workerを有効化する前、実行中、実行後に確認します。

デプロイ前

• その変更が本当にエッジで行うべきものか、originで直すべきものかを確認する（Frameworksタブを参照）。
• SnippetsとWorkersを選ぶ。リダイレクト／headerにはSnippets、本文注入、大規模リダイレクト表、A/BテストにはWorkersを使う。
• 変更がすべてのトラフィックに適用されるようworkerを書く。botだけに異なる内容を返すuser-agent分岐は作らない。
• 既定でサイト全体を対象にせず、route matchingで変更対象のURLパターンを限定する。
• workerをversion controlに入れ、何をなぜ行うかを記録する。
• CDNがworker前とworker後のどちらのレスポンスをcacheするかを決め、cache purgeの手順を追加する。
• 本文を書き換えるworkerでCPU／実行時間制限に達するほどページが大きくないことを確認する。
• stagingでテストし、GSC URL Inspection toolでGooglebotが実際に受け取った出力を確認する。

エッジ固有の安全確認（省略不可）

• CDNのWAF／bot management ruleを監査し、workerが動く前にGooglebot（およびBingbot）が遮断されていないことを確認する。
• CDNのAI-bot controlとbot対策toggleを確認する。Cloudflareでは「Configure AI bot policies」のSearch／Agent／Training設定、または従来の「Block AI Bots」toggleがnetwork levelでrobots.txtより優先されていないかを調べる。
• WAF blocklistをGoogleが公開するGooglebot IP範囲と照合し、正規botをreverse DNSで検証する。
• 意図的に一時停止する場合は、bot verification interstitialではなく明示的な503／429を返す。

クローキング防止策

• botと人間でcanonical／hreflang／title／robotsの出力が同じことを、両方として取得して確認する。
• A/Bテストはユーザー単位ではなくページ単位で分割する。
• クローラーだけにエッジ事前レンダリングを返さない（非推奨のdynamic renderingに当たる）。

公開後

• GSC URL Inspectionで対象URLを再取得し、注入または変更した要素が表示されることを確認する。
• CDN cacheが変更済みのworker後レスポンスを配信していることを確認する。
• ワンクリックで戻せるrollbackを用意し、changelogを更新する。
• 将来のCMS変更と競合せず、originで修正されたときに廃止できるよう、workerが稼働中であることを開発チームへ知らせる。
• Bingへすぐ知らせるべき変更なら、対象URLにIndexNowを送る。

メンタルモデル

1. エッジのレスポンスがページそのものです。 Googleが見るのはCDNが配信する内容だけであり、workerが介在したかどうかは分かりません。そこにedge SEOの力と最大のriskがあります。すべてのworker出力を、文字どおり公開されたpageの真実として扱ってください。

2. エッジかorigin修正かを決める。 変更が阻まれているときはエッジが適します。たとえばShopifyやSalesforce Commerce Cloudのように制限されたプラットフォーム、数か月待ちの開発queue、誰もdeployしない移行redirect map、または今日公開する必要がある修正です。一方、変更が恒久的かつ中核的で、チームが配信できるならoriginで修正します。workerを増やすたびにcritical pathと保守対象が1つ増えるためです。目安は、緊急またはoriginでは不可能な変更はedge、恒久的かつ中核的な変更はoriginです。解決した問題より長く残るworkerはtechnical debtになります。

3. 全員に適用する。そうでなければクローキングです。 問うべきなのは「エッジを使っているか」ではなく、「そのロジックがボットと人に同じコンテンツを配信するか」です。全員に同一の変更を適用するなら安全です。ボット専用の分岐を設けた時点で境界を越えます。迷ったらGoogleの基準で確認してください。ログアウトした通常のユーザーが、Googlebotと同じメインコンテンツとリンクに到達できるでしょうか。

4. ユーザー分割ではなくページ分割。 SEO A/B testでは、各ページをcontrolかvariantへ割り当て、そのページについてGooglebotとすべてのユーザーに同じ版を見せます。ユーザー単位で分割し、botと人へ異なるものを返すのは、experimentを装ったクローキングです。

5. セキュリティ層はworkerより前: CDNのWAFやボットルールでブロックされたリクエストはworkerに届きません。workerやrobots.txtが正しくても、まずGooglebotがファイアウォールを通れることが必要です。

6. SnippetsとWorkersは仕事に合わせる: リダイレクト、ヘッダー、キャッシュのような軽量で状態を持たない処理はSnippets、HTML本文の注入やKVのリダイレクト表のような状態を持つ書き換えはWorkersを選びます。

エッジSEOチートシート

プラットフォーム比較

CloudflareのSnippetsとWorkers — 簡易判断

これはクローキングか？

要点

• 「Edge SEO」という語はDan Taylor（SALT.agency）がTechSEO Boost 2018で提唱しました。
• latencyは通常約10ms、極端な場合でも約50msで、本番では測定可能な変化がないことも多くあります。
• Cloudflare Workersの無料枠は1日10万リクエスト。1リクエストあたりのCPUは 無料10ms／有料は既定30秒（最大5分まで設定可能） です。Cloudflare Snippetsの上限は 5ms／2MB です。
• CDNが検出されるとGooglebotのcrawl rateは上がりますが、AIボット制御を含むWAF／bot ruleが遮断する可能性があります。
• security layerはworkerより前に動くため、WAFをGoogleのIP範囲と照合して監査します。

時間を使う価値のあるリソース

私の関連資料

• Technical SEO初心者向けガイド — 技術的SEO全体の中でedge SEOがどこに位置するかを説明します。
• JavaScript SEOの問題とbest practice — エッジで解決しようとすることが多いrendering側の問題です。
• Technical SEOの調整（Marketing Speak interview） — Cloudflare WorkersとHTML Rewriterを大規模に使う方法について話しています。

Dan Taylor／SALT.agency（この名称を提唱した人々）

• Edge SEO — Dan Taylor — 名付けた本人による標準的な定義です。
• Cloudflare Workersを使うTechnical SEOの詳細 — Igor KrestovとDan Taylor（SALT.agency）がCloudflare blogで説明する、filter chain実装の詳細です。
• Edge SEO webinarのまとめ — governance、risk、use caseを扱います。

エッジA/Bテスト

• Introducing JetStream — SearchPilot — Cloudflare上で行うWASM SEOテストです。
• SEO split testingとは — SearchPilot — ページ分割とユーザー分割の方法論、およびページ分割がクローキングを避けられる理由です。

ベンダーと公式資料

• Cloudflare — Snippets vs Workers。
• Fastly — edgeがSEOを単純化する3つの方法。
• Google — Crawling December: CDNとクロール。

業界の資料

• r/TechSEO — エッジ実装とクローキングの境界事例が議論されています。
• Edge SEOとは — Search Engine Land — 主なuse caseを網羅し、業界全体がこの分野をどう捉えるかを示す堅実な概説です。
• Dan TaylorによるEdge SEO — SEJ（2018年） — 名付けた本人が概念を紹介した当初のSEJ記事です。
• CDNがクロールへ与える影響についてのGoogleの説明 — SEJ — WAF／bot blockingのriskを含む、Googleの2024年12月CDN crawling guidanceの解説です。
• Edge SEO Interview — Conductor — edge SEOが解決する問題についてのDan TaylorへのQ&Aと実務家の引用です。
• Edge SEO完全ガイド — reSignal — Cloudflare、Akamai、Fastlyの実装比較に役立つ、platform別の包括的な説明です。
• Akamai EdgeWorkers use cases — SEOに関係するredirectやmetadataを含む、enterprise edge workerのuse caseを扱うAkamai公式資料です。

変更履歴