Consent scans
Updated
A consent scan shows what your pages do before a visitor chooses, after Reject all and after Accept all, and what your consent platform tells the tags that read it. This page explains what the scan does, which consent platforms it can answer, what it says when it could not complete a step, how comparisons treat that, and what the Consent signals card shows. The lists a consent scan produces are described in Inventory, and the third-party list that findings can be checked against in Approved third parties.
What a consent scan does
For each page it selects (at most 100 per scan, 10 by default), Page Lookout opens the page in three situations and writes down what it sees:
- Before a choice. Nobody has touched the cookie banner.
- After Reject all. The scan finds the banner, presses its reject control and waits until the platform has stored the choice.
- After Accept all. The same with the accept control.
In each situation it records which cookies exist, which third-party domains the page contacted and which local and session storage keys exist, and it reads the banner’s own state. It records names, never values. The findings compare the situations: an optional cookie that is there before any choice, a tracker still contacted after Reject all, a Reject all that changed nothing.
A choice made on one page, Reject all for example, is reused on the next page of the same scan, and the scan checks that the platform still holds it before it relies on it.
Which consent platforms it can answer
Page Lookout knows five kinds of consent set-up, from the most it can do to the least.
- OneTrust, Cookiebot, Usercentrics, Didomi, CookieYes, InMobi Choice and TrustArc. These seven are written and tested one by one. The scan finds the banner, presses Reject all and Accept all, and confirms from the platform’s own stored choice, usually its cookie, that the choice took effect.
- Many other platforms, through a public, community-maintained rule set that is pinned to one version. The scan can detect them and press Reject all only. Because those rules are not written and tested for each platform, every finding that depends on the state after the choice is marked “needs verification”.
- Platforms that expose the IAB consent interface but cannot be driven by the scan. The scan says it saw a platform and could not check what happens after Reject all, because it cannot press the platform’s buttons.
- Any banner, with selectors you supply. In a site’s scan policy, Advanced: consent banner controls lets you describe a banner the scan does not know: how to detect it, its accept and reject controls and how to tell that the choice was stored. These are used before anything automatic.
- Nothing recognised. The scan states that no consent platform was found. If the page then sets optional cookies or contacts optional third parties before any choice, that is a finding of its own.
A platform behind a region check, a bot check or a consent-free setting can look to the scan like “nothing recognised”. The next sections say how the scan reports that.
When a situation could not be completed
Sometimes Reject all or Accept all is not performed. The scan says which of these reasons applied.
| Reason | In plain words | A finding of its own? |
|---|---|---|
| No consent platform was found | There is no banner to answer. | Only if optional cookies or third parties appear before any choice. |
| The banner’s control was not found | A banner is there and the scan could not find the control it needed. | Yes: the reject control was not found (needs verification). |
| The banner did not respond | The control was pressed and the page did not end in the state the platform stores for that choice. | No. It can be a slow page, so it is not reported. |
| The scan ran out of time | The page or the platform was too slow for the scan’s own time budget. | No. |
| This platform is not supported yet | The scan recognised the platform and has no way to press its controls. | Yes, as for a missing control (needs verification). |
| The platform did not show a banner | The platform says no choice is being asked for this visitor, and there is no banner on the page. | No. Nothing was asked, so nothing is wrong. |
Whatever depends on a situation the scan could not complete is not judged. The scan never reads a missing situation as “nothing found”.
Needs verification
Every finding is either confirmed or needs verification.
- Confirmed means the scan saw it directly, for example a cookie that the classification tables call optional was in the browser before any choice.
- Needs verification means the scan saw something but cannot rule out an explanation that makes it harmless, so a person should look. The finding’s text says which. The usual causes: a cookie or domain no table recognises, a platform recognised only from the community rule set, a finding read from something missing rather than from something collected, a page that was still loading when the scan collected it, a list cut to fit a scan’s size limit, or a value that depends on a format its owner does not publish.
A finding that needs verification counts one level lower in Health. Treat it as a pointer to where to look.
When you compare scans
A scan is compared with the one before it on the same site. For consent, the comparison asks for each rule whether the new scan could look at what the rule reads.
- If the new scan could not complete a situation a rule reads, a finding that is no longer present is not shown as Fixed. It is shown as Not looked at, it stays open, and the next scan that can look decides.
- A finding that appears after a scan that could not look is shown as incomparable, not as new, and does not raise a regression alert.
- A run in which Reject all or Accept all could not be completed on a page does not resolve the findings about approved third parties either.
- Cookies, requests and storage are kept in lists with a size limit, so a page with a very large number of frames can have a list cut. Findings that depend on a cut list are marked for verification, and a cut list does not resolve a finding that was there before.
- The first scan of a site after a release that changes what consent findings say is compared as incomparable. What only the release raises shows as incomparable, and what it stops raising shows as Not looked at. The comparison says why.
A platform that loaded and showed no banner
Some pages load a recognised platform’s script and show the scan no banner. Page Lookout reports that with a low-key info finding, A consent platform loaded on this page but showed this scan no banner, marked “needs verification”. Nothing was checked after Reject all or after Accept all, and the finding says so.
A platform can decide not to show a banner by region, by its own settings or to automated browsers, or the banner can arrive too late. If it appears in an ordinary browser and not in the scan, check the platform’s settings for automated visitors or for that region. A site that shows this finding on every scan is one where the scan cannot answer, and that is what the finding is for. Adding the banner’s selectors in the site’s scan policy lets the next scan answer it.
The scan is an automated browser, and says so
Page Lookout’s user agent carries the token PageLookout and points to pagelookout.com/bot, which says what the scanner is and how to allow or block it. The scan does not hide that it is automated, does not pretend to be a person or another crawler, and does not try to get around a check meant for automated visitors. When a site treats automated visitors differently, the scan shows what the site shows an automated visitor, and the findings say that it could not answer.
Consent signals
Besides what a page does, a consent scan can read what the page declares about the visitor’s choice: not what the page did, but what it told the tags and vendors that read it.
The IAB consent string
Many consent platforms follow the IAB Transparency and Consent Framework (TCF). They expose an interface that returns a consent string: a compact record of the visitor’s choice. It lists the purposes the visitor consented to, the vendors they allowed and what the site declared as legitimate interest. Advertising tags read it before they run.
The scan asks the page’s interface for the string in each of the three situations, in the main frame of the page, and decodes it. Page Lookout keeps:
- whether the interface answered, whether the framework applies to this visitor, and the platform’s id and version;
- the purposes consented to, the purposes declared as legitimate interest and the special features consented to;
- how many vendors have consent and how many legitimate interest;
- how many publisher restrictions the string carries, and the framework policy version;
- a short digest that tells whether the string changed between situations.
Purposes 2 to 11 are the ones a visitor is normally asked about, such as selecting and measuring ads or personalising content. Purpose 1 is storing information on the device, and a string that grants purpose 1 alone is not counted as granting purposes in the card’s figures.
A short table kept with the scan links the domains of about thirty well-known advertising vendors to their number in the IAB vendor list. It is used only to see whether a vendor the page contacted is one the string allows. A domain that serves several products is not in it.
Google Consent Mode
Sites that use Google tags tell them what the visitor allowed through Consent Mode. Each Google request carries a short state, and the scan reads it from the requests themselves, not from the page’s code. There are four consent types: ad storage, analytics storage and, since Consent Mode version 2, ad user data and ad personalisation. For each, the card shows the state that was sent, the default the site set and the update after the choice: granted, denied, varied between requests, not set or could not be read.
Only requests to recognised Google endpoints are read: Google Analytics 4 (including a site’s own server-side collection path), Google Ads conversion and remarketing, and Floodlight. Nothing else is taken from a request: no property id, no client or user id, no page address and no full URL. If no Google request fired in a situation, the card says None in this state, which is the honest answer for a site that holds its Google tags back until the visitor chooses.
What the checks can tell you
These findings appear in a scan’s findings list like any other consent finding.
| Finding | In plain words |
|---|---|
| The consent string grants purposes before a choice was made | The platform’s record already consented to purposes before the banner was answered. |
| The consent string still grants purposes after Reject all | The record still consents to purposes after the reject control was used. |
| A consent platform returned no consent string after a choice | The interface said the framework applies and returned no string. Needs verification. |
| The consent string declares legitimate interest for purposes the framework reserves for consent | The string states a basis the framework’s policy does not offer for these purposes. |
| A vendor the consent string refuses was contacted after Reject all | A known advertising vendor was contacted although the string allows it neither basis. Needs verification. |
| A TCF vendor was contacted that the consent string does not list | The string and the page disagree about which vendors are in play. Needs verification. |
| Google tags sent consent as granted before a choice / after Reject all | A Google request carried at least one consent type as granted. |
| Google tags do not send the ad user data and ad personalisation consent states | Requests carry the older two states and not the two added in Consent Mode version 2. Needs verification. |
| Google tags on this page send no Consent Mode state | Google requests were made and none carried a state. Needs verification. |
Two things to keep in mind when reading them.
- Declared is not done. A string that grants a purpose says what the platform recorded. Whether a tag then misbehaved is what the cookie and request findings show.
- A refusal can be honoured. A vendor contacted after Reject all may serve ads without personal data, so that finding always asks a person to look.
These findings describe what the page declared. They do not say whether a value is right for your site: that needs someone who knows its set-up. They count in Health by severity and by the share of pages they were seen on, like any other consent finding. None of them is critical, so none caps a module’s Health on its own.
What is never stored
The consent string itself is never stored, logged or returned: only the decoded values above and the digest. For Google requests the scan keeps the consent state and a request count. The address, the query and every identifier in it are dropped when the request is recorded.
The Consent signals card and the CSV
The Consent signals card on a scan’s page shows what the pages of that scan declared, before a choice, after Reject all and after Accept all. It has a sentence at the top, for example An IAB consent string was found on 8 of 10 pages. After Reject all, 2 pages still grant purposes., whole-scan figures, a page selector and two tables, one for the IAB consent string and one for Google Consent Mode, each with the three situations as columns. A scan made before the signals were read, or with reading switched off, shows Not read in this scan.
Download CSV gives one row per page and situation. The columns are Page path, Scenario, TCF platform id, Applies to visitor, String, Purposes granted, Special features, Vendors with consent, Vendors with legitimate interest, the four Consent Mode states and Google requests. The file has at most 10,000 rows and says so when it is cut. A spreadsheet will not run a cell that starts with =, +, - or @, and each download is recorded against your organization. The same data is available through the API, see API and webhooks.
A site that already has consent scans is compared, on the first scan after the readings are switched on, as incomparable: the new findings show as incomparable instead of new, and no regression alert fires for the change. Alert rules that count findings or follow Health do not look at that, so the first scan after the switch-on can still raise them.
What it does not say
- It does not tell you whether a site meets any privacy requirement, and nothing in the product says so. A finding describes what a page did or declared in the situations the scan checked.
- It does not say a banner or a consent string is correct. It says what the page did, what it declared, and where a person should look.
- It checks the pages it selected, from one European region, as an automated browser. Many sites treat visitors in other regions, or real browsers, differently. An absent finding means “not seen in these situations”, not “not there”.
- It does not read the Global Privacy Control signal, the contents of the IAB US privacy string or a site’s own consent code yet.