How to Set Up Gated Membership Content in HubSpot's CMS Hub
Membership content puts pages behind a login without building a separate portal. How to set it up, how to keep SEO working, and the privacy obligation that starts the moment the gate collects an email address.
Membership content is HubSpot's way of putting pages behind a login, using your CRM records as the list of who gets in. No separate application, no second set of user accounts, no integration.
It is not about making people feel special. It is what you reach for when a specific group of people needs access to specific documents and everyone else should not have it.
Who actually needs this
Three shapes come up repeatedly for Australian businesses at 60 to 200 people.
A professional body with paying members. CPD resources, technical guidance, and templates that members have paid a subscription to access. The gate is what the subscription buys, and the list of who is current already lives in the CRM.
A franchise or dealer network. The operations manual, brand assets, pricing sheets, and training material go behind a partner login. Not because it is exclusive, but because franchisee pricing in public is a commercial problem and an outdated procedure in public is a liability.
A business with a paying customer base. Implementation guides, admin documentation, and release notes that customers need and prospects should not be reading, without commissioning a customer portal to hold six PDFs.
Notice what all three have in common. There is a real reason the content is restricted, and there is already a record in the CRM that says who qualifies. If neither of those is true, you probably want a normal gated form, not membership.
Before you build: the privacy obligation
A membership gate collects personal information. Usually an email address, often a name and a company, sometimes more.
That means Australian Privacy Principle 5 applies, and it applies at the point of collection. APP 5 covers notification of the collection of personal information: at or before the time you collect it, you have to tell the person who you are, why you are collecting it, and what you will do with it.
In practice, on the registration page:
- Say who is collecting the information, by the legal entity name people will recognise
- Say why, including whether registering also means marketing email
- Link your privacy policy from the form itself, not from the footer alone
- Do not bundle marketing consent into the access request silently. If registering for the resource library also subscribes them to a monthly newsletter, say so where they can see it
Also decide, before launch, how someone stops being a member. When a subscription lapses or a franchisee leaves the network, something has to remove their access, and it is better if that something is a workflow rather than someone remembering.
Setting it up
1. Build the pages
Create the pages in CMS Hub exactly as you would any other page. Guides, documentation, video pages, download pages, pricing sheets. Nothing about the build is different because they will be gated.
Structure them as though people will need to find things, because they will. A landing page for the member area, then sections, then documents. A flat list of 40 PDFs is where these projects go to die.
2. Turn on membership
In the page settings, find the "Require membership to access page" toggle. Switch it on, then choose which membership types can access that page.
That is the mechanism. The interesting decisions are all in the next step.
3. Define the groups
Membership access runs off your CRM data, which is the reason to use this feature at all. You can build access lists from contact properties and list membership: paying customer or not, subscription status, partner tier, role, region.
Two rules worth following.
Base access on a property you already maintain for another reason. If your finance system already sets a "subscription current" property, use that. A property created solely to control web access is a property that will go stale, because nothing else depends on it being right.
Keep the tiers to the number you can actually maintain. Bronze, Silver, and Gold is three login experiences, three sets of pages to keep current, and three ways to get someone's access wrong. Most organisations need one gate, possibly two.
The parts people get wrong
The login page
Not sure which pages are worth gating?
Most teams gate the page that was bringing the traffic in.
Keep the form short, use your own branding rather than a default, and make password recovery obvious and functional. Test the recovery email properly, from a real address, before launch. It is the single most common support request a member area generates and the easiest thing to leave broken.
Write instructions for first time registration in plain language. Your members are not necessarily comfortable with logins, especially in a professional body with a wide age range.
The access denied page
Someone who is not logged in, or does not qualify, will land on your gated pages. Google's snippet will send them there, and so will a link a member forwarded.
That page should explain what is behind the gate, who can access it, and what to do next: log in, register, or renew. Default "access denied" text with no route forward turns an interested person into a bounce and a support email.
Content that goes stale behind a login
Nobody sees gated content by accident, which means nobody notices when it is two years out of date. If you are gating an operations manual or technical guidance, put a review date on each document and someone's name against it. This is a real risk with procedural content, not a tidiness issue.
SEO: gated pages do not rank, so build the gate a front door
Search engines cannot see behind a login, so gated pages contribute nothing to your search visibility. That is the trade, and it is fine as long as you have planned around it.
Build public pages that describe what is inside. A page that explains what the member resource library contains, who it is for, and how to get access, optimised for the terms people search when they are looking for exactly that. Include the sign up path and, where it makes sense, one sample document ungated so people can see the standard of what is behind the gate.
That way the public pages do the search work and the gate does the access work, instead of asking one page to do both badly.
What to measure
Four numbers, and the last one is the one that matters.
- Registrations. New members over time, against the public pages driving them.
- Active members. How many registered members logged in this quarter. Registrations without logins means the gate is working and the content is not.
- What gets used. Which documents get opened and which never do. In a member area, this is your content plan.
- Retention, or renewal. For a subscription or a network, whether members with access renew at a better rate than members without. That is the business case for the whole thing.
HubSpot's reporting covers all four, because the member is a contact record.
Once it is working
A few things worth doing later rather than at launch.
Release content on tenure or completion, so a new member is not handed 40 documents on their first login. Use smart content to show different sections to different member types on the same page, which is easier to maintain than separate page trees. And extend the member area to registration for member only events, so the same record controls both.
Community features are the common request and the hardest to sustain. A forum with no posts is worse than no forum, so only build one if somebody's job includes being in it every day.
Start with one gate
Pick the single group with the clearest reason to have restricted access, gate the documents they need, and get the login and recovery working properly. Expand once you know people are using it.
How do your members actually get their login?
The sign-up gets tested far more often than the way back in.
If you are still deciding whether this is a CMS Hub job at all, we have written about what Content Hub actually covers, choosing the right CMS for your team, and how HubSpot CMS compares to WordPress.
And if the harder half of your project is the access rules rather than the pages, that is usually a CRM data question. Here is how we build websites on HubSpot.