Edge SEOとは？ | Search OS

Edge SEOは、オリジンにコードを一切デプロイすることなく、CDNエッジのワーカー層でSEO変更を適用します。
この用語は、2018年のTechSEO BoostカンファレンスでSALT.agencyのDan Taylorによって初めて提唱されました。
これは、リダイレクト、レスポンスヘッダー（X-Robots-Tag、canonical）、meta tagの挿入、hreflang、robots.txt、schema markup、A/Bスプリットテストに使用されます。
特に、ShopifyやSalesforce Commerce Cloudのようにサーバー設定や.htaccessへのアクセスを制限するプラットフォームを回避するのに効果的です。
変更は開発キューなしでほぼ即座にデプロイされ、平均的な追加レイテンシは約10msにとどまりますが、エンジニアリングチームとの連携は不可欠です。

概要

Edge SEOは、Cloudflare Workersのようなサーバーレスのエッジコンピューティング技術を使って、オリジンサーバーやCMSのコードベースに触れることなく、CDNエッジでSEO変更を適用します。重要なのは、CMSやオリジンサーバーがHTMLを生成した後、レスポンスがユーザーに届く前のタイミングでリクエストとレスポンスをインターセプトして書き換えることです。エッジサーバーは世界中に分散配置され、訪問者とオリジンの間に位置するため、変更は開発リリースのサイクルを挟まず、ほぼ即時に反映されます。

この用語は一般に、当時SALT.agencyでtechnical SEOの責任者だったDan Taylorに帰せられており、彼が2018年のTechSEO Boostカンファレンスで紹介しました。その後、SEOエージェンシーDistilledからスピンアウトしたSearchPilotのようなエンタープライズSEOテストツールが、エッジワーカーベースのソリューションを商用化したことで、確立されたtechnical SEOの手法となりました。

解決する課題

Edge SEOが注目されるのは、多くのプラットフォームがSEO作業に必要な設定アクセスを制限しているためです。代表的な制約には次のようなものがあります:

リダイレクトの制限: GitHub PagesはHTMLのmeta refresh経由でしかリダイレクトをサポートせず、古いサーバーではリダイレクトルールの数に上限があることもあります。
設定ファイルのブロック: Shopifyのような多くのホスティング環境では、robots.txtや.htaccessへの直接アクセスができません。
ログアクセスなし: ShopifyやSalesforce Commerce Cloudのようなプラットフォームでは、サーバーログファイルを抽出できません。
開発ボトルネック: すべての変更が開発キューを通過しなければならないため、些細なSEO修正であっても数週間かかることがあります。

オリジン側のこれらの制約とは独立してエッジレイヤーがレスポンスを書き換えられるため、こうした問題すべてを回避する手段になります。

仕組み

Cloudflare Workers では、エッジでの変更は主に3つの段階で発生します:

段階	対象	一般的な用途
受信リクエストを変更	リクエストURLとヘッダー	オリジンへのリクエストURLを書き換える、認証ヘッダーを追加する
送信レスポンスを変更	レスポンスヘッダー	セキュリティヘッダーを追加する、hreflangを挿入する、ログ記録
レスポンス本文を変更	HTML本文	canonical、robots、JSON-LDを挿入または編集する

一般的なユースケース

リダイレクト管理: オリジンがサポートしていない場合でも、エッジで301と302リダイレクトを処理します。大規模環境では、Workers KV に保存された Cuckoo Filter により、効率的なメモリ使用で数万件のリダイレクトを管理できます。
レスポンスヘッダーの制御: サーバー設定に触れずに、X-Robots-Tag、Cache-Control、HSTS、X-Frame-Options などのヘッダーを追加または変更します。
メタタグとcanonicalの挿入: メタタイトル、メタディスクリプション、およびcanonical タグをリアルタイムでHTMLレスポンスに挿入または上書きします。
hreflangの実装: コンテンツが複数のプラットフォームやccTLDにまたがっていても、エッジでhreflangタグを挿入することで、多言語および地域ターゲティングを管理します。
robots.txt およびschemaマークアップ: robots.txtを生成・編集し、直接アクセスをブロックするプラットフォーム上でも、リッチリザルト向けに構造化データを追加します。
スプリットテスト（A/B）: ユーザーに届く前にHTMLを変更し、titleタグなどの要素のバリエーションをテストします。両方のバリアントが同じcanonical URLを共有するため、リンクエクイティが分散されることはありません。

リダイレクト Worker の例

以下は、Cloudflare Workers で特定のパスを301でリダイレクトする簡単な例です。

export default {
  async fetch(request) {
    const url = new URL(request.url);
    if (url.pathname === "/old-page") {
      return Response.redirect(
        "https://example.com/new-page",
        301
      );
    }
    return fetch(request);
  },
};

メリットと制限事項

カテゴリ	詳細
利点	開発リリースなしでほぼ即時に反映でき、追加されるレイテンシーは約10ms程度とごくわずかで、非開発者でも実行でき、プラットフォームやレガシーインフラの制約を回避できる
制限事項	大きなデータではまれに最大50msのレイテンシーが追加されることがあり、エンジニアリングチームと連携せずに行うとデバッグの混乱やバグの原因になる可能性があり、監視すべきレイヤーが1つ増える

根拠

Search Engine Landによると、edge SEOはDan Taylorが2018年にTechSEO Boostで紹介した概念で、平均で約10msのレイテンシーを追加し、まれに大きなデータパケットでは最大50msまで増加することがあります。Cloudflareの公式ブログでは、workerがリクエストヘッダー、レスポンスヘッダー、レスポンス本文の3段階でSEO要素を変更できることが説明されており、hreflang挿入にBoyer-Moore-Horspoolのバイト配列検索を使用した場合、1024バイトのチャンクで毎秒424,948オペレーションを達成したと報告しています。Search Engine Journalは、edge SEOがShopifyやSalesforce Commerce Cloudのログ抽出制限、GitHub Pagesのリダイレクト非対応といったプラットフォーム制約をどのように解決するかを要約しています。

実装チェックリスト

まずエッジで適用する変更（リダイレクト、ヘッダー、メタ、hreflang）を一覧化し、オリジンとの重複や競合の可能性を確認します。
デバッグ時の混乱を避けるため、変更内容は前後ともにエンジニアリングチームと共有します。
A/Bテストを行う際は、両方のバリアントが同じcanonical URLを共有するように設定します。
大規模なリダイレクトは、Workers KVのようなキー・バリュー・ストアで個別に管理します。
エッジworkerが追加するレイテンシーとレスポンスの正確性を定期的に監視します。

Edge SEO

概要

解決する課題

仕組み

一般的なユースケース

リダイレクト Worker の例

メリットと制限事項

根拠

実装チェックリスト

参考文献と出典

関連コンテンツ