HTTP 410はURLを早く消すために使わず戻さない削除だと決めたpageに使う

HTTP 410は、そのURLのresourceがorigin serverで利用できなくなり、その状態が恒久的である可能性が高いとserverが判断して返すresponseです。検索結果から早く消したい、404 pageを見せたくないという理由だけで使いません。URLを別のpageへ移したのか、しばらく戻す可能性があるのか、もう同じ役割のpageを出さないのかを決めてから、301、404、410を分けます。

RFC 7231は、410 Goneをtarget resourceが利用できず、その状態が恒久的である可能性が高いことを示すstatus codeとして定義しています。serverが恒久的かどうかを知らない、または判断できない場合には404 Not Foundを使うべきだとしています。410は、削除したURLを外部のlink元から取り除く作業を助ける意図を持ちます。削除の理由を読者へ説明するpageの代わりではありません。

URLを移す場合と削除する場合を先に分ける

古いURLを見つけたとき、最初に考えるのは「新しいURLがあるか」です。商品やserviceの説明を別のURLへ移したなら、古いURLから対応する新しいURLへ301 redirectします。読者が古いlinkを開いても、近い内容へ進めるためです。top pageや無関係なcategory pageへ一律に送ると、読者が探した情報を見つけにくくなります。

同じ役割を持つ新しいpageがなく、今後も出す予定がないなら、404または410が候補になります。たとえば、終了した期間限定の企画、退職した人だけの紹介page、廃止したserviceの申込みpageです。ただし、終了したserviceについて既存顧客への案内、後継service、問い合わせ先を示す必要がある場合もあります。URLを消すことと、必要な案内を消すことを同じ作業にしません。

説明用の仮例として、2016年だけ受け付けた講座の申込みpageを考えます。翌年に同じ講座を開かず、申込みを再開する予定もなく、内容を引き継ぐpageもないなら、410を返す判断が候補です。一方で、同じ主題の新しい講座へ内容を更新して案内するなら、古いURLから新しい講座pageへ301 redirectします。来年も再開する可能性がある、終了の案内をしばらく表示したいなら、404や通常の案内pageを含めて判断します。

表はserverの設定だけを決めるものではありません。URLの状態を事業側が決め、技術側がそれに合うresponseを返すためのものです。制作会社へ「古いpageを消して」と依頼するだけでは、301が必要か、404か410か、imageやPDFも削除するか、外部からのlinkをどうするかが分かりません。

410を検索結果を消すための近道にしない

Googleの公式Q&Aは、削除したcontentに対応するpageがない場合は404または410を返すよう案内し、Googleは404と410を同じように扱うと説明しています。410を使えば検索結果から必ず早く消える、順位への影響が小さい、といった約束にはなりません。検索の処理時間を目的にstatus codeを選ばず、URLの実際の状態を返します。

検索結果に古いURLが残っているときは、まずそのURLを実際に開きます。画面に「ページがありません」と出ていても、HTTP responseが200 OKなら、削除を伝えていません。逆に410を返していても、site内のmenu、記事、サイトマップが古いURLへlinkしていれば、削除した判断とsite内の案内が食い違います。画面の文言、status code、内部link、XML sitemapを別に確認します。

404や410を返すURLを、robots.txtで先にblockすることも慎重に考えます。検索engineがresponseを取得できなければ、URLが削除済みであることを確認しにくくなります。URLを非公開にしたい事情と、削除した状態を返す事情は別です。重要な個人情報や契約上の問題がある場合は、status codeだけで判断せず、公開範囲、server側のアクセス制御、連絡窓口を確認します。

410 responseはcacheable by defaultでもあります。削除を取り消して同じURLへcontentを戻す可能性があるなら、410を軽く使いません。一度410を返したURLをすぐ復活させると、browserやcacheが古い状態を持つ場合があります。削除を決める前に、復活させる可能性、保管する原稿や画像、戻す担当者を確認します。

WordPressでは削除画面とHTTP responseを別に確認する

WordPressで投稿をゴミ箱へ入れた、固定pageを非公開にした、menuから外したことと、公開URLがどのresponseを返すかは同じではありません。permalink設定、themeの404 template、redirect plugin、hostingの設定によって結果が変わります。管理画面だけで削除済みと判断せず、loginしていない状態で古いURLを開き、response headerを確認します。

410を返す設定をthemeやpluginへ追加する場合は、対象のURL規則を狭くします。たとえば、終了した講座のURLだけを対象にするなら、どのslug、どの年、どのpageが対象かを記録します。存在しないURLを一律に410へすると、入力間違いのURL、移行漏れ、server障害のように原因が分からないものまで恒久削除として扱います。

終了した記事や商品を整理するときは、本文中のlink、関連記事、category page、site map、広告のlanding pageも見ます。古いURLが必要な案内からlinkされているなら、410だけ返しても読者は行き止まりになります。新しい案内があるならlinkを替え、完全に不要ならlinkを外します。URLのresponseを変える作業と、site内の案内を直す作業を一緒に進めます。

外部からのlinkは自分だけでは直せません。RFC 7231は410が外部のlink元へresourceを取り除く意図を伝える助けになることを示しています。けれども、外部siteの管理者がlinkをいつ外すかは別の判断です。重要な取引先や案内先に古いURLがあるなら、必要に応じて新URLや終了の連絡先を伝えます。status codeが外部の運用を自動で直すものではありません。

削除後は代表URLではなく対象一覧で確認する

一つのURLだけで試して設定を広げると、違うpageまで410になることがあります。削除するURLの一覧、301へ送るURLの一覧、404のままにするURLの一覧を作ります。各URLについて、旧URL、対応する新URLの有無、理由、設定したresponse、確認者を残します。

確認では、browserの画面だけでなくHTTP responseを見ることが必要です。410 pageにtop pageへのlinkや検索欄を置くことはできますが、本文の見た目が親切でもresponseが200なら410ではありません。反対に410を返していても、重要な誤案内が残っていないかは画面で見ます。status codeと読者向けの案内を別々に確認します。

削除した直後に全ての外部表示が消えると期待しません。site側でできるのは、実際のURL状態を返し、内部linkとサイトマップをそろえ、必要な案内を残すことです。検索結果や外部siteの反映は、site側の変更とは別の時刻に起こります。削除作業を急ぐほど、URLの移転先と必要な案内を先に決めます。

最初の一手は、削除したいURLを一つ選び、対応する新pageがあるか、再開する予定があるか、外部へ案内を残す必要があるかを書き出すことです。その答えに応じて301、404、410を選び、公開画面とHTTP responseの両方を確認します。