Site Authentication

Introduction

Use this guide if your site needs a password or login before anyone can see it. Common examples: “my site is password protected,” “my staging site has a login,” “I have a members-only area,” or “the scan only shows my login page.” AAArdvark can sign in to your site first so it scans the real content behind the password.

When adding a new site to your AAArdvark Workspace, you might need to configure authentication settings to access protected pages. Setting this up takes two steps. The second one is easy to miss, and without it your scans still run signed out:

• Save your site’s login credentials using one of the authentication methods below.
• Tell AAArdvark which pages to log in for by setting those pages to “Log in before scanning.”

And, don’t worry, you can always update these settings later if needed.

To get started, go to your dashboard and click Add a New Site at the top of the page.

Setting up Site Authentication

AAArdvark allows you to log in before scanning, making it possible to test restricted or members-only content.

You set up the login once for the whole site, under Login & HTTP Authentication in your site’s settings. Then you choose which pages use it, one at a time or many at once.

Authentication Methods

AAArdvark offers four authentication methods: HTTP Basic, Login Form, Password Protected, and Custom Header. Pick the one that matches what you see when you open your site in a private browser window:

• A browser pop-up asks for a username and password before anything loads: use HTTP Basic.
• A login page on your site asks for a username (or email) and password: use Login Form.
• A page on your site asks for a password only, with no username: use Password Protected.
• Your developers let requests in when they carry a special header or token: use Custom Header.

To choose one, open your site’s settings, expand Login & HTTP Authentication, and pick an option from the Authentication Type dropdown. The fields for that method appear below it. If you’re adding a new site, choose Customize Site Settings first; the Login & HTTP Authentication section only shows there.

When you save, AAArdvark tests the login right away (the one exception is Sign in during each scan, explained below). If the test fails, you’ll see “Could not authenticate with the settings provided.” and nothing is saved until you fix the details.

HTTP Basic:

This method is often used for development and staging sites that need a login for privacy. Your browser shows its own pop-up asking for a username and password before the site loads. It isn’t a page on your site, so there’s no logo or styling, just the browser’s sign-in box.

You’ll enter:

• Username: the username from that pop-up.
• Password: the password from that pop-up.

When you save, AAArdvark loads your site’s base URL with these credentials. If your site doesn’t return the page, you’ll see “Could not authenticate with the settings provided.” Double-check the username and password by signing in through the pop-up in a private browser window.

If AAArdvark detects this kind of login when you add your site, you’ll see a “This site is password-protected” notice. Click Add your login credentials. AAArdvark switches to Customize Site Settings, then opens and scrolls to the Login & HTTP Authentication section so you can enter your username and password.

Don’t put the username and password in the site address itself, like https://user:[email protected]. AAArdvark refuses that address with “Remove the login from the address.” Enter the address without the login, then add the username and password under Login & HTTP Authentication with HTTP Basic selected. The Add your login credentials button on that message takes you straight there.

Login Form:

Use this method when your site has its own login page with a username (or email) and password, like a WordPress or Drupal login, a members area, or a customer portal. AAArdvark fills in the form and clicks the login button, just like a person would, then scans your pages while signed in.

You’ll enter:

• Site type: WordPress, Drupal, Pantheon Dashboard, or Other for any other standard login form.
• Username and Password: the account AAArdvark should sign in with.
• Login Page URL: the path to your login page. This is filled in for you based on the site type: /wp-login.php for WordPress, /user/login for Drupal, and /login for Pantheon Dashboard and Other. Change it if your login page is at a different address, for example a WordPress site that moved its login page to a custom URL. The page still needs the platform’s standard login form; see Custom Login Pages below.

When you save, AAArdvark signs in with these details to make sure they work, unless Sign in during each scan is turned on. See Cookie Authentication with a Login Form below for the full setup, including the extra fields for Other and the Sign in during each scan option.

Password Protected:

Use this method when your site asks only for a password, with no username. This is common on sites that hide everything behind a single shared password, such as a site that isn’t launched yet or a password-protected store or page.

You’ll enter:

• Password: the password visitors type to get in.
• Login Page URL: the path to the page that shows the password box, starting with /, for example /password.
• Password Selector: a CSS selector that tells AAArdvark which field to type the password into, for example input[name="password"].
• Submit Button Selector: a CSS selector for the button that submits the password, for example button[type="submit"].

When you save, AAArdvark opens your Login Page URL, types the password into the field you named, and clicks the button. If the sign-in fails, you’ll see “Could not authenticate with the settings provided.” The most common cause is a selector that doesn’t match your form, so see Finding a CSS selector below.

Finding a CSS selector

The Password Protected method, and Login Form with Other as the site type, ask for CSS selectors. A selector is a short label that points AAArdvark to one element on your login page. To find one:

