WordPressのパーマリンク設定|初期設計・変更手順と404の確認方法
※本記事にはPRを含む場合があります。
こんにちは。『脱会社員』脱サラを応援し続けるブログ、運営者の『なかびー』です。
WordPressのパーマリンクは、最初に形を決めて、公開後はできるだけ同じURLを使い続けるのが基本です。これから記事を公開するサイトなら、内容を表す短いスラッグを付けた「投稿名」が扱いやすい選択肢になります。一方、すでに記事が読まれているサイトでは、「投稿名の方がよいと聞いた」という理由だけで全URLを変更する必要はありません。
困りやすいのは、サイト全体のURL構造と、記事ごとのスラッグを同じ設定だと思ってしまうことです。さらに、変更した後に新URLだけを開いて満足すると、SNSや他サイトに残った古いリンクから読者が来られない問題を見落とします。変更をするなら、設定画面の操作より先に、旧URLと新URLの対応、転送方法、確認範囲を決めましょう。
この記事では、独自サーバーで運営する一般的なWordPressサイトを想定し、初期設定と公開済みURLの変更を分けて説明します。画面名はWordPressの版、権限、テーマ、プラグインによって異なる場合があります。WordPress.comの契約プランや独自の管理画面を使う場合は、そのサービスの案内も確認してください。
本文内の画像は理解を助けるための生成イメージです。実際の管理画面や特定サービスの操作画面を再現したものではありません。URL例は説明用の架空例であり、そのまま自分のサイトに登録するものではありません。
WordPressのパーマリンクとは|設定を触る前に変更範囲を分ける

