Not Found（404）とSEO

TL;DR — Search Console の「Not found (404)」は、Google があなたのサーバーにページを リクエストして「見つかりません」という応答を受け取り、インデックスに登録しなかったことを意味します。Google は その URL を自ら発見しました — 通常はどこかのリンクから、またはそのページが以前存在していたためです — これは発見された経路を示すものであり、現在のサイトマップに存在しないことの証明ではありません。これは正常で、 通常は問題ありませんが、実際に削除されるべき URL に限ります。URL が 機能するべき 場合にのみ修正が必要で、 その場合はページを復元するか、適切な代替ページにリダイレクトします。

「Not found (404)」の意味

このラベルは、Google が URL をリクエストした際に HTTP 404 を受信したことを意味します。 この主張の根拠 Google reports Not found 404 when the page returned a 404 response when requested. 対象範囲： Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. 信頼度： 高 · 検証日： 2026-07-14 Google: Page indexing report Google は、429 以外の永続的な 4xx 応答を、コンテンツが存在しないものとして扱います。 この主張の根拠 Google treats 4xx responses other than 429 as if content does not exist and removes persistently returning URLs from the index. 対象範囲： Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. 信頼度： 高 · 検証日： 2026-07-14 Google: HTTP status codes

Google Search Console で ページのインデックス登録 レポートを開くと、ページがインデックスに登録されない理由のリストが表示されます。「Not found (404)」 はそのうちの 1 つです。これは、Googlebot が URL をリクエストし、あなたのサーバーが HTTP 404 (Not Found) — 標準的な「このページは存在しません」という応答 — を返したことを意味します。ページが 404 を返したため、Google はそれをインデックスに登録しませんでした。

人々を驚かせる点: Google は、この URL を あなたからの明示的なリクエストなしに 発見したと述べています。これは Google が どのように 発見したかを説明するもので — 通常は以下の 2 つのいずれかです — 現在のサイトマップに存在しないことの保証ではありません。同じ URL がまだ提出済みのサイトマップに含まれている場合、それは別の修正可能な問題 (古いサイトマップエントリ) であり、レポートが伝えていることと矛盾するものではありません:

• リンク。 ウェブ上の何かがその URL にリンクしている — あなた自身のページ、または 別のサイトのページ — そして Google がそのリンクをたどりました。
• 以前存在していたページ。 URL が以前は公開されインデックスに登録されていましたが、その後削除したか URL を変更しました。Google はそれをまだ覚えており、再チェックします。

404 は SEO に悪影響を与えますか?

これは誰もが本当に知りたい質問なので、最初に明確にします: いいえ、自動的には影響しません。 404 はウェブが機能する上での正常な一部です。ページは削除され、URL は変更され、他のサイトが存在しないアドレスにリンクすることもあります。ページが本当に存在しない場合に 404 を返すことは 正しい 動作です — Google 自身のドキュメントによると、429 以外の 4xx 応答はサイトのクロール率に影響を与えず、正しい 404 はサイトの他の部分に対するペナルティではありません。

ただし、その「正しい」というラベルは、実際に削除されるべき URL にのみ適用されます。まだリンクしているページ、サイトマップに含まれているページ、または他のサイトがまだリンクしているページでの 404 は、技術的に有効だからといって無害というわけではありません — それは壊れたリンク、失われたリンク評価、または訪問者が行き止まりに当たることです。したがって、本当に削除されたページで何もリンクしていない場合、レポートの「Not found (404)」は慌てる必要はありません。それ以外の場合は、確認する価値があります — 次のセクションを参照してください。

404 が実際に修正する価値がある場合

注意が必要な 404 は、機能するべき URL のものです:

• 自分のナビゲーションやコンテンツからまだリンクしているページ (壊れた内部リンク)。
• サイトマップに含まれている URL (含まれるべきではありません — サイトマップは公開されインデックス可能なページ用です)。
• 他のサイトがリンクしているページ (それらのリンクを無駄にすることになります)。
• まだトラフィックがある、または人々が明らかに到達しようとしていた URL。

これらの場合、2 つの良い選択肢があります:

1. ページを復元する 誤って削除された場合。
2. リダイレクトする 最も関連性の高い公開ページへ (301 リダイレクト)。これにより、訪問者を 役立つ場所に送り、重要なことに、古い URL を指すリンクの価値を引き継ぎます。

やってはいけないことの 1 つ: すべての死んだ URL をホームページにリダイレクトしないでください。Google はそのような無関係なリダイレクトを「ソフト 404」として扱います — これはそれ自体が問題です。 本当に関連するページにリダイレクトするか、そのまま 404 にしておきましょう。

