is_post_type_archive()で事例一覧ページの構造化データを出し分ける方法｜小売ECの検索リッチ表示とSEO

2026.08.10

小売ECのコーポレートサイトやオウンドメディアでは、通常のブログ記事とは別に「導入事例」「制作実績」「お客様の声一覧」といったカスタム投稿タイプのアーカイブページを用意していることがよくあります。ところが、こうしたアーカイブページは通常の記事一覧と同じテンプレート・同じ構造化データがそのまま流用されてしまい、検索結果でのリッチ表示の機会を逃しているケースが少なくありません。

WordPressには、現在表示中のページがカスタム投稿タイプのアーカイブページであるかどうかを判定する is_post_type_archive() という条件分岐タグがあります。この関数を使うことで、事例一覧などのアーカイブページだけに専用のパンくずリストや構造化データ（JSON-LD）を出し分ける実装が可能になります。

この記事では、is_post_type_archive() の正確な仕様を確認したうえで、小売事業者向けのWordPressサイトで事例一覧ページの構造化データを設計し、検索結果でのリッチ表示とSEO評価の両方を狙うための考え方を解説します。

この記事で分かること

  • is_post_type_archive() の正確な仕様と判定範囲
  • 投稿タイプアーカイブに構造化データを出し分ける設計
  • パンくずリストと構造化データを一致させる方法
  • 複数のカスタム投稿タイプが混在するサイトでの注意点
  • 検索結果のリッチ表示を狙うための周辺整備

is_post_type_archiveが小売ECの集客で重要になる理由

検索エンジンは、ページの内容を構造化データによって機械的に理解しようとします。事例一覧やお客様の声一覧のようなページは、単なる記事の集合ではなく「特定のカテゴリの情報がまとまったコレクションページ」としての性質を持ちます。この性質に合わせた構造化データ（CollectionPageやItemListなど）を提供できているかどうかで、検索結果の見え方が変わってくる可能性があります。

ところが多くのWordPressサイトでは、通常の投稿一覧テンプレート（archive.phpなど）がカスタム投稿タイプのアーカイブにもそのまま適用され、パンくずリストや構造化データも通常のブログ一覧と同じロジックで出力されてしまいます。これは、検索エンジンに対して「このページが何のコレクションなのか」を正しく伝えられていない状態です。

is_post_type_archive() を使えば、こうした汎用テンプレートの中でも「今表示しているのは事例一覧なのか、通常のブログ一覧なのか」を判定し、出力する構造化データやメタ情報を切り替えることができます。これは、SEOの技術的な整備としても、検索結果での見え方を改善する施策としても重要な起点になります。

  • 事例一覧はコレクションページとしての構造化データが求められる
  • 汎用テンプレートのままだと構造化データが実態と合わなくなる
  • 検索結果のリッチ表示は構造化データの正確さに左右されやすい
  • 投稿タイプごとに異なる情報設計が必要になる

is_post_type_archive()の役割を実務目線で理解する

is_post_type_archive() は、現在のクエリが「既存の投稿タイプのアーカイブページ」であるかどうかを判定する関数です。引数 $post_types は省略可能で、文字列（投稿タイプ名）または配列（複数の投稿タイプ名）を渡せます。戻り値は真偽値です。

if ( is_post_type_archive() ) {
    // 何らかの投稿タイプのアーカイブページであれば真
    echo 'この投稿タイプのアーカイブページです';
}

引数に投稿タイプ名を渡すことで、判定を特定の投稿タイプに絞り込めます。例えば「case_study」という投稿タイプの一覧ページだけを対象にしたい場合は、次のように書きます。

if ( is_post_type_archive( 'case_study' ) ) {
    // 事例紹介の一覧ページ専用の構造化データを出力する
    get_template_part( 'schema', 'case-study-archive' );
} elseif ( is_post_type_archive( array( 'voice', 'review' ) ) ) {
    // お客様の声・レビュー系のアーカイブページ専用の処理
    get_template_part( 'schema', 'voice-archive' );
}

ここで注意すべきなのは、引数を渡さずに is_post_type_archive() を呼び出すと、対象が「いずれかの投稿タイプのアーカイブページ全般」になる点です。複数のカスタム投稿タイプを運用しているサイトで、引数なしの判定だけで分岐ロジックを組んでしまうと、意図しない投稿タイプのアーカイブにまで同じ構造化データが適用されてしまうアンチパターンに陥ります。事例一覧専用の処理を書きたい場合は、必ず投稿タイプ名を明示して絞り込む必要があります。

また、is_post_type_archive() はタクソノミー（カテゴリやカスタムタクソノミー）のアーカイブとは判定対象が異なります。カテゴリアーカイブを判定したい場合は is_category() や is_tax() を使う必要があり、is_post_type_archive() では判定できません。混同すると、意図した分岐が発生しないバグにつながるため、投稿タイプのアーカイブなのかタクソノミーのアーカイブなのかを実装前に整理しておくことが重要です。

小売事業者のインバウンド集客に落とし込む考え方

