公開済みWordPress記事のURLは変えてよい？｜変更前の判断と転送確認表

01．タイトル変更・1記事の変更・全体変更を分ける

パーマリンクは記事などの恒久的なURLで、スラッグはURLに使われる記事名部分を指します。 WordPressでは、個別記事のスラッグと、サイト全体のパーマリンク構造を分けて扱います。 仕組みはWordPress公式のパーマリンク解説でも確認できます。

編集部では、見た目を短くすることや検索キーワードを足すことだけを理由に、公開済みURLを変えることは勧めていません。 転送や内部リンクの保守が増える一方、変更だけで順位が上がるとはいえないためです。 タイトルを直すたびにスラッグまで合わせる必要はありません。

たとえば日付入りの構造を投稿名だけに変えると、複数の記事URLが変わり得ます。 カテゴリーやアーカイブの経路も含め、影響範囲を確かめてください。 「1記事を直したい」という理由で、管理画面の全体設定を切り替えるのは避けましょう。

02．保存前に旧URLと変更理由を記録する

URLを変える場合は、対象ごとに次の表をコピーして記入します。 旧URLは編集後に思い出すのではなく、現在の公開ページから控えてください。 過去にもURLを変えたことがあれば、その旧URLも分かる範囲で別行に追加します。

バックアップは保存済みという表示だけで判断せず、記事データや関連設定をどこまで戻せるか確認します。 準備が曖昧なら、先にWordPressのバックアップで復元できる範囲を確認する手順を使ってください。 バックアップがあっても、転送確認を省略できるわけではありません。

記入例1：タイトルだけを改善する

以下の3例は説明用の架空例で、実際の移行・計測結果ではありません。 example.comは説明用のドメインです。

「ブログ準備メモ」を「ブログ開設前に用意するもの」に改題する例です。 旧URLがhttps://example.com/blog-preparation/なら、内容とのずれは小さいと判断し、URLはそのままにします。 対応メモには「タイトルのみ変更、転送は対象外、公開URLが変わらないことを保存後に確認」と記入します。

記入例2：内容と異なる1記事のURLを直す

バックアップの解説なのに、誤ってテーマ選びを意味するhttps://example.com/theme-choice/で公開した例です。 必要性を検討したうえで、https://example.com/backup-guide/へ移す計画を立てます。 旧→新の組み合わせ、転送設定の担当、関連記事の修正箇所を記録し、実施前の転送結果欄は「未確認」のままにします。

記入例3：サイト全体から日付を外したい

https://example.com/2025/08/blog-preparation/をhttps://example.com/blog-preparation/の形式にそろえたい例です。 同じ変更が他の記事にも及ぶため、1記事の対応メモだけでは準備不足です。 対象一覧と転送計画ができるまで「変更保留」とし、必要なら利用サーバーのサポートや保守担当に影響範囲を確認します。

03．変更が必要な場合の確認順序

変更を行うのは、対応メモが埋まり、現在の環境で転送を設定する方法が分かった後です。 WordPressが自動で転送してくれるはず、という前提にはしません。 個別スラッグ、全体構造、過去の変更履歴、プラグインやサーバーの設定によって確認対象が変わります。

1. 現在の状態を残す。旧URLで記事が開くことと、バックアップ・復元手段を確認します。
2. 新しい行き先と転送方法を準備する。旧ページを探す読者が必要な内容へ着くよう、対応を決めます。記事のスラッグ変更だけなら「WordPressアドレス」「サイトアドレス」を変更する作業ではありません。
3. URL変更と必要な転送を実施する。設定箇所や適用順序は利用環境の公式手順に従います。別の設定例をそのまま貼る前に、既存の転送ルールとの重複を確認してください。
4. 自分で直せるリンクを新URLへ更新する。関連記事、メニュー、カードなどを確認します。サイトマップやcanonicalの出力も、新しい行き先と合っているか調べます。
5. 旧URLからの経路と、新ページの表示を別々に確認する。旧URLから到着できるかだけでなく、応答コード、転送先、本文・表・リンクを記録します。

恒久的にURLを移す場合、Googleは可能ならサーバー側の恒久的リダイレクトを推奨しています。 301と308は恒久移動を示す応答コードです。 一時的な転送とは目的が違うため、Google公式のリダイレクトの説明と利用環境の手順を照合してください。

04．転送確認表で「完了」と「未確認」を分ける

下の表は確認の基準です。 結果欄には想定値を写すのではなく、確認した日時と実際の値を記入します。 画面が開いただけで301だったと推測せず、見ていない項目は「未確認」と残してください。

応答コードは、ブラウザーの開発者ツールのNetwork（ネットワーク）など、HTTP応答を確認できる方法で調べます。 Networkを開いてから旧URLを読み込み、必要に応じてログを保持する設定を使います。 旧URLへのリクエストと最終ページのリクエストを区別し、Statusと転送先のLocationを確認してください。 操作に慣れていなければ、旧・新URLの対応表を添えて保守担当に確認を依頼する方法もあります。

canonicalは検索エンジンに伝える正規URLの指定、noindexは検索結果への登録を除外する指示です。 これらの確認と、Googleが実際に新URLを登録したかの確認は別です。 編集部では保守しやすさから最終URLへ直接転送する形を勧めますが、途中の転送が1つあれば直ちに失敗と決めつけるものではありません。

05．404・トップページへの転送・ループが出たら

想定と違う結果が出たら、追加のURL変更を止め、対応メモと実際の行き先を照合します。 新URL自体が開かないのか、旧URLからの転送だけが失敗しているのかを切り分けてください。

• 新URLが404になる：公開状態、URLの入力、変更したスラッグが保存されたかを確認します。
• 関係のないトップページへ着く：個別の転送先と広範囲のルールが競合していないか確認します。404を隠す目的で一律にトップへ転送するのは避けます。
• 旧URLと新URLを往復する：転送ループの可能性があります。複数の設定場所を確認し、分からないルールを重ねて追加しないでください。

設定の影響範囲が分からなければ、利用サーバーやツールのサポートに状況を伝えます。 バックアップへの復元は、変更後の記事更新や注文なども巻き戻す可能性があります。 問題の切り分けをせずにサイト全体のデータベースを戻すことは避けましょう。

06．検索結果の変化は、転送とは別に追う

転送が動いていても、検索結果のURLや表示がすぐに切り替わるとは限りません。 変更日を控え、Search Consoleで旧・新それぞれのURLを確認します。 登録状態の読み分けはブログがGoogle検索に出ないときの診断表で整理できます。

GoogleのURL変更を伴うサイト移行のガイドは、対応表、内部リンクや正規URLの更新、転送確認を案内しています。 同ガイドでは移行時のリダイレクトを一般に少なくとも1年維持するよう勧めています。 これはサイト移行の案内であり、1記事の変更後ちょうど1年で削除してよいという意味ではありません。

検索結果に新URLが出たことだけを理由に転送を外すと、古いリンクを使う読者が記事へ着けなくなります。 外部リンクやブックマークからの利用も考えて維持を判断してください。 検索への反映日や順位の維持・上昇は保証できません。

07．変更しない判断も、記録して終える

まず「タイトル・本文のみ」「1記事のURL」「サイト全体の構造」のどれかを決めます。 URLを維持できるならそのまま改善し、変更が必要なら旧→新の対応と確認結果を残しましょう。 全体変更の対象や戻し方が分からない場合は、準備が整うまで保留するのが現実的です。

公開前の設定全般を見直したい場合は、WordPress初期設定のよくある質問へ進んでください。 公開済みの記事では、設定をそろえることより、今ある読者の経路を保つことを優先します。