カスタムタクソノミーの内部名は、登録コードと保存済みの分類データの両方で使われます。
データベースの文字置換だけでは移行が完了せず、登録設定、URL、テンプレート、キャッシュも確認する必要があります。
内部名・表示名・URLスラッグを区別する
表示ラベルだけの変更ならlabels、URLだけの変更ならrewriteの設定を確認し、内部名を変える必要があるか先に判断します。
登録済みという警告は名前の競合を示し、それだけで予約語の使用と断定できません。
新しい内部名には、既存のタクソノミーや予約されたクエリ変数と衝突しない独自の短い名前を選びます。
変更前に控えるもの
データベース全体と登録コードをバックアップし、検証環境へ複製します。
旧名に属するterm_taxonomy_id、term_id、parent、countと投稿の紐付け件数、現在の分類URLを保存します。
分類名そのものはterms、タクソノミーへの所属はterm_taxonomy、投稿との関連はterm_relationshipsで管理されます。
検証環境で登録設定を変更する
旧登録の引数と対象投稿タイプを維持して内部名だけを変更し、同じ機能を登録するコードが重複していないか確認します。
以下は旧名waza_old_kindから新名waza_new_kindへ移す場合のSQL例であり、そのまま本番へ貼り付けないでください。
wp_はデータベース名ではなくテーブル接頭辞なので、実際の接頭辞へ変更します。
SELECT taxonomy, COUNT(*) AS rows_count
FROM wp_term_taxonomy
WHERE taxonomy IN ('waza_old_kind', 'waza_new_kind')
GROUP BY taxonomy;新名の行がすでにある場合はここで止め、既存分類への統合を別途設計します。
対象テーブルがトランザクションに対応し、同時更新がない検証環境で次を実行します。
START TRANSACTION;
UPDATE wp_term_taxonomy
SET taxonomy = 'waza_new_kind'
WHERE taxonomy = 'waza_old_kind';
SELECT ROW_COUNT() AS changed_rows;
-- 控えた旧名の行数と一致するか確認
ROLLBACK; -- 最初は戻して件数を確認するロールバックまで行って変更件数を確認した後、バックアップ・停止時間・復元方法を用意して本実行を計画します。
本実行では最後のROLLBACKをCOMMITへ変更しますが、件数や対象が想定と異なる場合はコミットしません。
データ更新後の確認
対象分類のキャッシュを更新し、パーマリンク設定は移行時に一度だけ保存して再生成します。
毎アクセスflush_rewrite_rulesを実行するコードは追加しません。
旧名を参照するtax_query、テンプレート名、管理画面設定、REST連携を新名へ合わせます。
分類URLが変わる場合は旧URLと新URLの対応を作り、必要な転送を個別に設定します。
投稿との紐付け、親子関係、件数、分類一覧、個別投稿とREST出力を確認します。
分類データの一致とURLの動作を別々に判定する
| 確認対象 | 比較するもの |
|---|---|
| 投稿の割り当て | 変更前後のterm_taxonomy_idと投稿IDの組み合わせ |
| 親子の分類 | term_idとparent。名前の行数だけで判定しない |
| 公開側の絞り込み | 新しい内部名を指定したtax_queryの投稿ID |
| 分類URL | 各タームの変更前・変更後のURLと実際のHTTP応答 |
| RESTなどの連携 | 登録設定のshow_in_rest・rest_baseと利用側の参照名 |
独立した検証用WordPressで、専用の旧・新タクソノミーと投稿を使い、変更件数、ロールバック、コミット後の投稿との紐付け・親子関係・新名での絞り込みを確認しています。
2026年10月3日には、WordPress 7.1.2 / SWELL 2.19.0の基本パーマリンクで、分類URLのHTTP応答とRESTの匿名取得・編集拒否を追加確認しました。
実際のサイト全体の移行や転送設定の動作確認は別途必要です。
パーマリンクが基本設定の場合は、rewriteのスラッグが同じでもURLのクエリ変数名が変わる場合があります。「URLスラッグを変えていないから旧リンクもそのまま動く」と判断せず、保存したURL対応表で確認してください。
旧URLの200応答だけで移行成功を判定しない
| 隔離環境での確認 | 結果 |
|---|---|
| 新しい内部名の分類URL | 200。対象の分類名と投稿を表示 |
| 登録を外した旧内部名の分類URL | 200だがトップページを表示。新分類への自動転送はない |
| 新しいREST経路の分類取得 | 200。タームIDと親IDを維持 |
| 旧REST経路へのアクセス | 404。新しい経路へ自動転送されない |
| 新分類でRESTの投稿一覧を絞り込む | 割り当て済みの公開投稿を取得。非公開投稿は含まれない |
| 未ログインで分類をcontext=editとして取得 | 401。編集用の取得を拒否 |
基本パーマリンクでは、登録を外した分類のクエリ変数が解釈されず、旧URLがトップページとして200を返す場合があります。
URL対応表の各行について、応答コード・転送先・分類名・表示された投稿を照合してください。
この検証では独自の転送コードを追加していません。
URLやREST経路を維持する設計が必要な場合は、内部名とは別にrewrite・query_var・rest_baseの設定と利用側の参照を確認し、検証環境で旧経路を試してください。
戻し方と検証範囲
戻す場合はバックアップからデータと登録設定を同じ時点へ戻し、キャッシュとパーマリンクを再確認します。
この記事のSQLは移行手順の例で、本サイトの分類データを変更したり実データ移行を検証したりしたものではありません。
参照：register_taxonomyの登録条件と予約語。
ローカルの独立した一時テーブルでは、2行の変更、対象外行の維持、ID・親・件数の維持、ロールバックを確認しました。
このSQL試験はWordPress全体の分類移行やURL動作の検証とは別です。
