Overview 1. Why We Scan 2. XPath Basics 3. Finding XPath 4. XPath Patterns 5. Configuring 6. Troubleshooting 7. Cheat Sheet 8. Further Reading

Version: 1.0

Last Updated: May 14, 2026

Setting Up a Scan for Login Pages using XPath

What This Guide Covers

By the end of this guide you will be able to:

•Recognize when a TrustArc cookie scan needs to log in to a website to capture cookies that only fire after authentication.

•Read and write the most common XPath expressions used to identify login form fields.

•Configure the Scan Behind Login feature in CCM Pro or CCM Advanced end-to-end.

•Diagnose the most common failures — hidden forms, dynamic elements, multi-step logins — and apply the right fix.

1. Why We Scan Behind Login

A standard TrustArc cookie scan crawls only the pages a logged-out visitor can reach. That covers the marketing site, the blog, and any public landing pages — but it misses everything that lives behind authentication. Customer portals, member dashboards, billing screens, and admin consoles often load a different set of cookies and trackers than the public site. Without logging in, those trackers never appear on the consent banner.

Scan Behind Login solves this. You give the scanner a set of credentials and the instructions it needs to drive the login form, and it then crawls the authenticated portion of the site exactly as a real user would.

When you need this feature

•A client asks why "We don't see the cookies our customers actually load."

•The site has a self-service portal, paid SaaS area, or partner workspace.

•A regulated workflow (insurance quoting, banking, healthcare member portal) lives behind a login gate.

1.1 What you need before you start

Item	Why it matters
A test account on the target site	Never use a customer's real production credentials. Ask the client to provision a dedicated scan-only account.
The exact login URL	This is the URL the scanner navigates to first. Often it is not the homepage — for example, https://my.example.com/login.
The names of the Username and Password fields	You will identify these with XPath. Get them from your browser DevTools (see Section 3).
A logout pattern to exclude	If the scanner ever clicks a logout link, the session ends and the rest of the crawl fails. Common patterns: logout, sign-out, /logoff.
The static IP TrustArc scans from (if needed)	If the client allowedlists IPs, request the static scan IP from your TAM and have it added before testing.

2. XPath in Plain English

XPath stands for XML Path Language. The name sounds intimidating, but the idea is simple: XPath is a way of writing an "address" for any element on a webpage, in the same way a file path describes the location of a file on your computer.

TrustArc uses XPath because login forms are web pages, and web pages are HTML. HTML is a tree of elements — a body that contains a header that contains a navigation bar that contains links — and XPath is the language we use to point at one specific element in that tree.

2.1 The smallest XPath you need to understand

Almost every XPath you will ever write for Scan Behind Login follows this pattern:

//tagName[@attribute="value"]

Read it left to right: "find any element of this type, anywhere on the page, where this attribute has this value."

Three concrete examples make the pattern click:

XPath	In English	Matches
`//input[@name="userName"]`	Find any input element whose name attribute is "userName"	The username text box on most login forms
`//input[@type="password"]`	Find any input whose type attribute is "password"	The Password field — every browser hides the text by default
`//button[@id="login"]`	Find any button whose id is "login"	Log In button

2.2 The four pieces of syntax that do 90% of the work

Symbol	Meaning	Example
`//`	Search anywhere on the page	`//input` finds every input on the page
`@`	Refers to an attribute	`@name`, `@id`, `@class`, `@type`
`[ ]`	Filter — keep only matches that satisfy the condition inside	`//input[@name="email"]`
`text()`	The visible text inside the element	`//button[text()="Submit"]`

Memorize this one rule
If you can find a unique ID or name attribute on the field, use it. ids and names are stable, short, and rarely break when the site's designer rearranges the page. Reach for class only when nothing better is available, and avoid full paths like /html/body/div[2]/form/input[1] — they break the moment a developer adds a wrapper div.

3. Finding the Right XPath in Your Browser

You do not have to write XPath from scratch. Chrome, Edge, and Firefox can all show you the structure of any web page and help you copy a working selector. The workflow below takes about thirty seconds once you have done it twice.

3.1 The thirty-second workflow

Open the login page in Chrome.

