MemberPress Rules Not Working? 10 Real Causes and How to Fix Each One

There are two versions of this problem and they arrive from opposite directions. Either a paying member emails to say they cannot open the course they just bought, or you find out from a stranger that the whole members area is readable by anyone with the link. Both are the same fault wearing different clothes, and both are what people mean when they say MemberPress rules not working. The rule is saved. The rule looks right. The rule is not doing anything.

I build and repair WordPress membership sites for a living, and this is the single most common thing I get called in for. In almost every case the rule itself is fine. Something one layer away from the rule decided the outcome before MemberPress ever got a say: an administrator session, a second rule nobody remembered, a cache, a cookie, or a piece of content that was never running through the code path rules attach to. Below are the ten real causes, in the order I check them, and the exact screen to open for each.

How Does MemberPress Actually Decide Who Sees What?

A rule is not a switch on a page. It is a separate record that says “this content, for these people,” and it only takes effect when several other things line up first. Understanding that order is what turns this from guesswork into a five minute check.

Every request runs through the same sequence. WordPress works out who you are from your login cookie. MemberPress checks whether you hold administrative rights, and if you do, it stops there and shows you everything. If not, it looks for a rule that matches the content being requested. If a rule matches, it reads the access conditions on that rule, then applies any drip or expiration timing, then decides what an unauthorised visitor sees. Underneath all of it, your caching layer gets to answer the request before WordPress even wakes up.

Read that chain from the top rather than the bottom. Most people open the rule, confirm it says what they wanted, and conclude the plugin is broken. The rule is usually the one link that was never at fault. Everything below works through the chain in order, which is also the order that finds the cause fastest.

Cause 1: Are You Testing While Logged In as an Administrator?

This is the first thing I check and it accounts for more false alarms than everything else combined. MemberPress states it plainly in its own documentation: rules are ignored entirely when the current user has administrative rights. Not softened, not partially applied. Ignored.

So you open the protected page in the same browser you administer the site from, see the full content, and conclude the rule failed. It did not. You are simply not the audience it applies to. The reverse trap is just as common: a client checks on their phone, sees the paywall working, then checks on their laptop where they happen to be logged in as an admin, and reports the site as insecure.

Cause 2: Do Two Rules Cover the Same Page?

MemberPress rule types overlap by design. A rule for All Posts and a rule for a single post both reach the same article. So do a rule for Content Categorized as and a rule for Content Tagged as, whenever a post carries both. The moment two rules land on one piece of content, MemberPress documents the result bluntly: subscriber access will not be correct.

Worth being honest about something here, because it changes how you fix it. MemberPress documents that overlapping rules break access, but its guidance on avoiding rule conflicts gives no precedence order: nothing states which rule wins. That means you cannot reason your way to the outcome. The only supported arrangement is one rule per piece of content, so the repair is to remove the overlap rather than to work out who is beating whom.

There is exactly one documented exception. Two rules on the same content are allowed when one has a drip setting applied and the other does not. That pairing is intentional and supported. Every other overlap is not.

Cause 3: Did the Rule Save Without an Access Condition?

A MemberPress rule has two halves. The top half says which content is protected. The bottom half says who is allowed in, and it is added by clicking a plus icon and choosing a condition type. A rule saved with the top half filled in and the bottom half empty locks content away from everyone, including the people paying for it.

The subtler version is a rule with a condition that points at the wrong thing. There are three condition types: membership, individual member by username, and WordPress role or capability. Membership is the one to use. Role based conditions are the ones that quietly break, because a member’s WordPress role is not the same thing as their membership, and MemberPress recommends role conditions only for migrations rather than day to day protection.

Cause 4: Is the Member’s Subscription Actually Active?

Before blaming the rule, confirm the person actually holds what the rule asks for. MemberPress has a direct answer for this. Open MemberPress, then Subscriptions, find the member, and look at the Active column. A green Yes means they hold the membership right now. Anything else means the rule is behaving correctly and the problem is on the billing side.