完全版（404 vs 410 vs 301 vs noindex、404 にリンクしているものの見つけ方、レポートに残る期間）が必要ですか？詳細タブに切り替えてください。

TL;DR — 「Not found (404)」は、Googlebot が Google の説明によると独自に発見した URL（リンクや以前インデックスされたページ）をリクエストし、明示的なリクエストではなく、404 を受け取ったためインデックスされていないことを意味します。この説明は元の発見を説明しているだけで、URL が現在のサイトマップに存在しないという証明ではありません。404 はウェブの正常な一部であり、Google の公式ドキュメントでは 429 以外の 4xx レスポンスはクロール率に影響しないとされています。置き換えのない削除済みページの 404 は正しく、サイト全体のペナルティではありません。ただし、存在すべき URL（内部リンク、サイトマップ、被リンク、トラフィックがある）の 404 は、壊れたリンク、リンクの価値の喪失、ユーザーの喪失につながります。そのような場合は、ページを復元するか、関連性のある実際のライブページに 301 リダイレクトしてください。被リンクがあるものを優先してリンクの価値を回復します。それ以外は 404 のままにします。私の経験では 410 の方が少し早く消える傾向がありますが、Google は 429 以外の 4xx コードを同じように扱います。ホームページへの大量リダイレクトは避けてください（ソフト 404 のリスク）。Googlebot は古い 404 を頻度を減らしながら再チェックし続けるため、レポートに残り続けます。これは正常であり、ペナルティではありません。

Google が実際に伝えていること

レポートは観測された 404 を示していますが、どのリンク、過去の URL、アプリケーションルートがそれを生成したかをそれ自体で説明するものではありません。 この主張の根拠 Google reports Not found 404 when the page returned a 404 response when requested. 対象範囲： Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. 信頼度： 高 · 検証日： 2026-07-14 Google: Page indexing report Google の一般的な 4xx ドキュメントはインデックス動作を説明しています。 この主張の根拠 Google treats 4xx responses other than 429 as if content does not exist and removes persistently returning URLs from the index. 対象範囲： Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. 信頼度： 高 · 検証日： 2026-07-14 Google: HTTP status codes

Google のこのステータスの定義は短いものです：「このページはリクエスト時に 404 エラーを返しました。」 重要なのは周囲の文脈です。Google は URL をあなたからの明示的なリクエストやサイトマップなしで発見しました。これが「Not found (404)」と自分で送信したインデックスエラーを区別する点です。

この文は Google が元々 URL をどのように発見したかを説明しています。URL がサイトマップに一度も表示されたことがない、または現在も含まれていないという主張ではありません。ライブのサイトマップを確認して同じ URL がまだリストされている場合、それは実際の（そして別の）修正すべき問題、つまり古いサイトマップエントリであり、レポートが発見について伝えていることと矛盾するものではありません。

つまり、URL は次のいずれかから来ています：

• 内部リンクまたは外部リンク。 Google はクロール中にリンクを抽出します。タイプミスのある内部リンク、他のサイトの古いリンク、コメント内のリンクはすべて、Googlebot を 404 になる URL に向ける可能性があります。
• 以前インデックスされたページ を削除したか、URL を変更した場合。Google は見た URL を記憶し、長期間再リクエストします。
• スクレイピングされた、不正な、または捏造された URL。 他のサイトが URL を壊したり、ジャンクを追加したり、パスをでっち上げたりすることがあります。Google はそれらを試すことがあります。これらはすべてあなたの責任ではなく、対応も必要ありません。

最後の点は心に留めておく価値があります：このレポートで 404 を見つけても、何か間違ったことをしたという意味ではありません。 Google はウェブ上のあらゆる場所から URL を発見します。

「Not found (404)」は SEO に悪影響を与えますか？（先に結論）

いいえ、自動的には影響しません。これはこのレポートに関する最大の誤解です。404 はコンテンツがなくなったときにウェブが機能する方法であり、Google のクロールドキュメントでは 429 以外の 4xx ステータスコードはサイトのクロール率に影響しないとされています。本当に削除されたページに対する正しく返された 404 は、サイト全体のペナルティではありません。

ただし、これは「404 は決して重要ではない」という主張より狭いものです。404 自体がサイトの他の部分を引き下げるわけではありませんが、機能すべき URL（内部リンク、外部被リンク、実際のトラフィックがあるもの）の 404 は、具体的な何か、つまり壊れたリンク、失われたリンクの価値、行き止まりに当たる訪問者を失うことになります。レポート自体が問題なのではなく、存在すべきでない 404 を修正せずに放置することが問題です。

