AI Overviews、ヘッドレス再構築、次のアルゴリズムアップデートを乗り越えるテクニカルSEO。

テクニカルSEOは、検索エンジンとAIアシスタントがあなたのページをクロール、レンダリング、信頼できるかどうかを決定するレイヤーである——コンテンツやバックリンクが効果を発揮する前に。HTTP動作、HTMLセマンティクス、構造化データ、hreflang、カノニカライゼーション、Core Web Vitals、JavaScriptレンダリングをカバーしている。これを間違えると、残りの投資はすべて無駄になる。

2026年の定義は広がっている。2つの変化がそれを推し進めた。第一に、AI OverviewsとChatGPT搭載検索がほとんどのユーザーと基礎ページの間に位置するようになったため、引用可能性がランキング同じくらい重要になった。第二に、モーダルサイトはもはやWordPressインストール環境ではなく、Sanity、Strapi、Payload、Storyblok、Contentful、またはヘッドレスWordPressバックエンドからコンテンツを取得するヘッドレスフロントエンドの何らかの形態である。これらのスタックはそれぞれ、古いプレイブックではカバーしていないテクニカルSEOの失敗モードをもたらす。

2026年のクライアント向けの実務的な定義: テクニカルSEOは、Lighthouseの実行、Search Consoleのクロールレポート、AI Overview引用チェック、スキーマバリデータの通知——すべてのロケール、すべてのテンプレート、すべてのレンダーパスにわたって——が気付く機能のすべてである。代表的なURLにおいてこれら4つのシグナルのいずれかが失敗している場合、エンゲージメントはそこから始まる。

ヘッドレスまたはJamstackサイトでは、フロントエンドフレームワークがレンダリングを担当し、CMSがコンテンツを担当します。つまり、SEOはその間に落ち込む可能性があります。古典的なWordPress + Yoastモデルは、1つのサーバー、1つのレンダラー、1つのルールエンジンを前提としていました。WordPressからコンテンツをNext.jsやAstroに取り出すと、それらは自動的には何も継承されません。

Next.jsまたはAstroとペアになったヘッドレスWordPress

2026年に私たちが見ている最も一般的な構成：WP RESTまたはWPGraphQLがポストとページを公開し、Next.js App RouterまたはAstroがビルド時またはISRで それらをプルします。メリットは本物です。ページはプラグインの肥大化なしで配信され、Core Web Vitalsは緑を保つのが簡単で、エディターは使い慣れた管理画面を保持します。落とし穴も本物です。Yoastのcanonicalとmeta descriptionはAPI境界を越えて転送される必要があります。WordPressで定義されたリダイレクトはvercel.jsonまたはNetlify _redirectsに配置される必要があります。サイトマップは通常、WordPress側ではなくフロントエンドビルドで再生成される必要があります。Search Consoleの検証はwp-adminドメインではなく公開オリジンで実行される必要があります。

純粋な最新スタック

Next.js + Sanityビルド、Astro + Storyblokビルド、Nuxt + Strapiビルド、Next.js + Payloadビルド — すべてWordPressを完全にスキップします。テクニカルSEOの作業はCMSスキーマがフロントエンドが必要とするSEOフィールド（canonicalオーバーライド、リダイレクトマップ、hrelangグループ、schema-extension JSON）をモデル化していることを確認することに移行します。また、コンテンツが変更されたときにオンデマンド再検証が実行されることを確認します。ISRキャッシュポイズニングは静かな殺し屋です。revalidatePathが接続されなかったため、ページは公開後数時間古い状態で提供されます。

実際に最初に壊れるもの

実施した約200のヘッドレス監査全体で、本番環境を破壊する最も一般的な問題は単一のcanonicalコンフリクトです — フロントエンドが1つのcanonical URLを出力している間、CMSメタデータまたはサイトマップが別のURLを出力しています。Googleはそのうちの1つを選択します。ほぼ確実にあなたが望んだものではなく、間違ったURLがインデックスに登録されます。私たちはこれを、テンプレートから出力されたcanonicalとページのサンプルに対してCMSに保存されたcanonicalを比較し、不一致でビルドを失敗させるビルド時リンターで捉えています。