事例一覧ページに専用の構造化データを出す設計

導入事例や制作実績の一覧ページは、単なる記事リストではなく「実績のコレクション」として検索エンジンに伝えるべきページです。is_post_type_archive() で対象を判定し、CollectionPageやItemListといった構造化データを出力することで、ページの性質を正確に伝えられます。

この設計を行う際は、一覧に含まれる各事例（投稿）の情報も合わせてItemListElementとして構造化することを検討します。事例のタイトル、概要、実施時期などをリスト内の各要素に反映させることで、より詳細な情報として検索エンジンに渡せます。

  • 事例一覧をCollectionPage/ItemListとして構造化する
  • 各事例の要約情報をリスト要素に反映する
  • 通常の記事一覧とは別の構造化データテンプレートを用意する

パンくずリストと構造化データを一致させる

構造化データの中でもBreadcrumbListは、検索結果でのパンくず表示に直結する要素です。is_post_type_archive() の判定に合わせてパンくずの表示ロジックを切り替えることで、画面上のパンくずリストとBreadcrumbList構造化データの内容を一致させられます。

この一致がずれていると、検索エンジンが提供する情報の信頼性が下がるだけでなく、ユーザーが実際にクリックした際の導線と、検索結果に表示されるパンくずの期待値がズレてしまいます。事例一覧ページであれば「トップ＞事例一覧」、個別事例であれば「トップ＞事例一覧＞事例名」といった形で、画面表示と構造化データの階層を揃えることが基本です。

  • 画面上のパンくずとBreadcrumbListの階層を一致させる
  • 投稿タイプアーカイブ用のパンくずロジックを個別に用意する
  • 個別記事側の階層表示ともセットで整合を取る

投稿タイプごとに出し分けるJSON-LDテンプレートを設計する

複数のカスタム投稿タイプ（事例、お客様の声、導入企業一覧など）を運用している場合、それぞれのアーカイブページで求められる構造化データの種類は異なります。is_post_type_archive() の引数に投稿タイプ名や配列を渡すことで、投稿タイプごとに異なるJSON-LDテンプレートを呼び分ける設計が可能になります。

この設計をテーマファイルの一箇所に集約しておくと、新しい投稿タイプを追加した際にも構造化データの対応漏れを防ぎやすくなります。逆に、個別テンプレートファイルごとにバラバラに構造化データを埋め込んでしまうと、投稿タイプが増えるたびに実装が散らばり、メンテナンス性が下がります。

  • 投稿タイプ別のJSON-LDテンプレートを一元管理する
  • 新規投稿タイプ追加時の対応フローを決めておく
  • 出力ロジックをテーマの共通ファイルにまとめる

検索結果のリッチ表示を狙うために必要な周辺情報を整える

構造化データを正しく出力するだけでなく、Google Search Consoleでのエラー確認や、リッチリザルトテストでの検証も欠かせません。is_post_type_archive() による出し分けを実装した後は、実際に該当ページの構造化データが意図通りに出力されているかを継続的に確認する運用が必要です。

また、構造化データはあくまで検索エンジンへの補助情報であり、リッチ表示を保証するものではありません。ページ自体のコンテンツの質、更新頻度、内部リンクの充実度といった基本的なSEO要素と合わせて評価されることを前提に、構造化データの整備を位置づけておくことが重要です。

  • 構造化データの出力を定期的に検証する
  • リッチリザルトテスト等でエラーを確認する
  • コンテンツの質と合わせて評価される前提を持つ

複数CPTが混在するサイトでの判定ミスを防ぐ

事例、お客様の声、導入企業一覧など複数のカスタム投稿タイプを扱うサイトほど、is_post_type_archive() の引数を省略した判定に依存してしまうと、意図しない投稿タイプにまで同じロジックが適用されるリスクが高まります。投稿タイプが増えるほど、引数を明示した判定の重要性が増します。

この対策として、投稿タイプ名を配列やマッピングで一元管理し、テンプレート内で使い回す設計が有効です。投稿タイプ名の文字列をあちこちに直書きしてしまうと、リネームや追加のたびに修正漏れが発生しやすくなります。

  • 投稿タイプ名は一元的な設定として管理する
  • 引数を省略した判定を安易に使わない
  • 投稿タイプの追加・変更時に影響範囲を洗い出す

運用イメージ（架空パターン）

理解を深めるために、あくまで仮のケースとして運用イメージを描いてみます。例えば、什器や店舗備品を扱う仮のC社が、コーポレートサイトに「導入事例（case_study）」というカスタム投稿タイプを追加したとします。

導入当初、C社の事例一覧ページは通常のブログ一覧テンプレートを流用しており、構造化データも標準のBlogPosting系のまま出力されていたとします。そこで担当者は is_post_type_archive( ‘case_study’ ) を使って事例一覧ページを判定し、CollectionPageとしての構造化データ、および事例一覧専用のパンくずロジックを実装したとします。

