BigScoots Member Caching: Check User Isolation on Essential 75

What Essential 75 needs

| Decision | Published configuration | |---|---| | Base hosting | One site, 75,000 visits, 10 GB storage and 150 GB bandwidth. | | Logged-in caching | This guide covers Essential 75 with confirmed Boost eligibility; Boost is not included in E75. | | Suitable workload | Repeat protected pages using a supported membership integration. | | Main boundary | A listed integration does not validate your custom entitlement or payment flows. |

Confirm legacy or other Enterprise arrangements separately. Boost's 500 GB Cloudflare bandwidth allowance does not establish an upgrade to the host's origin resources or visit limits.

Four useful capabilities

**Per-user cached pages** target authenticated repeat visits that ordinary anonymous caching misses. BigScoots describes a private cached representation for each user; that is the provider's architecture claim, not our privacy or speed measurement.

**User-specific invalidation** can refresh the affected member after supported account or purchase events without discarding every other user's cache. Verify the events your site actually uses.

**Documented membership integrations** include MemberPress, WooCommerce Memberships, WishList Member and Leaky Paywall. They reduce custom integration work for supported standard flows; the list does not certify every extension or hook.

**Activation, status and targeted purge controls** give administrators a way to inspect the feature and recover stale content. Eligibility and production cache settings still matter; a successful homepage cache test cannot prove member-content isolation.

Budget the complete configuration

Essential 75 costs $35 monthly or $350 prepaid annually. Optional Boost costs $10 per month, billed monthly for one site, with installation and setup included.

At unchanged published rates, the combination is $45 per month, or $350 upfront plus twelve $10 payments: $470 across the first year. That is not a $470 prepaid package. Membership-plugin licences and custom development are separate.

The pricing FAQ says hosting prices include tax, while the Terms require applicable additional taxes. We could not reconcile that discrepancy with a final customer-specific quote; confirm your invoice total and add-on tax treatment before paying. The FAQ's historical price stability also does not override the Terms' future-price-change provision.

Prepare the right cache path

Confirm your plugin versions and integration with support. Review your actual login, registration, account, payment and webhook routes; do not copy another cache plugin's exclusion syntax or apply a blanket cache-everything rule. MemberPress's guidance identifies sensitive flows, but it does not replace BigScoots-specific configuration.

Use staging for compatibility work. BigScoots says staging is never cached, so testing the actual logged-in cache requires a provider-coordinated, controlled production check with synthetic accounts and data. Cache and page cache must be enabled on the eligible production configuration.

An administrator can inspect **Settings → BigScoots Cache** (or the BigScoots Helper submenu), then **Cache → Enable Cache for Logged-in Users**. Check the current state and activate deliberately after confirming eligibility.

Check isolation and changed access

The following is our proposed acceptance procedure, not a report of an observed vulnerability or completed test.

1. Create dummy members A and B with the **same WordPress role and membership level**, but different visible personal markers. Use separate browser profiles. Different roles alone could miss a cache partitioned by role instead of user.

2. Ask support to confirm that a chosen protected URL actually uses logged-in caching. Warm it in both profiles, then request it again and check each user's own marker. A deliberately bypassed account or payment page cannot be the sole proof.

3. Through a supported test path, change A's entitlement while B stays active. Confirm A's actual access state in the membership plugin before judging the result. In MemberPress, cancelling recurring billing normally leaves access until the current transaction expires.

4. Request the protected URL again in both retained sessions. **Do not manually purge, clear cookies or log out first**: those actions could conceal failed automatic invalidation. A must receive the content allowed by its confirmed state; B must retain its own content and access.

5. Test logout separately, then make a new network request to the protected URL. The response must deny member-only content to the logged-out visitor. A browser Back snapshot alone does not establish what the server currently serves.

If content is wrong or stale, record the failure, disable logged-in caching and purge through the provider-supported procedure with support. Passing these checks only supports the tested routes, versions and transitions; it is not a complete security audit.

Choose after the access checks

Choose this configuration when supported integrations, recurring cost and controlled checks fit the site. Keep a reliable existing setup when authenticated caching solves no demonstrated problem. Wait when custom entitlements, cache eligibility or the final invoice remain unresolved.

Review the separate [backup workflow](/en/hosting/bigscoots-essential75-backups) before changes and the [PHP worker capacity guide](/en/hosting/bigscoots-essential75-php-workers-woocommerce-capacity) when uncached workload is the bottleneck. Caching does not establish unlimited capacity.

Affiliate disclosure: Toolnavia may earn a commission if you buy an eligible Essential 75 plan through our BigScoots referral link.