Search Consoleに404が残り続ける理由|削除済みURLと正しい確認方法のメモ

  • URLをコピーしました!

Search Consoleの「ページのインデックス登録」を見ていると、「見つかりませんでした(404)」に古いURLが残っていることがあります。

削除した記事なら404になるのは当然です。けれど、Search Consoleの画面に残り続けていると、「これは直さないといけないのか」「非表示にした方がいいのか」と迷いました。

実際に、一時的な非表示リクエストを試したURLもあります。しかし、しばらくすると「非表示の期限が切れました」と表示され、404の一覧には残ったままでした。

この記事では、Search Consoleに404が残り続けたときに確認したことを、ミコトホドの運用メモとして整理します。

目次

404に残っているURLが、すべて問題とは限らない

Search Consoleに「見つかりませんでした(404)」と表示されると、サイト側に問題があるように見えます。

ただ、削除済みの記事や、すでに使っていない古いURLが404になること自体は自然です。存在しないページにアクセスされたとき、「見つかりませんでした」と返すのは、正しい動きです。

問題になるのは、今も使っているページが404になっている場合や、検索結果に出ているURLをクリックした先が404になっている場合です。

つまり、404の一覧にあるからすぐ直すのではなく、そのURLが今どういう状態なのかを確認する必要があります。

URL検査で現在の状態を確認する

まず確認したのは、Search ConsoleのURL検査です。

「見つかりませんでした(404)」に出ているURLをURL検査にかけると、そのURLがGoogleに登録されているか、最後にクロールされたときにどう扱われたかを確認できます。

ただし、URL検査の最初の画面は、前回クロール時点の情報を表示していることがあります。そのため、現在の状態を確認したい場合は、「公開URLをテスト」まで進めます。

公開URLテストで「見つかりませんでした(404)」と表示されるなら、そのURLは今も404として返っていることになります。

削除済みの記事URLが公開URLテストで404と確認できるなら、そのURLは削除済みページとして正しく処理されています。インデックス登録リクエストを送る必要はありません。

Search Consoleの公開URLテストで削除済みURLが404として確認されている画面
公開URLテストで削除済みURLが404として確認された画面

一時的な非表示は、404一覧を消すためのものではない

Search Consoleの404一覧に古いURLが残っていると、一時的な非表示リクエストで消せるのではないかと思うかもしれません。

ただ、一時的な非表示は、検索結果に表示されているURLを一時的に隠すための機能です。Search Consoleの「見つかりませんでした(404)」一覧を整理するためのものではありません。

実際に、一時的な非表示を試したURLでも、しばらくすると「非表示の期限が切れました」と表示されることがありました。

これは、非表示リクエストが失敗したというより、そもそも削除済みURLが404として処理されており、一時的に検索結果から隠す必要がなくなった状態と考えた方が自然です。

Search Consoleで古いURLの一時的な非表示リクエストが期限切れになっている画面
Search Consoleの一時的な非表示リクエストが期限切れになっている画面

404一覧に残っているだけなら、一時的な非表示を繰り返す必要はありません。まず見るべきなのは、そのURLが現在も404として正しく返っているかどうかです。

削除済みURLでも、Googleが再確認することがある

削除済みの記事URLでも、Googleが過去にそのURLを知っていると、あとから再確認されることがあります。

たとえば、過去のサイトマップ、RSSフィード、外部サイトからのリンク、ブックマークサービス、古い内部リンクなどがきっかけで、GoogleがそのURLを見に行くことがあります。

そのときにページが存在しなければ、Search Consoleには「見つかりませんでした(404)」として記録されます。

これは、今そのページが公開されているという意味ではありません。Googleが知っているURLを確認した結果、現在は見つからなかった、という記録です。