1. Open your login page in Chrome, Edge, or Firefox.
2. Right-click the password field and choose Inspect. The browser’s developer tools open with the field’s code highlighted.
3. Look at the highlighted <input>. If it has an id, such as id="pwd", your selector is #pwd. If it has a name instead, such as name="password", your selector is input[name="password"].
4. Do the same for the login button. If it has no id or name, button[type="submit"] often works.

If your form is unusual or you’re not sure which selector to use, contact support and we’ll help you find it.

Custom Header:

Select this option if your site or app lets a request through when it carries a specific header and value, such as an API token or a secret your developers set up for testing. You’ll enter:

• Header Name: the name of the header, for example Authorization.
• Header Value: the value that grants access, for example Bearer your-token. This value is visible to anyone who can edit the site in AAArdvark, so treat it like a password and use it on a test or staging site where you can. While scanning pages that log in, AAArdvark sends the header with every request those pages make, including requests to other sites they load, such as CDNs. Use a value meant only for this kind of access.
• Test URL: a path on your site that requires the header. When you save, AAArdvark requests this page with the header attached. If the page doesn’t load successfully, you’ll see “Could not authenticate with the settings provided.”

The header only works if your site is set up to accept it. If the scan still lands on your login page, check with your developers that a request carrying the header gets the real page instead of a redirect to the login. They can test it with a single command:

curl -sS -o /dev/null -w '%{http_code}\n' -H 'Your-Header-Name: your value' 'https://example.com/protected-page'

A 200 means your site accepts the header. A 302, 401 or 403 means your site isn’t accepting it yet, and the change needs to happen on your site’s side.

A successful save doesn’t prove the header works. When AAArdvark checks the Test URL, it follows redirects, so a site that sends the request to a login page that loads normally can still save without an error. Run the check above to be sure.

This is a different feature from the Custom Header in Allowlist Management, which helps you get past a firewall rather than a login. See Login Problems vs. Access Denied below.

Cookie Authentication with a Login Form

AAArdvark currently supports Cookie Authentication for WordPress, Drupal, and Pantheon Dashboard sites, plus other sites that use a standard username and password login form (choose Other as the site type). If you’d like to see support for another platform, submit a feature request.

To set up this method:

• Site Type:
  Select the platform your site is built on (WordPress, Drupal, Other, or Pantheon Dashboard), then enter your username and password.
• Username/Password:
  AAArdvark stores your credentials securely using strong encryption. For added security, we recommend creating a dedicated user account with limited permissions for accessibility scanning.
• Login Page URL:
  The path to your site’s login form. This is filled in for you and usually doesn’t need to be changed.

Custom Login Pages

If you choose Other as the site type, you can update the username, password, and submit button selectors to match your login form. They start out as input[name="email"], input[name="password"], and button[type="submit"], which match many standard login forms. If yours is different, see Finding a CSS selector above.

For WordPress, Drupal, and Pantheon Dashboard, AAArdvark uses each platform’s standard login form fields, and you can’t change them. You can still change the Login Page URL if the form is at a different address. If your login form has been customized so its fields no longer match the standard ones, choose Other as the site type instead and set the selectors yourself.

Sign in During Each Scan

With Other as the site type, you’ll also see a Sign in during each scan checkbox. By default, AAArdvark signs in once when a scan starts and reuses the cookies your site sets for every page. Some sites keep you signed in another way, as many single-page apps do, so reusing cookies isn’t enough.

If that’s your site, turn this on. AAArdvark then signs in again on every page set to log in, each time it’s scanned, including scheduled scans. Keep in mind:

• AAArdvark doesn’t test this sign-in when you save, so check your next scan’s results to confirm the pages were scanned while signed in.
• Your site’s security tools may see this as many sign-ins in a short time. Use a dedicated account without two-step verification or CAPTCHA. If sign-ins get blocked, allowlist AAArdvark in Allowlist Management or contact support about a static IP.

Set Which Pages Require Login Before Scanning

Saving your credentials tells AAArdvark how to log in. The next step tells it which pages need that login.

You choose which pages need a login and which don’t, so a site can have both public and protected pages. Flag pages one at a time, or select several and flag them all at once.

After saving your credentials for the first time with no pages flagged yet, AAArdvark will show a prompt on the dashboard: “Login credentials saved. Now choose which pages should log in before scanning.” Click Choose pages to log in on to go straight to the Pages list. Until at least one page is flagged, scans run signed out and your credentials won’t be used.

If you start a scan while credentials are saved but no pages are flagged, AAArdvark will show a “Scan without logging in?” warning. You can choose Choose pages to finish the setup, or Scan anyway to proceed for public pages.

Bulk Login Settings (Fast Path)