URL全体とスラッグは同じものではない
パーマリンクは、投稿や固定ページなどへアクセスするための継続的なURLです。たとえば https://example.com/blog-start/ なら、example.com がドメイン、blog-start がこの記事を識別するスラッグに当たります。サイトによっては、この間に日付やカテゴリー、archivesなどが入ります。スラッグだけを見て、最終URLも必ず同じ形になると考えないことが大切です。
WordPressの「設定」から開くパーマリンク画面は、主に投稿のURLに共通する形を決める場所です。記事の編集画面にあるスラッグの欄は、その記事固有の語句を決める場所です。たとえば全体が /archives/%post_id% の構造なら、投稿名スラッグを直しても、その語句が公開URLに現れるとは限りません。まず現在の設定と、実際に開ける投稿URLをセットで見ます。
固定ページでは親子関係がURLに反映されることがあり、商品などのカスタム投稿には追加機能独自の設定がある場合もあります。「投稿で成功した方法をすべてのURLに一括適用する」のは避けましょう。今回変えたいものが通常の投稿、固定ページ、カテゴリー一覧、商品ページのどれかを最初に書き出すと、触る場所を絞れます。
基本の考え方と構造タグは、WordPress公式のパーマリンク解説で確認できます。ここで押さえたいのは、投稿名、日付、IDなどを使って構造を作れることと、公開URLは長く維持する前提だという点です。
新規設定・一記事の変更・全体変更で難しさが違う
まだ誰にも共有していない新規サイトでURL形式を決める作業と、何年も運営したサイトのURLを変える作業は、同じボタンを使っても影響が違います。公開前なら修正対象は比較的少なく済みますが、公開後には他サイトのリンク、ブックマーク、メール、印刷物のQRコードなど、自分だけでは書き換えられない入口が増えます。
「記事は三本だけだから大丈夫」と本数だけで判断するのも不十分です。一記事でもSNSで広く共有されていたり、取引先の案内に使われていたりすれば、旧URLの維持は重要です。逆に、長く運営しているサイトでも、今回の作業が未公開の下書き一件のスラッグ修正なら、サイト全体のURL変更は必要ありません。
※表は横にスクロールできます。
| 状況 | 先に確認すること | 基本の進め方 | 見落としやすい点 |
|---|---|---|---|
| 公開前の新規サイト | 共有済みURLやテスト公開の有無 | 共通構造を決め、記事ごとにスラッグを確認 | テスト記事のURLも外部に残ることがある |
| 未公開の下書き一件 | 予約・共有プレビューとの関係 | その記事のスラッグだけを編集 | 全体設定を変える必要は通常ない |
| 公開済みの記事一件 | 旧URL、流入、リンク元、変更理由 | 一対一の対応を用意し、転送と動作を確認 | 自動転送に任せきりにしない |
| 全投稿の構造変更 | 全URL一覧、例外、運用停止の影響 | 事前検証と復旧計画を作って実施 | カテゴリーページや固定ページは別範囲 |
| サーバーだけの移転 | 移転前後でURLが同じか | URLを維持できる方法を優先 | サーバー変更とURL変更を混ぜない |
この表は、当ブログが作成した作業の振り分け例です。複雑な会員サイトや通販サイトでは、注文、ログイン、決済なども関係します。ブログ記事だけの説明で本番の設定を変えず、保守担当者へ変更範囲を相談してください。
SEOのためだけに既存URLを変えるべきか
読みやすいURLは管理や共有に役立ちますが、投稿名へ変更すれば検索順位が上がるという保証はありません。URLを整えることと、記事の内容を改善することは別の作業です。現在の記事が検索されない理由を確認せずにURLだけ変更すると、解決したかった問題が残るうえ、転送の保守まで増える可能性があります。
変更の判断は、「今のURLでは何に困っているか」から始めます。たとえば誤って個人情報を含めた、サイト統合でURLを整理する必要がある、長く維持できない分類が入っている、といった事情があるなら、変更の便益と作業の負担を比較します。単に見た目を英語にしたい程度なら、今後の新規記事から命名ルールをそろえる方法もあります。
GoogleのURL構造に関する案内では、理解しやすいURLや、単語を区切るハイフンなどが紹介されています。ただし、これは既存サイトを無計画に改名するよう勧めるものではありません。自分のサイトで変更する必要があるかどうかは、読者への影響まで含めて考えましょう。
作業対象外もメモすると事故が減る
「この記事のスラッグだけを変える。ドメイン、HTTPS、末尾スラッシュ、カテゴリーは変えない」のように、変更しないものも書いておきます。途中で関連設定が気になっても、今回の目的と切り分けられます。問題が起きた場合も、直前に変えたものが一つなら、原因を説明しやすくなります。
実際の作業前には管理画面の設定値を画像やメモで残し、対象記事のタイトル、ID、旧URL、公開状態を控えます。URLは手入力で再現せず、公開ページからコピーする方が取り違えを減らせます。長い日本語URLでは表示上の文字列とコピーした符号化された文字列が違って見えることもあるため、どちらかを勝手に削ったり短縮したりしないでください。
新規サイトのパーマリンク設定|投稿名とスラッグを実際のURLで確認する