A failed renewal is the usual culprit, and it produces a support ticket that sounds exactly like a broken rule. The card expired, the recurring payment failed quietly overnight, the subscription lapsed, and the member woke up locked out of content they were reading yesterday. From their side nothing changed. From the rule’s side, they stopped qualifying.

Cause 5: Is a Drip or Expiration Window Holding Content Back?

Drip and expiration settings live on the rule itself, which is why they get missed. The rule names the right content and the right membership, so it reads as correct at a glance. The timing fields sitting below decide whether this particular member, on this particular day of their subscription, is inside the window.

MemberPress lists this explicitly among the reasons a user cannot reach content: dripping or expiration on the rule can exclude someone at the moment they are looking. A member who joined last week sees a lesson scheduled for day thirty as missing, not as scheduled, unless your theme is showing them a release date. On a cooking education platform I built with drip released courses (Jen’s Cook, on my portfolio), the release schedule was always the first thing to open whenever somebody reported a lesson had vanished.

Cause 6: Is Your Cache Serving the Page Before MemberPress Runs?

This is the cause that produces the frightening version of the problem, where protected content is served to people who never logged in. A full page cache stores the finished HTML of a page and hands that copy to the next visitor without running WordPress at all. If the stored copy was generated while somebody with access was viewing it, the cache now serves paid content to the public.

MemberPress addresses this directly in its troubleshooting guidance, and its recommendation is unambiguous: turn off full page browser caching in your caching plugin, and cache only static items such as CSS, JavaScript, images and fonts. This is the same class of problem that makes logged in performance behave so differently from what a speed test reports, which I covered in more depth in the guide to why membership sites feel slow for logged in members.

Object caching deserves its own mention. MemberPress lists Redis Object Cache among plugins known to cause problems, and page builder level caching is worse: Elementor’s Element Caching is documented as breaking partial rules and drip settings specifically, because the cached widget never re-evaluates who is looking at it.

Cause 7: Are Login Cookies Split Across www and HTTPS?

This one looks nothing like a rule problem, which is why it survives for months. WordPress login cookies are valid under www or non-www, but not both, and the same split applies between HTTP and HTTPS. A member who logs in at one address and then follows a link to the other is, as far as WordPress is concerned, logged out. MemberPress then does exactly what it should and shows them the paywall.

The symptom is distinctive once you know it. Access works, then stops, then works again, with no pattern anyone can describe. It usually correlates with which link the member clicked: an old bookmark, an email from before the SSL certificate was installed, or an internal link somebody hard coded with the wrong prefix.

Cause 8: Is the Page One That Rules Were Never Going to Cover?

Page and post rules protect pages and posts. They do not protect your home page, your blog index, category pages, tag pages or date archives. Those are generated by different templates, and a rule aimed at a page does not touch them. So the article body is locked while the same article’s excerpt sits on the blog index for anyone to read.

Search results are their own version of this. MemberPress notes that the Relevanssi search plugin causes protected posts to stop appearing in search results, which is the opposite failure: content correctly protected but now invisible to the members who paid for it. Whichever direction it fails in, the lesson is the same. Coverage is not uniform, and assuming it is produces both leaks and lockouts.

Cause 9: Is the Content Rendered Outside the Standard Content Function?

MemberPress applies protection through the standard WordPress content function that themes call to print a post’s body. Anything a theme or plugin renders by another route never passes through that filter, so no rule ever gets the chance to act on it. This is the technical reason behind a whole family of complaints that all sound like a broken plugin.

MemberPress documents the practical consequences. Community content from BuddyPress and BuddyBoss is not protected by rules. Custom post types added by third party plugins are outside the protection too unless the integration explicitly handles them. The same documentation names the Flynt theme as rendering content outside the standard WordPress area in a way that prevents protection rules from applying at all. Community platforms fail quietly in a lot of ways, which is a pattern I ran into again while working through BuddyBoss notification problems.

Page builders sit in the same category. Protecting a section inside Elementor needs the MemberPress Elementor add-on installed and active, plus a Partial rule created first, and MemberPress documents WP Fusion as causing those Elementor rule settings to be ignored entirely when both are present.

