Most podcast guest directories are SaaS platforms. They're fine for general discovery, but they fall apart when you need something specific -- like a curated, branded directory tied to your own podcast's ecosystem. That's exactly the problem WP Legends faced. They had 137 WordPress experts who'd appeared on their show, and they wanted a searchable, filterable database where listeners (and potential sponsors) could browse those guests by expertise, episode, and topic. Not a third-party listing. Their own thing, on their own domain, under their own brand.

We built it. Here's how, why, and what we'd do differently.

Building a Podcast Guest Directory: 137 Profiles, One Database

Table of Contents

The Problem with Existing Podcast Guest Directories

Before diving into the build, it helps to understand why WP Legends didn't just use an existing platform. There are plenty of them:

  • PodcastGuests.com has 42,000+ users and has facilitated over 19,000 interviews since 2020
  • PodMatch uses AI-driven matching with a dating-app style interface and has strong traction in the podcasting community
  • Rephonic indexes over 3 million podcasts with listener demographics and download estimates
  • MatchMaker.fm serves a community of 25,000+ members
  • RadioGuestList.com has been running a reverse-model (hosts post requests, guests apply) since 2008

These platforms solve a real problem: connecting hosts with guests they've never met. But WP Legends had a different need. They'd already interviewed 137 people. They wanted to showcase those guests -- their expertise, their episode appearances, their availability for other shows -- in a way that lived on the WP Legends site itself.

Think of it less like a matchmaking tool and more like an alumni directory. Branded, searchable, and deeply integrated with the podcast's existing content.

No off-the-shelf platform gives you that. Not without sacrificing your domain authority, your design system, or your data ownership.

WP Legends: The Project Brief

WP Legends is a podcast focused on the WordPress ecosystem -- developers, agency owners, plugin creators, theme designers, community leaders. After three years of episodes, they had an impressive roster of guests but no good way to surface that roster to visitors.

The brief was straightforward:

  • A searchable directory of all 137 guest profiles
  • Filterable by expertise area (development, design, business, community, etc.)
  • Each profile links to the episode(s) they appeared on
  • Guest profiles include bio, headshot, social links, and areas of expertise
  • Fast. Really fast. No loading spinners for a directory of this size.
  • SEO-friendly -- each guest profile should be its own indexable page
  • Easy for the WP Legends team to add new guests as episodes publish

The budget was modest. The timeline was tight. That's usually how these things go.

Why Not Just a WordPress Plugin?

Fair question. WP Legends was already on WordPress, so why not use something like GravityForms + a custom post type, or a directory plugin like Business Directory Plugin?

We considered it. But the WordPress plugin route had three issues:

  1. Performance -- Client-side search on WordPress with 137+ profiles and multiple taxonomy filters gets sluggish fast, especially on shared hosting
  2. Design flexibility -- Most directory plugins impose their own markup and styling. WP Legends had a specific design language they wanted to maintain
  3. Future scale -- They planned to expand beyond 137 profiles. The architecture needed to handle 500+ without degradation

We went headless instead.

Building a Podcast Guest Directory: 137 Profiles, One Database - architecture

Architecture Decisions

The stack we landed on:

  • WordPress as headless CMS -- WP Legends was already comfortable with the WordPress admin. No reason to rip that out. We set it up as a content backend only, using WPGraphQL to expose the data.
  • Next.js frontend -- For the directory pages, search interface, and individual guest profiles. Server-side rendering for SEO, client-side filtering for speed.
  • Algolia for search -- 137 profiles doesn't need Algolia. But the instant search UX and faceted filtering made the experience feel premium. And at this scale, you're comfortably within the free tier.

This is the kind of project where a headless CMS approach really shines. The content team works in an interface they already know (WordPress admin), and the frontend team has complete control over presentation and performance.

Why Next.js Over Astro?

We debated this one. For a primarily content-driven directory, Astro would have been a strong choice -- smaller JavaScript bundles, excellent static generation, and great performance out of the box.

But the interactive search and filtering requirements pushed us toward Next.js. The directory listing page needed real-time filtering without page reloads, and Next.js's hybrid rendering model (static pages for individual profiles, dynamic rendering for search) was a cleaner fit.

If the directory were purely browse-based with no search, Astro would've won.

Data Modeling for Guest Profiles

