JavaScript で描画するページが検索結果に出ない時、最初に疑うべきは順位要因ではありません。まず確認すべきなのは、Google がそのページを評価する前提条件を満たしているかどうかです。画面上では完成して見えていても、Googlebot が受け取った HTML に本文、見出し、正規 URL、インデックス可否の指示が揃っていなければ、内容の良し悪しを判断する前の段階で止まります。
実務では、公開後 14 日以内に「検索に出ない」と相談される JavaScript 案件の多くを、本文の弱さではなく取得経路の不整合で説明できます。SPA、ヘッドレス CMS、一覧を後から読み込む商品ページ、フォーム完了後に本文を描画する LP は、いずれも同じ落とし穴にはまりやすい構造です。この記事では、Google のクロールとインデックス登録、インデックス登録の考え方、JavaScript SEO の基本に沿って、JavaScriptレンダリングでインデックスされない時に、どこから疑い、何を優先し、どの粒度で修正指示に落とし込むべきかを 6 手順で整理します。
順位改善より先に取得可否を疑うべき明確な理由
JavaScriptレンダリングでインデックスされない時、最初に確認すべきなのは本文改善ではなく、HTTP 応答とレンダリング後 HTMLです。ここを飛ばしてタイトルや見出しを書き直しても、Googlebot が必要な情報を受け取れていなければ結果は動きません。Google は クロールとインデックス登録 の流れの中でページを取得し、必要に応じて JavaScript を処理し、その時点で得られた情報を基に登録可否を判断します。つまり、検索に出るかどうかは「本文が良いか」より前に、「本文を取得できるか」で決まります。
公開後 14 日以内、管理 URL が 500 以下、かつ新規公開ページが中心の案件では、次の順番を崩さないでください。
- URL が `200`、`404`、`410` のどれを返しているかを確定する
- レンダリング後 HTML に `title`、`h1`、本文冒頭 200 文字前後があるか確認する
- `canonical` が自己参照か、意図した統合先だけを指しているかを見る
- `meta robots` と robots.txt が衝突していないか確かめる
- ここまで通ってから、本文、内部リンク、見出し構成の評価に進む
この順番を守る理由は単純です。インデックス未登録の初期段階では、評価の議論より取得の議論の方が再現性を持ちやすいからです。JavaScript SEO の基本でも、Google は JavaScript を扱える一方で、ブロックされた資産や不完全な出力を前提に、自動で不足分を補ってくれるわけではないと示されています。主要本文が API 応答待ちで空のまま返っている、認証付き API に依存している、初期 HTML に `noindex` が残っている。どれか 1 つでもあれば、見た目が整っていても取得には失敗します。
例外もあります。 すでに Search Console でインデックス済みになっており、表示回数も継続して出ているのに順位だけが弱い場合は、取得ではなく内容評価や内部リンク設計から入るべきです。反対に、`site:` でほとんど拾われず、ページのインデックス登録レポートでも未登録理由がまとまっているなら、内容改善を先に進めるのは遠回りになります。JavaScript 案件ほど、順番を誤ると一か月単位で無駄が出ます。
Search Consoleで最初の30分を使い切る確認手順
JavaScriptレンダリングでインデックスされない時、最初の 30 分は Search Console に集中してください。 ここで全体像がつかめないなら、調査の深さではなく見方がずれています。使う画面は 2 つで足ります。全体傾向は ページのインデックス登録レポート、個別 URL の実態は URL 検査ツール です。Search Console を送信ボタンとしてしか使わない運用では、JavaScript 案件の切り分けにほとんど役立ちません。まずは状態を見極める道具として使う前提に切り替えましょう。
確認する順番を固定すると、調査は速くなります。最初の 10 分でページのインデックス登録レポートを開き、件数が多い未登録理由を 2 つに絞って拾います。ここで理由が `Blocked by robots.txt` なのか、`クロール済み - インデックス未登録` なのか、`検出 - インデックス未登録` なのかで、調査の入口は変わります。次の 10 分で代表 URL を 5 本選び、最後の 10 分で URL 検査に入り、登録済み情報とライブテストの差を見ます。これで十分です。最初から 50 URL を目で追う必要はありません。
画面 | 30分で確認すること | この画面で出す結論 | 見落としやすい点 |
|---|---|---|---|
ページのインデックス登録レポート | 未登録理由の上位 2 件、件数が大きいテンプレート | 共通不具合か、個別事故か | 少数 URL の例外に引っ張られやすい |
URL 検査の登録済み情報 | Google が採用した `canonical`、最終クロール時点の状態 | 過去の時点で何を見ていたか | 最新デプロイが反映済みとは限らない |
URL 検査のライブテスト | 現在の応答、レンダリング後 HTML、ヘッダー | 今この瞬間に取得できるか | 合格してもインデックス登録は保証されない |
代表 URL の選び方にも基準が必要です。公開 7 日以内なら、トップページではなく未登録が多いテンプレートから 5 本選んでください。 管理 URL が 50 未満なら、その 5 本で足ります。管理 URL が 50 から 500 なら、一覧、詳細、絞り込み、記事ページのように、テンプレートごとに 2 から 3 本ずつ見る方が正確です。管理 URL が 500 を超える場合は、個別 URL 調査から入るべきではありません。まず未登録理由の上位 2 件に対し、テンプレート単位の不具合を仮説として置く必要があります。
Search Console の使い方そのものは、Googleインデックス登録を早めたいときの実務手順。Search Consoleを道具として使い切る でも詳しく触れています。JavaScript 案件では、この考え方がさらに重要です。送信して待つのではなく、状態を切り分けてから送ること。順序を逆にしないのが、最短で原因に近づく方法です。
ライブテストと登録済み情報を必ず並べる理由
JavaScriptレンダリングでインデックスされない時、ライブテストだけで安心してはいけません。登録済み情報と同じ URL で並べてこそ、どこが壊れていたかが見えてきます。 ライブテストは「今の状態」、登録済み情報は「Google が前回採用した状態」です。この 2 つが一致していなければ、修正すべき箇所はかなり絞れます。
URL 検査ツール では、取得したページの HTML、HTTP ヘッダー、読み込み資産、JavaScript コンソールを確認できます。ここで見るべきなのは、スクリーンショットの見栄えではありません。合否は HTML とヘッダーで判断してください。 画面が崩れていても HTML に本文が入っていれば、インデックスは進む場合があります。反対に、画面上に文字が見えていても HTML に本文が存在しなければ、その見た目は SEO の根拠になりません。
最低限、次の 5 点は毎回確認しましょう。
- レンダリング後 HTML に `h1` と本文冒頭 200 から 300 文字が入っている
- `title` と `meta description` がテンプレート流用ではなく URL 固有になっている
- `canonical` が自己参照か、統合先として妥当な 1 本だけを指している
- `meta robots` に `noindex` や意図しない `nofollow` が混ざっていない
- コンソールに API 失敗、資産取得失敗、認証失敗が出ていない
ここで差が出た時の判断も明確にしておく必要があります。ライブでは本文があるのに登録済み情報の HTML が薄いなら、今は直っていても、Google が見た時点では壊れていたと判断します。この場合は内容改善へ進まず、デプロイ時刻、障害ログ、キャッシュ更新、`canonical` の誤配信を先に見直してください。逆に、ライブでも登録済みでも本文が空に近いなら、問題は現在進行形です。描画をユーザー操作や API 応答に依存させすぎています。
特に注意したいのが、主要本文をタブ開閉やクリック後にだけ出す実装です。モバイル ファースト インデックスに関するベスト プラクティス でも、主要コンテンツをユーザー操作前提にしない方がよいと示されています。記事本文、商品説明、FAQ 回答、価格、申込条件のような中核情報は、初回 HTML か、自動で取得できる形で返すべきです。ここを「あとで出るから問題ない」と扱うと、JavaScriptレンダリングでインデックスされない状態が長引きます。
レンダリング不良と正規化ミスを先に切り分ける
JavaScript 案件の未登録は、レンダリングの失敗だけでなく、正規 URL の整理ミスでも起こります。 この 2 つを一緒に扱うと、修正指示がぶれます。Googlebot が本文を取れていないのか、取れているものの別 URL を正規と見なしているのか。最初にこの切り分けをしてください。前者は HTML 出力と応答、後者は `canonical`、重複 URL、内部リンク、パラメータ設計の問題です。
Google は robots.txt の概要 と robots.txt ファイルの作成と送信 で、robots.txt はクロール制御のためのものだと示しています。また、noindex を使用してページを検索インデックスから除外 では、`noindex` を効かせるには Googlebot がそのページを取得できる必要があると分かります。さらに 重複した URL の正規化 と 重複 URL の統合 を読むと、正規化の中心は `canonical` であり、robots や `noindex` を代用品にすべきではありません。ここは迷わず整理したい領域です。
制御手段 | 何に使うべきか | 効く条件 | 使うべきでない場面 |
|---|---|---|---|
`robots.txt` | 不要なクロール経路を減らす | Googlebot が取得前に経路を判断する時 | 正規 URL の統合、検索結果からの除外 |
`noindex` | 検索結果に出したくない URL を除外する | ページが取得可能であること | robots で止めた URL、正規化の代用 |
`rel="canonical"` | 近い内容の URL を 1 本へ寄せる | 内容差が小さく、統合先が明確なこと | 内容差の大きい別ページの強引な統合 |
強く勧めたいのは、パラメータ付き URL や並び替え URL が増えているなら、最初に内部リンクの揺れを止めることです。`canonical` を正しく置いても、内部リンクが毎回別 URL を指していれば、Google に余計な候補を渡し続けます。正規 URL に評価を集める考え方は、内部リンク最適化の2026年実務 回遊を増やすだけで終わらない評価配分の考え方 と、アンカーテキスト最適化の最新実務 2025年更新ガイダンスから逆算する内部リンク設計 でも押さえておきたい論点です。
もう一つ、存在しない URL を `200` で返す実装は避けてください。JavaScript 側で「該当データなし」と表示しても、HTTP レベルで `404` か `410` を返さなければ、`soft 404` や薄いページの量産につながります。商品詳細や記事詳細で存在確認を後段の API に任せているなら、今すぐ見直すべきです。 URL 数が 1,000 を超えると、この設計の粗さが未登録件数として一気に表面化します。
実装チームへ返す修正指示の優先順位を固める
原因が見えた後に重要なのは、何を直すかより、どの順番で直すかを固定することです。JavaScriptレンダリングでインデックスされない案件は、修正対象を一度に広げると、どこで改善したのか分からなくなります。実装チームへ返す指示は、Googlebot が見る順に並べてください。
最優先で直すべきなのは、初回 HTML に主要情報を出すことです。`title`、`h1`、本文導入、正規 URL、`meta robots` が初回出力にないなら、そこから手を付ける必要があります。次に、主要本文の読み込みをクリック依存、スクロール依存、認証依存にしないこと。その後に、存在しない URL の `404` / `410` 制御、モバイル版と PC 版の差分解消、サイトマップの正規 URL 化へ進みます。順番を逆にして、先にサイトマップだけ送るのは避けてください。 サイトマップは補助にはなりますが、構造の不整合を打ち消す手段ではありません。サイトマップの概要 と サイトマップの作成と送信 を見ても、送信はあくまでヒントだと分かります。
実装方式 | 最初に選ぶ条件 | 推奨度 | 主な注意点 |
|---|---|---|---|
SSR | 管理 URL 500 以下、主要本文が毎回必要、公開直後の回復を急ぐ | 最優先 | サーバー負荷とキャッシュ設計を同時に整える |
事前描画 | 更新頻度が日次以下、LP や記事中心、公開 URL が読みやすい | 高い | 更新時の再生成漏れを監視する |
クライアント描画のみ | 会員画面や個別最適化が中心で、検索流入を狙わない | 限定的 | 公開ページでは原則避ける |
月間 PV 10 万未満、管理 URL 500 以下なら、公開ページは SSR か事前描画へ寄せるべきです。 クライアント描画だけで押し切る選択は、初動復旧の負担が大きすぎます。例外は、会員専用ダッシュボードや認証必須の画面のように、そもそもインデックス対象ではないページだけです。公開ページをクライアント描画のまま維持する合理性は、かなり限られます。
実装側へ返すチェックリストは、次の粒度まで落とし込んでください。
- レンダリング後 HTML に本文導入 200 文字前後が存在する
- `title`、`h1`、`canonical` が URL ごとに固有である
- `meta robots` に想定外の `noindex` が混ざっていない
- 存在しない URL は `200` ではなく `404` か `410` を返す
- モバイル版と PC 版で本文量と構造化データが揃っている
- CSS、JS、API が robots.txt で誤って止まっていない
- サイトマップには正規 URL だけを載せている
- 修正後に代表 URL 5 本でライブテストと登録済み情報の差を確認する
この形で返せば、開発、編集、QA が同じ基準を持てます。社内で判断が割れやすい案件ほど、抽象論ではなく HTML 差分の事実で会話した方が早く進みます。JPSM SEO 編集事業部でも、初回診断では代表 URL の差分表を先に作り、その後で改修優先度を決めています。
サイト規模ごとに変えるべき調査の優先順位
JavaScriptレンダリングでインデックスされない時、対処の入口は全サイト共通です。ただし、優先順位は規模に応じて変える必要があります。 小規模サイトと大規模サイトで同じ調査手順を回すと、どちらも無駄が増えます。重要なのは、どこまでを人が見て、どこからをテンプレート単位や監視に切り替えるかです。
小規模運用では、構造を単純にする判断を優先してください。 月間 PV 10 万未満かつ管理 URL 500 以下なら、個別 URL の細かな調整より、SSR か事前描画へ寄せる方が再発防止につながります。公開後 7 日以内なら、代表 URL 5 本の HTML 差分と `canonical` の向きだけで十分です。例外は、商品在庫や価格が 1 日に何十回も変わるケース。この場合は SSR を優先し、事前描画だけで回すのは避けた方がよいでしょう。
中規模運用では、URL 単位ではなくテンプレート単位で直してください。 月間 PV 10 万から 100 万、管理 URL 500 から 1 万程度なら、記事、詳細、一覧、絞り込みの 4 系統に分けて `title`、`canonical`、本文出力の基準を定義します。未登録理由が `クロール済み - インデックス未登録` に偏る時は、各テンプレートで本文量と正規 URL の出し方が揃っているかを確認します。人が 100 URL を読むより、テンプレート 4 本を直す方が効果は出やすいものです。
大規模運用では、Search Console だけで終わらせないことが重要です。 月間 PV 100 万以上、管理 URL 1 万超なら、代表 URL の目視だけでは足りません。デプロイ時刻、エラーログ、監視通知、クロール時刻を突き合わせてください。ライブテストで直って見えても、デプロイ直後の 30 分だけ API が失敗していれば、その瞬間に取得された HTML が登録済み情報として残ります。ここまでくると、手動確認は補助です。主役はログと差分管理になります。
規模ごとの推奨を短くまとめると、次の通りです。
- 月間 PV 10 万未満・URL 500 以下: 構造を単純化し、公開ページは SSR か事前描画へ寄せる
- 月間 PV 10 万から 100 万・URL 500 から 1 万: テンプレート単位で `canonical`、本文、構造化データを統一する
- 月間 PV 100 万以上・URL 1 万超: 代表 URL の確認に加え、ログ監視とデプロイ差分の検証を必須にする
この 3 つを混ぜないことが重要です。小規模なのに監視設計から始める必要はありませんし、大規模なのに担当者が 20 URL を目視し続けても追いつきません。
よくある誤判定を実務で立て直す6つの具体策
JavaScriptレンダリングでインデックスされない案件では、同じ誤判定が繰り返されます。ここを先回りして潰しておくと、調査の手戻りを減らせます。
- ライブテストが成功したので解決したと判断する
これは早計です。ライブテストは「今の取得可否」を見る画面であり、「登録済み情報の更新完了」を示すものではありません。登録済み情報の HTML が古いままなら、結論は「直った可能性が高い」で止めるべきです。再クロール待ちで片づけず、直近デプロイで何が変わったかを追ってください。
- robots.txt で止めたうえで `noindex` を入れる
この組み合わせは避けてください。`noindex` を読ませたいなら、Googlebot はそのページへ到達できなければなりません。除外したいページを robots で塞いだままにすると、検索結果に URL だけが残る不格好な状態を招きやすくなります。
- `canonical` を削除命令として使う
`canonical` は「こちらを正規として見てほしい」という合図であって、強制削除の命令ではありません。内容差の大きいページを無理に 1 本へ寄せると、正規 URL の評価まで不安定になります。統合したいなら、内容差が小さいか、役割が明確に重複している時だけに使うべきです。
- 本文をタブやアコーディオンの内側へ押し込む
見た目の整理を優先し、本文の本体を初期表示から外す実装は危険です。FAQ の回答、サービス比較、申込条件、価格の説明を後出しにすると、モバイル版で取りこぼしやすくなります。見た目より、まず取得を優先して設計してください。
- 存在しない詳細 URL をすべて `200` で返す
これは修正優先度が高い問題です。後段の JavaScript が「該当なし」を描画しても、HTTP が `200` のままだと薄いページとして扱われやすくなります。公開 URL 数が多いサイトほど、この設計の悪影響は大きく出ます。
- サイトマップ送信だけで回復を待つ
サイトマップは有効ですが、それだけでは戻りません。HTML、`canonical`、`meta robots`、内部リンク、HTTP 応答が揃って初めて効いてきます。構造が壊れたまま送信しても、調査を遅らせるだけです。
誤判定を立て直すコツは、感覚ではなく「Google が見た事実」に寄せることです。スクリーンショット、会議での印象、ローカル環境の見た目ではなく、Search Console の登録済み情報、ライブテスト、HTTP 応答、レンダリング後 HTML を起点にしてください。ここが揃うだけで、開発と編集の会話はかなり短くなります。
今日中に終える初動対応3項目の進め方を整理する
JavaScriptレンダリングでインデックスされない時、初動でやるべきことは多くありません。むしろ、やることを 3 つに絞るべきです。 広げすぎると原因の切り分けが曖昧になります。
- ページのインデックス登録レポートで未登録理由の上位 2 件を確認する
件数が多い理由をまず押さえます。`クロール済み - インデックス未登録` なのか、`robots.txt によりブロックされました` なのかで、調査の入口は変わります。ここで少数の例外を追わないことが重要です。
- 代表 URL 5 本で、ライブテストと登録済み情報の差を並べる
トップページは後回しにして、未登録が多いテンプレートから 5 本選んでください。`title`、`h1`、本文導入、`canonical`、`meta robots`、HTTP 応答の差分を 1 枚にまとめれば、改修優先度が決まります。
- 修正後は正規 URL だけをサイトマップへ載せ、同じ 5 本で再確認する
修正が入ったら、別の URL を見にいく必要はありません。最初に選んだ 5 本で差分が消えたかを確認します。同じサンプルを追うからこそ、改善したかどうかが分かります。
ここまでできれば、次に何を直すべきかはかなり明確になります。本文改善へ進んでよいのは、Googlebot が本文を安定して取得できていると確認できた後です。反対に、そこが曖昧なままでは、施策を積み上げても土台が動きます。まず今日やるべきことは、Search Console を開き、未登録理由の上位 2 件を確認し、代表 URL を 5 本選ぶことです。そこから先は、事実に沿って判断できます。