Where Paywalls Leak

You built a paywall so content reaches members only. WordPress, with the best intentions, also ships four features whose entire job is spreading content around: feeds that syndicate it, embeds that preview it elsewhere, a sitemap that maps it for crawlers, and comments that open a conversation with the internet. Each one leaks by design, and each has a toggle.

Feeds

Every WordPress site publishes RSS and Atom feeds of its posts and comments at /feed/, no login required. A scraper doesn't need to bypass your paywall; it can subscribe to your paywall's output.

Feeds leak even when they look empty-ish: they carry titles, excerpts (or full text, depending on settings), and structure. On a course site, a feed of lesson titles is a syllabus handed to whoever asks. Feeds also burn server cycles generating XML for bots that will never buy anything.

Disable feeds (high impact) redirects every feed URL to your home page. The honest cost: podcast clients, feed readers, IFTTT/Zapier recipes that consume your feed stop working. If you publish a podcast, you need your feed, so skip this toggle and curate what feeds contain instead. If you don't publish a feed on purpose, you're only feeding scrapers.

Embeds

oEmbed lets your posts be previewed on other WordPress sites, and lets your site preview theirs. Two leak paths: the preview itself exposes content structure and excerpts outside your domain, and the discovery machinery (endpoints, scripts, rewrite rules) is attack surface. The framing risk is real too: your login page rendered inside an attacker's iframe is step one of a clickjacking attempt.

Disable embeds (high impact) turns the whole system off. The cost is convenience: pasting a YouTube URL into the editor stops producing a tidy embedded player. If your course pages are built on embedded video, use raw embed codes and the secure video features instead, then enable this.

Sitemaps

WordPress maintains an XML sitemap at /wp-sitemap.xml listing all your public content. Search engines use it to index. So does everyone else: it's a complete, machine-readable map of your site, served free.

For a membership site, the sitemap is usually counterproductive twice over. It hands scrapers a crawl list you'd never publish as a page, and it invites search engines to index URLs you'd rather keep out of results (members-only material that renders a login prompt to guests still shows up as an indexed URL).

Disable XML sitemaps (high impact, but only if you rely on core's sitemap for SEO). If you run Yoast or Rank Math, they generate their own sitemaps and this toggle doesn't touch them; coordinate the two so you're not advertising content you meant to fence.

Comments and pingbacks

Comments are the most attacked surface in WordPress: spam bots, link injection, database bloat. Most membership sites host conversation in a community, a forum, or a cohort room, not in WordPress comment threads, which makes the comment system pure liability. Disable comments globally (high impact) turns it off across all post types; existing comments are hidden, not deleted, and the toggle is reversible. Disable comments REST API blocks the endpoint spam bots use to submit comments programmatically, worth enabling even if you keep comments on.

Pingbacks and trackbacks deserve their own line: they can be weaponized into reflection attacks that flood your site with traffic from other WordPress sites. Disable pingbacks and trackbacks ends that; nothing legitimate on a membership site uses them.

The principle

Every one of these features distributes content by design. That's a feature for a blog and a bug for a membership site. Walk the list, ask "who is this for?" and if the answer isn't "my members," the toggle is probably safe to flip, with a glance at the warning label first.