Cause 10: Are Protected Files Still Downloadable by Direct Link?

A rule protects the page a file sits on. It does not, on its own, protect the file. Anyone holding the direct upload URL downloads it without ever meeting your paywall, and that URL travels: in a forwarded email, in a browser history, in a shared document.

MemberPress solves this at the server level rather than in PHP. Its file protection rewrite rules check for a member cookie and a matching lock file before releasing a file, and route anything unverified through a handler that decides whether to allow it. Three constraints matter. It officially supports Apache and LiteSpeed, with Nginx unsupported and dependent on your host adding configuration. The rules have to sit after the WordPress rules in .htaccess. And a list of extensions is deliberately excluded for performance reasons, including php, jpg, jpeg, gif, png, css, js, svg, woff, ttf and xml.

What About LearnDash Courses and MemberPress Courses?

If your content is a course, stop looking at rules. The LearnDash integration does not work through them. Course access is granted on the membership itself: edit the membership, open the Membership Options box, choose the LearnDash tab, and select the courses that membership grants. Buying the membership enrols the student in those courses.

Three documented details cause most of the trouble here. Courses need their access mode set to Closed for the integration to behave. Adding five or more courses to one membership moves enrolment into a background process that needs a working cron job, so a site with broken cron enrols nobody. And courses added to a membership after people have already bought it do not enrol existing members retroactively without running the Retroactive Tool.

MemberPress also lists LearnDash under known plugin conflicts, with courses failing to attach to memberships on purchase. If enrolment is the symptom, check the integration and the cron before rewriting anything. Course completion has its own separate failure modes, which I worked through in the guide to LearnDash lessons not marking complete.

MemberPress Rules Not Working: Which Check Comes First?

Run these in order. Each one either finds the cause or removes a whole category of cause from the search, which is faster than opening settings at random.

1. Reproduce it as the right person. Logged out in a private window for the public view, and as a real test member in a second browser for the member view. Never in your admin session.
2. Check the subscription. MemberPress, then Subscriptions, then the Active column for that member. A green Yes, or the problem is billing rather than rules.
3. Read the whole rules list. Not the one rule. List every rule that could reach the affected content and confirm only one does.
4. Open that rule fully. Access condition present, type set to Membership, correct membership named, drip and expiration checked against the member’s real signup date.
5. Purge every cache and retest. Plugin, server, CDN and page builder caching, then the same two browser test again.
6. Check the address. Whether the failing visit was on www or non-www, HTTP or HTTPS, and whether that matches your canonical address.
7. Ask what kind of content it is. A page or post, an archive, a custom post type, builder output, a course, or a file. Each has a different mechanism, and only the first is covered by an ordinary rule.
8. Test with a clean plugin set. On a staging copy, switch to a default theme and disable everything except MemberPress. If protection works there, reactivate in batches until it breaks again.

One oddity is worth knowing about, because it looks alarming and has a documented workaround. If every page on your site is locked and you have no rules at all, MemberPress acknowledges the behaviour in its own documentation, states it cannot reproduce the cause, and gives a workaround: add a new rule, publish it while ignoring the validation errors for the empty fields, check the site, then delete that rule. It reads like superstition. It is their own published fix.

Why Does a Broken Rule Stay Invisible for So Long?

Because nothing reports it. A rule that fails open produces no error, no warning and no log entry. The page loads perfectly. It just loads for the wrong person, and the wrong person has no reason to tell you. Sites run for a year with a members area that was public the entire time, and the discovery comes from an unrelated direction: a search result that should not exist, or somebody mentioning they read the material without joining.

A rule that fails closed is louder but still slow, because it reaches you as a support ticket about one person rather than as a fault. You fix that one account by hand, the ticket closes, and the underlying cause survives. Six people later it becomes obvious there is a pattern, and by then the trail back to the change that caused it has gone cold.

