クロール可能性の問題：クロールを妨げる原因と修正方法

要点 — クロール可能性とは、検索エンジンがページを発見して到達できるかを示すものです。 robots.txtによる遮断、たどれないリンク、エラーを返し続けるサーバー、大量の不要URLなど、到達を妨げるものがクロール可能性の問題です。 クロールできないページはインデックス登録されず、検索結果にも表示されません。まずアクセス問題を直してください。

クロール可能性とは

ページが順位を得る前に、検索エンジンはGooglebotやBingbotを送り、URLを発見してページを取得する必要があります。クロール可能性とは、それをどれだけ容易に行えるかです。クロール可能性の問題は、その処理を止めたり遅らせたりする技術的要因です。 Evidence for this claim Google describes Search as crawling, indexing, and serving, and not every page proceeds through every stage. Scope: Google Search processing model. Confidence: high · Verified: 2026-07-14 Google: How Search works

検索を 発見 → クロール → レンダリング → インデックス登録 → 提供 の流れとして考えます。この5段階は実務向けの整理であり、Google公式モデルでは発見とレンダリングも広い「クロール」段階に含めます。いずれにせよクロールは上流にあり、その後のすべてが依存します。ボットが読めなければ、コンテンツの質が高くても意味がありません。

クロール可能性を損なう4種類の問題

ほぼすべての問題は4分類のいずれかに入ります。これは切り分けを速めるための方法で、サイトマップ不足や誤った noindex などを含む完全な一覧ではありません。URLが発見されないときは、まず分類を特定します。

1. アクセスが遮断されている。 robots.txt、ログイン、403を返すファイアウォール、CSS/JSの遮断などです。
2. リンクが壊れているかクロール不能。 JavaScriptクリックだけのナビゲーションや、内部リンクのない孤立ページです。
3. サーバーが失敗している。 サーバーエラー、DNS障害、極端な遅延、長いリダイレクトチェーンです。
4. URL在庫が肥大化している。 フィルター、カレンダー、追跡タグが類似URLを大量生成し、重要ページより不要URLにクロールを浪費させます。

多くの人が誤解する点

robots.txtでページを遮断してもGoogleから削除されません。 Googleがページを読めなくなるだけです。外部リンクがあれば説明文なしで検索結果に出る場合があります。削除したいなら、クロールを許可したうえで noindex を指定します。 Evidence for this claim Google says robots.txt controls crawler access and is not a mechanism for keeping a page out of Google. Scope: Google robots.txt behavior; noindex must remain crawlable to be observed. Confidence: high · Verified: 2026-07-14 Google: robots.txt introduction

また、クロールはランキングではありません。 クロール頻度を上げても順位は上がりません。クロールは通過すべき入口であり、評価点ではありません。

Search Consoleやサーバーログでの調査方法、問題別の修正を確認するには、上級者向けタブへ進んでください。

要点 — クロール可能性とは、クローラーがページを発見、アクセス、取得できる度合いです。問題は主に、アクセス遮断、リンク不備、サーバー障害、URL在庫の肥大化の4種類です。インデックス登録とランキングの上流にある必要条件ですが、ランキングシグナルではなくインデックス可能性とも別です。GSCとサーバーログで診断し、まずアクセス、次に在庫を修正します。

クロール可能性とは何か（そして何ではないか）

クロール可能性は 発見 → クロール → レンダリング → インデックス登録 → 提供 の最初の段階です。 Evidence for this claim Google describes Search as crawling, indexing, and serving, and not every page proceeds through every stage. Scope: Google Search processing model. Confidence: high · Verified: 2026-07-14 Google: How Search works ここでの失敗は登録と順位の上流にあります。「クロール可能性」はSEO実務上の包括語で、Google公式は検索をクロール、インデックス登録、提供の3段階とし、URL発見とレンダリングをクロールに含めます。本記事の5段階と4分類は、問題を速く特定するための実務的な整理です。

