2021年に、あるクライアントから慌てた電話をもらった。彼らはHeadless Contentfulとその前面をNext.jsで、4,200個の商品ページをリローンチしていた。そのエージェンシーは彼らにこう売り込んでいた：モダンなスタック、超高速、Googleは気に入るだろう、と。ローンチから6週間で、オーガニックトラフィックは61%減少していた。クロールエラーではない。手動ペナルティでもない。ただ消えていた。
重要なポイント：ヘッドレス化はデフォルトではSEO問題を解決しません。クライアント側レンダリング、メタデータ転送の欠落、プレビューURLがインデックスに流出することから、クロールの破損が生じます。
同じパターンを何度も見てきた。そして、フラストレーションを感じるのは、SSRは技術的には機能していたということだ。ページはサーバーで描画されていた。HTMLが返されていた。しかし、全体が静かに崩壊していた約7つの他の場所があり、誰もそれをチェックしようとは思わなかった。
これはヘッドレスが良いか悪いかについての投稿ではない。明らかに素晴らしいことができる。ヘッドレススタックのSSRがSEOで失敗する具体的で解決可能な方法と、実際にあなたが何をするべきかについてだ。
---
SSRがヘッドレスSEOを自動的に修正するという神話
ここまでのところだ。2016～2018年頃にクライアント側レンダリングが主流になったとき、SEOコミュニティは集団で大騒ぎした（正当な理由で）。Googleのクローラーは JavaScript実行に対して一貫性がなく、コンテンツはインデックスされないままになり、SPA サイトはランキングを失血していた。だから業界は SSR を特効薬として猛烈に推し進めた。
そして SSR は純粋な CSR より確かに良い。だが「良い」というのは「解決した」という意味ではない。
SSRはレンダリングの問題を解決する。キャッシュ戦略、クロールバジェット、カノニカルの混乱、またはCMSとHTML <head> 間のメタデータパイプラインについては、ほぼ何もしない。これらはまったく別の失敗モードだ。そしてヘッドレスアーキテクチャでは、CMSとフロントエンドフレームワークという少なくとも2つのシステムが何をするかに同意する必要がある。
多くの場合、彼らは合意しない。
---
ヘッドレススタックで SSR が実際に SEO を破壊する場所
Time-to-First-Byte の問題
SSR は、あなたのサーバーが高速な場合のみ高速だ。ヘッドレスセットアップでは、Next.js や Nuxt サーバーは応答する前に CMS API からコンテンツを取得しなければならない。Contentful（もしくは Sanity、Storyblok、あるいは他のいずれか）が遅い瞬間を経験している場合、TTFB は急上昇する。設定が悪い SSR セットアップで CMS API コールドスタート中に TTFB が3秒を超えるスパイクを見たことがある。
Google は TTFB をクロール予定のシグナルとして使う。遅い応答は Googlebot がセッションごとに少ないページ数をクロールすることを意味する。大規模なカタログサイトでは、それは直接、クロール待機キューに数週間留まるページに翻訳される。
実行時に生成されるカノニカルタグ
これは人々を驚かせる。WordPressのようなトラディショナルCMSではカノニカルタグはテーマまたはSEOプラグインに組み込まれている。ヘッドレスセットアップでは、あなたのカノニカルロジックはフロントエンドコード、おそらくNext.js <Head> コンポーネント、またはレイアウトラッパーに存在する。CMSはあなたがレンダリングしているカノニカルについて知らない。
それでは、商品URLにソートやフィルタリングのクエリパラメータがある場合はどうなるか？または、CMSが返すページスラッグがルーティングロジックと少し異なる場合？カノニカルタグが間違ったURLを指すか、まったく欠落している状態になる。昨年、Seahawkの英国の小売業者向けプロジェクトでこれを見つけた。800ページはカノニカルが/?page=1を指していた。ページネーションロジックがSEOコンポーネントに間違ったプロップを渡していたからだ。見つけるのに2日かかった。修正に3行。
フォールバックのないメタデータパイプライン
すべてのHeadless CMSではSEOメタデータフィールド、メタタイトル、説明、OGタグを追加できる。素晴らしい。しかし、エディターがページを公開してそれを入力するのを忘れた場合はどうなるか？YoastのあるWordPressなら、生成されたフォールバックが得られる。ヘッドレスセットアップでは、フロントエンドコンポーネントに明示的なフォールバックロジックがない場合、空の <title> タグが得られる。あるいはさらに悪いことに、生のフィールド名がHTMLにエコーされる。
フォールバックチェーンを明示的に常に構築せよ：seoTitle ?? pageTitle ?? siteName。すべてのフィールド。例外なし。
ここがスキーマ駆動型CMSの真価を発揮するところです。Sanityでは、SEOフィールド（メタタイトル、canonical、hreflang、構造化データ）がコンテンツモデルの型付きプロパティであり、ページエディタに後から付け足したボックスではありません。フォールバックチェーンはスキーマに一度だけ存在し、すべてのフロントエンドコンポーネントで再実装する必要がなく、GROQクエリはテンプレートが必要とするフィールドをきっちり返してくれるので、過剰取得もなければCMSの疎な応答をパースする必要もありません。メタデータパイプラインがより信頼性高くなります。なぜなら、真実の源がそれを消費するコードではなく、コンテンツモデルだからです。最近クライアント向けにこれをリリースしたのですが、このセクションで説明しているランタイムバグの一つのクラス全体が削除されました。
---
だれもが十分に考えないキャッシング層
Next.jsのISR、Incremental Static Regenerationは本当に賢い。ほぼ静的パフォーマンスを得て、スケジュールで再検証する機能が得られる。しかしSEOでは、再検証ウィンドウは実際の影響を持つ決定だ。
revalidate: 3600（1時間）に設定すると、コンテンツの編集は公開後1時間までGooglebotに認識されない。ブログには十分だ。ニュースサイトやフラッシュセールのeコマースページには災難だ。クライアントが4時間の期限付きセールを実施したが、割引キャンペーン計画時にISRウィンドウについて誰も考えていなかったため、45分間キャッシュされた「売切れ」ページが表示されていた。
修正は常に「より積極的に再検証する」ではない。より頻繁な再検証はより多くのオリジンロードを意味する。実際の修正はオンデマンド再検証で、コンテンツ公開時にCMS Webhookからキャッシュパージをトリガーする。Next.jsはv12.2以降オンデマンドISRをサポートしている。Contentful、Sanity、Storyblokはすべて発信Webhookをサポートしている。それらを接続する。約1日かかる。
---
クロールバジェットとヘッドレスURL表面
トラディショナルCMSプラットフォームはURL、タクソノミー、ページネーション、アーカイブのカノニカルハンドリングの周りに何年もの慣例がある。ヘッドレスセットアップはあなたに完全な自由を与える。つまり、あなたはコード内でそのすべての決定を自分で下す必要があるということだ。
注意を払わないときの自由は危険だ。
ヘッドレスプロダクトカタログでファセット絞り込みを使うと、/products?colour=red&size=M&sort=price-asc のような数万単位のユニークなURLとそのすべての組み合わせが簡単に生成されます。SSR層がそれらすべてをユニークなHTMLでレンダリングし、ベースURLへのcanonicalがなければ、Googlebotに無限の迷路を渡してしまうことになります。
ヘッドレスビルドのたびに私が実装するいくつかのことがある:
- robots.txtでSEO的に重要でないクエリパラメータURLをすべてブロック
- フィルター済みおよびソート済みのすべてのバリアントに対して、クリーンなベースURLを指す単一の正規化を実装
- 小規模サイトではページ2以降のページネーションページに<meta name="robots" content="noindex, follow">を使用
- XMLサイトマップをGooglebotが実際にクロールしているもの（Google Search Consoleのカバレッジレポート経由）と照らし合わせてください。最初のパスでこの2つが同じことはめったにありません。
サイトマップは静的にビルド時に生成するのではなく、CMSから動的に生成してください。最後のデプロイ時点のコンテンツだけを反映したサイトマップは、デプロイ間に編集者が40ページ新しく公開した場合、役に立たなくなります。
---
構造化データのギャップ
ヘッドレスCMSは構造化されたコンテンツで優れています。スキーマ、フィールドタイプ、参照など、SanityとContentfulはどちらもデータをうまくモデル化します。しかしSEO向けの構造化データ（JSON-LDスキーマ、Product、Article、BreadcrumbListなど）はまったく別の話です。
私が監査したヘッドレスフロントエンドのセットアップの多くは、JSON-LD がまったくないか、レイアウトに付け足された単一の汎用 WebSite スキーマしかありません。これは見逃しです。商品ページでは、CMS から取得したライブの価格、在庫状況、レビューデータを含む Product スキーマが必要です。レシピページやハウツーページでは、適切なスキーマは Google のリッチリザルトに直接影響を与える可能性があります。
実装は複雑ではありません。Next.js では、JSON-LD を <Head> 内の <script type="application/ld+json"> タグに入れて、ページプロパティから値を入力し、Google の Rich Results Test でテストするだけです。複雑なのは、CMS のコンテンツモデルがフロントエンドが利用すべき適切なフィールドを提供するようにすることです。これは開発チケットではなく、コンテンツアーキテクチャに関する話し合いです。
---
メタデータパイプライン全体の修正
私がヘッドレス SEO 監査のたびに実行する正確なチェックリストをお見せします。概念的なものではなく、実際のステップです。
- レンダリングされたHTMLを検証します。curl -A "Googlebot" [your URL]を使い、生のレスポンスを調べてください。<head>に実際に何が含まれていますか？ブラウザがハイドレーション後に表示するものではなく、生のサーバーレスポンスです。
- ランダムに選んだ20ページでcanonicalの正確性をチェックしてください。特にパラメータ付きのプロダクト・カテゴリページです。サイトが大きい場合は、node-fetchを使った小さなスクリプトを作成して、大規模にcanonicalをプルして解析してください。
- 3つの拠点からTTFBをテストします。ロンドン、フランクフルト、バージニアからGooglebot UAでWebPageTestを使っています。どの拠点でも800msを超えて一貫している場合は、他の何かをする前にCMS APIのレスポンスタイムを調べてください。
- サイトマップをGSCと照らし合わせてください。Search Consoleからカバレッジレポートをエクスポートしてください。サイトマップ内の「有効」なURLをあなたのサイトマップと比較します。サイトマップに含まれていても「除外」されているURLは調査が必要です。
- 重複した<title>と<meta description>タグをチェックしてください。レイアウトコンポーネントとページレベルコンポーネントの両方がメタデータを書き込もうとする場合に、予想以上に起こります。
- オンデマンド再バリデーションをエンドツーエンドでテストしてください。CMSでコンテンツ変更を公開します。サーバーレンダリングページに反映されるまでどのくらい時間がかかりますか？ 時間単位で計測される場合は、webhookをセットアップしてください。
- 構造化データは代表的なページタイプ（Product、Article、FAQ は最低限）で検証する。Google の Rich Results Test を使用して、ローカルではなくライブ URL で実施する。
---
私が実際に使うツール
理論的なリストではない。これは私がヘッドレスSEOの修正に取り組んでいるときにマシン上で開いているツールだ。
- Screaming Frog でライブサイトをレンダリングモードで クロールして、Googlebot が見ているものを確認する。まずレンダリングモードを「None」に設定して生の SSR 出力を確認し、その後「JavaScript」モードと比較する。
- WebPageTest で TTFB、サーバーレスポンスのウォーターフォール、CDN エッジのヒット/ミスヘッダーを確認する。
- Google Search Console の Coverage レポート、特定ページの URL Inspection、ページタイプ別の Core Web Vitals を確認する。
- Postman または `curl` で CMS API に手動でクエリを実行し、SSR レイヤーに実際に返されているデータを確認する。
- Next.js のビルトインログ機能。見過ごされることが多いが、ステージング監査中に詳細ログを有効にすると、レンダーがどこで待機しているかが明確になる。
率直に言うと、Screaming Frog だけから見える headless SEO の問題は、私が見つけるもののうち 80% を占める（何を探すべきか知っていれば）。
---
FAQ
Next.js と SSR で SEO が必ずうまくいくのか？
いいえ。SSR はサーバー上で HTML をレンダリングしてからクライアントに届けることを意味しており、これは必要条件ですが十分条件ではありません。正しい canonical タグ、適切な sitemap、正確なメタデータ、構造化データ、高速なサーバーレスポンスタイムが必要です。SSR は JavaScript レンダリングの問題を解決します。アーキテクチャの問題は解決しません。
SEO の観点では Contentful は Sanity より優れているのか？
どちらの CMS も直接 SEO に影響しません。ヘッドレスだからです。レンダリングされた HTML に何の意見も持ちません。問題は、どちらが SEO 関連のコンテンツフィールドのモデリングをより簡単にするかです。両方とも SEO フィールドプラグインがあります。Sanity の GROQ クエリ言語は、フロントエンドが必要とする正確なデータを成形する際に、より高い柔軟性を提供し、クリーンなメタデータパイプラインを構築しやすくなります。ただし、これは SEO の議論ではなく、開発者体験の議論です。
ヘッドレスセットアップでhreflangをどう処理しますか？
メタデータを処理する方法は他と同じです。CMS データからサーバー側で生成して、すべてのページの <head> に挿入します。複雑さはロケールから URL へのマッピングを CMS で管理し、フロントエンドが正しく使用することにあります。Next.js を使用している場合、i18n の設定がルーティング側の多くを処理します。ただし、コンテンツデータから <link rel="alternate" hreflang="..."> タグを明示的にレンダリングする必要があります。
SEOを向上させるためにSSRの代わりにSSGを使うべきですか？
コンテンツの更新頻度による。完全な静的生成（SSG）は最速の TTFB を提供し、デプロイ時にすべてが事前構築されますが、ISR を使用していない限りコンテンツ更新はデプロイ時にのみ反映されます。ほぼ静的なマーケティングサイトの場合、オンデマンド ISR による SSG がおそらく適切です。インベントリ変更が頻繁な大規模カタログの場合、短期間のキャッシュヘッダーと積極的な CDN キャッシングを伴う SSR がより適切です。
---
不快な真実ですが、ヘッドレススタックは、これまでのCMSアーキテクチャよりも、SEOに関する責任を開発者の手に委ねるものです。インストールして対応するプラグインは存在しません。正規URL のロジックからサイトマップ生成、構造化データまで、すべての決定はコードの決定です。つまり、それらの決定はすべて間違う可能性があり、ほとんどのチームはランキングが既に悪い方向に動くまで、それらを監査しません。
先手を打ちましょう。Googlebotがするのと同じようにあなた自身のサイトをクロールしてください。問題はほぼ常にGoogleが見つける前に見つけることができます。