これは、HTTPステータスコード全般に関する私自身の見解とも一致します。4xxレスポンスは特定のページがインデックスから外れる原因になりますが、それはページがきれいに消えるだけであって、ドメインに適用されるペナルティではありません。404を返すページは単にインデックスに存在しなくなるだけで、他のすべてには影響しません。

Googleの公式ヘルプドキュメントも、インデックス全般について同じ点を指摘しています。適切な理由でURLがインデックスされないことは問題なく、「削除したページで、代わりのページがない場合の404」 は、まさにその適切な理由の1つとして明示されています。本当に削除されたページの404は、正しい最終状態であり、対応すべき項目ではありません。

Googleが404を内部的にどう処理するか

GoogleのHTTPステータスに関するドキュメントによると、その仕組みは明確です。以前インデックスされたURLの場合、インデックスパイプラインはそれをインデックスから削除します。新しく遭遇した404は単に処理されません。インデックスするものがないからです。また、GooglebotはURLをすぐに忘れるわけではなく、再リクエストを続け、クロール頻度は時間とともに徐々に減少します。

この再チェックの動作が、古い404が対応後も長くレポートに表示され続ける理由です。 Googleは、ページが戻ってくる可能性に備えて、定期的にページがまだ存在しないことを確認しています。これは問題の兆候ではなく、通常の規模のサイトでは、意味のある量のクロールバジェットを無駄にしているわけでもありません。

404を修正すべき場合と、そうでない場合

判断ルールはシンプルです。URLが存在すべき場合にのみ404を修正します。 URLが「存在すべき」ことを示すシグナルは次のとおりです。

• 内部リンクがある（ナビ、コンテンツ、フッターの壊れたリンク）。
• サイトマップに含まれている（含まれるべきではありません。サイトマップには、ライブでインデックス可能なURLのみをリストする必要があります）。
• 外部バックリンクが指している。
• まだトラフィックがある、または人々が探しているものに明確に一致する。

これらのいずれも当てはまらない場合（ページが本当に削除され、価値のあるものが何も指していない場合）は、404のままにしておきます。それが正しい対応であり、何もする必要はありません。

重要なものを修正する方法

解決すべきURLについては、選択肢は限られています。

• ページを復元する（誤って削除された場合、または同等のコンテンツを戻せる場合）。
• 最も関連性の高いライブページに301リダイレクトする。 これは、適切な代替ページがある削除済みページに対する通常の対応です。以前、4xxとして表示されるページについて述べたように、多くの場合、それぞれを関連ページに301リダイレクトするだけで済みます。リダイレクトはユーザーを役立つ場所に送るだけでなく、リンクのランキング価値も新しいURLに引き継ぎます。
• ページが本当に削除され、適切な代替ページがない場合は、404（または410）のままにする。 これは失敗ではなく、正しい答えです。

インバウンドリンクで優先順位を付ける。 最も価値の高い404は、外部バックリンクがあるものです。リンクのある死んだURLは、関連ページへの単一のリダイレクトで回収できるエクイティを漏らしているからです。バックリンクのある404 URLを抽出し（バックリンクツールやリンクレポートで確認できます）、それらを最初に301リダイレクトします。リンクもトラフィックもない404は、そのまま404にしておけばよく、リダイレクトしても何も達成されません。

すべてをホームページにリダイレクトしない。 無関係なページへのリダイレクト（典型的には、すべての死んだURLを / にまとめて送ること）は、Googleによってソフト404として扱われます。なぜなら、宛先がリクエストされたものの実際の代替ではないからです。関連する ページにリダイレクトするか、まったくリダイレクトしないかのどちらかです。

404 vs 410 vs 301 vs noindex

これらは常に混同されます。完全な判断テーブルはチートシートタブにあります。短いバージョンは次のとおりです。

• 404 (Not Found) / 410 (Gone) — ページが存在しない。どちらもURLをインデックスから削除し、Googleの公式ドキュメントでも4xxステータスコード（429以外）を同じように扱うとされています。私自身の実務経験では、410の方が少し速く削除される傾向がありますが、どちらにしても差は最小限です。 410は「これは二度と戻らない」というシグナルを送りたい場合に使い、404はそれ以外で完全に問題ありません。
• 301 (Moved Permanently) — コンテンツが移動した。新しいURLにシグナルを集約する。これは、削除されたページに適切な代替ページがある場合に使うツールです。
• noindex — ページは存在し、公開されたままにすべきだが、検索結果に表示したくない。目的が異なるので使うツールも異なります。本当に削除されたページには使わないでください。