混同を避けるため、次の3つの「同じではない」を押さえます。

• クロール可能性 ≠ インデックス可能性。 クロールできても noindex や品質シグナルで登録されないことがあります。
• クロール ≠ ランキング。 Googleは “an increased crawl rate will not necessarily lead to better positions in Search results… while crawling is necessary for being in the results, it’s not a ranking signal.” (翻訳) クロール頻度を上げても検索順位が改善するとは限らず、クロールは結果表示に必要でもランキングシグナルではありません。
• クロール ≠ レンダリング。 Googleは別工程で “during the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome” (翻訳) クロール中に最新バージョンのChromeを使ってページをレンダリングし、検出したJavaScriptを実行します。レンダリング待ちのため初回取得より遅れる場合があります。

パイプライン全体はクロールのハブで解説します。本記事は障害時の切り分け層です。

クロール可能性問題の4分類

問題を速く特定するために使います。これは完全な分類ではありません。サイトマップ、noindex、canonical、nofollow、モバイル同等性、重複コンテンツは重要ですが、多くは純粋なアクセス障害ではなく、発見、インデックス可能性、レンダリング、クロール効率の問題です。

1. アクセスが遮断されている

robots.txtによる遮断。 Disallow はクローラーによるURL取得を止めます。Googleは “A robots.txt file tells search engine crawlers which URLs the crawler can access on your site… It is not a mechanism for keeping a web page out of Google.” (翻訳) robots.txtはクローラーがアクセスできるURLを示すもので、ウェブページをGoogleから除外する仕組みではありません。ステージング用の Disallow: /、CMSの広すぎる規則、必要な *.js / *.css の遮断が典型例です。 Evidence for this claim Google says robots.txt controls crawler access and is not a mechanism for keeping a page out of Google. Scope: Google robots.txt behavior; noindex must remain crawlable to be observed. Confidence: high · Verified: 2026-07-14 Google: robots.txt introduction

noindexとdisallowの罠。 robots.txtで遮断しながら noindex を置くと、Googleはページを取得できず指定を読めません。外部リンク経由で登録が残ることがあります。登録解除にはクロールを許可して noindex を追加します。robots.txtで遮断されても登録された実験 でも、“crawling and indexing are two different things.” (翻訳) クロールとインデックス登録は別のものです。

ログイン障壁と401。 Googlebotが完了できないログインやOAuthの内側にあるコンテンツは到達不能です。ただし、すべてのペイウォールがクロール不能という意味ではありません。購読コンテンツを一般訪問者とクローラーに異なる方法で提示する運用もあるため、Googlebotが通過できないログインと従量制・有料壁は分けて判断します。

403 Forbidden。 IP許可リストを変更する前に、次の順で原因を調べます。

1. robots.txt：対象ユーザーエージェントでパスが禁止されていないか。
2. 断続的またはキャッシュされた遮断：複数回、複数地点から再試験。
3. ユーザーエージェント遮断：WAF/CDNの特定ボット規則。文字列は偽装可能です。
4. IP範囲遮断（4xx）：ファイアウォール、CDN、地域規則。 ユーザーエージェントだけでなく逆引きと正引きDNSで確認したGooglebotのみを許可し、実際の遮断層を特定してから変更します。

JS/CSSの遮断。 GoogleはヘッドレスChromeでレンダリングします。robots.txt やCDNが必要なJS/CSSを拒否すると、レンダリング後のページが壊れ、コンテンツやリンクを認識できない場合があります。URL検査のライブテストとスクリーンショットで確認します。

2. リンクが壊れているかクロール不能

クロール不能なリンク。 “Google can only crawl your link if it’s an <a> HTML element with an href attribute. Most links in other formats won’t be parsed and extracted by Google’s crawlers.” (翻訳) Googleがクロールできるのはhref属性を持つa要素のリンクで、その他の形式の多くは解析・抽出されません。<a routerLink="...">、<span href="...">、<a onclick="goto(...)"> は対象外です。主要ナビゲーションがJSクリックだけなら、サイトの一部が発見されないことがあります。JavaScript SEOの問題とベストプラクティス も参照してください。

