Password Protection and Site Search

This content was generated with the assistance of AI and should be verified against the official Webflow documentation before being relied on in production.

This sub-section’s Webflow bibliography lists the reference material consulted while preparing these pages.

This page describes password protection and site search as they were on 2026-10-28, the date on which their facts were checked against Webflow’s documentation. Both features belong to the hosting layer of a site, so they need a Site plan with hosting, not just a Workspace plan, and the limits differ by tier. Plans are named by tier only; the Plans, Workspaces, Seats and Roles page explains the tiers, and the Product Changes and Deprecations page tracks later changes. Webflow’s Help Center still uses the older plan names CMS and Business in many articles. Since the May 2026 plan change those two tiers have been merged into Premium, so an article that says "CMS and Business hosting plans" refers to Premium and above in today’s naming.

In the running example, the Fernbrook Gardens team uses both features. The Volunteers area holds rotas and instructions that must not be public, so it is protected by a password. The Plants collection holds hundreds of items, so visitors need a search box to find a plant by name. The page ends with the third need, a members-only area with personal logins, which Webflow no longer provides natively.

What each feature is for

Password protection and site search solve different problems and are often confused with real access control.

  • Password protection puts a shared password in front of a page, a folder of pages or the whole site. Anyone who knows the password gets in. There are no individual users, no roles and no audit of who looked at what.

  • Site search lets visitors type a query and see matching pages and CMS items from the published site. It is a hosted feature, so it needs no external search service for small and medium sites.

  • Neither feature is an accounts system. The retired User Accounts feature is covered at the end of the page.

Password protection

Webflow can ask for a password before it serves a page. The restriction is applied by Webflow’s hosting, so it works only for sites that are hosted with Webflow on a Site plan. Free, unhosted sites in a free Workspace cannot protect the whole site, and password protection of pages and folders needs a Site plan. This also means that a site exported as code or served from another host loses the feature; see Code Export and Portability and Reverse Proxy and Custom Hosting.

Three levels of protection

A password can be set at three levels.

Level Where it is set What it covers

Site

Site settings, in the password section

Every published page of the site. Available on hosted sites with a Site plan.

Folder

The Pages panel, in the folder settings

Every page inside the folder, including pages in nested folders.

Page

The Pages panel, in the page settings, under the general section

One page. Static pages are supported, and CMS template pages are covered in the Help Center article.

The steps are the same in spirit at every level: open the settings, switch password protection on, type the password, save, and publish the site. Nothing is protected until the site is published, because the password is part of what the hosting layer serves.

Precedence between levels

Webflow documents the following behaviour for folders: a password set on a folder replaces any password that was already set on the pages or subfolders inside it, and pages inside a folder inherit the folder’s password. In practice this gives a simple mental model.

flowchart TD A[Visitor requests a page] --> B{Page inside a
protected folder?} B -- yes --> C[Ask for the folder password] B -- no --> D{Page has its
own password?} D -- yes --> E[Ask for the page password] D -- no --> F{Site password set?} F -- yes --> G[Ask for the site password] F -- no --> H[Serve the page] C --> H E --> H G --> H

The diagram summarises the documented rules; when two levels are set at once and the result is not what you expect, test the page in a private browser window after publishing, because the browser remembers a correct password for the visit and hides the problem.

The password page

A visitor who requests a protected page sees a password page instead. Webflow creates it as a utility page in the Pages panel, together with the 404 page and, once search is added, the search results page. The password page is reached under the path /401, and you design it like any other page: add a heading, text, a logo and style the form. Two points matter:

  • All protected pages share one password page. Different folders and pages may have different passwords, but the visitor sees the same design everywhere, so write neutral text such as "This area is for Fernbrook volunteers".

  • The form is generated by Webflow. You restyle it with classes, but you do not build the form logic yourself.

Fernbrook Gardens: protecting the Volunteers area

