クローラーとは？GoogleがWebサイトを巡回する仕組みを徹底解説

クローラーとは何かを初心者向けに解説。GooglebotがWebサイトを巡回する仕組みやクロール頻度、robots.txt、クロールバジェットの基本を紹介します。巡回されない原因やSearch Consoleでの確認・対処方法も分かります。

「ブログ記事を公開したのに、Googleがなかなか見つけてくれない」「GooglebotはどのようにWebサイトを巡回しているの？」と疑問に思ったことはありませんか？

Google検索では、クローラーと呼ばれる自動プログラムがWebページを発見し、文章や画像などの情報を取得しています。

しかし、記事を公開すれば必ず巡回されるわけではなく、内部リンクやサイトの設定、サーバーの状態などが影響する場合もあります。

この記事では、Googlebotの種類や巡回の仕組み、クロール頻度、robots.txt、クロールバジェット、Search Consoleでの確認方法まで初心者向けに解説します。

Googleに記事を発見してもらいやすいサイトづくりを学びたい方は、ぜひ最後までご覧ください。

クローラーとは？Google検索での役割を初心者向けに解説

クローラーとは、インターネット上のWebサイトを自動的に巡回し、ページの情報を取得するプログラムです。

Google検索では、Googlebotと呼ばれるクローラーがWebページを発見し、文章や画像、リンクなどの情報を取得しています。

例えば、WordPressで新しいブログ記事を公開すると、Googlebotがその記事のURLを発見し、ページの内容を読み取ることがあります。

ただし、記事を公開しただけで、必ずGooglebotが巡回するわけではありません。

ここでは、クローラーの基本的な役割からGooglebotの特徴、クローリングとインデックス登録の違い、SEO対策との関係まで初心者向けに解説します。

クローラーとは何をするプログラム？

クローラーとは、Webサイトに自動的にアクセスし、ページの情報を収集するプログラムです。

私たちがWebサイトを閲覧するときは、ブラウザを開いてページの内容を確認します。

一方、クローラーはプログラムによってURLへアクセスし、HTMLなどの情報を取得します。

例えば、Googlebotが「トマトの育て方」という記事をクロールした場合、記事の文章やリンク、画像に関する情報などを取得します。

また、ページ内に別の記事へのリンクがあれば、そのURLを新しく発見する手がかりにもなります。

クローラーの主な働きは次のとおりです。

• インターネット上のWebページを発見する
• WebページのHTMLなどを取得する
• ページ内のリンクから別のURLを見つける
• 公開済みページの変更内容を再取得する
• 取得した情報を検索エンジンの処理へ渡す

クローラーの役割を整理しました。

役割	内容	具体例
URLの発見	新しいページを見つける	新着記事を発見
情報の取得	ページの内容を読み込む	タイトルや本文を取得
リンクの確認	別のURLを発見する	関連記事へ移動
再クロール	更新された情報を取得する	修正後の記事を再取得
情報の提供	検索エンジンの処理につなげる	インデックス処理に利用

例えば、WordPressで「家庭菜園」というカテゴリーを作成し、その中に複数の記事を公開したとします。

クローラーがカテゴリー一覧へアクセスすると、そこに掲載されている記事へのリンクから、新しいURLを発見する場合があります。

ただし、すべてのURLが必ずクロールされるわけではありません。

Google公式資料でも、クロールは自動化されたプログラムがWebページを発見し、情報を取得する処理であると説明されています。

クローラーは、検索エンジンがWebページの存在を知るための重要な役割を担っています。

Googlebotとは？Googleが利用する代表的なクローラー

Googlebotとは、Google検索がWebページの情報を取得するために使用する代表的なクローラーです。

Googlebotは、すでに発見しているURLやページ内のリンクなどを手がかりに、インターネット上のWebページへアクセスします。

例えば、WordPressで新しい記事を公開し、トップページの新着記事一覧にその記事へのリンクが表示されたとします。

Googlebotがトップページをクロールすると、そのリンクから新しい記事のURLを発見する可能性があります。

Googlebotの代表的な種類には、次の2つがあります。

• Googlebot Smartphone： スマートフォンからのアクセスを再現するクローラー
• Googlebot Desktop： パソコンからのアクセスを再現するクローラー

Google検索では、モバイル版のページ内容を中心にインデックス登録を行う仕組みが採用されています。

そのため、スマートフォン用Googlebotの役割も重要です。

Googlebotの基本的な特徴を整理しました。

項目	内容
名称	Googlebot
運営元	Google
主な目的	Google検索のためのWebページ取得
主な種類	Smartphone・Desktop
URLの発見方法	リンクやサイトマップなど
巡回頻度	サイトやページの状況によって異なる

ただし、Googlebotがサイトを訪問したからといって、そのページが必ずインデックス登録されるわけではありません。

また、Googlebotの巡回回数が多いほど、検索順位が上がるという仕組みでもありません。

Google検索セントラルでは、Googlebotの種類と役割について公式に説明されています。

ブログ運営者は、Googlebotがページへ正常にアクセスできる状態を維持することが大切です。

クローラー・ボット・スパイダーの違い

クローラーについて調べると、「ボット」や「スパイダー」という言葉を見かけることがあります。

これらは似た意味で使われることがありますが、厳密には対象とする範囲が異なります。

まず、ボットとは、人間の代わりに自動的な処理を行うプログラムの総称です。

その中で、Webページを巡回し、情報を取得することを主な目的とするプログラムがクローラーです。

また、スパイダーは、Webページのリンクをたどりながら巡回するクローラーを表す別の呼び方です。

それぞれの違いを整理しました。

用語	意味	代表的な用途
ボット	自動処理を行うプログラムの総称	情報収集・自動応答など
クローラー	Webページを巡回して情報を取得するプログラム	検索エンジンの情報収集
スパイダー	クローラーの別称	リンクをたどる巡回
Googlebot	Google検索で利用されるクローラー	Webページの取得

例えば、問い合わせに自動回答するチャットボットも、広い意味ではボットの一種です。

しかし、チャットボットは通常、GooglebotのようにWebページを巡回することを主な目的としていません。

一方、Googlebotは、Webサイトを巡回するためのクローラーです。

Googleの公式資料でも、クローラーはロボットやスパイダーと呼ばれることがあると説明されています。

SEO初心者の方は、**「ボットは自動プログラムの総称で、クローラーはWebページを巡回するボットの一種」**と理解しておけば十分です。

GoogleはなぜWebサイトを巡回するのか？

GoogleがWebサイトを巡回する主な理由は、新しいページや更新された情報を発見し、検索サービスに役立てるためです。

インターネット上では、毎日多くのWebページが公開・更新・削除されています。

Googleが一度取得した情報だけを利用していると、新しい記事や修正された内容を検索結果に反映できなくなります。

そのため、Googlebotは新しいURLの発見だけでなく、公開済みページの再クロールも行っています。

例えば、WordPressで公開した「トマトの育て方」という記事について、収穫時期の説明を修正したとします。

Googlebotがそのページを再クロールすることで、変更された内容を取得できる場合があります。

GoogleがWebサイトを巡回する主な目的を整理しました。

巡回の目的	内容	具体例
新規ページの発見	新しいURLを見つける	公開されたブログ記事
更新内容の確認	変更された情報を取得する	古い操作手順の修正
リンクの発見	関連するURLを把握する	新しい関連記事
ページの状態確認	取得可能な状態か確認する	404エラーなど
検索情報の更新	検索用データの更新につなげる	修正された記事内容

例えば、WordPressの操作画面が変更された場合、以前の記事に新しいスクリーンショットや説明を追加することがあります。

Googlebotが再クロールすれば、その更新情報がGoogleの処理に利用される可能性があります。

ただし、記事を更新するたびに、必ずGooglebotがすぐに訪問するわけではありません。

Googleは、ページの状況や更新の必要性などに応じて、再クロールのタイミングを判断しています。

Googlebotの巡回は、新しい記事を見つけるだけでなく、検索に利用する情報を新しい状態に保つためにも重要です。

クローリングとインデックス登録の違い

クローリングとインデックス登録は、Google検索の仕組みを理解するうえで重要な用語です。

しかし、両者は同じ意味ではありません。

クローリングとは、GooglebotがWebページへアクセスして情報を取得する処理です。

一方、インデックス登録とは、取得した情報を分析し、Googleの検索用データベースに登録する処理を指します。

例えば、WordPressで「SEOとは？」という記事を公開した場合、Googlebotがそのページを取得しても、Googleがインデックス登録しないことがあります。

違いを表にまとめました。

比較項目	クローリング	インデックス登録
主な役割	ページの情報を取得する	検索用データベースに登録する
主な処理	Googlebotによるアクセス	Googleによる内容の分析・登録判断
処理の結果	ページを取得する	登録される場合がある
確認方法	Search Consoleのクロール情報	URL検査の登録状況
検索結果への表示	保証されない	登録済みでも表示は保証されない

例えば、Search Consoleで次のように表示される場合があります。

「検出 – インデックス未登録」

GoogleがURLを発見しているものの、まだクロールしていない状態です。

「クロール済み – インデックス未登録」

Googleがページを取得したものの、インデックス登録していない状態です。

この違いを理解しておくと、記事がGoogle検索に表示されない場合に、どの段階を確認すればよいか判断しやすくなります。

Google公式資料でも、クロール、インデックス登録、検索結果の表示は別の段階として説明されています。

クローリングからインデックス登録、検索順位の決定まで、Google検索全体の流れを詳しく知りたい方は、「Google検索の仕組みとは？クローラーから表示までを初心者向けに解説」も参考にしてください。

クローラーの仕組みを理解することがSEOに役立つ理由

クローラーの仕組みを理解すると、なぜ内部リンクやXMLサイトマップ、サーバーの設定などがSEO対策で重要なのか分かりやすくなります。

例えば、どれほど詳しい記事を作成しても、Googlebotがそのページへアクセスできなければ、内容を正常に取得できません。

また、記事が公開されていても、サイト内のどこからもリンクされていない場合、GoogleがURLを発見する手がかりが少なくなることがあります。

Googlebotが巡回しやすい状態を整えるために、初心者が意識したいのは次の点です。

• 記事を正常に公開する
• カテゴリーと内部リンクを整理する
• XMLサイトマップを適切に管理する
• robots.txtの設定を確認する
• サーバーエラーを放置しない
• パーマリンク変更時には適切な転送設定を行う
• Search Consoleでクロール状況を確認する

クローラーの仕組みとSEO対策の関係を整理しました。

クローラーに関係する項目	SEOで意識したい対策
URLの発見	内部リンク・XMLサイトマップ
ページへのアクセス	robots.txt・サーバー設定
コンテンツの取得	HTMLやJavaScriptの正常な表示
再クロール	更新後の状態確認
エラーの発生	404・500エラーなどの調査
巡回状況の確認	Search Consoleの活用

例えば、WordPressで記事のURLを変更した場合、旧URLから新URLへ適切に301リダイレクトすることが重要です。

また、リンク切れやサーバーエラーが発生している場合は、必要に応じて修正しましょう。

ただし、Googlebotの巡回回数を増やすこと自体が検索順位を上げる対策ではありません。

クローラーが正常に情報を取得できる状態を整え、読者に役立つ内容を提供することがSEO対策の基本です。

Googlebotにはどのような種類がある？

Googlebotには、スマートフォン用とパソコン用のWebクローラーがあります。

それぞれ異なる端末からのアクセスを再現し、Webページの情報を取得する役割を持っています。

また、GoogleにはGooglebot以外にも、画像検索や各種Googleサービスに関連するクローラーがあります。

ブログ運営者は、Googlebotの種類だけでなく、モバイルファーストインデックスやユーザーエージェントの仕組みを理解しておくと、クロールに関する問題を調べやすくなります。

ここでは、Googlebotの種類と役割、端末による違い、本物のGooglebotを確認する方法まで解説します。

スマートフォン用Googlebotとは？

スマートフォン用Googlebot（Googlebot Smartphone）は、スマートフォンからWebサイトへアクセスする状態を再現して、ページの情報を取得するクローラーです。

例えば、WordPressで公開した記事をスマートフォンで開くと、画面の幅に合わせて文章や画像、メニューなどが表示されます。

スマートフォン用Googlebotも、モバイル環境を想定してページへアクセスします。

Google検索では、モバイル版のコンテンツがインデックス登録やランキングの主な情報源として利用されています。

そのため、スマートフォンでも重要な内容を正常に取得できる状態にすることが大切です。

主な確認項目を整理しました。

確認項目	内容
本文	スマートフォンでも全文を確認できるか
画像	正常に読み込まれるか
見出し	H2・H3の内容が表示されるか
内部リンク	リンク先へ移動できるか
JavaScript	重要な内容の表示に問題がないか
アクセス制限	モバイルクローラーが妨げられていないか

例えば、パソコンでは記事全文が表示されていても、スマートフォンでは重要な説明が読み込まれない場合、Googleによるページの理解に影響する可能性があります。

WordPressのCocoonはレスポンシブデザインに対応していますが、個別の記事やプラグインの設定によって表示に問題が生じることもあります。

そのため、公開前にはスマートフォン表示も確認しましょう。

Googleの公式資料でも、スマートフォン用Googlebotはモバイル端末でのアクセスを再現するクローラーとして説明されています。

パソコン用Googlebotとは？

パソコン用Googlebot（Googlebot Desktop）は、パソコンからWebサイトへアクセスする状態を再現するクローラーです。

Googlebot Smartphoneと同じく、Webページの情報を取得するために利用されます。

ただし、Google検索ではモバイル版のコンテンツが中心となっているため、スマートフォン用Googlebotとパソコン用Googlebotの役割を同じものとして考える必要はありません。

両者の違いを整理しました。

比較項目	スマートフォン用	パソコン用
名称	Googlebot Smartphone	Googlebot Desktop
再現する環境	モバイル端末	デスクトップ端末
主な役割	モバイル版ページの取得	デスクトップ版ページの取得
robots.txtのトークン	Googlebot	Googlebot
検索での位置付け	モバイルファーストの中心	補助的な取得など

例えば、パソコン用ページだけに重要な説明があり、スマートフォン用ページには掲載されていない場合、Googleが取得できる情報に差が生じる可能性があります。

ただし、パソコン用Googlebotが不要になったわけではありません。

Googleは両方のクローラーを使用しています。

なお、robots.txtのGooglebotというユーザーエージェントトークンでは、スマートフォン用とパソコン用を別々に指定することはできません。

ブログ運営者は、特定のGooglebotを無理に優先させるのではなく、どちらの環境でも必要な情報を取得できるサイトを目指しましょう。

モバイルファーストインデックスとの関係

モバイルファーストインデックスとは、Googleが主にスマートフォン用Googlebotで取得したモバイル版コンテンツを、インデックス登録やランキングに利用する仕組みです。

以前はパソコン向けのページが中心でしたが、現在はモバイル版の内容を重視する仕組みになっています。

例えば、WordPressで長い解説記事を公開している場合、パソコン版だけでなくスマートフォン版でも本文や画像、見出しなどを確認できる必要があります。

モバイルファーストインデックスで注意したい項目を整理しました。

項目	確認したいこと
本文	パソコン版とモバイル版で重要な内容が一致しているか
見出し	モバイル版でも適切に表示されるか
画像	重要な画像を取得できるか
メタ情報	title要素やrobots設定に違いがないか
構造化データ	必要な情報がモバイル版にもあるか
ページの取得	Googlebotがアクセスできるか

例えば、パソコン版には「SEO対策の手順」が全文掲載されていても、モバイル版では説明の半分が削除されている場合、Googleが利用できる情報が少なくなる可能性があります。

一方、スマートフォン向けに本文を折りたたみ表示していても、Googleがその内容を正常に取得できる構造なら、必ずしも問題になるわけではありません。

Googleは、モバイル版とパソコン版で重要なコンテンツを同等にすることを推奨しています。

初心者の方は、スマートフォンで実際に記事を開き、本文・画像・リンクが正常に表示されるか確認することから始めましょう。

Googlebotと画像・動画向けクローラーの違い

Googleには、通常のWebページを取得するGooglebotだけでなく、画像や動画などの情報を扱うGoogle検索機能もあります。

例えば、家庭菜園の記事にトマトの写真を掲載した場合、その画像がGoogle画像検索で利用される可能性があります。

また、動画を埋め込んだ解説記事では、Googleが動画に関する情報を発見・処理する場合があります。

ただし、「Googlebot Image」「Googlebot Video」という名前の独立した代表的クローラーが、必ずそれぞれの画像・動画を巡回するという単純な仕組みではありません。

Googleの公式資料では、通常のGooglebotがGoogle画像検索やGoogle Videoなどにも関係することが示されています。

検索機能と確認したい情報を整理しました。

対象	主な情報	ブログでの確認例
Webページ	本文・HTML・リンク	記事が正常に取得できるか
画像検索	画像・alt属性・周囲の文章など	写真が表示されるか
動画検索	動画・掲載ページ・関連情報	動画を正常に利用できるか
ニュース検索	記事内容・公開情報など	ニュース記事の状態

例えば、釣りの仕掛けを説明する記事では、図解画像と本文を組み合わせることで、読者が内容を理解しやすくなります。

画像を掲載するときは、次の点を確認しましょう。

• 画像のURLが正常に開けるか
• robots.txtなどで取得を妨げていないか
• alt属性が画像の内容に合っているか
• 画像の周囲に関連する説明があるか
• スマートフォンでも表示されるか

画像や動画を増やしただけで検索順位が上がるわけではありません。

本文と関連する情報を適切な形式で提供することが大切です。

Googlebotのユーザーエージェントとは？

ユーザーエージェント（User-Agent）とは、Webサーバーへアクセスするプログラムが、自分の種類や実行環境などを伝えるために使用する情報です。

通常のブラウザがアクセスする場合にもユーザーエージェントが送信されます。

GooglebotもWebサーバーにアクセスするとき、Googlebotであることを示すユーザーエージェント文字列を送信します。

例えば、サーバーのアクセスログには、Googlebotの名前を含むリクエストが記録される場合があります。

ユーザーエージェントに関する用語を整理しました。

用語	意味
User-Agent	アクセス元のプログラム情報を示すHTTPヘッダー
Googlebot	Google検索用クローラーの識別名
Googlebot Smartphone	モバイル端末を再現するGooglebot
Googlebot Desktop	パソコン環境を再現するGooglebot
アクセスログ	サーバーへのリクエスト履歴
robots.txt	クローラーのアクセスを制御するルール

例えば、Googlebotのユーザーエージェントには、次のような識別子が含まれます。

Googlebot/2.1

これは識別子の一例であり、実際のユーザーエージェント文字列全体はもっと長い場合があります。

また、ブラウザやGooglebotのバージョンに関する情報は変更されることがあります。

そのため、ユーザーエージェント文字列を確認するときは、Googleの最新の公式資料を参考にしましょう。

なお、ユーザーエージェントにGooglebotと書かれていても、本物のGooglebotとは限りません。

この点は、次の項目で説明します。

Googlebotを装う不正なアクセスとの見分け方

Webサイトのアクセスログに「Googlebot」という名前が表示されていても、そのアクセスが必ずGoogleから送信されたとは限りません。

ユーザーエージェント文字列は、アクセスするプログラム側で変更できるためです。

そのため、Googlebotを装った不正なクローラーや自動アクセスが存在する場合があります。

例えば、短時間に大量のアクセスがあり、ユーザーエージェントにGooglebotと表示されていても、それだけでGoogleの正式なクローラーとは判断できません。

Google公式資料では、Googlebotの正当性を確認する方法として、送信元IPアドレスや逆引きDNSなどを利用する手順が紹介されています。

代表的な確認方法を整理しました。

確認方法	内容	初心者向けの考え方
User-Agentの確認	Googlebotの識別子があるか	これだけでは本物と断定できない
IPアドレスの確認	アクセス元を調べる	サーバーログなどを利用
逆引きDNS	IPアドレスからホスト名を確認	技術的な調査が必要
正引きDNS	ホスト名が元のIPアドレスへ戻るか確認	なりすまし判定に役立つ
Google公開のIP範囲	公式のIP情報と照合	信頼できる確認方法

