soft 404を直す手順｜空のページ・表示障害・公開終了を見分ける

ページを残すべきかを先に決める

完成物は対象URL、現在の表示、HTTP応答、期待する状態、修正、再確認をまとめた表です。Googleの案内では、存在しない説明や空の本文に成功応答を返す状態がsoft 404に関わります。まず、そのURLに何があるべきかを担当者に確認します。

記事を公開終了したのか、内容が移転したのか、本当は本文があるはずなのかで対応は変わります。報告の件数を減らすため、全URLをトップへ転送する方法は取りません。

応答コードと表示された本文を比べる

通常の閲覧とURL検査で、応答コード、本文、読込み失敗を確認します。自分がログインしているときだけ本文が見える場合や、JavaScriptの実行後にエラーになる場合も分けて記録します。

例示URLを一つ直しただけで全体が直ったとは判断しません。共通テンプレート、データ取得、空の検索結果など、同じ仕組みで作られるURL群を調べます。公開前後の変更履歴も照合します。

残す・移す・終了の三つで修正する

内容を残すなら、データ取得や必要な資源を直し、十分な本文が表示されるか確認します。移転したなら、読者の目的に合う後継ページへ対応させます。内容がなく後継もないなら、適切な404または410を返す方針を選びます。

存在しないページに説明のない薄い文章を足して成功応答にするだけでは、読者の問題は解決しません。エラー用の案内ページでも、HTTP応答と画面の内容を整合させます。

対象一覧には、見出しがあるだけか、本文が途中まで出るか、エラーが表示されるかを短く記録します。これにより同じsoft 404でも、共通の取得不良と公開終了を分けやすくなります。検索結果が空のページでは、検索条件を変える案内とページの公開方針を別に考えます。新しい記事を作る場合も、そのURLで読者が必要とする情報を用意できるかを先に確認します。

記事のデータ取得に失敗した例

架空のURL記事A-071は公開中ですが、DB接続の不具合で見出しとエラー文だけが表示されるとします。記事を削除扱いにせず、接続と表示処理を調べます。修正後は匿名の閲覧者として本文が表示されるか確認します。

同じテンプレートの別記事も確認し、応答コードだけでなく本文の有無を見ます。公開終了した別URLに同じ修正を適用しないよう、期待状態を表に分けます。この例は原因の切り分け方で、実際のサイト障害ではありません。

修正表で同じ原因のURLをまとめる場合も、重要な代表例は個別に残します。例えば商品一覧が空になる問題と、記事本文が取得できない問題を一つの対応へまとめると、片方だけ直って全件完了にされることがあります。原因、対象テンプレート、確認したURLを結び、各群で再確認します。終了ページの案内を改善する場合は、役立つ関連先を置きながら、存在しないという応答を維持できるかも確認します。

再確認と検索側の状態を記録する

修正後に対象URLと代表的な関連URLを開き、応答、本文、必要な画像やスクリプトを確認します。サイトマップや内部リンクが古い公開終了URLを案内している場合は、それらも直します。

公開が直った日と検索側で再確認された日は別に記録します。レポートがすぐに変わらなくても何度も無関係な修正を重ねず、同じURLの観測を続けます。必要に応じてレポートの案内に沿って検証を進めますが、反映時期は断定しません。

全件対応を急がず影響で優先する

重要な記事や内部リンクから到達するURLを先に確認します。昔の誤入力など存在しないことが正しいURLまで、すべて記事に作り直す必要はありません。少数なら手動確認、大量なら取得結果を表にまとめて担当へ割り振ります。

費用は監査の契約だけでなく、本文やテンプレートの修正に分けます。完了条件はsoft 404の件数を一時的に減らすことではなく、残すURLに必要な内容があり、終了したURLが正しく応答し、読者への案内と一致することです。

• JavaScriptサイトのSEO点検｜初期HTMLと表示後の本文を比べる
• 公開を終える記事の統合先を決める
• 公開前後のSEO確認｜URL・検索除外・言語版を検証する