WordPressはあなたに最も多くのプラグインのファイアパワーと自分自身を撃つ最も多くの方法を与えます。古典的なWordPressサイトのテクニカルSEOプレイブックは、ほとんどの場合減算に関するものです — 重複したcanonicalを削除し、YoastとRankMathとセカンドプラグインの間のスキーマの戦いを消し、2 MBのCSSを配信するページビルダーを制御し、8年間成長したリダイレクトチェーンをクリアします。

2026年に推奨するデフォルトスタック：単一のSEOプラグイン（RankMathまたはYoast、決して両方ではない）、適切なエッジキャッシング（Cloudways、Kinsta、WP Engine）を備えたマネージドホスト、パフォーマンスが重要な新規ビルド用のBricks BuilderまたはネイティブなKadenceまたはBlocksyを備えたGutenberg、ポータブル形式にエクスポートするリダイレクトマネージャー、およびアセットクリーンアップ用のPerfmattersまたはFlyingPress。監査作業は、それらの決定のどれがあなたのサイトで異なる方法で行われたかを見つけ、その結果を解き放つことです。

ヘッドレス側では、作業は減算から構築へシフトします。Yoastがないため、メタタグのクランピングを自分たちで構築する必要があります。プラグインスキーマがないため、JSON-LDをテンプレート化する必要があります。組み込みサイトマップがないため、生成してストリーミングする必要があります。SEOのためにヘッドレスプロジェクトに追加するコードの量は、通常、WordPressサイトが無料で提供しているものの3～5倍です。ただし、そのコードは自分たちが所有し、バージョン管理され、テスト可能であり、次のプラグインアップデートで壊れることはありません。

GEOとAEOは、AI機能が検索トラフィックを奪う2つの異なる方法の名称です。AEO（Answer Engine Optimisation）はより古い用語で、Featured Snippets、People Also Ask、Knowledge Panelsなど、あなたのページから一節を取り出して答えとして表示するGoogleの機能をカバーしています。GEO（Generative Engine Optimisation）はより新しい用語で、AI Overviews、ChatGPT search、Perplexity、Bing Copilotなど、アシスタントが段落を生成してあなたのページを出典として引用する場合に最適化することです。

それが構造的に意味するところ

どちらのサーフェスも同じものを求めています。引用に適した一節です。すべてのサーフェスで機能する構造的ルールは同じです。トピックラベルではなく、質問をH2として使用してください。見出しの直後の1～2文に答えを入れてください。その答えを250語以下に保ってください。答えがサーバーサイドでレンダリングされていることを確認してください。ページロード後にハイドレートするJavaScriptコンポーネントの内部ではなく。AIクローラーとGoogleエクストラクターはほとんどJavaScriptを実行しません。あなたの答えがJSで表示される必要がある場合、あなたは見えません。

GEOがAEOから異なる点

GEO固有には3つのことがより重要です。エンティティオーソリティ――GoogleとLLMsは誰が何について話すことが許可されているかのグラフを構築し、リンクなしブランドメンションがそれに供給します。aboutとmentionsアレイを備えたスキーマ――テキストの壁ではなく、エンティティグラフの一部としてあなたのページを解析可能にします。そしてllms.txt――robots.txtとsitemap.xmlが検索クローラーを支援するのと同じように、AIツールにあなたのサイトのキュレートされたマップを提供する/llms.txtの新興標準ファイル。私たちが構築するすべてのサイトにllms.txtをデプロイし、重大なページが公開されるたびに更新します。

ほとんどのプラグインが出力するよりも少ないスキーマタイプが必要ですが、デプロイするものは有効かつ一貫性がある必要があります。短いリストで、プロジェクトの9割をカバーします。

