301 Moved Permanentlyは、内容が永続的に別の場所へ移ったことを示す番号です。サーバーが301とLocationという移転先の情報を返すと、ブラウザは新URLを開きます。単に本文へ「移転しました」と書くことや、クリックできるリンクを置くこととは仕組みが違います。

架空のサイトで、準備の案内を/old-guide/から/new-guide/へ変えるとします。旧URLへ来た人を、同じ準備の回答がある新URLへ案内できます。URLを変えずに本文を直すだけなら、その更新に301は必要ありません。新しい題名やカテゴリが好ましいという理由だけで、既存URLを変える必要があるかも先に考えます。

Googleは、サーバー側の永続的な転送を、永続移転を伝える方法として推奨しています。301は新URLを扱う強いシグナルですが、元の順位や売上を同じ状態で保つ保証ではありません。移転の内容、転送先の表示、クロールなども関係します。「SEOを保つコード」を貼るだけで全て終わると扱わないでください。

この章の根拠：出典1出典2出典3

301と302の違いを、効果が強い・弱いだけで選ばないでください。301は永続的な移転、302は一時的な移動を示します。Googleの説明でも、永続か一時かによって古いURLを扱う意味が変わります。例えば一時的に別の案内を見せる場面と、古い記事を新しい記事へまとめた場面を区別します。

同じ役割の内容が移転先にないなら、全てのURLをホームへ転送する判断は適切とは限りません。Googleは関連性の低い一つのURLへの大量の転送を避けるよう説明しています。削除し、代わりの内容がないURLでは、404や410などの扱いを検討します。一方、複数の回答を実際に一つへ統合したなら、その統合後のページが転送先候補になります。

POST（入力などのデータをサーバーへ送る要求）で送信するフォームやAPI（プログラム同士が情報や処理をやり取りする窓口）では、301によって次の要求がGET（ページなどの内容を取得する要求）へ変わる場合があります。MDNはメソッドを保つ308との違いを説明しています。本稿の試し例は、普通のページを読むGETだけです。入力や決済を送るURLへ、そのまま同じ設定を適用しないでください。必要な要求の種類と現在の仕組みを担当へ確認します。

この章の根拠：出典2出典4出典1

対応表には、旧URL、新URL、旧ページの役割、同じ役割が残るか、期待する応答を書きます。記事だけでなく、画像やPDFのURLが変わる移転なら、その参照先も対象にします。見た目が似たページを行き先にするのではなく、旧URLを開く人が必要な答えを得られるかを確認します。

新URLを先に開き、200で返るか、必要な本文があるか、公開を妨げる設定が残っていないかを見ます。新URLがさらに別のURLへ転送されるなら、最終のURLを転送先にするほうが分かりやすくなります。旧→中間→新の連続転送や、新→旧へ戻るループを対応表で見つけます。

Googleのサイト移転の資料は、旧新のマッピングと最終の行き先への直接転送を説明しています。本稿の表は、その準備を一つの移転でも確認するための提案です。全部のURLを正規表現で一括転送する方法は、同じパス構造が保たれるかなど別の条件が必要です。少ないURLの移転なら、一対ずつ確認できる表から始められます。

この章の根拠：出典4

次の見本はPython 3を使える環境で、転送の応答を理解するためのものです。新しい空のフォルダーへserver.pyとして保存し、ターミナルでそのフォルダーに移動してpython3 server.pyを実行します。ブラウザでhttp://127.0.0.1:8769/old-guide/を開くと、新しい準備案内へ移動します。外部へ公開するコードではありません。

ChromeのNetworkを先に開き、ログを残す設定を使ってから旧URLを開きます。旧URLの行は301、HeadersのLocationは/new-guide/、新URLの行は200になるかを見ます。ブラウザの最終アドレスだけでは、途中が301か302かを判断できません。期待する順序と番号を記録します。

127.0.0.1は自分のパソコンです。同じポートが使用中なら別のポートへ変え、他のアプリを止めないでください。確認後はターミナルでCtrl+Cを押して終了します。この見本はGETの一対だけを扱い、WordPressやApache、CDN（複数の配信拠点を使って、画像やページなどを読者へ届ける仕組み）の転送設定は含みません。見本の結果を本番の転送の確認済み記録と扱わないでください。

この章の根拠：出典1出典5

転送は、サーバー、CMS（文章や画像を管理画面から更新する仕組み）のプラグイン、CDNやホスティングの設定など、複数の場所で動くことがあります。既にあるルールへ別のルールを重ねると、往復や連続転送になる場合があります。まず現在の設定場所と管理担当を確認します。Apacheの.htaccessは、その環境で許可されている場合の選択で、全てのサーバーで使えるものではありません。

変更前に、設定の内容と、サイトの復旧に必要な保存を確認します。CMSを使う場合には、原稿ファイルだけでなくデータベースやサイトファイルも関係します。試し環境で旧URL、新URL、転送対象外の正常URLを確認してから、本番の作業範囲を決めます。サイト全体が表示されない場合に、誰がどの保存へ戻すかも決めます。

Googleはサイト移転で、転送をできるだけ長く、一般的には一年以上維持すると説明しています。検索の処理だけでなく、古いリンクを使う人もいるためです。サイト内のリンクとサイトマップは新URLへ直し、転送があるから古い参照を残してよいと扱わないでください。期間は実際の契約と管理体制で維持できるかを確認します。

この章の根拠：出典6出典4出典7

対応表の完成は、コードを貼ることではありません。旧URLから期待した新URLへ直接進み、同じ役割の本文を読めることを確認した状態です。実測していない欄は未確認と残します。内容を削除したURLや、フォームの送信を扱うURLは、同じ301の見本に一括で含めないでください。

反映後に想定外の行き先へ進む場合は、表と実際のLocationを比較します。旧新が往復するなら両側のルール、途中で別のURLへ進むならサーバーやCMSなどの設定を確認します。古い転送をブラウザや配信のキャッシュが覚えている場合もあるため、別の確認方法と記録を担当へ渡します。

本稿のローカル見本は、301とLocationの仕組みを確かめるためのものです。本番での適用は、WordPressやサーバーの環境に合う方法で行います。対応表、変更前の保存、試し環境の結果をそろえ、必要な設定を一つずつ確認してください。順位が同じに戻ると約束せず、移転と検索の記録を別に見ます。

この章の根拠：出典2出典4出典5