例えば、サーバー管理画面で大量のアクセスが確認された場合、すぐにGooglebotをブロックするのは避けましょう。

本物のGooglebotを誤って遮断すると、Googleによるクローリングに影響する可能性があります。

確認するときは、次の順番がおすすめです。

1. サーバーのアクセスログを確認する
2. アクセス元のIPアドレスを調べる
3. ユーザーエージェントを確認する
4. 必要に応じて逆引きDNS・正引きDNSを確認する
5. Google公式のIP範囲と照合する
6. 不審なアクセスと判断した場合に、必要なセキュリティ対策を検討する

IPアドレスやDNSの確認は、初心者にとって難しい場合があります。

その場合は、レンタルサーバーのサポートやセキュリティに詳しい専門家へ相談する方法もあります。

WordPressでセキュリティプラグインを利用している場合も、Googlebotを誤ってブロックしていないか注意しましょう。

本物のGooglebotと不正な自動アクセスを区別するには、ユーザーエージェントの名前だけで判断しないことが重要です。

GoogleクローラーがWebサイトを巡回する仕組み

Googlebotは、インターネット上のWebページを自動的に発見し、必要に応じてアクセスして情報を取得するクローラーです。

例えば、WordPressで新しい記事を公開すると、Googlebotはトップページやカテゴリー一覧、XMLサイトマップなどを手がかりに、その記事のURLを発見することがあります。

しかし、URLを発見しただけで、必ずページがクロールされるわけではありません。

Googleは、ページの状況やサーバーの応答などを考慮しながら、取得するURLやタイミングを判断しています。

ここでは、Googlebotが新しいURLを見つける方法から、内部リンク・外部リンクの役割、Webサーバーへのアクセス、HTMLやJavaScriptの取得まで、巡回の仕組みを詳しく解説します。

Googlebotは新しいURLをどこから発見する？

Googlebotは、インターネット上のすべてのURLを最初から把握しているわけではありません。

すでにGoogleが知っているページやXMLサイトマップなどを手がかりに、新しいURLを発見しています。

この処理は「URL検出」と呼ばれています。

例えば、WordPressで「トマトの育て方」という記事を公開し、トップページの新着記事一覧にリンクが表示されたとします。

Googlebotがトップページをクロールすると、そのリンクから新しい記事のURLを発見する可能性があります。

GooglebotがURLを見つける主な方法は次のとおりです。

• すでに発見しているページのリンクをたどる
• トップページやカテゴリー一覧から記事を発見する
• ほかのWebサイトからのリンクを確認する
• XMLサイトマップに記載されたURLを見つける
• 過去に取得したページのURLを再確認する

URL発見の方法を整理しました。

発見方法	仕組み	ブログでの具体例
トップページ	掲載されたリンクを確認	新着記事一覧
カテゴリー	同じカテゴリー内のURLを発見	Google検索（SEO）の記事一覧
内部リンク	関連する記事のリンクをたどる	SEO入門記事から個別記事へ
外部リンク	別サイトからのリンクを確認	他サイトで紹介された記事
XMLサイトマップ	URL一覧を参照	WordPressのサイトマップ

ただし、URLを発見しても、Googlebotがすぐにクロールするとは限りません。

Googleは、取得するページやタイミングを自動的に判断しています。

Google検索セントラルでも、既知のページに掲載されたリンクやサイトマップから新しいURLを発見すると説明されています。

ブログ運営者は、新しく公開した記事がサイト内のリンクから見つけられるようにしておくことが大切です。

内部リンクをたどってページを巡回する仕組み

内部リンクとは、同じWebサイト内のページ同士をつなぐリンクのことです。

Googlebotは、ページを取得した際に、そのページに掲載されたリンクから別のURLを発見することがあります。

例えば、WordPressで次のような記事を公開しているとします。

• Google検索（SEO）完全ガイド
• Google検索の仕組み
• クローラーとは？
• インデックス登録についての記事

これらの記事を適切な内部リンクでつなぐことで、読者は関連する情報を続けて読むことができます。

Googlebotにとっても、新しいURLを発見する手がかりになります。

内部リンクの基本的な構造を整理しました。

ページ	リンク先の例	役割
トップページ	カテゴリー一覧	記事を探す入口
カテゴリー一覧	個別記事	関連する記事を整理
完全ガイド	詳しい解説記事	テーマ別の情報へ案内
個別記事	関連する別記事	必要な情報を補足

例えば、「Google検索の仕組み」という記事の中から「クローラーとは？」という記事へリンクを設置すると、読者はGooglebotについて詳しく学べます。

ただし、内部リンクを増やせば必ずクロール頻度が上がるわけではありません。

内部リンクを設置するときは、次の点に注意しましょう。

• リンク先の記事が公開されているか
• リンク先URLに誤りがないか
• 記事の内容と関連しているか
• リンク先の内容が分かる文章になっているか
• 同じリンクを必要以上に繰り返していないか
• 重要な記事が孤立ページになっていないか

孤立ページとは、サイト内のほかのページから内部リンクでたどれないページのことです。

孤立ページでもXMLサイトマップなどからGoogleが発見する可能性はありますが、読者やGooglebotがページを見つける手がかりは少なくなります。

Google公式資料でも、重要なページへリンクからアクセスできる構造が推奨されています。

内部リンクは、Googlebotのためだけでなく、読者が必要な情報を探しやすくするために整えることが基本です。

外部リンクから新しいWebサイトを発見する方法

Googlebotは、同じWebサイト内のリンクだけでなく、異なるWebサイトに掲載されたリンクから新しいURLを発見することもあります。

例えば、家庭菜園に関するブログの記事が、別のWebサイトで参考情報として紹介されたとします。

Googlebotが紹介元のページを取得すると、そのリンクから紹介先の記事URLを発見する可能性があります。

このように、別のWebサイトから自分のページへ向けられたリンクを「被リンク」と呼びます。

リンクの種類を整理しました。

リンクの種類	意味	具体例
内部リンク	同じサイト内へのリンク	関連記事への案内
外部へのリンク	別のサイトへのリンク	Google公式資料へのリンク
被リンク	他サイトから受けるリンク	自分の記事が紹介される

例えば、「WordPressの初期設定」を解説した記事が、初心者向けの情報サイトから紹介されれば、Googleがそのリンクを通じてURLを発見する手がかりになります。

ただし、すべてのリンクがGooglebotによって必ずたどられるわけではありません。

リンクの設定やアクセス制限、Google側の判断などによって、リンク先が取得されない場合もあります。

ブログ運営者が意識したいのは、次の点です。

• 読者に役立つ記事を作成する
• 情報の出典を明示する
• 信頼できる公式資料を参考にする
• 不自然な相互リンクを増やさない
• リンクを購入して検索順位を操作しようとしない

特に、検索順位を操作する目的で不自然なリンクを大量に設置する行為には注意が必要です。

外部リンクや被リンクは、自然な情報のつながりとして考えましょう。

XMLサイトマップがURL発見に役立つ理由

XMLサイトマップとは、Webサイト内の重要なURLなどの情報を検索エンジンへ伝えるためのファイルです。

Googlebotは、XMLサイトマップを参考にして、まだ発見していないページや更新されたページを見つけることがあります。

例えば、WordPressで数百本の記事を公開している場合、すべての記事がトップページから直接リンクされているとは限りません。

そのような場合に、XMLサイトマップがURL発見の補助的な役割を果たします。

XMLサイトマップに関係する主な情報を整理しました。

項目	役割
URL	ページの場所を知らせる
最終更新日時	実際の更新状況を伝える手がかり
サイトマップインデックス	複数のサイトマップをまとめる
Search Consoleへの送信	サイトマップの場所を知らせる

例えば、WordPressでは、次のようなURLでXMLサイトマップが提供される場合があります。

https://example.com/wp-sitemap.xml

ただし、利用しているプラグインやテーマなどによって、実際のサイトマップURLは異なります。

XMLサイトマップを確認するときは、次の点を意識しましょう。

• サイトマップが正常に開けるか
• 公開済みの記事が適切に含まれているか
• 古いURLが不必要に残っていないか
• Search Consoleで取得できているか
• サイトマップ生成機能が重複していないか

Googleに伝える最終更新日時は、実際にページへ意味のある変更を加えた場合に更新することが大切です。

ただし、XMLサイトマップを送信したからといって、すべてのURLが必ずクロールされるわけではありません。

また、サイトマップの送信自体が検索順位を直接上げるものでもありません。

XMLサイトマップは、Googlebotが重要なURLを発見するための補助的な仕組みと理解しましょう。

GooglebotがWebサーバーへアクセスする流れ

GooglebotがWebページをクロールするときは、そのページを公開しているWebサーバーへアクセスします。

例えば、WordPressで作成した記事は、レンタルサーバーなどに保存された情報を基に表示されます。

Googlebotも、記事のURLにアクセスしてサーバーからHTMLなどを取得します。

基本的な流れは次のとおりです。

1. Googlebotがクロール対象のURLを選ぶ
2. robots.txtなどのクロール制限を確認する
3. 必要に応じてURLのサーバーへアクセスする
4. サーバーがHTTPレスポンスを返す
5. Googlebotがページの情報を取得する
6. 必要に応じて追加のリソースを読み込む
7. 取得した情報を後続の処理へ渡す

ここで重要になるのが、HTTPステータスコードです。

HTTPステータスコードとは、サーバーがリクエストに対して返す応答状態を示す番号です。

代表的なコードを整理しました。

ステータス	意味	Googlebotへの影響
200	正常に取得できた	ページ内容を取得できる
301	恒久的な転送	転送先URLの確認につながる
403	アクセス禁止	ページを取得できない
404	ページが存在しない	通常のページ内容を取得できない
429	リクエストが多すぎる	クロール頻度が調整される可能性
500	サーバー内部エラー	正常に取得できない
503	一時的に利用できない	再試行やクロール調整の対象になる

例えば、サーバーが500エラーを返している場合、Googlebotはページの内容を正常に取得できません。

また、エラーが続くと、Googleがサイトへのクロール頻度を減らす場合があります。

Googleの公式資料でも、サーバーの応答状況を考慮してクロール速度が調整されると説明されています。

ブログ運営者は、記事が正常に表示されることに加えて、サーバーエラーが長期間続いていないか確認しましょう。

HTML・CSS・JavaScriptを取得する仕組み

Webページは、HTML・CSS・JavaScriptなどの技術を利用して構成されています。

Googlebotは、ページのHTMLを取得した後、必要なリソースを読み込み、レンダリングによってページの内容を確認します。

レンダリングとは、HTMLやCSS、JavaScriptなどを処理して、ブラウザで表示されるようなページの状態を構成することです。

それぞれの役割を整理しました。

技術	主な役割	WordPressでの例
HTML	ページの構造と内容	本文・見出し・リンク
CSS	デザインと表示方法	文字色・余白・レイアウト
JavaScript	動的な動作や表示	メニュー・一部の画像表示
画像ファイル	視覚的な情報	アイキャッチ・図解

例えば、WordPressで作成した記事にJavaScriptを利用した画像表示機能がある場合、Googleは必要に応じてJavaScriptを実行してページ内容を確認します。

Googleは、レンダリングにChromiumベースの環境を使用しています。

ただし、JavaScriptを利用していること自体がSEOに悪いわけではありません。

重要なのは、Googleが必要な情報を正常に取得できることです。

初心者が確認したい項目は次のとおりです。

• 記事の本文が正常に表示されるか
• 重要な画像が読み込まれているか
• 内部リンクが正しく動作しているか
• JavaScriptのエラーで本文が消えていないか
• robots.txtで必要なリソースを遮断していないか
• スマートフォンでも主要な内容を確認できるか

例えば、WordPressの高速化プラグインでJavaScriptの読み込み設定を変更した後、メニューや画像が表示されなくなる場合があります。

そのようなときは、表示に問題がないか確認し、必要に応じて設定を見直しましょう。

特に、GooglebotがアクセスできないJavaScriptやCSSが重要なコンテンツの表示に影響している場合は注意が必要です。

ページがブラウザで表示されるだけでなく、Googleにも主要な情報を取得できる状態にしておくことが大切です。

GooglebotがすべてのURLを巡回するわけではない理由

Googlebotは、インターネット上に存在するすべてのURLを巡回するわけではありません。

Googleは非常に多くのWebページを扱っているため、取得するページやクロール頻度を自動的に判断しています。

また、URLが発見されていても、アクセス制限やサーバーの問題などによってクロールできない場合があります。

代表的な理由を整理しました。

理由	内容
URLが未発見	Googleがページを認識していない
クロール待ち	URLは発見されているが未取得
robots.txt	クロールが禁止されている
ログイン制限	Googlebotがページへアクセスできない
サーバーエラー	ページを正常に取得できない
URLの重複や増加	クロール対象の選択や効率に影響する
クロールの必要性	Googleが取得の必要性を判断する

例えば、WordPressで記事を公開しても、サイト内にその記事へのリンクがなく、XMLサイトマップにも掲載されていない場合、GoogleがURLを発見する手がかりは少なくなります。

また、検索結果に表示する必要のないURLが大量に生成されている場合、クロール効率に影響することがあります。

ただし、URLが発見されていてもクロールされない状態だけで、その記事の品質が低いと断定することはできません。

Googleは、すべてのURLを取得できるわけではなく、クロール能力や必要性などを考慮して処理すると説明しています。

記事がクロールされない場合は、次の順番で確認しましょう。

1. WordPressで正常に公開されているか
2. 記事のURLが開けるか
3. 内部リンクやXMLサイトマップに問題がないか
4. robots.txtでアクセスを禁止していないか
5. サーバーエラーが発生していないか
6. Search Consoleで現在の状態を確認する

Googlebotがすぐに訪問しない場合でも、技術的な問題が見つからなければ、必ずしも記事を書き直す必要はありません。

Googlebotの巡回頻度はどのように決まる？

Googlebotは、すべてのWebサイトを毎日同じ回数だけ巡回しているわけではありません。

Googleは、ページの更新状況やクロールの必要性、サーバーの応答状態などを考慮しながら、巡回する頻度を自動的に調整しています。

例えば、新しい情報が頻繁に掲載されるページと、長期間更新されていないページでは、再クロールの必要性が異なる場合があります。

また、Googlebotが巡回する回数を増やせば、必ず検索順位が上がるわけでもありません。

ここでは、Googlebotの巡回頻度が決まる仕組み、新しい記事のクロールにかかる時間、再クロールの特徴、サーバーとの関係について詳しく解説します。

Googlebotは毎日Webサイトを巡回するのか？

Googlebotは、必ず毎日すべてのWebサイトを巡回するわけではありません。

Webサイトの規模や内容、更新状況、サーバーの状態などによって、クロール頻度は異なります。

例えば、毎日新しい情報が追加されるサイトと、数か月間ほとんど更新されていない個人ブログでは、Googleがクロールする必要性が異なる場合があります。

ただし、毎日記事を公開すれば、必ずGooglebotが毎日訪問するという仕組みでもありません。

Googlebotの巡回頻度に関係する要素を整理しました。

要素	巡回頻度との関係
新しい記事の公開	新しいURLを取得する必要性が生じる
既存記事の更新	内容を再確認する必要性に関係する
ページの人気度	再クロールの需要に関係する
サーバーの安定性	クロール可能な量に影響する
不要なURLの増加	クロール効率に影響する場合がある

例えば、WordPressで週に数本の記事を公開している場合、Googlebotがどのタイミングで記事を取得するかは一定ではありません。

また、Googlebotがトップページをクロールしたとしても、その日にすべての個別記事を取得するわけではありません。

ブログ運営者は、Googlebotが毎日来るかどうかよりも、重要な記事へ正常にアクセスできる状態になっているかを確認しましょう。

新しい記事がクロールされるまでの時間

新しい記事がGooglebotにクロールされるまでの時間は、Webサイトによって異なります。

Googleの公式資料では、新しいページが認識されるまでに数日かかることがあり、クロールや再クロールには数日から数週間かかる場合があると説明されています。

ただし、これはすべての記事に共通する決まった期間ではありません。

例えば、記事を公開して翌日にクロールされる場合もあれば、さらに時間がかかる場合もあります。

クロールまでの時間に関係する項目を整理しました。

確認項目	内容
公開状態	記事が正常に公開されているか
内部リンク	公開記事へのリンクがあるか
XMLサイトマップ	URLが適切に掲載されているか
アクセス制限	robots.txtなどで遮断されていないか
サーバー	正常に応答しているか
Search Console	URLが発見されているか

例えば、Search Consoleで「検出 – インデックス未登録」と表示された場合は、GoogleがURLを認識しているものの、まだクロールしていない状態です。

この場合、公開直後であれば、Googleの処理を待つことが適切な場合もあります。

一方、長期間クロールされない場合は、内部リンクやサーバーの状態などを確認しましょう。

ただし、サイトマップを繰り返し送信したり、登録リクエストを何度も行ったりしても、必ずクロールが早くなるわけではありません。

更新した記事が再クロールされる仕組み

Googlebotは、新しい記事だけでなく、過去に取得したページを再びクロールすることがあります。

これを「再クロール」と呼びます。

再クロールは、公開済みページに新しい情報が追加されたり、既存の内容が変更されたりした場合などに行われます。

例えば、WordPressの操作方法を解説した記事で、管理画面の変更に合わせてスクリーンショットを差し替えたとします。

Googlebotがそのページを再クロールすれば、更新された内容を取得できる場合があります。

更新内容と確認項目を整理しました。

更新内容	確認したいこと
本文を修正	新しい文章が正常に表示されるか
画像を追加	画像を正常に取得できるか
タイトルを変更	本文と一致しているか
内部リンクを修正	リンク先が正常に開くか
URLを変更	301リダイレクトが適切か
ページを削除	正しいHTTPステータスを返すか

記事を更新する際は、次の点を意識しましょう。

• 読者にとって必要な情報を修正する
• 古い操作手順や画像を見直す
• 更新後のURLが正常に開けるか確認する
• 内部リンクや公開設定を確認する
• 重要な変更を行った場合は必要に応じて再クロールをリクエストする

ただし、更新した直後に必ず再クロールされるわけではありません。

また、再クロールされたとしても、検索順位が上がる保証はありません。

更新日だけを変更することよりも、読者に役立つ情報を正確に提供することが大切です。

ページの重要性や更新状況と巡回頻度の関係

Googlebotの巡回頻度には、ページの人気度や更新状況などが関係します。

Googleは、すでに取得したページの情報を必要に応じて更新するため、再クロールする対象を判断しています。

例えば、頻繁に内容が変わるニュースページと、内容がほとんど変化しない解説ページでは、情報を再取得する必要性が異なります。

ただし、更新頻度が高ければ必ずクロール回数が増えるとは限りません。

Google公式資料では、クロールの必要性に関係する要素として、人気度や情報の古さ、サイト内のURLの状況などを挙げています。

主な要素を整理しました。

要素	Googlebotとの関係
人気度	人気のあるURLは再クロールされやすい傾向がある
情報の古さ	変更内容を確認する必要性に関係する
更新状況	新しい情報の取得が必要になる場合がある
URLの重複	クロール効率に影響することがある
サイトの移転	新URLの再処理が必要になる

例えば、家庭菜園の記事で栽培方法を最新の知見に合わせて修正した場合、Googlebotが再クロールすることで変更内容を取得できる可能性があります。

ただし、数行の文章を変更するたびに再クロールを要求する必要はありません。

初心者の方は、次の点を意識しましょう。

• 必要な情報を正確に更新する
• 内容が変わっていない記事を無理に変更しない
• 更新日を操作して巡回を増やそうとしない
• 重要な記事がサイト内で見つけやすい状態にする
• Search Consoleで必要な情報を確認する

巡回頻度を増やすことを目的に更新するのではなく、記事の内容を維持・改善することを優先しましょう。

サーバーの応答速度やエラーが巡回に与える影響

GooglebotがWebサイトを巡回するときは、サーバーへHTTPリクエストを送信します。

そのため、サーバーの応答速度やエラーの発生状況は、Googlebotが取得できるページ数などに関係します。

例えば、サーバーが安定して応答していれば、Googleはクロールを継続しやすくなります。

一方、サーバーの応答が極端に遅くなったり、500エラーなどが繰り返し発生したりすると、Googleがクロールの負荷を抑える場合があります。

