Why this exists
A password screen is not an error. It is a normal web page that loads successfully, with a heading, a box, and a button. That matters more than it sounds. Without access configured, an agent visits your site, gets a perfectly successful page load, and reads the password screen. It then reports on that screen as though it were your website. The run completes, findings appear, and nothing in the output says the agent never actually saw your site. Setting up Site Access removes that. It also means that when access is wrong, the run stops and tells you, instead of quietly describing the wrong page.Which option do I need?
Almost always answerable from one question: who is doing the blocking? Open your site in a private browser window and look at what answers.The redirect is the tell. If the browser ends up on a different domain than the one you asked for, that is an identity provider, and single sign on is the only option that works.
Ask about the platform first
If your site sits behind Cloudflare Access or on a Vercel deployment, you can use a bypass token even if there is also single sign on behind it. Two minutes in a hosting dashboard beats twenty minutes with an identity administrator, so it is worth checking before assuming you need the harder option.The five options
Bypass token
Cloudflare Access or Vercel issues a secret intended for automation. No sign in, no session, and the only option that also works in page previews.
Single sign on
For sites that redirect to Okta, Microsoft Entra, or any SAML provider. Needs a dedicated service account exempt from multi-factor.
Okta, step by step
The verified walkthrough: the application, the service account, the group, and the three policies that have to line up.
Passwords and login forms
Shared site passwords (Webflow, Shopify, Squarespace, Framer), browser sign in prompts, and login forms on your own site.
When something is wrong
What each message means, why a sign in that used to work stops, and what Superflow stores.