PlugPress
Howdy, visitor Get PlugPress One

Restricted Content Showing in Your .md Pages? How to Fix It

Short answer: update to Waggle 1.0.5. Older versions built the Markdown copy of a page
from the raw stored content, which skipped membership and paywall plugins. On a site that
restricts content, the full text could be served to anyone who asked for the .md address.
From 1.0.5, the Markdown copy shows exactly what a logged-out visitor sees.

This only affects sites that restrict content. If everything you publish is public, nothing
was exposed.

Members-only content is readable at the .md address

Symptom. A post is correctly restricted on your site. A visitor who is not logged in
sees "this content is for members". But adding .md to the address returns the whole
article.

Why it happens. Plugins that restrict content do not delete the text. The article stays
in the database, and the plugin swaps it for a notice when the page is displayed. That swap
happens through a WordPress feature called the_content.

Waggle's Markdown copy skipped that step. It read the stored article and converted it
directly, so the swap never ran. Your normal pages were never affected.

Two things made it worse. The Markdown response could be cached, so a CDN would keep handing
out the text. And llms.txt listed that address, so it was advertised to AI crawlers.

How to check. Request both versions while logged out. The -b '' sends no cookies,
which is the point:

# What a logged-out visitor sees on the normal page
curl -s -b '' https://example.com/your-restricted-post/ | grep -i "members"

# What the Markdown copy returns
curl -s -b '' https://example.com/your-restricted-post.md

If the first shows your restriction notice and the second shows the article, this is the
issue. Use a private window or curl -b ''. Logged in as an administrator you will
legitimately see everything and learn nothing.

Fix. Update to Waggle 1.0.5. Then do two things:

  1. Clear your caches — page cache, CDN, and Waggle's own. A cached copy keeps serving
    until it expires, up to a day.
  2. Check whether anything was fetched. Look at AI Visibility → Bot traffic for hits
    on .md addresses of restricted posts. Waggle only sees crawlers, so if the content is
    sensitive, check your server access logs for .md requests too.

Are password-protected posts affected?

No. Waggle has never served a Markdown copy for a password-protected post. The address
returns 404 whether or not you know the password. Drafts, pending posts and posts you
excluded with the per-page switch are refused the same way.

curl -s -o /dev/null -w '%{http_code}n' -b '' https://example.com/your-protected-post.md
# 404 is correct

A restricted page shows fragments of other content

Symptom. After restricting a post, its .md copy is not the article and not the
restriction notice. It shows page fragments, a list of other posts, or navigation text.

Why. Waggle has a fallback for pages whose content is not stored in the post, which is
how some page builders work. If the converted text came out very short, Waggle would load
the real page and lift its main content area.

A restriction notice is short. So restricting a post could trigger that fallback and pull in
whatever else the page rendered.

Fix. Update to Waggle 1.0.5. The fallback now only runs when the stored post is
genuinely empty, which is what it was for.

What does the .md address show from 1.0.5?

Always the public version of a page — what a logged-out visitor would see.

This applies to administrators too, on purpose. The Markdown copy is cached once per page
with no record of who asked for it. If an administrator's view were cached, everyone would
then receive it. Serving one public version for everybody prevents that.

To read the full text of a restricted post, use the WordPress editor. The .md address is a
public address and behaves like one.