Here is the failure that keeps membership-site owners awake, and it is a real one rather than a theoretical one.
You sell access to premium content. You install an AI assistant. The assistant indexes your whole site, because that is what indexers do. Now an anonymous visitor can ask it questions and get your paid content back as an answer, correctly cited, for free.
Your paywall is intact. Your content is not.
The check happens before indexing
Every page is tested before Helpie reads it, and a restricted page is skipped without being fetched.
What counts as restricted:
- WordPress-native restrictions. Anything not publicly viewable, and anything with a password on it.
- SEO noindex flags, from Yoast, Rank Math or SEOPress. If you have told search engines not to index a page, Helpie takes that as an instruction too. It is a reasonable proxy for "this is not for the public".
- Membership plugins. MemberPress, Paid Memberships Pro, Restrict Content Pro, WooCommerce Memberships, Paid Member Subscriptions, and LearnDash course content, which is skipped wholesale.
- Private forums on BuddyBoss.
Each is checked using that plugin’s own rules rather than a guess, so a page restricted by a rule you configured in MemberPress is evaluated by MemberPress logic.
Content that becomes gated is forgotten
This is the part a one-time check would miss.
A page was public. You indexed it. Six months later you move it behind a membership, because that is a normal thing to do with content that turned out to be valuable.
If the indexer merely skipped it from then on, the copy captured while it was public would sit in the index indefinitely, answerable, forever.
Helpie does not skip it. It purges it. Encountering a page that is now gated actively removes whatever was previously stored, so the transition from public to paid removes it from the assistant’s reach the next time the indexer runs.
Inside the page, too
Page builders let you show individual elements only to logged-in users or to particular roles. A block of admin instructions in the middle of an otherwise public page, visible to staff and nobody else.
Fetching the rendered page as an anonymous visitor handles most of this naturally. For Bricks, Helpie goes further and reads the element conditions directly, skipping any element restricted by user state, role, membership or capability, along with everything nested inside it.
The distinction is deliberate: conditions about who can see something are respected. Conditions that merely shape a layout, like post type or screen size, are not treated as restrictions, because they are not.
This was a real leak, found and closed in May 2026, where admin-only element text inside a public page could reach an anonymous visitor through chat.
Personal data is not in the index either
The knowledge base holds published content. It does not hold customer records, orders or personal information.
When the assistant does need a customer’s own data, to answer "where is my order", it fetches it live at the moment of asking, for that logged-in customer, with an ownership check. Nothing personal is ever stored in the searchable index, so there is nothing there to leak to anybody else.
Why this is a feature rather than an assumption
Any indexer can be pointed at a site. The question is what it does with the parts of that site that were never meant to be public, and the honest answer for most tools is that nobody checked.
We do not know what your membership terms or your local regulations require of you. What we can do is make sure the assistant respects the boundaries you have already drawn, and keep respecting them when you move them.