孤立ページ。 内部リンクがないページはサイトマップか外部リンクでしか発見できません。サイトマップは発見を助けますが、リンクシグナルの代わりにはなりません。関連するハブやカテゴリからリンクしてください。

深いページ。 ホームから多くのクリックを要するページは、クロールが遅く頻度も下がります。重要ページは浅い階層に置きます。

3. サーバーが失敗または制限している

5xxサーバーエラー。 500 / 502 / 503 / 504 はコンテンツの代わりにエラーを返します。継続するとGooglebotは “they try not to crawl the site too fast to avoid overloading it… HTTP 500 errors mean ‘slow down’” (翻訳) サイトを過負荷にしないようクロール速度を抑え、HTTP 500は「減速」の意味になります。 と判断し、登録済みページをやがて削除することもあります。robots.txtが5xxの場合、まず約12時間停止し、最終正常版を最長30日使うなど段階的です。計画停止には Retry-After 付き 503 が正しく、数週間続くと悪影響があります。429 も同様に後退します。

DNS障害。 HTTPより上流の問題です。期限切れドメイン、ネームサーバー移行失敗、apex解決障害などで名前解決できなければ、5xxを返すサーバーにも到達できません。継続すればサイト全体が落ちます。GSCのクロール統計にあるホスト状態と外部監視で検出します。

遅い応答と取得の切り詰め。 サーバーが遅いほどGoogleのクロールは減ります。2026年3月のInside Googlebot による取得上限はURLあたり約2 MB、PDFは64 MBです。超過部分は拒否ではなく切り詰められ、取得済み部分だけが登録対象になります。重要内容を大量データの後ろに置かないでください。

リダイレクトチェーンとループ。 各ホップはクロール資源を使い、長いチェーンはクロールに悪影響があります。Googleは約5ホップで到達を諦める場合があります。ループはタイムアウトし、GSCでリダイレクトエラーになります。

4. URL在庫が肥大化している

スパイダートラップ。 ファセットの組み合わせ、終わりのないカレンダー、セッションID、無限ページネーションなどが事実上無限のURLを生成します。不要な類似URLにクロールが偏り、実ページが減ります。一律のしきい値はなく、サイト固有の通常値に対して特定パターンへ不釣り合いにアクセスが集中することが兆候です。

URLパラメータ。 クエリ文字列（?key=value）は同じ内容に複数URLを作ります。並べ替え・絞り込み・ページ分割は類似、追跡・セッションIDは完全重複を生みます。GoogleはURL Parametersツールを2022年4月に廃止しました。現在は順序を統一し、受動パラメータには rel=canonical、本当のトラップだけをrobots.txtで遮断します。BingにはIgnore URL Parametersが残っています。

ソフト404。 空の検索結果など、実質「見つからない」のに 200 OK を返すページです。Googleは存在すると判断して取得を続けます。実際の 404 または 410（410 Gone） を返してください。

クロールバジェットの枯渇（大規模サイトのみ）

これは4番目の問題が大規模化したものですが、ほとんどのサイトでは起きません。 Googleは “if your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” (翻訳) 急速に変化する大量ページがなく、公開当日にクロールされるなら、このガイドを読む必要はありません。10万URL程度では通常影響せず、週次更新100万ページ以上、日次更新1万ページ以上が目安です。予算はホスト名単位でGoogleの各クローラーが共有し、増え続ける「検出・未登録」が警告になります。解説記事 も参照してください。

クロール可能性の問題を見つける方法

Google Search Console。

