サーバーログを見たら、AIクローラーが404を踏み続けていた
サーバーログを見て、驚いた。
クローラーが404を踏み続けていた。しかも1回や2回ではない。同じURLを何度も繰り返し叩いて、そのたびに404を返されている。
404といえば「ページが見つからない」というエラーです。人間が見れば「あ、このページなくなったんだな」とわかります。ブラウザの戻るボタンを押して別のページに移動します。
クローラーは違います。404を返されても、同じURLをまた叩きに来ます。サイトマップに古いURLが残っていれば、そのURLが消えるまで延々とアクセスし続けます。
問題はそれだけではありません。クローラーが1回のクロールでアクセスできるページ数には上限があります。404を踏むたびにその上限を1回消費しています。存在しないページに予算を使い続けた結果、本当に読んでほしい記事にたどり着けないまま帰ってしまいます。
AI観測ラボのサーバーログを解析したところ、複数のクローラーが異なるパターンで404を踏んでいることが確認できました。原因はWordPressでよくある3つのパターンに集約されます。原因と対策をログの実例とともに解説します。
この記事でわかること｜📖：約5分
- サーバーログで実際に確認できたクローラーの404パターン3つ
- 404がクローラーにとって致命的な理由
- WordPressで起きやすい原因と具体的な修正方法
- Search Consoleを使った404の検知から修正までのフロー
- 今すぐ使える404チェックリスト
実際のログで見つけた404の実例3パターン
2026年3月7日、AI観測ラボのサーバーログを解析しました。1日分のログだけで、複数のクローラーが404を踏んでいる場面が確認できました。
パターン1：旧URLの残骸をApplebotが踏み続ける
Applebotとは、AppleのSiriやSpotlight検索向けにデータを収集するクローラーです。iPhoneやMacで検索したときの回答に使われる可能性があります。
このApplebotが/dcta-flow/というURLに404を返されていました。
このURLはDCTAシリーズの記事を公開する前に使っていた仮のURLです。正式公開時にスラッグを変更したため、旧URLにアクセスしても何も存在しない状態になっていました。Applebotはどこかで旧URLを記憶していて、いまも叩きに来ています。
スラッグを変更したときの対処法は後述します。
パターン2：sitemap.xmlとsitemap_index.xmlの混在でAhrefsBotが迷う
AhrefsBotはSEOツール「Ahrefs」のクローラーです。サイトのリンク構造や被リンクを収集するために動いています。Ahrefsのデータは多くのSEOツールの基礎データになっているため、正しくクロールされることに越したことはありません。
このAhrefsBotが/sitemap.xmlに対して1日で3回404を返されていました。
WordPressはデフォルトで/sitemap_index.xmlを生成します。/sitemap.xmlというURLは存在しません。AhrefsBotはどこかで/sitemap.xmlというURLを記憶していて、存在しないファイルを繰り返し叩き続けています。
sitemapのURL統一については後述します。
パターン3：スラッグ変更後のfeed残骸をMJ12botが叩く
MJ12botはSEOツール「Majestic」のクローラーです。サイトの被リンクデータを収集しています。
MJ12botが以下のURLに404を返されていました。
/aiクローラーとは？chatgpt・claudeに見つけてもらう8つの方/feed/以前公開した記事のタイトルをそのままスラッグに使っていた時期のURLです。その後スラッグを英語の短いものに変更したため、旧URLにアクセスしても存在しない状態になっています。さらに末尾に/feed/がついているのは、RSSフィードのURLとして外部に記録されていたためです。
スラッグを変更するとこのような残骸が複数発生します。リダイレクト設定をしていない場合、クローラーは旧URLを叩き続けます。
| クローラー | 404を踏んだURL | 原因 |
|---|---|---|
| Applebot | /dcta-flow/ |
スラッグ変更後の旧URL残骸 |
| AhrefsBot | /sitemap.xml |
sitemapのURL混在 |
| MJ12bot | 旧スラッグ+/feed/ |
スラッグ変更後のfeed残骸 |
404がクローラーにとって致命的な理由
「削除したページだから404でも仕方ない」と思っていませんか。人間にとっては404は単なるエラー表示ですが、クローラーにとっては話が違います。
クローラーには「1回の巡回で回れるページ数」に上限がある
クローラーがサイトを巡回するとき、1回の訪問で無制限にページを読んでいくわけではありません。サーバーへの負荷を考慮して、1回の巡回で消費できるリクエスト数に上限が設けられています。これをクロールバジェットといいます。
404を踏むたびに、このクロールバジェットを1回消費します。存在しないページへのアクセスに予算を使い続けた結果、本当に読んでほしい新しい記事にたどり着けないまま巡回を終えてしまいます。
クロールバジェットの考え方についてはAIクローラーとは？引用されるサイト設計の基本と8つの対策でも解説しています。
クローラーは404を返されても同じURLを叩き続ける
人間なら404を見たら別のページに移動します。クローラーは違います。サイトマップや外部サイトに古いURLが残っている限り、404を返されても同じURLを繰り返し叩き続けます。
今回のログでAhrefsBotが/sitemap.xmlに1日3回404を返されていたのはその典型です。サイトマップのURLが統一されていない限り、明日も明後日も同じことが繰り返されます。
AIクローラーは404を踏んだサイトをどう評価するか
AIクローラーがサイトを評価する基準は公開されていません。ただ、404が多いサイトは「メンテナンスが行き届いていないサイト」と判断される可能性があります。
引用されるサイトの条件として信頼性が重要になる点はAIはなぜあなたのサイトを信頼できると判断するのか｜DCTAフロー Trustフェーズで詳しく解説しています。404の放置はその信頼性を下げるリスクがあります。
- クロールバジェットを無駄に消費して重要ページが後回しになる
- 同じ404URLを繰り返し叩かれてサーバー負荷が増える
- メンテナンス不足のサイトと判断されて信頼性が下がる可能性がある
WordPress別・原因と対策
今回のログで確認できた404は、WordPressでよく起きる3つの原因に集約されます。それぞれの原因と対処法を解説します。
原因1：スラッグを変更したときにリダイレクトを設定していない
記事公開後にスラッグを変更すると、旧URLにアクセスしても何も存在しない状態になります。クローラーは旧URLを記憶しているため、変更後も旧URLを叩き続けます。
対処法は旧URLから新URLへの301リダイレクトを設定することです。301リダイレクトとは「このURLは別のURLに恒久的に移動しました」とクローラーに伝える設定です。
WordPressで301リダイレクトを設定する方法は2つあります。
方法1：プラグインを使う（初心者向け）
「Redirection」というプラグインをインストールすると、管理画面から旧URLと新URLを入力するだけでリダイレクトが設定できます。コードの知識は不要です。
方法2：.htaccessに直接書く（上級者向け）
Redirect 301 /旧スラッグ/ https://example.com/新スラッグ/ConoHaなどのサーバーでは管理画面から.htaccessを編集できます。編集前に必ずバックアップを取ってください。
原因2：sitemapのURLが統一されていない
WordPressはYoast SEOなどのプラグインを使うと/sitemap_index.xmlを自動生成します。一方、外部ツールや古い設定が/sitemap.xmlというURLを参照している場合、クローラーは存在しないURLを叩き続けます。
対処法は使用するsitemapのURLを1つに統一して、robots.txtに明記することです。
Sitemap: https://example.com/sitemap_index.xmlrobots.txtにsitemapのURLを明記する方法はrobots.txtの正しい書き方【AI時代版】で詳しく解説しています。
原因3：sitemapに削除・移動済みのURLが残っている
記事を削除したりスラッグを変更したりしたあと、sitemapの更新が追いついていないケースがあります。sitemapに古いURLが残っていると、クローラーはそのURLを正しいページとして認識して繰り返しアクセスし続けます。
対処法はsitemapを定期的に確認して、存在しないURLを削除することです。Yoast SEOを使っている場合は記事を削除すると自動でsitemapから除外されますが、スラッグ変更の場合は手動確認が必要なケースがあります。
| 原因 | 対処法 |
|---|---|
| スラッグ変更後にリダイレクト未設定 | Redirectionプラグインまたは.htaccessで301設定 |
| sitemapのURLが統一されていない | robots.txtにsitemapのURLを明記して統一 |
| sitemapに古いURLが残っている | 月1回sitemapを確認して不要なURLを削除 |
Search Consoleで404を検知して修正するフロー
サーバーログを毎日確認するのは現実的ではありません。Google Search Consoleを使えば、404が発生しているURLを一覧で確認できます。無料で使えて、WordPressサイトなら必ず導入しておきたいツールです。
ステップ1：カバレッジレポートを開く
Search Consoleにログインして、左メニューの「ページ」をクリックします。「インデックス登録されていない理由」の一覧に「見つかりませんでした（404）」という項目が表示されていれば、404が発生しているページが存在します。
ステップ2：404URLの一覧を確認する
「見つかりませんでした（404）」をクリックすると、404を返しているURLの一覧が表示されます。URLを見て以下の3つに分類します。
- スラッグ変更済みの旧URL→ 301リダイレクトを設定する
- 削除した記事のURL→ sitemapから削除する
- 存在したことのないURL→ 外部からの不正アクセスの可能性があるため放置でよい
ステップ3：原因に応じて修正する
スラッグ変更済みの旧URLはRedirectionプラグインで301リダイレクトを設定します。削除した記事のURLはYoast SEOのsitemap設定から除外されているか確認します。
ステップ4：修正後にSearch Consoleで検証する
修正が完了したら、該当URLをSearch Consoleの「URL検査」で入力して「インデックス登録をリクエスト」をクリックします。クローラーが再度アクセスして404が解消されたことを確認すれば完了です。
→
404URLを一覧で確認
→
原因を3つに分類
→
リダイレクト or sitemap修正
→
URL検査で検証
まとめ：月1回のチェックでクローラーへの404をゼロに近づける
サーバーログを1日分解析しただけで、3種類のクローラーが異なるパターンで404を踏んでいることが確認できました。どれも「気づかないまま放置されがちな404」でした。
原因はシンプルです。スラッグを変更したときにリダイレクトを設定しなかった。sitemapのURLが統一されていなかった。sitemapに古いURLが残ったままだった。どれも一度対処すれば繰り返さない問題です。
月1回Search Consoleのカバレッジレポートを確認する習慣をつけるだけで、クローラーへの404は大幅に減らせます。クロールバジェットを無駄に消費しない設計が、AIに読まれるサイトの土台になります。
AIクローラーがサイトをどう巡回するかについてはAI検索はどうやってあなたのサイトを読んでいるのか？で詳しく解説しています。
404対策チェックリスト
以下のチェックリストを月1回の習慣として使ってください。
- Search Consoleの「ページ」→「見つかりませんでした（404）」を確認した
- スラッグを変更した記事に301リダイレクトを設定した
- robots.txtにsitemapのURLを明記した（sitemap_index.xmlに統一）
- sitemapに削除・移動済みのURLが残っていないか確認した
- 修正したURLをSearch ConsoleのURL検査で検証した
関連記事：
あなたのサイトは、
AIに見えていますか？
URLを入力するだけで30秒。8項目を自動診断し、優先度別の改善プランを提示します。完全無料・登録不要。