404と410の比較について、私自身の考え方としては、404と410は同様に扱われます。どちらもページをインデックスから削除し、私の経験では410の方が少し速いですが、Googleのドキュメントでは4xxコード（429以外）を同一に扱っています。 だから、選択に悩む必要はありません。「永久に削除」には410を、それ以外には404を選んで、先に進みましょう。

404にリンクしているものを特定する方法

404を修正する（または修正する価値があるか判断する）には、その404に何がリンクしているかを特定します。

• GSCで: 「Not found (404)」ステータスを開き、サンプルURLをクリックして、Referring page をDiscoveryで確認します。これは完全なリンクインベントリではなく、1つの手がかりとして扱ってください。Googleはこれを、URLの発見に使用した可能性があるページと説明しており、直接リンク、リンクが見つかった上位ページ、または情報が利用できない場合は単に存在しない場合もあります。これだけで止めずに、以下の方法と組み合わせてください。
• クローラー / サイト監査で: Ahrefs Site AuditやScreaming Frogは、サイト内の壊れた内部リンクをリストアップします。これは、リンクを編集して直接修正できる社内の404です。
• 被リンクツールで: 壊れた被リンクをチェックして、外部サイトがリンクしているサイト上のデッドURLを見つけます。これらが301の優先事項です。
• サーバーログで: どのURLがリクエストされ、どのステータスコードが大規模に返されているかの真実の情報源です。

修正の検証と期待される結果

存在すべきURLを復元またはリダイレクトしたら、Page IndexingレポートでValidate Fixを押せます。これは必須ではなく任意です。Googleは、検証するかどうかに関係なく、次回ページをクロールするときに自動的に修正を検出できると述べています。Validate Fixを押すと、そのレビューを追跡できるだけで、保証されたタイムラインや高速な再処理の約束はありません。どちらにしても、カウントがすぐにゼロになるとは期待しないでください。Googleは404を漸減スケジュールで再クロールするため、正しく処理されたURLでもレポートにしばらく残ることがあります。その残存は再チェックの動作であり、修正が効かなかった兆候ではなく、Googleが完了を保証する固定時点はありません。（そして、本当に正しい404をレポートから消そうとして検証する理由はありません。検証は修正の確認のためであり、機能している404を却下するためではありません。）

非常に大規模なサイトで大量の偽の404（壊れたテンプレートやスパイダートラップによる何百万ものジャンクURL）が生成される場合、クロール効率が実際の懸念事項となり、1つずつではなくパターンベースの修正が必要になります。しかし、一般的なサイトでは、404によるクロールバジェットのコストは無視できる程度です。

関連するステータスとの位置づけ

“Not found (404)“は明確なケースです。サーバーが正しく「not found」と応答しました。Page Indexingレポートの隣接する項目は異なる状況であり、混同しないでください。ソフト404は、200（または無関係なリダイレクト）で配信される「見つかりません」というメッセージであり、Googleはこれを別途フラグします。Blocked due to other 4xx issueは、401/403およびその他の4xxファミリーをカバーします。Redirect errorは壊れたリダイレクトであり、通常の「Page with redirect」とは異なります。そして**server error (5xx)**は、ページが存在しないのではなく、サーバーが失敗したことを意味します。修正方法は異なるため、まず実際にどのステータスを見ているかを特定してください。

レポート全体については、GSC ページ インデックス ハブを参照してください。ボットがそもそもどのように URL をリクエストするかという根本的な仕組みについては、クロール を参照してください。

AIまとめ

Advancedバージョンの簡潔な見解:

