Search Consoleに内部404が出てるんだけど、これって見つけたURLをそのまま直せばいいのかな。
いきなり直すより、まず診断です。Search Consoleの404一覧は「修正リスト」ではなく、「確認リスト」として扱ったほうが安全です。
たしかに、404って言われると焦るんだよね。全部リダイレクトすればいいのかと思ってた。
全部を一括で直すと、かえって間違ったリンクに変えることがあります。内部リンクなのか、外部リンクなのか、本当に404なのか。そこを分けて見ていきましょう。
Search Consoleに404が出てくると、どうしても「早く直さないと」と思ってしまいます。
もちろん、壊れたリンクを放置するのはよくありません。読者がクリックした先で404になれば、その時点で読む流れが切れます。内部リンクが多いブログほど、こういう小さな破損は少しずつ効いてきます。
ただ、Search Consoleに出たURLを見て、いきなりWordPress本文を書き換えるのは危険です。404に見えても、原因はいくつかあります。単純なリンク切れもあれば、二重エンコードされたURL、リダイレクト途中のURL、Cocoonや外部メディア表示の確認画面を誤って拾っているケースもあります。
僕の場合も、最初から本番記事を直すのではなく、まずローカルで診断し、修正候補をプレビューし、それから手動で確認する流れにしました。この記事では、そのときに使った考え方を整理します。
Search Consoleの404は、まず「修正」ではなく「診断」する
Search Consoleの404一覧は、便利ですが、そのまま修正指示書として使うものではありません。
Search Consoleは「GoogleがこのURLを見つけたけれど、今は404になっている」という事実を教えてくれます。でも、そのURLがどこから発生しているのか、記事本文のリンクなのか、古いブログカードなのか、外部サイトからのリンクなのかまでは、別途確認が必要です。
なので、最初にやるべきことは、404 URLを分類することです。
- 自分のブログ内の内部リンクなのか
- 外部リンクなのか
- 本当に404なのか
- リダイレクトされているだけなのか
- URLのエンコードがおかしくなっていないか
ここを飛ばしてしまうと、直さなくていいものを直したり、直すべき場所とは違う場所を触ったりします。
内部404で最初に見るべき3つの項目
内部404を確認するとき、僕はまず3つに分けて見ます。
自サイト内リンクか、外部リンクか
まず、その404 URLが自分のブログ内のURLなのかを確認します。自サイト内のリンクであれば、記事本文やブログカード、関連記事ブロックなどが原因になっている可能性があります。
逆に外部リンクであれば、自分のWordPress本文を直すべき場合もありますが、相手サイトの削除や移転が原因のこともあります。この場合は、無理にリダイレクトで処理する話ではありません。
本当に404なのか、リダイレクトなのか
次に、HTTPステータスと最終URLを見ます。
最初のURLが404に見えても、実際にはリダイレクトされて正常ページに着地している場合があります。逆に、リダイレクトが途中で壊れていて、最終的に404になっていることもあります。
ここは感覚で判断せず、診断結果のステータスを見たほうが安全です。
二重エンコードURLではないか
今回とくに分かりやすかったのが、二重エンコードされた内部URLです。
URLの中に %25e3 のような文字が入っている場合、もともとの日本語URLがさらにエンコードされている可能性があります。こうなると、WordPress上では本来存在する記事なのに、リンクとしては404になることがあります。
実際の診断でも、元のURLは404でしたが、1回デコードしたURLは200で開ける例がありました。
http_status: 404
decoded_url_1_status: 200
suggested_fix_status: 200
fix_confidence: highこういう場合は、単純に「記事が存在しない」のではなく、「リンクURLの形が壊れている」と考えたほうが自然です。
修正前にプレビューCSVを作る
内部404を直すときに大事なのは、いきなりWordPress本文を書き換えないことです。
まずはローカルで診断して、修正候補のプレビューを作ります。たとえば、内部404候補の一覧と、デコード後URLが200で開けるかを確認したプレビューCSVを分けて見ると、かなり判断しやすくなります。
見るポイントはこのあたりです。
- 元のリンクURL
- 元のHTTPステータス
- 1回デコードしたURL
- デコード後URLのステータス
- 修正候補URL
- 修正候補の信頼度
- リンク元の記事タイトル
ここまで見てから、初めて「これは本文中のリンクを直してよさそうだ」と判断します。
二重エンコードURLを直すときの考え方
二重エンコードURLは、見た目だけだとかなり分かりにくいです。
でも、%25 が多く含まれているURLは注意して見たほうがいいです。%25 はパーセント記号そのものを表すため、もともと %e3 のようにエンコードされていた日本語URLが、さらにもう一度エンコードされている可能性があります。
この場合、1回デコードしたURLが200で開けるなら、修正候補としてはかなり有力です。
ただし、ここでも自動で一括置換するのは避けたほうがいいです。リンク先の記事が本当に文脈に合っているか、アンカーテキストとリンク先がズレていないかは、人間が確認したほうが安全です。
WordPress本番更新前に必ず確認すること
WordPressで本文を直す前に、最低限これだけは確認します。
- リンク元の記事は正しいか
- リンク先の記事は今も存在するか
- 修正候補URLはブラウザで開けるか
- リンク先の内容が本文の流れに合っているか
- クラシックエディターのテキストモードでHTMLが崩れていないか
- プレビュー画面でリンクがクリックできるか
とくに、クラシックエディターを使う場合は、ビジュアルモードとテキストモードの切り替えでHTMLが崩れることがあります。Cocoonの吹き出しやブログカードを扱う場合も、推測でHTMLを書かず、既存記事で正常に動いている形式を使ったほうが安全です。
修正後にもう一度診断する
内部404対応は、直したら終わりではありません。
修正後にもう一度ローカル診断を走らせて、同じ内部404候補が残っていないか確認します。Search Console側の反映には時間がかかることがありますが、少なくともローカル診断で同じリンクが404として残っていないかは確認できます。
今回の診断でも、ある時点では内部404候補が出ていましたが、後の実行では内部404候補ファイルがヘッダーだけになっていました。これは、少なくともその診断範囲では候補が残っていない状態として見られます。
自動化してよい部分と、人間が見るべき部分
内部404対応は、自動化できる部分と、人間が見るべき部分を分けるとかなり楽になります。
自動化してよいのは、URLの一覧化、HTTPステータス確認、デコード候補の作成、修正候補CSVの出力あたりです。ここは機械的に処理できます。
一方で、本文の流れに合っているか、読者にとって自然なリンクか、古い記事へ誘導して問題ないかは、人間が見るべきです。
つまり、AIやローカルツールに任せるのは「候補を出すところ」まで。最後に採用するかどうかは、自分で決める。この線引きがあると、WordPressの本番記事を壊しにくくなります。
関連して読んでおきたい記事
ブログ作業をAPIなしでどこまで安全に進められるかについては、ChatGPT Plusだけでブログ自動化はどこまでできるのか？APIなしで試した現実 にも書いています。
また、この記事内に出てくるクルーとオーディンについては、クルーとオーディンの問答録・・・クルーって誰 あとオーディンって誰なの？ にまとめています。
まとめ: 内部404対応は「一括修正」より「小さく確認」が安全
Search Consoleに404が出ていると、すぐ直したくなります。
でも、内部404対応で大事なのは、急いで一括修正することではありません。まず診断する。修正候補をプレビューする。1件ずつ手動確認する。WordPressのプレビューで見る。最後にもう一度診断する。
この流れにしておくと、間違ったURLへ置き換えたり、本文の流れを壊したりするリスクをかなり減らせます。
ブログのメンテナンスは、派手な作業ではありません。でも、こういう小さな404を安全に直していくことが、読者にとっても、自分の運営にとっても、あとから効いてくると思います。