Press F12 (or right-click anywhere and choose Inspect). DevTools opens.

Click the small arrow icon in the top-left of DevTools (or press Ctrl+Shift+C), then click the Username field on the page.

DevTools highlights the matching HTML — usually an <input> tag. Read its name or id attribute. That is the value you put inside the brackets of your XPath.

To verify, press Ctrl+F inside the Elements panel and paste your XPath (for example '//input[@name="userName"]'). DevTools tells you how many elements match. You want exactly one.

Tip — Copy Full XPath as a fallback
Right-click any element in the Elements tab and choose Copy > Copy Full XPath. This gives you an absolute path like /html/body/div[2]/form/input[1]. It works, but it is brittle — use it only when no clean attribute is available, and rewrite it with attributes as soon as you can.

3.2 Reading what you find

Most login pages give you one of three patterns. Recognise them and you have your XPath.

What you see in DevTools	What you write in TrustArc	Notes
`<input name="userName" />`	`//input[@name="userName"]`	Cleanest case. Use it.
`<input id="email" />`	`//input[@id="email"]`	Equally good. IDs are usually unique.
`<input type="password" class="pw-field" />`	`//input[@type="password"]`	There is usually only one Password field on a page, so type="password" is reliable.

4. The XPath Patterns You Will Actually Use

These are the patterns that cover the vast majority of login forms you will encounter in the wild. Treat this as your cheat sheet.

Pattern 1 — Username field by name

//input[@name="userName"]

Default choice for the Username, Email, or Login field. Inspect the element and copy the value of the name attribute into the brackets.

Pattern 2 — Password field by type

//input[@type="password"]

Browsers render only one password input per form, so this almost always returns exactly one element. Use it whenever the Password field has no clean name or ID.

Pattern 3 — A button by its visible text

//button[text()="Sign In"]

Use this when the Submit button has no useful ID. Match the text exactly — Sign In is not the same as sign in or Sign in. If the casing or spacing varies, use contains() instead (next pattern).

Pattern 4 — Partial text match with contains()

//button[contains(text(),"Log")]

Matches "Log In", "Log in", "Login", or "Log On" — useful when you do not want to be brittle about exact casing.

Pattern 5 — The first or nth link

//a[1]

Targets the first <a> (link) element on the page. The legacy TrustArc example uses //a[1] to click the Submit link on a simple form. If the submit control is a real <button>, prefer Pattern 3 or Pattern 6 instead.

Pattern 6 — Submit button by type

//button[@type="submit"]
//input[@type="submit"]

Some forms have a button with no text, no id, and no useful class — but a type="submit" attribute is almost always present. Either of the two lines above will find it.

Pattern 7 — Attribute starts with

//input[starts-with(@name, "user")]

Quick reference — every operator on one card
//tag — any element of this tag, anywhere
'@attr="value"' — exact attribute match
'contains(@attr,"v")' — substring of attribute
'starts-with(@attr,"v")' — attribute begins with
'text()="X"' — visible text equals
'contains(text(),"X")' — visible text contains
[1] [2] [last()] — position among siblings

5. Configuring Scan Behind Login in TrustArc

This section walks through the screens in CCM Pro / CCM Advanced. The numbering matches the official Scan Configuration documentation, so a trainee can follow this guide alongside the product.

5.1 Open the Scan Behind Login window

In CCM, navigate to Cookie Consent Manager > Scans and Consent > Add Scan and Consent.

On the Scan Details tab, locate the Scan Configurations panel on the right.

Click the Scan Behind Login button. A new window opens.

Click Add Login URL to start a new entry.

5.2 Choose the login type

TrustArc supports two login mechanisms. Pick the one the target site uses.

Type	When to choose it
Form Login	Standard HTML form: a username box, a password box, and a submit button on a login page. This covers about 95% of cases.
HTTP Basic Authentication	A pop-up modal that the browser itself shows (no HTML form on the page). Common on internal admin tools and some legacy systems.

5.3 Set the exclusion pattern (Form Login only)

Before you do anything else, fill in the Exclusion Pattern field. The scanner crawls every link it finds, and if it ever clicks a logout link, the session dies and the rest of the scan returns logged-out cookies. The fix is one line:

