コーポレートサイトを WordPress で構築するとき、
「デフォルト投稿（post）をそのまま使うか」
それとも 「最初からカスタム投稿タイプに統一するか」
この設計方針で悩むこと、けっこうあると思います。
ブログサイトを作るだけといったシンプルな要件なら、素直に標準の投稿タイプ(post)を使えば十分です。
追加実装も少なく、WordPressの標準的な使い方でもあります。
ただ、WordPressでコーポレートサイトを構築する場合、最初から複数の投稿タイプを扱う前提になると、少し事情が変わってきます。
例えば、blog を標準の投稿タイプ（post）として扱い news などはカスタム投稿で対応する構成にした場合、テンプレートのルールが揃わなかったり、post だけが特別扱いの存在になってしまうのが地味に悩ましいポイントです。
小さな違和感が少しずつ積み重なり、気づいたころには、保守コストがじわじわ上がっているなんてことにもなりかねません。
今回はこの「postを使うべきか？カスタムに統一すべきか？」問題について整理してみたいと思います。
シンプルなブログなら post が最短
単純にブログだけを運用するなら、post を使うのが一番ラクです。
理由はシンプルです。
- 追加実装ゼロ
- 管理画面UXが標準
WordPressらしい、最短ルートの構成です。
ただしblogを post としたまま、複数コンテンツになると違和感が出てきます。
例えば次のように混在させると、
post → blog
news → カスタム投稿
works → カスタム投稿
event → カスタム投稿
postだけが例外になります。
発生する問題
- postだけパーマリンク設定が別管理
- テンプレート命名規則が揃わない
- 条件分岐が増える
- 新規メンバーが理解しづらい
この小さな不統一がじわじわ効いてきて、結果的に技術的負債につながる可能性があります。
複数コンテンツならカスタム投稿タイプで統一する
そのため、私は最初からこうしています。
post → 未使用
blog → カスタム投稿
news → カスタム投稿
works → カスタム投稿
event → カスタム投稿
すべて同じルールで扱う、という設計です。
これだけでテンプレート構造がかなりスッキリします。
post は使用しないため、管理画面からは非表示にします。
add_action( 'admin_menu', function () {
remove_menu_page( 'edit.php' );
} );
ただし、これはあくまで管理画面上の非表示に過ぎません。
post タイプ自体は内部的に存在しているため、sitemap.xml には引き続き含まれます。
WordPress の標準 sitemap は public な投稿タイプを自動出力するため、post を使っていなくても post-sitemap.xml が生成されます。
そのため、post を完全に使用しない場合は sitemap からも除外しておきます。
add_filter('wp_sitemaps_post_types', function ($post_types) {
unset($post_types['post']);
return $post_types;
});
カスタム投稿統一のメリット
メリット①： テンプレートが完全統一
archive-{posttype}.php
single-{posttype}.php
このルールだけで完結します。
どのファイルが何用なのか一目でわかりやすくなります。
例えば、新規でサイトの改修を依頼されたときでも
「newsの一覧を直したい → archive-news.php」
のように、迷わず対象ファイルにたどり着けます。
構造把握の時間が減り、保守や運用がかなり楽になります。
メリット②： 将来拡張に強い
投稿タイプを分けておくと、機能追加や仕様変更の影響範囲を小さくできます。
例えば、「news だけ一覧レイアウトを変えたい」、「works だけ検索対象に含めたい」
といった個別にカスタマイズしたい要件が後から出てきても、投稿タイプ単位で対応できます。
カスタム投稿 で分離されていれば、
archive-news.php や single-works.php のように 対象ファイルが明確 なので、修正箇所も限定されます。
投稿タイプごとに責務を分けておくだけで、長期運用や追加開発がかなり楽になります。
メリット③： データ構造が明確
「記事」ではなく「コンテンツタイプ」として整理できる。
HeadlessやREST連携でも扱いやすい。
例えば、blog を post、news をカスタム投稿タイプとして分けている場合。
$query = new WP_Query([
'post_type' => 'post',
'posts_per_page' => 10,
]);
このコードだけでは、
「blog を取得している」のか、それとも別の用途の post なのかが判断できません。
post という指定はあくまで「標準投稿」という意味でしかなく、
実際にどんなコンテンツを扱っているのかは、プロジェクトの文脈を知らないと分からない状態になります。
一方、カスタム投稿 で分離していれば、
$query = new WP_Query([
'post_type' => 'news',
'posts_per_page' => 10,
]);
これだけで「news を取得している」と一目で分かります。
コード自体がコンテンツの意味を説明してくれるため、構造把握や改修がかなり楽になります。
Headless 構成や REST API でも同様です。
REST API（カスタム投稿）
/wp-json/wp/v2/news
REST API（post運用）
/wp-json/wp/v2/posts?categories=3
どちらが直感的かは一目瞭然です。
投稿タイプで分離しておくだけで、取得条件がシンプルになり、実装や運用がかなり楽になります。
メリット④：URL設計がきれいに揃う
コーポレートサイトのように最初から複数の投稿タイプを扱う場合、
post は使わずカスタム投稿に統一することで、URL構造を明確に分けることができます。
post とカスタム投稿が混在している構成では、
見た目上は同じようなURLに見えても、
内部的には「標準投稿」と「独自投稿」という異なるルールで管理されている状態になります。
その結果、
- パーマリンク設定の考え方が post だけ別になる
- パンくずリストの生成ロジックが揃わない
- テンプレート階層やルーティングの理解にズレが出る
といった、細かな違和感が生まれやすくなります。
一方、post を使わずカスタム投稿に統一すると、
「コンテンツタイプ ＝ URL構造」という関係がそのまま成立します。
ブログ
- 一覧
https://example.com/blog/ - 詳細
https://example.com/blog/blog_detail_page/
お知らせ
- 一覧
https://example.com/news/ - 詳細
https://example.com/news/news_detail_page/
この構成では、
- URLルールが投稿タイプ単位で明確になる
- パンくずも
/news → 記事のように自然に揃う - ルーティングやテンプレートの考え方が統一される
ため、情報設計として非常に素直です。
特にコーポレートサイトでは、
URL・パンくず・コンテンツ構造を同じルールで説明できることが重要になります。
後からページを追加したり、コンテンツが増えてきた場合でも、
「このURLはどの投稿タイプか」「どこに属する情報か」を迷わず判断しやすくなります。
結果として、
フロント実装・SEO設計・保守運用のすべてで扱いやすい構造になります。
まとめ
小規模なブログだけなら post で十分。
複数の投稿タイプを扱うなら、最初からカスタム投稿タイプで揃えてしまうのがおすすめです。
設計ルールが統一されるので、テンプレート構造も分かりやすくなり、運用や保守がかなり楽になります。