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

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

2026年、その定義は拡張している。2つの変化がそれを推し進めた。第一に、AI OverviewsとChatGPT搭載の検索が現在ほとんどのユーザーと根本的なページの間に位置しており、これはランキングと同じくらい引用準備が重要であることを意味する。第二に、モーダルサイトはもはやWordPressインストールではなく、Sanity、Strapi、Payload、Storyblok、Contentful、またはヘッドレスWordPressバックエンドからコンテンツを取得するヘッドレスフロントエンドの何らかのフレーバーである。これらのスタックのそれぞれは、古いプレイブックでカバーされていない独自の技術SEO障害モードを導入している。

2026年のクライアント向けの実用的な定義：Technical SEOは、Lighthouseの実行、Search Consoleのクロールレポート、AI Overviewの引用チェック、およびスキーマ検証ツールが通知するもののすべてであり、すべてのロケール、すべてのテンプレート、すべてのレンダリングパスにわたっている。これら4つのシグナルのいずれかが代表的なURLで失敗している場合、エンゲージメントはそこから始まる。

ヘッドレスまたは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のカノニカルメタディスクリプションはAPI境界を横切って転送される必要がある。WordPressで定義されたリダイレクトはvercel.jsonまたはNetlify _redirectsに着地する必要がある。サイトマップは通常、WordPressサイドではなくフロントエンドビルド上で再生成される必要がある。Search Consoleの検証はwp-adminドメインではなく公開オリジンで行われる必要がある。

純粋な最新スタック

Next.js + Sanityビルド、Astro + Storyblokビルド、Nuxt + Strapiビルド、Next.js + Payloadビルドは、すべてWordPressを完全にスキップしている。Technical SEOの作業は、CMSスキーマがフロントエンドが必要とするSEOフィールド（カノニカルオーバーライド、リダイレクトマップ、hreflanggループ、スキーマ拡張JSON）をモデル化することを確認すること、およびコンテンツが変更されたときにオンデマンド再検証がトリガーされることを確認することに移行する。ISRキャッシュポイズニングはサイレントキラーであり、revalidatePathが決してワイアされなかったため、公開後に数時間、ページが古い状態で提供される。

実際に最初に壊れるもの

約200のヘッドレス監査を実施した結果、本番環境を破壊する最も一般的な問題は正規URLの競合であり、フロントエンドが1つの正規URLを出力しながら、CMSメタデータまたはサイトマップが別の正規URLを出力している。Googleは1つを選択し、ほぼ常にあなたが望んでいないもの、そして間違ったURLがインデックスで終わる。テンプレートから出力されたカノニカルとCMSに保存されたカノニカルをページのサンプルで比較し、不一致でビルドを失敗させるビルド時リンターでこれをキャッチしている。

WordPressは最もプラグインの火力と、自分自身を撃つ最もの方法をあなたに与える。古典的なWordPressサイト上の技術SEOプレイブックは主に減算に関するものであり、重複した正規化を除去し、YoastとRankMathと誰も覚えていないインストールした第三のプラグインの間のスキーマファイトを殺し、2MBの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、/llms.txtの新興標準ファイルで、AIツールに対してあなたのサイトのキュレートされたマップを提供します。これはrobots.txtとsitemap.xmlが検索クローラーを支援するのと同じ方法です。私たちはビルドするすべてのサイトにllms.txtをデプロイし、主要なページがランドするたびに更新します。

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

• Organization、レイアウト内の単一のサイト全体グラフ、ロゴ、sameAs（実在するソーシャルアカウントのみ）、住所、contactPoint。これをページごとに複製しないでください。
• WebSite、レイアウト内で1回、オンサイト検索がある場合のsitelinks検索用の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を計算しないこと。エッジケースで破綻する（ヒンディー語翻訳がないスペイン語ページがある場合、「ロケールAにpageXが存在すればロケールBにも存在する」と仮定するコードはクラスターを分割してしまう）。

実際にhreflangを殺すもの

繰り返し見られる3つのパターン。ロケール正規表現の順序付け。「zh-Hant」の前に「zh」を置くとロケール検出で間違ったロケールをキャプチャして破損したhreflangを出力する。x-defaultの忘却。すべてのクラスターにはx-defaultフォールバックが必要であり、通常は英語版を指す。クラスターIDのドリフト。翻訳が新しいIDを取得して元のIDを継承せず、静かに1つのクラスターを関連のない2つに分割してしまい、どちらも完全な相互参照セットを持たない。

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

プログラマティックSEOは構造化データソースとテンプレート、ディレクトリ、比較ページ、ロケーションページ、用語集ページから数千のページを生成する。正しく行えば単一著者のコンテンツでは対応できないロングテールをスケールで獲得できる。誤れば手動アクションをトリガーしてインデックス済みページのほとんどを一夜にして削除される。

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