あわせて、個別の事例記事側にもArticleとBreadcrumbListの構造化データを整備し、一覧と個別ページの階層が一致するように調整したとします。実装後は、Google Search Consoleの拡張性レポートで構造化データのエラーが解消されているかを定期的に確認する運用に切り替えたとします。

このような仮の対応を行った場合、事例一覧ページが検索エンジンにとって「実績のコレクション」として認識されやすくなり、事例関連の検索クエリでの見え方が改善する可能性があると考えられます。あくまで仮のシナリオですが、投稿タイプ単位で構造化データを出し分ける意義のイメージとして参考にしてください。

実装・運用の進め方

  • サイト内のカスタム投稿タイプと、それぞれのアーカイブページを洗い出す
  • is_post_type_archive()を使った投稿タイプ別の判定ロジックを実装する
  • 投稿タイプごとに適した構造化データ（CollectionPage、ItemListなど）を設計する
  • パンくずリストと構造化データの階層を一致させる
  • Google Search Consoleやリッチリザルトテストで検証する
  • 新規投稿タイプ追加時の対応フローをドキュメント化する

よくある失敗と回避策

  • is_post_type_archive()を引数なしで使い、意図しない投稿タイプにも同じ処理が適用される
  • タクソノミーアーカイブとの判定を混同し、is_category()やis_tax()で対応すべき箇所を誤って実装する
  • 画面上のパンくずと構造化データの階層が一致していない
  • 構造化データを実装したまま検証を怠り、エラーに気づかない
  • 投稿タイプ名を各所に直書きし、変更時に修正漏れが発生する

社内で持つべき判断軸

  • どの投稿タイプのアーカイブがリッチ表示を狙う優先度が高いか
  • 構造化データの出力ロジックを誰がメンテナンスするか
  • 新規投稿タイプ追加時に構造化データ対応をどう組み込むか
  • 検証作業をどの頻度で行うか

成果測定で見るべき指標

  • Search Consoleの拡張性レポートにおける構造化データのエラー件数
  • 事例一覧・お客様の声一覧ページの検索流入数の推移
  • リッチリザルトテストでの検証結果
  • 事例一覧経由の個別記事へのクリック率
  • 事例一覧経由の問い合わせ・資料請求のCV数

よくある質問

is_post_type_archive()に引数を渡さないとどうなりますか

引数を省略すると、現在のページがいずれかの投稿タイプのアーカイブページであれば真を返します。特定の投稿タイプだけを対象にしたい場合は、必ず投稿タイプ名を文字列または配列で指定する必要があります。

is_post_type_archive()とis_archive()の違いは何ですか

is_archive()はカテゴリ・タグ・日付・投稿者・投稿タイプなど、あらゆる種類のアーカイブページで真を返す包括的な判定です。is_post_type_archive()はその中でも投稿タイプのアーカイブページに限定した判定を行います。

カテゴリアーカイブの判定にis_post_type_archive()は使えますか

使えません。カテゴリやタグ、カスタムタクソノミーのアーカイブページを判定したい場合は、is_category()、is_tag()、is_tax()といった別の条件分岐タグを使う必要があります。

構造化データを出し分けるとSEOの順位は必ず上がりますか

構造化データの整備は検索エンジンにページの内容を正確に伝える施策であり、順位上昇を直接保証するものではありません。コンテンツの質や内部リンクなど他の要素と合わせて評価される前提で取り組むべきです。

投稿タイプを追加するたびに構造化データの実装は必要ですか

新規投稿タイプのアーカイブページが検索流入を狙う対象であれば、構造化データの対応を検討すべきです。すべての投稿タイプに一律で必要というわけではなく、優先度に応じて判断します。

is_post_type_archive()はテーマファイルのどこで使うのが一般的ですか

archive.phpや投稿タイプ専用のアーカイブテンプレート（archive-{post_type}.php）、またはheadタグ内で構造化データを出力する共通テンプレートの中で使うのが一般的です。

EC制作・EC広告の相談先を探している小売事業者の方へ

ここまで解説した設計や実装は、単体の関数を知るだけでは十分ではありません。実際の集客成果につなげるには、商品データの持ち方、カテゴリやタグの設計、記事導線、内部リンク、コンバージョン導線、広告配信先の整合まで含めて一貫して設計する必要があります。

自社ECの制作、既存WordPressサイトの改善、Shopifyや基幹システムとの連携、広告運用と連動した特集ページ制作までまとめて整理したい場合は、事業構造に合わせた設計が重要です。運用負荷を抑えながら売上につながる情報設計を進めたい場合は、要件整理の段階から相談できる体制を持っておくと失敗を減らせます。

まとめ

is_post_type_archive() は、カスタム投稿タイプのアーカイブページを正確に判定し、そのページの性質に合った構造化データを出し分けるための起点になる関数です。事例一覧やお客様の声一覧を通常のブログ一覧と同じ扱いにせず、専用の構造化データとパンくず設計を行うことで、検索結果でのリッチ表示とSEO評価の両方を狙えます。まずは自社サイトの投稿タイプとアーカイブページの構成を棚卸しするところから始めてみてください。

コメント

タイトルとURLをコピーしました