• Organization――ロゴ、sameAs（実際のソーシャルアカウントのみ）、住所、contactPointを備えたレイアウト内の単一のサイト全体グラフ。ページごとに複製しないでください。
• WebSite — レイアウト内で1度だけ、オンサイト検索がある場合はサイトリンク検索の potentialAction を含める。
• BreadcrumbList — すべての非ホームページに、ロケール正確な URL を含める（フランス語ページは /en/ ではなく /fr/ の祖先を指す必要がある）。
• Article または BlogPosting — 長文コンテンツに、エンティティグラフ強化のための about および mentions 配列を含める。
• Service — 商用ページに、serviceType、provider、areaServed、audience、および価格帯を公開できる場合は offers.priceSpecification を含める。
• Product — eコマース上に、offers.priceCurrency、availability、および実際のレビューがある場合のみ aggregateRating を含める。
• FAQPage — ページに少なくとも2つの本物の質問がある場合。スキーママークアップで勝つためにFAQをでっち上げるのは、当社が削除する最も一般的なマニュアルアクション トリガーである。
• LocalBusiness またはそのサブタイプ — 物理的位置情報ページに、地理座標と openingHoursSpecification を含める。

本番環境でスキーマを破壊する3つのこと。schema.org で定義されていないプロパティを発明する。sameAs の値を発明する（偽のLinkedIn URL、放棄されたTwitterハンドル）。複数プラグインから競合する Organization グラフを配信する。ビルド リンターでスキーマ バリデーターを実行し、これら3つのパターンのいずれかで ビルドを失敗させる。

Hreflang はスケーリング時に失敗する。制約が双方向で、データセットが疎だからだ。ページのすべてのロケール バリアントは自己参照し、他のすべてのバリアントを参照し、他のすべてのバリアントから逆参照される必要がある。1つのロケール内の1つのページで1つの方向を欠いたら、Google は無言でクラスターをダウングレードする。

スケールするパターン

すべての翻訳可能な行に content_group_id（またはそれに相当するもの）を保存する。ページのすべてのロケール バリアントは 1 つの ID を共有する。hreflang エミッター、サイトマップ エミッター、カノニカル エミッターはすべてそのIDからクラスターを導出する。URLパターンマッチングだけからhreflangを計算しない。エッジケースで崩壊する（ヒンディー語翻訳がないスペイン語ページは、コードが「ページXがロケールAに存在すればロケールBにも存在する」と仮定する場合、クラスターを分割してしまう）。

実際にhreflangを殺すもの

繰り返し見られる3つのパターン。ロケール正規表現の順序付け — ロケール検出正規表現で「zh」を「zh-Hant」の前に置くことで、間違ったロケールをキャプチャして壊れたhreflangを書き込む。x-defaultの忘却 — すべてのクラスターには x-default フォールバック（通常は英語版を指す）が必要。クラスター ID ドリフト — 翻訳がソース ID を継承する代わりに新しい ID を取得し、単一クラスターが無関係な2つに静かに分割される。どちらも完全な相互参照セットを持たない。

ビルド時 hreflang リンターを常に追加する。ページのサンプルをクロールし、参照するhreflangクラスターをウォークスルーし、クラスターが不完全または非対称の場合はビルドを失敗させる。

プログラマティック SEO は、構造化データソースとテンプレートから数千ページを生成する — ディレクトリ、比較ページ、ロケーションページ、用語集ページ。正しく実行すれば、単一著者のコンテンツが対応できないスケールでロングテールに到達できる。間違うとマニュアルアクションがトリガーされ、インデックスされたページのほとんどが一晩で削除される。

クリーンなプログラマティック ビルドとシン コンテンツの区別

