Googlebotクロールを正しく制御する 実装判断と検証の実務手順

検索流入が伸び悩む案件で、現場の時間をもっとも奪うのは、「Googlebotが来ていないのか」「来ているのに取得できないのか」「取得できているのに、残すべきでないURLへ回っているのか」が混ざったまま議論が進む場面です。設定項目だけを見ると、robots.txt、noindex、canonical、サイトマップ、内部リンク、HTTP応答、JavaScript出力が並びます。ただ、Google のクロールとインデックス登録 と インデックス登録 の前提に沿って整理すると、考える順序はもっと単純になります。

結論を先に述べます。Googlebot制御で最初にやるべきなのは、止めるURLを探すことではなく、残すURLを明文化することです。ここが曖昧なまま設定だけを触ると、検索に残したいページまで止まり、反対に不要なURLがクロールを使い続けます。公開直後の確認手順を先に押さえたい場合は、Googleインデックス登録を早めたいときの実務手順 Search Consoleを道具として使い切る もあわせて読むと、公開後の運用までつなげやすくなります。

最初に決めるのは残すURLの範囲と優先度

Googlebot制御で成果が出る現場では、例外なく「検索に残すURLの定義」が先にできています。逆に失敗する現場では、`Disallow` の行だけが増え、誰も主役URLを説明できません。月間PVが10万未満でも、URLパターンが10種類を超えたら、まず分類表を作るべきです。月間PVが100万を超えるなら、URL総数そのものよりも「パターンの増え方」を危険信号として見たほうが実務に合います。

私が最初に分けるのは、次の4群です。

• 主力URL: サービス詳細、カテゴリ、商品詳細、導入事例、比較ページ、指名検索を受ける事業ページ。検索流入と成果の両方に寄与するURLです。
• 補助URL: FAQ、記事詳細、地域別一覧、活用ガイドなど。単独流入も狙えますが、主力URLを支える役割が大きいURLです。
• 閲覧用URL: 並び替え、絞り込み、会員向け導線、計測パラメータ付きURL、内部検索結果など。利用者には必要でも、検索結果に残す価値が薄いURLです。
• 退役URL: 終了LP、旧URL、重複テンプレート、テストページ、開発残骸。検索にも閲覧にも残さないURLです。

ここでの方針は明確です。Googlebotに優先して通すのは、主力URLと補助URLだけで十分です。閲覧用URLは検索から外し、退役URLは整理して減らします。すべてを同じ重みで扱う設計は、ほぼ確実に崩れます。

規模別に先に守るべきURLは変わる

• 月間PV10万未満でURL総数が5,000未満なら、主力URLを20本から50本に絞って守るべきです。最初から全ページを救おうとすると、確認が粗くなります。
• 月間PV10万から100万で、記事、カテゴリ、サービスページが混在するなら、テンプレート単位で主力URLを決めるべきです。1URLずつ判断すると、担当者ごとに基準がぶれます。
• URL総数が5万を超えるなら、個別URLではなく「URL群」で制御すべきです。パターン単位で残すか止めるかを決めない限り、運用が追いつきません。

例外もあります。採用、IR、法務、サポートのように、検索流入より事業上の説明責任が優先される領域では、流入規模が小さくても残す判断が必要です。反対に、検索流入が多いブログでも、パラメータ違いで中身がほぼ同じなら主力URLには入りません。PVではなく、検索に残す理由を説明できるかどうかで決めるべきです。

孤立URLが多いサイトでは、クロール制御より前に内部導線を見直したほうが早く効きます。そうした場面では、内部リンク最適化の2026年実務 回遊を増やすだけで終わらない評価配分の考え方 を先に確認してください。Googlebotの問題に見えて、実際には主要URLへ評価が流れていないだけという案件は珍しくありません。

症状別に原因を切り分ける確認作業の進め方

クロール制御の議論を始める前に、Search Consoleとサーバーログで現実を確認するべきです。推測のまま設定を変えると、来ていないだけのURLを障害と誤認し、本当の問題を見逃します。見る順序は、次の4段階で足ります。

