テクニカルSEO実装：クロール・インデックス・表示速度

クロールとインデックスの制御

robots.txtは「クロールしてよいか」を、noindexは「インデックスに登録してよいか」を制御します。 この2つは目的が違い、混同すると意図と逆の結果になります。とくに、検索結果に出したくないページに robots.txtのDisallowを使うのは誤りです。Googleは、ブロックされたページでも他ページからリンクされていれば URLがインデックスに登録される場合があると説明しています。[出典: robots.txt の書き方、設定と送信]

robots.txtを変更したら、Search Consoleのrobots.txtレポートでGoogleが実際に読んだ内容を確認します。 CDNやサーバーの設定によっては、ブラウザで見えている内容とクローラーが取得する内容が違うことがあります。

Googlebotの動きを前提にする

robots.txtとnoindexを正しく設定しても、Googlebotがページの中身を読めなければインデックスには入りません。ここでは、JavaScriptで描画したコンテンツの扱いと、アクセスログのGooglebotが本物かどうかの確認方法を押さえます。

クロールとレンダリングは別のタイミング

GooglebotはHTMLを取得したあと、ヘッドレスChromiumでページをレンダリングしてJavaScriptを実行し、その結果をインデックスに登録します。 ただしレンダリングはクロールと同時ではなく順番待ちのキューに入り、ページがこのキューで数秒間、またはそれ以上待機することがあると Googleは説明しています。JavaScriptでしか描画されない本文は、登録が遅れたり、失敗すれば登録されなかったりします。 重要な見出し・本文・内部リンクは、最初のHTMLに含めておくのが安全です。[出典: JavaScript の基本を理解する]

確認は、URL検査ツールの「クロール済みのページを表示」でGoogleが取得したHTMLを見るのが確実です。 ブラウザの表示にはあるのに、そこに本文が無ければ、レンダリング前提のページになっています。

Googlebotを名乗る偽のアクセスを見分ける

User-Agentの文字列は誰でも名乗れるため、アクセスログの「Googlebot」が本物とは限りません。Googleは確認方法として、 アクセス元IPアドレスの逆引きDNSでドメイン名がgooglebot.com・google.com・googleusercontent.comのいずれかであることを確認し、 さらにそのドメイン名を順引きして元のIPに一致するかを見る手順を示しています。クローラーごとのIPレンジのJSONも公開されているので、ログ側で突き合わせることもできます。サーバー負荷を理由にBotを遮断する前に、まず本物かどうかを確認します。[出典: Google クローラーの確認]

Botの分類そのもの（一般的なクローラー／特殊なケース用／ユーザー トリガー フェッチャー）はSEO対策とはで、AI各社のBotはAIクローラーの一覧とrobots.txtで扱います。

未インデックスの対処法

インデックスされない状態には2種類あります。設定のせいで登録できない状態（noindex・robots.txt・canonical・リダイレクト・エラー）と、取得はできたがGoogleが登録する価値を認めなかった状態です。前者は設定を直せば戻りますが、後者は設定を直しても戻りません。まず、どちらなのかを確定させます。

理由別の対処

直したあとにやること

「クロール済み - インデックス未登録」が特定のページ種別に固まっている場合、個別ページの問題ではなく サイト構造の問題です。中身がリンク数個しかない一覧ページを大量に作っていないかを、レッスン08で確認してください。なお、Googleは基本事項を満たしていても インデックス登録や掲載を保証していないと明記しています。すべての未登録を0にすることは目標になりません。[出典: Google 検索の基本事項]

クローラーの訪問頻度と取得ファイル

Googleがいつ・何件・どのファイルを取得したかは、Search Consoleの「設定 → クロールの統計情報」で見られます。 Googleはこのレポートを上級者向けと位置づけており、ページ数が1,000未満のサイトでは使う必要はないと明記しています。 また、ドメインプロパティなどルートレベルのプロパティでのみ利用できます。[出典: クロールの統計情報レポート]

訪問頻度は絶対値ではなく推移で見る

何件クロールされていれば正常、という基準はありません。見るのは合計クロールリクエスト数の推移と、 同じ画面に出る平均応答時間です。Googleは、サイトが速く応答する状態が続けばクロール頻度の上限が上がり、 応答が遅い場合やサーバーエラーが返る場合は上限が下がってクロールが減る、と説明しています。[出典: 大規模なサイト所有者向けのクロール バジェット管理ガイド]つまりクロール数の減少は、多くの場合サーバー側の症状です。原因を本文や被リンクに求める前に、 応答時間と5xxの発生を確認します。

何を取りに来ているか：4つの内訳

HTMLが主になっているか