3つのこと。ページごとの実データ。すべてのURLは少なくとも1つの事実、数値、またはそのURLに固有の詳細を持つ。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%への再エンコード、実際の表示寸法プラス2xレティナへのサイジング、ヘッド内のプリロードタグ追加、fetchpriority="high"の設定で解決される。1 MBのヒーロー画像が30 KBのWebPになることがほとんどのプロジェクトで最も高い影響を与える変更である。CLSは明示的な寸法のない画像と広告から生じる。すべての画像に明示的なwidthとheight属性、固定高さ広告スロット、クライアント側ウィジェット向けの予約スペース。INPは相互作用の重いJavaScriptから生じ、通常はサードパーティのタグマネージャーまたは過熱気味のアナリティクスライブラリ。修正はデバウンス、遅延ロード、またはより軽い相当品への置き換え。

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

2つのパターン。第1に、CarouselコンポーネントまたはJavaScriptドリブンレイアウト内のLCP画像。画像はJSが実行された後にのみレンダリングされ、LCPはキャリオセルのローディングスケルトンであって写真ではない。第2に、font-display: swapなくプリロードなしでロードされたウェブフォント。フォントダウンロード中200～400ミリ秒テキストが見えず、LCPが画像は高速であってもしきい値の2.5秒を超えて押し出される。両方ともCrUXフィールドデータレビューで検出され、単一のLighthouseランではない。

ビルド時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 と明示的なディメンション（寸法）がチェックされている。

リンターはnpm run buildの最後のステップとして実行される。違反があるとビルドが失敗し、デプロイが失敗する。リンターがないと、すべてのリグレッション、上限を超えたメタディスクリプション、SEOフィールドの設定忘れ、プロパティ名変更で破損したスキーマエミッターが静かに出荷される。リンターがあると、回帰は開発者のノートパソコンを離れる前にキャッチされる。

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

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

• エンティティオーソリティ、Wikipedia上での存在、一貫したorganisation schema、実際のsameAsアカウント、オープンウェブ全体でのブランド言及。
• サイトルートのllms.txt、AI ツール向けのサイトの厳選されたマップ、従来のクローラーに対応するrobots.txtとsitemap.xmlとは別。
• 長文コンテンツ上のaboutおよびmentionsを含むSchema、ページが位置するエンティティグラフを宣言。
• AI クローラーrobots.txt許可リスト、GPTBot、PerplexityBot、ClaudeBot、OAI-SearchBot、Google-Extended、Applebot-Extended、CCBot、Anthropic-AIを明示的に許可。これらのいずれかをブロックするのは自己招来の引用停止。
• 長文ページの回答豊富なセクション上のSpeakable schemaプロパティ、これがcitable pasageであることをvoiceおよびAI抽出器へのヒント。

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

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

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

ChatGPTおよびOpenAI検索製品向けのGPTBot、ChatGPT-User、OAI-SearchBot。Perplexity-UserおよびPerplexityBot。Claude-WebおよびClaudeBot、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 とuser-agentでホワイトリストに登録。Vercel WAFおよびEdge Middleware、汎用regexでAI user agentにマッチしないか確認。3つの代表的なURLに対して各user agentでcurlをテストし、200レスポンスを確認することで検証。

UK 政府デジタルサービス標準および GOV.UK デザインシステムに準拠した技術 SEO 基盤を構築します。GDS サービス標準は、公開されている最も厳密に文書化されたデジタルサービス品質原則です。段階的な強化、WCAG 2.2 AA へのアクセシビリティ、パフォーマンス、セマンティック HTML、JavaScript 障害時の優雅なフォールバックです。Seahawk の技術 SEO 業務のすべてで、この標準に従っています。

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

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

3～10週間、3フェーズ、固定価格。フェーズ1は監査、完全クロール、GSCおよびAhrefs確認、JSON-LD検証、hreflag クラスターチェック、Core Web Vitals フィールドデータ取得、AI引用ベースライン。フェーズ2は修復、修正をリリース、貴社チームまたは当社。フェーズ3はリグレッション防止のLinterおよび監視レイヤー。

監査フェーズの成果物

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

改善フェーズ

固定スコープの作業です。各チケットには明確な変更前の状態と変更後の状態があります。優先順位順に納品でき、予算が尽きたら任意のマイルストーンで契約を終了できます。最初に納品するバッチは常にビルドリンターで失敗するアイテムです。リンターがなければ常に退行するため価値提供までの道のりが最短で、リンターを導入すればすべての修正が定着します。

監視フェーズ

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