3つのこと。ページごとの実データ — すべての URL には、それに固有の事実、数字、または詳細が少なくとも1つある。シン プログラマティック ページはコンテンツの95%を共有する。意味のあるテンプレート — テンプレートは、検索最適化されたラッパーではなく、ユニークなデータの周りにコンテキスト、比較、推奨、または集約を追加する。そして品質ゲーティング — ユニークデータが不十分なページはサイトマップから除外され、インデックスからブロックされるか、データレイヤーが入力されるまでドラフト状態で保持される。

スケールでこれを実行してから学んだこと

HostList.ioをプログラマティックSEOプラットフォームとして構築しました。Next.jsとSupabaseで約28,000個のウェブホスティング企業ページを運用しています。2年間のGoogleアップデートを生き残ったページは、URL当たり最低3つの独自データポイントを持ち、さらにそのデータに基づいて比較、スコアリング、または推奨を行うテンプレートを備えたものでした。インデックスから削除されたページは、独自データが名前と価格だけのものでした。シンページをインデックスから削除するコストは小さかったのですが、それらを放置しておくコストは2024年3月のヘルプフルコンテンツアップデートが実施された時点でのサイト全体のランキングペナルティでした。

このオペレーティングプレイブックをクライアントのプログラマティックビルドにもたらしています。Next.jsまたはAstroフロントエンド、SupabaseまたはPostgresデータ、公開前にページをユニーク性でスコアリングするインジェストパイプライン、50,000以上のURLが単一のsitemap.xmlに収まらないため複数チャンクでストリーミングするサイトマップ、そしてすべてのリーフページをトピッククラスターに引き込む内部リンクグラフです。

Core Web Vitalsに合格するには、制御されたLighthouse実行ではなく、フィールドデータの75パーセンタイルで合格する必要があります。CrUXからのフィールドデータはGoogleが使用するもので、Lighthouseはデバッグツールです。実際のサイトでは、この2つがしばしば30%以上異なります。

予算が実際に使われる場所

LCPはほぼ常にヒーロー画像であり、ほぼ常にWebPに80%品質で再エンコードする、実際の表示寸法プラス2倍のRetina対応サイズにサイズ変更する、headにpreloadタグを追加する、そしてfetchpriority="high"を設定することで解決されます。1MBのヒーロー画像が30KBのWebPになることは、ほとんどのプロジェクトで最も影響度の高い変更です。CLSは明示的な寸法がない画像と広告から発生します。すべての画像に明示的なwidthとheight属性を指定する、固定高さの広告スロット、そしてクライアント側ウィジェット用に予約済みスペースを確保します。INPはインタラクション時の重いJavaScriptから発生します。通常はサードパーティのタグマネージャーまたは過剰に熱心なアナリティクスライブラリです。対策はデバウンス、遅延読み込み、またはより軽量な同等のものへの置き換えです。

ほとんどのプロジェクトが見落とすところ

2つのパターンです。1つ目は、CarouselコンポーネントまたはJavaScript駆動レイアウト内のLCP画像です。画像はJSが実行された後にのみレンダリングされ、LCPはカルーセルの読み込みスケルトンになり、写真ではありません。2つ目は、font-display: swapなしと preloadなしで読み込まれたウェブフォントです。フォントがダウンロードされる間、テキストが200～400ミリ秒間見えなくなり、画像が高速でもLCPが2.5秒のしきい値を超えます。どちらも単一のLighthouse実行ではなく、CrUXフィールドデータレビューで検出されます。

ビルド時SEOリンターは、ビルドの終了時に実行されるスクリプトで、出力ディレクトリからレンダリングされたHTMLファイルのスライスをサンプリングし、本番環境でSEOを低下させるパターンが見つかった場合にビルドを失敗させます。これはクライアントコードベースに追加する最も影響度の高い習慣です。

当社のチェック項目