初めて決めるなら維持しやすい構造から選ぶ
更新型の解説ブログでは、投稿名を使い、記事の内容を短い語句で表す方法が管理しやすい選択肢です。日付をURLへ入れなければ、記事を更新したときもURL内の日付を気にしなくて済みます。カテゴリー名を入れなければ、後から記事の分類を見直した際に、分類とURLの関係を調べる負担を減らせます。
ただし、日付やIDを使う方式が一律に間違いというわけではありません。ニュースの記録、既存システムとの連携、長く運用してきた命名規則など、維持する理由があるサイトもあります。自分が迷わず管理でき、今後も変えずに使える形式を優先してください。「どれが最強か」より、「この形式を続けると何を管理する必要があるか」で考えると選びやすくなります。
カスタム構造を使う場合は、画面にある構造タグの意味を理解してから組み合わせます。ドメインを欄へ貼り付けたり、他サイトの公開URLをそのまま入力したりする場所ではありません。特別な目的がなければ、既存の選択肢で足りるかを先に検討しましょう。
管理画面で保存した後は新規投稿の完成URLを見る
一般的な管理画面では「設定」から「パーマリンク」を開き、現在の選択肢を記録したうえで希望の構造を選び、変更を保存します。権限によっては設定画面が表示されません。メニューが見つからないからといって、権限変更用の追加機能を入れるのではなく、管理者へ確認してください。
保存したら、新規記事の編集画面でスラッグを確認します。画面右側の設定や概要、リンクに関する項目に表示されることがありますが、名称や場所は版によって異なります。記事タイトルを入力するとスラッグ候補が生成されることがあります。自動で出た値をそのまま使う前に、不要な記号や長すぎる語句が含まれていないかを見ましょう。
保存成功の表示だけで終えず、想定する公開URLを確認します。下書きのプレビューURLは、公開後の恒久的なURLとは役割が違います。共有用のURLとしてプレビューリンクをメモしないようにしてください。新規サイトのテストでは、公開してよい短いテスト記事を使う方法もありますが、不要な内容を検索へ残さない管理も必要になります。
操作の位置と保存の基本は、WordPress公式「Settings Permalinks screen」が参考になります。サーバー設定に関する警告が出た場合は、意味の分からないまま設定ファイルを上書きせず、契約先の案内やサポートへ確認しましょう。
スラッグは短さより「何の記事か」を優先する
スラッグは文章のタイトルを一字ずつ翻訳する場所ではありません。扱う対象と主要な目的が分かる短い語句にすると、自分で一覧を見たときにも整理しやすくなります。たとえばブログの始め方なら blog-start-guide、バックアップ方法なら wordpress-backup-guide といった考え方です。これらは架空の命名例であり、同じ単語を使えば検索に有利になるという意味ではありません。
年号は、毎年更新して使い続ける記事なら慎重に入れます。2026という文字を入れたURLで2027年の内容へ更新しても技術的に直ちに使えなくなるわけではありませんが、URLと内容の印象にずれが出ます。年度そのものを記録する記事なのか、最新情報へ更新する記事なのかを先に決めてください。
※表は横にスクロールできます。
| 記事の目的 | 命名の例 | 避けたい決め方 | 確認する理由 |
|---|---|---|---|
| WordPressの基礎手順 | wordpress-start-guide | タイトル全文を長くつなぐ | 一覧で用途を把握しやすくする |
| 毎年更新する比較 | hosting-comparison | 不要な年号を毎年変更する | URL変更の保守を増やさない |
| 特定年度の記録 | event-2026-report | 年度を省き全年度を同じ名前にする | 記事の範囲を区別する |
| 操作トラブルの解決 | wordpress-login-help | help、testなど意味が広すぎる語だけ | 他の記事と区別する |
| 公開前の試作 | 内容に合う名称へ整理 | sample、new-postを確認せず公開 | 後から改名したくなる理由を減らす |
日本語スラッグも利用できます。日本語だから必ずSEOで不利という判断はしないでください。一方、コピーや共有の場面で長い符号化文字列になることがあり、管理のしやすさから短い英数字を選ぶ運用はあります。英語を選ぶ場合も、意味が不明な単語を無理に並べるより、サイト内で一貫した命名にすることが大切です。
重複や自動調整を見つけたら公開前に直す
同じスラッグがすでに使われているなどの理由で、末尾に数字が付く場合があります。数字を消して保存しても戻るなら、同名の投稿や固定ページ、ゴミ箱などを確認します。ただし、数字が付いたというだけで既存記事を削除する必要はありません。内容が別なら、目的の違いが分かる名称を付ける方が自然です。
たとえば初心者向けの導入記事と、エラー対処の記事を両方wordpress-guideにしようとしていないか見直します。これはURLの問題に見えて、記事の役割が曖昧な問題でもあります。タイトル、説明文、スラッグを並べて読めば、それぞれが別の疑問に答えているか確認しやすくなります。
公開前の最終確認では、タイトルを直した後もスラッグが意図したままか、内部リンクにプレビューURLが混じっていないか、親ページやカテゴリーの変更がURLへ影響していないかを点検します。今後も使う命名ルールは、三行程度の運用メモにして残しましょう。
公開済みパーマリンクの変更手順|旧URLと新URLの対応から準備する

