Not every knowledge base belongs on the open internet. Internal process docs, partner playbooks, or guides for a paid product often need to stay out of public view — and out of Google. Password protection is the quickest way to get there: one password, set once in the console, locks the whole site.
How the login flow works
With password protection enabled, every URL on your site — the home page, individual articles, even search — shows a lock screen instead of content until the visitor authenticates.
The visitor types the shared password once. If it matches, Emovart sets a secure cookie in their browser and sends them straight on to the page they originally asked for.
Because the unlock is stored in a cookie, returning visitors on the same browser aren't asked again — the site feels completely normal to them until the cookie expires or gets cleared.
Setting up password protection
- Open Settings → Help Centers on emovart.studio and select your site.
- Switch to the Protected Access tab.
- Choose Password as the access mode.
- Type the password you want to use and click Save.
The lock takes effect immediately — no redeploy, no resync. Open your site in a private browser window to confirm the prompt appears.
To rotate the password later, just type a new one and save. Existing unlock cookies stop working, so everyone is asked for the new password on their next visit — handy when someone leaves the team or a link travels further than intended.
How secure is password protection?
The check happens on Emovart's servers, not in the browser. Protected pages are never delivered until the correct password has been entered, so there is nothing to dig out of the page source, and everything travels over HTTPS. The unlock cookie is signed, which means it can't be handcrafted or edited to fake access.
Protected sites also tell search engines not to index them, so your content won't surface in search results while the lock is on.
Be clear-eyed about what a shared password is, though: one credential for your whole audience. Anyone who knows it can pass it along, and you can't revoke a single person — only rotate the password for everyone at once. That makes it a great fit for keeping docs semi-private, and the wrong tool for genuinely sensitive material.
Getting the password to your readers
Put the password where your audience already looks: the onboarding email for new customers, your internal wiki or team password manager (1Password, Bitwarden, and friends all work) for employees, or the welcome message of your community. Avoid posting it anywhere public — that quietly turns your protected site back into an open one. And whenever someone who shouldn't have access anymore does, rotate the password and re-share it.
Other ways to protect access
A shared password is the simplest option, but Emovart offers two more precise ones:
- Email list from Notion — keep an allowlist of addresses in a Notion table; visitors verify with a one-time code, and you can revoke a single person by deleting a row. See Protecting your site with an email list from Notion.
- Custom backend authentication — your own server decides who gets in and issues signed tokens, ideal when readers already log in to your product. See How To Set Up Custom Backend Authentication For Your Emovart Site.