Getting the data model right was critical. Here's what each guest profile contains:

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!
}

In WordPress, this translated to:

  • A custom post type called podcast_guest
  • A custom taxonomy called expertise_area with terms like "Plugin Development", "Agency Operations", "Theme Design", "Community Building", "WordPress Core", "WooCommerce", "Performance Optimization"
  • ACF (Advanced Custom Fields) for structured data -- social links, company, role, featured quote, availability toggle
  • A relationship field connecting guests to episodes (which were another custom post type)

The WPGraphQL + ACF integration exposed all of this cleanly. One GraphQL query gets you everything you need for a profile page.

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
      }
    }
  }
}

Search and Filtering Implementation

This is where the project got interesting. 137 profiles isn't a lot of data, but the UX expectations were high. The WP Legends team wanted the kind of instant, faceted search you see on e-commerce sites -- type a keyword, click a category, see results update immediately.

Algolia Integration

We synced WordPress content to Algolia using a custom sync script that runs on post publish/update hooks. Each guest profile becomes an Algolia record with searchable attributes:

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,
};

On the frontend, we used Algolia's InstantSearch React library with custom widgets:

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>
  );
}

Search results update in under 50ms. For 137 records, this is frankly overkill -- but the UX difference between Algolia's instant results and a traditional form-submit search is night and day.

Could You Skip Algolia?

Absolutely. For 137 profiles, you could load all the data at build time and do client-side filtering with something like Fuse.js or even a simple Array.filter(). We actually prototyped this approach first.

The reason we went with Algolia anyway: the WP Legends team wanted typo tolerance, synonym matching (searching "ecommerce" should match "WooCommerce"), and the ability to weight results by episode count. Doing that well from scratch is more work than just using Algolia's free tier.

At 137 records, you're well within Algolia's free plan (10,000 search requests/month, 10,000 records).

Performance and Scale Considerations

Static Generation for Profile Pages

Each of the 137 guest profiles is statically generated at build time using Next.js generateStaticParams. This means:

  • Every guest profile loads in under 200ms (no server-side computation at request time)
  • Each page is fully indexable by search engines
  • Core Web Vitals are excellent -- LCP under 1.2s, CLS of 0, FID under 50ms
export async function generateStaticParams() {
  const guests = await getAllGuestSlugs();
  return guests.map((guest) => ({
    slug: guest.slug,
  }));
}

ISR for Fresh Data

We use Incremental Static Regeneration with a 60-second revalidation window. When the WP Legends team adds a new guest in WordPress, the directory page and new profile page are regenerated within a minute -- no manual deploys needed.

What About 500+ Profiles?

The architecture handles this without changes. Algolia scales to millions of records on paid plans. Static generation in Next.js handles thousands of pages routinely. The WordPress admin with ACF works fine at this scale. The only thing you'd want to add at 500+ is pagination or infinite scroll on the directory listing, which InstantSearch handles out of the box.

Comparing Directory Platforms and Approaches

Here's how the custom-built approach stacks up against using existing platforms:

Factor SaaS Directory (PodMatch, etc.) WordPress Plugin Custom Headless Build
Setup Time Minutes Hours Days to weeks
Monthly Cost Free–$50/mo Free–$100 (plugin license) Hosting only ($0–20/mo)
Brand Control Minimal Moderate Complete
SEO Benefit None (lives on their domain) Full Full
Data Ownership Limited (their platform) Full Full
Search Quality Good (their tech) Basic to moderate Excellent (Algolia, etc.)
Design Flexibility Low Low to moderate Unlimited
Content Team UX Separate login, separate interface WordPress admin WordPress admin
Scale to 500+ profiles Yes Degrades Yes
Maintenance Burden None (SaaS handles it) Plugin updates, conflicts Frontend + CMS updates

The honest truth: if you just want to be discovered as a podcast guest, sign up for PodMatch or PodcastGuests.com. They're free and they work. But if you want to own the directory -- if it's a core part of your brand and content strategy -- the custom build is worth it.

What We Learned Building This

Content Migration Was the Hard Part

The technical build took about two weeks. Migrating 137 guest profiles -- gathering correct headshots, current bios, accurate social links, verifying expertise tags -- took three weeks. The lesson: budget more time for content than code. Always.

The "Available for Guesting" Toggle Was Genius