The Pages list also shows a persistent reminder: “Your login credentials are saved, but no pages use them yet.” It stays until at least one page is flagged, then clears automatically.

To flag multiple pages at once:

1. Open the Pages menu in your site’s sidebar.
2. Select the pages that require authentication using their checkboxes.
   
   

   

3. Click Login settings in the bulk action bar, then choose Log in before scanning.
   
   

   

   
   

You’ll see a confirmation message: “N pages will now log in before scanning.” Each flagged page also shows a 🔒 Log in before scanning badge under its URL in the Pages list, so you can tell at a glance which pages are covered.

Setting Authentication Per Page

To turn it on for an individual page:

• Open the Pages menu in your site’s sidebar.
• Find the page that sits behind your login and click the pencil (Edit) icon in the Actions column.
• In the Editing Page panel, open the Authentication Settings dropdown and choose Log in before scanning. (The default is Do not log in before scanning.) You absolutely need to have already set up the login for the site using the steps above before being able to select the option.
• Click Update.

Repeat for each protected page. If you’re adding pages manually, the New Page form has the same Authentication Settings dropdown, so you can set it as you go.

Quick check: if a public page scans fine but a members-only page comes back empty or blocked, it’s almost always a page still set to “Do not log in before scanning.”

If Your Scan Still Shows the Login Page

Work through these in order:

• Is the page set to log in? Open Pages and look for the 🔒 Log in before scanning badge under the page’s URL. Pages set to Do not log in before scanning scan signed out, even when your credentials are saved.
• Do the credentials still work? If AAArdvark can’t sign in with a Login Form or Password Protected login, the pages set to log in will show the error “Unable to authenticate with site credentials.” For HTTP Basic, a wrong username or password can show “The site rejected the authentication credentials.” or “This site requires authentication.” Try the same username and password on your site, then update them in your site’s settings.
• Using Custom Header? Make sure your site accepts the header, using the check in the Custom Header section above.
• Using Sign in during each scan? That login isn’t tested when you save, so a wrong selector or password only shows up in scan results. Check the selectors against your login form (see Finding a CSS selector), or turn the option off and save once: AAArdvark then tests the login and shows “Could not authenticate with the settings provided.” if it fails. Once it saves without that error, turn the option back on and save again.

Sites That Use Single Sign-On or Two-Factor Login

None of the four methods can get through a single sign-on (SSO) screen like Microsoft Entra ID, Okta, or Google, or a two-factor prompt like a passkey or code. AAArdvark signs in from our cloud servers with no one there to approve the prompt. You still have options:

• Use a dedicated scanning account without two-factor. If your IT team can create an account that is excluded from two-factor login, try Login Form with Other as the site type. Some SSO setups also limit sign-ins to certain networks or devices. Because scans sign in from our cloud servers, not your office network, that account may need an exception to those rules too.
• Let AAArdvark skip the login on your server. If you control the server, you can set it up to let AAArdvark’s requests through without a login, either by its allowlist header or by a static IP address. See the Allowlist guide for the header and IP details.
• Ask us to set up a custom login. For sign-in flows the built-in methods can’t handle, our team can configure a custom login sequence for your site. Contact support and we’ll work through it with you.

Using Visual Mode? Visual Mode doesn’t use these settings. To browse and test pages behind a login there, follow the steps in Visual Mode: Pages with Authentication. Automated scans still need one of the options above.

Login Problems vs. Access Denied

These two problems look alike but have different fixes:

• Your scan shows a login page instead of your content. AAArdvark reached your site but wasn’t signed in. Make sure your login credentials are saved and the page is set to Log in before scanning. If both are done and the scan still shows the login page, work through If Your Scan Still Shows the Login Page above.
• You see an “Access Denied” error when adding your site or changing its URL. Your site refused the request. Most often a firewall or security tool, such as Cloudflare, blocked AAArdvark. Follow the Access Denied allowlist guide.

If a page scan fails, the page shows its own error in the Pages list:

• “This site requires authentication.” The page needs a login. Save your credentials and set the page to log in before scanning, as shown in this guide.
• “The site rejected the authentication credentials.” AAArdvark tried to sign in, but the username or password was wrong. Check them in your site’s settings.
• “This site is blocking our scanner.” This is a firewall or security block, not a login. Follow the Access Denied allowlist guide.

AAArdvark has two features called “Custom Header.” The one in Allowlist Management is a header AAArdvark sends with every request so your firewall can let it in. The Custom Header login method in this guide sends a header and value you choose, only on pages set to log in before scanning, so your site treats the request as signed in.

---

---

Related Guides

• 

  Changing a Site’s URL

• 

  Trend Report

• 

  Understanding Your Accessibility Score

• 

  Getting Started

---