• 意味： Googlebot は、リンクや以前インデックス登録されていたページなど、Google が独自に発見したと説明する URL をリクエストしました。これは明示的なリクエストによるものではなく、HTTP 404 が返されたためページはインデックス登録されません。Google の定義は “This page returned a 404 error when requested.” (翻訳)「このページはリクエスト時に 404 エラーを返しました」です。これは発見経路の説明であり、URL が現在のサイトマップにないことの証明ではありません。サイトマップに残る URL は別の修正対象です。
• URL の出所： 内部・外部リンク、削除または名前変更したページ、他サイトにあるスクレイピング・不正・捏造 URL などです。ここで 404 が見つかっても、必ずしもサイト側の誤りではありません。
• SEO への影響： 自動的ではありません。Google の公式文書では 429 以外の 4xx はクロール率に影響せず、代替のない削除ページが正しく 404 を返してもサイト全体のペナルティにはなりません。ただし、リンク、サイトマップ、被リンク、トラフィックがあり、機能すべき URL の 404 は壊れたリンク、失われた評価、ユーザー損失につながります。
• Google の処理： 以前インデックス登録されていた URL は削除し、新しく発見した 404 は処理せず、頻度を徐々に下げながら再確認します。古い 404 がレポートに残るのは正常で、ペナルティではありません。
• 修正する場合： 内部リンク、サイトマップ、被リンク、トラフィックがあり、存在すべき URL だけです。
• 修正方法： ページを復元するか、本当に関連する公開ページへ 301 リダイレクトします。評価を回収するため、被リンクのある 404 を優先します。本当に削除済みなら 404（または 410）のままにします。Google の文書では同じ扱いですが、実務経験では 410 の方がわずかに早く消える傾向があります。
• 避けること： すべてをホームページへ一括リダイレクトしないでください。関連性のないリダイレクトは ソフト 404 として扱われます。
• 404・410・301・noindex： 404 / 410 = 削除済み、301 = 移動して代替へ統合、noindex = ページを公開したまま検索から除外。
• リンクの発見： GSC の「参照元ページ」（完全なリンク一覧ではなく手がかりの1つ）、クローラー、被リンクツール、サーバーログを使います。修正を検証は任意で、実行しなくても Google は修正を検出できます。どちらにも保証された期間はありません。

公式ドキュメント

検索エンジンからの一次情報ドキュメント。

Google

• ページのインデックス登録レポート — この状態が表示されるレポートで、「Not found (404)」の定義と “it’s fine for a URL not to be indexed for the right reasons” (翻訳)「正当な理由で URL がインデックス登録されなくても問題ない」という説明を含みます。
• HTTP ステータスコード、ネットワークエラー、DNS エラー — 以前登録された URL の削除、新規 404 の非処理、クロール頻度の段階的低下など、Google の 4xx 処理。
• リダイレクトと Google 検索 — 存在すべき 404 を関連する公開ページへ送る 301 リダイレクトの設定方法。
• 検索からページを削除する方法 — 公開中のページを検索から除外する noindex。404 とは目的が異なります。

Bing / Microsoft

• Bing Webmaster Tools — サイト エクスプローラーと URL 検査 — Bing のクロール情報は 404 を同じ方法で表示します。処理のガイダンスは Google と一致しています (重要なものを修正し、本当に削除されたページは 404 のままにします)。

ソースからの引用

Googleからの公式声明。各リンクは、ソースページの引用箇所にジャンプするディープリンクです。

Google — 「見つかりません (404)」の定義

• “This page returned a 404 error when requested.” (翻訳)「このページはリクエスト時に 404 エラーを返しました」 — Google Search Console ヘルプ、ページのインデックス登録レポート。 引用箇所へ

Google — URL がインデックスされなくても問題ない

• “It’s fine for a URL not to be indexed for the right reasons—for example, an expected robots.txt rule on your site, a noindex tag on the page, a duplicate URL, or a 404 for a page that you’ve removed and have no replacement for.” (翻訳)「正当な理由で URL がインデックス登録されなくても問題ありません。たとえば、想定どおりの robots.txt ルール、ページの noindex タグ、重複 URL、または削除済みで代替のないページの 404 などです」 — Google Search Console ヘルプ、ページのインデックス登録レポート。 引用箇所へ

Google — インデックス登録における 4xx の処理方法

• “In the case of Google Search, the indexing pipeline removes the URL from the index if it was previously indexed. Newly encountered 404 pages aren’t processed.” (翻訳)「Google 検索では、以前インデックス登録されていた URL をインデックスから削除し、新しく検出した 404 ページは処理しません」 — Google Search Central、HTTP ステータスコードの文書。 引用箇所へ
• “The crawling frequency gradually decreases.” (翻訳)「クロール頻度は徐々に低下します」 — Google Search Central、HTTP ステータスコードの文書。 引用箇所へ

メンタルモデル

1. 発見 ≠ 送信。 「見つかりません (404)」は、Google が URL を独自に発見したことを具体的に意味します — リンク、古いインデックス済みページ、別サイトからの壊れた URL など — サイトマップからの発見ではありません。したがって、最初の質問は「どう修正するか」ではなく「この URL はそもそも存在すべきか」です。

2. 404 は削除されたページに対する正しい回答です。 404 は排除すべきエラーではなく、コンテンツがなくなった場合の正しい HTTP レスポンスです。品質シグナルでもランキング シグナルでもありません。目標は正確さ — URL が実際に真実の内容を返すこと — であり、レポートのゼロ件ではありません。