• ページのインデックス登録レポート：robots.txtによるブロック、5xx、404、リダイレクトエラーを表示します。
• クロール統計：応答コード、平均応答時間、DNS・robots.txt・接続のホスト状態を表示します。
• URL検査（ライブテスト）：Googlebotが取得・レンダリングした内容を確認できます。
• 「検出・インデックス未登録」：URLは認識されたが未取得で、リンクや優先度の問題が多い状態です。

サーバーログ分析が事実の基準です。ボットがどのURLへ何回アクセスし、どのステータスを得たかが分かります。逆引きと正引きDNSで本物のGooglebotを確認できる唯一の方法でもあります。スパイダートラップは特定URLパターンへの偏りとして現れます。

サイト監査クローラーのAhrefs Site AuditやScreaming Frog SEO Spiderはクロールを再現し、リダイレクトチェーン、遮断URL、孤立ページ、クロール深度を一度に検出します。

クロール可能性とインデックス可能性を混同しない

要するに、クロール可能性はボットがページへ到達できるか、インデックス可能性は取得後にGoogleが保存するかです。クロールを直した後の次の関門がインデックス可能性です。

GSCの状態は診断の出発点であり、確定原因ではありません。「検出・未登録」は通常クロールの予定・優先度、「クロール済み・未登録」は多くの場合コンテンツ品質を示します。ただしレンダリング遅延、canonical、登録適格性なども同じ表示を生みます。URL検査とログで確認し、インデックス問題にクロール対策を当てないでください。

Bingのクロール可能性がGoogleと異なる点

両方を最適化する場合に知っておくべき違いです。

• IndexNow：Bingなどは即時通知に利用しますが、Googleは参加していません。
• Crawl Control：Bingには時間帯を設定する機能があります。Googleは2024年1月に速度スライダーを廃止しました。
• Ignore URL Parameters：Bingには残り、Google版は2022年4月に廃止されました。
• lastmod：Bingは再クロール信号として重視し、Googleは不正確ならほぼ無視します。

Microsoft BingのFabrice Canelは “Less is more for SEO… Less URLs to crawl, better for SEO” (翻訳) SEOでは少ないほどよく、クロールするURLが少ないほどよい、と要約しています。

次に読む場所

本記事は地図です。アクセス制御はrobots.txtとnoindex、サーバーは5xx、クロール速度、リダイレクトエラー、URL肥大化はスパイダートラップ、URLパラメータ、クロールバジェット、発見とリンクは発見、クロール深度、孤立ページへ進んでください。全体はクロールハブから始めます。

AIによる要約

上級者向け内容の要約です。

• クロール可能性は、クローラーがページを発見、アクセス、取得できる度合いです。 検索処理の上流にあります。
• 異なる3概念： クロール可能性とインデックス可能性、クロールとランキング、クロールとレンダリングは別です。
• 4分類： アクセス遮断（401、403）、リンク不備（<a href> ではない導線）、サーバー障害（5xx）、URL在庫の肥大化（内容のない200）です。
• 大きな罠： noindex とdisallowを併用するとGoogleはnoindexを読めません。登録解除にはクロール許可とnoindexを使います。
• クロールバジェットは非常に大きく更新頻度の高いサイトで主に問題になります。
• 診断にはGSCとサーバーログを使い、アクセスから修正します。
• Bingとの違い： IndexNow、Crawl Control、Ignore URL Parameters、lastmod の扱いがあります。

公式ドキュメント

クロール障害を説明する一次資料です。

Google

• Google検索の仕組み：詳細ガイド — クロール、登録、提供、URL発見、減速の仕組み。
• クロールとインデックス登録 — robots、サイトマップ、canonical、制御。
• robots.txt入門 — できることとできないこと。
• クロール可能なリンク — <a href> の要件。
• クロールバジェットの最適化 — 容量、需要、浪費。
• Googleクローラーの概要 — ユーザーエージェントとIP範囲。
• Inside Googlebot（2026年3月） — 約2 MB、PDF 64 MBの上限と切り詰め。
• ページのインデックス登録レポート — 各状態の意味。