主な状況を整理しました。

サーバーの状態	巡回への影響
正常な応答	Googlebotがページを取得できる
応答が遅い	クロール量が調整される可能性
500エラー	ページの取得に失敗する
503エラー	一時的な利用不可として処理される
429エラー	リクエストの制限として扱われる

例えば、WordPressのプラグイン更新後に500エラーが発生した場合、Googlebotも記事を正常に取得できない可能性があります。

そのような場合は、次の順番で確認しましょう。

1. サイトが正常に表示されるか確認する
2. 複数の記事でエラーが発生していないか調べる
3. 最近変更したプラグインや設定を確認する
4. 必要に応じてサーバーの管理画面やログを確認する
5. 問題が解決した後にSearch Consoleで状態を調べる

Googleは、サーバーの応答状況に応じてクロール能力の上限を調整すると説明しています。

ただし、ページの表示速度を改善すれば、必ずクロール回数が増えるわけではありません。

Googlebotのためにも読者のためにも、安定してページを表示できる環境を維持することが重要です。

Googlebotの巡回回数を自由に指定できるのか？

Googlebotの巡回回数を、サイト運営者が自由に指定することはできません。

例えば、「1日に100回巡回してほしい」「新しい記事を毎時間取得してほしい」と設定しても、その希望どおりにGooglebotが動くわけではありません。

Googleは、クロール能力とクロールの必要性などを考慮して、各サイトへの巡回を自動的に調整しています。

巡回に関する操作と、その役割を整理しました。

操作	できること	できないこと
XMLサイトマップの送信	URLの発見を助ける	クロール時刻の指定
内部リンクの整理	ページを発見しやすくする	毎日の巡回保証
登録リクエスト	クロールを依頼する	即時クロールの保証
robots.txtの設定	特定URLのクロールを制限する	巡回回数を増やす
サーバー改善	クロールを妨げる問題を減らす	検索順位の保証

初心者が注意したいのは、次の点です。

• 巡回回数を増やす目的で登録リクエストを繰り返さない
• サイトマップを何度も送信しない
• robots.txtを使ってクロール頻度を増やそうとしない
• 検索順位とクロール回数を同じ指標として考えない

Googlebotの巡回を必要以上に増やそうとするより、サーバーの状態やURL構造を整えることが大切です。

なお、robots.txtに記述する従来のcrawl-delay指定は、Googlebotではサポートされていません。

巡回頻度を増減させる独自の命令を追加しても、Googlebotが希望どおりに動くわけではありません。

Googlebotがしばらく来ない場合の考え方

Googlebotが記事をしばらくクロールしていない場合でも、必ずしもサイトに問題があるとは限りません。

Googleは、ページの状況や更新の必要性などに応じて、再クロールするタイミングを判断しています。

例えば、内容がほとんど変わっていない記事では、再クロールまでに時間がかかる場合があります。

一方、新しい記事を公開してから長期間クロールされていない場合は、URLの発見状況やアクセス制限などを確認するとよいでしょう。

確認したい項目を整理しました。

確認項目	チェックすること
記事の公開状態	WordPressで正常に公開されているか
URL	正常に表示されるか
内部リンク	ほかの記事からアクセスできるか
XMLサイトマップ	URLが適切に掲載されているか
robots.txt	クロールを禁止していないか
サーバー	エラーが発生していないか
Search Console	URLの検出・最終クロール状況

初心者の方は、次の手順で確認しましょう。

ステップ1：記事のURLを開く

まず、公開ページが正常に表示されるか確認します。

ステップ2：内部リンクを確認する

カテゴリー一覧や関連記事から移動できるか調べます。

ステップ3：XMLサイトマップを確認する

対象記事のURLが適切に掲載されているか確認します。

ステップ4：Search ConsoleでURL検査を行う

GoogleがURLを認識しているか、最後にいつクロールしたかなどを調べます。

ステップ5：クロールを妨げる問題を確認する

robots.txtやサーバーエラーなどが発生していないか確認します。

ステップ6：必要な問題を修正する

技術的な問題が見つかった場合は修正し、必要に応じて再クロールをリクエストします。

Google公式資料でも、長期間クロールされない場合は、URLの認識状況やアクセス制限、サーバーの処理能力などを調べる方法が示されています。

ただし、登録リクエストを送信しても、すぐにGooglebotが訪問するとは限りません。

また、クロールされたとしても、インデックス登録や検索上位表示が保証されるわけではありません。

Googlebotが来ないという理由だけで記事を削除せず、まずはURLの状態と技術的な問題の有無を確認しましょう。

クロールバジェットとは？巡回できるURL数との関係

クロールバジェットとは、GooglebotがWebサイトを巡回するときに、Googleがそのサイトへ割り当てるクロールのリソースを表す考え方です。

Googleは、インターネット上のすべてのURLを無制限に巡回できるわけではありません。そのため、Webサイトの規模や更新状況、サーバーの応答などを考慮して、クロールするページや頻度を自動的に判断しています。

例えば、数百記事の個人ブログと、数百万ページを持つ大規模サイトでは、クロールに必要なリソースが異なります。

ここでは、クロールバジェットの基本から、クロール能力と需要の違い、URLの重複が巡回効率に与える影響まで解説します。

クロールバジェットの意味と基本的な仕組み

クロールバジェットとは、Googleが特定のWebサイトについて、クロールできる量とクロールする必要性を考慮して決める、巡回対象の範囲を指します。

例えば、サイト内に10万ページあったとしても、Googlebotがそのすべてを一度に取得するわけではありません。

Googleはサーバーへの負荷を抑えながら、必要と判断したURLをクロールします。

クロールバジェットは、主に次の2つの要素で決まります。

• クロール能力の上限： サーバーに負荷をかけすぎずに取得できる量
• クロール需要： Googleがそのサイトのページを取得・再取得する必要性

クロールバジェットの基本を整理しました。

項目	内容	具体例
クロール能力	サーバーの状態などに応じた取得能力	サーバーが安定して応答できる
クロール需要	Googleが取得したいページの量	新しい記事や更新されたページ
クロールバジェット	取得能力と需要を考慮した巡回対象	Googleが取得するURLの集合
クロール効率	重要なURLを無駄なく取得できるか	重複URLを適切に整理する

例えば、同じ内容を表示するURLが大量に存在すると、GooglebotがそれらのURLを確認するためにリソースを使う場合があります。

その結果、重要なページの発見や再クロールに影響する可能性があります。

ただし、クロールバジェットは「1日100ページまで」といった固定の上限ではありません。

Google公式資料では、クロールバジェットはクロール能力の上限とクロール需要によって決まると説明されています。

初心者の方は、まず「GoogleがすべてのURLを無制限に巡回するわけではない」と理解しておきましょう。

クロール能力とクロール需要の違い

クロール能力とクロール需要は、クロールバジェットを理解するための重要な要素です。

クロール能力は、WebサイトのサーバーがGooglebotからのアクセスにどの程度対応できるかに関係します。

一方、クロール需要は、Googleがページの情報を新しく取得する必要性を示しています。

例えば、サーバーが正常に動作していても、更新されるページが少なければ、Googleが頻繁にクロールする必要はない場合があります。

反対に、新しいページが大量に公開されても、サーバーが不安定であれば、Googlebotがクロールを抑える可能性があります。

違いを比較しました。

比較項目	クロール能力	クロール需要
基本的な意味	クロールできる量の上限	クロールする必要性
主な関係要素	サーバーの応答・負荷	URL数・更新状況・人気度など
問題の例	500エラーが多発する	不要なURLが大量に存在する
改善の方向性	サーバーの安定性を高める	URL構造や情報を整理する

例えば、WordPressのプラグインの不具合によってサーバーエラーが頻発すると、クロール能力の上限が下がる場合があります。

一方、重要な記事が更新された場合には、Googleがその情報を再取得する必要性が生じることがあります。

ただし、記事の更新頻度を無理に増やせば、必ずクロール需要が高まるわけではありません。

**クロール能力は「取得できる量」、クロール需要は「取得する必要性」**と覚えておくと分かりやすいでしょう。

Googleがクロール対象を選ぶ際に考慮すること

Googlebotは、Webサイト内のURLをすべて同じ頻度で巡回するわけではありません。

Googleは、ページの人気度や更新状況、サイト内のURL構成などを参考に、クロールする必要性を判断しています。

例えば、情報が頻繁に更新されるページは、変更内容を確認するために再クロールされることがあります。

また、Webサイト全体を別のURLへ移転した場合には、新しいURLを処理する必要性が高まる場合があります。

主な判断要素を整理しました。

判断に関係する要素	内容
URLの人気度	人気のあるページは再クロールされやすい傾向
情報の古さ	更新内容を確認する必要性
サイトの規模	Googleが認識しているURLの量
ページの品質・関連性	クロール需要の判断に関係する
URLの重複	クロール効率に影響する場合がある
サイト移転	新しいURLを再処理する必要性

例えば、WordPressでパーマリンクを変更した場合、Googleが旧URLと新URLの関係を確認するために、関連するページを再クロールすることがあります。

ただし、Googleが個別のURLをどの順番でクロールするかを、サイト運営者が完全に指定することはできません。

Google公式資料では、クロール需要に影響する主な要素として、URLの人気度や情報の古さなどが紹介されています。

ブログ運営者が優先したいのは、Googlebotの判断を操作しようとすることではなく、重要な記事を発見しやすい状態に整えることです。

大規模サイトと小規模ブログで対策は違う？

クロールバジェットの管理は、Webサイトの規模や更新頻度によって重要性が異なります。

例えば、数百ページの個人ブログでは、クロールバジェットを細かく調整する必要がない場合がほとんどです。

一方、数百万ページを持つ大規模サイトや、大量のURLが毎日更新されるサイトでは、クロール効率の管理が重要になります。

Google公式資料では、クロールバジェット管理の主な対象として、次のようなサイトを挙げています。

• 約100万ページ以上を持ち、定期的に内容が更新される大規模サイト
• 約1万ページ以上を持ち、毎日のように大量の内容が更新されるサイト
• Search Consoleで「検出 – インデックス未登録」のURLが多いサイト

これらのページ数は、おおまかな分類の目安であり、厳密な基準ではありません。

サイト規模による対策の違いを整理しました。

項目	小規模ブログ	大規模サイト
主な課題	記事の発見・公開設定	大量URLの効率的な処理
内部リンク	関連記事の整理	大規模なサイト構造の管理
XMLサイトマップ	正常な生成・送信を確認	多数のURLを適切に管理
サーバー	正常な表示を維持	大量アクセスへの対応
クロールバジェット	通常は過度な管理が不要	専門的な最適化が必要な場合がある

例えば、WordPressで500記事を公開しているブログなら、最初から高度なクロール制御を行う必要は通常ありません。

まずは、記事の公開状態、内部リンク、XMLサイトマップ、Search Consoleの未登録状況を確認することが大切です。

ただし、記事数が少なくても、不要なURLが大量に生成されている場合や、「検出 – インデックス未登録」が多数発生している場合は、詳しい調査が役立ちます。

クロールバジェット対策は、記事数だけで判断せず、実際のクロール状況に応じて検討しましょう。

不要なURLや重複ページがクロール効率に与える影響

Webサイト内に不要なURLや重複ページが大量に存在すると、Googlebotのクロール効率に影響する場合があります。

例えば、同じ記事について、異なるパラメータ付きURLが大量に生成されている場合です。

次のURLを考えてみましょう。

Example Domain

example.com

Example Domain

example.com

https://example.com/1234/?ref=menu

example.com

これらが同じ内容を表示している場合、Googleは複数のURLを認識する可能性があります。

クロール効率に影響する代表的なケースを整理しました。

URLの状態	考えられる影響	確認方法
重複ページが多い	同じ内容の確認にリソースを使う	canonicalを確認
不要なパラメータURL	URL数が増える	URL構造を調査
無限に生成されるURL	クロール対象が増大する	リンクや生成設定を確認
長いリダイレクトチェーン	取得までに追加の処理が必要	転送経路を確認
存在しないURLへのリンク	不要な取得を招く	リンク切れを修正

ただし、重複URLが存在すること自体が、直ちに重大なSEO問題になるわけではありません。

Googleは重複するページから正規URLを選択する仕組みを持っています。

そのため、すべての重複URLを手作業で削除する必要はありません。

ブログ運営者は、次の点を確認しましょう。

• 重要な記事の正規URLが適切か
• 内部リンクが正規URLを指しているか
• XMLサイトマップに不要なURLが掲載されていないか
• URL変更後の301リダイレクトが適切か
• 不要なURLが大量に増えていないか

なお、noindexはインデックス登録を防ぐ指示ですが、Googleがその指示を確認するためにページをクロールする場合があります。

クロール量を減らす目的で、すべての不要ページにnoindexを設定すればよいというものではありません。

また、robots.txtによるブロックはページの取得を制限しますが、Googleがページ内のnoindexなどを確認できなくなる点にも注意が必要です。

設定を変更するときは、URLを残す必要があるのか、検索結果に表示したいのかなどを整理してから対応しましょう。

初心者がクロールバジェットを過度に気にしなくてよい理由

SEO初心者の方は、クロールバジェットという専門用語を知ると、Googlebotの巡回回数を増やす必要があると考えるかもしれません。

しかし、一般的な個人ブログでは、クロールバジェットの細かい調整よりも、基本的なサイト管理を優先することが大切です。

例えば、WordPressで100記事を公開している場合、まず確認したいのは、記事が正常に表示されるか、重要な記事がSearch Consoleで登録されているかという点です。

初心者が優先したい対策を整理しました。

優先度	対策	理由
高い	記事を正常に公開する	Googlebotが取得できる状態にする
高い	内部リンクを整理する	URL発見の手がかりになる
高い	XMLサイトマップを確認する	重要なURLを知らせる
高い	サーバーエラーを修正する	クロールを妨げる問題を減らす
高い	Search Consoleを確認する	未登録の理由を把握する
状況による	クロールバジェットの詳細分析	大規模サイトなどで重要になる

例えば、Search Consoleで未登録の記事を見つけた場合でも、すぐにクロールバジェット不足と判断する必要はありません。

URLの発見状況やrobots.txt、サーバーエラー、インデックス登録の判断など、ほかの原因も考えられます。

Googleも、ページ数が少なく頻繁な更新がないサイトでは、サイトマップを最新の状態に保ち、ページのインデックス登録レポートを定期的に確認することが基本であると案内しています。

初心者の方は、クロール回数を増やすことよりも、Googlebotが重要な記事を正常に取得できる状態を維持することを優先しましょう。

Googlebotの巡回を妨げる主な原因

Googlebotは、WebサイトにアクセスしてHTMLや画像などの情報を取得します。

しかし、robots.txtによる制限やサーバーエラー、ログイン設定などによって、ページを正常に取得できない場合があります。

また、内部リンクの不足やJavaScriptの問題などが、URLの発見やページ内容の理解に影響することもあります。

例えば、WordPressで記事を公開していても、セキュリティプラグインがGooglebotを誤ってブロックしていると、必要な情報を取得できない可能性があります。

ここでは、Googlebotの巡回を妨げる代表的な原因と、初心者が確認したい対処方法を説明します。

robots.txtでクローリングが制限されている

robots.txtは、検索エンジンのクローラーに対して、Webサイト内のどのURLへのアクセスを許可するか、または制限するかを伝えるためのファイルです。

例えば、次のようなURLに設置されます。

https://example.com/robots.txt

Googlebotは、ページをクロールするときに、robots.txtのルールを確認します。

特定のURLがクロール禁止対象になっている場合、GooglebotはそのURLの取得を行いません。

robots.txtに関係する主な用語を整理しました。

項目	意味
User-agent	ルールを適用するクローラー
Disallow	クロールを禁止する対象
Allow	クロールを許可する対象
Sitemap	XMLサイトマップの場所を示す

例えば、公開したい記事を含むディレクトリが誤ってクロール禁止になっていると、Googlebotが記事の内容を取得できない場合があります。

確認するときは、次の点に注意しましょう。

• robots.txtが正常に取得できるか
• 公開記事へのアクセスが禁止されていないか
• サイト全体を誤ってブロックしていないか
• Search Consoleでクロール制限が報告されていないか
• robots.txtとnoindexを混同していないか

特に重要なのは、robots.txtがインデックス登録を直接禁止するための設定ではないという点です。

robots.txtでクロールを禁止していても、ほかのページからリンクされている場合などには、URLだけが検索結果に表示される可能性があります。

また、robots.txtでブロックしたページにnoindexを設定しても、Googlebotがその指示を確認できない場合があります。

robots.txtを変更する際は、どのURLを制限しているか確認してから操作しましょう。

ログインやパスワードによるアクセス制限

GooglebotがWebページへアクセスする際に、ログインやパスワードが必要な場合、ページの内容を取得できないことがあります。

例えば、WordPressの記事が「非公開」に設定されている場合、一般の閲覧者は通常、その記事を自由に閲覧できません。

また、Webサイト全体にBasic認証などのアクセス制限が設定されている場合も、Googlebotの巡回に影響することがあります。

主なアクセス制限と影響を整理しました。

制限の種類	状況	確認したいこと
WordPressの非公開設定	一般公開されていない	公開状態
パスワード保護	閲覧時にパスワードが必要	記事の公開設定
Basic認証	サイトへのアクセス時に認証が必要	サーバー設定
会員専用ページ	ログインが必要	公開範囲
IPアドレス制限	特定のアクセス元だけ許可	セキュリティ設定

例えば、Webサイトの制作中にBasic認証を設定し、そのまま一般公開した場合、Googlebotがページへアクセスできない可能性があります。

一方、会員専用ページや非公開ページなど、意図的にアクセスを制限している場合は、必ずしも問題ではありません。

重要なのは、検索結果に表示したい記事が、Googlebotから正常に取得できる状態になっているかどうかです。

アクセス制限を解除する前には、そのページを本当に一般公開してよいか確認しましょう。

403・404・429・500・503エラーが発生している

GooglebotがWebページへアクセスすると、WebサーバーからHTTPステータスコードが返されます。

このコードは、ページを正常に取得できたか、エラーが発生したかなどを示します。

例えば、記事のURLが存在しない場合には404エラーが返されることがあります。

また、サーバーの不具合によって500エラーが発生すると、Googlebotはページを正常に取得できません。

代表的なステータスコードを整理しました。

コード	意味	Googlebotへの影響
200	正常な応答	ページを取得できる
403	アクセス禁止	対象ページを取得できない
404	ページが存在しない	対象URLにページがないと判断される
429	リクエストが多すぎる	クロール速度を抑える場合がある
500	サーバー内部エラー	正常に取得できず、クロールが減少する場合がある
503	一時的に利用できない	一時的な障害として再試行される場合がある

注意したいのは、それぞれのエラーが同じ影響を与えるわけではないことです。

例えば、404エラーは、削除したページに対して正常に返される場合があります。

一方、429や5xxエラーが繰り返し発生すると、Googleがサーバーの過負荷を考慮して、クロール速度を抑えることがあります。

Google公式資料でも、429や5xxエラーはクロール速度の調整に関係すると説明されています。

エラーが見つかった場合は、次の順番で確認しましょう。

1. 対象URLが現在も必要なページか確認する
2. ブラウザでページが開けるか調べる
3. Search ConsoleでURL検査を行う
4. エラーの種類を確認する
5. 必要に応じてWordPressやサーバーの設定を調べる
6. 原因が分かった場合に修正する

なお、削除済みで代わりのページがないURLについては、404や410を返すことが適切な場合があります。

すべての404エラーをトップページへリダイレクトする必要はありません。

サーバーの負荷や応答遅延が影響している

GooglebotがWebサイトを巡回するときは、サーバーへリクエストを送信します。

そのため、サーバーが不安定だったり、応答に長い時間がかかったりすると、クロールに影響する場合があります。

例えば、WordPressのプラグインに不具合があり、ページの読み込みに時間がかかっている場合です。

Googlebotは、サーバーへ過度な負荷をかけないように、クロール量を調整することがあります。

主な原因と確認方法を整理しました。