変更前に対象URLと入口を一覧にする
公開済みURLを変えるときは、先に旧URLの一覧を作ります。記事タイトル、投稿ID、旧URL、予定する新URL、変更理由、転送確認、内部リンク確認の欄があれば、小規模な変更にも使えます。全体変更なら通常の投稿以外に影響するページがないか調べ、対象外のページも明示します。
一覧は管理画面だけでなく、サイトマップやアクセス解析、Search Consoleなどで補います。管理画面にある全記事と、検索で読まれている記事、SNSから読まれている記事は同じ一覧ではありません。流入が少ないURLでも、取引先へ送った資料に使われている可能性があります。用途を知る担当者がいるなら、変更前に確認を取りましょう。
以下は架空の作業表です。「転送できた」の一語だけでは、どこへ着地したか分かりません。記事ごとに正しい対応先を書き、テスト結果を残す形にします。実際のサイトではURLを完全な形式で記録し、相対パスの取り違えも防いでください。
※表は横にスクロールできます。
| 対象 | 旧URLの例 | 新URLの例 | 期待する動き | 変更前の判断 |
|---|---|---|---|---|
| 始め方の記事 | /2025/01/blog-start/ | /blog-start/ | 旧URLから同じ内容の新URLへ転送 | 共有済みリンクを調査 |
| 名称を直す記事 | /wordpres-guide/ | /wordpress-guide/ | 誤記を直した記事へ直接転送 | 変更の必要性を確認 |
| 統合する二記事 | /old-a/ と /old-b/ | /combined-guide/ | 内容を引き継いだ統合先へ案内 | 無関係な記事へ飛ばさない |
| 削除した内容 | /retired-page/ | 対応先なし | 適切な不在応答を返す | 無理にトップへ転送しない |
| 変更しない固定ページ | /contact/ | /contact/ | 同じURLで通常表示 | 巻き込み変更がないか点検 |
バックアップと戻し方を先に確かめる
準備するのはバックアップファイルだけではありません。作業直前の設定値、リダイレクト設定、対象URLの一覧、復元方法も一組にします。ファイルとデータベースの両方が必要になる構成もあるため、何を保存し、どう戻すかを利用中のサービスで確認しましょう。「自動バックアップがあるはず」で本番変更を始めると、対象日や復元範囲を後から調べることになります。
可能なら検証環境で変更し、通常記事、画像、ページ送り、フォームなどを確認します。検証環境が別ドメインなら、検索対象にしない設定やメール送信の制限にも注意が必要です。本番と環境が完全に一致するとは限らないため、検証成功を本番無事故の保証にはしませんが、設定の誤りを先に見つける機会になります。
復旧時に失う更新にも目を向けます。バックアップ後に問い合わせ、コメント、注文などが増えるサイトでは、丸ごと復元するとそのデータが戻ってしまう可能性があります。ブログのURL変更であっても、同じWordPress内に別機能がないかを確認してください。復旧判断を誰が行い、いつ作業を止めるかまで決めておくと慌てにくくなります。
旧URLから対応する新URLへ恒久的に転送する
URLを恒久的に移す場合は、旧URLから内容の対応する新URLへ恒久的なリダイレクトを設定する方法が基本です。301や308のようなHTTPステータスを使うサーバー側の転送が代表例です。実装はサーバー機能、設定ファイル、管理用プラグインなどで異なります。利用中の環境に合った方法を選び、同じ転送を複数の場所に重複登録しないようにします。
WordPressには古いスラッグからの転送が働く場合もありますが、すべての構造変更や特殊なURLを自動で引き継ぐと決めつけないでください。必ず実際の旧URLを開き、最終的に意図した記事へ到達するか確かめます。URLの文字列が変わったから成功ではなく、同じ内容へ一貫して案内されることが重要です。
関係のない旧URLをすべてトップページへ転送すると、読者が探していた内容を見つけられません。代替内容がないページは、適切な404や410などの扱いも検討します。「どこかへ飛べばエラーではない」という考え方ではなく、移転、統合、削除を分けて対応しましょう。
変更計画の根拠としては、Google検索セントラルのURL変更を伴うサイト移転ガイドを参照できます。URLの対応付け、転送、新旧両方の確認が必要になります。検索での再評価には時間がかかる場合があり、変更直後の順位だけで成功・失敗を断定しません。
一度の変更で検証できる範囲に収める
URLを変える日に、テーマ変更、サーバー移転、大量の記事削除をまとめて行うと、不具合や検索変化の理由が分かりにくくなります。個別変更で済むなら一記事ずつ進め、全体構造変更なら事前に例外を洗い出してから実施します。全体設定は多くの投稿へ同時に効くため、一部だけのつもりで保存しないでください。
当日の確認順は、まず新URLが正常に表示されるか、次に旧URLが正しい新URLへ転送されるか、その後に内部リンクやサイトマップを確認する流れにすると整理しやすくなります。旧URLから新URL、その新URLから別のURLという連鎖が増えていないかも見ます。二回目のURL変更では、初代URLから最新URLへ直接案内できるかを確認しましょう。
サーバー移転も必要な場合は、URL変更とは分けて計画する方が原因を追いやすくなります。移転時のデータやDNSの確認については、WordPressの引っ越し手順を参照してください。この記事のパーマリンク変更だけで、移転作業全体が完了するわけではありません。
パーマリンク変更後の404・転送ループ・反映されない問題を切り分ける