logout

That single word tells the scanner: "if a URL contains the substring 'logout', do not follow it." Add other patterns like sign-out or /logoff separated by commas if the site uses different logout URLs.

5.4 Write the XPath Actions script

This is where the XPath knowledge from Sections 2 to 4 pays off. The script is plain text — three or four lines that tell the scanner where to go, what to type, and what to click.

The structure is always the same:

<login URL on its own line>
xpath(<XPath to username field>) = '<username>'
xpath(<XPath to password field>) = '<password>'
xpath(<XPath to submit element>).click()

A working example for the TrustArc internal portal looks like this:

https://my.truste.com/login
xpath(//input[@name="userName"]) = 'phchang@truste.com'
xpath(//input[@name="password"]) = 'password'
xpath(//a[1]).click()

Read it line by line:

•Line 1 — the URL the scanner navigates to. Always the first line, never wrapped in xpath().

•Line 2 — type the username into whatever element matches '//input[@name="userName"]'.

•Line 3 — type the password into whatever element matches //input[@name="password"].

•Line 4 — click whatever element matches //a[1] (in this case, the submit link).

5.5 Test before you save

Click the Test Form button below the script editor.

TrustArc opens the URL, runs each line, and tells you whether each XPath matched and whether the login succeeded.

If the test passes, the form is added to the Fetched Forms list. Only forms that pass appear there — failed tests are silently dropped, so check that your form actually shows up.

Click Add to save the configuration, then Done to close the Scan Behind Login window.

Important — credentials in the script
Anyone with read access to the scan configuration can see the username and password in plain text. Always use a dedicated test account that has read-only access to the customer portal, not a real admin or shared account. Rotate the password after the scan is decommissioned.

6. Troubleshooting the Scenarios You Will Hit

The standard XPath script works for simple forms. Real client sites are rarely simple. The four scenarios below cover almost every failure mode trainers encounter in the field.

6.1 The login form is hidden until a button is clicked

Many modern sites hide the login form behind a Sign In button in the top-right corner. The Username and Password fields exist in the HTML but are invisible — and Test Form fails because the scanner cannot interact with hidden elements.

The fix is to click the button first, then fill in the form. Add the click as the first action after the URL:

https://app.example.com/
xpath(//button[contains(text(),"Sign In")]).click()
xpath(//input[@name="email"]) = 'scan-bot@trustarc.com'
xpath(//input[@name="password"]) = 'TestPassw0rd!'
xpath(//button[@type="submit"]).click()

6.2 The form is in an iframe or has a complicated XPath

Some sites embed the login form inside an iframe, or wrap fields in many layers of styled divs. DevTools gives you the path, but it is long and brittle.

Use the Copy Full XPath workflow described in Section 3.1. Then, before you ship it, try to rewrite it with attributes — replace something like:

/html/body/div[2]/div[1]/form/div/div[3]/input[1]

with something like:

//form//input[@name="email"]

The shorter form survives a developer adding a wrapper div. The full path does not.

6.3 Test Form reports "no element found"

This is almost always one of three causes:

•A typo in the attribute value — uppercase versus lowercase matters. userName and username are different.

•The field is loaded by JavaScript after the page renders. Add a click on whatever button reveals it (see 6.1).

•You are looking at a cached or stale page in DevTools. Hard-refresh (Ctrl+Shift+R) and re-inspect.

6.4 Login succeeds but the crawl returns logged-out pages

The scanner logged in, then clicked a logout link before it had time to crawl much. Go back to the Exclusion Pattern field (Section 5.3) and add every logout URL the site uses. Common patterns to add:

logout, sign-out, /logoff, /signout, /exit

6.5 Two-factor authentication

Scan Behind Login cannot complete a 2FA challenge — the second factor is, by design, something only a human can supply. Two workarounds work in practice:

•Ask the client to disable 2FA on the dedicated scan account, or

•Ask the client to whitelist the TrustArc scan IP so 2FA is bypassed for that source. Get the static IP from your TAM.

7. Checklist and Cheat Sheet

7.1 Pre-flight checklist

Tick each item before you start configuring. A scan you have to redo because of a missing item is a scan that delays go-live by a week.

•Dedicated test account on the target site (not a shared or production account).

•Login URL confirmed in a browser.

•Username and Password fields XPaths identified in DevTools.

•Submit button (or link) XPath identified.

•Logout URL pattern identified for the Exclusion Pattern field.

•TrustArc scan IP allowedlisted by the client (if their security team requires it).

•2FA disabled on the test account or bypassed by IP whitelisting.

7.2 XPath cheat sheet

What you want	XPath	Notes
Username field	`//input[@name="userName"]`	Replace userName with the actual name attribute.
Email field	`//input[@type="email"]`	Works on most modern sites.
Password field	`//input[@type="password"]`	Almost always unique on a login page.
Submit button (text)	`//button[text()="Sign In"]`	Match the visible label exactly.
Submit button (type)	`//button[@type="submit"]`	Use when the button has no useful text or id.
Submit link	`//a[1]`	Last resort — first link on the page.
Show login form	`//button[contains(text(),"Log In")]`	For forms that are hidden by default.
Dynamic field names	`//input[starts-with(@name,"user")]`	When name="user_a47f2" changes per page load.

7.3 Script template — copy, paste, edit three lines

https://login.example.com/
xpath(//input[@name="USERNAME_FIELD"]) = 'YOUR_TEST_EMAIL'
xpath(//input[@type="password"]) = 'YOUR_TEST_PASSWORD'
xpath(//button[@type="submit"]).click()

Replace the four ALL-CAPS values, paste into the Xpath Actions field, click Test Form, and you are done.

8. Further Reading

If you want to go deeper than the patterns covered in this training guide, the following references are reliable and frequently updated.

•W3Schools — XPath Syntax: w3schools.com/xml/xpath_syntax.asp

•BrowserStack — XPath Locators Cheat Sheet: browserstack.com/guide/xpath-locators-cheat-sheet

•Tutorialspoint — XPath Tutorial: tutorialspoint.com/xpath/index.htm

•Playwright Locators (for advanced cases): playwright.dev/docs/locators

TrustArc · Setting Up a Scan for Login Pages using XPath · trustarc.com

Version: 1.0

Last Updated: May 14, 2026

Setting Up a Scan for Login Pages using XPath

What This Guide Covers

By the end of this guide you will be able to:

Recognize when a TrustArc cookie scan needs to log in to a website to capture cookies that only fire after authentication.
Read and write the most common XPath expressions used to identify login form fields.
Configure the Scan Behind Login feature in CCM Pro or CCM Advanced end-to-end.
Diagnose the most common failures — hidden forms, dynamic elements, multi-step logins — and apply the right fix.

1. Why we scan behind login

When you need this feature

A client asks why "We don't see the cookies our customers actually load."
The site has a self-service portal, paid SaaS area, or partner workspace.
A regulated workflow (insurance quoting, banking, healthcare member portal) lives behind a login gate.

1.1 What you need before you start

Item	Why it matters
A test account on the target site	Never use a customer’s real production credentials. Ask the client to provision a dedicated scan-only account.
The exact login URL	This is the URL the scanner navigates to first. Often it is not the homepage — for example, https://my.example.com/login.
The names of the Username and Password fields	You will identify these with XPath. Get them from your browser DevTools (see Section 3).
A logout pattern to exclude	If the scanner ever clicks a logout link, the session ends and the rest of the crawl fails. Common patterns: logout, sign-out, /logoff.
The static IP TrustArc scans from (if needed)	If the client allowedlists IPs, request the static scan IP from your TAM and have it added before testing.

2. XPath in plain English

2.1 The smallest XPath you need to understand

Almost every XPath you will ever write for Scan Behind Login follows this pattern:

//tagName[@attribute="value"]

Read it left to right: "find any element of this type, anywhere on the page, where this attribute has this value."

Three concrete examples make the pattern click:

XPath	In English	Matches
`//input[@name="userName"]`	Find any input element whose name attribute is "userName"	The username text box on most login forms
`//input[@type="password"]`	Find any input whose type attribute is "password"	The Password field — every browser hides the text by default
`//button[@id="login"]`	Find any button whose id is "login"	The Log In button

2.2 The four pieces of syntax that do 90% of the work

Symbol	Meaning	Example
`//`	Search anywhere on the page	`//input` finds every input on the page
`@`	Refers to an attribute	`@name`, `@id`, `@class`, `@type`
`[ ]`	Filter — keep only matches that satisfy the condition inside	`//input[@name="email"]`
`text()`	The visible text inside the element	`//button[text()="Submit"]`

Memorize this one rule

If you can find a unique ID or name attribute on the field, use it. ids and names are stable, short, and rarely break when the site's designer rearranges the page. Reach for class only when nothing better is available, and avoid full paths like /html/body/div[2]/form/input[1] — they break the moment a developer adds a wrapper div.

3. Finding the right XPath in your browser

3.1 The thirty-second workflow

Open the login page in Chrome.
Press F12 (or right-click anywhere and choose Inspect).
DevTools opens.
Click the small arrow icon in the top-left of DevTools (or press Ctrl+Shift+C), then click the Username field on the page.
DevTools highlights the matching HTML — usually an <input> tag. Read its name or id attribute. That is the value you put inside the brackets of your XPath.
To verify, press Ctrl+F inside the Elements panel and paste your XPath (for example //input[@name="userName"]). DevTools tells you how many elements match. You want exactly one.

Tip — Copy Full XPath as a fallback

Right-click any element in the Elements tab and choose Copy > Copy Full XPath. This gives you an absolute path like /html/body/div[2]/form/input[1]. It works, but it is brittle — use it only when no clean attribute is available, and rewrite it with attributes as soon as you can.

3.2 Reading what you find

Most login pages give you one of three patterns. Recognise them and you have your XPath.

What you see in DevTools	What you write in TrustArc	Notes
`<input name="userName" />`	`//input[@name="userName"]`	Cleanest case. Use it.
`<input id="email" />`	`//input[@id="email"]`	Equally good. IDs are usually unique.
`<input type="password" class="pw-field" />`	`//input[@type="password"]`	There is usually only one Password field on a page, so type="password" is reliable.

4. The XPath patterns you will actually use

These are the patterns that cover the vast majority of login forms you will encounter in the wild. Treat this as your cheat sheet.

Pattern 1 — Username field by name

//input[@name="userName"]

Default choice for the Username, Email, or Login field. Inspect the element and copy the value of the name attribute into the brackets.

Pattern 2 — Password field by type

//input[@type="password"]

Browsers render only one password input per form, so this almost always returns exactly one element. Use it whenever the Password field has no clean name or ID.

Pattern 3 — A button by its visible text

//button[text()="Sign In"]

Pattern 4 — Partial text match with contains()

//button[contains(text(),"Log")]

Matches "Log In", "Log in", "Login", or "Log On" — useful when you do not want to be brittle about exact casing.

Pattern 5 — The first or nth link

//a[1]

Pattern 6 — Submit button by type

//button[@type="submit"]
//input[@type="submit"]

Some forms have a button with no text, no id, and no useful class — but a type="submit" attribute is almost always present. Either of the two lines above will find it.

Pattern 7 — Attribute starts with

//input[starts-with(@name, "user")]

Quick reference — every operator on one card

//tag any element of this tag, anywhere

@attr="value" exact attribute match

contains(@attr,"v") substring of attribute

starts-with(@attr,"v") attribute begins with

text()="X" visible text equals

contains(text(),"X") visible text contains

[1] [2] [last()] position among siblings

5. Configuring Scan Behind Login in TrustArc

This section walks through the screens in CCM Pro / CCM Advanced. The numbering matches the official Scan Configuration documentation, so a trainee can follow this guide alongside the product.

5.1 Open the Scan Behind Login window

In CCM, navigate to Cookie Consent Manager > Scans and Consent > Add Scan and Consent.
On the Scan Details tab, locate the Scan Configurations panel on the right.
Click the Scan Behind Login button. A new window opens.
Click Add Login URL to start a new entry.

5.2 Choose the login type