3. 存在すべきものだけを修正します。 すべての 404 を 1 つのテストにかけます: 内部リンク、サイトマップ、外部リンク、またはトラフィックがまだあるかどうか。はい → 復元するか、関連ページに 301 リダイレクトします。いいえ → 404 のままにします。この 1 つのルールでレポートの大部分が解決します。

4. URL を復元する前に、リンク価値を回収します。 修正する価値のある 404 のうち、外部からのインバウンド リンクがあるものが最優先です — 関連ページへの 301 リダイレクトでそのリンク価値を取り戻せます。リンクもトラフィックもない 404 はそのままにしておいて問題ありません。リダイレクトしても何も得られません。

5. 関連性のあるリダイレクトか、リダイレクトなし。 301 は本当に関連するページにたどり着く場合にのみ役立ちます。無関係なリダイレクト（すべて → ホームページ）はソフト 404 として扱われます。適切な宛先がない場合、正しい対応は 404 を維持することであり、無理に作ることではありません。

「見つかりません (404)」リストのトリアージ

レポートを上から下まで処理します:

• Page Indexing レポートで 「Not found (404)」 ステータスを開き、 サンプル URL を確認します。
• 各 URL について、Discovery の下にある Referring page をクリックして確認します — Google がリンクを見つけた場所の手がかりになる可能性がありますが、完全なリストであるとは限りません。
• 内部リンクされている URL にフラグを立てます — 壊れた内部リンクを元の場所で修正します（これが最も簡単な成果です）。
• サイトマップに含まれている URL にフラグを立てます — そこにあるべきではないため、削除するかページを復元します。
• 外部バックリンクがある 404 URL を抽出します（壊れたバックリンクレポート）— これらは、リンクの価値を回復するための 301 の優先事項です。
• まだトラフィックを受けている、またはユーザーの意図に明確に一致する 404 を確認します。
• 「存在すべき」URL ごとに: ページを復元するか、関連性の高いライブページ（ホームページではない）に 301 を設定します。
• リンクやトラフィックがなく、本当に消えた URL は 404 のままにします（少し速く消したい場合は 410）。
• ライブのリダイレクトが無関係な URL を / に送っていないことを確認します（ソフト 404 のリスク）。
• 必要に応じて Validate Fix を実行します（Google が独自に修正を検出することもあります）— その後、即座にゼロになるのではなく、ゆっくりと減少することを期待します。固定された期間はありません。
• 正しいステータスをトリアージしていることを確認します（ソフト 404、他の 4xx、リダイレクトエラー、5xx ではない — 修正方法が異なります）。

プレイブック: 突然の 404 スパイクへの対応

1. スパイクが本物であることを確認します。 Search Console のサンプルをライブクロールまたはサーバーレスポンスと比較します。レポートは現在の動作より遅れることがあります。
2. 原因とテンプレートごとにグループ化します。 デプロイ、URL パターンの変更、内部リンクのバグ、削除されたセクション、または不正な生成 URL を探し、行ごとに修正するのではなく対応します。
3. 価値のある URL を優先します。 存在すべき、意味のあるバックリンクやトラフィックがある、または内部リンクやサイトマップに残っている URL を復元またはリダイレクトします。
4. 正当な削除はそのままにします。 置き換えのない本当に消えた URL は 404 または 410 を返し続けるべきです。無関係なページにリダイレクトしないでください。
5. ソースを修正します。 テンプレート、内部リンク、サイトマップ生成を更新して、壊れたパターンを生成または促進しないようにします。
6. 検証して再発を監視します。 代表的な URL をテストし、パターンを監視します。価値のある URL が正しく解決され、新しく発見された 404 が期待されるベースラインに戻ったら終了します。

404 チートシート

どの状況でどのレスポンスを使うか

この 404 を修正すべきか？ — 判断フロー

クイックファクト

• 「Not found (404)」= Google は、あなたからの明示的なリクエストなしに URL を発見したことを説明しています。つまり、それがどのように発見されたかであり、現在のサイトマップに存在しないことを証明するものではありません。
• 正しく返された 404 は、自動的にサイト全体の品質やランキングのペナルティにはなりません。ただし、機能するはずの URL での 404 は、リンク、トラフィック、またはユーザーを失う原因になります。
• Google は、以前インデックスされた URL を 404 で削除します。新しい 404 は処理しません。
• Googlebot は、古い 404 を頻度を減らしながら再チェックし続けるため、残り続けます。
• 404 vs 410: Google のドキュメントは 4xx コード（429 を除く）を同じように扱います。実務者の経験では、410 の方が少し早く消えます。
• すべてをホームページにリダイレクトしないでください → ソフト 404。
• 404 のクロールバジェットへの影響は、大量の偽 URL がある非常に大規模なサイトを除いて無視できる程度です。

