Free Followers
Followers are a direct listener list you own — people who want to hear your show and hear from you, without a membership plugin, a paid tier, or a payment. A follower receives a private, tokenized feed URL of their own, and that feed carries the same episodes as your public feed.
A follower is not a tier. There is nothing to configure per episode and nothing to gate. If an episode is in your public feed, it is in every follower’s feed; if it is not, it is not. What the token buys you is not different content — it is knowing who is listening and being able to revoke one person’s access without touching anyone else’s.
Followers do not consume a paid subscriber slot. They do hold a feed token, so each follower occupies one slot in your plan’s total token cap.
The Follower Signup Shortcode
Place [benecaster_follower_signup] on any page to render a sign-up form for free followers:
[benecaster_follower_signup show_id="3"]
| Attribute | Required | Default | Description |
|---|---|---|---|
show_id |
On multi-show installs | — | Post ID of the show the follower is signing up for. Auto-resolved on single-show installs — see below for where to find it |
button_text |
No | "Follow" |
Text for the submit button |
success_message |
No | (translatable default) | Message shown after a successful signup |
name_field |
No | true |
Set to false to hide the name field and collect email only |
Finding your show ID: Benecaster displays each show’s ID as a small chip next to its name — #3 for show 3, and so on. Click the chip to copy the number. It appears in the header when you open a show, on every sub-tab, and on each card in Benecaster → Shows including archived ones. You don’t need show_id at all on a single-show install.
See the shortcode reference for full attribute documentation.
Form fields: Name (optional, controlled by name_field), Email (always required), and — when the Supporter Wall is on — a wall name. There is no password field.
Signing up is email-first. Your follower gives you an address and nothing else. We create their account, and the welcome email carries their feed URL alongside a single-use link that signs them in and lands them on their account page. They can set a password there if they want one; they never need one to listen.
What each visitor sees, because there are three cases and only the first is obvious:
- A new address gets the welcome email with the feed URL and the sign-in link. This always sends, even on a show where the podcaster has switched the welcome email off (Show Settings → Subscription → Welcome and Feed URL Emails) — it’s a follower’s only way to ever receive their feed URL, since there’s no billing relationship behind which it could reach them another way. Every other subscriber type does respect that switch. ⚠ If an admin later resets a follower’s token, this exemption does not carry over: Reset and send email still requires the show’s token-reset email switch to be on, the same as for any other subscriber.
- An address that already follows the show gets a different email — you already follow this show — with a link into their account. ⚠ It does not contain the feed URL, and it cannot. Feed tokens are stored hashed, so an existing follower’s URL genuinely cannot be looked up and re-sent. They sign in and read it from their account page. This is the same reason the account page shows it masked.
- Somebody already signed in to your site sees “Follow as {their email}” and a single button. One click and they are following. ⚠ No email is sent at all on this path — instead their full feed URL is shown on the success screen, which is the only place it will ever appear for them. If you are testing your own form while logged in, this is why no welcome email arrives.
On-screen, a new address and an existing follower look identical. Both see the same success message. That is deliberate: if the form said “you already follow this show”, anyone could use it to test which email addresses are registered on your site. The difference lives in the mailbox, where only the address’s real owner can see it.
The form is rate limited. A handful of submissions per address and a larger number per IP address, each within a rolling hour. ⚠ A submission over the limit shows the same success message and quietly does nothing — there is deliberately no error, because a message saying “too many attempts” for a particular address would tell a stranger that the address had recently been submitted. Nothing is created and no email is sent.
Two more automatic layers sit alongside the rate limits, and neither has a setting. A hidden honeypot field catches bots that fill in every field on a form, and a minimum fill time (a submission arriving less than a few seconds after the form loaded) catches scripted submissions no human could complete that fast. Both are on for every install automatically — there is nothing to configure. A caught submission is silently dropped: it shows the same success message and does nothing, for the same reason the rate limits behave that way.
You will not normally meet this. It matters in one case: if you are adding followers in bulk by pasting addresses into your own form, it will stop working partway through. Use Subscribers → Bulk enroll → Add as: Followers instead — it is not throttled, works on any show regardless of membership plugin, and honors the same unlicensed follower cap and double opt-in setting as this form. See Bulk Subscriber Enrollment.
A visitor who submits a stale or cached copy of the form sees a plain retry message — “This form took a while to load — please try submitting it again” — instead of the button silently doing nothing. This is expected if the page carrying the form sits in a full-page cache: the security token baked into the cached HTML has a roughly 24-hour effective lifetime, so a cache held longer than that reproduces this message for every visitor until the page is regenerated. Submitting the form again works normally.
Requiring email confirmation before a follow counts is available to developers via the benecaster_follower_double_optin filter — off by default, with no admin setting to turn it on from the dashboard. When a show opts in, a new address gets a confirmation email instead of the welcome email, and no follower account (and no cap slot) is created until the recipient clicks the link inside it. See the Filter Hooks Reference for the filter signature.
⚠ One thing to know before you test it yourself: an administrator or editor account is never signed in by an emailed link. Those accounts are sent to the WordPress password-reset screen instead. That is a deliberate protection, not a fault — an emailed link works for whoever opens the message, which is fine for a listener reaching their own feed and not fine for an account that can edit your site. Test with an address that is not a site administrator, or you will conclude the feature is broken.
No payment step: Followers are created directly. No checkout, no billing, no bridge membership required.
What a Follower’s Feed Carries
A follower’s feed carries your public feed’s episodes, and only those. There is no Followers row in the episode editor’s Tier Availability panel and no follower date to set — publish an episode to your public feed and every follower has it on their next fetch.
Paid tier availability is untouched by any of this. The Tier Availability panel still governs which of your bridge membership tiers can see an episode, exactly as before. Followers simply are not one of those rows.
What you cannot do: give followers something the public feed does not have. Early access, a bonus episode, a subscriber-only interview — those are paid-tier or free-tier membership features, and they need a membership plugin behind them. A follower list is for reach and for owning the relationship, not for gating.
Why the token, then?
Attribution. A public feed URL can’t tell you who’s listening — every download looks the same. A follower’s token means downloads are per follower, so you can see who is actually listening rather than a single undifferentiated public number.
Follower feeds keep working when everything else stops
A follower feed is the one tokenized feed that survives a licence ending. If your licence is cancelled or expires, if a payment failure runs its full course, or if you disconnect the show, your paying subscribers’ feeds stop — and your followers carry on receiving episodes and downloading audio exactly as before.
That is deliberate rather than an oversight: a follower’s feed only ever carried your public feed’s episodes, and your public feed keeps working in all of those states. Stopping followers would take away something the licence never granted in the first place.
What this means in practice: the list you built is not hostage to your billing. If you lapse and come back, your followers never noticed.
This does not cover the total token cap. Being over your licence’s total token cap is a different state from the licence ending, and it does affect followers — see The One Real Limit below. A follower’s feed surviving a lapsed or disconnected licence is not the same as it surviving an over-cap install.
How Followers Differ from Subscribers
| Paid subscriber | Follower | |
|---|---|---|
token_type |
subscriber |
follower |
| Source | Bridge (MemberPress, WooCommerce, etc.) | Direct sign-up via shortcode |
| Private tokenized feed | Yes | Yes |
| Which episodes it carries | The tiers they are mapped to | Your public feed’s episodes |
| Counts toward paid subscriber limit | Yes | No |
| Counts toward the total token cap | Yes | Yes |
| Has a tier mapping row | Yes | No |
Followers hold a feed token just as paying subscribers do, but are excluded from all capacity calculations and bridge lookups because they have no tier mapping.
Followers on the Supporter Wall and in Badges
A follower who opts in appears on the Supporter Wall exactly like a paying subscriber — included, never filtered out. The only difference is a label: their card carries a muted Follower chip and is classified is-follower (a paying subscriber’s card is classified is-subscriber), so a theme can style the two differently if it wants to. The wall’s sort order does not change by type.
The same classification shows up anywhere [benecaster_user_badge show_id="…"] renders with a show in context: a follower’s badge chips include the Follower chip, guaranteeing they always show at least that one. Rendered without a show_id, badges carry no follower/subscriber classification at all — one person can follow one show while paying for another, so a site-wide render can’t pick a side.
And [benecaster_member_since] reads “Following since June 2024” for a follower, instead of “Member since,” when a show is in context. See The Subscriber Account Page for the full formatting rules.
A Follower Who Later Subscribes
If a follower later subscribes to a paid tier — through any membership plugin, the built-in membership, or by being added under Subscribers → Bulk enroll → Add as: Subscribers — they become a subscriber at the same feed URL. Their existing token is upgraded in place rather than replaced: their podcast app starts receiving the paid episodes on its next poll, no new email is sent, and there is nothing for them to reinstall.
From that point on they count as a paying subscriber toward your plan’s limit and stop counting as a follower; the Subscribers list’s type filter shows them under Subscribers. If they later cancel, their feed is revoked exactly like any other subscriber’s — they do not go back to being a follower.
The One Real Limit
Followers are not license-gated. They work on the free WordPress.org plugin exactly as they do on a paid plan.
What is capped is how many followers you can have. On an unlicensed install the shortcode stops accepting new followers at 100 and shows an upgrade prompt instead — existing followers are unaffected, the form simply stops taking new ones. On a paid plan, followers share your plan’s total token cap with paying subscribers.
Those are two different caps and they behave differently — the next paragraph is about the second one, not the 100.
The 100-follower cap is a signup refusal. Nothing happens to anyone’s feed. The form stops taking new followers, and every existing follower carries on exactly as before. No follower is ever demoted to your public feed or locked out because of this cap.
The plan’s total token cap is the one with a feed consequence, and it depends on your enforcement preference. Under cap, over-cap free tokens — followers included — are locked out of the feed and receive a 410. Under auto upgrade, nothing is flagged and every listener keeps their feed while the plan change matures. Set the preference on My Account.
Counting Paying Subscribers
Because followers hold tokens just as paying subscribers do, any count that does not distinguish them by token type overcounts. The correct paying subscriber count requires two conditions:
- The token’s type is not one Benecaster exempts from paying (
followerandpurchaser) — excludes followers and purchasers, and counts every other type, including a custom one an add-on defines - The token’s tier is not free — excludes members on a $0 tier, whether it is a bridge plugin’s tier or a built-in-membership tier (these carry a non-exempt token type and are not excluded by the first condition alone)
See Which subscriber count is the paying one for the supported way to get this number.
Related
- How Feed Tokens Work — token lifecycle, reset, and access model
- Subscriber Dashboard — managing subscriber records
- Free vs. Paid Features — what each plan tier includes
See Also
Need this built rather than just documented? See our services →
Last updated