1. URL 検査ツール で、対象URLの取得可否、ユーザー指定canonical、Google選択canonical、最終クロール日時を確認する
2. ページのインデックス登録レポート で、同系統URLが何件失敗しているかを確認する
3. サーバーログで、直近7日から14日のGooglebotアクセスをテンプレート別に集計する
4. 直近の配信変更、CMS設定変更、WAFやCDNのルール変更を照合する

この順序を勧めるのは、単発の異常か、テンプレート全体の異常か、配信経路の異常かを30分ほどで切り分けられるからです。

数字で見ないと誤診しやすい項目

ログは「来たかどうか」だけでは足りません。少なくとも、次の比率を見てください。

• Googlebotアクセスの 5xx 比率が7日平均で1%を超える: まず配信基盤を直すべきです。内容改善より優先順位が上になります。
• 主力URLの 301が2回以上連続する: 内部リンクと旧URL整理を先に直すべきです。再取得が遅れやすくなります。
• 主要テンプレートで 404や410が意図せず5%以上: ルーティングか公開フローを疑うべきです。
• 「クロール済み - インデックス未登録」が 重要テンプレートで連続増加: 技術的な障害ではなく、重複、内容不足、canonical不一致の可能性が高いと見てよいでしょう。

ここでの判断は単純です。取得不能なら到達性、取得できるのに残らないなら重複と品質、そもそも来ていないなら内部リンクとサイトマップを疑います。この切り分けを飛ばして robots.txt を触るのは、順序が逆です。

よくある症状別に見る最初の対処

• URL検査で取得不能、ログにもGooglebotが出ない: `robots.txt`、WAF、認証、DNS、CDNルールを先に確認します。
• URL検査で取得可能、ログにも来ているのに残らない: `canonical`、本文重複、タイトル重複、内容の薄い一覧ページを疑います。
• 新規公開ページだけ来ない: サイトマップ送信と内部リンク追加を先に行うべきです。孤立ページは後回しにされがちです。
• 絞り込みURLばかり来る: 内部リンク出力とパラメータ設計が崩れています。クロール制御と同時に導線を直すべきです。

ここで内部リンクの文言が弱いと、主役URLへの評価集約が進みません。関連する判断は、アンカーテキスト最適化の最新実務 2025年更新ガイダンスから逆算する内部リンク設計 も参考になります。

robots.txtとnoindexの役割を先に分ける

この領域で最も多い失敗は、クロールを止めることと、インデックスから外すことを同じ操作だと思っていることです。役割は明確に分ける必要があります。robots.txt の概要 と robots.txt ファイルの作成と送信 はクロール制御、noindex を使用してページを検索インデックスから除外 はインデックス制御の話です。ここを混ぜると、設定だけが増えて成果につながりません。

まずこの比較表で判断してください

ここで強く勧めたいのは、検索に残したくないものの、内容確認は必要なページに、いきなり `Disallow` を当てないことです。`noindex` を使うなら、そのURLはまずクロール可能でなければ意味がありません。現場では逆順で設定されることが多く、これが長く尾を引きます。

具体的にどこへ何を当てるべきか

• 社内検索結果、絞り込み結果、並び替え、セッション付きURL: まず `robots.txt` と内部リンク抑制を組み合わせるべきです。
• お問い合わせ完了、会員限定の遷移ページ、テストLP、広告専用LP: `200` で返しつつ `noindex` を使うべきです。
• URLパラメータが違うだけで、商品集合も本文もほぼ同じ一覧ページ: `canonical` を優先すべきです。
• PDF資料、価格表、配布用ホワイトペーパー: HTMLで制御しようとせず、`X-Robots-Tag` を使うべきです。

例外もあります。絞り込みページでも、「渋谷 オフィス賃貸」「中途採用 エンジニア フルリモート」のように需要が独立し、本文も内部リンクも足して運用できるなら、主力URLとして残す余地があります。その場合は `noindex` や `robots.txt` へ逃がすより、独立ページとして育てるほうが適切です。

HTTP応答と正規化の設計を同時に決める

