Feed Showing Wrong Episodes

“Wrong episodes” covers several different problems: missing episodes a subscriber should have, episodes appearing that they shouldn’t, or an episode not appearing when you expect it to after publishing. Work through the relevant section below.

Episode Not Appearing After Publishing

Check availability dates. Benecaster controls when each episode appears in each tier’s feed through availability dates — not just the WordPress publish date. An episode can be published in WordPress but not yet available in the feed if its availability date hasn’t passed.

Go to the episode editor and check the Access tab. Confirm the availability date for the subscriber’s tier has passed. If it hasn’t, the episode won’t appear in the feed yet — this is expected behavior for scheduled early access or timed releases.

Check the availability cron. Benecaster checks for passed availability dates every 5 minutes via a scheduled background task. If your site runs on a shared host with low traffic, the scheduled task may not fire on time. An episode whose availability date just passed may take up to 5 minutes to appear in the feed.

To force an immediate check, go to Benecaster → Tools and click Check Availability Now.

Flush the feed cache. After an availability date passes and the cron runs, the feed cache for affected tiers is cleared automatically. If you suspect the cache is stale, flush it manually from Benecaster → Tools → Flush Feed Cache.

Check that the episode is published. Draft or scheduled WordPress posts are not included in any feed regardless of availability settings.

Check your site’s timezone. Availability dates are entered in your site’s timezone and released against it, not the subscriber’s — an episode set for 9am becomes available at 9am where your site thinks it is. If Settings → General → Timezone is set to somewhere you did not intend, every scheduled release shifts by that offset, and it shifts consistently enough to look like a cron problem rather than a clock one. Confirm the timezone is right, and that the date and time WordPress shows on that screen match the actual time now.

A consistent offset on every episode is a timezone setting, not a scheduling fault. Correct it in Settings → General and your existing availability dates keep the moments you originally chose — they are stored as absolute points in time, so changing the site timezone changes how they are displayed, not when they release.

Changing your timezone? Do it before you update Benecaster. Existing availability dates are converted once, using whatever Settings → General → Timezone says at the moment the update runs. Set the timezone you actually want first, then update, and every date you had already entered is read the way you meant it.

Episode Appearing for Wrong Tier

Check tier mapping. Go to Benecaster → Settings → Subscription and review your tier map. Confirm each membership tier is mapped to the correct Benecaster tier. A misconfigured tier map is the most common cause of a subscriber seeing episodes they shouldn’t — or not seeing ones they should.

Check episode-level overrides. Episode availability can be set at the show level (default for all episodes) or overridden per episode. An episode-level override takes precedence over the show default. Open the episode editor, go to the Access tab, and check whether per-episode availability dates are set differently from the show default.

Check the subscriber’s tier. In Benecaster → Subscribers, confirm the subscriber is on the tier you think they’re on. If your membership plugin recently changed their tier, Benecaster reflects that change on the next feed request.

Subscriber Seeing Episodes They Shouldn’t

If a subscriber on a lower tier is receiving episodes that should only be available to a higher tier:

Check the episode’s Access tab — confirm the higher-tier availability dates are set correctly and earlier than the lower-tier dates (or that lower-tier access is set to “hidden” or “teaser only”)
Check the tier mapping — confirm the subscriber’s membership tier maps to the correct Benecaster access level
Flush the feed cache — an old cached feed from before you changed availability settings may still be serving

Subscriber Receiving No Episodes at All

If a subscriber’s feed is completely empty:

Confirm their token is valid and their membership is active — see Subscriber Can’t Access Their Feed
Check that at least one published episode has an availability date in the past for their tier
Confirm their tier is mapped — an unmapped tier generates a valid token but an empty feed

Feed Not Updating in Podcast App

The feed content is correct when tested in a browser but the subscriber’s podcast app isn’t showing new episodes:

App poll lag. Most podcast apps poll their feeds every 1–24 hours. There may simply be a lag. The subscriber can usually trigger a manual refresh by pulling down to refresh their show in the app.
Aggressive app caching. Some apps cache a previous feed response and won’t pick up changes until the subscription is removed and re-added. Ask the subscriber to remove and re-add the feed if a manual refresh doesn’t work.
ETag mismatch. Benecaster sends ETag headers with every feed response. Apps that honour ETags will receive a 304 Not Modified response when nothing has changed, which is efficient but can mask problems if the ETag is stale. Flushing the feed cache from Benecaster → Tools resets the ETag and forces a fresh response on the next poll.
Benecaster feed cache. Cached feeds are at most 1 hour out of date. If you changed show settings (artwork, category, feed slug) and the change isn’t appearing, the old cache may still be serving. Flush it manually from Benecaster → Settings → General → Advanced. Episode publishes and availability changes clear the cache immediately regardless of TTL.
CDN or hosting cache (pretty permalink users only). If you’ve enabled pretty permalink feed URLs, some CDNs and hosting control panels may cache the feed response by URL path. Check whether your CDN has a cache rule for the feed URL pattern and configure an exclusion, or purge the URL manually. Benecaster sends Cache-Control: no-store on all feed responses, but not all caching layers honour it. Switching to the default query-string URL format bypasses this issue entirely.

Subscriber Seeing Public Episodes Instead of Paid Content

If a subscriber’s feed is returning content — but only the episodes that free or public visitors can see, not their paid tier’s episodes — work through these checks:

1. Check whether their subscription is active.
Go to Benecaster → Subscribers and find the subscriber. If their membership has lapsed, expired, or been cancelled, Benecaster revokes their token and (by default) routes their feed URL to the public feed. Their podcast app keeps working but serves only public-tier content. Resolve the membership issue in your membership plugin and then use Generate Token to issue a new token for the subscriber.

2. Check whether their token is over-limit.
If your site has more active paying subscribers than your plan allows, Benecaster flags the newest tokens as over-limit and routes them to the public feed until you upgrade. Look for an amber over-limit warning in Benecaster → Subscribers next to the subscriber’s row. Upgrading your plan clears the flag automatically at the next nightly check.

3. Check their tier mapping.
Go to Benecaster → Settings → Subscription and confirm the subscriber’s membership tier is mapped to the correct Benecaster tier. An incorrectly mapped or unmapped tier will produce a token that is technically valid but delivers the wrong episode set.

4. Check whether a grace period is active.
If a payment failed and the grace period is in progress, the subscriber may be receiving a degraded feed intentionally — see Feed Behavior During a Payment Grace Period for what to expect.

5. Flush the feed cache.
If the above look correct but the subscriber is still seeing the wrong content, flush the feed cache from Benecaster → Settings → General → Advanced. A cached feed from before a tier change may still be serving.

6. On a site with more than one show, check whether they’re seeing a different show’s public episodes entirely. On a version before this release, a subscriber of any show except the first-published one could receive the first show’s public episodes — a different show altogether — from the standard /podcast-feed/?token=… URL their app already had. This is fixed by updating the plugin: the same URL already saved in their app starts delivering their own show’s content on its next refresh, with nothing to reset or re-send. Some podcast apps keep the wrong show’s old episodes in their local library until the subscriber removes and re-adds the feed.