WEBサイト
自社ブログの外部リンクをチェックツールで洗ったら、リンク切れは0本だった。当サイトが公開しているリンク漏れ・チェックツール「🔧 リンク漏れ・チェックツール」でも同じ結果が出た。良い数字だと思って、そのまま終えかけた。
だが「ブログからseo_articleへのリンクが、どんな状態のページに着地しているか」を、別の角度から数え直した。404は0本のままだった。代わりに出てきたのは、リンク切れよりずっと大きな数字だった。ブログ133本が本文中で言及している自社のseo_article記事、そのリンク先の59.2%が、Googleが「AIの回答の引用元になれない」と明記している状態のページだったのだ。
この記事は、その具体的な数字と、なぜ普通のリンクチェックではこれが見つからないのかを書く。
「リンク切れゼロ」を確認して、安心しかけた
WEBディレクターなら誰でもやる基本の点検がある。サイト内のリンクを洗い出し、404（存在しないページ）や403（アクセス拒否）が返ってこないかを確認する作業だ。これを怠ると、読者は「ページが見つかりません」の壁にぶつかり、そのまま離脱する。だから多くのサイトが、月次や週次でこのチェックを回している。
当サイトも例外ではない。自社ブログ「AI Ronブログ」の全記事から、本文中に張られた外部・内部リンクを機械的に洗い出し、HTTPステータスを確認した。結果はゼロ件。存在しないページを指すリンクは1本もなかった。
ここで安心してしまうのが、いちばん危ない瞬間だ。「200が返る」ことと「そのページが役に立つ状態にある」ことは、まったく別の話だからだ。リンク切れの確認は、あくまで「読者がクリックしたときに、そのページへたどり着けるか」を測る点検であって、「たどり着いた先が、検索やAIの回答から見つかる状態にあるか」までは測っていない。同じ「点検した」という言葉が、実際には2つの違う範囲を指してしまう。
自社ブログ133本、リンク201本を数え直す
そこで確認の軸を変えた。「リンクが生きているか」ではなく「リンクの飛び先が、検索やAIの回答から見つかる状態にあるか」を数えた。
対象をどう決めたか
対象は、公開中のブログ記事133本の本文から、自社のseo_article記事への言及を抽出した201本のリンク。ユニークな記事数では59記事にあたる。この抽出は機械的な処理で行い、その仕組みが正しく動いているかを先に確かめた。同じ仕組みで、ブログ記事どうしの内部リンク（記事間リンク）1,400本を数えたところ、存在しない記事を指すものは0本だった。数える仕組みそのものは壊れていない、という前提が取れたうえでの数字だ。
この確認方法にも限界はある。本文中の文章に埋め込まれたリンクだけを対象にしており、サイドバーやフッターなど、テンプレート側で自動的に表示されるリンクは含まれていない。「本文の中で読者に紹介した先」に絞って数えている、という前提を先に断っておく。
そのうえで、201本のリンクそれぞれについて、飛び先のseo_article記事が「検索エンジンに見せてよい状態（インデックス可能）」か「検索エンジンから隠す設定（noindex）」かを、データベースの公開フラグで判定した。
数字が意味していること
結果を表にする。
| 飛び先の状態 | 本数 | 割合 |
|---|---|---|
| インデックス可能な記事を指す | 82本 | 40.8% |
| noindexの記事を指す | 119本 | 59.2% |
| 存在しない記事を指す（リンク切れ） | 0本 | 0.0% |
| 合計 | 201本 | 100% |
リンクの「張り方」自体は正しかった。存在しないページに読者を送っている箇所は1本もない。壊れていたのは、飛び先の「検索から見つかる状態」のほうだった。さらに、1本以上noindexへのリンクを持つ記事だけを数えると、133本中33本（24.8%）にのぼる。4本に1本の記事が、検索エンジンやAIから見えない場所へ読者を送っていたことになる。
この33本という数字にも幅がある。1本だけnoindexへのリンクを持つ記事もあれば、複数本まとめて持つ記事もある。どちらから手を付けるかは、単純にリンクの本数だけでなく、その記事自体がどれだけ読まれているかも合わせて見る必要がある。数を数えることと、優先順位を決めることは、別の作業だ。
404は測れる。noindexは200を返す
なぜ、いつものリンクチェックでこの問題が見つからなかったのか。答えは単純で、noindexが設定されたページは、HTTPステータスとしては正常な200を返すからだ。
普通のリンクチェックでは見つからない理由
リンクチェックツールがやっていることは、基本的に「そのURLにアクセスして、返ってきたステータスコードを記録する」だけだ。ページが実在し、サーバーが正しくコンテンツを返している限り、200というのは「正常」を意味する。
ところがnoindexは、HTMLの<head>内にあるメタタグ、あるいはHTTPレスポンスヘッダーで指定される。ページの中身は普通に存在し、ブラウザで開けば普通に読める。違うのは「検索エンジンにこのページをインデックスさせない」という一文が、目に見えない場所に書かれていることだけだ。
HTTPステータスコードの限界
つまり、HTTPステータスコードという「そのページに人がたどり着けるか」を測る道具では、「そのページが検索やAIの回答に出てくるか」という、もう一段別の状態を測ることができない。ステータスコードは配信の可否を教えてくれるが、掲載の可否は教えてくれない。
この違いに気づかないまま「リンク切れ0件だから内部リンクは健全」と報告してしまうと、実際には読者もAIも辿り着けないページへ、サイトの評価やクリックを送り続けることになる。読者側から見ると、リンクをクリックすればページ自体は普通に開ける。困るのはその手前だ。検索やAIの回答に、そのページ自体が最初から出てこないので、リンクをたどるという行為すら発生しない読者が、静かに増えていく。
AI Overviewの参照リンクになる条件
ここからは、Googleが公式ドキュメントで何を明記しているかを確認する。まず、AI OverviewやAI Modeの参照リンクとして表示されるための条件だ。
インデックスされ、スニペット表示できること
"To be eligible to be shown as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to be shown in Google Search with a snippet, fulfilling the Search technical requirements."
（日本語訳: AI Overviewや AI Modeの参照リンクとして表示される資格を得るには、そのページがインデックスされ、スニペット付きでGoogle検索に表示できる状態であり、検索の技術要件を満たしている必要がある）
条件はシンプルだ。「インデックスされていること」と「スニペット付きで検索結果に表示できる状態であること」の2つ。スニペットとは、検索結果の見出しの下に出る、記事の要約にあたる短い説明文のことだ。この要約が表示できる状態になっていて初めて、AIの回答の参照リンクとして選ばれる土俵に立てる。noindexが設定されているページは、この条件を最初の一歩でクリアできない。当サイトのブログが33本の記事でリンクしていた119本のnoindexページは、この時点でAI Overviewの参照リンクになる資格を持っていなかった、ということになる。
専用のAIスキーマもllms.txtの要件も無い
もう一つ、同じページに明記されている一文がある。
"There are no additional technical requirements. There is no special AI schema, llms.txt requirement or separate 'AI ranking' shortcut."
（日本語訳: 追加の技術要件は無い。専用のAIスキーマも、llms.txtの要件も、別個の「AIランキング」の近道も存在しない）
つまり、AIの回答に出るための特別な設定を足す前に、通常の検索でインデックスされる状態を整えることが先になる。当サイトも過去の記事でllms.txtの効果を測り続けてきたが、その前提として「そもそもインデックスされているか」を先に確認する必要がある、とこの一文は言っている。特別な設定は、基礎が整った上に足すものであって、基礎の代わりにはならない。
各社のAIクローラーは、noindexをどう扱っているか
次に、AI各社が自社のクローラーについて、noindexメタタグをどう扱うと公式に説明しているかを確認する。会社ごとに書き方が違い、そもそも言及が無いところもある。ここで確認するのは「クロールを許可するか」ではなく、あくまで「noindexというメタタグを読んだ後、どう扱うか」という一段細かい話であることに注意してほしい。robots.txtでクロール自体を止めているなら、そもそも下記の話は始まらない。
OpenAI（GPTBot）の場合
OpenAIの公開FAQには、noindexメタタグについての明記がある。
"If you do not want this to happen, use the noindex meta tag."
（日本語訳: これを望まない場合は noindex メタタグを使ってください）
ただし、続けてこう補足されている。
"in order for our crawler to read a meta tag, it must be allowed to crawl the relevant page(s)."
（日本語訳: ただし当社のクローラーがメタタグを読むためには、該当ページのクロールが許可されている必要がある）
ここが見落としやすい。robots.txtでそのディレクトリ自体をブロックしていると、クローラーはページの中身に一度も到達できず、noindexの指定を読むところまでたどり着けない。noindexは「来たときに従うルール」であって、「来させないルール」ではない。この2つを混同して、ブロックとnoindexを両方設定してしまうと、後者は意味を持たなくなる。
Anthropic（ClaudeBot）の場合
Anthropicの公式サポートページでは、ブロック方法についての記述が中心だ。
"To block a Bot from your entire website, add this to the robots.txt file in your top-level directory."
（日本語訳: サイト全体からボットをブロックするには、最上位ディレクトリの robots.txt に次を追加してください）
このページ（更新日 2026年4月7日）を確認した限り、noindexメタタグへの言及は見当たらなかった。「無い」と断定するより、「このドキュメントの中には無かった」という言い方が正確だ。IPアドレスによるブロックは非推奨と明記されている点は、当サイトのクローラー対策を見直すときにも参考になる。
Perplexityの場合
Perplexityの公式ドキュメントには、通常のクロールを行う「PerplexityBot」と、ユーザーが操作した瞬間にその場でページを取得する「Perplexity-User」という、性質の違う2種類のフェッチャーが説明されている。前者はrobots.txtに従うと明記されているが、後者はユーザーからの直接のリクエストに応じて動くため、robots.txtのルールを一般的には無視するという趣旨の記述がある。noindexメタタグそのものへの明記は確認できなかった。
この違いは実務上、意外と重要だ。「robots.txtでブロックしているから安心」と考えていても、ユーザーが個別にそのページのURLを貼って質問すれば、Perplexity-Userはその場で取得しに来る可能性がある。定期的な巡回クロールと、ユーザー操作に連動した即時フェッチは、同じ会社のサービスでも別のルールで動いていることがある。
Google-Extendedは別の軸
混同しやすいのが「Google-Extended」だ。これは独立したクローラーではなく、robots.txtに書くトークンの一つで、実際にクロールしているのはGooglebotのままだ。Google-Extendedが制御しているのは「クロール済みのコンテンツを、生成AIの学習などに使わせるかどうか」という下流の利用許諾であって、検索結果やAI Overviewに表示されるかどうかとは別の軸にある。この点についてはGoogleの公式ドキュメントの該当箇所を特定できておらず、この記事では断定を避ける。
| クローラー / フェッチャー | noindexメタタグへの言及 | 出典・更新日 |
|---|---|---|
| GPTBot（OpenAI） | 明記あり（ただしクロール許可が前提） | help.openai.com |
| ClaudeBot（Anthropic） | このページでは確認できず | support.claude.com（2026-04-07更新） |
| PerplexityBot | このページでは確認できず | docs.perplexity.ai |
| Perplexity-User | robots.txtを一般的に無視する旨の記述あり | docs.perplexity.ai |
| Google-Extended | 学習利用の可否を制御するトークン（表示可否とは別軸） | 公式記述を特定できず |
この表を見て分かるのは、「noindexを設定すればAIクローラーへの露出を完全に制御できる」と一律に言い切れないということだ。会社ごとに書いていることが違い、書いていない会社もある。読み方を一つに決めつけず、まず自社のrobots.txtがクロールそのものを止めていないかを確認するほうが、実務としては効く。
もう一つ実務的な注意点がある。ここで確認した内容は、あくまで各社が公開ドキュメントで明記している範囲であり、実際のクローラーの挙動を当サイトが個別に検証したものではない。「言及が無い」ことは「対応していない」ことの証明ではなく、単にそのドキュメントに書かれていなかった、という意味にとどまる。ドキュメントは更新されるので、定期的に読み直す前提で扱ってほしい。
noindexが「効かない」3つの組み合わせ
Googleの公式ドキュメントには、noindexが意図通りに機能しない条件も明記されている。
robots.txtでブロックされている場合
"If the page is blocked by a robots.txt file or the crawler can't access the page, the crawler will never see the noindex rule"
（日本語訳: robots.txt でブロックされているか、クローラーがページにアクセスできない場合、クローラーは noindex ルールを見ることが決してできません）
これは前段のOpenAIの補足と同じ構造だ。noindexを設定するなら、そのページ自体へのクロールは許可しておかないと、指定そのものが読まれない。「隠したいからrobots.txtでもブロックして、noindexも設定した」という二重の対策が、実は矛盾していることがある。
重複コンテンツの整理にnoindexを使う場合
もう一つ、意外と見落とされるのがこちらだ。
"We don't recommend using noindex to prevent selection of a Canonical page within a single site, because it will completely block the page from Search"
（日本語訳: 単一サイト内で正規ページの選定を防ぐために noindex を使うことは推奨しません。そのページが検索から完全にブロックされてしまうためです）
似たページが複数あるとき、片方をnoindexにして片方を残すという整理をしがちだが、Google自身は「正規化（canonicalの指定）」と「検索から完全に排除すること」を別の目的として扱っている。正規化とは、内容が重複する複数のURLのうち「これを代表として扱ってほしい」とGoogleに伝える仕組みで、ページ自体は検索結果に出続ける余地を残す。一方noindexは、そのページを検索結果から完全に外す指定であり、読者に見せる価値がまだあるページを、重複整理のつもりでnoindexにしてしまうと、想定より強く消してしまうことになる。
当サイトの場合、archives/105で書いた通り、1,286本の記事を意図的にnoindexへ切り替えた際の内部リンクが今回の確認のきっかけであり、切り替えそのものは正規化ではなく「書き直すまで検索から外す」という明確な判断のもとで行っている。だからこそ、切り替えた後に残った内部リンクの後始末が、今回のように必要になる。「出す側」の判断は済んでいても、「指す側」のリンクは自動では追随しない、というのが今回はっきりした構造だ。
自分のサイトで測る12の手順
ここまでの内容を、明日から実行できる手順に落とす。1つあたり5分以内で終わる粒度にした。まとめて全部やろうとすると止まるので、1日1〜2個ずつでもいい。
- サイト内の内部リンクをすべて洗い出し、飛び先のURLを重複を除いて数える。ここでの母数がはっきりしないと、後の項目の「何%か」が出せない
- 自社ブログの本文中にある内部リンクを、飛び先のURLごとにカウントする。サイドバーやフッターの自動リンクとは分けて数える。読者が記事の流れの中でクリックする先が対象
- 上位10ページを開き、meta robotsタグに noindex が入っていないか確認する。ブラウザで「ページのソースを表示」し、
<head>内をnoindexで検索すれば足りる - robots.txtを開き、その飛び先のディレクトリ自体をブロックしていないか確認する。ブロックされていると、noindexの指定自体がクローラーに読まれない
- 🔧 Search Console解説ツールを使い、「ページ」レポートを開いて分類を確認する
- Search Consoleの「ページ」レポートで、リンクしている記事が「クロール済み-インデックス未登録」に含まれていないか確認する。公式ヘルプによれば、このステータスは「将来インデックスされるかどうかは分からない」という宙ぶらりんの状態だ
- URL Inspection APIまたはSearch Console画面で、リンク先URLを3ページ実際に検査する。無料で確実に確認できる、唯一の公式手段
- サイトマップを開き、リンク先のURLが含まれているか確認する。含まれていない場合、検索エンジンに「見なくていい」と伝えていることになる
- canonicalタグが、リンク先とは別のURLを指していないか確認する。指している場合、そのページ自体は検索結果に出ない設計になっている可能性がある
- noindexページへリンクしている自社記事を、上位5本リストアップする。アクセス数の多い記事から優先する
- そのリストの中から、代わりに送れる公開済みページへリンクを張り替える。代わりが無ければ、リンクを一旦外すという選択肢もある
- 張り替え後、リンク先のHTTPステータスが200であることと、meta robotsにnoindexが無いことの両方を再確認する
この12項目は、当サイトが自社の点検で実際に使った手順そのままだ。読者に「やってみてください」と勧める前に、当サイト自身がこの手順を今回の記事の準備として実行している。順番も、実際に行った通りに並べてある。
一括で測る公式な方法は、無い
ここまでの手順を読んで「1回のリクエストで全ページのインデックス状態が分かる方法は無いのか」と思った人もいるだろう。結論から言うと、公式にはそういう手段は用意されていない。
URL Inspection APIの上限
Googleが提供する唯一の公式手段は、URL Inspection APIによる個別URLの検査だ。1つのプロパティに対して、1日あたり2,000クエリ、1分あたり600クエリという上限がある。しかもこの上限は「同一プロパティを検査する全アカウントの合算」で、ローリング24時間の窓で計測される。複数人でSearch Consoleを使っているサイトでは、自分が使っていなくても他の担当者の利用分で上限に近づくことがある。数百・数千ページを持つサイトを一括で検査するには、この上限が現実的な壁になる。
Bulk Data Export（BigQuery）は対象外
Search Consoleには、検索パフォーマンスデータをBigQueryへ自動エクスポートするBulk Data Exportという機能がある。クエリや掲載順位のデータは大量に取得できるが、これは「検索結果に表示された実績」のデータであって、「インデックスされているかどうか」というステータス自体は対象に含まれていない。「表示回数0件」を「インデックスされていない」と読み替えるのも早計だ。インデックスはされていても、そのクエリで一度も表示されていないだけ、という状態もありうる。
Screaming Frog無料版の上限
サードパーティのクロールツールでも代替できる部分はある。Screaming Frogの無料版はmeta robotsタグやcanonicalタグの確認機能を持っているが、1回のクロールにつき500URLまでという上限がある。それを超えるサイトでは有料版が必要になる。当サイトのブログとseo_article記事を合わせた規模であれば、この無料版の上限に収まる範囲で確認できる。
| 手段 | 上限 | できること |
|---|---|---|
| URL Inspection API | 1日2,000件・1分600件（プロパティ単位で合算） | 個別URLのインデックス状態を取得 |
| Search Console 画面 | 手作業 | 「ページ」レポートで状態を分類して確認 |
| Bulk Data Export（BigQuery） | 検索パフォーマンスデータのみ | クエリ・掲載順位の大量取得（インデックス状態は対象外） |
| Screaming Frog 無料版 | 1クロール500URLまで | meta robots / canonical の確認 |
つまり、100ページ程度の中小規模サイトならURL Inspection APIかScreaming Frog無料版で足りるが、それ以上の規模になると、どの手段を選んでも「一部だけを抜き出して確認する」という前提を受け入れる必要がある。今回の確認も、全記事の本文リンクをまず機械的に洗い出し、「noindexへのリンクを持つ記事」という優先度の高い33本に絞り込んでから、個別に状態を確認するという2段構えで行っている。全数を一括で検査する公式な近道が無い以上、「どこを優先して確認するか」を決める最初の絞り込みのほうが、実務では重要になる。
当サイトの現在地
ここまで読者に勧めた内容について、当サイト自身の現在地を正直に書く。ここでも守るのは、自社がやっているかどうかで推奨内容を選ばないという方針だ。読者にとって本当にやるべきことだけを先に書き、当サイトが未着手なら未着手だとそのまま書く。
✅ 当サイト実施済 自社ブログ133本の全リンクを機械的に洗い出し、飛び先の公開状態（インデックス可能かnoindexか）を確認した。これは今回の記事そのものの土台になっている。
✅ 当サイト実施済 「クロール済み」と「検出」、インデックス未登録の違いで扱ったSearch Consoleのレポート分類は、今回のチェックリストの手順6・7でそのまま使っている。
✅ 当サイト実施済 seo_article記事から自社ブログへの「帰り道」となる内部リンクは、公開中の記事すべてに設置済みで、飛び先が公開状態のページであることを個別に確認している。
🔧 当サイト着手中 今回見つかった、ブログからnoindexページへ向いている33本のリンクの張り替えは、これから着手する。優先順位は、noindexへのリンクを複数持つ記事から始める予定だ。飛び先が見つからない場合は、テーマの近い公開済みの記事に張り替えるか、代わりが無ければリンクを一旦外す。
🔧 当サイト着手中 AI Overviewの参照リンクになる条件を確認したうえで、当サイトの公開記事がインデックス除外の状態に無いかの定期点検を、今回の12手順に沿って組み込んでいく。
📋 当サイト予告 今回張り替えた記事の本数と、張り替え後のクリック状況の変化は、次の記事で改めて報告する。「やった」で終わらせず、その後どうなったかまでを合わせて公開する。
「リンク切れ0本」を確認したときの安心は、間違った安心ではなかった。ただし、それが答えていたのは「読者がクリックしたときに404にならないか」という一つの問いだけだった。「その先のページが検索やAIの回答から見つかる状態にあるか」は、まったく別の問いで、まったく別の測り方が要る。同じ「200」という返事の中に、性質の違う状態が混ざっていることを、今回の確認ではっきりさせた。
点検の道具を1つ増やしたのではなく、これまでの点検が「何を測っていて、何を測っていなかったか」の輪郭がはっきりした、というのが今回の実質だ。リンクチェックツールを疑う必要は無い。ツールは正しく仕事をしている。「そのツールがどこまでを見ているか」を、使う側が正確に把握しているかどうかが分かれ目だった。
関連 archives（連載軸として読む）
- archives/105「1,000件の宿題を6日間で畳んだ ── noindex一括解除、『あとで完全にする』の答え合わせ」 ── 1,286本を意図的にnoindexへ切り替えた、今回の確認の起点にあたる作業（2026-06-27）
- archives/128「出力は在った。だから誰も測らなかった ── datePublished・og:type・用語ハイライト・sitemapで見つけた4つの『値だけ違う』穴」 ── 「200が返る」ことと「正しく機能している」ことの違いを扱った回
- archives/131「『使われていないコード』は証明できない ── 指定した場所は死んでいて、指定しなかった場所が生きていた」 ── 指定した場所と、実際に機能している場所がずれていた、という構造が今回とよく似ている
- archives/116「1サイトの実測は仮説、2サイトの一致は事実 ── llms.txtを8言語サイトでも測ったら、AIクローラーが1件も来ていなかった」 ── AIクローラーの実際の挙動を複数サイトで確認した回
一次情報出典
- Google Search Central: AI features and your website
- Google Search Central: Block Search indexing with noindex
- Google Search Central: Consolidate duplicate URLs
- Google Search Console API: Usage limits
- Search Console ヘルプ: ページレポート（インデックス登録状況）
- OpenAI Help Center: Publishers and developers FAQ
- Anthropic Help Center: Does Anthropic crawl data from the web, and how can site owners block the crawler?
- Perplexity Documentation: Crawlers
- Screaming Frog SEO Spider: Pricing（無料版・有料版の機能比較）