よくある問題

ページ インデックス レポートで 404 の数が突然急増する

考えられる原因: 壊れたテンプレートがジャンク URL を生成している（不正なページネーションパラメータ、ファセットナビゲーションのバグ、リンクに漏れるセッション ID）、スパイダートラップ、または別のサイトがあなたの URL をスクレイピングして改変している。修正: 新しい 404 URL のサンプルを取得し、共通のパターン（クエリパラメータ、パスプレフィックス）を探します。自分のテンプレートが原因なら、不正なリンクを生成するコードを修正します。サーバーログまたは /tools/log-file-analyzer でパターンを確認し、実際のクロールボリュームなのか、単なる数件の例なのかを確認します。

URL を修正したのに、数週間経っても「Not found (404)」と表示される

考えられる原因: Googlebot は 404 を漸減スケジュールで再チェックするため、レポートの数は実際の修正より遅れます。これは予想通りであり、修正が失敗した兆候ではありません。修正: curl -I または /tools/http-status-checker を使用して、ライブ URL が現在正しいステータス（復元された場合は 200、リダイレクトされた場合は 301）を返していることを確認します。GSC で Validate Fix を実行することもできますが、必須ではありません。Google は独自に修正を検出できるためです。数は即座にゼロになるのではなく、徐々に減少すると予想してください。完全に消えるまでの明確なタイムラインはありません。

削除した URL が「Not found (404)」ではなく「soft 404」として表示される

考えられる原因: ページが実際の 404/410 ステータスではなく、HTTP 200 で「見つかりません」というメッセージを返しているか、無関係なページにリダイレクトしている。修正: curl -I または /tools/http-status-checker でレスポンスコードを確認します。200 の場合は、サーバー（または CMS）を設定して、ソフトエラーページではなく、そのパスに対して実際の 404/410 を返すようにします。

設定した 301 が宛先で「soft 404」として表示される

考えられる原因: 宛先ページがリクエストされた内容の真の代替ではない。Google は、不一致のリダイレクトターゲットを、無関係なものと同じように読み取ります。修正: /tools/redirect-checker でターゲットを再確認し、301 を元の URL のトピックに実際に一致するページにポイントします。最も近いカテゴリページやホームページではなく。

レポートに、作成もリンクもしていない URL がリストされる

考えられる原因: 別のサイトからのスクレイピング、不正な形式、または捏造された URL、または Google がまだ記憶して定期的に再チェックしている何年も前のページ。修正: レポートで URL をクリックし、Discovery の下にある Referring page を確認します。これは手がかりの可能性がありますが、Google がそのデータを利用できない場合があるため、保証された情報源ではありません。外部で明らかに改変されている場合は、対応は不要です。あなたが壊したものではありません。

スクリプトとスニペット

URL のライブステータスを確認する（macOS/Linux）

修正が必要かどうかを判断する前に、URL が実際に返しているステータスコードを確認します。

curl -I https://example.com/old-page

レスポンスの最初の行を確認します（例: HTTP/2 404 または HTTP/2 301）。リダイレクトの場合、curl は宛先を含む location: ヘッダーを表示します。

URL のライブステータスを確認する（PowerShell）

$response = Invoke-WebRequest -Uri "https://example.com/old-page" -Method Head -UseBasicParsing
$response.StatusCode

PowerShell が自動的にフォローせずに生の 301/302 を確認したい場合は、-MaximumRedirection 0 を追加します。

サーバーログで 404 ヒットを grep する（正規表現）

Apache/Nginx の「combined」形式のアクセスログに対してこれを実行して、404 を返したすべてのリクエストを抽出します。

grep -oP '"\S+ \K\S+(?=.*" 404 )' access.log

キャプチャグループの内訳: "\S+ \K はHTTPメソッド（GET/POST）をスキップしてマッチから除外します。\S+ はリクエストされたパスをキャプチャします。先読み (?=.*" 404 ) は、ログ行の残りに 404 ステータスが含まれていることをマッチ前に要求します。出力は404を返したURLのプレーンなリストです。sort | uniq -c | sort -rn にパイプして頻度順にランク付けします。

DevToolsコンソール — ページを離れずにステータスを確認

