WordPress のパーマリンク変更は、単なる表示設定の変更ではありません。公開済み記事の URL を変える作業であり、旧 URL をどう守るか、検索エンジンにどう移行を伝えるか、内部リンクをどう扱うかまで含めた URL 移行です。
特に記事数が多いサイトでは、パーマリンク変更を軽く扱うと 404、検索流入の低下、内部リンク切れ、SNS や外部サイトからのリンク切れにつながります。この記事では、旧 URL を守りながら WordPress のパーマリンクを変更する手順を整理します。
移行方針
最初に決めるべきことは、新しいパーマリンク構造そのものよりも、旧 URL をどう扱うかです。既存記事にアクセスしている読者、検索エンジン、外部リンクを無視して URL を変えると、記事自体は残っていても到達できない状態になります。
| 項目 | 方針 |
|---|---|
| 旧 URL | 必ず記録し、301 リダイレクトで新 URL へ送る |
| 新 URL | カテゴリ構造、slug、将来の変更頻度を考えて決める |
| 内部リンク | 可能な範囲で新 URL へ更新する |
| サイトマップ | 変更後に再生成し、Search Console へ反映する |
| 404 監視 | 移行後しばらくログと Search Console を確認する |
変更前にバックアップする
パーマリンク変更前には、WordPress のデータベース、wp-content、リダイレクト設定、現在の記事 URL 一覧を保存します。テーマやプラグインのバックアップだけでは足りません。URL 移行では、変更前の URL 一覧が特に重要です。
- データベースバックアップ
wp-contentのバックアップ- 現在の投稿 URL 一覧
- 現在のカテゴリ URL 一覧
- 既存のリダイレクト設定
- サイトマップの現状
変更前 URL をエクスポートする
変更前の URL を一覧として保存します。後から旧 URL を復元したり、リダイレクト対応表を作ったりするためです。WP-CLI が使える場合は、投稿 ID、タイトル、slug、URL を出しておくと扱いやすくなります。
コマンド
wp post list --post_type=post --post_status=publish --fields=ID,post_title,post_name,url --format=csv > before-urls.csv
wp term list category --fields=term_id,name,slug,count --format=csv > before-categories.csv投稿 ID を含めておくと、変更後 URL と突き合わせる時に便利です。タイトルだけで対応させると、同名記事やタイトル変更でずれることがあります。
パーマリンクを変更する
WordPress 管理画面のパーマリンク設定で新しい形式に変更します。たとえばカテゴリを URL に含める場合、/%category%/%postname%/ のような構造になります。
ただし、カテゴリを URL に含める場合は注意が必要です。投稿に複数カテゴリが付いていると、どのカテゴリが URL に使われるかが不安定になる可能性があります。URL を安定させたい場合は、投稿ごとのカテゴリは原則 1 つにし、補足情報はタグで表現する方が安全です。
| 形式 | 特徴 |
|---|---|
/%postname%/ | カテゴリ変更の影響を受けにくい |
/%category%/%postname%/ | 分類が URL に出るが、カテゴリ移動の影響を受ける |
| 日付入り URL | ニュースや日記には向くが、技術記事では古さが目立つことがある |
変更後 URL をエクスポートする
パーマリンク変更後に、同じ形式で URL 一覧をエクスポートします。変更前と変更後を投稿 ID で突き合わせ、リダイレクト対応表を作ります。
コマンド
wp post list --post_type=post --post_status=publish --fields=ID,post_title,post_name,url --format=csv > after-urls.csv
wp term list category --fields=term_id,name,slug,count --format=csv > after-categories.csvここで重要なのは、URL が変わっていない記事も含めて一覧化することです。差分だけを見ると、想定外に変わった記事を見落とすことがあります。
新旧 URL 対応表を作る
変更前後の CSV を投稿 ID で結合し、旧 URL と新 URL の対応表を作ります。この対応表がリダイレクト設定の元になります。
| 列 | 内容 |
|---|---|
| ID | 投稿 ID。新旧対応の軸にする |
| title | 確認用のタイトル |
| old_url | 変更前 URL |
| new_url | 変更後 URL |
| changed | URL が変わったかどうか |
対応表を作らずに手作業でリダイレクトを登録すると、抜けや重複が起きやすくなります。大量記事サイトでは、表を作ること自体が安全策です。
301 リダイレクトを設定する
旧 URL から新 URL へは、原則として 301 リダイレクトを設定します。WordPress の Redirection プラグイン、Web サーバー設定、リバースプロキシ設定など、どこで管理するかはサイト構成によります。
WordPress 管理画面で扱うなら Redirection プラグインが分かりやすいですが、記事数が多い場合やリバースプロキシを使っている場合は、Web サーバー側で管理した方が見通しが良いこともあります。
確認すること
- 旧 URL が 301 で新 URL に向くか
- リダイレクトが 2 段、3 段になっていないか
- カテゴリ変更で意図しない URL へ飛んでいないか
- http から https へのリダイレクトと競合していないか
- 末尾スラッシュの有無で揺れていないか
リダイレクトを確認する
リダイレクト設定後は、旧 URL に対して実際に HTTP ステータスを確認します。ブラウザ表示だけでは、301 なのか 302 なのか、何段リダイレクトしているのかが分かりにくいためです。
コマンド
curl -I https://www.example.com/old-url/
curl -IL https://www.example.com/old-url/curl -I で最初の応答を確認し、curl -IL で最終的にどこへ到達するかを確認します。移行直後は、代表的な記事だけでなく、カテゴリ別に複数記事を確認した方が安全です。
Search Console とサイトマップを更新する
パーマリンク変更後は、サイトマップを再生成し、Search Console で状態を確認します。新 URL がサイトマップに入り、旧 URL が 301 で新 URL へ移る状態になっているかを見ます。
- サイトマップに新 URL が出ているか
- 旧 URL が 404 ではなく 301 になっているか
- Search Console で 404 が増えていないか
- インデックス登録済み URL が徐々に新 URL へ移っているか
- 内部リンクが旧 URL のまま大量に残っていないか
大量記事サイトでの注意点
記事数が多いサイトでは、パーマリンク変更は一括作業に見えて、実際には移行後の監視が本番です。旧 URL へのアクセス、Search Console のエラー、リダイレクト漏れ、カテゴリ移動による URL 変化をしばらく見続ける必要があります。
また、カテゴリを URL に含める場合は、カテゴリ整理とパーマリンク変更が連動します。カテゴリ名や slug を変えるたびに URL が変わる可能性があるため、カテゴリは記事分類だけでなく URL 設計の一部として扱います。
参考書籍
書籍
WordPress の管理画面、テーマ、プラグイン、運用まわりを体系的に確認したい場合の参考書籍です。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
関連する記事
サイトマップ、パーマリンク、URL 設計の関係を整理した記事です。
REST API、WAF、PHP、パーマリンクの問題を切り分ける記事です。
URL 変更後のアクセス状況や流入変化を確認するためのアクセス解析記事です。
まとめ
WordPress のパーマリンク変更は、URL の見た目を整える作業ではなく、公開済み記事の URL 移行です。旧 URL を守らないまま変更すると、検索流入、外部リンク、内部リンクに影響が出ます。
安全に進めるには、変更前 URL のエクスポート、変更後 URL のエクスポート、新旧対応表、301 リダイレクト、サイトマップ更新、Search Console と 404 ログの確認をセットで行います。
特に記事数が多いサイトでは、パーマリンク変更は一度の設定変更で終わりません。移行後にどの URL が読まれているか、どこで 404 が出ているかを見ながら、リダイレクトと内部リンクを整えていく作業になります。
関連記事
WordPress のサイトマップが生成されない原因 – パーマリンクと URL 設計を確認する
WordPress で GA4 を使う理由 – アクセス解析を記事改善に活かす
WordPress が wordpress.org に接続できない時の切り分け – DNS / Proxy / Firewall / Kubernetes を確認する
WordPress の JSON レスポンスエラーを切り分ける – REST API / WAF / PHP / パーマリンクを見る
コンテナ上の WordPress からメールが送信できない原因 – SMTP / sendmail / Postfix を切り分ける
WordPress のメール送信が遅い原因 – sendmail / Postfix / DNS の待ち時間を切り分ける
WordPress 更新後に ModSecurity が反応する理由 – WAF の偽陽性と例外設計を見る
WordPress を Kubernetes で運用する構成 – コンテナ、永続化、DB、メール、外部公開を分けて考える