Bing / Microsoft

• bingbot：クロール効率の最大化 — Bingの定義。
• Bing Webmaster Tools：Crawl Control — 時間帯の設定。
• IndexNow — Bingなどが使う更新通知プロトコル。

出典からの引用

GoogleとBingの公表発言です。各リンクは出典ページの引用箇所へ移動します。

Google — robots.txtは削除手段ではない

• “A robots.txt file tells search engine crawlers which URLs the crawler can access on your site.” (翻訳) robots.txtファイルは、クローラーがサイト上でアクセスできるURLを伝えます。 — Google Search Centralドキュメント。 引用箇所
• “It is not a mechanism for keeping a web page out of Google.” (翻訳) ウェブページをGoogleから除外するための仕組みではありません。 引用箇所
• “The instructions in robots.txt files cannot enforce crawler behavior; it’s up to the crawler to obey them.” (翻訳) robots.txtの指示はクローラーの挙動を強制できず、従うかどうかはクローラー次第です。 引用箇所

Google — クロール可能なリンク

• “Google can only crawl your link if it’s an <a> HTML element with an href attribute.” (翻訳) Googleがリンクをクロールできるのは、href属性を持つa要素の場合です。 — クロール可能なリンクの作成。 引用箇所
• “Most links in other formats won’t be parsed and extracted by Google’s crawlers.” (翻訳) その他の形式のリンクの多くはGoogleのクローラーに解析・抽出されません。 引用箇所

Google — サーバー状態とレンダリング

• “They try not to crawl the site too fast to avoid overloading it. This mechanism is based on the responses of the site (for example, HTTP 500 errors mean ‘slow down’).” (翻訳) サイトを過負荷にしないようクロール速度を抑え、その仕組みはサイトの応答に基づきます。例えばHTTP 500は減速を意味します。 引用箇所
• “During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome.” (翻訳) クロール中、Googleは最新のChromeを使ってページをレンダリングし、検出したJavaScriptを実行します。 引用箇所

Google — クロールバジェット、クロールとランキング（2017年の記事をSearch Engine Landが原文転載）

• “An increased crawl rate will not necessarily lead to better positions in Search results… while crawling is necessary for being in the results, it’s not a ranking signal.” (翻訳) クロール頻度を上げても検索順位が改善するとは限らず、結果表示に必要でもランキングシグナルではありません。 解説
• “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” (翻訳) 急速に変化する大量ページがなく、公開当日にクロールされるなら、このガイドは不要です。 — 大規模サイト向けガイド。 引用箇所

Fabrice Canel（Microsoft Bing）

• “Crawling is the process by which bingbot discovers new and updated documents or content to be added to Bing’s searchable index.” (翻訳) クロールとは、bingbotがBingの検索インデックスへ追加する新規・更新済み文書やコンテンツを発見する処理です。 引用箇所
• “Less is more for SEO. Never forget that. Less URLs to crawl, better for SEO.” (翻訳) SEOでは少ないほどよい。クロールするURLが少ないほどSEOに有利です。 — Search Engine Land経由。 解説

クロール可能性の切り分けチェックリスト

影響が大きく一般的なアクセス問題から、次の順で確認します。

• 登録したいURLを robots.txt（Disallow: /、*.js、*.cssを含む） が禁止していない。
• noindexとdisallowを併用していない。
• 重要内容がログイン・401の内側になく、確認済みGooglebotへ403を返さない。
• ナビゲーションはJSクリックではなく <a href> を使う。
• 重要ページに少なくとも1本の内部リンクがあり、孤立ページではない。
• サーバー応答が速く安定し、5xxが少なく、計画停止は 503 + Retry-After を使う。
• DNSが安定して解決する。
• 長いリダイレクトチェーンやループがない。
• 重要内容が約2 MBの取得上限より前にある。
• カレンダーやファセットによるスパイダートラップがない。
• URLパラメータが重複URLを生成しない。
• 「見つからない」ページは 200 ではなく 404 / 410 を返す。
• GSCクロール統計でコード急増と応答時間を確認した。
• サーバーログで浪費と未到達の重要URLを確認した。