The Volunteers pages live in a folder called volunteers, with a rota page, a handbook page and the volunteer registration form. The setup is:

  1. In the Pages panel, create the folder volunteers and move the three pages into it.

  2. Open the folder settings, switch password protection on and set a long passphrase.

  3. Open the utility pages and style the password page with the garden’s brand variables.

  4. Publish the site and test in a private window.

  5. Share the passphrase with volunteers outside Webflow, for example in the welcome email.

Because the folder password replaces any password on its pages, the team does not need to set the password on each page, and a new page dropped into the folder is protected from its first publish.

What password protection does not do

Protection is deliberately simple, and several limits follow from that.

  • Uploaded files stay public. Images, PDFs and other files uploaded to the Assets panel are served from a public address. A protected page hides the link, not the file, so a PDF of the volunteer rota is reachable by anyone who has its URL. Put sensitive documents behind a service that enforces access, not in the Assets panel.

  • There is one shared secret. Changing the password locks everyone out until they receive the new one. Removing one person means changing the password for all.

  • There is no rate limiting or lockout that you control. Use a long passphrase rather than a word.

  • Protected content is not a security boundary for secrets. Do not place personal data, API keys or unpublished commercial information on a page protected only by a shared password.

  • Search and indexing. Password-protected content is left out of Webflow’s site search by default, and search engines cannot read a page that is behind the password form. Do not rely on this for confidentiality either.

  • Staging sites differ. The webflow.io staging domain has its own settings, so protect or noindex it separately if it shows unreleased material; see Domains, Hosting and Publishing Options.

When the real requirement is "only these named people may see this", use an authentication layer outside Webflow, as described in the last section.

Site search

Webflow’s site search indexes the published site and returns results from a search results page. It is added as a component and needs no external service.

Adding search

  1. In the Designer, open the Add panel and drag the Search component into the navbar or a page.

  2. The first time search is added, Webflow creates the Search results page in the utility pages of the Pages panel. Once it exists it stays, and you design it like any page.

  3. Style the search form and the result items with classes. The result items are a template that Webflow repeats for each match.

  4. Publish the site. Webflow builds the index from the published content, so a newly published change may take some time to appear in results.

By default everything on the site is indexed except components, randomized Collection lists, utility pages and password-protected content. A visitor who submits the form is sent to the search results page with the query in the address, which means a result page can be linked and bookmarked.

What is indexed and how it is refreshed

The index contains the text of static pages and of CMS items that have a published template page. Index refresh is a hosted job, and the rate at which you may ask for a manual reindex depends on the tier: the Help Center describes one manual reindex every 24 hours on the entry hosting tiers that include search, and more frequent reindexing on higher tiers. Because of this, a change made a minute ago may not be searchable yet, and an editor who expects instant results should be told so.

Three consequences are worth knowing for Fernbrook Gardens:

  • A plant item appears in search only when its collection has a published template page, as described in Collection Template Pages.

  • Search ranks content by relevance as computed by Webflow. There is no setting for weighting a field or for synonyms, so a visitor who types the Latin name finds the plant only if that text is on the page.

  • The number of results returned for one query is limited. Community reports give different numbers over the years, so do not design a page that assumes every match is listed; give visitors filters or collection lists as a second path, as in Collection Lists.

Excluding content from search

Not everything should be searchable. Webflow offers exclusion at several levels.

  • A page. In the page settings, switch on the option that excludes the page from search. This suits the thank-you page of a form, the volunteer registration page and draft landing pages.

  • A collection. In the collection settings, exclude the collection so that none of its items is indexed. The Staff collection of Fernbrook is a good candidate if staff profiles are shown only through a team page.

  • An element. An element can be marked so that its text is skipped, which keeps repeated boilerplate such as the footer address out of the result snippets.

Exclusion affects Webflow’s internal search only. It does not hide the page from Google and it does not remove the page from the sitemap. A page that must stay out of search engines needs a noindex robots setting, covered in SEO and AEO. The search results page itself is usually excluded from the index and, because it is a thin page, marked noindex, so that results lists do not appear in a search engine.