原因	考えられる状況	確認方法
サーバー負荷	アクセス集中など	サーバー管理画面
プラグインの不具合	処理が遅くなる	最近の変更を確認
データベースの問題	ページ生成が遅い	エラーログなど
一時的な障害	503エラーなど	サーバーの障害情報
過度なアクセス制限	429エラーなど	セキュリティ設定

例えば、WordPressの管理画面からプラグインを更新した後、サイト全体の表示が遅くなった場合は、更新内容が関係していないか確認することができます。

サーバーの問題を調べるときは、次の点を意識しましょう。

• 複数のページで表示遅延が発生していないか
• サーバーエラーが増えていないか
• 最近プラグインやテーマを変更していないか
• セキュリティ設定がアクセスを制限していないか
• Search Consoleのクロール統計に変化がないか

ただし、表示速度を改善すれば、必ずクロール回数が増えるわけではありません。

Googleはクロール需要も考慮するため、サーバーに余裕があっても、必要性が低ければクロールを増やさない場合があります。

サーバーの安定性を高める目的は、クロール回数を無理に増やすことではなく、Googlebotと読者が正常にページを利用できる状態を保つことです。

リンク切れや孤立ページでURLを発見しにくい

Googlebotは、Webページに掲載されているリンクをたどって、新しいURLを発見することがあります。

そのため、サイト内のリンク構造が整理されていないと、重要なページを発見しにくくなる場合があります。

例えば、WordPressで記事を公開していても、カテゴリー一覧や関連記事などからその記事へ移動できない場合です。

このようなページは「孤立ページ」と呼ばれます。

また、内部リンクのURLが間違っていると、Googlebotがリンク先へアクセスした際に404エラーになることがあります。

主な問題と対処方法を整理しました。

問題	内容	対処方法
リンク切れ	リンク先が存在しない	正しいURLへ修正
孤立ページ	サイト内のリンクから到達できない	関連ページからリンクする
旧URLへのリンク	変更前のURLが残っている	新URLへ更新
不自然なサイト構造	重要記事が見つけにくい	カテゴリーなどを整理
JavaScript依存のリンク	通常のリンクとして認識しにくい場合がある	適切なHTMLリンクを使用

例えば、「Google検索（SEO）」のカテゴリーに複数の関連記事がある場合は、記事の内容に応じて必要な内部リンクを設置するとよいでしょう。

ただし、内部リンクは数を増やすことが目的ではありません。

読者が関連する情報へ移動しやすい位置に設置することが基本です。

また、孤立ページであっても、XMLサイトマップなどからGoogleがURLを発見する場合があります。

そのため、内部リンクがないことだけで、必ずクロールされないと断定することはできません。

重要な記事がサイト内の適切な場所から見つけられるか、定期的に確認しましょう。

JavaScriptやレンダリングの問題で内容を取得できない

Googlebotは、WebページのHTMLを取得し、必要に応じてJavaScriptなどを処理して、ページの内容を理解します。

この処理を「レンダリング」と呼びます。

例えば、WordPressでJavaScriptを使って記事の一部を表示している場合、JavaScriptの読み込みに問題があると、Googleが重要な内容を確認できない可能性があります。

ただし、JavaScriptを利用していること自体が問題になるわけではありません。

重要なのは、必要なコンテンツをGoogleが正常に取得できるかどうかです。

主な問題と確認項目を整理しました。

問題	考えられる影響	確認方法
JavaScriptエラー	一部の内容が表示されない	ブラウザや開発者ツール
リソースのブロック	必要なファイルを取得できない	robots.txt
動的コンテンツの問題	本文が正しく生成されない	公開URLテスト
画像の読み込み不良	重要な画像を取得できない	実際のページ表示
ユーザー操作が必要	Googleが内容を発見できない場合がある	表示方法を確認

例えば、WordPressで高速化プラグインのJavaScript最適化設定を変更した結果、記事本文や画像が表示されなくなる場合があります。

そのようなときは、変更前後の表示を比較し、必要に応じて設定を見直しましょう。

Googleは、JavaScriptを利用したページを処理する際、取得したHTMLなどを基にレンダリングを行います。

初心者の方は、次の点を確認しましょう。

• パソコンとスマートフォンで本文が表示されるか
• 重要な画像が正常に読み込まれるか
• メニューや内部リンクが動作するか
• JavaScriptを利用した部分でエラーが発生していないか
• Search Consoleの公開URLテストで問題がないか

Googlebotがページへアクセスできていても、重要な内容を正常に取得できるとは限りません。

クロールの可否だけでなく、Googleが記事の主要な内容を確認できる状態かどうかも大切です。

セキュリティ設定がGooglebotを誤ってブロックしている

WordPressでは、セキュリティプラグインやサーバーのファイアウォールなどを利用して、不正アクセスを防ぐことがあります。

これらはWebサイトを保護するために役立ちますが、設定によってはGooglebotのアクセスを誤って制限する場合があります。

例えば、短時間に多数のアクセスがあったときに、自動的にアクセスを遮断する設定が有効になっている場合です。

Googlebotのリクエストが不正アクセスと誤認されると、403エラーなどが返される可能性があります。

代表的な設定と確認項目を整理しました。

設定・機能	役割	注意したいこと
セキュリティプラグイン	不正アクセスを防止	Googlebotを誤検知していないか
WAF	不審な通信を遮断	必要なアクセスを禁止していないか
IPアドレス制限	特定のアクセス元を制限	正規クローラーを遮断していないか
Bot対策	自動アクセスを制御	正常なGooglebotとの区別
アクセス回数制限	過度なリクエストを抑える	429エラーが頻発していないか

例えば、セキュリティ関連の設定を変更した直後から、Search Consoleで取得エラーが増えた場合は、その変更が関係していないか確認するとよいでしょう。

ただし、アクセスログに「Googlebot」という名前が表示されているだけでは、本物のGooglebotとは断定できません。

ユーザーエージェント文字列は偽装できるためです。

Googleは、正規のクローラーかどうかを確認する方法として、IPアドレスやDNSによる検証を案内しています。

問題が疑われる場合は、次の手順で確認しましょう。

1. Search Consoleでクロール状況を確認する
2. 403・429などのエラーが発生していないか調べる
3. 最近変更したセキュリティ設定を確認する
4. 必要に応じてサーバーのアクセスログを調べる
5. Googlebotのアクセス元を公式情報で検証する
6. 原因が確認できた場合に、必要な設定だけを修正する

セキュリティプラグインやWAFを、原因が分からないまま全面的に無効化することはおすすめしません。

不正アクセスを防ぐ機能を維持しながら、正規のGooglebotが必要なページを取得できるようにすることが大切です。

クロールエラーが続く場合は、Googlebotのアクセス状況とセキュリティ設定の両方を確認しましょう。

robots.txtとnoindexでクローラーを管理する方法

Googlebotは、Webサイトを巡回するときに、robots.txtなどの設定を確認しながらページの情報を取得します。

しかし、WordPressの設定によっては、Googlebotが記事をクロールできなかったり、インデックス登録が制限されたりする場合があります。

特に初心者が理解しておきたいのが、「robots.txt」と「noindex」の違いです。

robots.txtはGooglebotなどのクローラーによるアクセスを制御する仕組みで、noindexは検索エンジンへのインデックス登録を防ぐための設定です。

この2つを混同すると、公開したい記事がGoogleに登録されなかったり、検索結果から除外したいURLが表示されたりすることがあります。

ここでは、それぞれの役割や設定例、WordPressで確認する方法について解説します。

robots.txtとは？クロールを制御する基本設定

robots.txt（ロボッツテキスト）とは、検索エンジンのクローラーに対して、Webサイト内のどのURLへのアクセスを許可するか、または制限するかを伝えるためのファイルです。

通常、Webサイトのルートに配置されます。

例えば、次のようなURLです。

https://example.com/robots.txt

Googlebotは、このファイルに記載されたルールを参考にして、対象URLをクロールできるか判断します。

例えば、Webサイト内に検索エンジンが巡回する必要のないディレクトリがある場合、その場所へのクロールを制限する目的で利用できます。

robots.txtの主な役割を整理しました。

項目	内容
主な目的	クローラーのアクセスを制御する
設置場所	Webサイトのルート
対象	URLやディレクトリなど
主な命令	User-agent・Disallow・Allow
検索結果への影響	URLの表示を完全に防ぐものではない
確認方法	robots.txtのURLやSearch Console

robots.txtを利用する際は、次の点を理解しておきましょう。

• Googlebotなどのクローラーへのアクセスルールを指定できる
• クロールする必要のないURLを制限できる
• 検索順位を直接改善するための設定ではない
• インデックス登録を確実に防ぐ目的には適していない
• 悪意のあるクローラーがルールに従う保証はない

例えば、検索結果に表示したくないページがある場合、robots.txtでクロールを禁止するだけでは不十分です。

Googleは、別のページからリンクされているURLを、内容を取得せずに検索結果へ表示する場合があるためです。

Google公式資料でも、robots.txtは主にクロールトラフィックを管理するためのものであり、ページを検索結果から除外するための仕組みではないと説明されています。

robots.txtは、検索結果への表示ではなく、Googlebotによるページへのアクセスを制御するためのファイルだと理解しましょう。

robots.txtのDisallowとAllowの意味

robots.txtでは、主に「User-agent」「Disallow」「Allow」などの命令を使用します。

これらの命令によって、特定のクローラーがアクセスできるURLを指定します。

例えば、次のような記述があります。

User-agent: *
Disallow: /sample-private/
Allow: /sample-public/

※これは説明用の記述例です。現在のWordPressサイトにそのまま追加する必要はありません。

それぞれの意味を整理しました。

命令	意味	記述例
User-agent	ルールを適用するクローラー	User-agent: *
Disallow	クロールを禁止するパス	Disallow: /sample-private/
Allow	クロールを許可するパス	Allow: /sample-public/
Sitemap	サイトマップの場所を知らせる	Sitemap: https://example.com/sitemap.xml

User-agent: *は、すべてのクローラーを対象とする指定です。

Disallow: /sample-private/は、指定したパスへのクロールを禁止するルールです。

一方、Allowは、クロールを許可する対象を指定する場合に利用します。特に、広い範囲を禁止した中で特定のパスを許可したい場合などに役立ちます。

例えば、次のような記述もあります。

User-agent: *
Disallow: /

この記述は、対象となるクローラーに対して、サイト全体へのクロールを禁止するものです。

公開中のブログに誤って設定すると、Googlebotが記事を取得できなくなるため注意が必要です。

また、次のような記述では、クロール禁止のパスを指定していません。

User-agent: *
Disallow:

Googleでは、これをクロール禁止ルールがない状態として扱います。

ただし、実際には複数のルールが組み合わされる場合があり、適用されるルールはパスの一致条件などによって決まります。

初心者の方は、次の点を確認しましょう。

• 命令の意味を理解してから変更する
• 公開記事のディレクトリを誤って禁止しない
• ほかのルールとの組み合わせを確認する
• 変更後はSearch Consoleなどで影響を調べる

WordPressでブログを運営している場合、特別な理由がなければ、robots.txtを手動で頻繁に編集する必要はありません。

robots.txtファイルの確認方法

robots.txtは、多くの場合、ブラウザから直接確認できます。

例えば、自分のWebサイトが次のURLで公開されているとします。

Example Domain

example.com

この場合、robots.txtは通常、次のURLで確認します。

https://example.com/robots.txt

robots.txtを確認する基本的な手順は次のとおりです。

1. ブラウザを開きます。
2. 自分のサイトのURLを入力します。
3. URLの末尾に/robots.txtを追加します。
4. 表示された内容を確認します。
5. Disallowなどの制限があるか調べます。

例えば、次のような表示があった場合です。

User-agent: *
Disallow: /wp-admin/

これは、対象となるクローラーに対して、/wp-admin/以下のクロールを禁止する指定です。

ただし、WordPressではテーマやプラグイン、サーバー設定などによって、実際のrobots.txtの内容が異なることがあります。

確認するときは、次の点を意識しましょう。

確認項目	内容
robots.txtの表示	ファイルを正常に確認できるか
User-agent	どのクローラーに適用されるか
Disallow	どのURLを禁止しているか
Allow	例外的に許可するURLがあるか
Sitemap	サイトマップのURLが正しいか

なお、robots.txtが表示されないからといって、必ずGooglebotのクロールに問題があるとは限りません。

例えば、robots.txtが存在せず404を返す場合、Googleは通常、クロール禁止のルールがないものとして扱います。

一方、サーバーエラーによってrobots.txtを取得できない場合には、クロールへの影響が生じる可能性があります。

また、robots.txtの表示を確認することと、Googlebotが個別記事をクロールできることを確認することは別です。

特定の記事については、Search ConsoleのURL検査も利用して状態を確認しましょう。

noindexとは？インデックス登録を防ぐ設定

noindex（ノーインデックス）とは、Googleなどの検索エンジンに対して、対象ページをインデックス登録しないよう指示する設定です。

例えば、一般公開はしているものの、Google検索には表示させたくないページに利用する場合があります。

ただし、通常のブログ記事を検索結果に表示したい場合、誤ってnoindexを設定しないよう注意が必要です。

HTMLでは、次のような記述が使用されます。

<meta name="robots" content="noindex">

※これは仕組みを説明するためのコード例です。通常の公開記事に追加する必要はありません。

noindexについて整理しました。

項目	内容
主な目的	インデックス登録を防ぐ
主な設定方法	HTMLのmetaタグやHTTPヘッダー
Googlebotのアクセス	指示を読み取れる状態が必要
既存の登録ページ	Googleが認識すると検索結果から除外される
注意点	robots.txtでブロックすると指示を読めない場合がある

例えば、WordPressのCocoonには、投稿や固定ページなどのSEO設定に関連する機能があります。

通常の公開記事にnoindexを設定すると、Googleが指示を認識した場合、そのページはインデックス登録されません。

そのため、記事がGoogle検索に表示されない場合は、意図しないnoindex設定がないか確認することが重要です。

noindexを利用するときは、次の点に注意しましょう。

• 検索結果に表示したい記事には設定しない
• ページごとの設定を確認する
• テーマとSEOプラグインの設定重複に注意する
• robots.txtで同じページをブロックしない
• Search Consoleで登録状況を確認する

Googleは、noindexを適用するには、Googlebotがその指示を確認できる必要があると説明しています。

また、noindexは検索結果からページを除外するためのものであり、ページそのものを非公開にしたり、閲覧者から情報を保護したりする仕組みではありません。

個人情報などを保護したい場合は、パスワード保護やアクセス制限など、別の方法が必要です。

robots.txtとnoindexの違いを比較

robots.txtとnoindexは、どちらも検索エンジンに関係する重要な設定ですが、役割は異なります。

特に初心者の方は、**「クロールを止めたいのか」「検索結果への登録を防ぎたいのか」**という目的の違いを理解することが大切です。

例えば、Googlebotによる特定ディレクトリの巡回を制限したい場合には、robots.txtを検討します。

一方、一般公開しているページをGoogle検索へ登録したくない場合には、noindexが利用されます。

違いを表にまとめました。

比較項目	robots.txt	noindex
主な役割	クロールの制御	インデックス登録の制御
指定方法	robots.txtファイル	metaタグ・HTTPヘッダー
ページへのアクセス	Googlebotを制限できる	原則として許可する必要がある
検索結果への表示	URLだけ表示される場合がある	Googleが認識すれば除外される
主な用途	クロールトラフィックの管理	不要なページの登録防止
個人情報の保護	適していない	適していない

具体例を挙げると、次のようになります。

ケース①：クロールしてほしくないディレクトリがある

robots.txtで対象パスのクロールを制限する方法があります。

ケース②：ページは公開したいが、検索結果には表示したくない

noindexを利用する方法があります。

ケース③：会員以外には内容を見せたくない

ログイン認証やパスワード保護などが必要です。

ケース④：記事を削除して、検索結果からもなくしたい

ページの削除状態やHTTPステータス、必要に応じたGoogleの削除手続きなどを検討します。

ただし、同じページにrobots.txtによるクロール禁止とnoindexを同時に設定すると、Googlebotがnoindexを確認できない場合があります。

設定は組み合わせれば効果が強まるというものではありません。

目的に合った方法を選びましょう。

robots.txtでブロックしても検索結果にURLが表示される理由

robots.txtでクロールを禁止しているにもかかわらず、Google検索にURLが表示される場合があります。

これは、Googleがページの内容を取得していなくても、ほかのWebページからのリンクなどを通じて、そのURLの存在を認識できるためです。

例えば、次のような状況を考えてみましょう。

あるページへのクロールをrobots.txtで禁止していても、別の記事からそのページへリンクが設置されていたとします。

Googlebotはリンク元のページを取得することで、クロール禁止となっているURLの存在を発見する可能性があります。

その結果、ページの内容を取得せずに、URLのみが検索結果に表示される場合があります。

この仕組みを整理しました。

状態	Googleの処理
robots.txtでクロール禁止	ページ内容を取得しない
別ページからリンクされている	URLの存在を認識できる場合がある
内容を取得できない	スニペットなどが表示されない場合がある
URLが検索結果に表示	クロール禁止でも起こり得る

Google公式資料でも、robots.txtで禁止されたURLが、別ページから参照されている場合には検索結果に表示される可能性があると説明されています。

このような場合、検索結果から除外したいページに対して、robots.txtだけで対応することは適切ではありません。

noindexを利用する場合には、Googlebotがそのページへアクセスして指示を確認できる必要があります。

また、機密情報を含むページであれば、検索結果への表示だけでなく、一般の閲覧者がアクセスできないよう認証などを設定することが重要です。

robots.txtはクロールを制御する仕組みであり、ページの秘密を守るためのセキュリティ対策ではありません。

WordPressで設定を変更するときの注意点

WordPressでは、テーマやプラグイン、標準の設定によって、Googlebotのクロールやインデックス登録に関係する設定が行われます。

そのため、検索結果への表示に問題がある場合でも、robots.txtやnoindexをすぐに変更するのではなく、まず現在の設定を確認することが大切です。

例えば、Cocoonを利用しているサイトに別のSEOプラグインを追加すると、複数の場所で検索エンジン向けの設定を管理することになる場合があります。

初心者が確認したい主な設定を整理しました。

確認場所	主な確認内容
WordPress「設定」→「表示設定」	検索エンジン向けの表示設定
Cocoonの投稿・固定ページ設定	noindexなどの指定
SEO関連プラグイン	robotsメタタグなどの設定
robots.txt	Googlebotのクロール制限
Search Console	クロール・インデックス登録状況

設定を変更する際は、次の手順がおすすめです。

1. 現在の設定内容を確認する
2. 変更する目的を明確にする
3. 必要な設定やファイルのバックアップを取る
4. 変更する項目を限定する
5. WordPressの設定を保存する
6. 公開ページが正常に表示されるか確認する
7. Search Consoleで必要な状態を確認する

例えば、記事が「noindexタグによって除外」と表示されている場合は、その記事を本当に検索結果に表示したいのか確認しましょう。

検索対象にしたい記事であれば、WordPressやCocoonなどの設定を調べ、意図しないnoindexがあれば修正します。

一方、重複ページや不要な管理用ページなど、検索結果へ表示させる必要がないページは、未登録でも問題ない場合があります。

また、robots.txtを直接編集する際は、誤った設定によって公開記事全体のクロールを妨げる可能性があります。

現在正常に動作している設定を、SEO対策という理由だけで変更する必要はありません。

WordPressとCocoonでは、まず公開状態とnoindexの有無、robots.txtの内容を確認し、明確な問題がある場合に必要な修正を行いましょう。

GooglebotにWebサイトを発見してもらいやすくする基本対策

GooglebotがWebサイトを巡回するときは、内部リンクやXMLサイトマップなどを手がかりに、新しいURLを発見します。

そのため、WordPressで記事を公開する際は、単に記事を作成するだけでなく、Googlebotがページを見つけやすいサイト構造を整えることが大切です。

例えば、トップページからカテゴリー一覧へ移動でき、さらに個別記事へアクセスできる構造なら、読者もGooglebotも関連ページを発見しやすくなります。

一方、内部リンクのない孤立ページや、不要なURLが大量に生成されるサイトでは、重要なページの発見やクロールに影響する場合があります。