思考モデル

1. 4分類。 問題を、アクセス遮断、リンク不備、サーバー障害、在庫肥大化に分類してから修正します。

2. パイプライン。 発見、クロール、レンダリング、登録、提供のどこで失敗したかを先に特定します。段階が違えば修正は効きません。

3. 3つの相違。

• クロールとインデックス登録は別です。
• クロールとランキングは別です。
• クロールとレンダリングは別です。

4. 登録解除の判断。 検索から消すならクロールを許可して noindex。URL空間を取得させないなら robots.txtで禁止します。

5. 生成元を直してから遮断。 不要URLの生成を止め、その後に残りを遮断します。遮断だけでは容量上限に達していない限り予算を回復しません。

6. 重大度順。 サイト全体（DNS障害、robots.txtの Disallow: /、robots.txtの5xx）→ セクション全体 → 個別ページの順で対処し、まず被害拡大を止めます。

クロール可能性問題の早見表

4分類と代表的な症状

ボットに重要なステータスコード

• 200：取得成功。ただし実質未発見ならソフト404。
• 301 / 308：恒久リダイレクト。チェーンは短くします。
• 403 / 401：アクセス拒否・認証必須。
• 404 / 410：消滅を示します。
• 429 / 500 / 503：減速・後で再試行。計画停止は Retry-After 付き 503。

要点

• 取得上限はURLあたり約2 MB、PDFは64 MB。超過分は切り詰め。
• Googleがたどるリダイレクトは約5ホップ。
• 約10万URL未満では予算問題はまれで、単位はホスト名。
• URL Parametersツールは2022年4月、速度スライダーは2024年1月に廃止。
• IndexNowはBingなど向けでGoogleは不参加。

クロール可能性問題を見つけるツール

• Google Search Consoleのページ登録レポート：robots.txt、5xx、404、リダイレクト、未登録状態を確認。
• GSCクロール統計：コード、応答時間、ホスト状態を確認。
• GSC URL検査：取得・レンダリング結果を確認。
• サーバーログ分析：実アクセス、頻度、応答、本物のGooglebot、トラップを確認。
• サイト監査クローラー：AhrefsやScreaming Frogでチェーン、遮断、孤立、深度を検出。
• Ahrefs Webmaster Tools：確認済みサイトを無料監査。
• Bing Webmaster Tools：クロール情報、制御、サイトスキャン、パラメータ無視。

確認テスト：クロール可能性の問題

クロールを妨げる原因と修正方法について5問です。回答を選び、結果を確認してください。

クローラーがページへ到達できないのはなぜか

障害対応手順：重要セクションがクロールされなくなった

1. 範囲を確認。 代表URLを試し、最初の失敗時刻をリリースや障害と比較します。
2. 取得経路を確認。 DNS、TLS、リダイレクト、コード、認証、応答完全性を調べます。
3. アクセスを確認。 robots.txtとWAF/CDNを対象URL・ボットで試します。
4. 発見を確認。 ホームとハブからクロールし、孤立やJSのみの導線を直します。
5. レンダリングと在庫を確認。 必要資源、トラップ、重複経路を調べます。
6. 回復を検証。 再取得とログを監視し、アクセス回復後も登録されなければインデックス可能性を診断します。

ブラウザーでは200だがクローラーには403

想定原因： 対象ユーザーエージェントのrobots.txt、断続的・キャッシュされた遮断、WAF/CDN規則、IP・地域遮断の順で確認します。修正： 逆引きと正引きDNSでIPを検証し、エッジログから遮断層を特定して規則を狭めます。確認： 検証済みクローラーと通常利用者の両方が意図した応答を得ること。

