先に結論
404は単発なら正常な応答ですが、移行・デプロイ直後に増えた場合は検索流入や購入導線を失います。流入元、旧URL、ルーティング、実際のHTTP statusを確認し、復元・関連先への転送・404／410維持を選びます。
404のURLと流入元を固定する
- 404 URL、発生時刻、Referer、検索クエリ、端末、実際のHTTP statusを保存する。
- アクセスログとSearch Consoleで、件数・クリック・被リンクが多いURLを優先する。
- 直前のURL変更、CMS移行、デプロイ、ルーティング、大小文字、末尾スラッシュを確認する。
- 内部リンク、sitemap、canonical、外部被リンクの旧URLを区別する。
- 代替内容が同等かを確認し、復元・1対1転送・404／410維持を選ぶ。
結論：重要な旧URLに同等の移行先があれば1対1で転送し、誤った内部リンクとsitemapを修正します。代替がなければ無関係なトップへ飛ばさず404または410を返します。
URLごとに対応を選ぶ
| 状態 | 推奨対応 | 確認 |
|---|---|---|
| デプロイ漏れ・一時欠落 | 正規ページを復元 | release artifact、route、権限、CDN purge |
| 同等ページへ恒久移行 | 301／308で1対1転送 | 転送先200、loopなし、canonical一致 |
| 削除・代替なし | 404または410 | 内部リンク・sitemapから除外 |
| 大量の架空URL | 404維持 | bot、脆弱性探索、ログ容量、WAF |
| 本文はNot Found・status 200 | 404／410へ修正 | soft 404、キャッシュ、SSR fallback |
| アクセス拒否が目的 | 404へ偽装せず設計確認 | 403・認証・WAFを確認 |
soft 404を見逃さない
正常なテンプレートで「該当なし」を表示し、HTTP 200を返すと、検索エンジンはsoft 404として扱う場合があります。ブラウザ表示だけでなく、レスポンスstatus、canonical、robots、本文、構造化データを確認します。空の商品一覧や検索結果ゼロをすべて404にせず、ページの目的と再利用性で設計します。
移行時は旧新URL表を正本にする
- アクセス・被リンク・検索クリックのある旧URLを一覧化する。
- 同等内容の新URLを1対1で対応させる。
- 内部リンク、canonical、hreflang、sitemapを新URLへ統一する。
- 転送チェーンとループを検査し、旧URL→最終200を一段にする。
- 公開後は404件数、Googlebot、主要ランディングのクリックを継続監視する。
避ける操作
- すべての404をトップページへ一括転送する。
- 見つからないページにHTTP 200を返してsoft 404を増やす。
- 旧URLをsitemapへ残したまま、新URLも重複登録する。
- 大文字小文字・末尾スラッシュ・パラメータ差を無制限に別URL化する。
- アクセスログを確認せず、検索流入のあるページを削除する。
公式情報
よくある質問
404はすべて301リダイレクトすべきですか？
いいえ。代替ページが明確な時だけ関連先へ301または308を検討します。無関係なトップへ一括転送すると、利用者を迷わせ、Googleにはsoft 404として扱われる可能性があります。
存在しないページは404と410のどちらですか？
一時的な欠落や不明なURLは404、意図的に削除して戻さないことが明確なら410が候補です。重要URLの移行では、代替URL、被リンク、内部リンク、sitemapを先に確認します。
見た目は404なのにHTTP 200です
本文で『見つかりません』と表示しながら200を返すsoft 404候補です。存在しないURLには実際の404または410を返し、正常ページだけ200にします。