記事が増えてくると、カテゴリの作りが少しずつ窮屈になってきます。
私のブログも、暮らしの話と技術の話とゲームの話が同じ棚に雑多に積まれていて、そろそろ整理したいと考えていました。
ただ、整理に手をつける直前で、ひとつ確認しておくべきことに気づきます。
それは「どう分けるか」ではなく、「今のURLがカテゴリ変更にどう反応するか」という前提の確認。
ここを飛ばすと、カテゴリを動かした瞬間に大量のリダイレクト作業が降ってくることがあります。
同じ落とし穴で時間を溶かさないために、確認すべき一点を整理してみませんか。
前提（最小限）：何を整理しようとしたのか
最初に、今回いじろうとしていた環境を最小限だけ説明しておきます。
対象は、私が運営する公開記事122本ほどのブログです。
ジャンルは暮らし系・技術系・ゲーム系が入り混じっていて、これを大きく3系統へ束ね直したいというのが出発点。
パーマリンクという土台
整理の話に入る前に、URLの土台を押さえておきます。
WordPressのURLは「設定」の「パーマリンク」で決めた構造に従って組み立てられる。
たとえば構造を/%category%/%postname%/にすると、記事URLの中にカテゴリ名がそのまま入ります。
ここで効いてくるのが、2つの部品の性格の違い。
%postname%（スラッグ）は記事ごとに自由に書き換えられます。
一方の%category%は、その記事に割り当てたカテゴリから自動で生成される部分。
つまりカテゴリを変えると、URLのカテゴリ部分も自動的に変わるという関係が、最初から仕込まれているわけです。
この構造タグの仕様は、WordPress.org公式のパーマリンク解説に一覧でまとまっています。
サブドメインよりサブディレクトリを選んだ理由
3系統に分けると決めたとき、最初に迷ったのが置き場所の作りでした。
選択肢は大きく2つ。
サブドメインで分けるか、サブディレクトリで分けるか。
評価を集約したいならサブディレクトリ
結論から言うと、私はサブディレクトリにまとめる方針を選びました。
理由は、1つのサイトとして評価を集約し、読者にも関連記事を回遊してもらいたかったからです。
サブドメインは、検索エンジンから別サイトのように扱われ、評価が分散しやすい側面があります。
複数のWordPressを並行して管理する運用コストも、地味に重くのしかかってくる。
その点サブディレクトリなら、ドメインの力を一箇所に集めながら、回遊もつくりやすいという利点。
そして見落としがちなのが、このサブディレクトリ構造は、突き詰めるとカテゴリ設計の結果としてURLの階層に現れるものだという点です。
つまりカテゴリをどう切るかが、そのままURLの形を決めていきます。
棚卸し：サイトマップから全記事を並べる
方針が決まったら、次は現状の棚卸しです。
頭の中のイメージだけで再編を始めると、抜けや重複が必ず出てくる。
そこで頼りになったのが、WordPressが自動で吐き出すサイトマップでした。
sitemapで機械的に全記事を集める
WordPressは標準でwp-sitemap.xmlというサイトマップを生成します。
そこからカテゴリの一覧と、全記事のURLや最終更新日を、手作業ではなく機械的に取り出せる。
例えば、次のような形でサイトマップをたどって中身を覗いていきます。
# パーマリンク構造の確認（管理画面: 設定 → パーマリンク）
# 例) /%category%/%postname%/ ← カテゴリ名が入る = 移動でURLが変わる
# 全記事の棚卸しはサイトマップから取得できる
curl -s https://example.com/wp-sitemap.xml
curl -s https://example.com/wp-sitemap-taxonomies-category-1.xml
curl -s https://example.com/wp-sitemap-posts-post-1.xml
# ※ URLは例。実際のドメインに置き換える取得した一覧を、keep（残す）・PRUNE（間引く）・MOVE（移す）の3つに仕分けていく。
ラベルを振るだけで、これから発生する作業量が一目で見える化されるのが効きました。
仕分けで見えた数字
実際に仕分けてみると、全122本のうち keep 87・PRUNE 候補 26・MOVE 8・要目視 1という内訳に落ち着きます。
そしてPRUNE 候補の多くが、環境構築まわりの薄い記事に集中していたという発見。
具体的には、Ruby や Python、React、Raspberry Pi、開発環境のセットアップ記事などが並びます。
数字にしてみると、感覚で「なんとなく散らかっている」と思っていた状態が、はっきり輪郭を持って見えてきました。
地雷：/%category%/ がカテゴリ移動を全件301に変える
仕分けが終わって、いよいよ記事を動かそうとした手前で、最初の前提確認が効いてきます。
ここが今回の本題。
カテゴリ移動はURL変更そのもの
思い出してほしいのが、URL構造が/%category%/%postname%/だったという点です。
%postname%は自由に変えられますが、%category%はカテゴリ割り当てから自動生成されます。
ということは、ある記事のカテゴリをBlogからTechへ移すと、URLの先頭部分も/blog/から/tech/へ書き換わる。
カテゴリ移動は、実質的にURL変更そのものだったわけです。
私のように122本を抱えた状態でこれをやると、移動対象の記事はすべてURLが変わる計算になります。
「軽い整理のつもり」が、気づけば大量のリダイレクト案件に化けていました。
301と410をセットにする
URLが変わる以上、旧URLから新URLへの301リダイレクトは避けて通れません。
放置すれば、検索結果やブックマークから来た読者が軒並み404に突き当たることになります。
記事を消す場合も同じで、行き先があるなら301、完全に終わらせるなら410で明示する。
例えば、サーバ側ではこんな形の指定になります。
# 旧 /blog/what-is-npu/ → 新 /tech/what-is-npu/（カテゴリ移動で変わったURL）
Redirect 301 /blog/what-is-npu/ https://example.com/tech/what-is-npu/
# 削除記事は関連先へ301、行き先が無ければ410で終了を明示
Redirect 410 /tech/code-sample/resize-image/
# ※ プラグイン Redirection でも同等のことができるリスクを抑える着手順
ここから得た実務的な判断が、URLが変わらない作業から先に片づけるという順番でした。
同じカテゴリ内での記事の統合や、間引き対象のnoindex化は、URLを動かしません。
URLが変わらない処理は301が要らないので、リダイレクト設計の前に安全に進められます。
そして何より大きい気づきが、そもそもURLにカテゴリ名を含めない構造なら、この苦労自体が発生しないという事実。
/%postname%/のようにカテゴリ名を含まない構造だと、カテゴリを変えてもURLは一切変わりません。
これこそが、着手前にパーマリンクを確認しておく価値だと痛感しました。
最後に
カテゴリの整理は、つい「どう分けるか」から考えたくなります。
ただ、今回いちばん効いたのは、その前に「今のURLがカテゴリ変更にどう反応するか」を確かめる一手でした。
パーマリンクに %category% が含まれるかどうかで、カテゴリ整理のコストはまるごと変わる。
含まれているなら、カテゴリ移動は全件がURL変更＝301案件になります。
だからこそ、分類の議論を始める前に、まず構造を一度のぞいておく。
この順番を守るだけで、あとから降ってくるリダイレクトの山を未然に防げるという学びでした。
環境やテーマが違っても、「設計の前に、今の足場がどう動くかを確認する」という姿勢は、そのまま流用できるはず。
以上です。
コメントを残す