ここでは、GooglebotのURL発見を助けるための基本対策を、WordPress初心者にも分かりやすく解説します。

トップページから重要な記事へ移動できるようにする

Googlebotに重要なページを発見してもらいやすくするには、トップページから記事へ移動できるサイト構造が役立ちます。

トップページは、Webサイト全体の入口になるページです。

そこからカテゴリー一覧や個別記事へ移動できれば、読者は必要な情報を探しやすくなります。

例えば、Googleに関する情報を扱うブログなら、次のような構造が考えられます。

トップページ

Google検索（SEO）

Search Console

Google Analytics

個別の記事

クローラーとは？・Google検索の仕組み・SEOの基本など

サイト構造を簡略化した図です。

重要なページへ移動しやすくするための確認項目を整理しました。

確認項目	内容
トップページ	主要カテゴリーへのリンクがあるか
カテゴリー一覧	個別記事が掲載されているか
ナビゲーション	必要なページへ移動できるか
記事一覧	公開済み記事が見つけやすいか
リンク先	正しいURLが設定されているか

トップページからすべての記事へ直接リンクする必要はありません。

カテゴリーや関連記事などを通じて、重要なページへ自然に移動できる構造があれば十分です。

Google公式資料でも、適切な内部リンクによって重要なページを発見しやすくできると説明されています。

サイト構造は、Googlebotのためだけでなく、読者が迷わず情報を探せることを優先して整えましょう。

カテゴリーと内部リンクを整理する

カテゴリーとは、関連する記事をテーマごとに分類するための仕組みです。

WordPressでは、カテゴリーを利用して記事を整理できます。

例えば、Googleに関するブログであれば、「Google検索（SEO）」「Search Console」「Google Analytics（GA4）」などに分ける方法があります。

カテゴリーを整理することで、同じテーマの記事をまとめて閲覧しやすくなります。

一方、内部リンクは、記事本文などから同じサイト内の別ページへ移動できるようにするリンクです。

カテゴリーと内部リンクの役割を比較しました。

項目	主な役割	具体例
カテゴリー	記事をテーマ別に分類	Google検索（SEO）
カテゴリー一覧	同じ分野の記事を表示	SEO関連記事一覧
内部リンク	関連する別記事へ案内	Googlebotの記事から検索の仕組みの記事へ
パンくずリスト	現在のページの位置を示す	ホーム ＞ SEO ＞ 個別記事

例えば、「クローラーとは？」という記事から「Google検索の仕組みとは？」という記事へリンクを設置すると、読者は関連するテーマを続けて学べます。

内部リンクを設定するときは、次の点を確認しましょう。

• 記事の内容とリンク先が関連している
• リンク先の記事が公開されている
• 正しいURLを設定している
• リンク先の内容が文章から分かる
• 同じリンクを不必要に繰り返していない
• 読者が必要な情報へ自然に移動できる

例えば、「こちらをクリック」と書くよりも、「Google検索の仕組みを詳しく解説」のように、リンク先の内容が分かる表現を使用すると親切です。

ただし、内部リンクの本数を増やすことだけを目的にする必要はありません。

読者にとって必要な関連記事を、適切な位置に設置することが大切です。

XMLサイトマップを正常に管理する

XMLサイトマップは、Webサイト内に存在する重要なURLなどを検索エンジンへ知らせるためのファイルです。

Googlebotは、XMLサイトマップを参考にして、新しい記事や更新されたページを発見することがあります。

例えば、WordPressで多数の記事を公開している場合、XMLサイトマップによって重要なURLをGoogleへ知らせることができます。

ただし、XMLサイトマップを送信しても、すべてのURLがクロール・インデックス登録されるわけではありません。

Google公式資料でも、サイトマップはURLの発見を助けるものですが、登録を保証するものではないと説明されています。

XMLサイトマップで確認したい項目を整理しました。

項目	確認内容
サイトマップのURL	正常に取得できるか
公開記事	必要なURLが掲載されているか
正規URL	古いURLや不要なURLが含まれていないか
最終更新日時	実際の重要な変更を反映しているか
Search Console	サイトマップを取得できているか

WordPressでは、本体やプラグインなどによってXMLサイトマップを生成できます。

すでに正常なサイトマップが存在する場合、新しいプラグインを追加する必要はありません。

また、次の点にも注意しましょう。

• HTMLサイトマップとXMLサイトマップを混同しない
• noindexのページを不必要に掲載しない
• 旧URLを残したままにしない
• 複数のサイトマップ生成機能の重複を確認する
• エラーがある場合は原因を調べる

特に、パーマリンクを変更した場合は、新しいURLが適切に掲載されているか確認するとよいでしょう。

ただし、正常に取得されているサイトマップを毎日再送信する必要はありません。

重要なページを孤立ページにしない

孤立ページとは、同じサイト内のほかのページから内部リンクでたどれないページのことです。

例えば、WordPressで記事を公開したものの、トップページやカテゴリー一覧、関連記事などからリンクされていない場合が考えられます。

このようなページは、読者が見つけにくいだけでなく、GooglebotがリンクをたどってURLを発見する手がかりも少なくなります。

ただし、孤立ページであっても、XMLサイトマップや外部リンクなどからGoogleが発見する場合があります。

孤立ページを減らすための方法を整理しました。

対策	内容
カテゴリーの設定	関連する記事一覧へ掲載する
内部リンク	関連記事から案内する
トップページ	重要な記事や案内ページへリンクする
記事一覧	公開済み記事を探せるようにする
リンク切れの確認	正しいURLへ移動できるか調べる

例えば、「Googlebotの巡回頻度」という記事を公開した場合、「クローラーとは？」という記事から関連情報として案内する方法があります。

ただし、記事同士の関連性が低い場合は、無理にリンクを設置する必要はありません。

孤立ページの対策では、次の点を意識しましょう。

• 重要な記事への入口があるか
• 読者が自然に移動できるか
• カテゴリーが適切か
• 公開後にリンクが外れていないか
• 古い記事から新しい記事へ案内できるか

重要な記事がサイト内で見つけやすい状態になっているかを確認することが、基本的な対策になります。

不要なリダイレクトやリンク切れを減らす

リダイレクトとは、あるURLへアクセスしたときに、別のURLへ自動的に転送する仕組みです。

例えば、WordPressでパーマリンクを変更した場合、旧URLから新URLへ301リダイレクトを設定することがあります。

適切な301リダイレクトは、URL変更をGoogleや読者へ伝えるために役立ちます。

しかし、リダイレクトが何段階も続く場合や、転送先が存在しない場合は、ページの取得に余分な処理が必要になったり、エラーが発生したりする可能性があります。

代表的な問題を整理しました。

問題	状況	改善方法
リンク切れ	リンク先が404になる	正しいURLへ修正
リダイレクトチェーン	複数の転送が続く	可能な範囲で直接転送
リダイレクトループ	転送が繰り返される	設定を修正
旧URLへの内部リンク	古いURLが残っている	新URLへ更新
間違った転送先	無関係なページへ転送	適切な転送先を指定

例えば、次のような転送がある場合です。

旧URL → 中間URL → 新URL

技術的に必要な場合もありますが、通常は旧URLから最終的な新URLへ直接転送できる方が分かりやすくなります。

ただし、すべてのリダイレクトを削除すればよいわけではありません。

過去に公開した記事のURLを変更した場合、旧URLから新URLへの適切な301リダイレクトは維持する必要があります。

また、削除した記事に代わる適切なページがない場合、404または410を返すことが自然な対応となる場合もあります。

初心者の方は、次の点を確認しましょう。

• 旧URLから正しい新URLへ転送されるか
• 内部リンクが新URLを指しているか
• 404エラーが発生していないか
• リダイレクトループがないか
• 正常に動作している301リダイレクトを誤って削除していないか

URL変更後は、転送設定と内部リンクの両方を確認することが重要です。

モバイル版でも重要なコンテンツを表示する

Google検索では、主にスマートフォン用Googlebotが取得したモバイル版コンテンツを、インデックス登録やランキングに利用しています。

この仕組みを「モバイルファーストインデックス」と呼びます。

そのため、パソコン版で記事が正常に表示されていても、スマートフォン版で重要な内容が欠けている場合は注意が必要です。

例えば、パソコンでは全文を表示しているのに、スマートフォンでは記事の一部が読み込まれない場合があります。

Googleがモバイル版で取得できる情報が不足すると、ページの理解やインデックス登録に影響する可能性があります。

モバイル版で確認したい項目を整理しました。

確認項目	内容
本文	重要な文章が表示されるか
見出し	H2・H3が正常に表示されるか
画像	必要な画像が読み込まれるか
内部リンク	正しく移動できるか
JavaScript	重要な内容が正常に生成されるか
robots設定	モバイル版に誤った制限がないか

特に、重要な本文をクリックやスクロールなどの特定操作後にだけ読み込む仕組みには注意が必要です。

Google公式資料では、ユーザー操作を必要とする遅延読み込みコンテンツをGoogleが取得できない場合があると説明されています。

WordPressのCocoonはスマートフォン対応のレイアウトを利用できますが、記事ごとの画像や表、広告などは別途確認するとよいでしょう。

例えば、横幅の広い比較表がスマートフォンで画面からはみ出していないか、画像が正常に表示されるかを確認します。

ただし、スマートフォン対応だけで検索順位の改善が保証されるわけではありません。

Googlebotが重要なコンテンツを取得できることと、読者が快適に記事を閲覧できることの両方を意識しましょう。

サーバーが安定して応答できる状態を保つ

GooglebotがWebページを取得するときは、WebサーバーへHTTPリクエストを送信します。

そのため、サーバーが正常に応答できる状態を維持することが重要です。

例えば、WordPressのプラグインに不具合が発生して500エラーが続くと、Googlebotが記事の内容を正常に取得できなくなる場合があります。

また、サーバーの負荷が高く、応答が遅くなっている場合、Googleがクロール量を調整することもあります。

主な状況を整理しました。

サーバーの状態	Googlebotへの影響
HTTP 200	正常にページを取得できる
応答遅延	クロール量が調整される可能性
HTTP 403	アクセス禁止によって取得できない
HTTP 429	クロール頻度が抑えられる場合がある
HTTP 500	サーバー内部エラーで取得できない
HTTP 503	一時的な利用不可として扱われる

サーバーを安定させるためには、次の点を確認しましょう。

• WordPressやプラグインの更新状態を確認する
• サーバーエラーが発生していないか調べる
• 不必要なプラグインを増やさない
• キャッシュ設定に問題がないか確認する
• セキュリティ設定が正規のGooglebotを妨げていないか調べる
• Search Consoleのクロール関連情報を確認する

例えば、サイト全体の表示が急に遅くなった場合は、最近変更した設定やプラグインの更新内容を確認するとよいでしょう。

ただし、原因を特定しないままセキュリティ機能やキャッシュ機能を停止することはおすすめしません。

必要に応じて、レンタルサーバーのサポートへ相談する方法もあります。

サーバーの安定性を高めることは、Googlebotが正常に巡回できる環境を保つだけでなく、読者にとっても重要な対策です。

不必要なURLを大量に生成しない

GooglebotがWebサイトを巡回するときは、Googleが発見したURLの中から、取得する対象を選んでいます。

そのため、同じ内容を表示するURLや、必要のないURLが大量に生成されると、クロール効率に影響する場合があります。

例えば、WordPressで同じ記事に複数のパラメータ付きURLが作られる場合です。

https://example.com/1234/

Example Domain
example.com

https://example.com/1234/?ref=menu
example.com

これらが同じ記事を表示する場合、Googleは重複するURLとして扱う可能性があります。

ただし、重複URLが存在すること自体が、直ちにSEO上の重大な問題になるわけではありません。

Googleには、複数のURLから代表となる正規URLを選ぶ仕組みがあります。

不要なURLが増える主な例を整理しました。

原因	発生する可能性があるURL	基本的な対策
パラメータ	同じ内容の別URL	用途や正規URLを確認
重複ページ	同じ記事が複数URLで表示	canonicalを確認
自動生成ページ	不要な一覧ページなど	生成設定を確認
URL変更	旧URLと新URL	301リダイレクトを確認
リンクの誤設定	存在しないURL	内部リンクを修正

例えば、WordPressでカテゴリーやタグを大量に作成した場合、記事一覧ページが増えることがあります。

ただし、カテゴリーやタグのページは、読者に役立つ分類として機能している場合もあります。

そのため、URLが多いという理由だけで、すべて削除する必要はありません。

確認したいのは、次の点です。

• 同じ内容のURLが不必要に増えていないか
• 正規URLが適切に設定されているか
• XMLサイトマップに重要なURLが掲載されているか
• リンク切れがないか
• 不要な一覧ページが大量に生成されていないか

また、noindexを設定すれば、Googlebotによるクロールを必ず減らせるというわけではありません。

Googleがnoindexの指示を確認するために、そのURLをクロールする場合があるためです。

重要なのは、URLの総数を無理に減らすことではなく、Googlebotが必要なページを見つけやすいサイト構造を維持することです。

WordPress・Cocoonでクローリングに関係する設定を確認する方法

WordPressでブログ記事を公開しても、Googlebotが必ずページをクロールするとは限りません。

Googlebotが記事を正常に取得するためには、Webサイトの公開設定やnoindex、XMLサイトマップ、パーマリンク、内部リンクなどが適切に管理されていることが大切です。

例えば、記事が公開されていても、Cocoonで誤ってnoindexを設定していると、Googleがその指示を認識した場合、インデックス登録されません。また、パーマリンクの変更後に301リダイレクトが正しく機能していなければ、旧URLから新URLへの移動に問題が生じることがあります。

ここでは、WordPressとCocoonで確認したい設定を、初心者にも分かりやすく解説します。

WordPressの検索エンジン向け表示設定を確認する

WordPressには、検索エンジンによるインデックス登録を抑制するための設定があります。

この設定は、Webサイトを制作している途中など、検索結果に表示させたくない場合に利用することがあります。

しかし、一般公開しているブログで誤って有効にしていると、Google検索への登録に影響する可能性があります。

WordPressでは、次の手順で確認できます。

1. WordPressの管理画面にログインします。
2. 左側メニューの「設定」をクリックします。
3. 「表示設定」を選択します。
4. 「検索エンジンでの表示」の項目を探します。
5. 「検索エンジンがサイトをインデックスしないようにする」のチェック状態を確認します。
6. 設定を変更した場合は、画面下部の「変更を保存」をクリックします。

一般公開して検索結果に表示したいブログでは、通常、このチェックを外します。

確認項目を整理しました。

確認項目	内容
投稿の公開状態	記事が「公開」になっているか
検索エンジンでの表示	インデックス登録を抑制する設定が有効になっていないか
記事のURL	一般の閲覧者がアクセスできるか
noindex	別の設定で登録が禁止されていないか
Search Console	登録状況がどうなっているか

例えば、ブログの制作中に検索エンジン向けの表示設定を変更し、公開時に元へ戻し忘れる場合があります。

そのため、Webサイトを公開した後には、一度確認しておくと安心です。

WordPressの公式マニュアルでも、この設定は検索エンジンへインデックス登録を控えるよう伝えるものであり、アクセスそのものを禁止する機能ではないと説明されています。

ただし、チェックを外したからといって、すぐにGoogleへインデックス登録されるわけではありません。

WordPressの公開設定は、Googleがページを取得・登録できる状態を整えるための基本項目として確認しましょう。

Cocoonのnoindex設定で注意したいこと

Cocoonには、検索エンジン向けのSEO設定が用意されています。

その中には、特定のページをインデックス登録の対象から除外するnoindex設定があります。

例えば、通常のブログ記事を検索結果に表示したいにもかかわらず、誤ってnoindexが設定されていると、Googleがその指示を認識した際にインデックス登録されなくなります。

Cocoonのnoindex設定は、主に次の2つの場所で確認できます。

① Cocoon全体のSEO設定

1. WordPressの管理画面を開きます。
2. 「Cocoon設定」をクリックします。
3. 「SEO」タブを開きます。
4. ページの種類ごとのnoindex設定を確認します。

② 個別記事のSEO設定

1. WordPressの「投稿一覧」を開きます。
2. 確認したい記事の編集画面を開きます。
3. 記事の「SEO」設定欄を探します。
4. noindexに関する設定を確認します。

Cocoon公式FAQでも、SEOタブや投稿編集画面のSEO設定からnoindexを管理できると説明されています。

設定の違いを整理しました。

設定場所	主な役割	確認したいこと
Cocoon設定 → SEO	ページの種類ごとの管理	投稿やカテゴリーなどの設定
記事編集画面のSEO欄	個別記事の管理	その記事がnoindexになっていないか
WordPressの表示設定	サイト全体の設定	登録を控える設定が有効でないか
SEOプラグイン	追加のSEO設定	Cocoonとの設定重複

例えば、特定の記事だけがGoogle検索に表示されない場合は、その記事の個別設定を確認しましょう。

一方、複数の記事に同じ問題が発生している場合は、Cocoon全体の設定も確認するとよいでしょう。

ただし、検索結果に表示する必要がないページに意図的にnoindexを設定している場合は、無理に解除する必要はありません。

また、Cocoonと別のSEOプラグインを併用している場合、設定の重複にも注意が必要です。

記事が未登録だからといって、すべてのnoindex設定を解除するのではなく、登録したいページだけを確認することが大切です。

XMLサイトマップが正常に生成されているか確認する

XMLサイトマップは、Webサイト内の重要なURLなどの情報をGoogleへ伝えるためのファイルです。

Googlebotは、XMLサイトマップを参考にして、新しい記事や更新されたページを発見することがあります。

WordPressでは、本体やプラグインなどによってXMLサイトマップが生成される場合があります。

例えば、次のようなURLです。

https://example.com/wp-sitemap.xml

※これはWordPress標準サイトマップの一般的なURL例です。実際のURLは環境によって異なります。

確認する手順は次のとおりです。

1. ブラウザで自分のサイトのXMLサイトマップを開きます。
2. エラーがなく表示されるか確認します。
3. 投稿用のサイトマップがあるか調べます。
4. 公開記事のURLが適切に含まれているか確認します。
5. Search Consoleの「サイトマップ」で取得状況を確認します。

主な確認項目を整理しました。

確認項目	内容
サイトマップのURL	正常に開けるか
公開記事のURL	必要な記事が掲載されているか
古いURL	パーマリンク変更前のURLが残っていないか
サイトマップの取得状況	Googleが取得できているか
重複生成	複数の生成機能が不必要に重複していないか

例えば、記事のパーマリンクを変更した場合、サイトマップには新しい正規URLが掲載されていることが望ましいでしょう。

ただし、HTMLサイトマップとXMLサイトマップは役割が異なります。

HTMLサイトマップは主に読者がページを探すためのもので、XMLサイトマップは検索エンジンへURL情報を伝えるために利用されます。

また、Googleがサイトマップを正常に取得したとしても、すべての記事がクロール・インデックス登録されるわけではありません。

すでに正常なサイトマップが用意されている場合は、無理に新しいプラグインを追加せず、現在の管理方法を維持しましょう。

パーマリンク設定とURL変更の注意点

パーマリンクとは、WordPressで公開した記事や固定ページに割り当てられるURLのことです。

例えば、次のようなURLがあります。

Example Domain

example.com

WordPressでは、「設定」→「パーマリンク」からURLの基本構造を確認できます。

ただし、すでに多くの記事を公開しているサイトでは、パーマリンクの設定を安易に変更しないことが重要です。

Googleが認識しているURLが変わると、旧URLと新URLの関係を再確認する必要があるためです。

パーマリンクに関する確認項目を整理しました。

確認項目	内容
現在のURL構造	意図した形式になっているか
記事の公開URL	正常に表示されるか
内部リンク	正しいURLを指しているか
XMLサイトマップ	新しいURLが掲載されているか
canonical	正しい正規URLを示しているか
301リダイレクト	URL変更後に適切な転送があるか

例えば、記事のURLを次のように変更した場合です。

変更前：

Example Domain

example.com

変更後：

Example Domain

example.com

この場合、Googlebotが旧URLにアクセスする可能性があるため、旧URLから新URLへ適切に転送する必要があります。

ただし、数字を利用したパーマリンクだからという理由だけで、公開済みのURLを変更する必要はありません。