ファイル形式別でHTMLが最も多い形式になっているかを見ます。Googleが「HTMLは何％あるべき」という 基準を出しているわけではないので、当サイトでは「HTMLが上位にあり続けているか」を目安にしています。 画像の多いサイトや、リソースを入れ替えた直後は一時的に他の形式が増えます。問題なのは、HTML以外の取得が続けて大半を占め、新規ページや更新ページの取得が後回しになっている状態です。 Googleは、CSSやJavaScriptなど埋め込みリソースの取得もサイトのクロール割り当てを消費すると説明しています。[出典: 大規模なサイト所有者向けのクロール バジェット管理ガイド]

逆に、レンダリングに必要なJavaScriptやCSSをrobots.txtで止めるのは対処になりません。 Googleは、レンダリングに必要なリソースを取得できないと、ページの内容の抽出や検索での掲載に支障が出ると説明しています。[出典: Google 検索セントラル ブログ「The how and why of Googlebot crawling」]減らすべきなのは同じ内容を何度も取り直させている無駄で、リソースそのものへのアクセスではありません。

なお、クロールの統計情報を細かく追う価値があるのは、ページ数が多いサイトです。 Googleのクロール バジェットのガイドも、対象を大規模なサイト（100万ページ以上で更新頻度が中程度など）としています。[出典: 大規模なサイト所有者向けのクロール バジェット管理ガイド]小規模なサイトでは、前節の未インデックスの解消と本文の改善のほうが先です。

重複と正規URLの整理

同じ内容が複数のURLで見える状態は、評価が分散するだけでなく、どのURLを検索結果に出すかの判断をGoogleに委ねることになります。canonical・301リダイレクト・サイトマップの3つで、代表URLを1本に決めます。

サイトマップには、代表URLだけを載せます。canonicalで除外したURLをサイトマップに残すと、 サイトマップとcanonicalが矛盾したシグナルを出すことになります。サイトマップの更新日（lastmod）も、 全ページ同じ日付にすると更新のシグナルとして機能しません。[出典: サイトマップの作成と送信]

構造化データの選び方

構造化データは、ページの内容を機械が読める形で併記するマークアップです。順位を上げる設定ではなく、 検索結果での表示のされ方（リッチリザルト）を変えるためのものです。[出典: 構造化データの仕組みについて]守るべき条件は1つで、マークアップの内容がページに表示されているテキストと一致していることです。

実装後は、リッチリザルトテストとSearch Consoleの拡張レポートで検証します。 楽天レシピはCMS側で対応して2週間で全ページに反映し、構造化データテストツールで検証したうえで、 検索エンジンからの流入が2.7倍になったと報告しています。Eventbriteは基本テンプレートを1つ作り、 以降は微調整だけで運用しています。1ページずつ手で書くのではなく、テンプレートで一括して出すのが実装の要点です。

なお、生成AI向けの特別な構造化データは存在しません。Googleは、AI機能に表示されるために 特別なschema.orgの構造化データを追加する必要はないと明記しています。詳しくはGEOでやらなくていいことで扱います。

Core Web Vitalsの直し方

Core Web Vitalsは、LCP（読み込み）・INP（応答性）・CLS（視覚的な安定性）の3指標です。 良好とされる目安はLCPが2.5秒以内、INPが200ミリ秒以下、CLSが0.1以下で、判定はモバイルとPCを分けたうえで 全体の75パーセンタイルの値で見ます。[出典: web.dev「Web Vitals」]

3指標を同時に追わないでください。PageSpeed Insightsのフィールドデータを開き、最も悪い1指標に絞るほうが進みます。実際、redBusはINPだけに絞って改善し、売上が7%増えたと報告しています。

実例：この作業で何が動いたか

このレッスンで扱った作業について、施策と結果の数値が同じ文書で公開されている事例です。数値は各社の環境での結果であり、同じ結果を保証するものではありませんが、どの作業がどの指標に効いた例があるかの対応関係は読み取れます。

全11件の実例はレッスン12にまとめています。 次のレッスンでは、技術的に読める状態になったページに、引用される本文を書いていきます。

到達チェックリスト

次の項目を自分のサイトで確認できたら、このレッスンは終わりです。1つでも「まだ」がある場合は、次のレッスンに進む前にそこを埋めてください。

よくある質問

記事から取り入れたこと

「テクニカルSEO実装」の範囲でその後に出た記事のうち、このレッスンに足すべきと判断したものです。 レッスン本文は仕組みの説明にとどめ、確認できた個別の手順・数値はここに積みます。

• サイトマップの並び順ではクロール順は決まらないので、順番の調整に工数を使わない。

  2026.09.02·出典: クローラーはsitemap順に見ていない。実ログ19万件で巡回の順番を解析した