最初に記録するのは操作履歴と再現条件
ページが開かないときは、設定を次々に変える前に症状を記録します。旧URLだけが開かないのか、新URLも開かないのか、トップページは見えるのか、管理画面には入れるのかを分けます。すべてを「パーマリンクがおかしい」とまとめると、サーバー障害、権限、キャッシュ、公開状態など別の原因を見落とします。
ブラウザーのアドレス欄にあるURL、表示されたメッセージ、直前に変更した設定、発生時刻を控えます。ログインしているブラウザーでは見えても、一般読者には見えない場合もあります。別のブラウザーやログアウト状態での確認を加え、特定の端末だけかどうかを確かめてください。外部へ相談するときは、管理画面の認証情報や利用者の個人情報をそのまま送らないようにします。
HTTPステータスを見られる環境なら、ブラウザーの開発者ツールのネットワーク欄などで確認できます。見慣れない場合は、ステータスの解釈を推測せず、表示画面とURLをそろえてサポートへ伝えるだけでも調査の助けになります。画面に「404」と書いてあることと、サーバーが返す応答が404であることが常に同じとは限りません。
旧URLだけ404なら転送と対応表を確認する
新URLは正常で旧URLだけが404になるなら、転送が登録されていない、対象パスが一致していない、別のルールが先に働いている、といった可能性があります。対応表にある旧URLをコピーして再現し、末尾スラッシュ、日付、カテゴリー部分、文字の符号化などを確認します。思い出して手入力した別URLを検証していないかも見直しましょう。
リダイレクト機能の設定では、入力欄が完全なURLを求めるのか、パスだけを求めるのかが製品ごとに異なります。正規表現を使う一括ルールは便利ですが、対象範囲を広げすぎると関係のない記事まで転送されます。説明を理解できない場合は、件数が少ないうちは一対一の対応で検証する方が管理しやすいことがあります。
新URLも404になる場合は、記事が公開されているか、URLが保存後の値と一致するか、投稿タイプの設定が変わっていないかを見ます。新規記事の下書きプレビューが見えるだけで、一般公開URLも正常だと思わないでください。パーマリンク構造を変更した直後なら、サーバーの書き換え設定がその形式に対応しているかも調査対象です。
※表は横にスクロールできます。
| 症状 | 最初の確認 | 次に調べる場所 | 避けたい操作 |
|---|---|---|---|
| 旧URLだけ404 | 新URLが正しい記事を表示するか | 転送元の一致・ルールの有効性 | 全旧URLをトップへ一括転送 |
| 投稿URL全体が404 | トップと管理画面は開くか | 構造設定・サーバーの書き換え設定 | 未確認の設定ファイルを丸ごと上書き |
| 何度も転送される | 最終URLと転送の経路 | HTTPS・末尾スラッシュ・複数転送機能 | 転送設定をさらに重ねる |
| 自分の端末だけ古い表示 | 別ブラウザーやログアウト状態 | ブラウザー・サーバー・CDNのキャッシュ | 全体設定を元に戻してまた変える |
| 一記事だけ別記事へ飛ぶ | 投稿IDと旧新対応表 | 重複スラッグ・誤った転送先 | 正しい記事を削除して解決しようとする |
| 変更欄自体が見つからない | 権限・投稿タイプ・使用サービス | 管理者やサービスの公式案内 | 権限を増やす不明なプラグインを入れる |
転送ループは「AからB、BからA」を探す
転送が繰り返されるときは、複数の機能が違う正解を主張していないかを調べます。たとえば一方で末尾スラッシュを付け、別の場所で外す設定になっていると、同じページの形をめぐって行き来する原因になり得ます。HTTPS、wwwの有無、ドメイン、カテゴリー部分なども確認する軸です。
サーバー管理画面、WordPressの追加機能、CDNなど、転送を扱える場所が複数ある場合は、どこに何を設定したかを一覧にします。直前に追加したルールから調べ、既存のSSL設定を根拠なく外さないようにしてください。通信を暗号化しない状態に戻すことを、ループ解消の通常手順にはしません。
手元で原因を特定できない場合は、変更したルール、発生するURL、想定する着地点を管理者へ伝えます。「サイトが変です」だけでなく、「旧URL Aを開くとBへ進んだ後にAへ戻り、エラーになる」と説明できると、問題の箇所を共有しやすくなります。復旧のために一時的に機能を止める場合も、読者への影響が分かる範囲で行いましょう。
キャッシュ削除と設定修正は分けて検証する
キャッシュに古い転送や表示が残ることはありますが、すべての不具合をキャッシュのせいにはできません。まず設定値とURLの対応を確認し、利用中のキャッシュ機能の公式手順に沿って対象を更新します。どの層を消したか記録し、一度に多くの操作を重ねないことが原因確認に役立ちます。
ブラウザーの再読み込みだけではサーバーやCDNの保存内容が変わらない場合があります。反対に、サーバー側を更新しても、手元のブラウザーに以前の情報が残る場合もあります。違うブラウザーで正しく見えるなら、サイト全体を変更する前に端末側の条件を調べましょう。
設定ファイルの編集が必要という案内に出会ったときは、使っているWebサーバーとホスティングの手順を確認します。Apache向けの記述を別の環境へそのまま当てはめられるとは限りません。管理画面で修正できる範囲を超えたら、バックアップを確保し、サーバー会社や保守担当へ相談する方が安全です。
変更後の点検と日常の運用|同じURLを長く使うためのチェックリスト