画像URLでも同じことが起こります。WordPressでは画像が /wp-content/uploads/ 配下に保存されるため、過去に使っていた画像やサムネイルを削除すると、Search Console上で /wp-content/uploads/* のようにまとめて表示されることがあります。

この * は実際に使ったURLではなく、Search Consoleが uploads 配下のURLをまとめて表示しているものです。昔使っていた画像を削除したあとに出てくることがあります。

Search Consoleでwp-content/uploads配下のURLが404としてまとめて表示されている画面
uploads配下の画像URLがまとめて404として表示されている例

過去に使っていた画像やサムネイルを削除している場合、このような表示が出ることがあります。今公開中の記事で画像切れが起きていなければ、削除済み画像の404として見て大丈夫です。

直すべき404と、放置していい404を分けて考える

Search Consoleに404が出ていても、すべてを同じように直す必要はありません。

大事なのは、そのURLが今のサイトにとって必要なものかどうかです。

削除済みの記事や、今は使っていない画像URLが404になっているだけなら、基本的には正常な状態です。存在しないページや画像に対して、見つからないと返しているだけだからです。

一方で、今公開している記事や、記事内で使っている画像が404になっている場合は修正が必要です。読者が開こうとしているページや画像が表示されないためです。

状態対応
削除済みの記事URLが404基本的にそのままでOK
今公開している記事が404すぐに修正する
移転先がある旧URLが404301リダイレクトを検討する
削除済み画像のURLが404今使っていなければ基本的にそのままでOK
記事内で使っている画像が404画像の差し替えやリンク修正が必要
検索結果に出ているURLを開くと404優先して確認する。対応先があれば301、なければ削除ツールなどを検討する

404をゼロにすることよりも、現在のサイトで必要なページや画像が正しく表示されているかを見る方が大事です。

特に確認したいのは、検索結果に古い記事タイトルやURLが残っていて、クリックすると404になるケースです。これは読者が実際に踏む可能性があるため、Search Consoleの一覧に残っているだけの404より優先して確認します。

対応する新しい記事があるなら301リダイレクトを検討します。対応する記事がない場合でも、検索結果に古い情報が残り続けているなら、削除ツールや再クロールの状況を確認します。

削除済みのURLまで無理に消そうとすると、Search Consoleの表示に振り回されてしまいます。

参照元ページに古いURLが残っていないか確認する

Search ConsoleのURL検査では、参照元ページが表示されることがあります。

参照元ページは、GoogleがそのURLを見つけるきっかけになったページです。ただし、必ずしも現在もそこからリンクされているとは限りません。過去にGoogleが見つけた記録として残っている場合もあります。

そのため、参照元ページが表示されている場合は、実際にそのページを開き、古いURLが今も残っていないか確認します。

今回確認したURLでは、参照元としてRSSフィードや外部サービスのページが表示されていました。フィードを開いてページ内検索をしても該当URLが残っていなければ、現在のサイト側から出し続けているURLではないと判断できます。

  • 参照元ページを開く
  • ページ内検索で古いURLの一部を探す
  • 該当URLが残っていれば、リンクやフィードの状態を確認する
  • 該当URLが見つからなければ、過去の発見記録として考える

参照元ページは、404の確認だけでなく、通常のインデックス確認でも参考になります。たとえば、固定ページをURL検査したときに、トップページが参照元として表示されることがあります。

これは、トップページやフッターなどからそのページへ内部リンクがあり、Googleがそのリンクをたどってページを見つけていると考えられます。

Search ConsoleのURL検査でインデックス登録済みページの参照元にトップページが表示されている画面
正常にインデックス登録されているページで、トップページが参照元として表示されている例

このように、参照元ページを見ると、GoogleがどこからURLを見つけたのかを確認する手がかりになります。404のURLでも、今も内部リンクやフィードに古いURLが残っているのか、それとも過去の記録として残っているだけなのかを切り分けやすくなります。

外部サービスに古いURLが残っていることもある

古いURLは、自分のサイト内だけに残るとは限りません。

過去に使っていたブログサービスや、ブックマークサービス、外部サイトなどにURLが残っていると、Googleがそこから古いURLを見つけることがあります。

今回確認した中では、はてなブックマーク側に、以前のサイト運用時代の記事情報が残っていました。

Search ConsoleのURL検査で参照元ページにはてなブックマークのURLが表示されている画面
参照元ページとして、はてなブックマークのURLが表示されていた例

今回の場合、はてなブログ時代の記事はすでに存在していません。現在のミコトホドにも、対応する記事はありません。

そのため、はてなブックマーク側に古い記事情報が残っていても、リンク先で404になること自体は自然です。存在しない記事に対して、現在のサイトが「ページが見つかりませんでした」と返しているだけだからです。

対応する新しい記事があるなら、旧URLから新しい記事へ301リダイレクトする方法があります。

ただし、対応する記事がない場合は、無理にトップページや関係のないページへリダイレクトする必要はありません。読者にとっても、Googleにとっても、関係のないページへ移動する方が不自然です。

対応する新しいページがある旧URLは301リダイレクトを検討します。対応するページがない旧URLは、404のままで問題ありません。関係のないページへ無理にリダイレクトしない方が自然です。

まとめ:404を消すより、なぜ見えているのかを確認する

Search Consoleに「見つかりませんでした(404)」が残っていると、何か問題があるように見えます。

404は、存在しないURLに対して返される状態です。削除済みの記事や、今は使っていない画像URLが404になること自体は自然です。

ただ、Search Consoleの一覧に表示された時点で、そのURLは運営者にとって確認すべき対象として見えてしまいます。ページとしては存在していないのに、Search Console上では404の項目として存在しているように見える。ここが分かりにくいところです。

だからこそ、404一覧にあるというだけで判断せず、URL検査や公開URLテストで現在の状態を確認します。参照元ページ、内部リンク、フィード、外部サービスに古いURLの痕跡が残っていないかも見ます。

確認した結果、対応する新しいページがあるなら301リダイレクトを検討します。対応するページがなく、現在も404として正しく返っているなら、404のままにする判断もあります。

一方で、検索結果に古い記事タイトルやURLが残っていて、クリックすると404になる場合は優先して確認します。読者が実際に踏む可能性があるため、Search Consoleの一覧に残っているだけの404とは分けて考えます。

URL検査で現在の状態を確認できる一方で、ページのインデックス登録レポートに404が残り続けることもあります。この表示は運営者にとって分かりにくく、一覧表示とURL検査の結果がもっと分かりやすくつながっていれば、迷う場面は減るはずです。

今回の確認では、404をただ消すのではなく、そのURLがなぜ見えているのか、今も痕跡が残っているのか、現在のサイトにとって直すべきものなのかを分けて見ることが大切だと分かりました。

  • URLをコピーしました!

コメント

コメントする

目次