register_post_typeのrewriteとwith_frontをちゃんと理解して設定する【WordPress】

こんにちは！コーダーのゆうしです。

カスタム投稿タイプを作るとき、register_post_type() の rewrite オプションをなんとなく書いていませんか？特に with_front の設定を間違えると「URL に /blog/ が余分につく」「変更したら 404 になった」といったトラブルが起きます。

今回は rewrite オプションの中身と、現場でよくハマるポイントを整理して解説します。

rewriteオプションとは
slugでURLのスラッグを変える
with_frontをfalseにしないと起きる問題
has_archiveとrewriteのslugはセットで考える
rewriteを変更したら必ずパーマリンク設定を保存し直す
躓きやすいポイント
まとめ

rewriteオプションとは

register_post_type() の rewrite は、カスタム投稿タイプのパーマリンク（URL）のリライトルールを制御するオプションです。省略すると true が適用され、投稿タイプのスラッグ名がそのまま URL に使われます。

rewrite に配列を渡すことで細かく制御できます。よく使うキーは以下の3つです。

キー	内容	デフォルト
slug	URL に使うスラッグ文字列	投稿タイプ名（`$post_type`）
with_front	管理画面のパーマリンク設定の前方スラッグを引き継ぐか	true
feeds	フィードのパーマリンク構造を作るか	`has_archive` の値

slugでURLのスラッグを変える

デフォルトでは投稿タイプ名がそのまま URL のスラッグになります。たとえば register_post_type( 'news', ... ) と登録すると URL は /news/投稿スラッグ/ になります。

slug を指定するとこの部分を変更できます。

function my_register_post_type() {
  register_post_type( 'news', [
    'label'       => 'ニュース',
    'public'      => true,
    'has_archive' => true,
    'rewrite'     => [
      'slug'       => 'information', // URLのスラッグをinformationに変更
      'with_front' => false,
    ],
  ] );
}
add_action( 'init', 'my_register_post_type' );

この場合、個別記事のURLは /information/投稿スラッグ/、アーカイブページは /information/ になります。

💡 slug に 'aaa/bbb' のようにスラッシュ区切りで書くと、第3階層以下のURL（例：/service/news/投稿スラッグ/）にも対応できます。

with_frontをfalseにしないと起きる問題

ここが一番ハマりやすいポイントです。with_front のデフォルトは true で、管理画面の「設定 → パーマリンク設定」で指定したパーマリンク構造の前方部分をカスタム投稿タイプのURLにも引き継ぎます。

具体的には、パーマリンク設定を /blog/%postname%/ のように設定している場合、with_front が true だとカスタム投稿のURLが次のようになってしまいます。

✗ with_front: true（意図しない結果）
https://example.com/blog/news/記事スラッグ/

✓ with_front: false（意図した結果）
https://example.com/news/記事スラッグ/

/blog/ が余分についてしまい、URLが崩れます。カスタム投稿タイプの URL にはサイト全体のパーマリンク設定を引き継いでほしくないことがほとんどなので、基本的には with_front => false にしておくのが無難です。

　NG（with_frontの指定なし＝true）　

'rewrite' => [
  'slug' => 'news',
  // with_frontの指定なし → デフォルトのtrueが適用される
  // パーマリンク設定に /blog/ があればURLが /blog/news/記事スラッグ/ になる
],

'rewrite' => [
  'slug'       => 'news',
  'with_front' => false, // 前方スラッグを引き継がない
],

has_archiveとrewriteのslugはセットで考える

has_archive を true にするとアーカイブページが有効になりますが、そのURLは rewrite の slug に連動します。さらに has_archive に文字列を渡すと、アーカイブページのスラッグだけを別で指定することもできます。

'has_archive' => 'news-list', // アーカイブのURLは /news-list/
'rewrite'     => [
  'slug'       => 'news',       // 個別記事のURLは /news/記事スラッグ/
  'with_front' => false,
],

アーカイブページと個別記事でスラッグを変えたい場面（例：一覧は /information/、記事詳細は /news/記事スラッグ/）では、この書き方が使えます。

rewriteを変更したら必ずパーマリンク設定を保存し直す

ここを知らずにハマる人が多いポイントです。rewrite の設定を変更しても、WordPressのリライトルールのキャッシュがそのまま残っているため、すぐには反映されず404エラーが出ます。

設定変更後は必ず管理画面の 「設定 → パーマリンク設定」を開いて「変更を保存」ボタンを押してください。設定自体は変えなくて構いません。このひと手間でリライトルールが再構成されます。

⚠️ register_post_type() の rewrite を変更したあとに「ページが見つかりません（404）」になった場合は、ほぼパーマリンク設定の再保存で解決します。コードを疑う前にまずここを確認してください。

躓きやすいポイント

rewriteをfalseにするとパーマリンクが機能しなくなる

rewrite => false にするとリライトルール自体が無効になります。フロントエンドからURLでアクセスできなくなるため、通常の用途では使いません。管理画面上だけで使う内部用の投稿タイプなどに限定した選択肢です。

// フロントエンドからアクセスさせたくない内部用投稿タイプの例
register_post_type( 'internal_data', [
  'public'  => false,
  'rewrite' => false, // リライトルールを作らない
] );

slugに日本語を使うとURLが文字化けする

slug には英数字とハイフンを使うのが原則です。日本語を指定すると URL がパーセントエンコードされて文字化けしたような見た目になります。スラッグは必ず半角英数字で設定してください。

'slug' => 'ニュース', // → URLが %E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9 になる

'slug' => 'news', // 半角英数字で指定する

まとめ

rewrite オプションのポイントをまとめると次のとおりです。

slug でカスタム投稿タイプのURLスラッグを指定できる（デフォルトは投稿タイプ名）
with_front はデフォルトが true。管理画面のパーマリンク設定の前方スラッグが引き継がれるので、通常は false にする
設定を変更したあとは「設定 → パーマリンク設定」を保存し直さないと404になる

ご不明な点やコーディングのご依頼はお問い合わせからお気軽にどうぞ。