2000年に初めて登録されたドメインを購入しました。長い運用歴だけを見れば、むしろ魅力的に見えます。ところが新しいサイトを公開すると、私が一度も作っていないページへのリクエストでサーバーログが埋まり始めました。
新しいプロジェクトには存在しないURLに、1日1,000件を超えるリクエストが届いていました。アクセス解析では、ほとんどエンゲージメントのない大きなダイレクトトラフィックの急増として見えていました。同じ時期にYandexのクローラーも古いパスを再訪し、404 Not Foundを受け取っており、Yandex Webmasterには一晩で900件を超えるエラーが積み上がりました。
最初は「古いボットが死んだURLを叩く。その活動をYandexが見ている。だからYandexも繰り返しクロールする」と考えていました。私から見えた時系列だけなら、確かにそう見えます。ただし、これは私のデータで証明できる範囲を超えた因果関係です。
実際に確認できたこと
確認できたのは、別々の3つの事実です。1つ目は、ドメインの過去に由来するURLへ大量のリクエストが来ていたこと。2つ目は、それが実質的なユーザーエンゲージメントにつながっていなかったこと。3つ目は、Yandexのクローラーも古いパスへアクセスし、Webmasterに一晩で900件超のエラーが記録されたことです。
運用上は十分に問題でした。ログはノイズだらけになり、不要なリクエストが増え、Webmasterのレポートも整理が必要になります。しかし、これだけでは外部ボットがYandexのクロールを引き起こしたとは証明できませんし、エラーそのものが検索順位やオーガニックトラフィックを直接下げたとも言えません。クロールとインデックスは別物で、インデックスとランキングも別物です。エラーレポートはペナルティの証拠ではありません。
私が単純化しすぎていた404と410の違い
以前は「404は今だけ見つからない、410は永久に消えた」という理解で考えていました。直感的な説明としては分かりやすいのですが、HTTPの意味としては正確ではありません。
404 Not Foundは、サーバーが要求されたリソースの現在の表現を提供できないことを示します。それだけでは、一時的か恒久的かまでは示しません。410 Goneはより具体的で、そのリソースがもはや利用できず、その状態が恒久的だとサーバー側で分かっている場合に適したステータスです。
SEOについても同じ注意が必要です。検索エンジンは404でも410でも、削除されたURLを検索結果から外すことができます。ですから今の私は、410を「404より強いSEOステータス」とは呼びませんし、削除済みページに404を返すこと自体が間違いだとも考えていません。
それでも私のケースでは限定的な410が妥当だった理由
今回の古いパスは一時的な障害ではありませんでした。ドメインの以前のコンテンツに属するURLで、新しいサイトには対応するページがありません。少なくとも対象にしたURLについては、永久に戻さないと分かっていました。だから410 Goneが状態を最も正確に表していました。
そこで、未知のURLをすべて410にするのではなく、把握できているレガシーパスだけに限定して410を返すようにしました。その変更後、古いパスをめぐるクロールとレポートのノイズは収まり、Webmaster側の状況もかなり整理されました。
ただし因果関係は慎重に扱っています。「限定的な410の導入後に改善した」「そのURLの状態を410が正しく表していた」とは言えます。一方で、410だけですべてのボットが止まったと証明することはできません。第三者のボットはHTTPステータスの意味を無視し、同じURLへ延々とアクセスし続けることもできます。
今使っている判断基準
大事なのは「410は404より良いか」ではなく、「そのURLに実際に何が起きたか」です。
- 明確な移転先がある：本当に同等の新URLへ
301などの恒久リダイレクトを使う。 - リソースが恒久的に削除され、代替もないと分かっている：
410 Goneは意味の正確な選択肢になる。 - 単なる未知のURL、タイプミス、もともと存在しないURL：通常の
404 Not Foundでよい。
逆に、エラー表示を消したいだけで、すべての死んだURLをトップページへリダイレクトするのは避けます。リソースの本当の状態を隠し、ユーザーにもクローラーにも分かりにくい挙動になるからです。
今なら履歴のあるドメインを公開前にどう監査するか
もう一度履歴のあるドメインを使うなら、旧サイト自体を移行しなくても、過去のURL履歴を移行作業の一部として扱います。
- 過去のURLの痕跡を調べる。 公開前に履歴上のURLや明らかな旧セクションを洗い出す。
- 初日からアクセスログを見る。 自分が作っていないパスへの反復リクエストは、そのドメインが外部にまだ記憶されていることを示す。
- 人間、検索クローラー、その他のボットを分ける。 ダイレクトトラフィックの急増とクローラーエラーは別のシグナルであり、1つの因果関係にまとめない。
- 繰り返し現れる死んだURLを分類する。 重要なパターンごとに301、404、410のどれが正しいか決める。
- 結果を別々に監視する。 リクエスト頻度、クローラーレポート、インデックス状況を分けて見て、「SEOの健全性」という1つの曖昧な指標にしない。
ログやWebmasterがノイズで埋まってから原因を追うより、公開前後にこの確認をする方がずっと小さなコストで済みます。
410では解決できないこと
410は、あるリソースの状態を伝えるHTTPレスポンスです。ファイアウォールでも、レート制限でも、ボット遮断機能でもありません。スクレイパーが410を受け取った後もリクエストを送り続ければ、サーバーはそのリクエストを受けて応答する必要があります。問題の本体が過剰なリクエスト量なら、それは別のインフラ対策が必要です。
また、410はSEOを押し上げる仕組みでもありません。正しいステータスはクローラーにURLの状態を伝える助けになりますが、それだけで新しいサイトの順位が上がるわけではありません。
この経験から残ったルール
驚いたのは、古いドメインに古いURLがあったことではありません。その見えない履歴が、公開後すぐにどれほど強く表面化したかです。存在しないページへ1日1,000件超、ほぼゼロのエンゲージメント、そしてYandex Webmasterには一晩で900件超のエラー。
履歴のあるドメインは、空の名前空間ではありません。元のコンテンツが消えてから何年経っても、古いリンク、クローラー、スクリプト、ボットはパスを覚えていることがあります。今の私のルールは単純です。履歴を監査し、現実に合ったHTTPステータスを返し、運用上のボットトラフィックと検索エンジンについての推測を混同しない。
履歴は資産になり得ます。同時に、引き継ぐ状態でもあります。