• すべてのページに H1 タグが正確に 1 つ存在する。
• インデックス対象のすべての URL に対して、メタディスクリプションが 120～155 文字である。
• html lang 属性がロケールパスと一致している（/fr/ ページは lang="fr"）。
• 翻訳可能なルートで hreflang クラスタが完全かつ双方向である。
• すべてのページの JSON-LD が schema.org の定義に対して有効である。
• 禁止されたコンテンツパターンがない — sameAs 内のフェイクソーシャル URL、ハードコードされたテスト用プレースホルダーテキスト、禁止されたジェネリックコピーライティング単語。
• テンプレートから出力される Canonical URL が CMS に保存されている Canonical と一致している。
• テンプレートのサンプルに対して Image WebP と明示的なディメンション（寸法）がチェックされている。

Linter は npm run build の最後のステップとして実行される。違反がある場合、ビルドが失敗し、デプロイが失敗する。Linter がなければ、すべての回帰 — メタディスクリプションが制限を超えた、SEO フィールドが設定されていなかった、プロパティ名が変更されたときにスキーマエミッターが壊れた — がサイレントにシップされる。これがあれば、回帰は開発者のノートパソコンを出る前にキャッチされる。

すべての関連ページを引用可能な段落のスタックとして書くことで引用されます。引用可能な段落とは、質問形式のH2見出し、その直後の直接的な1～2文の回答、次の100～200語のサポート情報、そして回答ブロック内にJavaScriptレンダリングされたコンテンツがないものです。AI抽出器はその冒頭の文を抜き出して引用します。

段落構造以外に役立つもの

• エンティティオーソリティ — Wikipedia上の存在、一貫したorganisationスキーマ、実在するsameAsアカウント、オープンウェブ全体でのブランドメンション。
• サイトルートのllms.txt — 従来のクローラーに提供するrobots.txtとsitemap.xmlとは別の、AIツール向けのサイトマップ。
• 長文コンテンツ上のaboutとmentionsを含むスキーマ — ページが属するエンティティグラフを宣言します。
• AIクローラー向けrobots.txtの許可リスト — GPTBot、PerplexityBot、ClaudeBot、OAI-SearchBot、Google-Extended、Applebot-Extended、CCBot、Anthropic-AIを明示的に許可します。これらのいずれかをブロックすることは自ら招く引用停止です。
• 長文ページの回答が豊富なセクションのSpeakableスキーマプロパティ — これは音声およびAI抽出器に対して、ここが引用可能な段落であることを示唆します。

引用の追跡はほとんどのチームがスキップする部分です。Otterly、Profound、AthenaHQはドメイン別のAIオーバービューとPerplexity引用シェアを追跡します。われわれはすべてのエンゲージメントの上に週次の引用追跡を加え、オーガニックトラフィックと並行して報告します。引用を測定していない場合、GEOのワークがなにかを実現しているかどうか判断することはできません。

AIクローラーがあなたのサイトを読み取るには、robots.txtがそのユーザーエージェントを明示的に許可し、かつホスティングレイヤーがネットワークエッジで彼らをブロックしていない必要があります。両方のチェックに合格する必要があります。デフォルトのCloudflare設定、デフォルトのVercel WAFルール、デフォルトのWordPress セキュリティプラグインは、警告なしにAIボットをルーチン的にブロックします。

当社が提供するrobots.txtのホワイトリスト

ChatGPTおよびOpenAI検索製品向けのGPTBot、ChatGPT-User、OAI-SearchBot。PerplexityBotおよびPerplexity-User。ClaudeBot、Claude-Web、anthropic-ai。BardおよびAI Overviews向けのGoogle-Extended。Applebot-Extended。多くのオープンソースモデルに供給するCommon Crawl向けのCCBot。Cohere-AI。Meta-ExternalAgent。Bytespider（TikTokのクローラー）— 通常はブロックされます。これは攻撃的であり、ほとんどのプロジェクトはTikTokに彼らのコンテンツをリフティングされたくないからです。

あなたがしなければならないその他のこと