内部リンク・サイトマップ・正規URLをそろえる
転送が正常でも、自分で更新できる内部リンクは新URLへ直しておくと、読者や検索エンジンが余計な転送を経ずに移動できます。本文だけでなく、メニュー、プロフィール、関連記事、固定ページ、画像に付けたリンクなどを対象にします。自動生成されるリンクと手入力したリンクを分けると、直すべき場所を探しやすくなります。
サイトマップに新URLが載っているか、旧URLが不要に残っていないかも確認します。SEO機能が出すcanonicalなどの正規URL指定については、実際のページ出力を見て、古いURLを正規として示していないかを調べます。意味が分からない欄を一斉に書き換えず、使っている機能の公式説明を確認してください。
SNSの過去投稿や他サイトのリンクは、すべてを自分で更新できるわけではありません。転送を残す理由の一つは、その入口を維持するためです。自分で管理するプロフィールや固定投稿、配布資料など、今後も使うものから新URLへ直していきます。他者へ修正を依頼する場合も、対象の旧URLと新URLを一組で伝えましょう。
当日と後日の点検は目的を変える
変更当日は、ページが開くこと、正しい記事へ転送されること、主要機能が動くことを優先します。後日は、検索で新しいURLが扱われているか、想定外の404が増えていないか、古いURLからの訪問に問題がないかを見ます。異なる目的の確認を一つの「SEOチェック」で済ませない方が、何が終わり何が継続中か分かります。
Search ConsoleのURL検査やページのインデックス登録の情報は参考になりますが、管理画面の報告には反映の時間差があります。ブラウザーで開けることと、検索での扱いが切り替わることは同時ではありません。変更後すぐに新URLが検索で見えないからといって、URLを何度も戻したり変えたりするのは避けましょう。
※表は横にスクロールできます。
| 確認時点 | 確認対象 | 残す記録 | 対応が必要な状態 |
|---|---|---|---|
| 変更直後 | 新URL・旧URL・代表的な機能 | 着地点、応答、確認した日時 | 404、誤転送、表示やフォームの不具合 |
| 同日中 | 内部リンク・メニュー・サイトマップ | 修正済み箇所と未対応箇所 | 自分で直せる旧URLが主要導線に残る |
| 数日後以降 | 検索の登録状況・エラー傾向 | 変更前後を比べられるメモ | 意図しないURLが継続して問題になる |
| 更新作業のたび | タイトル修正とURLの関係 | スラッグ変更の有無 | 内容修正のついでにURLまで変わる |
| 保守引き継ぎ時 | 転送ルール・URL台帳 | 担当者と保存場所 | 何のための転送か説明できない |
この確認時点は運用例です。サイトの規模や更新頻度に合わせて調整し、重要な機能に不具合があれば次の点検日まで待たずに対応します。反対に、変化のない順位を一日に何度も見て設定を触るより、エラーと対応関係を落ち着いて確認する方が役立ちます。
タイトルを改善してもURLを変えない運用を作る
記事のタイトルは、内容の改善や読者の疑問に合わせて直すことがあります。そのたびにスラッグまで同じ文言に合わせる必要はありません。たとえば「初心者向け」をタイトルに加えたり、説明を具体化したりしても、記事の主題が同じなら既存URLを維持する方が管理しやすくなります。
ただし、記事をまったく別のテーマへ置き換える場合は、古い読者が期待している内容との関係を考えます。URLを維持すれば何を載せてもよいわけではありません。更新、統合、新規作成、削除のどれが適切かを編集面から判断し、その後にURLの扱いを決めましょう。
複数人で記事を書くなら、公開前に誰がスラッグを確認するか、公開後に誰が変更を承認するかを決めます。投稿担当者が独断で全体設定を変更しない体制にすると、記事制作とサイト保守が混ざりにくくなります。命名メモと変更台帳は、特別なツールでなくても、担当者が確実に見られる場所にまとめれば十分です。
よくある疑問と今日やること
「URLが数字だけならすぐ変えるべきですか」という疑問には、現在の運用上の不都合と変更の影響を確認してから判断すると答えます。数字を含むURLが使われているだけで、すべての記事を変更する必要はありません。新規記事も現在の構造に沿うため、個別スラッグを付ける前に構造を把握しましょう。
「カテゴリーを変えたらURLも変わりますか」という疑問は、構造次第です。URL構造にカテゴリーを使う場合と使わない場合で影響は異なります。分類を変える前に対象記事の公開URLを控え、変更後に同じ入口で開けるか確認します。固定ページの親子関係や、商品用の追加機能にも別のルールがあるため、通常投稿と同じ扱いにしません。
「リダイレクト用プラグインは必須ですか」という疑問には、必須とは限らないと答えます。サーバー側で適切に管理できる場合もあります。重要なのは、転送元と転送先を把握し、競合せず動くことと、将来も維持できることです。追加機能を入れるかどうかは、その機能が必要か、管理を続けられるかで決めてください。
「サーバーを変えればパーマリンクの問題も解決しますか」という期待だけで契約を変えるのはおすすめしません。原因が記事の公開状態や転送設定なら、移転しても同じ問題を持ち込む可能性があります。契約先を選び直す事情がある場合は、バックアップやサポート、更新費用まで副業ブログ向けレンタルサーバー比較で整理してから検討しましょう。こちらは関連サービスを比較する記事であり、本記事の技術仕様の出典とは区別しています。
今日まず行うのは、現在のパーマリンク構造を記録し、代表的な公開記事のURLを一つ確認することです。新規サイトなら命名ルールを決め、公開済みサイトなら変更理由と対象一覧を作ります。理由が曖昧なら急いで変えず、記事の内容や導線の改善を優先して構いません。
パーマリンク管理のゴールは、設定画面をきれいに見せることではなく、読者が同じ入口から必要な内容へたどり着ける状態を守ることです。初期設定は分かりやすく、変更は必要な範囲だけに絞り、変更した後は旧URLも検証する。この順番を守れば、URLを直す作業を、後から何度もやり直す作業にせずに済みます。