Googleは、URL変更を伴うサイト移転について、リダイレクトや内部リンク、サイトマップなどを適切に管理することを推奨しています。

すでに正常に公開されている記事では、SEO対策だけを目的とした不必要なURL変更を避けましょう。

301リダイレクトがGooglebotの巡回に与える影響

301リダイレクトとは、あるページが恒久的に別のURLへ移動したことを伝える仕組みです。

例えば、WordPressの記事URLを変更した場合、旧URLから新URLへ301リダイレクトを設定することがあります。

Googlebotが旧URLにアクセスすると、サーバーから転送先が通知され、新しいURLを取得する手がかりになります。

基本的な流れは次のとおりです。

旧URL → 301リダイレクト → 新URL

例えば、旧URLが次のような場合です。

Example Domain

example.com

新URL：

Example Domain

example.com

301リダイレクトを設定することで、旧URLへアクセスした読者を新URLへ案内できます。

ただし、転送が正常に行われていても、Googleが新URLをインデックス登録するまでには時間がかかる場合があります。

確認したい項目を整理しました。

確認項目	内容
旧URL	正しい新URLへ転送されるか
新URL	正常に記事が表示されるか
HTTPステータス	意図した恒久的な転送か
内部リンク	旧URLが残っていないか
canonical	新しい正規URLを指しているか
Search Console	新URLの登録状況

特に注意したいのが、リダイレクトチェーンです。

例えば、次のような状態です。

旧URL → 中間URL → 新URL

Googlebotは複数のリダイレクトをたどることができますが、可能であれば旧URLから最終的な新URLへ直接転送する方がよいでしょう。

また、Google公式資料では、URL変更後のリダイレクトを十分な期間維持することが推奨されています。

すでに正常に機能している301リダイレクトを、古いという理由だけで削除しないようにしましょう。

カテゴリーや関連記事のリンクを見直す

WordPressでは、カテゴリーと内部リンクを利用して記事同士をつなぐことができます。

Googlebotは、既存のページに掲載されたリンクから新しいURLを発見することがあります。

そのため、カテゴリー一覧や関連記事のリンクが適切に設定されていることは、記事の発見に役立ちます。

例えば、「Google検索（SEO）」カテゴリーの中に「Google検索の仕組み」「クローラーとは？」などの記事があれば、カテゴリー一覧からそれぞれの記事へ移動できます。

また、記事本文に関連する解説記事へのテキストリンクを設置する方法もあります。

確認項目を整理しました。

項目	確認すること
カテゴリー	記事の内容に合っているか
カテゴリー一覧	公開記事へ移動できるか
内部リンク	関連する記事へ案内しているか
リンク先URL	404エラーになっていないか
アンカーテキスト	リンク先の内容が分かるか
孤立ページ	重要な記事がリンクから見つけられるか

内部リンクを見直す際は、次の点を意識しましょう。

• 関連性の高い記事だけをつなぐ
• 同じ記事へのリンクを必要以上に繰り返さない
• リンク先の記事が公開されているか確認する
• パーマリンク変更後は旧URLが残っていないか調べる
• 読者が次に必要とする情報へ自然に案内する

例えば、クローラーの仕組みを説明した記事から、Google検索全体の仕組みを詳しく解説した記事へリンクを設置すると、読者は理解を深めやすくなります。

ただし、内部リンクを増やせば必ずGooglebotの巡回頻度が増えるわけではありません。

読者が迷わず情報を探せる構造を優先しましょう。

キャッシュ・セキュリティ系プラグインの影響を確認する

WordPressでは、表示速度の改善や不正アクセス対策のために、キャッシュ系・セキュリティ系プラグインを利用することがあります。

これらのプラグインはサイト運営に役立ちますが、設定によってはGooglebotのアクセスやページの表示内容に影響する場合があります。

例えば、セキュリティ系プラグインのアクセス制限が厳しすぎると、正規のGooglebotが誤ってブロックされる可能性があります。

また、キャッシュやJavaScriptの最適化設定を変更した結果、記事本文や画像の読み込みに問題が発生することもあります。

主な影響を整理しました。

プラグイン・設定	考えられる影響	確認方法
キャッシュ機能	古いページが表示される場合がある	キャッシュ更新・表示確認
JavaScript最適化	一部の内容が読み込まれない場合がある	公開ページ・レンダリング確認
セキュリティ機能	Googlebotを誤ってブロックする場合がある	アクセスログ・403エラー
アクセス回数制限	429エラーが発生する場合がある	サーバーログ
WAF	一部のアクセスが拒否される場合がある	サーバー管理画面

例えば、プラグインを更新した直後に、Search Consoleでページの取得エラーが増えた場合は、更新した設定が影響していないか確認しましょう。

ただし、原因が分からないままセキュリティ機能をすべて停止することはおすすめしません。

確認するときは、次の順番が適切です。

1. エラーが発生しているURLを確認する
2. 最近変更したプラグインや設定を調べる
3. Search Consoleで取得状況を確認する
4. 必要に応じてサーバーログを確認する
5. 原因を特定してから必要な設定を修正する

Googlebotを装う不正なアクセスも存在するため、User-AgentにGooglebotと表示されているだけで正規のクローラーとは判断できません。

セキュリティ設定の変更が必要な場合は、レンタルサーバーのサポートなども活用しましょう。

設定変更後にGooglebotのアクセス状況を確認する

WordPressやCocoonの設定を変更した後は、Googlebotが正常にページを取得できる状態になっているか確認しましょう。

例えば、noindexを解除した場合や、robots.txtの制限を修正した場合は、変更した設定が公開ページに反映されているか調べます。

その際に役立つのがGoogle Search ConsoleのURL検査ツールです。

確認手順は次のとおりです。

1. 設定を変更した記事のURLを開きます。
2. 記事が正常に表示されるか確認します。
3. Search Consoleを開きます。
4. 対象URLをURL検査欄に入力します。
5. 「公開URLをテスト」をクリックします。
6. クロールやインデックス登録の許可状態を確認します。
7. 必要に応じてインデックス登録をリクエストします。

設定変更後の確認項目を整理しました。

変更した設定	主な確認項目
noindex	登録を禁止する指示が残っていないか
robots.txt	クロールが許可されているか
パーマリンク	正しいURLで表示されるか
301リダイレクト	旧URLから新URLへ転送されるか
キャッシュ設定	現在の内容が表示されるか
セキュリティ設定	Googlebotを妨げていないか

ただし、「公開URLをテスト」で問題が見つからなくても、インデックス登録が完了したわけではありません。

公開URLテストは、現在のページを取得できるかなどを確認するものであり、Googleによる登録を保証するものではないためです。

設定変更後は、公開ページの動作確認とSearch Consoleによる検査を組み合わせることが大切です。

Google Search Consoleでクローラーの巡回状況を確認する方法

Google Search Consoleは、GoogleがWebサイトをどのように認識し、クロールやインデックス登録を行っているかを確認できる無料ツールです。

例えば、WordPressで公開した記事について、Googlebotが最後にクロールした日時や、robots.txtによる制限があるかなどを調べられます。

また、「クロールの統計情報」レポートでは、Googlebotによるリクエスト数やサーバーの応答状況などを確認できます。

ここでは、URL検査ツールとクロールの統計情報レポートを使い分けながら、Googlebotの巡回状況を調べる方法を具体的に説明します。

Search Consoleで確認できるクロール関連の情報

Search Consoleでは、主に次の機能を利用してGooglebotの巡回状況を確認できます。

• URL検査ツール
• ページのインデックス登録レポート
• クロールの統計情報レポート
• サイトマップレポート

それぞれ役割が異なるため、調べたい内容に応じて使い分けましょう。

機能	主な確認内容	おすすめの利用場面
URL検査	個別URLのクロール・登録状況	特定の記事を確認したい
ページのインデックス登録	未登録の理由や登録状況	サイト全体の問題を調べたい
クロールの統計情報	Googlebotのリクエスト数・応答	巡回状況を詳しく調べたい
サイトマップ	サイトマップの送信・取得状況	URL発見の手がかりを確認したい

例えば、「SEOとは？」という記事だけがGoogle検索に表示されない場合は、まずURL検査を使用します。

一方、複数の記事でサーバーエラーが発生している場合は、クロールの統計情報レポートが役立つことがあります。

なお、クロールの統計情報は主に詳しい技術的な調査に使う機能です。

一般的な小規模ブログでは、最初からすべての数値を分析する必要はありません。Google公式ヘルプでも、小規模なサイトでは通常、このレベルの詳細な分析を必要としないと案内されています。

初心者の方は、個別記事はURL検査、サイト全体のクロール状況は統計情報という使い分けを覚えましょう。

URL検査ツールで最終クロール日時を確認する

URL検査ツールでは、Googleが対象ページを最後にクロールした日時を確認できる場合があります。

例えば、WordPressで記事を更新した後に、Googleがその変更を取得したか調べたいときに役立ちます。

基本的な手順は次のとおりです。

1. Google Search Consoleを開きます。
2. 対象サイトのプロパティを選択します。
3. 画面上部の「URLを検査」に記事URLを入力します。
4. Enterキーを押します。
5. 検査結果の「ページのインデックス登録」などの詳細を開きます。
6. 「最終クロール」の日時を確認します。

例えば、次のような情報が表示されたとします。

確認項目	表示例
インデックス登録	登録済み
最終クロール	2026年10月20日
クロールを許可？	はい
ページの取得	成功
インデックス登録を許可？	はい

※日付と結果は説明用の仮データです。

この例では、Googleが10月20日に対象URLをクロールしたことが分かります。

ただし、その後の10月22日に記事を更新した場合、URL検査に表示される情報は更新前の状態に基づいている可能性があります。

そのため、最終クロール日時だけで、現在の本文がすべてGoogleに反映されていると判断しないようにしましょう。

なお、GoogleがまだクロールしていないURLでは、最終クロール日時が表示されない場合もあります。

「クロールを許可？」の項目を確認する

Search ConsoleのURL検査では、「クロールを許可？」という項目を確認できる場合があります。

これは、対象URLについてGooglebotのクロールが許可されているかを示す情報です。

例えば、「クロールを許可？」が「いいえ」と表示されている場合、robots.txtによってクロールが禁止されている可能性があります。

確認したい内容を整理しました。

表示内容	意味	確認したいこと
はい	robots.txtによる禁止が検出されていない	ページの取得状況
いいえ	robots.txtによるクロール禁止	対象URLへのルール
情報が表示されない	取得状況などによって判断できない場合がある	詳細な検査結果

例えば、robots.txtで記事が含まれるディレクトリを禁止している場合、Googlebotはそのページを取得できません。

その場合は、次の点を確認しましょう。

• robots.txtに対象URLを禁止するルールがあるか
• 意図的にクロールを制限しているか
• 公開記事のディレクトリを誤って制限していないか
• サーバーやセキュリティ設定にも問題がないか

ただし、「クロールを許可？」が「はい」であっても、Googlebotがページを正常に取得できたとは限りません。

サーバーエラーやアクセス制限など、ほかの問題が発生する場合もあるためです。

また、「クロールを許可？」と「インデックス登録を許可？」は異なる項目です。

前者は主にrobots.txtの制限、後者はnoindexなどの登録制御に関係します。

Google公式ヘルプでも、両者は区別して説明されています。

公開URLをテストして取得状況を調べる

公開URLテストは、現在公開されているページにGoogleの検査システムがアクセスできるかなどを確認するための機能です。

例えば、Cocoonでnoindexを解除した後に、現在のページが登録可能な状態になっているかを調べる場合に役立ちます。

基本的な操作手順は次のとおりです。

1. Search Consoleで対象URLを検査します。
2. 画面の「公開URLをテスト」をクリックします。
3. テスト結果が表示されるまで確認します。
4. ページの取得状況を確認します。
5. クロールとインデックス登録の許可状態を調べます。
6. 必要であれば、取得されたページの詳細情報を確認します。

確認したい項目を整理しました。

確認項目	主な内容
テスト結果	現在のURLが登録可能な状態か
ページの取得	Googleの検査システムが取得できたか
クロールを許可？	robots.txtによる禁止の有無
インデックス登録を許可？	noindexなどの設定
クロール済みのページ	取得されたHTMLなどの情報

例えば、「URLはGoogleに登録できます」と表示された場合、公開ページが基本的な登録可能条件を満たしていると判断されたことになります。

ただし、この表示は、実際にGoogleへインデックス登録されたことを意味しません。

また、公開URLテストには限界があり、重複ページの判断など、すべての登録条件を検査するわけではありません。

公開URLテストは、現在の取得状態を確認するために利用し、実際の登録状況は通常のURL検査結果で別途確認しましょう。

クロールの統計情報レポートの見方

Search Consoleの「クロールの統計情報」レポートでは、GoogleがWebサイトへアクセスした履歴の集計情報を確認できます。

例えば、Googlebotによるクロールリクエスト数や、サーバーの平均応答時間、エラーの発生状況などを調べられます。

基本的な確認手順は次のとおりです。

1. Search Consoleを開きます。
2. 対象サイトのプロパティを選択します。
3. 左側メニューの「設定」をクリックします。
4. 「クロールの統計情報」を選択します。
5. 表示されたレポートを確認します。

主な項目を整理しました。

項目	意味	確認したいこと
クロールリクエストの合計数	Googleによる取得リクエスト数	急激な増減がないか
ダウンロードの合計サイズ	取得したデータの量	極端な増加がないか
平均レスポンス時間	サーバーの平均応答時間	応答が極端に遅くなっていないか
ホストのステータス	サイトへの接続状況	障害が発生していないか
クロールレスポンス	HTTP応答の内訳	エラーが増えていないか
クロールの目的	新規発見・再取得の区別	取得状況の傾向
Googlebotの種類	アクセスしたクローラーの種類	スマートフォン用などの内訳

Google公式ヘルプでは、クロールの統計情報は主にルートレベルのドメインプロパティ、またはルートレベルのURLプレフィックスプロパティで利用できると説明されています。

そのため、プロパティの種類によっては、レポートが表示されない場合があります。

また、クロールリクエスト数には、HTMLページだけでなく、画像やCSSなどのリソースの取得も含まれます。

クロールリクエストが100回あったからといって、100記事がクロールされたという意味ではありません。

初心者の方は、リクエスト数そのものよりも、ホストの状態やサーバーエラーの有無を確認することから始めましょう。

Googlebotのリクエスト数と応答コードを確認する

クロールの統計情報レポートでは、Googleがサイトへ送信したリクエスト数や、サーバーから返されたHTTPステータスコードの内訳を確認できます。

例えば、通常はHTTP 200の応答が多いサイトで、突然500エラーが増えた場合、サーバーに問題が発生している可能性があります。

代表的な応答コードを整理しました。

コード	意味	確認したいこと
200	正常な応答	ページが正常に取得されているか
301	恒久的な転送	意図したURLへ移動しているか
304	前回から変更なし	正常なキャッシュ関連の応答か
403	アクセス禁止	意図しないアクセス制限
404	ページが存在しない	URLの削除・リンク切れ
429	リクエスト数が多すぎる	アクセス制限の状態
500	サーバー内部エラー	サーバーやWordPressの不具合
503	一時的な利用不可	サーバーの負荷・メンテナンス

例えば、次のような仮のデータがあったとします。

応答コード	リクエスト数
200	800
301	100
404	60
500	40
合計	1,000

※説明用の仮データです。

この場合、500エラーが40件発生しています。

ただし、この40件が40種類のURLを意味するわけではありません。同じURLへの複数のリクエストが含まれる場合があります。

調査するときは、次の順番がおすすめです。

1. エラーが増えた時期を確認する
2. 応答コード別の内訳を調べる
3. 該当するサンプルURLを確認する
4. 最近のWordPressやサーバーの変更と比較する
5. 必要な問題があれば修正する

また、301が多くても、URL移転などで意図した転送が行われている場合は正常なことがあります。

404も、削除したページについて適切に返されている場合は必ずしも問題ではありません。

Google公式ヘルプでも、クロールレスポンスはURL数ではなく、リクエスト数を基準に集計されると説明されています。

HTTPステータスコードは件数だけで判断せず、どのURLで、なぜ発生しているか確認しましょう。

スマートフォン用Googlebotの巡回状況を確認する

Google検索では、主にスマートフォン用Googlebotが取得したモバイル版のコンテンツを、インデックス登録やランキングに利用しています。

そのため、スマートフォン用Googlebotがサイトへアクセスできる状態になっているかも重要です。

Search Consoleのクロール統計では、Googlebotの種類ごとのリクエスト状況を確認できます。

基本的な手順は次のとおりです。

1. Search Consoleの「設定」を開きます。
2. 「クロールの統計情報」を選択します。
3. Googlebotの種類に関する項目を確認します。
4. 「スマートフォン」の分類を選択します。
5. 必要に応じて対象URLや応答コードを調べます。

Googlebotの種類を整理しました。

種類	主な役割
スマートフォン	モバイル端末を再現したページ取得
パソコン	デスクトップ端末を再現したページ取得
画像	画像に関係する取得
動画	動画に関係する取得
ページリソースの読み込み	CSSや画像などのリソース取得

なお、クロール統計でスマートフォン用Googlebotのリクエストが確認できても、すべての記事がインデックス登録されたことを意味するわけではありません。

また、対象となる個別記事を詳しく確認したい場合は、URL検査ツールを使用しましょう。

スマートフォン用Googlebotの巡回を確認するときは、次の点も意識してください。

• モバイル版で記事本文が正常に表示されるか
• 重要な画像が読み込まれるか
• JavaScriptの問題が発生していないか
• robots.txtで必要なリソースを禁止していないか
• URL検査でページの取得に問題がないか

Googlebotの種類は、巡回状況を理解するための情報です。

特定のGooglebotのリクエスト数を無理に増やそうとする必要はありません。

クロールの問題が見つかった場合の調査手順

Search Consoleでクロールの問題が見つかった場合は、原因を整理してから修正しましょう。

例えば、クロール統計で500エラーが急増した場合と、個別記事でrobots.txtによる制限が確認された場合では、必要な対策が異なります。

初心者の方は、次の順番で確認すると分かりやすくなります。

ステップ1：問題が発生しているURLを確認する

まず、特定の記事だけに問題があるのか、サイト全体で発生しているのかを調べます。

ステップ2：URLが正常に開けるか確認する

記事をブラウザで開き、エラーが発生していないか確認します。

ステップ3：URL検査を実行する

Googleが認識しているクロールやインデックス登録の状態を調べます。

ステップ4：公開URLテストを行う

現在のページを取得できるか確認します。

ステップ5：問題の種類を判断する

robots.txt、noindex、サーバーエラー、リダイレクトなどを区別します。

ステップ6：必要な設定を修正する

問題が確認できた場合は、WordPress、Cocoon、サーバーなどの該当箇所を修正します。

ステップ7：修正後の状態を確認する

公開ページとSearch Consoleの情報を再確認します。

問題別の対応を整理しました。

問題	最初に確認したいこと	基本的な対応
robots.txtでブロック	クロール禁止のルール	必要な場合に修正
noindexが設定されている	登録を禁止する設定	意図しない場合に解除
403エラー	アクセス制限	WAFなどを確認
404エラー	URLの削除・変更	リンクや転送を確認
500・503エラー	サーバーの状態	不具合や負荷を調査
リダイレクトの問題	転送先URL	301設定を確認
JavaScriptの問題	レンダリングされた内容	表示処理を確認
未クロール	URLの発見状況	内部リンクなどを確認

ここで注意したいのは、Search Consoleで問題が表示されたからといって、必ず設定変更が必要になるわけではないことです。

例えば、削除済みの記事に対する404エラーや、意図的に設定したnoindexなどは、正常な状態である場合があります。

また、公開URLテストが成功しても、Googleによる再クロールやインデックス登録がすぐに行われるとは限りません。

Googlebotの巡回状況を改善するためには、クロール回数を増やすことよりも、実際に発生している問題を正しく把握し、必要な箇所だけを修正することが大切です。

Googlebotが来ない・クロールされない場合の対処方法

WordPressで記事を公開しても、Googlebotがすぐに巡回するとは限りません。

