Scanning and Scan Results Best Practices and Troubleshooting

Provide a clear scan scope

Provide a sitemap whenever possible. A sitemap improves scan efficiency and helps the scanner discover relevant pages more reliably.

If you know which pages or page types are most important, target those pages or paths directly instead of relying entirely on broad site discovery.

Keep the scan focused

In most cases, it is best to keep the scan focused on the most important pages rather than trying to crawl every possible page on a large site.

As a practical best practice, try to keep scans around 1000 pages when possible, even though the technical limit may be higher.

Use the correct domain strategy

The URL you enter affects scope. Scanning a root domain generally covers the broader domain space, while scanning a specific subdomain such as a www host limits the crawl to that subdomain and its paths. Be intentional about whether you want root-domain coverage or a subdomain-specific scan.

Verify URLs and target pages

Verify that the main URL, sitemap URLs, target pages, and login URLs are correctly formatted and use the intended protocol. Incorrect URL formatting can prevent the scanner from reaching content and can lead to low-page or zero-page results.

Address security controls early

If your site uses a firewall, Web Application Firewall, bot protection, regional restrictions, security plugins, or hosting-layer filtering, make sure the OneTrust scanner can reach your site. When needed, safelist the OneTrust scanner IP addresses and user agents before running production scans.

Configure authentication only when needed

If important pages require login, configure a supported authentication approach and provide complete login details. Do not add only a login page URL without the credentials and settings needed to complete the flow.

Test small when troubleshooting

If a scan appears stuck or unhealthy, stop it and retry with a very small page limit first. Once the limited test succeeds, rerun the broader scan.

For more information, see Website Scanning Best Practices.

Overview

The Overview section summarizes what was found in the selected scan. Use it first to understand the size and general shape of the result before drilling into details.

Services

The Services section broadens the analysis beyond cookies to vendor and service activity. This can provide useful context when reviewing tracking technologies across a site.

Cookies

The Cookies section is often the most important place to begin. Review cookie counts, categories, and any Added or Removed values compared to the previous scan.

If a cookie appears as Unknown, it means it has not yet been categorized. Unknown cookies do not appear in the cookie list or preference center until they are categorized.

Forms

The Forms section shows detected form fields and whether they appear to collect personal information. This is primarily informational and can help explain what the scanner saw on a given page.

Pages

The Pages section is one of the most useful troubleshooting tools. It shows which page URLs were actually scanned, the number of cookies found on each page, and whether the page contains a form, policy content, or a login requirement.

If a page does not appear here, the scanner likely did not reach it.

Storage

The Storage section audits local storage objects. It should not be interpreted as a direct map between cookies and storage items.

Initiators

The Initiators section helps explain tag relationships and piggy-back behavior. Use it when you need to understand which tag triggered other tags or where data flow originates.

For more information, see Viewing Scan Results.

• Pending means the scan has been submitted and is waiting to run.

• Queued means the scan is waiting to begin once other scans have completed.

• Scanning means the crawler is actively traversing the site and collecting data.

• Completed means results are ready for review.

• Failed Login means authentication did not complete successfully.

• Scan Error means the scan did not complete successfully and needs review.

• Canceled means a user canceled the scan.

For more information, see Scanning a Website.

Scanning behind authentication is supported for certain login approaches, but not every login flow can be scanned successfully.

Simple, well-structured login configurations are more likely to succeed. Complex login scenarios may fail, especially if they depend on unsupported patterns such as reCAPTCHA, certificate-based authentication, or other advanced controls.

If a full behind-login crawl is not possible, it may still be acceptable to scan the majority of relevant pages and supplement remaining coverage through targeted review or manual categorization.

For more information, see Scanning Behind Authentication.

Even when scan results look correct, implementation behavior can still be affected if the scanned domain and the implemented script domain do not align.

This can cause consent not to persist correctly and can cause the banner to reappear unexpectedly. When reviewing scan or implementation behavior, confirm that the scan target, published script, and runtime domain strategy are aligned.

For more information, see Scanning a Website and Publishing and Implementing Cookie Consent Scripts.

1. Confirm the scan status and timestamp.

2. Confirm the actual scan scope, including domain strategy, sitemap, target pages, page limit, region, and login settings.

3. Review the Pages section of the Scan results screen to confirm whether the scanner reached the page in question.

4. Review Cookies and Tags sections of the Scan results screen for added or removed technologies since the previous scan.

5. Determine whether the result is consistent with expected scanner behavior, page reachability, login conditions, browser conditions, user-action triggers, or geolocation differences.

6. If the issue relates to disclosure output, compare scan results against categorizations, manually added records, and script publication state before assuming there is a product defect.

Before opening a support case, collect the following details.

• Website or app name.

• Scan date and timestamp.

• Current scan status.

• Whether the issue is website or mobile related.

• The exact page, path, or app area where the expected result was not seen.

• Whether the content requires login.

• Whether scanner IPs and user agents are safelisted.

• Whether a sitemap and target pages were configured.

• Whether the script was republished after the latest relevant scan or categorization update.

• Screenshots or exports from the relevant scan results areas.

• Scan results are shaped by scope, accessibility, authentication, security controls, browser behavior, geolocation, and trigger conditions.

• The Pages section of the Scan results screen is often the fastest way to explain why a customer believes something was missed.

• Differences between scan results, categorizations, and the Cookie List are often expected and should be analyzed before they are treated as product issues.

• For mobile apps, start with SDKs, permissions, data types, and Privacy Manifest alignment before investigating individual findings in more detail.