AIで書いた記事が検索に出てこないとき、まず切り分けるべきは「順位が低い」のではなく「そもそもインデックスに入っていない」のかどうかです。結論を先に書きます。公開直後の新規URLがインデックスされていないのは正常で、Google 自身が「新しいコンテンツを追加してからインデックスされるまで数日かかることがある」、リクエスト後のクロールも「数日から数週間かかる」と明記しています(ページのインデックス作成レポート ヘルプ / Google Search Central: 再クロールをリクエストする)。
したがって異常かどうかの判断線は「公開から2週間」です。本記事ではこれを基準に、URL検査の表示だけで原因を7つに切り分ける手順を、Google の公式ドキュメントの原文表現つきで示します。AI記事が「ペナルティを受けたのでは」と疑う前に、たいていは発見経路(sitemap・内部リンク)か noindex・canonical の事故で説明がつきます。
公開から何日待つのが正常か(判断線は2週間)
Google はインデックスの速さについて2つのことを公式に書いています。1つは「即時のインデックスを期待しないこと」で、ページのインデックス作成レポートのヘルプには「新しいコンテンツを追加したとき、Google がインデックスするまでに数日かかることがある」とあります。もう1つは、URL検査からインデックス登録をリクエストした場合でも「クロールには数日から数週間かかる」で、さらに「クロールをリクエストしても、検索結果への掲載がすぐに、あるいはまったく起こらないことを保証するものではない」と明記されています。
実務では次の線で判断すると迷いません。公式が「数日」「数日〜数週間」としか言っていないため、ここから先は当社が運用上採っている基準で、Google の公式な数値ではありません。
公開からの経過 | インデックス未登録の評価 | やること |
|---|---|---|
0〜3日 | 正常。URL検査が「unknown」でも異常ではない | 待つ。発見経路(sitemap・内部リンク)だけ確認 |
4〜13日 | 様子見。ただし発見経路が無いなら今すぐ直す | sitemap 掲載と内部リンク1本以上を確認 |
14日以降 | 異常として扱う | この記事の判定手順で原因を特定する |
よくある誤解が「インデックス登録をリクエストすれば速くなるので、毎日押せばいい」です。公式ドキュメントには「個別URLの送信には割り当て(quota)があり、同じURLに対して再クロールを何度もリクエストしてもクロールが速くなることはない」とはっきり書かれています。押すのは1回で十分です。
URL検査の3つの表示を読み分ける(意味がまったく違う)
原因を特定する唯一の入口は Search Console の URL検査です。ここに出る文字列は似ていますが、指している段階が違うので打ち手も違います。公式ヘルプの原文の定義を並べます。
表示 | 公式の定義(要約) | どの段階で止まっているか | 打ち手 |
|---|---|---|---|
URL is unknown to Google(URL が Google に認識されていません) | 「Google がこの URL をまだ見たことがない」 | 発見される前。クロールも試みられていない | sitemap 掲載と内部リンクを作る。そのうえでインデックス登録をリクエスト(公式も「インデックス作成には通常数日かかる」と添えている) |
Discovered - currently not indexed(検出 - インデックス未登録) | 「Google はページを発見したが、まだクロールしていない。通常は Google が URL をクロールしようとしたが、サイトに過負荷をかけると見込まれたためクロールを再スケジュールした」 | 発見済み・クロール待ち | サーバー応答速度とクロール負荷を疑う。同時に、同種の薄いページを量産していないか見直す |
Crawled - currently not indexed(クロール済み - インデックス未登録) | 「ページは Google にクロールされたがインデックスされなかった。将来インデックスされる場合もされない場合もある。この URL を再送信する必要はない」 | クロール済み・採用されず | 内容側の問題。重複・独自性の不足を疑う。公式が「再送信は不要」と言っているので、リクエストを連打しても意味がない |
この3つを混同すると打ち手を間違えます。たとえば「Crawled - currently not indexed」なのに sitemap を作り直しても何も変わりません。クロールはすでに済んでいるからです。逆に「unknown」のまま本文を書き直しても、Google はその本文をまだ見ていません。
判定手順(上から順に7つ試す)
公開から14日を過ぎてインデックスされていない記事は、次の順番で潰します。上から順にやるのが大事で、下のほうの「内容の作り直し」から手をつけると、発見経路の不備を抱えたまま記事を書き直す徒労になります。
- URL検査を1回だけ実行し、3つの表示のどれかを確定させる。「unknown」「Discovered」「Crawled」で以降の分岐が変わります。
- 発見経路を数える。その記事へ向かう内部リンクが1本以上あるか、sitemap.xml に実際にその URL が載っているかを目で確認します。どちらも無ければ原因はここで確定です。
- sitemap の中身を確認する。URL が載っていても、lastmod が全URLで同じ日付・同じ時刻になっていると信用されません。
- noindex を探す。HTML の meta robots と HTTP ヘッダーの X-Robots-Tag の両方で「noindex」の文字列を探します。URL検査の「インデックス登録を許可」欄にも出ます。
- canonical を確認する。URL検査の「Google が選択した正規URL」が別ページになっていないかを見ます。
- robots.txt と認証を確認する。robots.txt でブロックしていないか、Googlebot に 401・403 を返していないかを確認します。
- 重複・独自性を見直す。ここまで全部クリアで「Crawled - currently not indexed」なら、原因は内容側です。
1〜6はすべて機械的に確認できる事実で、判断が入りません。AI記事が検索に出てこないという相談のうち、実際には1〜6のどこかで止まっているケースが大半です。「AIで書いたからインデックスされないのではないか」という不安は、まずAI記事にGoogleのペナルティがあるのかという論点を整理したうえで、この7段階を通してから考えるべきものです。
原因1〜2: 発見経路が無い/sitemap が信用されていない
Google はまず URL を「発見」しないとクロールできません。発見経路は実質的にsitemap と内部リンクの2つです。AIで記事を量産している現場でいちばん多い事故が、記事は増えているのにどのページからもリンクされていない記事が溜まっていくことです。一覧ページのページネーションが2ページ目以降をリンクしていない、タグページが noindex、といった構成だと、古い記事はどこからも辿れなくなります。
sitemap については、公式ドキュメントの但し書きを正確に読む必要があります。sitemap のドキュメントには「サイトマップは検索エンジンがサイトのURLを発見する助けになるが、サイトマップ内のすべての項目がクロールされインデックスされることを保証するものではない」とあります。つまり sitemap は「発見の保証」であって「インデックスの保証」ではありません。
そのうえで、sitemap の lastmod には明確な条件があります。サイトマップの作成ドキュメントには「Google は lastmod の値を、それが一貫して、かつ検証可能に(たとえばページの最終更新と比較して)正確である場合に使用する」と書かれています。ビルドのたびに全URLの lastmod を実行時刻で上書きする実装は、この「一貫して正確」に反します。全記事が毎日更新されたことになるため、値そのものが無視されやすくなります。更新していない記事の lastmod は動かさないのが正解です。
内部リンクをどう張るかは、記事を増やすほど効いてきます。AIブログで内部リンクを機械的に増やす設計をあわせて読むと、発見経路を仕組みとして確保できます。
私たちは AIブログ生成ツールというサービスも提供しており、ここで書いたような sitemap と内部リンクの設計を最初から組み込んだ形で記事を増やす運用をしています。記事の途中で恐縮ですが、同じ悩みを自力で組み直すのが大変だと感じた方には役に立つかもしれません。よろしければご覧ください。
原因3〜5: noindex・canonical・robots.txt・認証の事故
ここは設定の事故で、原因が判明すれば直すのは一瞬です。公式ヘルプが挙げている「インデックスされない理由」のうち、AI記事の運用で踏みやすいものを並べます。
- URL marked ‘noindex’(noindex タグによって除外されました): 公式の説明は「Google がページをインデックスしようとしたときに noindex ディレクティブに遭遇したため、インデックスしなかった」。ステージング環境のテンプレートをそのまま本番へ持ち込んだ、プレビュー用の全ページ noindex を外し忘れた、という形で起きます。HTML だけでなく X-Robots-Tag レスポンスヘッダー側にも入りうる点に注意してください。
- URL blocked by robots.txt(robots.txt によりブロックされました): 公式は「ただしこれはページがインデックスされないことを保証しない。Google がページを読み込まずに他の情報を得られる場合、まだインデックスされる可能性がごくわずかにある」とも書いています。つまり確実に出したくないときは robots.txt ではなく noindex を使うのが公式の指示です。逆に言えば、出したいページを robots.txt で塞いでいると、クロールされないので内容が評価されません。
- Blocked due to unauthorized request (401) / Blocked due to access forbidden (403): 公式は 403 について「HTTP 403 はユーザーエージェントが認証情報を提示したがアクセスを許可されなかったことを意味する。しかし Googlebot は認証情報を提示しないので、サーバーがこのエラーを誤って返している」と書いています。ベーシック認証や、Bot 対策のファイアウォールが Googlebot を弾いている場合がこれです。
- Duplicate without user-selected canonical / Duplicate, Google chose different canonical than user: 後者について公式は「このページは正規ページとして指定されているが、Google は別の URL のほうが正規として適切だと考えている」と説明し、対処として「ユーザー指定の正規URLが現在のページと似ていなければ、Google はその URL を正規として選ばない。重複ページは正規ページと似ている必要がある」と書いています。canonical は宣言であって命令ではないということです。
AIで書いた記事に特有の罠は、テンプレートを使って量産する過程で同じ canonical をコピーしてしまうことです。記事Aのテンプレートから記事Bを作ったときに canonical が記事Aを指したままだと、記事Bは「Duplicate」としてインデックスされません。これは本文の品質とは無関係に起きます。
原因6〜7: 重複・ほぼ同内容で「クロール済み - インデックス未登録」になる
7段階の1〜6をすべてクリアしていて、それでも「Crawled - currently not indexed」のままなら、Google はそのページを見たうえでインデックスに入れる価値がないと判断していることになります。ここが AI記事で本当に詰まる唯一の場所です。
Google のスパムポリシーには「スケーラブルなコンテンツの不正使用(scaled content abuse)」という項目があり、「検索順位を操作することを主な目的として多数のページが生成されること」と定義されています。例として挙げられているうちの1つが「生成AIツールやそれに類するツールを使って、ユーザーに価値を加えずに多数のページを生成すること」です。重要なのは、同じ定義の中に「どのように作られたかにかかわらず(no matter how it's created)」という一句が入っていることです。AIかどうかではなく、独自性と価値の有無で見られています。
実務で見分けやすい症状は次の3つです。
- 記事の7割が「◯◯とは」の一般論で、残り3割も他記事の言い換え。検索結果の上位5本を要約しただけの記事は、Google から見ると既にインデックスされている情報の重複です。
- 同一テーマの記事が3本以上あり、どれが主役か決まっていない。この場合、1本がインデックスされて残りが「Duplicate without user-selected canonical」になります。公式は「これはエラーではなく意図通りの動作」と書いています。
- 数値・手順・出典が無く、断定も否定もしていない。読者が判断に使える部分がゼロのため、AI検索・LLM からも引用されません。
直し方は本数を増やすことではなく、1本に一次情報を1つ以上入れることです。公式ドキュメントの原文表現、自社の実測値、実際に試した手順のどれかが入っていれば、他記事の重複にはなりません。AI記事の内容側を直す工程については、AI記事の誤情報を公開前に潰す手順が具体的です。なお、いったんインデックスされたあとで順位だけが落ちたケースは本記事の対象外で、AI記事の順位が落ちたときの切り分けのほうが近い症状です。
IndexNow は Google には効かない(Bing・Yandex などのみ)
インデックスされない相談でよく出てくるのが「IndexNow を入れれば速くなる」という話です。これはGoogle には当てはまりません。
IndexNow の公式サイトが公開している送信先エンドポイントは、汎用の api.indexnow.org に加えて Bing・Naver・Seznam.cz・Yandex の4つで、Google のエンドポイントは存在しません(IndexNow FAQ)。Google Search Central のドキュメントにも IndexNow を使う手順の記載はなく、Google 向けの公式な通知手段は sitemap と URL検査からのインデックス登録リクエストだけです。
つまり IndexNow の導入は Bing・Yandex 系での反映を速める施策としては有効ですが、Google でインデックスされない問題の解決策にはなりません。IndexNow 自身も「URL を送信してもすぐにインデックスされることは保証しない」と明記しています。Google 側で効くのは、この記事の7段階のうち発見経路(sitemap・内部リンク)を実際に作ることです。
インデックスされない記事を作り続けると、いくら溶けるか
ここが一番見落とされる論点です。インデックスされない記事を書き続けることの損失は、記事1本の制作コスト × 本数 × 未インデックス率で表せます。本数を増やす前に発見経路を直すべきかどうかは、この式の第3項だけで決まります。
以下の係数は算式の動きを見せるための仮の係数で、実在の単価や相場ではありません。自社の数字に置き換えて使ってください。
項目 | 仮の係数 | 月あたり |
|---|---|---|
1本あたりの制作時間(AI下書き+人の確認・修正) | 1.5時間 | — |
月の公開本数 | 20本 | 30時間 |
未インデックス率 | 40% | 12時間が検索流入ゼロのまま |
同じ条件で12か月続けた場合 | — | 144時間 |
この式から出てくる判断線は1つです。
- 未インデックス率が公開2週間後の時点で20%を超えていたら、本数を増やす段階ではなく発見経路を直す段階です。原因1〜5はすべて1回の修正で全記事に効く構造の問題で、記事を1本書く時間より短く終わります。
- 未インデックス率が20%以下で、内訳が「Crawled - currently not indexed」に偏っているなら、原因は内容側です。このときだけ記事の作り方を変える意味があります。
- この20%という線も当社の運用上の基準で、Google が公表している数値ではありません。自社で2〜3か月測れば、サイトごとの平常値が出ます。
測り方は難しくありません。Search Console のページのインデックス作成レポートで、公開から2週間以上経った記事のうち未登録のものを数え、同期間の公開本数で割るだけです。月1回これを測っていれば、インデックスの事故は最長1か月で見つかります。測っていないサイトでは、半年分の記事がまとめて消えていたことに後から気づきます。
「AIで書いたから」インデックスされないのか(Googleの立場)
結論として、Google は「AIで書いたこと自体」を理由にインデックスを拒否するとは書いていません。AI生成コンテンツに関する公式ガイダンスには「AI や自動化の適切な使用は、当社のガイドラインに違反しません」「これは、検索順位を操作することを主な目的としてコンテンツを生成するために使われていないことを意味します」と書かれています。
同じガイダンスには「コンテンツがどのように作られたかではなく、コンテンツの品質に焦点を当てる」という表現もあります。約10年前に人手で量産されたコンテンツが増えたときも「人が書いたコンテンツを全面禁止する」のではなく品質で評価する仕組みを改善した、という例まで添えられています。
したがって、AI記事がインデックスされないときに疑う順番は「AIだから」が最後です。発見経路・設定の事故・重複の3つで説明がつかなかった場合に初めて、独自性の不足という本題に入ります。
一次ソースで確認できなかったこと
正直に書きます。次の2点は Google の公式ドキュメントでは確認できませんでした。
- 「公開から14日」「未インデックス率20%」という判断線: Google は「数日」「数日から数週間」としか書いていません。本記事の14日・20%は当社の運用基準です。
- Google が IndexNow を採用しないと明言した公式文書: Google Search Central のドキュメントに IndexNow の記載が無いこと、IndexNow 公式のエンドポイント一覧に Google が含まれないことは確認しましたが、「Google は IndexNow を使わない」と書いた Google 公式のページは見つけられませんでした。「公式に案内されていない」までが確認できた事実です。
インデックスの事故は、記事の品質の話に見えて実際は構成と配信の話です。自社サイトでどこで止まっているのか判断がつかない場合は、URL検査の表示(unknown / Discovered / Crawled のどれか)と公開日だけお知らせいただければ、原因の当たりをつけてお返しできます。よろしければお気軽にご相談ください。
よくある質問
AI記事を公開してから何日インデックスされなければ異常ですか?
Google は「新しいコンテンツを追加してからインデックスされるまで数日かかることがある」、インデックス登録をリクエストした場合のクロールも「数日から数週間かかる」としか明言していません。本記事では運用上の基準として公開から14日を異常の線に置いています。0〜3日で URL検査が「URL が Google に認識されていません」になるのは正常です。
URL検査の「検出 - インデックス未登録」と「クロール済み - インデックス未登録」は何が違いますか?
止まっている段階が違います。「検出 - インデックス未登録」は Google がページを発見したがまだクロールしていない状態で、公式には「サイトに過負荷をかけると見込まれたためクロールを再スケジュールした」と説明されています。「クロール済み - インデックス未登録」はクロールされたうえでインデックスに入らなかった状態で、公式は「この URL を再送信する必要はない」としています。前者はサーバー負荷と発見経路、後者は内容側の問題です。
インデックス登録のリクエストは毎日押したほうが速くなりますか?
なりません。Google の公式ドキュメントに、個別URLの送信には割り当てがあり、同じ URL に対して再クロールを何度もリクエストしてもクロールが速くなることはないと明記されています。押すのは1回で十分で、その後は sitemap 掲載と内部リンクを作るほうが効きます。
IndexNow を導入すれば Google のインデックスが速くなりますか?
なりません。IndexNow 公式サイトが案内している送信先は Bing・Naver・Seznam.cz・Yandex で、Google のエンドポイントは存在しません。Google Search Central にも IndexNow の手順はありません。Google 向けに効くのは sitemap と URL検査からのインデックス登録リクエストです。
AIで書いたこと自体がインデックスされない理由になりますか?
Google の公式ガイダンスは「AI や自動化の適切な使用は、当社のガイドラインに違反しません」「コンテンツがどのように作られたかではなく、コンテンツの品質に焦点を当てる」と述べています。ただしスパムポリシーの「スケーラブルなコンテンツの不正使用」には、生成AIを使ってユーザーに価値を加えずに多数のページを生成することが例として挙げられています。AIかどうかではなく、独自性と価値の有無で判断されます。