クロール制御は、設定ファイルだけでは完結しません。HTTP応答と正規化の設計を揃えて初めて、Googlebotへ一貫した意図を伝えられます。 重複した URL の正規化 と 重複 URL の統合 を読むと、`canonical` も `301` も「主役URLを明示する手段」であり、雑に使う道具ではありません。

ここでの推奨は次の通りです。

• 後継ページがあり、検索意図も近いなら `301` を選ぶべきです。旧URLを `200` のまま残すのは避けてください。
• 代替がなく、6か月以内の再開予定もないなら `410` を優先してかまいません。不要URLの整理が早く進みます。
• 一時的な在庫切れや一時停止は `404` に落とすべきではありません。`200` のまま代替導線と再開見込みを示したほうが整合します。
• 本文差分がある別ページに `canonical` を向けるのは避けるべきです。Googleに無視されるだけでなく、チーム内の判断も乱れます。

旧URL整理は次の基準で決める

• 旧URLの外部リンクや指名流入が残っている: `301` を優先します。
• 法務、IR、サポート情報のように履歴として残す必要がある: `200` のまま情報更新し、必要なら `noindex` を併用します。
• 終了LPで再開見込みがなく、代替もない: `410` を選びます。
• CMS都合で削除できないが検索には残したくない: `200` + `noindex` を選びます。

この基準を先に決めるだけで、soft 404 の発生率は大きく下がります。現場でありがちなのは、画面には「ページが見つかりません」と出しつつ `200` を返しているケースです。利用者にも検索エンジンにも中途半端で、長く残すべきではありません。

正規化は主従関係を説明できるときだけ使う

`canonical` の使い方にも線引きが必要です。主見出し、主要本文、主な商品集合が同じなら `canonical` を検討し、内容の役割が違うなら別ページとして扱うべきです。たとえば色違い、計測パラメータ違い、印刷用表示のような差分なら集約の余地があります。一方、地域別ページ、比較条件が異なる一覧、FAQ構成が違うサービスページは、別ページとして扱うほうが自然です。

例外は、CMSや配信都合で一時的に二重URLが発生する移行期です。その場合は `301` がすぐ打てないこともあるため、短期間だけ `canonical` でしのぐ判断はありえます。ただし、1か月以上そのままにする設計は勧めません。仮対応が恒久化しやすいからです。

JavaScript依存ページの公開条件を厳しくする

検索を取りにいくページで、初期HTMLに必要な情報が出ない構成は選ばないほうがよいです。JavaScript SEO の基本を理解する と モバイル ファースト インデックスに関するベスト プラクティス は、JavaScript自体を否定していません。ただ、実務では「読めるHTMLを先に返す」構成のほうが、事故が圧倒的に少ないのです。

SEO対象ページは描画方式を分けるべき

推奨ははっきりしています。自然検索を取りにいくページが50URLを超えるなら、全面CSRは避けるべきです。主要ページまでクライアント側描画に寄せると、取得確認と障害調査に余計な工数がかかります。

サイト構成ごとに決める描画方式

• コーポレートサイトやBtoBサービスサイト: 主要ページは SSR か SSG を選ぶべきです。保守と検証の両面で安定します。
• 会員機能中心のWebサービス: 会員画面は CSR で構いませんが、集客ページだけは別系統で SSR に分けるべきです。
• 既存CMSにJavaScript部品を後付けしているサイト: 部品がなくても本文、見出し、主要リンク、`canonical`、`meta robots` が読める構成へ戻すべきです。

ありがちな事故も先に挙げておきます。

• タブを開かないと本文がDOMへ入らない
• モバイルだけ内部リンクが折りたたみで消える
• `canonical` や `meta robots` をクライアント側で後から差し替える
• 主要リンクが遅延読み込み後にしか現れない
• PDFなのにHTMLの `meta robots` で制御しようとする

これらはすべて、公開前に気づける事故です。URL検査ツールのライブテストと、実際の初期HTML確認を主要URL10本で必ず行うべきです。そこを省くと、内容改善をどれだけ重ねても土台が揺れたままになります。

サイトマップと内部リンクの優先順位を揃える

