How to Test Every User Role on a WordPress Membership Site at Once
One site, many people
A membership site is really several sites wearing the same URL. The admin sees settings. A Gold member sees the premium course. A Silver member sees a teaser and an upgrade button. A visitor who isn’t logged in sees the sales page. A member whose payment failed sees something else again.
Every role on your site, signed in side by side. No logging out, no second browser.
Every change you make has to work properly for all of those roles. Move a lesson, edit a content rule, add a coupon, and you need to check it as each person who’ll see it.
The trouble is that a normal browser only lets you be one of those people at a time. Sign in as your test member and your admin tab is signed out, because every tab shares the same cookies. So you sign out, sign in, check, sign out, sign back in as admin, change something, and start again.
This guide shows a faster way: every role signed in at once, side by side in one window, so you can make a change as admin and see what it does to each member the moment you refresh.
Each role lives in its own colored Identity. Edit the lesson as admin, then click the Gold, Silver, Lapsed or New visitor tab to see that same lesson the way each of them does.
Why don’t incognito windows or user-switching plugins solve this?
Because each one gives you a single extra role at a time, and a membership site needs five or more signed in at once. Here are the four fixes plugin help pages usually suggest, and where each one breaks.
| Workaround | What you get | Where it breaks |
|---|---|---|
| Log out and back in | One role at a time | Slow, and you lose your place every time you switch |
| An incognito or private window | One extra login | A third role means another browser. Close the window and you start over |
| A user-switching plugin | Jump to any user from the admin screen | Still one role at a time, and you’re testing a switched session, not a real login. It also means installing a plugin on the site |
| Several browsers | One login per browser | Four browsers open and no idea which account is in which. Your extensions and settings differ in each |
Incognito deserves a special mention, because it’s the tip plugin docs give most often. It’s fine for a quick look at the logged-out view. But a membership site rarely has two kinds of user.
These workarounds only buy you one extra role. That's not enough.
It has an admin, two or three levels, a lapsed member and a visitor, and incognito covers exactly one of them.
Read next: User Switching vs. separate Identities, for when a plugin isn’t enough.
How do I stay signed in as several users on one site at once?
Ghost Browser gives each tab an Identity. An Identity keeps its own cookies, so a tab in one Identity can be signed in as admin while the tab next to it is signed in as a Gold member, on the same site, in the same window. Each Identity has a name and a color, so you always know who you’re looking at.
Here’s the setup for a typical membership site. You do it once, and then it’s there every time.
- Create a test user for each role. In WordPress, add one user per membership level, plus one with an expired or cancelled membership. Use an address pattern you’ll remember, like
gold@yoursite.test. - Create one Identity per role. Open the Identity menu and choose New Identity, and name it after the role: Admin, Gold, Silver, Lapsed. Give each a different color.
- Sign each Identity in. Open your site in each Identity’s tab and log in as that role’s test user. They all stay signed in, side by side.
- Check the logged-out view without signing out. Right-click any tab and choose Duplicate into new Temporary Identity. You get the same page as a brand-new visitor, while every other tab stays signed in.
- Save the set as a Workspace. Name it after the site. Next time, reopen the Workspace and every role comes back signed in, on the pages you left them.
- Make your changes. Now make a change in the Admin tab, then click across the colored tabs and refresh. You see what every member sees, in seconds.
- Go about your day. Spot checks take seconds, so you can move on to another Workspace as your day goes on. Come back minutes, hours, days or weeks later and every role is still ready to test.
Tip: Need a member who signs up from scratch? Use a Temporary Identity. Close its last tab and its cookies are gone, so the next one starts fresh. To reset one Identity without signing out the others, see Reset One Login Without Logging Out of Admin.
What should I check as each role?
With every role open, run down this list after any change. It catches most of what members email support about. Test as the person who’ll see it, not as the person who built it.
| Role | What to check |
|---|---|
| Admin | The change saved, and settings show what you expect |
| Each paid level | Content they paid for is visible; content above their level is locked with the right upgrade message; menus and dashboards show the right links |
| Lapsed or cancelled member | Paid content is locked again; the renewal or win-back message shows; no leftover access through direct links |
| Logged-out visitor | Sales pages, pricing and teasers show; protected pages redirect to login or the sales page, not an error |
| Brand-new sign-up (Temporary Identity) | Registration, checkout, welcome email trigger and first login all work, start to finish |
Two things are worth testing as every role, every time: direct links to a protected page (paste the URL into each tab), and anything that remembers the visitor, like pop-ups, onboarding tours and “once per day” messages.
Test as the person who'll see it, not as the person who built it.
What kinds of sites need this?
Any site where different people see different things. Membership sites, online courses and sites built on a role manager plugin are the most common, but stores, communities and marketplaces need the same testing.
If two people can see different pages, you have more than one site to test.
Membership sites
Sites built on plugins like MemberPress, Paid Memberships Pro, Restrict Content Pro and WooCommerce Memberships. Keep an Identity for each membership level, plus a lapsed member and a logged-out visitor, and check content rules, the pricing page and each member’s account page.
Online courses (LMS)
Sites built on LearnDash, LifterLMS, Tutor LMS or Sensei LMS. Keep Identities for the admin, an instructor or group leader, a student partway through a course and a visitor. Check drip schedules, lesson locks and progress as the student while you edit the course as admin.
Role manager plugins
Sites that use Members, User Role Editor or PublishPress Capabilities to create custom roles. Every custom role is another version of the site, so give each one an Identity and check what it can see, edit and publish after any capability change.
Stores with different kinds of customers
WooCommerce stores with wholesale pricing, subscriptions or customer-only products. Keep a retail customer, a wholesale customer, a subscriber and a guest signed in, and watch prices, products and checkout change as you switch tabs.
Communities and forums
Sites built on BuddyBoss, BuddyPress or bbPress. Communities need at least two members talking to each other. Give each member an Identity, send a message or join a group in one tab, and watch it arrive in the other, while a moderator Identity sees both.
Multi-vendor marketplaces
Marketplaces built on Dokan, WCFM or WC Vendors. Keep the admin, two vendors and a customer signed in, so you can place an order as the customer and watch it land in the right vendor’s dashboard.
Others
Client portals, booking sites, job boards and directories all show different pages to different people. So does your own plugin if it has role or capability rules: keep an Identity for each WordPress role (administrator, editor, author, subscriber) and run your release checks across all of them before you ship.
Who on the team uses this?
Anyone who has to see the site as someone else: the developer building it, the QA tester checking it, the site owner, the support desk, the agency running it and the designer polishing it.
The developer, the tester and the support desk all need to see what the member sees.
- Developers: build as Admin in one tab and refresh the member tabs to see the change land, with DevTools open in any of them. One Workspace per project keeps every role ready.
- QA testers: run the role checklist across every Identity side by side, and reproduce a bug as the same kind of user who reported it, without borrowing anyone’s login.
- Site owners and admins: check an update as every member before your members see it, with nothing extra installed on the site.
- Support staff: keep a test account at each level signed in. When a Silver member writes in, you see what Silver sees while your admin tab stays open.
- Agency project managers: keep a Workspace per client, and walk the client through the site as each role from one window.
- Designers and content editors: check layouts, menus and copy in the logged-in and logged-out views without asking a developer to sign you in.
And once the site is live, whoever promotes it can work the same way: agencies and social media managers keep each brand’s social accounts in its own Identity, all signed in at once.
When should I test as every role?
Before every release or update. Every plugin update, theme change, new coupon or new membership level can change what a member sees. Admins see everything, so a release can look fine to you and still lock a paying member out.
Admins see everything, so a release can look fine to you and still lock a paying member out.
Before every release, reopen your Workspace, run the checks above as each role, then sign up from scratch in a Temporary Identity.
Read next: Before every release, see your site as every customer, the full pre-release checklist.
Does Ghost Browser help me test every environment?
Yes. Keep one Workspace per environment, such as local, staging and live, and use the same role Identities in each. Checking a change everywhere then means switching Workspaces, not logging in again. That matters because a change that works on staging can still break on live: caching, payment settings, email and plugin versions often differ on production, and members notice those first.
A change that works on staging can still break on live.
Set it up once
- One Workspace per environment. For example Local, Staging and LIVE, each holding tabs for that environment’s address.
- The same Identities in every Workspace. Sign your Admin, Gold, Silver and Lapsed Identities in to each environment once. Each environment has its own address, so one Identity can stay signed in to all of them.
- One color per role, everywhere. Gold is the same color on local, staging and live, so you can read any tab at a glance.
- Make live impossible to miss. Name it in capitals, like “LIVE: yoursite.com”.
Run every release the same way
- Build and check in Staging. Make the change as Admin, then click through each role’s tab.
- Push the change to live.
- Switch to the LIVE Workspace and repeat. Same checks, same roles, plus a sign-up from scratch in a Temporary Identity.
- Compare. Anything that passes on staging and fails on live is usually caching, payment or email settings, and you’ve caught it before a member does.
Common pitfalls, and how to avoid them
- Editing the wrong site. Never mix staging and live tabs in one Workspace, and glance at the address bar before you click Update as Admin.
- Test accounts that only exist on staging. Create the same test members on live, with clearly named test addresses, and keep them out of your mailing list and reports.
- Real charges on live. Use a 100% off test coupon for live sign-ups, then delete the test order.
- Cached pages for visitors. A logged-out visitor on live may get a cached page. If the Temporary Identity view looks out of date, clear the cache and check again.
- Staging emailing real members. A staging copy of live holds real members’ addresses. Turn staging email off, or send it to a test inbox, before you test sign-ups there.
Do I have to set this up every time?
No. You only set this up once. Save it as a Workspace, and the next time you test, every role opens already signed in.
- One Workspace per site. Reopen it and every role is signed in where you left it.
- Staging and live. A Workspace for each, as described in the section above.
- Client sites. Agencies can keep a Workspace per client, with the client’s editor role next to their own admin login, for handoff and support.
Frequently asked questions
Do I need to install anything on my site?
No. Nothing changes on the site, so you can test production the same way you test staging.
Will my Chrome extensions and DevTools still work?
Yes. Ghost Browser is built on Chromium, so DevTools and Chrome extensions work as they do in Chrome.
How is this different from Chrome profiles?
Chrome opens each profile in its own window, so you switch windows to switch people. Identities sit side by side as color-coded tabs in one window, and you can save the whole set as a Workspace.
Does Ghost Browser run on Mac, Windows and Linux?
Yes. There’s a 64-bit build for Windows, two Mac builds (one for Apple chips, one for Intel chips), and a 64-bit .deb package for Debian and Ubuntu on Linux.
Can I see what members in another country see?
Yes, on the Pro plan. Proxy Manager can put a proxy on an Identity, so one tab sees your site from another region while the others stay local. You bring the proxies you already use.
Is it free?
The free plan includes up to three Identities, enough for admin, one member and a temporary visitor. Paid plans remove the limit.
See every role at once
Download Ghost Browser free, create an Identity for each role, and see your whole site the way your members do, after every change.
Try it with your own accounts.
Free for up to three identities. No credit card needed.