Robots.txtは必要ですが十分ではありません。3つの追加チェックがあります。Cloudflare bot fight modeおよびbot management — AIエージェントをブロックするものをオフにするか、IPおよびユーザーエージェントでホワイトリストに登録してください。Vercel WAFおよびEdge Middleware — AIユーザーエージェントに一般的な正規表現でマッチしていないことを確認してください。WordfenceのようなWordPressセキュリティプラグイン — これらはデフォルトでGPTBotおよびPerplexityBotをブロックするルールを搭載していることが多いため、明示的にホワイトリストに登録してください。各ユーザーエージェントを3つの代表的なURLに対してcurlでテストし、200レスポンスを確認してください。

UK 政府デジタルサービス標準および GOV.UK デザインシステムに準拠した技術 SEO 基盤を構築します。GDS サービス標準は、公開されている最も厳密に文書化されたデジタルサービス品質原則です。段階的な強化、WCAG 2.2 AA へのアクセシビリティ、パフォーマンス、セマンティック HTML、JavaScript 障害時の優雅なフォールバックです。Seahawk の技術 SEO 業務のすべてで、この標準に従っています。Government Digital Service Standard and the GOV.UK Design System. The GDS Service Standard is the most rigorously documented set of digital-service quality principles in the public domain: progressive enhancement, accessibility to WCAG 2.2 AA, performance, semantic HTML, and graceful degradation when JavaScript fails. We follow it on every Seahawk technical SEO engagement.

SEO にとって重要な理由：GDS に準拠したサイトは Core Web Vitals を一貫して合格し、クラシック有機検索でも順位が高く、AI Overview の引用に特に適しています。GDS が求める構造的明確性が、AI が表面データから抽出する構造的明確性と同じだからです。この標準は AI 検索時代より前に存在していますが、それに完全に適合しています。

UK エンタープライズ、公共部門、規制対象産業のクライアントにとって、GDS 準拠は実質的な調達シグナルです。その他の場合、より低い基準で納品する代理店と異なる品質マーカーです。

3～10 週間、3 フェーズ、固定価格です。フェーズ 1 は監査で、完全クロール、GSC と Ahrefs レビュー、JSON-LD バリデーション、hreflang クラスター確認、Core Web Vitals フィールドデータ取得、AI 引用ベースラインです。フェーズ 2 は修正で、当社またはあなたのチームが修正を展開します。フェーズ 3 は回帰を防ぐリンターと監視層です。

監査フェーズの成果物

• Screaming Frog の完全クロールを CSV で出力し、重要度でランク付けした問題に関する書面による要約。
• Search Console エクスポート（カバレッジレポート、クエリ、ページレベルのパフォーマンス）と異常な点に関する注釈。
• テンプレートのサンプルに対するスキーマバリデーターパス、および破損または欠落しているすべてのタイプに関する書面での注釈。
• 翻訳可能なルートに関するHreflangクラスタ整合性レポート。
• CrUXからのCore Web Vitalsフィールドデータ取得、メトリクスごとの過去25週間のチャート付き。
• AI OverviewとPerplexity引用ベースライン — 現在のシェア、名指しされた3つの競合他社に対するギャップ分析。

改善フェーズ

固定スコープの作業。各チケットは明確なビフォー状態とアフター状態を持っています。優先度順に納品し、予算が尽きたら任意のマイルストーンで契約を終了できます。最初に納品するバッチは常にビルドリンターに失敗する項目です。リンターなしで継続的に回帰するため最短で価値を提供でき、リンターが導入されればすべての修正が維持されます。

監視フェーズ

ステージングと本番環境での週次自動リンティング、月次のCore Web Vitalsレポート、月次のAI引用追跡、およびGoogleやあなたのチームがフラグを立てたものに対応する常時稼働のSlackチャネル。クローズ時にダッシュボードを引き継ぐため、更新するかどうかに関係なく可視性を保つことができます。