記事のURLをまだ発見していない場合や、発見していてもクロールの順番が来ていない場合があります。また、robots.txtによるアクセス制限、サーバーエラー、パーマリンク変更後の設定などが影響することもあります。

例えば、Search Consoleで「検出 – インデックス未登録」と表示された場合、GoogleはURLを認識していますが、まだクロールしていない状態です。

ここでは、Googlebotが記事を巡回しない場合の原因と、初心者でも実践できる確認・対処方法を順番に解説します。

記事を公開してもGooglebotが来ないときは？

新しい記事を公開しても、Googlebotがすぐに訪問するとは限りません。

Googleは、内部リンクやXMLサイトマップなどからURLを発見し、クロールの必要性やサーバーの状況などを考慮して巡回しています。

例えば、WordPressで「SEOキーワードの選び方」という記事を公開した翌日にSearch Consoleで確認しても、まだクロールされていない場合があります。

ただし、公開直後にGooglebotが来ないことだけで、サイトに問題があるとは判断できません。

まずは、次の項目を確認しましょう。

• 記事が「公開」状態になっているか
• 記事のURLを開くと正常に表示されるか
• カテゴリー一覧などからリンクされているか
• XMLサイトマップにURLが適切に掲載されているか
• robots.txtによるクロール制限がないか
• Search ConsoleでURLを認識しているか

確認する項目を表にまとめました。

確認項目	確認方法	問題がある場合の対応
公開状態	WordPressの投稿編集画面	公開設定を確認
URL	ブラウザで開く	404などの原因を調査
内部リンク	カテゴリー・関連記事	必要なリンクを設置
XMLサイトマップ	サイトマップのURL	生成・掲載状態を確認
クロール状況	Search ConsoleのURL検査	表示された理由を調査

例えば、記事が下書きのままだった場合は、公開設定を確認する必要があります。

一方、記事が正常に公開され、サイトマップにも掲載されている場合は、Googleのクロール処理がまだ行われていない可能性があります。

Google公式資料では、クロールには数日から数週間かかる場合があると説明されています。

Googlebotがすぐに来ない場合でも、まずは記事の公開状態とURLの発見状況を確認し、問題がなければ一定期間後に再確認しましょう。

「検出 – インデックス未登録」の場合に確認すること

Search Consoleで「検出 – インデックス未登録」と表示された場合、Googleは対象URLを発見していますが、まだクロールしていません。

例えば、WordPressで記事を公開し、XMLサイトマップにURLが掲載されたとしても、Googlebotがそのページへアクセスしていない場合があります。

この状態では、記事の内容が低品質だと判断されたとは限りません。

Google公式ヘルプによると、この状態はGoogleがURLを発見したものの、クロールがまだ行われていないことを示します。サイトへの負荷を考慮してクロールが延期される場合もあります。

確認したい項目は次のとおりです。

• 記事が正常に公開されているか
• GooglebotがURLへアクセスできるか
• 内部リンクから記事へ移動できるか
• XMLサイトマップが正常に取得されているか
• サーバーエラーが発生していないか
• 不要なURLが大量に生成されていないか

主な確認項目を整理しました。

状況	考えられること	確認方法
公開したばかり	クロール待ちの可能性	公開日・URL検査
内部リンクが少ない	URL発見の手がかりが不足	サイト構造を確認
サイトマップに問題	URL情報が適切に伝わっていない	サイトマップレポート
サーバーが不安定	クロールが調整されている可能性	クロール統計
不要なURLが多い	クロール効率に影響する場合がある	URL構造を調査

例えば、同じ記事のURLが不要なパラメータによって大量に生成されている場合は、URL構造を確認するとよいでしょう。

ただし、原因が特定できていない段階で、記事を削除したり、パーマリンクを変更したりする必要はありません。

また、内部リンクを追加しただけで、必ずクロールが早まるわけではありません。

「検出 – インデックス未登録」が続く原因や具体的な確認方法については、「『検出 – インデックス未登録』の原因とは？インデックスされない理由を解説」で詳しく紹介しています。

「クロール済み – インデックス未登録」との違い

「検出 – インデックス未登録」と「クロール済み – インデックス未登録」は、似た表示ですが意味が異なります。

前者はGoogleがURLを発見しているものの、まだクロールしていない状態です。

一方、後者はGooglebotがページをクロールしたものの、インデックス登録していない状態です。

例えば、WordPressで公開した記事がGooglebotに取得されていても、Googleが現時点で登録しないと判断する場合があります。

2つの状態を比較しました。

比較項目	検出 – インデックス未登録	クロール済み – インデックス未登録
URLの発見	済み	済み
クロール	まだ行われていない	実施済み
インデックス登録	未登録	未登録
主な確認対象	URL発見・クロール状況	登録状況・ページ内容
すぐに記事を修正すべきか	必ずしも必要ない	必ずしも必要ない

「クロール済み – インデックス未登録」の場合は、次の項目を確認するとよいでしょう。

• 記事の内容が検索意図に合っているか
• ほかの記事と内容が大きく重複していないか
• 必要な情報が掲載されているか
• Googleが別の正規URLを選択していないか
• 取得後にページの状態が変わっていないか

ただし、「クロール済み – インデックス未登録」と表示されたことだけで、記事の品質が低いと断定することはできません。

Google公式ヘルプでも、クロール後に登録されていないURLは、将来的に登録される場合もあり、必ずしも再クロールをリクエストする必要はないと説明されています。

重要なのは、どちらの状態なのかを正しく区別し、それぞれに合った確認を行うことです。

robots.txtでブロックされている場合の対処方法

robots.txtは、GooglebotなどのクローラーがWebサイト内のどのURLへアクセスできるかを制御するためのファイルです。

例えば、公開記事を含むディレクトリが誤ってクロール禁止になっている場合、Googlebotはそのページの内容を取得できません。

ただし、robots.txtによる制限が、必ずしも間違った設定とは限りません。

管理用のページなど、意図的にクロールを制限している場合もあるためです。

まずは、対象URLに制限が必要か確認しましょう。

robots.txtの確認手順は次のとおりです。

1. ブラウザで自分のサイトのrobots.txtを開きます。
2. User-agentとDisallowの記述を確認します。
3. 公開記事に適用されるルールがないか調べます。
4. Search Consoleで対象URLを検査します。
5. 「クロールを許可？」の項目を確認します。
6. 意図しない制限があれば、必要な箇所を修正します。

代表的な記述例を整理しました。

記述	意味
User-agent: *	すべてのクローラーを対象にする
Disallow: /	サイト全体のクロールを禁止する
Disallow: /sample/	指定したパスを禁止する
Disallow:	この行では禁止対象を指定しない

例えば、次の記述には注意が必要です。

User-agent: *
Disallow: /

これは、対象となるクローラーに対し、サイト全体へのアクセスを禁止する指定です。

一般公開したブログで誤って設定すると、Googlebotが記事を取得できなくなります。

ただし、robots.txtは検索結果へのURL表示を確実に防ぐ仕組みではありません。

Googleは、robots.txtでブロックされたURLでも、ほかのサイトからのリンクなどによってURLの存在を認識する場合があります。

そのため、robots.txtとnoindexを混同しないようにしましょう。

設定変更が必要な場合でも、robots.txt全体を削除するのではなく、問題となっているルールだけを確認・修正することが大切です。

サーバーエラーが続いている場合の確認手順

GooglebotがWebページを取得するには、Webサーバーが正常に応答する必要があります。

しかし、サーバーの負荷やプラグインの不具合などによって、500エラーや503エラーが発生することがあります。

例えば、WordPressのプラグインを更新した後、サイトの一部が表示されなくなった場合です。

そのような状態が続くと、Googlebotによるページの取得にも影響する可能性があります。

代表的なHTTPステータスコードを整理しました。

コード	意味	確認したいこと
200	正常な応答	ページが正しく取得できるか
403	アクセス禁止	WAFや認証設定
404	ページが存在しない	URLや削除の状況
429	リクエストが多すぎる	アクセス制限
500	サーバー内部エラー	WordPressやサーバーの不具合
503	一時的な利用不可	メンテナンスや負荷

サーバーエラーが続いている場合は、次の手順で確認しましょう。

1. 対象URLをブラウザで開きます。
2. ほかの記事でも同じ問題が発生しているか調べます。
3. Search ConsoleでURL検査を行います。
4. クロールの統計情報でエラーの増減を確認します。
5. 最近更新したテーマやプラグインを確認します。
6. 必要に応じてサーバーのエラーログを調べます。
7. 原因が分かった場合に修正します。

例えば、サイト全体で500エラーが発生している場合は、個別記事の本文を修正しても問題が解決しない可能性があります。

このような場合は、WordPressやサーバーの状態を優先して確認しましょう。

一方、削除済みの記事に対する404エラーは、正常な状態である場合もあります。

エラーが表示されたという理由だけですべてを修正するのではなく、そのURLが本来どのような状態であるべきかを判断しましょう。

パーマリンク変更後にクロールされない場合の対応

WordPressでパーマリンクを変更すると、記事のURLが変わります。

そのため、Googleが認識している旧URLと、現在公開している新URLが異なる場合があります。

例えば、次のように変更した場合です。

変更前：

Example Domain

example.com

変更後：

Example Domain

example.com

この場合、Googlebotが旧URLへアクセスした際に、新URLへ正常に転送されるよう301リダイレクトを設定することが重要です。

301リダイレクトは、ページが恒久的に移動したことを示す仕組みです。

確認項目を整理しました。

確認項目	内容
旧URL	正しい新URLへ転送されるか
新URL	正常に表示されるか
301リダイレクト	恒久的な転送になっているか
内部リンク	旧URLが残っていないか
XMLサイトマップ	新URLが掲載されているか
canonical	新しい正規URLを示しているか
Search Console	新URLのクロール・登録状況

例えば、旧URLを開いたときに新URLが表示されても、それだけでインデックス登録が完了したとは限りません。

Googleがリダイレクトを処理し、正規URLの情報を更新するまでには時間がかかる場合があります。

また、リダイレクトチェーンが発生している場合は、可能な範囲で最終URLへ直接転送することも検討しましょう。

Googleは、URL変更後のリダイレクトを通常少なくとも1年間は維持するよう推奨しており、読者の利便性を考えるとさらに長期間維持することも有効です。

すでに正常に機能している301リダイレクトを、一定期間が過ぎたという理由だけで削除しないようにしましょう。

また、数字を使ったパーマリンクだからという理由だけで、URLを変更する必要はありません。

インデックス登録をリクエストする方法

Google Search Consoleでは、特定のURLについてインデックス登録をリクエストできます。

これは、Googleに対象ページのクロールを依頼するための機能です。

例えば、新しい記事を公開した場合や、クロールを妨げる設定を修正した場合に利用できます。

操作手順は次のとおりです。

1. Google Search Consoleを開きます。
2. 対象サイトのプロパティを選択します。
3. 画面上部の「URLを検査」に記事URLを入力します。
4. 現在のインデックス登録状況を確認します。
5. 必要に応じて「公開URLをテスト」をクリックします。
6. 問題がなければ「インデックス登録をリクエスト」を選択します。
7. リクエストが受け付けられたことを確認します。

登録リクエストに関係する表示を整理しました。

表示・操作	意味
URLはGoogleに登録されていません	現時点で未登録
公開URLをテスト	現在のページの取得・登録可能性などを確認
URLはGoogleに登録できます	基本的な登録可能条件を満たすと判断された
インデックス登録をリクエスト	Googleへクロールを依頼する
リクエスト済み	リクエストが受け付けられた

ただし、「URLはGoogleに登録できます」と表示されても、実際にインデックス登録されたわけではありません。

また、リクエストを送信したからといって、必ずGooglebotがすぐに訪問するわけでもありません。

Google公式資料では、クロールのリクエストと検索結果への掲載は別であり、登録が保証されないことが説明されています。

初心者の方は、リクエスト後に同じ操作を何度も繰り返す必要はありません。

一定期間後に、Search Consoleで登録状況を再確認しましょう。

登録リクエストを繰り返しても改善しない場合の考え方

インデックス登録を何度もリクエストしても、未登録の状態が続く場合があります。

しかし、リクエストの回数を増やせば、必ずクロールやインデックス登録が早まるわけではありません。

Googleは、ページの状態やクロールの必要性などを考慮しながら、取得・登録するURLを判断しています。

そのため、改善しない場合は、リクエストの回数ではなく、ページの状態を確認することが大切です。

確認したい項目を整理しました。

確認項目	内容
公開状態	記事が正常に公開されているか
URL	正しいURLを検査しているか
robots.txt	クロールが禁止されていないか
noindex	登録を禁止する設定がないか
canonical	Googleが別URLを選択していないか
サーバー	取得エラーが発生していないか
記事内容	読者に必要な情報が掲載されているか
重複	類似記事との役割が明確か

例えば、「クロール済み – インデックス未登録」と表示されている場合は、Googleがすでにページを取得しています。

この状態で同じURLを何度も送信しても、登録が保証されるわけではありません。

Google公式資料でも、同じURLへの再クロールリクエストを繰り返しても、クロールが早くなることはないと説明されています。

登録されない場合は、次の順番で確認しましょう。

1. Search Consoleの表示内容を確認する
2. 技術的な問題がないか調べる
3. 類似記事や正規URLの状態を確認する
4. 必要に応じて記事内容を見直す
5. 明確な問題があれば修正する
6. 一定期間後に登録状況を再確認する

ただし、未登録という表示だけで、記事の品質が低いと断定することはできません。

登録リクエストを繰り返すよりも、Googleがページを正常に取得できるか、登録したいURLが適切な状態になっているかを確認することが重要です。

Googleクローラーの巡回について初心者が避けたい失敗

Googlebotの巡回について学ぶと、「巡回回数を増やせば検索順位が上がるのでは？」「サイトマップを何度も送信した方がよいのでは？」と考えることがあります。

しかし、クロール回数を増やすことと、検索順位を改善することは同じではありません。

また、robots.txtやパーマリンクなどの設定を十分に理解せず変更すると、Googlebotがページを取得できなくなる場合があります。

ここでは、SEO初心者が注意したい代表的な失敗を紹介し、適切な対応方法を解説します。

Googlebotの巡回回数が多いほど順位が上がると思い込む

Googlebotの巡回回数が多いからといって、検索順位が必ず上がるわけではありません。

クローリングはGoogleがWebページの情報を取得するための処理であり、検索順位の決定とは異なる段階です。

例えば、Googlebotがある記事を毎日のように取得していても、その記事が検索キーワードに関連する情報を十分に提供していなければ、上位表示されるとは限りません。

クロール回数と検索順位の違いを整理しました。

項目	目的	確認方法
クロール回数	ページやリソースの取得状況を把握	クロールの統計情報
インデックス登録	検索用データベースへの登録状況を確認	URL検査
検索順位	検索語句に対する掲載位置を把握	検索パフォーマンス
クリック数	検索結果からの流入を把握	検索パフォーマンス

初心者の方は、次の点を意識しましょう。

• クロール回数だけをSEOの成果と考えない
• 重要な記事が正常に取得されているか確認する
• インデックス登録状況を別に確認する
• 検索順位は検索クエリごとに調べる
• 読者に役立つ記事の作成を優先する

クロール回数を増やすことよりも、Googleが記事を正常に取得でき、読者に必要な情報を提供できていることが大切です。

XMLサイトマップを何度も送信する

XMLサイトマップは、Googleへ重要なURLの情報を知らせるために役立ちます。

しかし、同じサイトマップを何度も送信すれば、Googlebotが早く巡回するという仕組みではありません。

例えば、Search Consoleでサイトマップの取得が正常に行われている場合、毎日手動で再送信する必要は通常ありません。

サイトマップの管理方法を整理しました。

状況	おすすめの対応
サイトマップが正常に取得されている	現在の設定を維持する
新しい記事を公開した	自動生成されるサイトマップの状態を確認する
サイトマップのURLを変更した	必要に応じて新しいURLを送信する
取得エラーが発生している	エラー原因を調べる
旧URLが残っている	正規URLや生成設定を確認する

例えば、WordPressで新しい記事を公開すると、サイトマップ生成機能によってURLが自動的に追加される場合があります。

そのような環境では、記事を公開するたびにサイトマップを手動送信する必要はありません。

ただし、サイトマップにエラーが発生している場合は、正常に取得できる状態へ修正しましょう。

サイトマップは送信回数よりも、内容が正確で正常に取得できることが重要です。

同じURLを繰り返し登録リクエストする

Search Consoleでは、個別記事のインデックス登録をリクエストできます。

しかし、同じURLを何度も送信しても、クロールや登録が必ず早くなるわけではありません。

例えば、記事を公開した日に登録リクエストを送信し、翌日も未登録だからといって何度もリクエストする必要はありません。

Googleは、クロールするタイミングを自動的に判断しています。

登録リクエストについて、初心者が覚えておきたい点を整理しました。

• 登録リクエストはクロールを依頼する機能
• リクエスト送信はインデックス登録の完了ではない
• 同じURLへの連続送信にメリットはない
• 登録リクエストには利用上限がある
• リクエスト後も未登録が続く場合がある

例えば、次のような違いがあります。

表示・状態	意味
リクエスト済み	Googleへ依頼した状態
クロール済み	Googleがページを取得した状態
インデックス登録済み	Googleが登録した状態
検索結果に表示	検索語句に応じて掲載された状態

Googleも、同じURLへのリクエストを繰り返してもクロールが早まらないと案内しています。

リクエスト後は、設定に明確な問題がないか確認したうえで、後日登録状況を調べましょう。

robots.txtを理解せずに変更する

robots.txtは、Googlebotなどのクローラーによるアクセスを制御する重要なファイルです。

そのため、設定内容を理解せず変更すると、公開記事のクロールを妨げる可能性があります。

例えば、次のような記述です。

User-agent: *
Disallow: /

この設定は、対象となるクローラーに対して、サイト全体のクロールを禁止します。

一般公開しているブログに誤って設定すると、Googlebotが記事の内容を取得できなくなります。

robots.txtを変更する前に確認したい項目を整理しました。

確認項目	内容
変更目的	なぜクロールを制限するのか
対象URL	どのページに影響するか
User-agent	どのクローラーに適用されるか
Disallow	禁止するパスが正しいか
noindex	登録制御との違いを理解しているか
バックアップ	元の設定へ戻せるか

robots.txtは、検索結果への表示を確実に防ぐための仕組みではありません。

また、Googlebotにクロールさせないページでは、HTML内のnoindexを読み取れない場合があります。

そのため、検索結果に表示したくないという理由だけでrobots.txtを変更しないようにしましょう。

WordPressやCocoonで正常に動作している設定は、明確な理由がない限り変更する必要はありません。

公開済み記事のURLを安易に変更する

WordPressでは、パーマリンクを変更すると記事のURLが変わる場合があります。

しかし、すでに公開されている記事のURLを変更すると、旧URLから新URLへの移行を適切に管理する必要があります。

例えば、記事URLを次のように変更した場合です。

変更前：

Example Domain

example.com

変更後：

Example Domain

example.com

URLを変更しただけでは、Googleがすぐに新URLを正規ページとして認識するとは限りません。

確認したい項目を整理しました。

確認項目	内容
301リダイレクト	旧URLから新URLへ転送されるか
内部リンク	旧URLが残っていないか
XMLサイトマップ	新URLが掲載されているか
canonical	新しい正規URLが適切か
Search Console	新URLの登録状況

例えば、記事タイトルを変更したいだけなら、通常はパーマリンクまで変更する必要はありません。

また、数字のURLだからSEOに不利だという理由だけで、公開済み記事のURLを変更する必要もありません。

Googleは、URL変更時に適切なリダイレクトや内部リンクの更新などを推奨しています。

すでに公開している記事では、URLの安定性を重視し、不必要なパーマリンク変更を避けましょう。

不要なURLや重複ページを大量に作る

Webサイト内に同じ内容を表示するURLや、必要のないページが大量に生成されると、Googlebotのクロール効率に影響する場合があります。

例えば、同じ記事について複数のパラメータ付きURLが作られる場合です。

https://example.com/1234/

Example Domain
example.com

https://example.com/1234/?ref=menu
example.com

これらが同じ内容を表示する場合、Googleは重複するURLとして認識する可能性があります。

