WordPressの初期設定で「投稿名」「日付と投稿名」「カスタム構造」のどれを選ぶべきか迷っていませんか。すでに記事を公開している場合は、URLを短く整えたいと思っても、変更後の404や検索流入への影響が不安になります。
新規の小規模ブログでは、短く説明的で、カテゴリや公開日の変更に左右されにくい/%postname%/を基本候補にできます。ただし、ニュース、会員サイト、大量の商品ページなど、日付やIDをURLへ残す明確な運用要件があれば別です。
公開済みURLは、見た目を整えるだけの理由で変更しないでください。変更が必要なら、旧URLと新URLを一対一で対応させ、恒久転送、内部リンク、canonical、サイトマップまで同じ新URLへそろえます。
先に結論｜新規設定と公開後変更は分けて考える
| 状態 | 基本方針 | 最初の作業 |
|---|---|---|
| サイト公開前 | 運用に合う共通構造を一度決める | 設定→パーマリンクで候補を比較 |
| 記事の下書き中 | 公開前に個別スラッグを整える | 短く内容が分かる語へ変更 |
| 一部記事だけ公開済み | 変更理由と流入・被リンクを確認 | 旧新URL表と一対一転送を準備 |
| サイト全体が公開済み | 構造変更を小修正として扱わない | バックアップ、全URL一覧、テスト、監視を計画 |
サイト全体の立て直しでURLを見直す場合も、先に記事の残す・統合・削除を決めます。判断の順番は古いブログ記事を整理する方法とWordPressサイト再生ロードマップを参照してください。
パーマリンク・URL構造・スラッグの違い
| 用語 | 意味 | 例 |
|---|---|---|
| URL | ページ全体のウェブアドレス | https://example.com/wordpress-backup/ |
| パーマリンク | 投稿や固定ページに割り当てる恒久的なURL | 各記事へリンクするときに使うURL |
| 共通構造 | 投稿URLを作るサイト全体の規則 | /%postname%/ |
| スラッグ | 投稿URLの個別部分 | wordpress-backup |
WordPress公式のパーマリンク設定画面の解説では、パーマリンクは投稿、固定ページ、カテゴリ、タグアーカイブへリンクする恒久的なURLと説明されています。名前どおり、公開後に頻繁に変える前提の設定ではありません。
共通構造を変えると、多数の投稿URLが一度に変わることがあります。個別記事のスラッグだけを変える場合とは影響範囲が異なるため、作業前に対象URL数を確認します。
パーマリンク構造は運用に合わせて選ぶ
| 主な構造 | 向く運用 | 注意点 |
|---|---|---|
| 基本 | 検証用や特殊な要件 | URLから内容を推測しにくい |
| 日付と投稿名 | 日付自体に意味があるニュース・日報 | 公開日の変更や再編集でも日付がURLに残る |
| 月と投稿名 | 月単位で整理する媒体 | 長期更新記事では日付が内容とずれる場合がある |
| 数字ベース | IDで安定管理する要件 | URLだけでは内容を推測しにくい |
| 投稿名 | 一般的なブログ・解説メディア | 公開前に分かりやすいスラッグを付ける運用が必要 |
| カスタム構造 | 日付・ID・カテゴリ等を含む要件 | 複雑化と将来変更の影響を理解して設計する |
このサイトのような長期更新型の解説ブログでは、/%postname%/ならカテゴリ名や公開日を変えても投稿URLを維持しやすく、内容も推測しやすくできます。これは検索順位の保証ではなく、読者への分かりやすさと長期運用の安定性を優先した判断です。
/%category%/%postname%/は階層を表現できますが、カテゴリ再編時の扱いを先に決める必要があります。複数カテゴリを使うサイトではURLに採用されるカテゴリを意図どおり管理できるかも確認します。カテゴリ設計そのものはWordPressカテゴリ設計の基本で整理してください。
記事スラッグは公開前に決める
- ページの主題を短い語で表す
- 単語はハイフンで区切る
- 意味のない連番や長い自動生成文字列を避ける
- 日付やカテゴリを重ねて入れすぎない
- 公開後も通用する語を選ぶ
- サイト内で英字小文字などの方針を統一する
GoogleのURL構造の公式ガイドは、短く説明的なURLと、単語区切りにハイフンを使う方法を推奨しています。日本語URLも扱えるため、「日本語ではGoogleに登録されない」という説明は正しくありません。
一方、URLをメール、表計算、広告管理、サーバーログで共有すると、日本語部分が長いパーセント表記になることがあります。このサイトでは管理と共有のしやすさから、英字小文字とハイフンへ統一する方針です。英訳を長くしすぎず、主題が分かる範囲に絞ります。
公開前に設定する手順
- 管理画面の「設定→パーマリンク」を開く
- 現在の構造を画面保存する
- サイトの更新期間、記事タイプ、カテゴリ変更の可能性を確認する
- 新規サイトなら候補構造をテスト環境で選ぶ
- 設定を保存する
- 投稿を下書き保存し、投稿設定から個別スラッグを編集する
- プレビューURL、主要ページ、カテゴリ、404表示を確認する
- 公開後に使うURLを原稿・SNS・メール等へ記録する
すでに公開済み投稿があるサイトでは、設定画面を保存するだけでURLが変わる可能性があります。既存サイトで試しに切り替えて確認する操作はしません。現在のURL一覧と戻し方を用意し、テスト環境で影響を確認してから本番変更を判断します。
公開後にURLを変えるべきか判断する
| 変更理由 | 判断 | 補足 |
|---|---|---|
| 少し短くしたい | 原則変更しない | 見た目だけなら既存URLの安定を優先 |
| 誤字がある | 影響と必要性を比較 | 意味が通じるなら維持も選択肢 |
| 個人情報や機密語を含む | 変更を優先 | キャッシュ・ログ・検索残存にも対応 |
| カテゴリ再編でURLが変わる | 全URLを計画して実施 | 一対一転送と内部リンク更新が必要 |
| 重複記事を統合する | 関連する統合先へ変更 | 無関係なトップへ一括転送しない |
| HTTPS化・ドメイン変更 | サイト移転として扱う | パーマリンクだけの作業にしない |
HTTPからHTTPSへの変更はWordPressのSSL化手順、ドメイン名そのものの変更はWordPressのドメイン変更手順で扱います。サイト全体の移転を、個別スラッグの編集と同じ感覚で進めないでください。
公開後に変えるなら旧新URLを一対一で準備する
- ファイルとデータベースをバックアップする
- サイトマップ、Search Console、アクセス解析、被リンク等から旧URL一覧を作る
- 各旧URLに対応する新URLを一つずつ決める
- 対応先がない削除URLは、統合・404・410のどれが適切か判断する
- テスト環境で新URLと恒久転送を作る
- 転送を管理する場所をサーバー、プラグイン、CDN等の一か所に決める
- 内部リンク、メニュー、canonical、サイトマップの更新表を作る
- アクセスが比較的少ない時間帯に本番へ反映する
GoogleのURL変更を伴う移転ガイドは、旧URLと新URLの対応表を作り、可能ならサーバー側の恒久転送を使うよう案内しています。複数の旧ページを無関係なトップページへ集める転送は、読者を迷わせ、ソフト404として扱われる可能性があります。
恒久転送は301または308を使う
ページを恒久的に移動した場合、Googleは可能ならサーバー側の恒久転送を推奨しています。HTTPの301と308は、どちらも永続的な移転を示します。利用中のサーバーや管理機能が公式に案内する方法を選びます。
- 旧URLから対応する新URLへ直接転送する
- 旧URL→中間URL→新URLという転送連鎖を避ける
- 新URLから旧URLへ戻るルールを作らない
- http・https、www有無、末尾スラッシュの規則を統一する
- サーバーとプラグインとCDNで同じ転送を重ねない
- 転送先が200で本文を表示することを確認する
.htaccessはApache等の環境で使われますが、すべてのサーバーに同じ設定を貼れるわけではありません。文法や適用範囲を誤るとサイト全体が500エラーになることがあります。汎用コードをそのまま貼らず、サーバー公式機能または管理者の確認を優先します。
変更後に「ページの自動転送が正しく行われません」等が出た場合は、ルールを増やす前にWordPressのリダイレクトループを直す確認順で、WordPress、サーバー、CDNの転送を一か所ずつ調べます。
内部リンク・canonical・サイトマップも新URLへそろえる
| 更新対象 | 確認内容 |
|---|---|
| 本文内リンク | 旧URLを新URLへ直接更新する |
| メニュー・関連記事 | 転送を経由せず新URLへつなぐ |
| canonical | 新URLが自分自身を正規URLとして示す |
| XMLサイトマップ | 新URLを含み、旧転送URLを外す |
| OGP・構造化データ | URL参照が旧URLのまま残っていない |
| 広告・メール・プロフィール | 管理できる主要導線を新URLへ更新する |
転送があるから内部リンクを直さなくてよいわけではありません。内部リンクを新URLへ直接更新すると、読者の待ち時間とサーバー負荷を減らし、サイト内の正規URLを一貫させられます。リンクの見直し方はWordPress内部リンクの貼り方で確認してください。
投稿以外に変わるURLも確認する
共通構造やカテゴリーベースを変更するときは、通常の投稿だけを見て完了と判断しません。サイトの構成によっては、カテゴリ・タグ・著者・固定ページ・商品・添付ファイルなど、別種類のURLが検索や内部導線に残っています。
- XMLサイトマップに含まれるURL種類を一覧にする
- メニュー、パンくず、関連記事、カテゴリ一覧から実際にたどる
- Search Consoleで表示回数や外部リンクのある旧URLを確認する
- フォーム送信後や会員ページなど、機能に使うURLをテストする
- robots.txtやnoindexで隠れているURLも、変更対象か記録する
対象URLが多い場合は、全件を同日に変えず、URL種類ごとにテストと確認を区切る方法もあります。ただし同じページを複数回移動させる計画は避け、最終URLを先に決めてください。
変更後は旧URLから最終到達まで確認する
| 確認 | 合格条件 |
|---|---|
| 旧URL | 対応する新URLへ恒久転送される |
| 転送回数 | 不要な中間URLを経由せず直接到達する |
| 新URL | 200を返し、正しい本文・画像が表示される |
| canonical | 新URLを指し、旧URLへ戻らない |
| 内部リンク | 主要導線が新URLへ直接向く |
| サイトマップ | 新URLのみを送信する |
| Search Console | 旧新URLを検査し、クロールと登録の変化を記録 |
| 計測・機能 | GA4、フォーム、広告、共有、スマホ表示が正常 |
旧URLが404になる場合は、スラッグ、新しい公開状態、転送ルール、パーマリンク設定の順に確認します。原因の切り分けはWordPressの404エラーを直す手順を参照してください。
Googleはサイト移転の転送を一般に少なくとも1年維持し、読者の観点では可能ならさらに長く残すことを案内しています。旧URLへの被リンク、ブックマーク、古いメールは長く残るため、検索上の処理が落ち着いた直後に転送を消さないでください。
やってはいけない変更
- バックアップと旧URL一覧なしで共通構造を変更する
- 公開済み記事のスラッグを気分で何度も変える
- 旧URLをすべてトップページへ転送する
- 転送をサーバー、プラグイン、CDNで重複設定する
- 内部リンクを旧URLのまま放置する
- canonicalとサイトマップが旧URLを指す状態を残す
- 404を隠すため、すべての存在しないURLを200で表示する
- 反映直後の順位変動だけで転送を戻したり追加したりする
よくある質問
投稿名を選ぶとSEOで有利になりますか？
保証はありません。短く説明的なURLは人にも検索エンジンにも理解しやすい一方、検索順位はURL構造だけで決まりません。内容、検索意図、内部リンク、サイト全体の品質などを含めて改善します。
日本語スラッグは使えませんか？
Googleは日本語を含むURLも扱えます。ただし共有時に長いエンコード表記になりやすいため、サイトの運用方針として英字へ統一する選択があります。途中から全記事を英字へ変えるなら、見た目ではなく移転として計画してください。
パーマリンク設定を保存し直すと404が直りますか？
rewrite rulesが原因の一部症状で改善することはありますが、すべての404に効く万能策ではありません。URLの誤り、未公開、転送、サーバー設定、プラグイン競合などを先に切り分けます。
まとめ
パーマリンクは、公開後も使い続けるページの住所です。新規サイトでは、記事の性質と運用期間を考え、短く説明的で変わりにくい構造を選びます。一般的な長期更新ブログなら投稿名を基本候補にし、個別スラッグは公開前に整えます。
公開後は、URLを整えること自体を目的にしません。変更が必要なときだけ旧新URLを一対一で準備し、恒久転送、内部リンク、canonical、サイトマップを同じ新URLへそろえます。変更後の確認と転送の維持まで含めて、パーマリンク変更は完了です。