WordPress投稿タイプ別テンプレートを見直す
投稿タイプごとに分けたくなる理由
WordPressでサイトを運営していると、「この投稿タイプだけ見た目を変えたい」という場面が必ず訪れる。
ブログ記事と商品紹介、スタッフ紹介とお知らせ記事では、見せたい情報も構造もまったく異なる。同じテンプレートで無理やり対応しようとすると、どこかで無理が生じてくる。
たとえば、ブログ記事にはカテゴリーやタグ、著者情報を目立たせたい。一方で商品ページにはスペック表や購入ボタンを前面に出したい。こうした要件の違いが積み重なると、「投稿タイプごとにテンプレートを分けよう」という発想は自然な流れだと言える。
マーケティング観点でも、コンテンツの種類によってユーザーの期待値は異なる。訪問者が求めている情報をすばやく提供するためには、レイアウトそのものが最適化されている必要がある。WordPress 投稿タイプごとにテンプレート変更を検討するきっかけは、たいていこうした「使いにくさの蓄積」から生まれる。
WordPressのテンプレート階層を整理する
WordPressには「テンプレート階層」という仕組みがあり、どのPHPファイルを使って画面を表示するかを自動的に決定している。
この仕組みを理解することが、投稿タイプごとのテンプレート変更の出発点になる。
single.phpとarchive.phpの役割
single.phpは、個別の投稿を表示するためのテンプレートファイルだ。
WordPressは投稿の詳細ページを表示するとき、まず投稿タイプ専用のファイルを探し、なければsingle.phpにフォールバックする。このフォールバックの仕組みを知っておくと、テンプレートの設計がずいぶん楽になる。
archive.phpは、投稿の一覧ページを担当するファイルだ。カテゴリーページや月別アーカイブも、基本的にはこのファイルが使われる。
テンプレート階層の優先順位を整理すると、次のようになる。
single-{post_type}.php→ 投稿タイプ専用の個別ページsingle.php→ 汎用の個別ページ（フォールバック）archive-{post_type}.php→ 投稿タイプ専用の一覧ページarchive.php→ 汎用の一覧ページ（フォールバック）index.php→ 最終的なフォールバック
この階層を意識するだけで、「どのファイルを作ればいいか」の判断がかなりシンプルになる。
カスタム投稿タイプ用テンプレートの基本
カスタム投稿タイプを使い始めると、標準のsingle.phpやarchive.phpでは対応しきれない場面が増えてくる。
そこで登場するのが、投稿タイプ名を含んだ専用テンプレートファイルだ。
single-◯◯.phpとarchive-◯◯.phpの考え方
カスタム投稿タイプのスラッグがproductであれば、single-product.phpというファイルをテーマフォルダに置くだけで、WordPressが自動的にそれを使ってくれる。
特別なコードを書かなくても、ファイル名の命名規則に従うだけでテンプレートが切り替わる。この「ファイル名で制御する」という考え方は、WordPressのテンプレート階層の最もシンプルな活用方法だと言える。
archive-product.phpも同様で、product投稿タイプの一覧ページにだけ適用される。ブログの記事一覧とは別のレイアウトを用意したい場合に、このファイルが活躍する。
注意点として、カスタム投稿タイプのスラッグはregister_post_type()で設定した値と一致させる必要がある。スラッグのスペルミスは静かに失敗するため、動作確認は必ずセットで行いたい。
functions.phpでの条件分岐という選択肢
テンプレートファイルを増やす方法とは別に、functions.php内で条件分岐を使ってテンプレートを制御するアプローチもある。
ファイルを増やしたくない場合や、既存のテンプレートを柔軟に使い回したい場合には、こちらの方が合理的な選択になることもある。
is_singularやis_post_type_archiveの使い方
is_singular('product')は、product投稿タイプの個別ページを表示しているかどうかを判定する条件関数だ。
single.phpの中でこの関数を使えば、投稿タイプごとに異なるパーツを読み込んだり、クラスを切り替えたりすることができる。テンプレートファイルを分けずに済む分、ファイル管理がシンプルになるメリットがある。
is_post_type_archive('product')は、一覧ページ側の判定に使う関数だ。archive.phpの中で使うことで、投稿タイプごとに異なるヘッダーや絞り込みUIを出し分けることができる。
条件分岐を使う場合の典型的なパターンを示すと、次のようになる。
is_singular('post')→ 通常ブログ記事の個別ページis_singular('product')→ 商品ページis_post_type_archive('product')→ 商品一覧ページis_singular(array('post', 'news'))→ 複数の投稿タイプをまとめて判定
ただし、条件分岐が増えすぎるとfunctions.phpや既存テンプレートが肥大化しやすい。どのアプローチを選ぶかは、サイトの規模と将来の拡張性を考慮して判断したい。
共通パーツと専用レイアウトの切り分け
投稿タイプごとにテンプレートを分けていくと、「ヘッダーやフッターは共通なのに、何度も同じコードを書いている」という状況に陥りやすい。
そこで重要になるのが、共通パーツと専用レイアウトを明確に切り分けるという設計思想だ。
パーツ化とテンプレートパーツの使い方
WordPressにはget_template_part()という関数があり、テンプレートの一部を外部ファイルとして切り出して読み込むことができる。
たとえば、記事のメタ情報（著者・日付・カテゴリー）をtemplate-parts/post-meta.phpとして切り出しておけば、複数のテンプレートから呼び出して使い回せる。修正が必要になったときも、1ファイルを直すだけで済む。
get_template_part('template-parts/content', 'product')のように第二引数を指定すると、content-product.phpを優先的に読み込み、なければcontent.phpにフォールバックする。この仕組みを使うと、投稿タイプごとの差分だけを別ファイルで管理できる。
パーツ化を進める際に意識したいポイントをまとめると、次のようになる。
- ヘッダー・フッター・サイドバーは
get_header()・get_footer()・get_sidebar()で共通化 - 投稿タイプ固有の表示部分だけを
template-parts/以下に切り出す - ファイル名の命名規則を統一して、どのパーツがどの投稿タイプに対応するか一目でわかるようにする
サイト設計と運用コストのバランスを考える
テンプレートを細かく分けることは、表示の最適化という観点では正しい方向性だ。
しかし、テンプレートファイルが増えれば増えるほど、運用・保守のコストも比例して上がっていく。
増えすぎたテンプレートの整理視点
テンプレートが10ファイルを超えてくると、「どのファイルがどのページに対応しているか」を把握するだけで時間がかかるようになる。
特に複数人でサイトを管理している場合、ファイルの役割が暗黙知になっていると、誰かが誤ったファイルを編集してしまうリスクが高まる。テンプレートの整理は、技術的な問題であると同時に、チームの運用効率の問題でもある。
整理の基準として有効なのは、「このテンプレートは本当に独自のレイアウトが必要か」という問いを立てることだ。条件分岐で対応できるレベルの差異であれば、ファイルを分けるよりも既存テンプレートを拡張する方が管理しやすい場合もある。
テンプレートを整理する際の判断軸を示すと、次のようになる。
- レイアウトが根本的に異なる → 専用テンプレートファイルを作成
- 表示する情報の一部が異なる → 条件分岐またはテンプレートパーツで対応
- スタイルだけが異なる → CSSのクラス切り替えで対応
- 将来的に廃止が見込まれる投稿タイプ → ファイルを増やさず条件分岐で対応
マーケティング視点で見る投稿タイプ設計
WordPress 投稿タイプごとにテンプレート変更を検討する際、技術的な実装方法だけでなく、マーケティング戦略との整合性を考えることが重要になる。
投稿タイプの設計は、サイトがどのようなコンテンツをどのユーザーに届けるかという情報設計に直結している。
たとえば、採用情報ページと製品紹介ページでは、ターゲットとなるユーザーも、コンバージョンの定義もまったく異なる。採用情報ページでは「応募する」というCTAが最重要だが、製品ページでは「詳細を見る」「購入する」という導線が優先される。
こうした違いをテンプレートレベルで実装しておくことで、コンテンツ担当者が投稿を作成するだけで自然に最適なレイアウトが適用される状態を作れる。これはコンテンツ運用の効率化にも直結する。
SEO観点でも、投稿タイプごとに構造化データ（Schema.org）を最適化しやすくなるメリットがある。ブログ記事にはArticleスキーマ、商品にはProductスキーマ、求人情報にはJobPostingスキーマを適用するといった対応が、テンプレートを分けることで格段にやりやすくなる。
投稿タイプの設計段階から「このコンテンツはどんな体験を提供するか」を考えておくと、後からテンプレートを大幅に作り直す手間を減らせる。技術的な実装とマーケティング戦略を最初から連動させて考えることが、長期的なサイト運用においては合理的な判断だと言える。
最後に
WordPress 投稿タイプごとにテンプレート変更を行う方法には、ファイル名による制御・条件分岐・テンプレートパーツの活用という複数のアプローチがある。
どれが正解かは、サイトの規模・チームの体制・将来の拡張計画によって変わってくる。
大切なのは、「なぜこの投稿タイプには専用テンプレートが必要か」という理由を明確にしてから実装に入ることだ。理由が曖昧なままファイルを増やしていくと、後から整理が難しくなる。
テンプレート設計は、一度作ったら終わりではなく、サイトの成長に合わせて見直し続けるものだと考えると、運用コストとのバランスも取りやすくなる。どのアプローチを選ぶにせよ、「管理できる複雑さ」の範囲内に収めることが、長く続けられるWordPress運用の基本になる。
【参照・引用元】
- テンプレート階層 – Japanese Team – WordPress.org 日本語
- register_post_type() – Function | Developer.WordPress.org
- get_template_part() – Function | Developer.WordPress.org
- is_singular() – Function | Developer.WordPress.org
- is_post_type_archive() – Function | Developer.WordPress.org
- WordPressでカスタム投稿タイプ用テンプレートを作成するルールと手順 | 大阪 ホームページ制作 株式会社TREVOの技術ブログ
- 【WordPress】get_header()・get_footer()などのテンプレートタグまとめ＋include/requireとの違いも解説！ – Yagi-System
- JobPosting – Schema.org Type
- WordPressのテンプレート階層とは？優先順位のルールを徹底解説！ | wp.geek
