公開から数週間たっても順位が伸びず、Search Console では「クロール済み - インデックス未登録」や「検出 - インデックス未登録」が増える。それなのに、ブラウザで開くとページは普通に見える。この状態で画像圧縮や CSS の軽量化だけを進めても、たいていは回り道です。
まず疑うべきなのは、Google が受け取る初期 HTML に本文と内部リンクが十分にあるか です。Google は クロールとインデックス登録 で、ページ取得後に必要に応じてレンダリングし、その結果をもとに理解と登録を進める流れを示しています。JavaScript SEO の基本を理解する でも、リンクや本文が後段の処理に寄りすぎると、解釈が不安定になり得ることが読み取れます。
結論は明快です。SEO の対象ページでは「本文を先に返す設計」を選ぶべきです。 月間 PV が 10 万未満の記事サイトや BtoB サイトなら、まずサーバー側で本文冒頭、主要見出し、パンくず、関連記事リンクを返してください。React や Vue を使っていても、公開ページに限れば HTML を厚くするほうが安定します。例外は、会員専用画面や強い個別最適化が前提で、検索流入を主目的にしていないページくらいでしょう。
外部タグも同じです。CMP、広告、AB テスト、ヒートマップ、チャットを `<head>` の前半に積み上げる設計は避けてください。Google が読むべき本文より先に、計測や同意処理が動く構成は、表示速度とインデックスの両方を悪化させます。本文より先に動いてよいのは、表示に必須な最小限の CSS と正規化信号だけ と考えるのが安全です。
表示速度より本文欠落を先に確かめる実務理由
render-blocking を速度指標だけの問題として扱うと、判断を誤ります。LCP や INP が悪いページでも、本文と内部リンクが初期 HTML に十分あれば、インデックスは維持される場合があります。逆に Lighthouse の点数が悪くなくても、本文の大半を JavaScript の後段で描画しているページでは、検索流入だけが鈍ることも珍しくありません。
とくに危ないのは、次の三つです。
- 記事本文の 7 割以上が JavaScript 実行後にしか出ない
- 主要内部リンクが関連記事欄や追従ナビにしかなく、それも後段描画に依存している
- canonical、`noindex`、構造化データをテンプレートの後処理で書き換えている
この状態では、Google が インデックス登録 の判断に使う材料が揃いません。canonical は 重複した URL の正規化 や 重複 URL の統合 で示される重要な信号ですし、`noindex` は ページを検索インデックスから除外 のとおり、実際にクロールできる状態でなければ機能しません。本文が後から出る、meta が後から変わる、robots.txt では一部リソースを塞いでいる。この組み合わせは、復旧を長引かせる典型です。
実務では、URL 検査で見える HTML に本文冒頭 300〜500 文字がないページは、速度改善より先に設計を戻す ほうが得策です。月間 PV 30 万未満のサイトなら、CSS 削減に 2 週間使うより、記事本文と関連記事リンクをサーバー返却へ寄せるほうが回復は早いはずです。例外は、すでに初期 HTML に本文があり、第三者タグだけが一時的に重い場合。この場合は、配信順の整理から着手して構いません。
Google が読み取りにくいページに共通する兆候
Googlebot が取り切れていないページには、見分けやすい共通点があります。現場でまず見るべき兆候は、次の四つです。
初期 HTML の情報量が明らかに少ない
URL 検査ツールの「表示された HTML」で、導入文が数行しかない、h2 見出しが出てこない、関連記事リンクが空に近い。この状態なら、render-blocking が原因候補の上位です。URL 検査ツール ではライブテストとインデックス済み状態を見比べられるので、両者で本文量に差があれば、レンダリング依存が強すぎると判断できます。
主要内部リンクがクリック依存になっている
パンくず、関連カテゴリ、関連記事、比較ページへの導線が、クリックやタブ切り替えを起点に後から挿入される設計は避けるべきです。Google は JavaScript SEO の基本 で、リンク発見が後段になる可能性を説明しています。記事ページなら、本文内リンク 2〜3 本、パンくず、関連記事 3 本前後は初期 HTML に含めるのが無難でしょう。
canonicalと noindex が動的すぎる
テンプレートやタグ設定の都合で canonical が一覧ページや別 URL を向く、あるいは `noindex` を条件分岐で付け替える。この運用は事故を呼びます。canonical は公開時点で自己参照を基本に固定し、例外ページだけ個別管理する ほうが安全です。例外として、明確な重複ページ群や印刷用ページがあるなら、設計上の理由がある canonical を許容して構いません。
モバイルで本文が削られている
モバイル ファースト インデックスに関するベスト プラクティス が示すとおり、モバイル版の主コンテンツ不足はそのまま不利に働きます。PC では全文が見えるのに、モバイルでは「続きを読む」の内側に本文の大半を入れているケースは要注意です。モバイルで見えない本文は、検索でも弱くなる と考えたほうがよいでしょう。
この四つのうち二つ以上に当てはまるなら、render-blocking を単なる速度課題と見なすべきではありません。設計と配信順の問題として扱うのが適切です。
Search Console で原因を切り分ける順番
原因の切り分けは、順番を決めておかないとぶれます。おすすめは、URL 検査から入り、ページ単位で確かめ、次にレポートで広がりを見る 進め方です。
最初の十分で確認する五つの項目
- URL 検査ツール で対象 URL を開き、インデックス済みかどうかを確認する
- ライブテストを実行し、取得そのものが成功するかを見る
- 「表示された HTML」で本文冒頭、h1、h2、パンくず、主要内部リンクが出ているか確認する
- canonical、`noindex`、robots の扱いが意図どおりかを見る
- ページのインデックス登録レポート で、同じ種別の URL に問題が広がっていないか確認する
この順番を守ると、問題は三系統に整理できます。
- 取得できない問題
- 取得はできるが HTML が薄い問題
- HTML はあるが正規化や品質評価で落ちる問題
render-blocking で重点的に見るべきなのは二番目 です。ライブテストが通っていても、HTML が薄ければ安心できません。取得できたことと、本文を十分に理解できたことは別だからです。
robots.txt は最初に確認を終える
ライブテストが失敗する場合、まず robots.txt の概要 と robots.txt ファイルの作成と送信 を確認し、CSS や JavaScript を誤って塞いでいないか見てください。解析に必要なリソースをブロックしているなら、render-blocking の細かな調整より先に解除すべきです。
ここは例外もあります。認証が必要な管理画面や、意図的に検索結果へ出さない画面なら、robots 制御を優先して問題ありません。ただし、公開記事やサービス詳細ページで同じ設定を流用するのは避けるべきです。
サイトマップは復旧局面で効く補助信号
HTML を直したあとで、サイトマップの概要 と サイトマップの作成と送信 に沿って、正規 URL のみを送る状態へ整えてください。サイトマップは魔法の解決策ではありませんが、復旧局面では「どの URL を見てほしいか」を伝える補助信号として機能します。noindex URL や重複 URL を混ぜたまま送る運用はやめるべきでしょう。
Search Console の使い方は、Googleインデックス登録を早めたいときの実務手順。Search Consoleを道具として使い切る でも詳しく触れています。送信リクエストを繰り返すより、先に HTML と内部リンクを整えるほうが、実務では明らかに効果的です。
原因別に改修の優先順位を決める実務比較表
render-blocking の対処で迷う最大の理由は、「どこから直すか」が曖昧になりやすいことです。まずは次の表で優先順位を固定してください。
原因候補 | インデックスへの影響 | 先に直すべき度合い | 推奨対応 |
|---|---|---|---|
本文が JavaScript 後段で生成される | 非常に大きい | 最優先 | 本文冒頭 300〜500 文字、h2、主要リンクをサーバー返却へ切り替える |
主要内部リンクが後段描画に依存 | 大きい | 高い | パンくず、関連記事、比較ページ導線を初期 HTML に置く |
CMP・AB テスト・広告タグが `<head>` 前半で同期実行 | 大きい | 高い | 非同期化、遅延化、読み込み順の見直しを実施する |
canonical や noindex を動的に付け替える | 大きい | 高い | 公開時点で安定した値に固定し、例外だけ個別設定する |
CSS が大きすぎる | 中程度 | 中 | クリティカル CSS の整理、不要 CSS の削減を進める |
外部フォントが重い | 小〜中 | 低 | フォント数削減、`font-display` の見直しを行う |
この表で重要なのは、CSS やフォントを後回しにする判断 です。速度改善の文脈では気になる項目ですが、インデックス不調の復旧局面では、本文と内部リンクのほうが優先度は上です。例外は、CSS 自体が本文表示を止めていて、HTML はあるのにスクリーンショットが白い場合。このときだけは、CSS の配信順を前に持ってきてください。
もう一つ、設計の選び方も比較しておくべきです。
構成 | 推奨度 | 向いている場面 | 避けるべき場面 |
|---|---|---|---|
本文をサーバー側で返す | 5/5 | 記事、サービス詳細、比較ページ、採用情報 | なし。公開ページでは基本形 |
本文を JavaScript 実行後に組み立てる | 1/5 | 会員専用画面、検索流入を狙わない画面 | 記事、LP、カテゴリ一覧 |
外部タグを本文より先に同期実行する | 1/5 | ほぼなし | モバイル流入が多い全ページ |
パンくずや関連記事を初期 HTML に置く | 5/5 | 記事とカテゴリ群の回遊強化 | なし。原則採用でよい |
ここまで方針を明確にすると、実装判断はぶれにくくなります。検索流入が目的なら、公開ページは複雑さを減らす方向へ寄せるべき です。柔軟なフロント実装を優先した結果、毎月のインデックス監視に工数を払い続けるのは、費用対効果に見合いません。
サイト規模別に見直すべき改修水準の考え方
「状況による」で片づけると、現場は動けません。月間 PV と運用体制ごとに、求められる改修水準を切り分けます。
月間 PV が 10 万未満のサイト
サーバー返却を第一選択にしてください。 記事中心の自社メディアや BtoB サイトなら、本文、見出し、関連記事、パンくずを最初から返すだけで十分なことが多いです。監視も広げすぎる必要はありません。URL 検査とページのインデックス登録レポートを週次で見る運用で足ります。
例外は、短期間の実験 LP を大量に出すケースです。この場合は開発速度を優先してクライアント描画を使うこともありますが、インデックスを主目的にしない前提で割り切るべきでしょう。
月間 PV が 10 万〜100 万のサイト
テンプレート単位で改修してください。 記事詳細、カテゴリ一覧、サービスページ、比較ページの代表 URL をそれぞれ 3 本ずつ選び、共通原因を潰すのが効率的です。1 ページずつ直すやり方では追いつきません。テンプレートでの切り分けは、内部リンク最適化の2026年実務 回遊を増やすだけで終わらない評価配分の考え方 の考え方とも相性がよく、評価配分の見直しまで一緒に進められます。
例外として、カテゴリごとに CMS テンプレートが完全に違う媒体では、まず流入規模の大きい型から着手したほうがよいでしょう。重要度の低い型まで一気に触る必要はありません。
月間 PV が 100 万以上のサイト
責任分界を明確にした監視を導入すべきです。 CMP、広告、計測、フロント基盤、CMS 出力の担当を分け、代表 URL の HTML スナップショット差分を週次で確認してください。ここまでの規模になると、render-blocking は技術課題ではなく運用課題です。再発防止を設計に組み込まない限り、直しても戻ります。
例外は、流入が少ない一部サブディレクトリだけです。全体監視に乗せつつ、改修優先度は低めで構いません。
多言語・複数サブドメインのサイト
先に canonical とサイトマップを揃えるべきです。 URL 設計が曖昧なまま render-blocking を直しても、正規化で迷えば回復は遅れます。とくに言語別 URL と旧 URL が混在している媒体では、まず正規 URL の定義を一本化してください。そのうえで hreflang、内部リンク、初期 HTML の順に整えるほうが早く収束します。
アンカーテキストまで見直すなら、アンカーテキスト最適化の最新実務 2025年更新ガイダンスから逆算する内部リンク設計 もあわせて確認すると判断しやすくなります。
復旧を早めるための実務確認チェックリスト
改修前後で最低限見るべき項目を、実行順に並べます。抽象論ではなく、この順で進めてください。
- URL 検査の「表示された HTML」で、本文冒頭 300〜500 文字と h2 見出しが見えるか確認する
- パンくず、関連記事、比較ページへの主要内部リンクが HTML ソースに存在するか確認する
- `robots.txt` が CSS や JavaScript を誤って遮断していないか確認する
- `noindex` を使うページが robots.txt でブロックされていないか確認する
- canonical が自己参照を基本に統一され、サイトマップの URL と矛盾していないか確認する
- モバイル表示で本文が省略されすぎていないか確認する
- 修正後は代表 URL を 5〜10 本だけ再検査し、同じ型で反映を確認してから範囲を広げる
- ページのインデックス登録レポートで、問題 URL の件数が 2〜4 週間で減少傾向にあるか確認する
このチェックリストで三つ以上に問題が出たら、細かな速度改善へ進むべきではありません。まず設計を戻し、HTML を厚くしてから再計測するのが適切です。
JPSM SEO 編集事業部でも、公開ページの複雑さを減らし、本文と内部リンクを先に返す設計へ戻した案件のほうが、再クロール後の安定性は高く出ています。派手な改善策より、検索エンジンが迷わないページを作ることのほうが、結局は費用対効果に優れます。
render-blocking 復旧を三段階で進める手順
最後に、現場でそのまま動ける形にまとめます。render-blocking が疑わしいときは、次の三段階で進めるべきです。
第一段階では本文とリンクを先に返す
記事ページなら、タイトル、導入文、h2 見出し、関連記事 3 本、パンくずを初期 HTML に載せてください。サービスページなら、要点、比較軸、FAQ 見出し、資料請求や問い合わせ導線を先に返します。最初の改修では満点の速度指標を狙わず、Google が読む材料を揃えることを優先する のが正しい順番です。
第二段階で止めている要因を減らす
CMP、AB テスト、広告、外部計測、巨大な CSS、外部フォントの順で、本文より前に並んでいる処理を後ろへ送ります。1 回で全部触るのではなく、代表 URL 5〜10 本に効く要因から順に減らしてください。同時改修を避ける理由は、何が効いたかを見失わないためです。
第三段階では再確認して横展開する
URL 検査で HTML、スクリーンショット、canonical が正常になった代表 URL を確認し、そのあとでサイトマップ送信と再クロール依頼を行います。テンプレート単位で改善が確認できたら、同じ型の URL へ横展開してください。確認前の一斉再送信は避けるべき です。失敗しても原因を追えなくなります。
render-blocking とインデックスの関係で迷ったら、覚えるべき原則は一つだけです。速度より先に、本文と主要内部リンクを Google に渡す。 これが崩れている限り、改善は安定しません。まず今日中に代表 URL を 5 本選び、URL 検査で「表示された HTML」を開いてください。そこに本文冒頭、h2、主要内部リンクが見えていなければ、次にやるべき改修はもう決まっています。