This was a late addition. Each guest profile has a boolean field: "Available for other podcasts?" Guests who opt in get a subtle badge on their profile. This turned the directory from a retrospective archive into a live resource. Other podcast hosts started using it to find WordPress guests.

That single feature drove more traffic to the directory than anything else.

Schema Markup Matters

We added Person schema markup to each guest profile page:

{
  "@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"
  ]
}

Within two months, several guest profiles were appearing in Google's knowledge panels for name searches. That's a tangible SEO win that no third-party directory platform can deliver.

Don't Over-Engineer Taxonomy

We started with 23 expertise categories. That was way too many. With only 137 profiles, most categories had fewer than 5 entries -- which makes filtering feel broken. We consolidated down to 8 broad categories, and the UX improved immediately.

A good rule of thumb: each filter option should return at least 10 results to feel useful. Adjust your taxonomy accordingly.

Results After Six Months

The numbers WP Legends shared with us after the directory had been live for six months:

  • Directory pages account for 34% of organic traffic to the site
  • Average time on directory: 3 minutes 42 seconds -- people actually browse
  • 47 inbound links from other WordPress blogs referencing specific guest profiles
  • 12 guest booking requests came through the directory from other podcast hosts
  • Core Web Vitals: all pages passing on both mobile and desktop

That's a content asset that compounds. Every new episode adds a new indexable page to the directory.

FAQ

How much does it cost to build a custom podcast guest directory?

For a project like this -- 137 profiles, searchable and filterable, headless WordPress with a Next.js frontend -- you're looking at a build cost in the range of $8,000–$15,000 depending on design complexity and content migration needs. Ongoing hosting costs are minimal: Vercel's free tier handles the frontend, and managed WordPress hosting runs $20–50/month. Check our pricing page for current headless project estimates.

Can I build a guest directory with just WordPress and no headless setup?

Yes, but with trade-offs. A custom post type with ACF and a directory plugin like FacetWP for filtering works fine for smaller directories (under 50 profiles). Beyond that, you'll start fighting WordPress's front-end performance limitations, especially on shared hosting. The headless approach costs more upfront but scales much better.

What's the best search solution for a small directory (under 200 records)?

For under 200 records, you have three solid options: Algolia's free tier (10,000 searches/month), client-side search with Fuse.js (zero cost, works offline), or Meilisearch self-hosted (open source, fast). Algolia gives you the best out-of-the-box UX with typo tolerance and faceted filtering. Fuse.js is the simplest to implement if you don't need fuzzy matching.

How do I get podcast guests to submit their own profile data?

The WP Legends approach was smart: they sent each past guest a short form (built with Gravity Forms) asking for a current bio, headshot, social links, and expertise areas. The form submissions fed directly into WordPress as draft guest profiles for the team to review. About 80% of guests responded within two email follow-ups. People generally want to be listed -- it's free promotion for them.

Should I use a SaaS platform like PodMatch instead of building my own directory?

It depends on your goal. If you want to find new guests for your show, PodMatch and PodcastGuests.com are excellent and mostly free. If you want to showcase your existing guests as a content asset on your own domain, you need a custom build. They solve different problems. Many podcasters use both.

How do you handle SEO for individual guest profile pages?

Each profile page gets a unique title tag ("Guest Name -- WordPress Expert | WP Legends"), meta description pulled from their bio, Person schema markup, and an Open Graph image featuring their headshot. The combination of structured data and unique content on each page makes them indexable and competitive for name-based searches. We've seen guest profiles rank on page one for the guest's name within 4-8 weeks.

What's the best headless CMS for a podcast directory?

WordPress with WPGraphQL is hard to beat if your team already knows WordPress. The content modeling with Custom Post Types and ACF is flexible, and the ecosystem is massive. If you're starting fresh and don't have WordPress expertise, Sanity or Contentful are strong alternatives with better developer experience for structured content. We cover the options in depth on our headless CMS development page.

How do you keep guest profiles updated over time?

This is the unglamorous part. We built a simple annual review workflow: once a year, the system sends each guest an email with a link to update their profile information. About 60% respond. For the rest, the WP Legends team does a quick manual check -- verify the company and role are still accurate, update any broken social links. It takes about 2 hours per quarter for 137 profiles. Not zero maintenance, but manageable.