ポッドキャストゲストディレクトリの構築：137のプロフィール、1つのデータベース
ポッドキャストゲストディレクトリの構築：137プロフィール、1つのデータベース
ほとんどのポッドキャストゲストディレクトリはSaaSプラットフォームです。一般的な検索には十分ですが、特定のもの（例えば、独自のポッドキャストエコシステムに結びついたキュレーションされたブランド化されたディレクトリ）が必要になると機能しなくなります。これはまさにWP Legendsが直面していた問題です。彼らは自分たちのショーに出演した137人のWordPressエキスパートを持っていて、リスナー（および潜在的なスポンサー）が専門知識、エピソード、およびトピックでゲストを参照できる検索可能でフィルタリング可能なデータベースが必要でした。サードパーティのリスティングではなく、独自のドメイン上で、独自のブランド下で、独自のものを。
私たちがそれを構築しました。以下は、その方法、理由、および異なることについてです。
目次
- 既存のポッドキャストゲストディレクトリの問題
- WP Legends：プロジェクト概要
- アーキテクチャの決定
- ゲストプロフィールのデータモデリング
- 検索とフィルタリングの実装
- パフォーマンスとスケーリングの考慮
- ディレクトリプラットフォームとアプローチの比較
- 構築を通じて学んだこと
- FAQ
既存のポッドキャストゲストディレクトリの問題
構築に深入りする前に、WP Legendsが既存のプラットフォームを使用しなかった理由を理解するのに役立ちます。そのようなプラットフォームはたくさんあります：
- PodcastGuests.comは42,000人以上のユーザーを持ち、2020年以来19,000件以上のインタビューを促進しています
- PodMatchはAI駆動のマッチングとデーティングアプリスタイルのインターフェースを使用し、ポッドキャストコミュニティで強い牽引力を持っています
- Rephonicは300万以上のポッドキャストをリスナーの人口統計とダウンロード推定値とともにインデックスしています
- MatchMaker.fmは25,000人以上のメンバーのコミュニティを提供しています
- RadioGuestList.comは2008年からリバースモデル（ホストがリクエストを投稿し、ゲストが申請する）を実行しています
これらのプラットフォームは実際の問題を解決します：まだ出会ったことのないゲストとホストを結びつけます。しかし、WP Legendsは異なるニーズを持っていました。彼らはすでに137人にインタビューしていました。彼らはそれらのゲスト（彼らの専門知識、彼らのエピソード出演、他のショーのための彼らの利用可能性）をWP Legendsサイト自体に住む方法で紹介したかったのです。
これを同窓生ディレクトリとして考えてください。ブランド化され、検索可能で、ポッドキャストの既存のコンテンツと深く統合されています。
既製のプラットフォームはそれを提供していません。あなたのドメイン権限、デザインシステム、またはデータの所有権を犠牲にしない限り。
WP Legends：プロジェクト概要
WP Legendsはwords Pressエコシステムに焦点を当てたポッドキャストです—開発者、エージェンシー所有者、プラグイン作成者、テーマデザイナー、コミュニティリーダー。3年間のエピソードの後、彼らは印象的なゲストの名簿を持っていましたが、その名簿をビジターに表示する良い方法がありませんでした。
簡潔でした：
- 137人のゲストプロフィールすべての検索可能なディレクトリ
- 専門知識領域（開発、デザイン、ビジネス、コミュニティなど）でフィルタリング可能
- 各プロフィールは、彼らが出演したエピソード（単数または複数）にリンクします
- ゲストプロフィールには、バイオ、ヘッドショット、ソーシャルリンク、および専門知識領域が含まれます
- 高速。本当に高速。このサイズのディレクトリには読み込みスピナーはありません。
- SEOフレンドリー—各ゲストプロフィールは独自のインデックス可能なページである必要があります
- WP Legendsチームがエピソードを公開する際に新しいゲストを簡単に追加できます
予算は控えめでした。タイムラインは厳しかった。通常はこのようなものです。
なぜ単なるWordPressプラグインではないのか？
公正な質問。WP Legendsはすでにwords Pressを使用していたため、GravityForms +カスタム投稿タイプ、またはBusiness Directory Pluginのようなディレクトリプラグインを使用しないのはなぜですか？
私たちはそれを検討しました。しかし、words Pressプラグインのルートには3つの問題がありました：
- パフォーマンス—複数のタクソノミーフィルターを備えた137以上のプロフィールでのwords Press上のクライアント側検索は、特に共有ホスティング上で高速に遅くなります
- デザインの柔軟性—ほとんどのディレクトリプラグインは独自のマークアップとスタイリングを課します。WP Legendsは維持したい特定のデザイン言語を持っていました
- 将来のスケール—137以上のプロフィール拡張を計画していました。アーキテクチャは劣化なしに500以上を処理する必要がありました
代わりにヘッドレスに行きました。
アーキテクチャの決定
私たちが着地したスタック：
- ヘッドレスCMSとしてのwords Press—WP Legendsはwords Press管理にすでに慣れていました。それを引き裂く理由はありません。WPGraphQLを使用してデータを公開し、コンテンツバックエンドのみとして設定しました。
- Next.jsフロントエンド—ディレクトリページ、検索インターフェース、個別のゲストプロフィール用。SEO用のサーバーサイドレンダリング、高速フィルタリング用のクライアント側レンダリング。
- 検索用のAlgolia—137プロフィールはAlgoliaを「必要」としません。しかし、インスタント検索UXとファセットフィルタリングは、エクスペリエンスをプレミアムに感じさせました。このスケールでは、あなたは自由層内で快適にいます。
これはヘッドレスCMSのアプローチが本当に輝くプロジェクトの種類です。コンテンツチームは既に知っているインターフェース（words Press管理）で作業し、フロントエンドチームはプレゼンテーションとパフォーマンスを完全に制御できます。
Next.jsをAstroより選ぶ理由は何ですか？
私たちはこれについて議論しました。主にコンテンツ駆動型のディレクトリでは、Astroは強い選択肢となっていただろう—より小さなJavaScriptバンドル、優れた静的生成、および優れた箱から出てくるパフォーマンス。
しかし、対話的な検索とフィルタリングの要件は私たちをNext.jsに押しやりました。ディレクトリリスティングページは、ページをリロードせずにリアルタイムフィルタリングが必要で、Next.jsのハイブリッドレンダリングモデル（個別プロフィール用の静的ページ、検索用の動的レンダリング）がより清潔なフィットでした。
ディレクトリが純粋にブラウズベースで検索がなかった場合、Astroが勝つでしょう。
ゲストプロフィールのデータモデリング
データモデルを正しく取得することは重要でした。各ゲストプロフィールに含まれるもの：
type GuestProfile {
id: ID!
name: String!
slug: String!
bio: String!
headshot: MediaItem
expertise: [ExpertiseArea!]!
socialLinks: SocialLinks
episodes: [Episode!]!
website: String
availableForGuesting: Boolean
location: String
company: String
role: String
featuredQuote: String
}
type ExpertiseArea {
name: String!
slug: String!
}
type SocialLinks {
twitter: String
linkedin: String
github: String
mastodon: String
}
type Episode {
title: String!
slug: String!
publishedDate: DateTime!
episodeNumber: Int!
}
words Pressでは、これは次のように翻訳されました：
podcast_guestというカスタム投稿タイプ- 「プラグイン開発」、「エージェンシー運営」、「テーマデザイン」、「コミュニティ構築」、「WordPressコア」、「WooCommerce」、「パフォーマンス最適化」のような用語を持つ
expertise_areaというカスタムタクソノミー - 構造化データ用のACF（Advanced Custom Fields）—ソーシャルリンク、会社、役割、注目の引用、利用可能性トグル
- ゲストをエピソード（別のカスタム投稿タイプでした）に接続する関係フィールド
WPGraphQL + ACF統合はこのすべてをきれいに公開しました。1つのGraphQLクエリはプロフィールページに必要なすべてを取得します。
query GetGuest($slug: String!) {
guestBy(slug: $slug) {
title
guestFields {
bio
company
role
website
availableForGuesting
featuredQuote
socialLinks {
twitter
linkedin
github
}
}
expertiseAreas {
nodes {
name
slug
}
}
featuredImage {
node {
sourceUrl
altText
}
}
relatedEpisodes {
nodes {
title
slug
date
}
}
}
}
検索とフィルタリングの実装
ここはプロジェクトが興味深くなったところです。137プロフィールはそれほど多くのデータではありませんが、UX期待は高かったです。WP Legendsチームは、eコマースサイトで見られるようなインスタント、ファセット検索を望んでいました—キーワードを入力し、カテゴリをクリックし、結果がすぐに更新されるのを見てください。
Algolia統合
カスタム同期スクリプトを使用して、words PressコンテンツをAlgoliaに同期しました。これは投稿の公開/更新フックで実行されます。各ゲストプロフィールはAlgoliaレコードになり、検索可能な属性を持ちます：
const guestRecord = {
objectID: guest.id,
name: guest.title,
bio: guest.guestFields.bio,
company: guest.guestFields.company,
role: guest.guestFields.role,
expertise: guest.expertiseAreas.nodes.map(e => e.name),
episodeCount: guest.relatedEpisodes.nodes.length,
available: guest.guestFields.availableForGuesting,
headshot: guest.featuredImage?.node?.sourceUrl,
slug: guest.slug,
};
フロントエンドでは、カスタムウィジェットでAlgoliaのInstantSearchReactライブラリを使用しました：
import { InstantSearch, SearchBox, RefinementList, Hits } from 'react-instantsearch';
import { algoliasearch } from 'algoliasearch';
const searchClient = algoliasearch('APP_ID', 'SEARCH_KEY');
export default function GuestDirectory() {
return (
<InstantSearch searchClient={searchClient} indexName="podcast_guests">
<SearchBox placeholder="Search guests by name, topic, or expertise..." />
<RefinementList attribute="expertise" />
<Hits hitComponent={GuestCard} />
</InstantSearch>
);
}
検索結果は50ミリ秒未満で更新されます。137レコードでは、これは率直に言って過度です—しかし、Algoliaのインスタント結果と従来のフォーム送信検索の間のUX差は昼と夜です。
Algoliaをスキップできますか？
もちろん。137プロフィールの場合、すべてのデータをビルド時にロードし、Fuse.jsまたは単純なArray.filter()のような何かでクライアント側フィルタリングを行うことができます。私たちは実際に最初にこのアプローチをプロトタイプ化しました。
とにかくAlgoliaに行った理由：WP Legendsチームは、タイプミス許容度、同義語マッチング（「ecommerce」を検索すると「WooCommerce」に一致する必要があります）、およびエピソード数による結果の重み付けを望んでいました。それを最初からよくやることはAlgoliaの無料層を使用するよりも多くの仕事です。
137レコードでは、あなたはAlgoliaの無料プラン内で十分です（月あたり10,000検索、10,000レコード）。
パフォーマンスとスケーリングの考慮
プロフィールページの静的生成
137人のゲストプロフィールの各々は、Next.js generateStaticParamsを使用してビルド時に静的に生成されます。これはつまり：
- すべてのゲストプロフィールは200ミリ秒未満でロード（リクエスト時のサーバー側計算なし）
- 各ページは検索エンジンによって完全にインデックス可能です
- Core Web Vitalsは優れています—LCP 1.2秒未満、CLS 0、FID 50ミリ秒未満
export async function generateStaticParams() {
const guests = await getAllGuestSlugs();
return guests.map((guest) => ({
slug: guest.slug,
}));
}
ISR（段階的な静的再生成）
60秒の再検証ウィンドウを備えた段階的な静的再生成を使用します。WP Legendsチームがwords Pressに新しいゲストを追加すると、ディレクトリページと新しいプロフィールページは1分以内に再生成されます—手動デプロイは不要です。
500以上のプロフィールはどうですか？
アーキテクチャは変更なしでこれを処理します。Algoliaは有料プランでレコード数百万にスケーリングします。Next.jsの静的生成は定期的に数千ページを処理します。ACFを持つwords Press管理はこのスケールで問題なく機能します。500以上で追加したい唯一のことは、ディレクトリリスティングのページネーションまたは無限スクロール（InstantSearchは箱から出てくるときに処理します）です。
ディレクトリプラットフォームとアプローチの比較
カスタムビルドアプローチが既存のプラットフォームを使用することとどのように積み重ねるか：
| 要因 | SaaSディレクトリ（PodMatch等） | words Pressプラグイン | カスタムヘッドレスビルド |
|---|---|---|---|
| セットアップ時間 | 分 | 時間 | 日から数週間 |
| 月額費用 | 無料–$50/月 | 無料–$100（プラグインライセンス） | ホスティングのみ（$0–20/月） |
| ブランドコントロール | 最小限 | 中程度 | 完全 |
| SEO利点 | なし（自分たちのドメイン上に住んでいる） | フル | フル |
| データ所有権 | 限定的（プラットフォーム） | フル | フル |
| 検索品質 | 良い（彼らのテク） | 基本から中程度 | 優れている（Algolia等） |
| デザインの柔軟性 | 低い | 低から中程度 | 無制限 |
| コンテンツチームUX | 個別ログイン、別のインターフェース | words Press管理 | words Press管理 |
| 500以上のプロフィールへのスケール | はい | 低下 | はい |
| メンテナンスの負担 | なし（SaaSが処理） | プラグイン更新、競合 | フロントエンド + CMS更新 |
正直なところ：ポッドキャストゲストとして発見されたいだけなら、PodMatchまたはPodcastGuests.comにサインアップしてください。彼らは無料で彼らは働きます。しかし、あなたがディレクトリを所有したい場合—それがあなたのブランドとコンテンツ戦略の中核の一部であれば—カスタムビルドはそれの価値があります。
構築を通じて学んだこと
コンテンツ移行は難しい部分でした
技術的なビルドには約2週間かかりました。137個のゲストプロフィール移行—正しいヘッドショット、現在のバイオ、正確なソーシャルリンク、検証済みの専門知識タグの収集—には3週間かかりました。教訓：コードよりもコンテンツにより多くの時間をかけてください。常に。
「ゲスティングに利用可能」トグルは天才でした
これは後の追加でした。各ゲストプロフィールにはブール値フィールドがあります：「他のポッドキャスト用に利用可能ですか？」オプトインするゲストは自分たちのプロフィールで微妙なバッジを取得します。これは、ディレクトリを遡及的なアーカイブから実時間リソースに変えました。他のポッドキャストホストはそれを使用してwords Pressゲストを見つけ始めました。
その単一の機能は、他のすべてよりもディレクトリにより多くのトラフィックを駆動しました。
スキーママークアップが重要です
各ゲストプロフィールページに人物スキーママークアップを追加しました：
{
"@context": "https://schema.org",
"@type": "Person",
"name": "Guest Name",
"jobTitle": "Role",
"worksFor": {
"@type": "Organization",
"name": "Company"
},
"url": "https://wplegends.com/guests/guest-slug",
"sameAs": [
"https://twitter.com/handle",
"https://linkedin.com/in/handle"
]
}
2ヶ月以内に、複数のゲストプロフィールが名前検索のためのGoogleのナレッジパネルに表示されていました。これは、サードパーティのディレクトリプラットフォームが提供できない接線的なSEO勝利です。
タクソノミーをオーバーエンジニアリングしないでください
私たちは23の専門知識カテゴリで始まりました。それは多すぎました。137プロフィールだけでは、ほとんどのカテゴリは5未満のエントリを持っていました—フィルタリングが壊れているように見えるのはこのためです。私たちは8つの幅広いカテゴリに統合し、UXはすぐに改善されました。
良い経験則：各フィルターオプションは有用に感じるために少なくとも10の結果を返すべきです。それに応じてタクソノミーを調整します。
6ヶ月後の結果
WP Legendsがディレクトリがライブになってから6ヶ月後に共有した数字：
- ディレクトリページはサイトへの有機トラフィックの34%を占めています
- ディレクトリの平均時間：3分42秒—人々は実際に閲覧します
- 他のwords Pressブログからの47の内部リンク特定のゲストプロフィール参照
- 12ゲスト予約リクエスト他のポッドキャストホストからディレクトリを通じて来ました
- Core Web Vitals：モバイルとデスクトップの両方ですべてのページが合格
それは複合する内容資産です。すべての新しいエピソードはディレクトリに新しいインデックス可能なページを追加します。
FAQ
カスタムポッドキャストゲストディレクトリを構築するのにどのくらいの費用がかかりますか？
このようなプロジェクト—137プロフィール、検索可能でフィルタリング可能、ヘッドレスwords PressとNext.jsフロントエンド—の場合、設計の複雑さとコンテンツ移行のニーズに応じて、$8,000–$15,000の範囲で構築コストを見ています。進行中のホスティングコストは最小限です：Vercelの無料層はフロントエンドを処理し、管理されたwords Pressホスティングは$20–50/月実行されます。現在のヘッドレスプロジェクト推定については、価格ページを確認してください。
just words Pressとヘッドレスセットアップなしでゲストディレクトリを構築できますか？
はい、トレードオフですが。FacetWPのようなカスタム投稿タイプとACFおよびディレクトリプラグインを使用したフィルタリングは、より小さなディレクトリ（50プロフィール未満）に機能します。それ以上では、特に共有ホスティング上でwords Pressのフロントエンドパフォーマンスの制限と戦い始めます。ヘッドレスアプローチは事前により高いコストですが、はるかによくスケーリングします。
小さなディレクトリ（200レコード未満）の最良の検索ソリューションは何ですか？
200レコード未満の場合、3つの堅実なオプション：Algoliaの無料層（月10,000検索、10,000レコード）、Fuse.jsを使用したクライアント側検索（ゼロコスト、オフラインで機能）、またはMeilisearchセルフホスト（オープンソース、高速）。Algoliaはタイプミス許容度とファセットフィルタリングを備えた最良のアウトオブザボックスUXを提供します。Fuse.jsはファジーマッチングが不要な場合、実装が最も単純です。
ポッドキャストゲストに独自のプロフィールデータを送信してもらうようにするにはどうしますか？
WP Legendsのアプローチは賢かった：彼らは各過去のゲストに短い形式（Gravity Formsで構築）を送信し、現在のバイオ、ヘッドショット、ソーシャルリンク、および専門知識領域を求めました。フォーム送信は、チームがレビューするためのドラフトゲストプロフィールとしてwords Pressに直接給餌しました。約80%のゲストは2つのメールフォローアップ以内に応答しました。人々は一般的にリストされたいです—それは彼らのための無料プロモーションです。
PodMatchのようなSaaSプラットフォームを使用する代わりに、独自のディレクトリを構築する必要がありますか？
あなたの目標によります。あなたのショーのために新しいゲストを見つけたい場合、PodMatchとPodcastGuests.comは優れており、ほぼ無料です。既存のゲストを独自のドメイン上のコンテンツ資産として紹介したい場合、カスタムビルドが必要です。彼らは異なる問題を解決します。多くのポッドキャストは両方を使用します。
個別のゲストプロフィールページのSEOをどのように処理しますか？
各プロフィールページは、一意のタイトルタグ（「ゲスト名—WordPress Expert | WP Legends」）、バイオから引き出されたメタディスクリプション、人物スキーママークアップ、およびヘッドショットを備えた人物スキーママークアップを取得します。構造化データと各ページの一意のコンテンツの組み合わせは、それらをインデックス可能で名前ベースの検索に競争力のあるものにします。私たちは4-8週間以内にゲストの名前のゲストプロフィールを1ページでランク付けされているのを見てきました。
ポッドキャストディレクトリに最適なヘッドレスCMSは何ですか？
words Press（WPGraphQL使用）は、あなたのチームがwords Pressをすでに知っている場合、ビートするのは難しいです。カスタム投稿タイプとACFを使用したコンテンツモデリングは柔軟で、エコシステムは巨大です。words Pressの専門知識から始めていない場合、SanityまたはContentfulは、構造化されたコンテンツのためのより良い開発者体験を備えた強い代替案です。ヘッドレスCMS開発ページで詳細にオプションをカバーしています。
ゲストプロフィールを時間とともに更新し続けるようにするにはどうしますか？
これはつまらない部分です。簡単な年間レビューワークフローを構築しました：年に一度、システムは各ゲストに自分たちのプロフィール情報を更新するリンク付きのメールを送信します。約60%が応答します。残りの場合、WP Legendsチームは簡単に手動チェックを行います—会社と役割がまだ正確であることを確認し、壊れたソーシャルリンクを更新します。137プロフィールでは、四半期ごとに約2時間かかります。メンテナンスはゼロではありませんが、管理可能です。