主な問題と確認方法を整理しました。

問題	考えられる影響	確認方法
重複URL	同じ内容のURLが増える	canonicalを確認
不要なパラメータ	クロール対象が増える	URL構造を調査
大量の一覧ページ	重要な記事を見つけにくくなる場合がある	カテゴリー・タグを確認
リダイレクトチェーン	不必要な転送が増える	転送経路を調べる
リンク切れ	存在しないURLへのアクセス	内部リンクを修正

ただし、重複URLが存在するだけで、必ず検索順位が下がるわけではありません。

Googleには正規URLを選択する仕組みがあります。

また、カテゴリーやタグの一覧ページも、読者に役立つものであれば、すべて削除する必要はありません。

重要なのは、不要なURLが大量に生成されていないか確認し、必要に応じて適切に整理することです。

クロールされない記事をすぐに削除する

記事がGooglebotにクロールされていない場合でも、すぐに削除する必要はありません。

例えば、Search Consoleで「検出 – インデックス未登録」と表示されている場合、GoogleはURLを発見していますが、まだクロールしていません。

この状態だけで、記事の内容が悪いと判断されたわけではありません。

記事を削除する前に確認したい項目を整理しました。

確認項目	判断のポイント
公開からの期間	公開直後ではないか
URLの状態	正常に表示されるか
内部リンク	記事を見つける手がかりがあるか
クロール制限	robots.txtなどの問題がないか
記事内容	読者に必要な情報か
類似記事	ほかの記事との役割が重複していないか

例えば、記事を公開して数日しか経過していない場合は、Googlebotがまだ訪問していない可能性があります。

一方、長期間クロールされず、サイト構造やサーバーに問題が見つかった場合は、その問題を優先して修正しましょう。

また、類似した記事が複数ある場合は、読者の検索意図や記事の役割を比較することも大切です。

クロールされていないという理由だけで記事を削除せず、原因と記事の必要性を確認してから判断しましょう。

クロール済みとインデックス登録済みを混同する

Google検索では、クローリングとインデックス登録は異なる処理です。

しかし、初心者の方は「Googlebotが記事を取得したのだから、検索結果に表示されるはず」と考えてしまう場合があります。

実際には、Googleがページをクロールした後も、インデックス登録しないことがあります。

それぞれの違いを整理しました。

状態	意味	検索結果への表示
URL検出	GoogleがURLを認識	まだ保証されない
クロール済み	Googleがページを取得	まだ保証されない
インデックス登録済み	検索用データベースに登録	検索語句に応じて表示される可能性
検索結果に表示	Googleが検索結果として掲載	順位や表示形式は変動する

例えば、「クロール済み – インデックス未登録」と表示された場合は、Googlebotが取得したことは分かりますが、登録済みではありません。

一方、「URLはGoogleに登録されています」と表示された場合でも、特定の検索キーワードで上位表示されるとは限りません。

確認するときは、次のように使い分けましょう。

• クロールの確認： URL検査の最終クロール情報
• インデックス登録の確認： URL検査の登録状況
• 検索結果への表示状況： 検索パフォーマンス
• 検索順位の傾向： 検索クエリごとの平均掲載順位

この違いを理解することで、問題が発生したときに必要な対策を考えやすくなります。

Googlebotが巡回したことをSEOの最終成果と考えず、インデックス登録と検索結果への表示状況まで区別して確認しましょう。

Googleクローラーについてよくある質問

Googlebotの仕組みを理解していても、「記事を公開してから何日でクロールされるの？」「巡回頻度を増やす方法はあるの？」といった疑問を持つ方は少なくありません。

また、robots.txtやnoindex、クロールバジェットなどは、初心者にとって違いが分かりにくい用語です。

ここでは、WordPressでブログを運営する方からよく寄せられる疑問を取り上げ、Googlebotの巡回やインデックス登録との関係を分かりやすく解説します。

Googlebotは毎日必ずサイトを巡回しますか？

いいえ。Googlebotが毎日必ずすべてのWebサイトを巡回するわけではありません。

Googleは、Webサイトの更新状況やページの重要性、サーバーの状態などを考慮して、クロールするURLや頻度を自動的に判断しています。

例えば、頻繁に新しい情報が公開されるニュースサイトと、月に数回更新する個人ブログでは、Googlebotの巡回状況が異なる場合があります。

また、Googlebotがトップページを訪問しても、その日にすべての個別記事をクロールするとは限りません。

巡回頻度に関係する主な要素は次のとおりです。

• ページの更新状況
• Googleが判断するクロール需要
• URLの人気度や認識状況
• サーバーの応答速度
• サーバーエラーの発生状況

Googlebotが毎日来ていなくても、記事が正常にインデックス登録されていれば、必ずしも問題があるわけではありません。

巡回回数そのものよりも、重要な記事がGoogleに正常に取得されているかを確認しましょう。

新しい記事を公開すると何日でクロールされますか？

新しい記事がクロールされるまでの期間は、Webサイトによって異なります。

Googleの公式資料では、クロールには数日から数週間かかる場合があると説明されています。

ただし、必ず数日以内にクロールされるという保証はありません。

例えば、WordPressで記事を公開した翌日にGooglebotが訪問する場合もあれば、さらに時間がかかる場合もあります。

確認したい項目を整理しました。

確認項目	内容
記事の公開状態	正常に公開されているか
URL	ブラウザで開けるか
内部リンク	カテゴリーなどから移動できるか
XMLサイトマップ	URLが適切に掲載されているか
Search Console	GoogleがURLを認識しているか

例えば、公開直後にSearch Consoleで「検出 – インデックス未登録」と表示されても、すぐに記事を修正する必要があるとは限りません。

まずは設定を確認し、問題がなければ一定期間後に再確認しましょう。

Googlebotの巡回頻度を増やす方法はありますか？

Googlebotの巡回頻度を、サイト運営者が自由に指定することはできません。

例えば、「毎日10回クロールしてほしい」と設定しても、Googlebotがその指示どおりに動くわけではありません。

ただし、Googlebotが重要なページを発見し、正常に取得できる環境を整えることはできます。

基本的な対策は次のとおりです。

• 内部リンクを適切に整理する
• XMLサイトマップを正常に管理する
• サーバーエラーを減らす
• robots.txtの設定を確認する
• 不要なURLの大量生成を避ける
• 読者に役立つ記事を必要に応じて更新する

例えば、記事のURLを変更した後にリンク切れが発生している場合は、内部リンクを修正することが役立ちます。

ただし、これらの対策を行っても、必ず巡回回数が増えるわけではありません。

Googleも、クロールの必要性に応じて頻度を判断していると説明しています。

巡回回数を増やすことよりも、クロールを妨げる問題を減らすことを優先しましょう。

Googlebotは画像やPDFもクロールしますか？

はい。Googlebotは通常のHTMLページだけでなく、画像やPDFなどのファイルも取得することがあります。

例えば、WordPressの記事に掲載した写真がGoogle画像検索に表示されたり、公開したPDF資料がGoogle検索に登録されたりする場合があります。

ただし、ファイルを公開すれば必ずクロール・インデックス登録されるわけではありません。

主な対象を整理しました。

ファイルの種類	Googleの対応	ブログでの具体例
HTML	ページの内容を取得	通常のブログ記事
JPEG・PNG・WebP	画像情報を取得できる	アイキャッチ・説明画像
PDF	対応するPDFの内容を取得できる	操作マニュアル・資料
CSS	ページの表示に必要な場合に取得	Cocoonのデザイン
JavaScript	ページの処理・表示に利用	動的なメニューなど

例えば、家庭菜園の記事で栽培カレンダーをPDF形式で公開した場合、GoogleがそのPDFのURLを発見して取得する可能性があります。

ただし、GooglebotによるPDFのクロールにはファイルサイズなどの制限があり、すべての内容が必ず処理されるとは限りません。

画像やPDFを公開するときは、次の点を確認しましょう。

• ファイルのURLが正常に開けるか
• robots.txtで取得を妨げていないか
• ファイル名が内容に合っているか
• 画像には適切なalt属性を設定しているか
• PDFは文字を選択できるなど、内容を理解しやすい形式か

特に、画像内の文字だけで重要な情報を伝えるのではなく、記事本文にも必要な説明を掲載すると、読者にとって分かりやすくなります。

robots.txtでGooglebotを完全にブロックできますか？

robots.txtを使用すると、ルールに従うGooglebotに対して、指定したURLへのクロールを禁止できます。

例えば、次の設定です。

User-agent: Googlebot
Disallow: /

これは、Googlebotによるサイト全体へのクロールを禁止する記述例です。

ただし、ここで注意したいのは、クロールを禁止することと、検索結果からURLを完全に消すことは別という点です。

違いを整理しました。

目的	適した方法
Googlebotのクロールを制限する	robots.txt
Google検索への登録を防ぐ	noindex
一般の閲覧者もアクセスできないようにする	パスワード保護・認証など
検索結果から緊急に一時非表示にする	Search Consoleの削除ツールなど

robots.txtでブロックしたURLでも、ほかのWebページからリンクされていれば、URLだけが検索結果に表示されることがあります。

また、robots.txtはセキュリティ機能ではないため、個人情報を保護する目的には適していません。

WordPressで公開したい記事がある場合は、サイト全体を誤ってクロール禁止にしないよう注意しましょう。

noindexを設定したページもクロールされますか？

はい。noindexを設定したページでも、Googlebotがクロールすることがあります。

むしろ、Googleがnoindexの指示を確認するには、通常、そのページやリソースを取得できる必要があります。

例えば、WordPressで公開している固定ページにnoindexを設定した場合、Googlebotがそのページへアクセスし、noindexを確認すると、Google検索のインデックス登録対象から除外します。

ただし、robots.txtでクロールを禁止している場合、Googlebotがnoindexを読み取れないことがあります。

違いを整理しました。

設定	クロール	インデックス登録
通常の公開ページ	可能	Googleの判断による
noindex	通常は可能	Googleが指示を認識すれば除外
robots.txtで禁止	指定URLのクロールを禁止	URLのみ表示される場合がある
robots.txt禁止とnoindexの併用	noindexを読み取れない場合がある	除外を保証できない

Googleの公式資料でも、noindexを有効にするには、Googlebotが指示を取得できる状態が必要であると説明されています。

検索結果に表示したくないページは、目的に応じてnoindexを利用し、robots.txtと混同しないようにしましょう。

クロールバジェットは初心者のブログでも重要ですか？

一般的な小規模ブログでは、クロールバジェットを過度に気にする必要はありません。

クロールバジェットとは、GoogleがWebサイトへ割り当てるクロール能力や需要に関係する考え方です。

特に、大量のページを持つ大規模サイトや、頻繁にURLが増えるサイトなどで重要になる場合があります。

サイトの規模別に整理しました。

サイトの状況	おすすめの対応
数十～数百記事のブログ	基本設定と内部リンクを確認
数千記事のサイト	URL構造や未登録状況を確認
大量のURLを持つ大規模サイト	クロールバジェットの詳しい分析を検討
未クロールURLが大量に発生	規模を問わず原因を調査

例えば、WordPressで300記事を公開している場合、まずはXMLサイトマップや内部リンク、サーバーエラーなどを確認する方が実践的です。

ただし、記事数が少なくても、不必要なURLが大量に生成されている場合などは注意が必要です。

初心者はクロールバジェットの数値を追うよりも、重要な記事が正常に発見・取得されるサイトづくりを優先しましょう。

クローリングされれば必ずインデックス登録されますか？

いいえ。Googlebotが記事をクロールしても、必ずインデックス登録されるわけではありません。

クローリングは、Googleがページの内容を取得する処理です。

一方、インデックス登録は、取得した情報を分析し、検索用データベースに登録する処理です。

例えば、Search Consoleで「クロール済み – インデックス未登録」と表示された場合は、Googleがページを取得したものの、インデックス登録していない状態です。

違いを整理しました。

状態	意味
URL検出	GoogleがURLを認識
クロール済み	ページの情報を取得
インデックス登録済み	検索用データベースへ登録
検索結果に表示	検索語句に応じて掲載

例えば、内容が非常によく似た記事が複数ある場合、Googleが別の正規URLを選択する可能性があります。

また、クロール後に登録されない理由は一つとは限りません。

そのため、未登録になったという理由だけで、記事の品質が低いと断定しないことが大切です。

Googleも、クロールとインデックス登録は保証されるものではないと説明しています。

Search Consoleに登録するとGooglebotが来やすくなりますか？

Search Consoleにサイトを登録すると、Googleが認識しているクロールやインデックス登録の状態を確認できるようになります。

また、XMLサイトマップの送信や、URL検査によるクロールのリクエストも利用できます。

ただし、Search Consoleへ登録すること自体が、Googlebotの巡回頻度を直接増やすものではありません。

Search Consoleの主な役割を整理しました。

機能	できること
URL検査	個別記事の登録状況を確認
インデックス登録リクエスト	クロールを依頼
サイトマップ	URL一覧の場所を通知
ページのインデックス登録	未登録の理由を確認
クロールの統計情報	Googlebotのリクエスト状況を確認

例えば、記事を公開した後にSearch ConsoleでURLを検査すると、GoogleがURLを認識しているか確認できます。

また、必要に応じてインデックス登録をリクエストできます。

ただし、登録リクエストを送信しても、必ずクロールやインデックス登録が行われるわけではありません。

Search Consoleは巡回回数を増やすためのツールではなく、Google検索におけるサイトの状態を確認・管理するためのツールと理解しましょう。

記事を更新するたびに登録リクエストは必要ですか？

いいえ。記事を更新するたびに、必ずインデックス登録をリクエストする必要はありません。

Googlebotは、公開済みページを必要に応じて再クロールしています。

また、WordPressのXMLサイトマップなどを通じて、更新されたURLをGoogleが把握することもあります。

例えば、誤字を1か所修正した程度であれば、毎回登録リクエストを送信する必要は通常ありません。

一方、重要な情報を大幅に更新した場合や、クロールを妨げる技術的な問題を修正した場合には、再クロールをリクエストする方法があります。

更新内容別に整理しました。

更新内容	登録リクエストの考え方
誤字や表現の軽微な修正	通常は不要
本文の大幅な更新	必要に応じて検討
重要な情報の修正	必要に応じて検討
noindexの誤設定を修正	URL検査後に検討
サーバーエラーを修正	取得状況を確認して検討
URLを変更した	転送や新URLを確認したうえで検討

Google公式資料でも、同じURLについて登録リクエストを繰り返しても、クロールが早くなるわけではないと説明されています。

記事更新のたびにリクエストするのではなく、変更内容とSearch Consoleの状態に応じて判断しましょう。

Googlebotの巡回を理解してWebサイトを適切に管理しよう

Googlebotは、内部リンクやXMLサイトマップなどを手がかりにWebページを発見し、必要に応じてクロールするプログラムです。

ただし、記事を公開しても必ず巡回されるわけではなく、クロール済みでもインデックス登録されない場合があります。

WordPressでは、robots.txtやnoindex、サーバーエラー、内部リンクなどの設定を適切に管理することが大切です。

また、Search Consoleを活用してGooglebotの巡回状況を確認し、問題がある場合は原因に応じて改善しましょう。

今日覚えておきたい重要ポイント3つ

Googlebotについて、初心者が覚えておきたいポイントは次の3つです。

1．GooglebotはWebページを発見・取得するクローラー

Googlebotは、内部リンクやXMLサイトマップなどを手がかりにURLを発見し、Webページの情報を取得します。

2．クロールとインデックス登録は別の処理

Googlebotが記事を取得しても、必ずインデックス登録や検索上位表示が行われるわけではありません。

3．Search Consoleで巡回状況を確認することが大切

記事がGoogle検索に表示されない場合は、URL検査やインデックス登録レポートを確認し、必要な対策を行いましょう。

Googlebotの役割とクローリングの仕組み早見表

GooglebotがWebページを発見してから、検索結果に表示されるまでの基本的な流れを整理しました。

段階	主な処理	確認したいこと
① URL発見	リンクやサイトマップなどからURLを見つける	内部リンク・サイトマップ
② クローリング	Webページの情報を取得する	robots.txt・サーバー状態
③ レンダリング	必要に応じてJavaScriptなどを処理する	本文・画像の表示
④ インデックス登録	ページ内容を分析して登録を判断する	URL検査・noindex
⑤ 検索結果への表示	検索語句に応じてページを表示する	検索パフォーマンス

例えば、新しい記事がクロールされていない場合は、URLの発見状況やアクセス制限を確認します。

一方、クロール済みでもインデックス未登録の場合は、ページの内容や正規URLなども確認対象になります。

問題がどの段階で発生しているかを把握することが、適切な対処への第一歩です。

Googlebotの巡回を妨げる原因と対処方法一覧表

Googlebotが正常に巡回できない場合には、さまざまな原因が考えられます。

代表的な原因と対処方法をまとめました。

原因	主な問題	対処方法
robots.txt	クロールが禁止されている	ルールを確認
noindex	インデックス登録が禁止されている	意図した設定か確認
403エラー	アクセスが拒否されている	WAFや認証設定を確認
404エラー	URLにページが存在しない	URL変更・削除状況を確認
500・503エラー	サーバーに問題がある	ログやプラグインを確認
内部リンク不足	URLを発見しにくい	関連ページからリンク
XMLサイトマップの問題	URL情報が適切に伝わらない	生成・取得状況を確認
JavaScriptの問題	重要な内容を取得できない	レンダリングを確認
リダイレクトの問題	新URLへ正常に移動できない	301設定を確認

なお、noindexはクロールそのものを禁止する設定ではありません。また、404エラーも意図的に削除したページであれば正常な状態です。

エラーの件数だけで判断せず、個別のURLが本来どのような状態であるべきかを確認しましょう。

WordPressのクローリング対策チェックリスト

WordPressやCocoonを利用している場合、次の項目を確認しておくと、Googlebotの巡回を妨げる問題を発見しやすくなります。

WordPress設定チェック

□ 記事が「公開」状態になっている
□ WordPressの検索エンジン向け表示設定に問題がない
□ Cocoonで意図しないnoindexが設定されていない
□ robots.txtで公開記事を誤って禁止していない
□ XMLサイトマップが正常に取得できる
□ 重要な記事へ内部リンクから移動できる
□ 旧URLから新URLへの301リダイレクトが正常に機能する
□ スマートフォンでも本文と画像が表示される
□ サーバーエラーやプラグインの不具合がない

すべての項目を毎日確認する必要はありません。

例えば、WordPressの設定やプラグインを変更したとき、パーマリンクを変更したとき、Search Consoleで新しい問題が確認されたときなどに見直すとよいでしょう。

Search Consoleで確認したい項目チェックリスト

Googlebotが記事をどのように取得しているかを調べる際は、Search Consoleを活用しましょう。

Search Console確認チェック

□ 対象記事のURLを検査した
□ Googleへのインデックス登録状況を確認した
□ 最終クロール日時を確認した
□「クロールを許可？」を確認した
□「ページの取得」の結果を確認した
□「インデックス登録を許可？」を確認した
□ 必要に応じて公開URLテストを実行した
□ サイトマップの取得状況を確認した
□ 必要に応じてクロールの統計情報を確認した
□ 問題を修正した場合は後日結果を再確認する

例えば、Search Consoleで「URLはGoogleに登録されていません」と表示された場合は、インデックス登録されていない理由を確認します。

また、「公開URLをテスト」で登録可能と表示されても、実際に登録されたことにはなりません。

問題を修正した後は、必要に応じて登録リクエストを行い、一定期間後に状態を再確認しましょう。

Googlebotの巡回状況を正しく理解し、WordPressの設定とSearch Consoleの情報を組み合わせて管理することが、安定したブログ運営につながります。

まとめ

Googleクローラー（Googlebot）は、WebサイトのリンクやXMLサイトマップなどを手がかりにURLを発見し、ページの情報を取得する役割を担っています。

ただし、記事を公開しても必ずクロールやインデックス登録が行われるわけではありません。

Googlebotが正常に巡回できるように、内部リンクやrobots.txt、サーバーの状態を適切に管理することが大切です。

また、Search Consoleでクロール状況を確認し、問題が見つかった場合は原因に応じて改善しましょう。