カスタム投稿タイプとブログカテゴリの違い｜FAQや用語集はどちらで持つべきか
この記事の結論
FAQ、用語集、課題解決といったコンテンツを増やしていくなら、ブログのカテゴリではなく、カスタム投稿タイプで独立させることをおすすめします。
判断の目安として、私たちはそのテーマで5本程度は書けそうか、を見ています。書く見込みがあるなら、最初からカスタム投稿タイプで入れ物を用意しておくほうがよいと考えています。理由は3つあります。構造化データとデザインを、そのコンテンツの種類に合わせて作れること。そして、箱を分けておくほうが、何を書けばいいかがはっきりして、コンテンツを作りやすくなることです。
一方で、書く本数が数本で止まりそうなら、ブログのカテゴリで十分です。入れ物だけ作って中身が入らないと、一覧ページが痩せたまま残ります。
この記事での「カスタム投稿タイプ」の定義
WordPressには、もともと「投稿」と「固定ページ」という2種類の入れ物があります。カスタム投稿タイプ（Custom Post Type）は、これに加えて自分で新しい入れ物を作れる仕組みです。
たとえばFAQをカスタム投稿タイプにすると、URLは /faq/ のような形にでき、ブログとは別の場所に格納されます。専用の一覧ページ、専用のデザイン、専用の構造化データを持てるのが特徴です。
対してブログのカテゴリで持つ場合、一般的には /blog/faq/ のようなURLになり、あくまでブログ記事の一種として扱われます。
なお、URLの形はWordPressのパーマリンク設定やテーマの実装で変更できます。ここで挙げているのは一般的な例で、設定次第では別の形にもできます。
一番の違いは「別の入れ物か、同じ入れ物の中の仕切りか」
ブログのカテゴリ：同じ入れ物を仕切って使う
すべてブログ記事として作り、カテゴリで分類します。実装は簡単で、記事を書くたびにカテゴリを選ぶだけです。
ただし、中身はすべて同じ「ブログ記事」です。デザインも共通、構造化データも共通になります。用語集もFAQも、ブログ記事のテンプレートで表示されます。
カスタム投稿タイプ：種類ごとに入れ物を分ける
FAQはFAQ、用語集は用語集として、別々の入れ物を用意します。それぞれに専用のデザインを当てられ、専用の構造化データを付けられます。
実装には手間がかかります。テーマ側で投稿タイプを登録し、一覧ページやテンプレートを用意する必要があります。ただ、一度作ってしまえば、あとは記事を追加していくだけです。
比較表で整理すると
| 比較項目 | ブログのカテゴリ | カスタム投稿タイプ |
|---|---|---|
| URL | /blog/faq/ など（ブログ配下） | /faq/ など（独立した階層） |
| デザイン | ブログ記事と共通 | 種類ごとに変えられる |
| 構造化データ | ブログ記事と共通 | 種類ごとに最適なものを付けられる |
| 一覧ページ | カテゴリ一覧として表示 | 専用の一覧ページを作れる |
| 実装の手間 | ほぼ不要 | テーマ側の実装が必要 |
| 向いている量 | 数本程度 | 5本以上、継続的に増やす場合 |
ブログのカテゴリで十分なケース
正直に書くと、カスタム投稿タイプが常に正解ではありません。
書く本数が数本で止まりそうなら、ブログのカテゴリで十分です。実装の手間をかけて入れ物を作っても、中身が3本しか入らなければ、一覧ページは痩せたままになります。それなら、ブログ記事として書いてカテゴリで分類したほうが、労力に見合います。
また、テーマ側の実装ができない場合も、無理にカスタム投稿タイプにする必要はありません。プラグインで代用する手もありますが、デザインや構造化データを自由に作れないなら、独立させる意味は薄れます。
それでもカスタム投稿タイプを勧める理由
何を書けばいいかが、はっきりする
技術的な話の前に、実務として一番大きいのはここだと感じています。
「今月もブログを書かないと」と考えても、何を書くかで手が止まります。テーマが自由すぎるからです。一方で「用語集を増やそう」と決めていれば、書くべき用語はリストアップできます。「FAQを増やそう」なら、実際にお客様から聞かれた質問がそのまま題材になります。
入れ物が決まると、中身が決まる。細分化しておくほうが、なんとなくブログを書こうとするより、はるかにコンテンツを作りやすくなります。私たちは、実はこの運用面が一番大きなメリットだと考えています。構造化データもURL設計も大切ですが、そもそも記事が増えなければ、どんな設計も意味を持ちません。
これは運用の続けやすさに直結します。SEOで一番難しいのは施策の選定ではなく継続だと考えていますが、その継続を支えるのが「次に何を書くかが自明である」という状態です。投稿タイプを分けておくと、この状態を作りやすくなります。
構造化データを、種類に合わせて付けられる
技術面では、これが最も大きい理由です。
構造化データは、ページの内容を検索エンジンやAIが読み取りやすい形で伝える記述です。そして、コンテンツの種類ごとに適した形式があります。FAQにはFAQPage、用語集にはDefinedTermといった型が用意されています。なお、こうした構造化データを実装したからといって、検索結果での見え方が必ず変わるわけではありません。表示の仕様は変更されることもあります。私たちは、見た目の変化よりも、機械に内容を正しく伝える手段として実装しています。
カスタム投稿タイプで分けておくと、種類ごとにテンプレートを分けやすくなります。テンプレートが分かれていれば、その種類に合った構造化データを自動で出力する形にしやすい。記事を追加するたびに手作業で付ける必要がなくなり、本数が増えても品質が揃います。構造化データそのものはカテゴリでも実装できますが、種類ごとの自動化がしやすいかどうかが違います。ブログのカテゴリでも実装次第では可能ですが、テンプレートで種類ごとに自動化しにくく、運用が複雑になりやすいという違いがあります。構造化データの基本的な考え方は構造化データ（JSON-LD）の基本にまとめました。
デザインを、コンテンツの性質に合わせられる
用語集は「1語1ページ」で短く、FAQは「質問と回答」で完結し、課題解決は「症状から原因、対処」へと辿る形になります。それぞれ最適な見せ方が違います。
カスタム投稿タイプなら、種類ごとにテンプレートを用意できるため、その形に合ったデザインを当てられます。ブログ記事と同じ体裁で用語集を出すと、余計な要素が多く、読みづらくなりがちです。
一覧ページが、そのテーマの入り口になる
/faq/ や /glossary/ といった一覧ページは、そのテーマ全体の受け皿として機能します。
私たちのサイトでは、FAQの一覧ページと個別ページが、検索からの入り口として実際に機能している場面が増えました。ブログの1カテゴリという扱いだと、こうした受け皿としての役割は持たせにくくなります。
URLで、コンテンツの性質が伝わる
/faq/ /glossary/ /solution/ と分かれていれば、URLを見ただけで、そのページがどういう種類の情報かが分かります。人にとって内容が分かりやすく、サイト全体の構造も整理しやすくなります。Googleも、シンプルで論理的なURL構造を推奨しています。
ただし、これは順位への直接的な効果というより、サイトの構造を整理しやすくするメリットだと捉えています。URLを分けたから順位が上がる、という話ではありません。
私たちも、最初は全部ブログでした
偉そうに書いてきましたが、私たち自身、最初はすべてブログで書いていました。よくある質問も、用語の説明も、課題の解説も、ブログ記事としてカテゴリで分類していただけです。
変えたきっかけは、運用してみて不便を感じたことでした。判断の決め手になったのは、2つです。
一つは、構造化データの実装のしやすさです。ブログのテンプレートは共通なので、FAQに合った構造化データを記事ごとに手作業で付けることになります。本数が増えるほど手間になり、付け忘れも起きます。テンプレートで自動化できないか、と考えたのが出発点でした。
もう一つは、記事の書きやすさです。「今月もブログを書こう」だと、何を書くかで手が止まる。でも「FAQを増やそう」と決まっていれば、実際にお客様から聞かれた質問がそのまま題材になります。書くべきものが自然に決まる状態のほうが、運用が続くと分かってきました。
そこでFAQを新設し、ブログとは別の投稿タイプとして独立させました。それ以降は、新しいコンテンツの種類を始めるときは、最初から独立させる方針にしています。移行するより、最初から分けておくほうが手間がかからないと学んだからです。
つまり、この記事で書いてきた判断基準は、後から考えた理屈ではありません。自分たちが実際に不便を感じて、調べて、やり方を変えた経験から出てきたものです。
判断の目安：私たちは5本程度を目安にしています
私たちは、そのテーマで5本程度は書けそうか、を目安にしています。5本ほどあると一覧ページにも情報量が生まれ、独立したコンテンツ群として形になり始めるためです。ただし、これは私たちの運用上の感覚であって、絶対的な基準ではありません。3本でも独立させる価値があるテーマもあれば、10本あってもカテゴリで足りる場合もあります。
そして、もう一つ大事な考え方があります。「たまってから独立させる」のではなく、「先に箱を作って、集中して投下する」という順番です。
多くの場合、ブログで数本書いてから「増えてきたから独立させよう」と考えます。ただ、移行にはURLの変更が伴い、リダイレクトの設定も必要になります。最初から独立させておけば、この手間は発生しません。
私たちは、新しいコンテンツの種類を始めるとき、まずカスタム投稿タイプを用意します。そこにある程度まとめて記事を投下し、一覧ページが機能する状態まで一気に持っていく。この順番で運用しています。
どちらを選ぶべきか——判断のための5つの質問
1. そのテーマで、継続的に書く見込みがあるか？
書き続けられそうならカスタム投稿タイプ、数本で止まりそうならブログのカテゴリです。私たちは5本程度を一つの目安にしていますが、テーマによって変わります。
2. そのコンテンツに、専用の構造化データがあるか？
FAQ（FAQPage）や用語集（DefinedTerm）のように、種類に応じた構造化データがあるなら、カスタム投稿タイプの利点が大きくなります。
3. ブログ記事とは違う見せ方をしたいか？
用語集を短く簡潔に見せたい、FAQを質問と回答の形で整えたい。そうした要望があるなら、テンプレートを分けられるカスタム投稿タイプが向きます。
4. 一覧ページを、そのテーマの入り口にしたいか？
/faq/ のような一覧を検索の受け皿として育てたいなら、独立させたほうが設計しやすくなります。
5. テーマ側の実装ができるか？
自社または制作会社で、テーマの実装ができるかどうか。できないなら、無理に独立させず、ブログのカテゴリで運用するのも現実的な判断です。
ENVY DESIGNの実装——8種類のコンテンツ群で運用しています
私たちのサイトは、ブログのほかに複数のカスタム投稿タイプを持っています。それぞれ、なぜ独立させたのかという理由があります。
| 種類 | URL | 公開本数（2026年7月時点） | なぜ独立させたか |
|---|---|---|---|
| ブログ | /blog/ | 103本 | 考え方や実測データを記録する場所 |
| よくある質問 | /faq/ | 64本 | 1問1ページで独立したURLを持たせ、質問単位で検索に応じるため |
| 制作実績 | /works/ | 45本 | 事例ごとに専用の見せ方（写真・課題・成果）が必要なため |
| 用語集 | /glossary/ | 26本 | 1語1ページで短く定義し、各ページから参照される結び目にするため |
| 課題解決 | /solution/ | 23本 | 症状から原因、対処へと辿る専用の構成にするため |
| 選び方ガイド | /compare/ | 9本 | 比較表を軸にした専用の構成にするため（この記事もここに入ります） |
| 制作の流れ | /flow/ | 7本 | 依頼後の進み方を段階ごとに示すため |
| お客様の声 | /voice/ | 4本 | 第三者の評価として、制作実績とは別枠で見せるため |
いずれも「たまったから分けた」のではありません。最初から独立させて、そこに集中して記事を投下してきました。
分かりやすいのが用語集です。作ると決めたとき、まず /glossary/ という投稿タイプを用意しました。そのうえで、AI検索やWeb制作に関する用語を、1語1ページで積み上げていきました。今は26本を公開しています。もしブログのカテゴリで始めていたら、URLは /blog/glossary/ になり、あとから独立させるにはリダイレクトが必要でした。この考え方はバラバラな知識を束ねる「結び目」｜私たちが用語集を作る理由にも書いています。
選び方ガイド（/compare/）も同じです。公開しているのはまだ9本ですが、比較表を軸にした専用の構成にしたかったので、最初から独立した投稿タイプにしました。ブログ記事として書いていたら、この形にはなっていません。
8種類を運用していると、当然ながら手が回らないものも出てきます。だからこそ、それぞれの更新状況を管理画面で見える化して、どのコンテンツ群が手薄かを一目で分かるようにしています。入れ物を作ることより、そこを痩せさせないことのほうが難しい、というのが実感です。
実測：どのコンテンツ群が、検索で見られているか
種類を分けた結果、実際にどうなったか。Search Consoleで直近28日の表示回数を種類ごとに集計し、公開済みの本数で割って、1本あたりどれだけ検索結果に出ているかを見ました。
| 種類 | 公開本数 | 表示回数（28日） | 1本あたりの表示回数 |
|---|---|---|---|
| ブログ | 103本 | 19,957回 | 193.8回 |
| 用語集 | 26本 | 3,472回 | 133.5回 |
| 制作の流れ | 7本 | 358回 | 51.1回 |
| よくある質問 | 64本 | 3,139回 | 49.0回 |
| 課題解決 | 23本 | 1,117回 | 48.6回 |
| 制作実績 | 45本 | 1,763回 | 39.2回 |
| 選び方ガイド | 9本 | 168回 | 18.7回 |
| お客様の声 | 4本 | 73回 | 18.2回 |
【調査データ】2026年7月時点・Google Search Console・直近28日の実測値です。本数は公開済みのみで数えています。
まず断っておくと、ブログを他と同列には比較できません。ブログは何年も前から書き続けてきたもので、記事数も、外部からのリンクも、検索エンジンに評価されるまでの時間も、他とは条件が違います。一方、用語集や選び方ガイドは、比較的最近になって作った箱です。同じ土俵に乗せた数字ではない、という前提で見てください。
そのうえで目を引くのが、用語集です。公開しているのは26本と少なく、始めてからの期間も短いのに、1本あたりの表示回数はよくある質問の2.7倍あります。
1語1ページで、そのページが何に答えるものかがはっきりしていることも影響していると考えています。「◯◯とは」という検索に対して、ページの主題が正面から一致している状態です。よくある質問は、1問1ページではあるものの、質問の形が多様で、検索語と一致しにくいものも含まれます。ただし、扱っている用語自体の検索需要との相性もあり、構造だけが理由と言い切れるものではありません。
一方で、選び方ガイド（この記事が入る投稿タイプ）は9本、1本あたり18.7回とまだ弱い数字です。本数が少なく、公開して間もないためだと見ています。投稿タイプを作っただけでは結果は出ず、そこに記事を投下し続けて初めて機能する、ということでもあります。
念のため補足すると、「種類を分ければ検索で勝てる」という単純な話ではありません。この記事で書いてきた独立させる理由は、構造化データを種類ごとに揃えられること、デザインを性質に合わせられること、そして何より、何を書けばいいかがはっきりして運用が続くことです。検索での効率の優劣を主張したいわけではありません。
もちろん、構造だけが理由とは考えていません。公開時期、内部リンクの張られ方、扱っているテーマの検索需要。数字の背景には複数の要因があります。それでも、こうして種類ごとの傾向が見えること自体が、投稿タイプを分けている効果の一つだと考えています。どのコンテンツ群が育っていて、どこが痩せているか。ブログのカテゴリで混在させていたら、この比較はできませんでした。
まとめ
FAQや用語集をブログのカテゴリで持つか、カスタム投稿タイプで独立させるか。判断の分かれ目は、そのテーマで継続的に書く見込みがあるかどうかです。私たちは5本程度を目安にしています。
書くなら、最初から独立させたほうがよいと考えています。構造化データを種類に合わせて付けられること、デザインをコンテンツの性質に合わせられること。そして、入れ物が決まると中身が決まり、何を書けばいいかがはっきりすること。この3点が、独立させる理由です。
そして、たまってから移すのではなく、先に入れ物を作って集中して投下する。この順番のほうが、移行の手間もなく、一覧ページが早く機能し始めます。
よくある質問
カスタム投稿タイプにすると、SEOに有利になりますか？
カスタム投稿タイプにしただけで順位が上がるわけではありません。有利になりうるのは、構造化データを種類に合わせて付けられること、コンテンツの性質に合ったデザインにできること、一覧ページを受け皿として育てられることによる間接的な効果です。中身が薄いまま箱だけ分けても、効果は期待しにくいと考えています。
あとからブログ記事をカスタム投稿タイプに移せますか？
移すこと自体は可能ですが、URLが変わるため、リダイレクトの設定が必要になります。既に検索から流入があるページの場合、移行には慎重さが求められます。だからこそ、増やす予定があるなら最初から独立させておくことをおすすめしています。
プラグインでFAQを作るのと、何が違いますか？
プラグインでも十分に実現できる場合が多くあります。ACFやCPT UIのようなプラグインを使えば、投稿タイプの追加もカスタムフィールドの設定もできます。確認しておきたいのは、専用のテンプレートを作れるか、必要な構造化データを出せるかという点です。独自要件が多い場合は、テーマ側で実装するほうが自由度は高くなります。
カスタム投稿タイプは、いくつまで作ってよいですか？
数の上限を気にするより、それぞれに継続して記事を投下できるかを基準にしたほうがよいと考えています。投稿タイプを増やしすぎると、更新が追いつかず、痩せた一覧ページが並ぶことになります。私たちの場合は、それぞれのコンテンツの更新状況を管理画面で見える化して、手薄な箱が分かるようにしています。
ブログのカテゴリでFAQを運用しても、構造化データは付けられますか？
実装次第では可能です。ただ、テンプレートで種類ごとに自動化しにくいため、本数が増えるほど手間がかかり、付け忘れも起きやすくなります。継続的に増やすなら、テンプレート側で自動生成できる形にしておくほうが現実的だと考えています。
出典
- Google検索セントラル「構造化データの仕組みについて」 https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
- Google検索セントラル「URL 構造」 https://developers.google.com/search/docs/crawling-indexing/url-structure
- WordPress「Post Types」 https://wordpress.org/documentation/article/post-types/
関連記事
- 構造化データ（JSON-LD）の基本｜必須スキーマ6種と実装の全体像
- バラバラな知識を束ねる「結び目」｜私たちが用語集を作る理由
- 内部リンクのSEO効果と正しい設計方法｜自社サイトで実際に繋ぎ直した記録
- Wikipediaの構造だけ借りる｜思想は真逆の「偏った百科事典」を作っている
お問い合わせ
サイトのコンテンツをどう分けて設計すべきか迷っている段階でも構いません。相談してみるからご連絡ください。
カスタム投稿タイプで運用している用語集の実測は、用語集はSEOに効果がある？でご覧いただけます。