WordPressのカテゴリーとタグを使い分ける基本：記事整理で迷わない実務ルール
WordPressで記事を整理するときは、カテゴリーを「サイトの大きな棚」、タグを「記事を横断して探すための付箋」として考えると迷いにくくなります。
たとえば技術ブログなら、カテゴリーは「WordPress」「自動化」「データ処理」のように読者がメニューからたどる入口に向いています。一方でタグは「REST API」「WP-CLI」「エラー対処」「初心者向け」のように、複数カテゴリーの記事を横断してまとめたいキーワードに向いています。
この記事で分かることは次の通りです。
- カテゴリーとタグの役割の違い
- 実務で迷いやすい分類例
- 管理画面、REST API、WP-CLIでの指定例
- 増えすぎ、重複、削除時の注意点
- 代替手段としてのカスタムタクソノミーの考え方
対象は、WordPressで記事を投稿・整理する初心者から実務初級者です。確認日は2026年7月7日で、WordPress.org公式ドキュメントとDeveloper Resourcesを参照しています。
まず結論：カテゴリーは必須の大分類、タグは任意の横断ラベル
カテゴリーとタグはどちらも「タクソノミー」と呼ばれる分類の仕組みですが、使い方は同じではありません。
カテゴリーは、投稿を大きなテーマごとに分けるための分類です。WordPress公式ドキュメントでも、投稿は1つ以上のカテゴリーに分類され、似た内容の記事をグループ化してナビゲーションに役立てるものとして説明されています。
タグも投稿を似た内容でまとめるために使えます。ただし、カテゴリーと違って親子関係を持ちません。つまり「親カテゴリー」「子カテゴリー」のような階層は作れず、平らなキーワード一覧として扱います。
ここがポイント: カテゴリーは読者がサイト内をたどるための道筋、タグは記事同士を細かく結びつけるための補助線です。
実務では、次のように分けると整理しやすくなります。
| 項目 | カテゴリー | タグ |
|---|---|---|
| 主な役割 | 記事の大分類 | 横断的なキーワード |
| 階層 | 親子関係を作れる | 親子関係はない |
| 投稿時の扱い | 通常は少数を選ぶ | 必要に応じて複数付ける |
| 読者の使い方 | メニュー、一覧、カテゴリーページから読む | 関連語、技術名、用途から読む |
| 増えすぎたときの問題 | サイト構造が分かりにくくなる | 似たタグが乱立して検索性が落ちる |
カテゴリーは「読者が選ぶ入口」として設計する
カテゴリーは、サイト全体の案内板になる分類です。
WordPressのカテゴリーは親子関係を持てます。たとえば「Web制作」を親カテゴリーにして、その下に「WordPress」「HTML・CSS」「サーバー運用」を置くような整理ができます。
カテゴリーに向いている例
カテゴリーは、記事を書いた後に毎回悩まない粒度にするのが実務では大切です。
向いているのは、次のような分類です。
- WordPress
- Web制作
- サーバー運用
- 自動化
- データ処理
- エラー対処
これらは、読者が「今日は何について読みたいか」を選ぶ入口になります。サイトのナビゲーションや一覧ページにも出しやすく、記事数が増えても意味が崩れにくい分類です。
カテゴリーに向かない例
反対に、細かすぎる言葉をカテゴリーにすると管理が苦しくなります。
functions.php404エラーREST API初心者向け2026年版
これらは記事の特徴としては便利ですが、サイト全体の大きな棚にするには細かすぎます。こうした語はタグに回したほうが自然です。
スラッグはURLに出る前提で決める
カテゴリーには名前だけでなくスラッグがあります。スラッグはURL向けの文字列で、公式ドキュメントでもカテゴリースラッグはURLに使われるものとして説明されています。
例として、カテゴリー名を「WordPress」、スラッグを wordpress にすると、テーマや設定によっては次のようなカテゴリーページになります。
https://example.com/category/wordpress/
日本語カテゴリー名を使う場合でも、スラッグは英数字とハイフンで短く付けると、共有や管理がしやすくなります。
カテゴリー名: サーバー運用
スラッグ: server-operation
カテゴリー名は後から変えられますが、スラッグを変更するとカテゴリーページのURLが変わる場合があります。外部リンクや内部リンクを使っているサイトでは、リダイレクトやリンク修正が必要になることがあります。
タグは「あとから探すためのキーワード」として使う
タグは、カテゴリーをまたいで記事を見つけるための分類です。
WordPress公式ドキュメントでは、タグはカテゴリーと違って階層を持たないと説明されています。つまり、タグは「親タグ」「子タグ」のように育てるものではありません。
タグに向いている例
タグは、記事の中身を具体的に表す言葉に向いています。
- REST API
- WP-CLI
- ブロックエディター
- エラー対処
- 初心者向け
- JSON
- 自動投稿
たとえばカテゴリーが「WordPress」の記事でも、「REST API」タグを付けておけば、別カテゴリーのAPI連携記事と一緒に読者へ見せられます。
ここがタグの強みです。カテゴリーは棚、タグは棚をまたいだ索引です。
タグを増やしすぎると何が困るか
タグは自由に付けられるため、放っておくとすぐに増えます。
よくある失敗は、表記ゆれです。
WordPress REST API
REST API
WP REST API
wordpress api
これらを別々のタグとして作ると、同じ話題の記事が分散します。読者がタグページを開いても記事が1本しかなく、一覧として役に立たない状態になります。
実務では、タグを作る前に次の点を確認します。
- 既存タグに同じ意味のものがないか
- 今後も複数記事で使う見込みがあるか
- カテゴリー名と重複していないか
- 日本語表記と英語表記をどちらに寄せるか
1記事にしか使わない予定の語は、タグにしない判断も有効です。検索キーワードとして重要なら本文や見出しに自然に入れれば十分な場合があります。
管理画面での基本操作：名前、スラッグ、説明を確認する
カテゴリーもタグも、管理画面では名前、スラッグ、説明を管理できます。
カテゴリーの場合は、加えて親カテゴリーを指定できます。タグには親子関係がないため、親を選ぶ項目はありません。
入力例：技術ブログの記事を分類する
たとえば次の記事を投稿するとします。
タイトル: WordPress REST APIで下書き記事を作成する基本
内容: 外部スクリプトからWordPressへ記事を送信する方法を解説する
この場合、分類は次のように考えられます。
カテゴリー: API・連携
タグ: WordPress, REST API, JSON, 自動投稿
カテゴリーを「WordPress」にする選択もあります。ただし、サイト全体で「API・連携」を主な導線にしたいならカテゴリーはそちらにし、WordPressはタグに回すほうが記事の探し方に合います。
正解は1つではありません。大事なのは、読者が一覧ページを開いたときに期待する記事が並ぶかどうかです。
出力例：読者から見える分類
テーマによって表示は変わりますが、記事下や一覧で次のように表示されることがあります。
カテゴリー: API・連携
タグ: WordPress / REST API / JSON / 自動投稿
ここでカテゴリーが5個も6個も付いていると、読者はどの分類が主なのか分かりにくくなります。タグが20個並んでいる場合も同じです。分類は多いほど親切なのではなく、選びやすい数に絞るほうが機能します。
REST APIで指定するときはID配列を使う
WordPress REST APIで投稿を作成・更新する場合、投稿データには categories と tags を指定できます。
公式のPosts APIリファレンスでは、categories はcategoryタクソノミーのターム、tags はpost_tagタクソノミーのタームとして扱われます。どちらも配列です。
サンプル：投稿作成時にカテゴリーとタグを指定する
次は、カテゴリーID 3、タグID 8 と 12 を付けて下書き投稿を作る例です。
curl -X POST https://example.com/wp-json/wp/v2/posts \
-u "user:APPLICATION_PASSWORD" \
-H "Content-Type: application/json" \
-d '{
"title": "WordPress REST APIの分類テスト",
"status": "draft",
"content": "分類指定の確認用本文です。",
"categories": [3],
"tags": [8, 12]
}'
期待される考え方は次の通りです。
{
"categories": [3],
"tags": [8, 12]
}
ここで指定するのはカテゴリー名やタグ名ではなく、既にWordPress側に存在するタームのIDです。外部ツールから投稿する場合は、先にカテゴリーやタグのIDを取得しておく必要があります。
認証情報はコードに直書きしない
上の例では説明のために APPLICATION_PASSWORD と書いていますが、実務では認証情報をスクリプトへ直書きしないでください。
最低限、次のように扱います。
- 環境変数から読み込む
.envを使う場合はGit管理に含めない- 共有端末やCIログに表示しない
- 不要になったアプリケーションパスワードは削除する
分類指定そのものは単純でも、投稿APIは認証を伴います。カテゴリーとタグの話だけでなく、認証情報の保管場所まで含めて運用を決めておく必要があります。
WP-CLIで一括変更するときは「置き換え」に注意する
サーバー上でWordPressを管理している場合、WP-CLIを使うと投稿の分類をコマンドで変更できます。
公式の wp post term set コマンドは、投稿などのオブジェクトにタームを設定するためのコマンドです。ただし重要なのは、既存のタームを置き換える動作だという点です。
サンプル：投稿ID 123 にカテゴリーを設定する
wp post term set 123 category wordpress
この例では、投稿ID 123 に wordpress というスラッグのカテゴリーを設定します。
タグを設定するなら、タクソノミー名は post_tag です。
wp post term set 123 post_tag rest-api wp-cli automation
よくある失敗：追加のつもりで既存タグを消す
wp post term set は既存タームを置き換えます。そのため、タグを1つ追加するつもりで次のように実行すると、既に付いていた他のタグが外れる可能性があります。
wp post term set 123 post_tag rest-api
既存タグを残したい場合は、先に現在のタグを確認し、残したいタグも含めて指定する運用にします。
wp post term list 123 post_tag
wp post term set 123 post_tag rest-api wp-cli automation
一括処理では、実行前に対象投稿IDと変更後の分類をCSVなどに出して確認すると事故を減らせます。
よくある迷いどころと判断基準
カテゴリーとタグは、運用を始めてから迷う場面が増えます。ここでは実務でよく出る判断を整理します。
1つの記事にカテゴリーはいくつ付けるか
基本は1つ、多くても2つ程度に絞ると管理しやすくなります。
複数カテゴリーを付けられるからといって、記事に関係する分類をすべて選ぶ必要はありません。カテゴリーは「この記事の主な置き場所」です。補助的な話題はタグで拾えば十分です。
カテゴリー名とタグ名が同じでもよいか
技術的には作れますが、実務では避けたほうが分かりやすいです。
たとえばカテゴリーにもタグにも「WordPress」があると、読者にも管理者にも意味の違いが伝わりにくくなります。カテゴリーとして使うならタグにはしない、タグとして使うならカテゴリーにはしない、という整理を先に決めます。
タグページに記事が少ない場合はどうするか
タグページに1記事しかない状態が長く続くなら、そのタグは見直し候補です。
対応は次のどれかです。
- 似たタグへ統合する
- 表記ゆれを直す
- 今後使う予定がなければ削除する
- 本文内キーワードとして扱い、タグにはしない
タグの削除は投稿そのものを削除する操作ではありません。ただし、タグページのURLは使えなくなるため、外部からリンクされている場合は注意が必要です。
カテゴリーを削除すると投稿はどうなるか
WordPress公式ドキュメントでは、カテゴリーを削除しても投稿自体は削除されず、削除されたカテゴリーに属していた投稿はデフォルトカテゴリーへ割り当てられると説明されています。
これは重要です。大量の記事があるサイトでカテゴリーを整理すると、意図せず「未分類」などのデフォルトカテゴリーへ記事が移ることがあります。
整理前には、次の順で確認します。
- 削除対象カテゴリーに何本の記事があるか
- 移動先カテゴリーを決めているか
- デフォルトカテゴリーが適切な名前になっているか
- カテゴリーURLに外部リンクがないか
代替手段：分類が複雑ならカスタムタクソノミーを検討する
カテゴリーとタグだけで無理に整理しないほうがよいケースもあります。
たとえば、企業サイトで「製品」「業種」「導入目的」をそれぞれ別軸で絞り込みたい場合、カテゴリーとタグだけに詰め込むとすぐに混乱します。
このような場合は、カスタムタクソノミーを検討します。カスタムタクソノミーは、WordPressに独自の分類軸を追加する仕組みです。
例としては次のような使い分けです。
- カテゴリー: 記事の大分類
- タグ: 横断キーワード
- カスタムタクソノミー: 製品種別、対象業種、難易度、地域など
ただし、カスタムタクソノミーはテーマ、プラグイン、管理画面、URL設計に関わります。初心者のうちは、まずカテゴリーとタグを絞って運用し、それでも足りない場合に検討する順番が現実的です。
実務で使う分類ルールの作り方
最初に完璧な分類表を作るより、少数のルールから始めるほうが運用しやすくなります。
おすすめは、次のような短いルールをチーム内で共有することです。
1. カテゴリーは記事の主題を1つ選ぶ
2. タグは検索・横断に使える語だけ付ける
3. 新しいタグを作る前に既存タグを検索する
4. スラッグは英数字とハイフンで統一する
5. 月1回、使われていないタグと表記ゆれを見直す
この程度でも、分類の乱れはかなり減ります。
特に重要なのは「新しいタグを作る前に既存タグを検索する」ことです。タグは記事投稿のたびに増えやすく、後から統合するほど手間がかかります。
まとめ：読者の探し方から逆算すると分類は決めやすい
カテゴリーとタグの違いは、管理画面の機能差だけで覚えるより、読者の動きで考えるほうが実務に落とし込みやすくなります。
読者がメニューや一覧から大きなテーマを選ぶならカテゴリー。複数テーマの記事をまたいで、特定の技術名や用途から探すならタグです。
最後に、運用前に確認したいポイントを短くまとめます。
- カテゴリーはサイトの大分類として少数に絞る
- タグは横断検索に役立つ語だけ使う
- スラッグはURLに出る前提で分かりやすく付ける
- REST APIではカテゴリー・タグをID配列で指定する
- WP-CLIの
term setは既存分類の置き換えに注意する - 分類軸が増えすぎるならカスタムタクソノミーを検討する
次に見るべきなのは、実際のサイトで「1記事だけのタグ」「同じ意味のタグ」「使われていないカテゴリー」がどれだけあるかです。そこを棚卸しすると、カテゴリーとタグの設計が読者の探し方に合っているかが見えてきます。