旧URLを壊さないサイト移行｜301・404・410の使い分けと確認手順

移行前に最初に作るものは何ですか？

旧URLを1行ずつ記録するURL台帳です。サイトマップだけでなく、実ファイル、データベース、内部リンク、アクセス記録など、確認できる複数の情報源から集めます。URLを漏らしたまま公開すると、本文が残っていても入口を失います。

301・404・410はどう使い分けますか？

HTTP状態の解釈は検索サービス固有の反映時間を保証するものではありません。公開後は、実際の応答と各サービスの公式な検査結果を分けて確認します。

なぜ無関係なトップへの一括転送を避けますか？

読者が求めた記事と転送先の答えが一致しないからです。見かけ上の移行率が100%になっても、内容の対応関係がなければリンク切れを隠しているだけです。代替がないURLは、明確な404または410を返す方が状態を説明できます。

公開前にどの順番で検証しますか？

1. 台帳を凍結する旧URL、処理、転送先、期待結果をレビュー可能な形式で保存する。
2. 成果物を別領域に作る途中の生成物を本番用ディレクトリへ混ぜない。
3. 内部リンクを全件確認するHTML、画像、CSSなどの参照先が成果物内にあるか検査する。
4. 転送を連鎖させない旧URLから最終URLへ一度の301で到達するようにする。
5. 本番相当でHTTPを確認する状態、Location、canonical、見出しを台帳の期待値と照合する。
6. 公開後に再確認する代表URLだけでなく、台帳の優先範囲を機械的に検査して日時を残す。

canonicalとサイトマップは何を確認しますか？

公開する各ページのcanonicalが、そのページ自身の最終URLを示すことを確認します。サイトマップには、検索対象として公開する200ページだけを載せ、転送元、404、410、noindexページを混ぜません。

• canonicalはHTTPSの最終URLで、転送を挟まない
• 末尾スラッシュの方針が内部リンクと一致する
• サイトマップのURLがすべて200を返す
• robots.txtのサイトマップURLが実在する
• 旧URLを指す内部リンクが新成果物に残っていない

Coffee Break Againでは何を検証しましたか？

旧WordPressサイトのURLを台帳化し、コーヒー記事はサブドメインの静的アーカイブへ1対1で移す設計にしました。新しい本体サイトのテーマと一致しない旧記事を、新トップへまとめて転送しない方針です。

アーカイブの扱いと閲覧上の注意は旧コーヒー記事についてにまとめています。

よくある質問