TL;DR - check your site in 2 minutes
- What changed: since 24 October 2026 a password on a page also protects every page below it, including pages opened by their Notion ID (/<notion page id>), the same way membership tiers always have.
- Check: open your site in a private browser window. Pages that should be public must open without the password prompt, and private sections must ask for it.
- One page asks for a password but should be public: Pages → open that page → Protect Page → No password (overrides parent) → Save.
- Only the protected page itself should be private (for example a password on the home page only): open that page → Protect Page → uncheck Also protect sub-pages → Save.
- Sub-pages you had opened before 24 October were restored for you on 25 October. Nothing to do there.
The bug we fixed
A password on a page has always been meant to protect the pages below it, the same way membership tiers do. Because of a bug in our code, it did not work that way. When you saved a password, Super copied it only to the sub-pages that existed at that moment, and each page was then checked on its own. So:
- a sub-page you added later was public, although it sat inside a protected section;
- a page opened by its Notion ID instead of its address was public, even when the whole site had a password on its home page;
- clearing the copied password on a sub-page made it public, which is why some sites used it as a way to open a few pages.
That is a security problem: a page you believed was private could be open to everyone without you noticing. On 24 October 2026 we fixed the bug, and since then Super decides at the moment a visitor opens a page:
- If the page has its own password, that password applies.
- If not, Super walks up the page's address, for example from
/handbook/hr/holidaysto/handbook/hrand/handbook, and uses the password of the nearest protected parent. - If no parent has a password, the page is public.
Membership tiers have always worked like this, so passwords and memberships now follow the same rule. A sub-page you add to a protected section is protected from its first visit.
The fix closes the gap, but it also changed how some sites behaved, because they had relied on the bug to keep certain pages open. That is why there are now explicit settings for it: instead of depending on a side effect, you decide which pages stay public.
Who noticed a difference
If you had cleared the password on some sub-pages to make them public, they were briefly protected again by their parent's password after the fix. On 25 October we restored them: every such sub-page that existed before the change was set to No password (overrides parent), so it is public again exactly as you left it. You don't need to do anything for those pages.
The pages we could not restore this way are pages that have no address of their own in your Pages list, such as Notion pages a visitor opens through a /<notion page id> link on a site with page syncing turned off. For those, use the new checkbox described below.
Keep one sub-page public
- Open your site in the Super dashboard and go to Pages.
- Open the sub-page and find the Protect Page card.
- Choose No password (overrides parent) and save.
The page is now open to everyone, and so are its own sub-pages, unless one of them has a password of its own. For members-only sections, the same choice is called Public (overrides parent).
The Protect Page card tells you where a page's protection comes from, for example Inherited from parent — this page is password protected via /handbook, and the pages list shows a lock on every page that is protected, including the inherited ones.
New: Also protect sub-pages
Some sites put a password on the home page only to keep the home page itself private, and expect everything else to stay open. With the bug, that is what happened to pages added later or opened by their Notion ID. With the fix, a home page password protects the whole site. The new checkbox lets you choose that behaviour on purpose.
On the Protect Page card, under the password or the membership tiers, there is now a checkbox Also protect sub-pages. It is checked by default, so nothing changes for your site until you uncheck it.
The page itself | Sub-pages without their own protection | Sub-pages with their own password or tiers | |
Also protect sub-pages checked (default) | Protected | Protected by this page | Keep their own protection |
Also protect sub-pages unchecked | Protected | Public | Keep their own protection |
When the box is unchecked, the page keeps its password or tiers to itself:
- Sub-pages with an address in your Pages list are public.
- Pages opened by their Notion ID (
/<notion page id>) are public too. - A sub-page with its own password or membership tiers stays protected.
- Site search lists the public sub-pages and still hides the protected ones.
Check the box again and the sub-pages are protected again. Removing the password from the page makes everything below it public, whichever way the box is set.
How to set it up
- Open your site in the Super dashboard and go to Pages.
- Open the page that carries the password or the membership tiers, for example your home page.
- On the Protect Page card, uncheck Also protect sub-pages and save.
- Open a sub-page in a private browser window to check that it loads without the password prompt. It can take a few minutes for the change to apply.
FAQs
Do I need to change anything?
Usually not. If your whole section or site is meant to be private, the fix protects it the way it always should have, including pages you add later. Only if you want the password to stay on one page, uncheck Also protect sub-pages on that page.
Why did my site behave differently before?
Because of the bug: sub-pages that were not there when the password was saved, or that you opened by their Notion ID, were never checked against the parent's password. That was not the intended behaviour, and it could leave private content open. If you want the old result on purpose, uncheck Also protect sub-pages.
I made some sub-pages public before the fix. Are they still public?
Yes. On 25 October we set every sub-page that had no password of its own under a protected parent to No password (overrides parent). If you still see a password prompt on a page you meant to be public, open it in the dashboard and check its Protect Page card, or contact our support.
What is the difference between the checkbox and No password (overrides parent)?
No password (overrides parent) is set on a sub-page and opens that sub-page and the pages below it. Also protect sub-pages is set on the protected page and decides whether its protection reaches the pages below it at all. Use the first for a few public pages inside a private section, the second when only the page itself should be private.
Does this work for membership too?
Yes. Membership tiers inherit the same way, Public (overrides parent) keeps one members-only sub-page open, and Also protect sub-pages works the same for tiers as for a password.
Which plans include it?
Every plan that includes password protection or memberships. On the Free plan, page passwords are not available.