ページは存在するがクローラーが要求しない

想定原因： 孤立、JSのみの操作、壊れたページ分割、サイトマップ不足。修正： 関連ページから <a href> を追加し、canonical URLを適切なサイトマップへ入れます。確認： サイトクロールが到達し、後にログで検証済みクローラーを確認します。

クロールツールが遮断リソースを報告する

想定原因： robots.txtがレンダリングに必要なCSS、JavaScript、APIを遮断。修正： 非公開エンドポイントを露出せず必要資源を許可します。確認： レンダリング結果に利用者と同じ主要内容・リンクがあること。

不要URLへのクロールが急増する

想定原因： ファセット、カレンダー、内部検索、セッションID、無限ナビゲーション。修正： 生成経路を除き、登録とレンダリングへの影響を理解してから統合・遮断します。確認： 同等期間のログでパターンが減り、重要URLは発見可能なこと。

プロンプト：クロール証拠を切り分け表にする

Analyze the crawlability evidence below. For each URL, classify the failure as access, discovery/linking, server/redirect, rendering/resource, or URL-inventory. Cite only the supplied evidence, list missing checks, and return symptom → likely cause → safest fix → pass/fail verification. Keep crawlability separate from indexability.

[PASTE STATUS, HEADERS, ROBOTS TEST, CRAWL PATH, RENDERED HTML, AND LOG OBSERVATIONS]

プロンプト：robots.txtの変更を安全に確認する

Review this proposed robots.txt change against the supplied sample URLs and user agents. Build an allow/block matrix, identify the winning rule, flag required resources or valuable pages that would become blocked, and propose the smallest safe change. Do not claim the file removes URLs from the index.

[PASTE CURRENT FILE, PROPOSED FILE, USER AGENTS, AND URL SAMPLES]

URL一覧のクロール応答を確認する

while IFS= read -r url; do curl -L -sS -o /dev/null -w '%{http_code}\t%{url_effective}\t%{time_total}\n' "$url"; done < urls.txt

PowerShell版：

Get-Content .\urls.txt | ForEach-Object { try { $r = Invoke-WebRequest -Uri $_ -MaximumRedirection 10; "{0}`t{1}" -f $r.StatusCode,$r.BaseResponse.ResponseUri } catch { "ERROR`t$_" } }

レンダリング済みHTMLでクロール不能なリンク操作を探す

ブラウザーのDevTools Consoleで実行します。クリック動作があるのに通常のリンクではない要素を一覧にします。

[...document.querySelectorAll('[onclick], [role="link"]')].filter(el => !el.matches('a[href]')).map(el => ({text: el.textContent.trim(), html: el.outerHTML.slice(0, 300)}));

結果は確認待ち一覧であり、すべてをリンクに変えるべき証拠ではありません。

有用な参考資料

関連記事

• robots.txtで遮断されても登録される理由 — noindexとdisallowの罠。
• 上位2ページをrobots.txtで遮断した実験 — 実際の挙動。
• クロールバジェットを気にすべき時 — 対象サイトと浪費要因。
• JavaScript SEOの問題とベストプラクティス — JS依存のリンクと発見。
• 新しいウェブクローラー — 現在のクローラー。

講演資料

• 検索の仕組み — クロール、レンダリング、登録、ランキングの解説。

業界資料

• GoogleのCrawling December — 公式解説集。
• Googleのクロールバジェット解説 — 2017年記事の転載で、“not a ranking signal” (翻訳) ランキングシグナルではない、という説明を含みます。
• 100,000 URLでは通常バジェットへ影響しない — John Muellerの発言。
• クロール、レンダリング、登録の5つの基盤関門 — Fabrice Canelの説明。
• Googlebotのバイト上限と構造 — 2026年3月の更新。
• Googlebotのファイルサイズ上限 — 超過時の切り詰め。

変更履歴