公開後に効くのは、サイトマップ送信そのものではありません。サイトマップに入っているURLと、内部リンクで押しているURLと、実際に残したいURLが一致していることです。サイトマップの概要 と サイトマップの作成と送信 を見ると、サイトマップは保証の道具ではなく、優先URLの申告です。だからこそ、全URLを雑に流し込む運用は避けるべきです。

私が勧める基準は、次の3つです。

• `200` を返し、自己参照 `canonical` があり、検索に残すURLだけをサイトマップへ入れる
• `noindex`、`301`、`410`、`robots.txt` で止めたURLを混ぜない
• `lastmod` は本文や主要属性に実変更があったURLだけ更新する

もしサイトマップ内のURLのうち、5%以上が非対象URLになっているなら、一度作り直したほうがよいでしょう。純度が落ちると、Search Consoleで原因を追いにくくなります。

内部リンクも同じです。主役URLへ評価を寄せたいなら、関連記事、パンくず、カテゴリ導線、比較記事、FAQからのリンク先を揃えます。記事側だけ頑張っても、カテゴリやサービス詳細から押されていなければ、再取得の優先順位は上がりません。導線の設計は、先に触れた 内部リンク最適化の2026年実務 回遊を増やすだけで終わらない評価配分の考え方 と、文言設計を扱う アンカーテキスト最適化の最新実務 2025年更新ガイダンスから逆算する内部リンク設計 をあわせて読むと整理しやすくなります。

公開後三週間の運用と検証手順を固定する

クロール制御は、一度直したら終わりではありません。公開後三週間で確認手順を固定し、その後は週次運用へ落とし込むべきです。ここを定例化できるかどうかで、再発率が変わります。

三週間の進め方はこの順番で十分です

1週目は現状把握です。主力URLを10本、補助URLを10本、閲覧用URLを10本選び、URL検査、モバイルHTML、ログ、HTTP応答を確認します。ここで分類と実態がずれていたら、設定を足す前に分類表を直してください。

2週目は制御の統一です。`robots.txt`、`noindex`、`canonical`、`301`、`410`、`X-Robots-Tag` の役割を一覧表にまとめ、テンプレートごとに適用ルールを決めます。担当部署ごとに別々の表を持つと、ほぼ確実に食い違います。1枚にまとめるべきです。

3週目は監視の定着です。サイトマップ送信、インデックス登録レポートの監視、ログ集計、障害時の連絡系統を固定します。この段階で運用担当が一人しか触れない状態だと、属人化が起きます。JPSM SEO 編集事業部でも、クロール不具合の相談は設定修正そのものより、判断表と確認手順の整備から入ることが少なくありません。そこがない事業組織ほど、同じ障害を半年後に繰り返すからです。

公開後に毎週見る実務チェックリスト

• 主力URL10本の URL 検査結果を確認し、Google選択canonical が意図どおりかを見る
• テンプレート別にGooglebotの `200` `301` `404` `410` `5xx` 比率を出す
• `robots.txt` の変更履歴と、CDN・WAFのルール変更履歴を同時に確認する
• サイトマップに `noindex` や `301` が混ざっていないかを点検する
• モバイルHTMLで本文、主見出し、主要リンク、`canonical`、`meta robots` が出ているかを見る
• 301の連鎖が発生していないか、旧URLから新URLへの到達経路を5本以上サンプリングする
• 絞り込みURLや内部検索URLが主力URLより多くクロールされていないかを見る

数値の見方も決めておくと迷いません。`robots.txt` や応答コードの誤設定を直した後は、24時間から72時間で再取得の兆しが見えることがあります。一方、`canonical` の整理や重複解消、内部リンクの再設計は2週間から6週間を見込むべきです。日ごとに一喜一憂するより、7日移動平均で追うほうが実務に向いています。

最後に、今日やるべきことを3つに絞ります。主力URLを10本選ぶ、各URLの制御方法を1枚の表に書く、直近7日分のログでGooglebotの応答比率を出す。 まずはここまで進めてください。この3つが揃えば、Googlebot制御は「何となく設定を足す作業」ではなく、「事業上の価値が高いURLへ迷わず通す作業」に変わります。