Back to Blog
Queryra + MemberPress: AI Semantic Search That Respects Your Paywalls
guide

Queryra + MemberPress: AI Semantic Search That Respects Your Paywalls

How AI semantic search works on a MemberPress site without exposing premium content. Queryra and MemberPress operate in different layers — search returns post IDs, MemberPress enforces access at render time. No coupling code, no configuration. Test results, architecture, and recommended setup.

RG
Rafal Gron
Founder, Queryra
May 13, 2026·6 min read

When you add AI semantic search to a site that already uses MemberPress for paywalls, the first question is usually anxious: *"Will the AI leak my premium content?"*

The short answer is no — and the reason is architecturally interesting. Queryra and MemberPress operate in completely different layers of the WordPress request lifecycle. Neither system needs to know about the other. They just work together.

This post walks through how that works, the test setup we ran to confirm it, and the recommended configuration.

The fear (and why it doesn't apply here)

Many WordPress search plugins replace the default search by hooking deep into the WP_Query pipeline. Some bring their own permissions model. Some skip standard WordPress access checks for performance. This sounds reasonable until you realize what it implies: a search plugin that bypasses access checks can return content the user shouldn't see — Gold-tier course excerpts in search results for free members, or hidden article snippets to logged-out visitors.

The fear is legitimate when search and access control are tightly coupled. The good news: with Queryra and MemberPress, they aren't.

The architecture

When a visitor searches your site, Queryra runs in three steps:

  1. Query intercepted. Queryra hooks into WordPress's pre_get_posts action and posts_search filter.
  2. Semantic match. The query is sent to Queryra's AI search API, which returns a list of post IDs ranked by semantic relevance to the query.
  3. Modified SQL. Queryra rewrites the search SQL to fetch the specific post IDs returned by the API.

From that point, WordPress takes over — exactly like it would for any other search. The standard WP_Query runs, fetches the posts, hands them to your theme. MemberPress hooks into the_content, get_the_excerpt, and template_redirect to enforce its rules at render time, regardless of how the WP_Query was constructed.

The key insight: Queryra returns IDs. It never returns content. The actual title, excerpt, and body that the visitor sees come from WordPress at render time. MemberPress filters at that layer, exactly as it does for archive pages, category listings, and direct URL access.

The two systems operate orthogonally. No coupling. No coordination.

Test setup

To confirm this empirically, we ran a clean test:

  • Fresh WordPress install (Docker, port 8103)
  • MemberPress 1.12.15 with two membership tiers (Silver $9.99/mo, Gold $29.99/mo)
  • Three content pages: one free, one Silver-only, one Gold-only
  • MemberPress Rules configured to enforce tier access
  • Test users at each tier plus admin

We then searched for content-specific marker keywords from three perspectives:

Search byQueryResult
Logged-out visitor"gold-only content marker"Title visible, body replaced with MemberPress login prompt
Silver member"gold-only content marker"Title visible, body replaced with MemberPress upgrade prompt
Admin"gold-only content marker"Full content visible

Behavior was identical with Queryra active and with Queryra deactivated (default WordPress search). MemberPress applies the same rules regardless of which search engine populated the result list. The titles serve as teasers; the content stays paywalled.

This is the same behavior MemberPress users already know from archive pages and category listings. Queryra doesn't introduce a new exposure surface.

What this means for you

If you're running MemberPress and considering AI semantic search:

  • No additional configuration is required. Install both plugins, sync content, and go.
  • Search results behave like every other WordPress page. Whatever MemberPress lets through in archives, it lets through in search results. Whatever it gates, it gates everywhere.
  • You don't need a search plugin that's "MemberPress-aware". That concept is a category error — search and access control are different problems, solved by different systems.

Edge cases worth knowing

  • ReadyLaunch templates. MemberPress ships with optional ReadyLaunch templates for login/account pages. These don't affect search results pages (those come from your theme), so no interaction with Queryra to worry about.
  • Course Creator. MemberPress Courses register custom post types (mpcs-course, mpcs-lesson). To include them in semantic search, enable those post types in Queryra settings (Settings → Content → Post types). Standard MemberPress rules apply at render time.
  • Custom Rules with non-post content. If you've configured MemberPress to gate content stored outside wp_posts (custom tables, external systems), that content also isn't indexed by Queryra — but that's not a MemberPress-Queryra interaction issue, just the scope of what Queryra indexes (v1.2 reads wp_posts and recognized taxonomies).

TL;DR

  • Queryra (AI semantic search) and MemberPress work together with no configuration.
  • Queryra returns post IDs; MemberPress filters at render. The two systems never overlap.
  • Search results behavior is identical to default WordPress search, with MemberPress's access rules respected the same way.
  • Titles of protected content appear as teasers (same as in WordPress archives); content stays paywalled.

For the integration status page, see Queryra + MemberPress docs.