Webflow has no view of what is indexed, so when an excluded page still shows in results or an included one is missing, wait for the next index refresh and, if the difference persists, contact Webflow support.

Excluding a page from code

The Designer API can set the same page option from a Designer Extension. The method excludes the current page from Webflow’s internal site search and needs the permission to manage page settings. A Plant Label Kit style extension could use it to hide printable label pages from search:

// Get the page currently open in the Designer
const currentPage = await webflow.getCurrentPage()

// Exclude it from Webflow's internal site search
await currentPage.excludeFromSearch(true)

Source: Designer API: exclude page from search. The extension model is explained in Designer Extensions and the Designer API.

When Webflow search is not enough

The hosted search suits a site of tens or a few hundreds of pages. It is the wrong tool when you need faceted filtering, typo tolerance, per-field weighting, analytics of queries or search over content that is not on the site. Typical alternatives are a dedicated search service fed from the CMS, using the Data API described in Data API: CMS, or a headless front end that owns search, as in Content Delivery API and Headless. Webflow’s own filtering of Collection lists, described on the collection lists page, covers many "search by attribute" cases without any search index at all.

Pitfalls

  • Search works on the published site only. Content in staging, drafts and unpublished items is not searchable.

  • Excluding a page from search does not remove it from the sitemap or from Google.

  • A site with many near-identical CMS pages returns near-identical results; make titles distinctive.

  • Search needs hosting, so it does not work in an exported copy of the site. Code export drops it, along with the CMS, ecommerce and forms.

  • Components are not indexed on their own, so text that exists only inside a component instance is indexed as part of the page that uses it, not as a separate hit.

Members-only content after the User Accounts sunset

Webflow once offered a native User Accounts (Memberships) feature that gave visitors individual logins and gated pages by access group. Webflow announced its end and the feature was shut down on 2026-01-29. From that date the feature is disabled on all sites, the User Accounts APIs and the user_account_* webhooks have been removed from every API version, and new sites could no longer enable it from 2025-01-31. The sister feature Logic ended on 2025-06-27. The facts and the migration guidance are in the Help Center articles listed below, and the removal of the endpoints is in the developer changelog.

This changes how a members-only area is designed. A shared password protects a page, but it cannot give each volunteer a login, and Webflow can no longer do that itself. The choices are:

Need Approach Trade-off

A few trusted people, rarely changing

Folder password on the volunteers folder

One shared secret; no individual revocation. Free of extra services.

Individual logins on a Webflow site

A third-party membership service added with custom code. Webflow’s update named Outseta and Memberstack as recommended partners, and agencies can migrate to other tools.

Extra cost and a script on the page. Review the vendor’s data handling.

Fully custom accounts, roles and data

An application of your own, for example a Webflow Cloud app or a separate service, with the Webflow site linking to it

More work, full control. See Webflow Cloud and Hybrid Apps.

Gated downloads or sensitive documents

A storage or document service that enforces access itself

The Assets panel is public, so it is never the place for them.

For Fernbrook Gardens the decision is proportionate. The volunteer pages contain a rota and a handbook, nothing confidential, so a folder password is enough, and the garden accepts that a departing volunteer means a new passphrase. If the garden later wanted a donor portal with personal records, it would use a membership service or its own application rather than a shared password.

Any code that consumed the removed User Accounts endpoints or webhooks stopped working on 2026-01-29 and has to be deleted or replaced. See Webhooks for the events that still exist and Where Older Books and Tutorials Are Outdated for tutorials that still describe the old feature.

Checklist

Use this list before publishing a site that uses either feature.

  • The site has a Site plan with hosting, and the plan tier supports the needed reindex rate.

  • Every protected area is a folder, and its password is stored in the team’s password manager, not in a page.

  • The password page is styled and uses neutral wording.

  • No sensitive file is uploaded to the Assets panel.

  • The Search results page is styled, and it is excluded from the index and marked noindex.

  • Forms' thank-you pages, staff profiles and other low-value pages are excluded from search.

  • Nobody on the team still plans to use User Accounts or its APIs.

Where to go next

References