コンソールパネルに貼り付けて、現在のブラウザから特定のURLのステータスを確認します:

fetch("https://example.com/old-page", {method: "HEAD"}).then(r => console.log(r.status, r.url));

ブックマークレット — 現在のページのステータスを確認

これをブックマークバーにドラッグします（ブックマークレットです。任意のページでクリックすると、そのページ自身のレスポンスステータスを確認できます）:

javascript:(function(){fetch(location.href,{method:"HEAD"}).then(function(r){alert(r.status+" "+r.url);});})();

404を見つけて修正するためのツール

このサイトのツール

• /tools/http-status-checker — リダイレクト、復元、または何もしないかを決定する前に、任意のURLのライブHTTPステータスを確認します。
• /tools/redirect-checker — 設定した301が、チェーンやループなしで、意図した宛先に単一ホップで実際に解決されることを確認します。
• /tools/log-file-analyzer — サーバーログを解析して、Googlebotが実際にヒットして404を返しているURLとその頻度を確認します。
• /tools/site-audit-lite — 自分のサイトをクロールして、壊れた内部リンク（ソースでリンクを編集して直接修正できる404）を表面化します。

サードパーティ製ツール

• Google Search Console — ページインデックスレポート自体。“Not found (404)” の例を開き、Referring pages ビューを使用して何がリンクしていたかを確認し、変更を行ったら Validate Fix を使用します。
• Bing Webmaster Tools — Bing向けの同等のクロールエラーサーフェス。
• Ahrefs または Screaming Frog — 壊れた内部リンクをリストするサイト全体のクロール、および 壊れたバックリンク（サイト上のデッドURLにリンクしている外部サイト）を表面化するバックリンクレポート — 301の優先リストです。

404修正の検証

存在すべきURLを復元またはリダイレクトした後、修正が実際に有効になったことを確認するためにこれらを実行します。単に想定するのではなく。

修正されたURLのライブステータスチェック

実行するテスト: URLに対する curl -I、または /tools/http-status-checker。 期待される結果: ページを復元した場合は200、リダイレクトした場合は正しい宛先への301。失敗の解釈: まだ404、5xx、または間違ったページを指すリダイレクトは、修正が実際にデプロイされていないことを意味します。監視ウィンドウ: 即時。ロールバックトリガー: 間違ったステータスまたは間違った宛先 — サーバールールを修正し、先に進む前に再確認します。

リダイレクトパスのチェック

実行するテスト: 古いURLに対する /tools/redirect-checker。 期待される結果: 関連するライブページに直接着地する単一ホップの301 — チェーンなし、ループなし。失敗の解釈: 複数ホップ、ループ、または無関係なページへの着地（ソフト404のリスク）。監視ウィンドウ: 即時。ロールバックトリガー: チェーン、ループ、または無関係な宛先 — リダイレクトルールを修正します。

GSC Validate Fix

実行するテスト: ページインデックスレポートで、“Not found (404)” を開いて Validate Fix を押します（オプション — Googleは独自に実際の修正を検出することもできます）。期待される結果: ステータスが “Validation started” から “Passed” に移行し、影響を受けるURL数が減少します。失敗の解釈: 検証が失敗するか、長期間カウントが動かない場合 — ライブURLが実際に修正されていること、および古いURLにリンクするものが何もないことを再確認します。監視ウィンドウ: 継続的で、固定された完了日はありません（Googleは404を段階的に減少するスケジュールで再チェックし、即時ではなく、保証されたタイムラインは提供しません）。ロールバックトリガー: 繰り返しの検証失敗 — サーバーレベルで修正を再検証します。

サーバーログのクロール動作

実行するテスト: 旧URLへのリクエストに対して /tools/log-file-analyzer を実行します。 期待される結果: 変更後、Googlebotの旧URLへのアクセスは時間の経過とともに減少し、リクエストは新URLへ移行します。失敗の解釈: 変更後もGooglebotが旧URLへ同じ頻度でアクセスし続ける場合、リダイレクトを認識していない（または旧URLへの直接リンクがまだ存在する）可能性があります。監視期間: 長期間にわたって継続します（Googleの公式ドキュメントによると、クロール頻度は固定スケジュールなしで徐々に減少します）。ロールバックのトリガー: 長期間経過しても減少が見られない場合 — リダイレクトがサーバーサイド（JSやメタリフレッシュリダイレクトではない）であることを確認し、旧URLへの残存する内部リンクを監査します。

クイズ

「Not found (404)」について実際に理解できているかを確認する5つの質問。

変更履歴