How the cache decides, in one paragraph
SiteGround's SuperCacher has three layers: NGINX static caching, Dynamic Caching (full-page caching) and Memcached (object caching). Its Speed Optimizer tutorial says full-page caching is enabled by default at server level for all sites hosted at SiteGround. SiteGround's dynamic caching article explains how to read the result in the X-Proxy-Cache response header: HIT (served from cache), MISS (generated dynamically, for example on the first request or when caching is off) and BYPASS (the cache was deliberately skipped because the visitor is logged in, the URL is on the exclude list, or a bypass cookie is present).
The risk for a membership site is not that logged-in students get cached pages; SiteGround bypasses them by cookie. The risk is a page that must be personal for a logged-out visitor, such as a login form with a security token, a checkout step or a "thank you, here is your access" page, being cached and served to the next visitor.
What SiteGround already bypasses
SiteGround's dynamic caching configuration article lists cookies and URL fragments that are always served dynamically. It describes the URL list as partial or full matches, which has a side effect: any URL containing one of these words skips the cache, including public pages you might want cached.
| Type | Listed by SiteGround | What it covers on a course site |
|---|---|---|
| Cookie | wordpress_logged_in_ | Every logged-in user, including students viewing lessons |
| Cookie | wp-postpass_ | Visitors who entered a password-protected post password |
| Cookie | wp_woocommerce_session, woocommerce_cart_hash, woocommerce_items_in_cart=1 | Anyone with a WooCommerce cart or session |
| Cookie | edd_items_in_cart=1, it_exchange_session_, yith_wcwl_products | Easy Digital Downloads, iThemes Exchange and YITH wishlist sessions |
| Cookie | wpSGCacheBypass=1 | A bypass cookie you can set yourself |
| URL | wp-login, preview=true, cart, my-account, checkout, addons, add-to-cart, wp-cron.php, xmlrpc.php, contact | Default WooCommerce pages and WordPress login |
| URL | task=registration, register, view=registration|administrator|remind|login | Registration URLs that use these words |
| URL | status.php, update.php, install.php, user, info, flag, ajax, aha | Any URL containing these words, e.g. /user-dashboard/ or /course-info/ |
What a membership or course site usually still needs to exclude
Membership plugins name their pages however you configure them. If your account page is /account/, your login page is /login/ or /sign-in/, or your checkout is /join/ or /enroll/, none of those slugs appear in SiteGround's default list. A logged-out visitor requesting them carries no logged-in cookie, so the page can be cached.
Open your membership or LMS plugin's settings, write down the actual URL of each page it creates, and add any that are personal or contain forms to Speed Optimizer, Caching, Exclude URLs from Caching. The tutorial says you can enter a relative path or full URL, and that an asterisk works as a wildcard: /join/* excludes everything under /join/, and *enroll* excludes any URL containing "enroll".
Two other settings matter. Exclude Post Types from Caching serves every post of a chosen type uncached to all users, which is useful if your plugin uses a custom post type for gated content that must never be cached even for logged-out visitors. And the File-Based Caching option has a Logged-in Users Cache setting that is off by default; leave it off on a membership site, because the tutorial notes it creates a separate cache per user and can increase storage use on sites with many users.
- Login, password reset and two-factor pages (any slug your plugin uses).
- Registration and checkout pages, including every step of a multi-step checkout.
- Thank-you and order confirmation pages.
- Account, profile, billing and subscription management pages.
- Course dashboards or "my courses" pages that a logged-out visitor might reach before redirecting.
- Pages that show a logged-out teaser for gated lessons, if the teaser includes a form with a security token.
Frontend optimization is a separate risk
Page caching is not the only Speed Optimizer feature that can break a membership site. The frontend optimization tutorial warns that both combining JavaScript files and deferring render-blocking JavaScript "may cause issues with scripts that require a certain order of execution." Checkout forms and payment fields are a common casualty.
The tutorial describes excluding specific scripts from minification and an Exclude from Deferral of Render-blocking JS option for deferral; it does not describe an exclusion option for combining JavaScript. If a checkout or login form misbehaves after you enable these options, exclude the payment or form script from minification or deferral, turn JavaScript combining off, and retest.
Verify every page with the header, not by eye
Looking at a page while you are logged in as an administrator tells you nothing, because your own logged-in cookie bypasses the cache. Test as a logged-out visitor. Speed Optimizer has a Test URL Caching Status tool at the bottom of the Caching page that checks whether a URL is cached and confirms excluded URLs are served dynamically. From a terminal, request the page twice in a private session and read X-Proxy-Cache on the second response.
| Page | Expected X-Proxy-Cache for a logged-out visitor | If you see HIT |
|---|---|---|
| Home, sales page, public course catalogue | HIT after the first request | Working as intended |
| Login page | BYPASS | Add its slug to Exclude URLs |
| Registration or checkout (every step) | BYPASS | Add its slug to Exclude URLs; retest each step |
| Thank-you or order confirmation | BYPASS | Add its slug; check no personal data is on a cached copy |
| Account and subscription management | BYPASS | Add its slug |
| A lesson URL, requested while logged in as a student | BYPASS (logged-in cookie) | Investigate; the logged-in cookie should bypass |
A ten-minute checklist after any change
- List every URL your membership, LMS and payment plugins create; keep the list in your runbook.
- Compare it with SiteGround's default exclusions and add missing slugs with wildcards where a page has sub-steps.
- Run the Test URL Caching Status tool or check X-Proxy-Cache for each listed URL while logged out.
- Log in as a test student and confirm lessons show BYPASS.
- Complete one test purchase end to end, then purge the cache and repeat it.
- If you enabled JavaScript combine or defer, retest checkout and login forms on mobile and desktop.
- Recheck after renaming any page slug or changing membership plugins; exclusions are URL-based.
Questions before you decide
Does SiteGround cache pages for logged-in members?
Not by default. The dynamic cache bypasses requests carrying the wordpress_logged_in_ cookie, and the File-Based Caching Logged-in Users Cache option is off by default.
Why is my public page never cached?
SiteGround matches its excluded URL list on partial matches, so a URL containing words such as user, info, contact or register is served dynamically. Rename the slug if that page should be cached.
Does Memcached need exclusions too?
Memcached is object caching for database queries, enabled in Site Tools and in the plugin. The URL exclusions described here apply to Dynamic and File-Based page caching.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- SiteGround: Speed Optimizer caching tutorial Accessed 29 Oct 2026
- SiteGround KB: Dynamic caching configuration Accessed 29 Oct 2026
- SiteGround: Speed Optimizer frontend optimization tutorial Accessed 29 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.