The deeper reason is that access is decided by a chain, but administered through a single screen. Everything you can see on the rule page looks correct because it is correct. The link that failed is somewhere you were not looking: a cache, a cookie domain, a plugin conflict, a template that never called the function protection attaches to. That gap between where the fault happens and where you go looking is the whole problem.

How Do You Stop Rule Problems Coming Back?

Keep a permanent test member for every membership you sell, in a browser you never administer from, and open a protected page as each of them after any change to rules, plugins, theme or caching. It takes two minutes and it is the only check that reflects what a real customer experiences.

Prefer few broad rules over many specific ones. One rule per membership, aimed at a category that protected posts belong to, is far easier to keep conflict free than thirty single post rules accumulated over two years. When you add protected content, tag it into the existing category rather than writing a new rule for it.

Write down your caching exclusions somewhere outside the plugin, because they get lost during host migrations and plugin swaps, and a lost exclusion list is how a members area quietly becomes public again. Do the logged out walk through of the site once a quarter: the menu, the blog index, the search box, the category pages, and a direct file URL. Finally, treat every plugin addition as a protection change, since MemberPress maintains a long published list of plugins and themes that interfere with rules, and checking that list takes less time than diagnosing the result.

Frequently Asked Questions

Why can I see protected content when I am logged in as an admin?

Because that is intended behaviour, not a fault. MemberPress ignores all rules for any user with administrative rights, so an admin session always shows the full content regardless of what the rule says. It makes your own browser useless for testing protection. Check the public view in a logged out private window, and the member view with a real test account on the membership itself, in a separate browser.

Can I use two MemberPress rules on the same page?

Only in one documented case: one rule with a drip setting and one without, applied to the same content. Every other overlap is unsupported, and MemberPress states that subscriber access will not be correct when two rules cover one piece of content. The documentation gives no precedence order either, so there is no way to predict which rule wins. Remove the overlap until exactly one rule applies.

Why is my protected page visible to logged out visitors?

Full page caching is the usual answer. A cached copy generated while a member was viewing gets served to everyone afterwards, without WordPress or MemberPress running at all. Exclude protected URLs from page caching, switch off caching for logged in users, disable Elementor’s Element Caching if you use it, then purge the plugin, server and CDN caches together. If it survives that, check whether the page is an archive or custom post type that rules never covered.

Why can a paying member not open the content they bought?

Work through four checks in order. Confirm the Active column shows a green Yes on the Subscriptions screen, since a failed renewal produces this exactly. Confirm the rule names the membership they actually hold rather than a retired one with a similar name. Check drip and expiration timing against their real signup date. Then look for a second rule covering the same content, which produces incorrect access in either direction.

Do MemberPress rules protect PDFs and video files?

Not by themselves. A rule protects the page, while the file keeps its own direct URL that works for anyone holding it. File protection needs a Custom URI rule plus server level rewrite rules, officially supported on Apache and LiteSpeed only, with Nginx dependent on your host. Several extensions are excluded for performance, including php, jpg, png, css, js and svg. Where that does not fit, the Downloads add-on serves files through WordPress instead.

Why do my LearnDash courses ignore MemberPress rules?

Because courses are not governed by rules at all. Access is granted on the membership, through the LearnDash tab in the Membership Options box, and buying the membership enrols the student. Courses need to be set to Closed, memberships granting five or more courses enrol in the background and need working cron, and courses added after people bought require the Retroactive Tool to enrol existing members. Writing a rule for a course does nothing useful.

If you have worked through all ten and protection still behaves unpredictably, the cause has usually moved outside MemberPress. A security or login plugin interfering with sessions. A host level cache nobody mentioned. A theme rendering content through its own template rather than the standard function. A migration that carried rules across but not the memberships they point at. Those are worth checking once the ten above are genuinely ruled out, and not before.

The pattern behind nearly all of this is the same. A membership site is not one system deciding access, it is five or six systems agreeing to, and the rule is only the one you can see. Once you read it as a chain rather than a switch, the answer is usually sitting one link above where everybody was looking, and finding it costs far less than rebuilding around it.