A membership site, a course platform, a client portal. Anything where visitors log in, behaves differently from a normal site in one respect that governs everything: most of your traffic cannot be cached.
That single fact changes the hosting requirements, the performance work and the security posture.
Page caching does not help logged-in users
A cached page is one file served to everyone. A logged-in page shows one person's name, their courses, their orders, so it cannot be shared.
Every caching layer therefore excludes logged-in sessions by default, and it must: caching a logged-in page can serve one member's page to another, which is a serious incident instead of a bug.
So a membership site's real capacity is how many members can be active at once, not how many visitors it can serve, and that number is usually far lower than people assume from testing the public pages. There is more on what runs out in handling a traffic spike.
Object caching is the layer that does help
Since pages cannot be cached, the gain has to come from making each page cheaper to build. Object caching stores database query results in memory so repeated queries are not repeated.
That is the one caching layer that helps logged-in users, and on a membership site it is not optional in the way it is on a brochure site. There is more on what each does in caching layers.
Cache the public pages normally as well. The marketing pages, the course catalogue and the sales pages are shared content and should be served from cache.
Plan for memory, not bandwidth
Logged-in requests run the full application, so concurrency is bounded by how many PHP processes you can run and how much memory each holds.
On shared hosting that ceiling arrives quickly, and the symptom is a site that hangs and then loads during busy periods instead of one that errors, requests are queuing.
A membership site with real usage generally belongs on a VPS or a plan with dedicated resources sooner than an equivalent brochure site would. Comparing the tiers goes into when that is genuinely true rather than assumed.
Sessions have to be shared, if anything is
Default PHP sessions are files on one server. That is fine on one machine and breaks the moment there is more than one, because a member's session exists on whichever server took the first request.
The symptom is members being logged out apparently at random. If you ever move to more than one application server, sessions must move to a shared store, and it is worth knowing that before the move rather than during it.
Protect the files, not just the pages
The mistake that gives paid content away.
A course video or a PDF uploaded to the media library sits at a predictable URL and is served by the web server, not the application. The membership plugin controls the page; it does not control the file.
So a member can share the direct link and anyone can download it, membership or not.
Protected content must be served through the application, which checks access and then sends the file, or stored outside the web root entirely with the application streaming it. Test it yourself: copy a file URL and open it in a private window while logged out. Selling digital products sets out the access methods.
Registration is an attack surface
Open registration means anyone can create an account on your site, and automated systems will.
Set the default role to the least-privileged one that works, and check it. A default of anything above subscriber is a serious misconfiguration. For the roles, see WordPress user roles.
Add email confirmation and a spam control on the registration form. Then watch the user list: a sudden rise in registrations that never log in again is automated, and those accounts are a liability instead of an audience.
Mail becomes business-critical
Password resets, welcome messages, course notifications. A membership site whose mail fails has members who cannot get in and no way to tell you.
Send through authenticated SMTP in place of the server's default, and confirm messages arrive at major providers rather than assuming. Fixing WordPress email goes into why mail is often accepted and then discarded.
Watch the sending volume too. A course announcement to every member at once is bulk mail, and it belongs on a sending service rather than your hosting account. Sending a newsletter properly deals with the distinction.
You are holding personal data now
Names, addresses, payment references, and a record of what each person accessed.
That raises the stakes on everything else in this list: backups that are actually restorable, access limited to people who need it, and a plan for what happens if it leaks.
It also means old accounts are a liability in place of an asset. Deleting data for members who left is a reasonable policy and worth deciding deliberately.
Test as a member, regularly
Keep a real member account and use it.
Log in, view protected content, complete whatever the purchase or renewal flow is. Then log out and confirm the same content is refused.
That last check is the one that catches the file-protection failure above, and it is not visible from an administrator account, which sees everything regardless.
Check what is actually protected
A membership site restricts content and the restriction applies to the page rather than to the files behind it. Request a protected page while logged out and confirm it is refused. Then request any file it references, such as a document or a video, directly by its address. Those are frequently served without any check at all, which means the content is public to anybody with the address and the membership only controls who can find it. That distinction is the difference between a paywall and a polite suggestion.