Known Plugin Conflicts

Benecaster is a standard WordPress plugin and coexists with the large majority of the ecosystem without configuration. This page lists the categories that need attention, and what to do about each.

There is no plugin blocklist here, and Benecaster does not refuse to run alongside anything. These are interactions worth knowing about, not incompatibilities.

Caching Plugins

This is by far the most common source of trouble, and it affects every caching plugin rather than any particular one.

The problem: the subscriber account page is personalized — it shows one subscriber their own private feed URL. If a page cache stores that page and serves it to the next visitor, the wrong person sees someone else’s feed URL. That’s a real access-control problem, not a cosmetic one.

The fix: exclude the account page from caching. Caching Plugin Configuration gives step-by-step settings for WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache, and SG Optimizer.

Private feed URLs are already protected — Benecaster sends headers that prevent them being cached — so the exclusion work is about pages, not feeds. Do it before you launch rather than after.

Object caching (Redis, Memcached) is a different thing entirely and needs no exclusions. Benecaster uses it automatically and benefits from it.

Other Podcast Plugins

Seriously Simple Podcasting, PowerPress, and similar plugins manage episodes in their own data format and generate their own feeds.

The problem: they don’t conflict at a technical level — both can be active — but they don’t share episode data. Episodes created in another plugin don’t appear in Benecaster’s feeds, and each plugin continues emitting its own feed independently. Running both indefinitely means maintaining two sets of episodes and publishing two feeds.

The fix: import your episodes into Benecaster during setup — the wizard includes a one-time import step — then deactivate the other plugin once you’ve confirmed your feeds are correct. Keep it installed but inactive until you’re certain, rather than deleting it immediately.

If you deliberately want both — one plugin for a public show, Benecaster for a private one — that works. Just be clear which feed is which.

SEO and Feed-Modifying Plugins

Some SEO and optimization plugins alter or disable WordPress’s built-in feeds.

The problem: a plugin configured to disable RSS feeds site-wide can affect Benecaster’s feeds too. The symptom is feeds returning empty or 404 for everyone at once, immediately after activating or reconfiguring such a plugin.

The fix: if your feeds break right after a change to an SEO plugin, look for a “disable RSS feeds” or “redirect feeds” setting and exempt Benecaster’s feed URLs. Feeds working before a change and not after is strong evidence of where to look.

Permalink and Slug Collisions

Not a plugin conflict, but it produces similar confusion.

The problem: if an episode slug matches a page slug at the same level, one shadows the other and the wrong content loads.

The fix: Benecaster detects these and shows an admin notice naming both items and telling you which to rename. Act on the notice — it won’t resolve itself. See Permalink Settings.

Security and Firewall Plugins

The problem: feed URLs contain a long token and are polled repeatedly by podcast apps from many IP addresses. Some security plugins read that pattern as suspicious and rate-limit or block the requests. The symptom is feeds failing for some subscribers but not others, often geographically clustered.

The fix: allowlist your feed URL path in the security plugin’s rate-limiting rules. If subscribers in one region report failures while others are fine, this is the first thing to check.

SMTP Plugins Are a Requirement, Not a Conflict

Worth stating explicitly since it comes up as a “conflict”: Benecaster needs an SMTP plugin to send email reliably, and having one installed is correct. If two SMTP plugins are active at once they will fight over mail delivery — keep exactly one. See SMTP Setup.

Reporting Something Not Listed Here

This list covers what’s currently known. If you find a genuine incompatibility, tell support and include the plugin name and version, what breaks, and whether deactivating it resolves the issue. Confirmed conflicts get added here.

Before reporting, confirm it with the standard test: deactivate the suspected plugin, check whether the problem goes away, reactivate it, and check whether it returns. A conflict that reproduces on that cycle is worth investigating; one that doesn’t usually has another cause.