ブラウザでは正常に見えるのに、ページが検索結果へ出ない。新しいページへの内部リンクがGoogleに発見されない。このような問題は、JavaScript実行後にだけ本文やリンクが現れるサイトで起こり得ます。
JavaScript SEO監査の結論は、画面を目視するだけでなく、①サーバーが返す初期HTML、②JavaScript実行後のHTML、③Googleが取得した状態、④実際のインデックス結果を同じURLで比較することです。本記事では、差分の取得、原因の切り分け、SSR・SSG・CSRの選択、修正後の検証までを7ステップで整理します。SEO担当者と開発担当者が、修正対象と優先順位を共通の証拠で決められるようになります。
JavaScript SEO監査では4つの状態を比較する
JavaScript SEO監査では、「ユーザーに見えるか」だけで合否を決めません。サーバー応答、ブラウザでの描画、Googleの取得結果、検索インデックスという4つの状態を比較し、どこで情報が失われたかを特定します。
Google Search Centralは、JavaScriptページをクロール、レンダリング、インデックスの3段階で処理すると説明しています。Googlebotは最初のHTMLからリンクを抽出し、レンダリング後のHTMLからも内容とリンクを抽出します。そのため、初期HTMLに主要情報がなくても必ず失敗するわけではありません。一方で、JavaScriptやAPIのエラー、robots.txtによるリソース遮断、ユーザー操作が必要な表示は、レンダリング後にも残らない可能性があります。
| 比較する状態 | 確認するもの | 主な取得方法 | 差が示す問題 |
|---|---|---|---|
| 初期HTML | 本文、title、canonical、robots、href | curl、ブラウザのソース表示 | JavaScriptへの依存範囲 |
| レンダリング後HTML | 実行後の本文、リンク、構造化データ | Chrome DevTools、レンダリング対応クローラー | JS・API・遅延表示の失敗 |
| Google取得状態 | クロール済みHTML、スクリーンショット、取得エラー | Search ConsoleのURL検査 | Google環境固有の差 |
| インデックス結果 | 登録可否、選択canonical、検索上の表示 | URL検査、ページのインデックス登録 | 技術要因と品質要因の最終結果 |
ブラウザの目視だけでなく、同じURLの4つの状態を保存して比較すると、情報が失われた段階を切り分けられます。
重要なのは、差分があること自体を直ちに不合格にしないことです。広告、チャット、計測タグなど、検索に不要な要素の差は低優先です。H1、主要本文、商品・サービス情報、内部リンク、canonical、robots、構造化データの差を優先して確認します。
監査前に対象URLと合格条件を決める
全URLを無差別に確認するより、テンプレートと重要度で層別化して代表URLを選ぶ方が、短時間で再現性の高い監査になります。少なくとも、トップ、カテゴリ、詳細、記事、検索・絞り込み、404の各テンプレートから正常系と例外系を選びます。
監査表には、URL、ページ種別、想定ステータスコード、インデックス可否、正規URL、主要本文、必須内部リンク、構造化データ種別を記録します。ECサイトなら、在庫あり・在庫なし、ページネーション、絞り込み条件も分けます。SPAなら、直リンクで開いた場合と、画面内遷移で開いた場合を比較してください。
合格条件は「表示された」ではなく、次のように証拠へ落とします。
- 主要本文がレンダリング後HTMLに存在する
- インデックス対象URLがHTTP 200を返す
- 移動・削除・エラーURLが意図した3xx・4xxを返す
- 重要ページへのリンクが`<a href=”…”>`として抽出できる
- title、canonical、robotsの初期値と実行後の値が矛盾しない
- Search ConsoleのURL検査で必要なリソースが読み込まれる
- 公開URLとGoogleが選択したcanonicalが意図どおり一致する
JavaScript SEO監査を7ステップで実行する
監査は、発見、取得、レンダリング、インデックスの順に進めます。後工程だけを見ると、原因がJavaScriptなのか、canonicalや品質評価なのかを切り分けにくくなるためです。
取得前の条件確認から始め、レンダリング差分、Googleの取得結果、修正後の再検査へ進むことで原因の混同を防ぎます。
STEP1｜HTTP応答とクロール可否を確認する
最初に、対象URLのHTTPステータス、リダイレクト、robots.txt、robots meta、X-Robots-Tagを確認します。Googleは通常、HTTP 200のページをレンダリング対象へ送ります。CSRのエラーページが常に200を返すと、soft 404として扱われる可能性があります。
また、JavaScriptやCSSのURLをrobots.txtで遮断すると、Googleがページを正しく再現できません。HTML本体だけでなく、主要なJS、CSS、APIの応答も確認します。認証、Cookie、Local Storage、WebSocketなどに依存しないと主要本文が出ない設計も要注意です。
STEP2｜初期HTMLに何があるか取得する
curlや「ページのソースを表示」で、JavaScript実行前のHTMLを保存します。本文文字列、H1、title、meta description、canonical、robots、構造化データ、主要リンクを抽出してください。
この工程の目的は、CSRを一律に否定することではありません。検索に不可欠な情報のうち、何がレンダリングへ依存しているかを可視化することです。売上や問い合わせに直結するページほど、主要本文と発見経路を初期HTMLへ含める設計が安全です。
STEP3｜レンダリング後HTMLとの差分を取る
ヘッドレスブラウザやJavaScriptレンダリング対応クローラーで、実行後のDOMを取得します。初期HTMLと比較し、追加・削除・書き換えを分類します。
| 差分 | 主な原因候補 | 判定 |
|---|---|---|
| 本文が追加されない | API失敗、例外、タイムアウト、認証依存 | 重大 |
| SSR本文が実行後に消える | hydration不整合、クライアント側の上書き | 重大 |
| canonicalが別URLへ変わる | ルーターやhead管理の競合 | 重大 |
| 主要リンクがクリック後だけ現れる | イベント・スクロール依存 | 重大 |
| 構造化データの値が本文と不一致 | データ取得時点やテンプレートの差 | 高 |
| 広告やチャットだけが増える | 補助機能 | 低 |
差分比較はDOM全体の行数ではなく、検索に必要な要素単位で行います。日時、セッションID、計測属性などの変動値を除外すると、回帰テストへ再利用しやすくなります。
STEP4｜内部リンクとURL発見を確認する
Googleが確実に解析しやすいリンクは、`href`属性を持つ`<a>`要素です。`onclick`だけの要素、ボタンだけの画面遷移、`href`のないアンカーは、重要URLの発見経路として扱わない方が安全です。
初期HTMLクロールとレンダリング後クロールを別々に行い、発見URL数とリンク元数を比較します。XMLサイトマップにあるのに内部リンクから到達できないURL、レンダリング後にしか発見できない重要URL、ユーザー操作後にだけ現れるリンクを抽出します。
SPAでは、各画面に固有のURLを与え、フラグメントだけで本文を切り替える設計を避けます。History APIを利用しても、最終的なリンク要素には通常のURLを持つ`href`が必要です。また、そのURLへ直接アクセスした場合にも、同じ主要内容と正しいステータスコードが返ることを確認します。
STEP5｜遅延表示、メタ情報、構造化データを検査する
スクロール、クリック、タブ切り替え、同意操作の後に初めて読み込まれる主要本文は、Googleが取得できない可能性があります。画像の遅延読み込みと、本文・リンクの遅延生成は分けて評価してください。検索に必要な本文や一覧へのページネーションは、操作なしで到達できる形にします。
title、meta description、canonical、robotsは、初期HTMLとレンダリング後HTMLの両方で確認します。特に、初期HTMLの`noindex`をJavaScriptで削除する方法は避けます。Googleは`noindex`を確認するとレンダリングを省略する場合があり、削除処理が実行されない可能性があるためです。
STEP6｜Googleの取得結果とインデックスを照合する
Search ConsoleのURL検査で、登録済みの状態とライブテストを確認します。クロール可否、取得結果、インデックス可否、Googleが選択したcanonical、レンダリング済みHTML、スクリーンショット、読み込めなかったリソースを記録します。
ただし、ライブテストの合格はインデックス登録を保証しません。ライブテストは現在の取得可能性を確認するもので、重複、品質、サイト全体の評価など、登録時の全条件を判定するものではないからです。重要テンプレートごとに「技術的に取得可能」「実際に登録済み」を分けて管理します。
STEP7｜修正後に同じ条件で再検査する
修正前後でURL、ユーザーエージェント、端末、待機条件、Cookie状態をそろえます。初期HTML、レンダリング後HTML、抽出リンク、HTTP応答、Search Consoleの結果を再取得し、重大差分が解消したことを確認します。
公開後は、テンプレート単位の自動テストへ組み込みます。主要本文の文字列、canonical、robots、HTTPステータス、必須リンクが失われた場合に、リリース前または直後に検知できる状態が理想です。
原因別に修正方法を選ぶ
すべてのJavaScriptサイトをSSRへ移行する必要はありません。ページの更新頻度、公開範囲、個別URLの必要性、障害時の影響を基準に、ルート単位でSSR、SSG、CSRを選びます。
| 状態 | 第一候補 | 理由・注意点 |
|---|---|---|
| 公開記事・サービスページ | SSGまたはSSR | 主要情報とリンクを初期HTMLで返しやすい |
| 頻繁に変わる公開商品ページ | SSRまたは再生成型の静的出力 | 鮮度と取得安定性を両立しやすい |
| ログイン後の管理画面 | CSR | 通常は検索対象外で、操作性を優先できる |
| 既存CSRをすぐ移行できない | 一時的なプリレンダリング | 同等内容を返し、恒久策の期限を決める |
| JS実行後にSSR本文が消える | hydration修正 | レンダリング方式の変更前に不整合を直す |
検索流入の必要性と更新頻度を基準に、ページやルートごとにレンダリング方式を選びます。
Googleは、クローラー向けに別HTMLを返す動的レンダリングを回避策と位置付け、長期的な解決策としては推奨していません。新規開発や大規模改修では、サーバーサイドレンダリング、静的レンダリング、hydrationなどを検討します。
一方、検索不要の管理画面までSSRにする必要はありません。公開URLのうち、検索流入を獲得するページと、そこへつながるリンクを優先します。
修正優先順位は影響範囲と再現性で決める
優先順位は、個別URLの順位ではなく、テンプレートの影響範囲、検索に必要な要素、発生頻度、修正難易度で決めます。同じ不具合が数千URLへ展開されるテンプレート問題は、単一ページの表示崩れより先に対応します。
| 優先度 | 状態 | 対応例 |
|---|---|---|
| P0 | 主要テンプレートの本文が取得不能、誤noindex、重大な5xx | リリース停止、即時ロールバック |
| P1 | canonical競合、重要リンク消失、soft 404の大量発生 | 次回リリースを待たず修正 |
| P2 | 構造化データ欠落、補助本文の遅延表示、少数URLの差 | スプリント内で修正 |
| P3 | 検索に不要な装飾差分、低重要URLの軽微な差 | 記録して定期改修 |
影響URLが多く、主要本文やインデックス制御へ影響する不具合ほど優先して修正します。
担当分担も明確にします。SEO担当者は対象URL、期待値、検索影響を定義し、開発担当者は再現条件と技術原因を記録します。QA担当者は同一条件で再検査し、承認者が公開可否を判断します。「GooglebotはJavaScriptを実行できる」という説明だけで閉じず、対象URLの取得証拠を完了条件にしてください。
JavaScript SEO監査チェックリスト
次の項目をテンプレートごとに確認すると、監査漏れを抑えられます。
- [ ] インデックス対象URLがHTTP 200を返す
- [ ] エラーURLが意図した4xxを返す
- [ ] 主要なJS・CSS・APIがGooglebotから取得可能である
- [ ] 初期HTMLと実行後HTMLの主要本文を比較した
- [ ] H1、title、canonical、robotsの差を比較した
- [ ] 重要リンクが`<a href>`として存在する
- [ ] 直接アクセスと画面内遷移で同じ主要内容が出る
- [ ] クリックやスクロールなしで主要本文とリンクを取得できる
- [ ] Search Consoleでレンダリング済みHTMLを確認した
- [ ] Googleが選択したcanonicalを確認した
- [ ] 実際のインデックス結果とライブテストを分けて記録した
- [ ] 修正前後を同じ条件で再検査した
- [ ] 代表URLの検査をデプロイ後の回帰確認へ組み込んだ
まとめ
JavaScript SEO監査では、初期HTML、レンダリング後HTML、Googleの取得状態、インデックス結果を同じURLで比較します。重点項目は、主要本文、`<a href>`による内部リンク、HTTPステータス、canonical、robots、遅延表示です。
このテーマの全体像や前提を確認したい場合は、「テクニカルSEOとは？クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト」もあわせて確認してください。
まず代表URLをテンプレート別に選び、7ステップで差分を取得してください。問題が見つかったら、ページの公開性と更新頻度に応じてSSR・SSG・CSRを使い分けます。修正完了はブラウザの目視ではなく、同一条件での再取得とSearch Consoleの実測で判定します。これにより、SEO担当者と開発担当者が推測ではなく証拠で優先順位を決められます。
参考文献・データ元
- Google Search Central「Understand the JavaScript SEO basics」（2026年3月4日更新）https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics — クロール・レンダリング・インデックスの処理、リンク抽出、canonical、robots、ステータスコードの確認に使用。
- Google Search Central「Fix Search-Related JavaScript Problems」（2025年12月10日更新）https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript — URL検査、レンダリング環境、リソース取得とデバッグ条件の確認に使用。
- Google Search Central「SEO Link Best Practices for Google」https://developers.google.com/search/docs/crawling-indexing/links-crawlable — `a`要素と`href`属性を用いたクロール可能なリンクの条件確認に使用。
- Google Search Central「Dynamic Rendering as a workaround」（2025年12月10日更新）https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering — 動的レンダリングの位置付けと代替方式の確認に使用。
- Google Search Console ヘルプ「URL Inspection tool」https://support.google.com/webmasters/answer/9012289 — 登録済みURL、ライブテスト、レンダリング結果の確認範囲に使用。