Running a Podcast Network

Running several shows under one banner works well in Benecaster, but the decisions that matter are made early — before you’ve created shows and acquired subscribers. This walkthrough covers those decisions in the order you need to make them.

Read Running Multiple Shows first for the mechanics. This page is about structuring a network.

Decide First: One Installation or Several

This is the decision that’s expensive to reverse, so make it deliberately.

One WordPress installation, multiple shows suits a network where you are the operator. One plugin to update, one license, one login, one place to check everything. Cross-show analytics work out of the box. This is the right default for most networks.

Separate installations suit shows that are genuinely separate businesses — different owners, different branding, different people needing admin access. The cost is real: every update, every configuration change, every check happens N times.

The question that usually settles it: does anyone need admin access to one show without getting it to all of them? WordPress roles are site-wide, so a user with Benecaster admin rights on a multi-show installation can administer every show on it. If you need genuine separation between show operators, you need separate installations.

Remember both limits apply — a Multi-Show license allows 3 shows and 3 site activations. See Show Limits.

Set a Naming Convention Before You Create Anything

Feed slugs appear in every subscriber’s feed URL and can’t be changed casually afterwards — changing one changes every subscriber’s URL for that show.

Decide the pattern now and apply it consistently. Whatever you choose, write it down; the point is that show four follows the same rule as show one, two years later.

Per Show, Not Per Network

Each show carries its own identity, and this is where a network either feels coherent or doesn’t:

• Name, artwork, description — per show, and they’re what appear in podcast directories
• Tiers — per show. Shows don’t have to use the same tier structure, but there’s a strong argument for consistency: a subscriber who follows two of your shows shouldn’t have to learn two different models.
• Email sender name — per show, so subscribers see the show they subscribed to rather than your network name. Usually what you want; a listener may not know your network exists.

Shared Across the Installation

• License — one key covers every show
• SMTP — one connection, one sending address for all shows
• Site-level settings — anything not scoped to a show

The sending address being shared is the one that surprises people. Subscribers see the show’s name but your site’s address. If per-show addresses matter — separate domains per show, for instance — that needs the benecaster_email_from_address filter and an SMTP provider configured to authorize multiple sending addresses.

Subscribers Are Per Show

Tokens are show-specific, always. Someone subscribing to two of your shows subscribes twice and holds two feed URLs.

Say this plainly wherever people sign up. The assumption that one payment covers the network is common, and discovering otherwise after paying generates refund requests. If you want a genuine network-wide offer, it has to be built in your membership plugin as a bundle that grants access to each show’s tier.

Adding a Show Later

1. Benecaster → Shows → Add New
2. Set identity fields following your naming convention
3. Configure tiers, mirroring your existing shows unless there’s a reason not to
4. Map membership plugin levels to the new show’s tiers
5. Publish a test episode and confirm the feed before announcing anything

Check your show slots first — the limit is enforced immediately with no grace period, so a full slot blocks creation outright.

Operating Day to Day

Use the show switcher deliberately. Most screens are scoped to one show. Editing the wrong show’s settings is the characteristic multi-show mistake — glance at the switcher before making changes.

“All Shows” for cross-show analytics. Individual shows for everything else.

Roles are site-wide. There’s no per-show permission model. Anyone who can administer Benecaster can administer every show on the installation. If that’s not acceptable, you needed separate installations — which is why that decision comes first.

When a Show Ends

Deleting or archiving a show frees its slot immediately, so a network can retire one show and launch another without upgrading.

Before you delete: export anything you want to keep, and give subscribers notice. Their tokens stop working when the show goes, and a feed that silently dies is a bad last impression for someone who paid you.