ヘッドレス移行後にトラフィックが落ちる理由と、それを防ぐ方法
クライアントサイドレンダリング、落ちた canonical、遅いオリジン。ヘッドレス移行が静かにオーガニックトラフィックを失わせる 3 つの道筋と、それぞれをどう閉じるか。
ヘッドレス CMS は、あなたの HTML について何の意見も持ちません。コンテンツを API 経由で返すだけで、検索エンジンが見るものはすべてあなたが書いたコードが生成します。
だからこそ、「ヘッドレスは SEO に悪いのか？」というのは間違った問いです。正しい問いはこうです。再構築は HTML の何を変えたのか？ 実際のところ、答えは 3 つのうちのどれかであり、3 つとも修復可能です。
リーク 1 — JavaScript 実行後にしか存在しないコンテンツ
最もよくあり、最も高くつくものです。
サーバーレンダリングを備えたフレームワークに移行し、その後チュートリアルがそうしていたからという理由で、記事本文をクライアントの effect で取得してしまいました。その結果:
- Googlebot は初回は空の殻を受け取り、レンダリングは後回しにキューに入ります—時にはずっと後に。
- 他のクローラー（Bing、AI クローラー、ソーシャルプレビューのボット）はそもそもほとんどレンダリングしません。リンクは空白で展開されます。
- Largest Contentful Paint は コンテンツ を測定しますが、あなたのコンテンツは殻の 1 往復後に到着します。
診断 — コマンド 1 つ、ツール不要:
0 は、コンテンツが HTML にないことを意味します。これが 1 を返すまでは、この記事の他のすべては二の次です。
修正 — サーバーで取得します。Next.js App Router ではそれがデフォルトです。よくあるミスは、'use client' 境界をツリーの高い位置に置いてしまうことです。ページ全体を包むのではなく、インタラクティブなコンポーネントまで下げてください。
リーク 2 — 再構築で失われた canonical、meta、構造化データ
旧い CMS には、すべてのページに canonical タグ、meta description、Open Graph タグ、Article スキーマを生成する SEO プラグインがありました。誰も明示的にそれを削除しようとは決めませんでした。ただ、再構築のチェックリストになかっただけです。
症状: 重複コンテンツのクラスタリング（パラメータ URL、末尾スラッシュのバリエーション、ページネーションされたアーカイブがすべて別々にインデックスされる）、リッチリザルトの欠如、そして間違ったタイトルで展開されるソーシャルシェア。
修正 — これらのフィールドをテーマではなくコンテンツモデルの一部にします。corpusctl では SEO モジュールがエントリごとのタイトル、description、canonical、ソーシャル画像をコンテンツと並べて保存するので、それをレンダリングするものに存在するのではなく、エントリと共に移動します。
そして CI でそれらを検証します。代表的な 10 の URL を取得し、それぞれに自己参照の canonical が正確に 1 つ、155 文字未満の空でない description、そして有効な JSON-LD があるかをチェックするテストは 1 時間で済み、この種のリグレッションを永続的に捕捉します。
リーク 3 — 考えてこなかったキャッシュの背後にある遅いオリジン
ヘッドレスは通常、パフォーマンスを向上させます。悪化させるのは、フロントエンドがリクエストごとに CMS から取得し、その CMS がデータベースクエリ 1 回分離れているときです。