Website Compliance
How Website Compliance Scanning Actually Works
What actually happens between entering a URL and receiving a compliance report.
Quick answer
An automated website compliance scan works by rendering a page in a real browser engine — not just fetching its raw HTML — so it sees the page the way an actual visitor would, including scripts that run after page load and content gated behind cookie consent. That rendered page is converted into a structured snapshot: scripts loaded, cookies set, consent-gating behavior, DOM structure, and text content. Each compliance module (GDPR, AI Act, accessibility) then runs its own checks against that same snapshot, and the results are combined into one report.
By GetGDPRScan Editorial · Last updated 2026-07-24
A compliance scan is often assumed to mean "the tool downloaded my HTML and searched it for keywords." That approach exists, and it is unreliable — it misses anything that only appears after JavaScript runs, which today is most tracking and consent behavior.
This article describes the actual mechanism: rendering, snapshotting, and modular analysis. The companion article, What Automated Compliance Scanners Can (and Can't) Detect, covers this mechanism's limits.
Why does rendering the page matter, instead of just fetching its HTML?
Raw HTML fetched with a simple HTTP request often looks nothing like what a visitor's browser actually renders. Cookie banners, tracking scripts, and consent logic are frequently injected or modified by JavaScript after the initial page load — a plain HTML fetch never executes that JavaScript, so it can miss the exact behavior a compliance check cares about.
Rendering the page in a real browser engine executes that JavaScript the same way a visitor's browser would, which is what makes it possible to observe things like: does a tracking script actually fire before the user interacts with a consent banner, or only after.
What gets extracted from a rendered page?
Once a page is rendered, it's converted into a structured snapshot rather than analyzed as raw markup. That snapshot typically includes which scripts loaded and from where, what cookies were set and when, the page's DOM structure and text content, and — critically — the page's state both before and after simulated consent interaction, so a scanner can distinguish a script that fires immediately from one that only fires after consent is given.
How do the different compliance modules use the same snapshot?
Each module — GDPR, AI Act, accessibility — is a distinct rule set that reads the same underlying snapshot rather than triggering its own separate page load. The GDPR module looks for tracking scripts and cookies relative to consent state; the accessibility module evaluates DOM structure against WCAG success criteria; the AI Act module looks for signals of AI-system usage and related disclosures.
This is why adding a new compliance domain doesn't require rebuilding the scanning mechanism — it requires writing a new module that reads the signals already being captured, or extending the snapshot to capture new signals a module needs.
What each live module reads from the snapshot
| Module | Primary signals it reads |
|---|---|
| GDPR | Scripts/cookies before vs. after consent, cookie banner presence, privacy policy content |
| AI Act | Signals of AI-system usage and related disclosure text |
| Accessibility (WCAG) | DOM structure — headings, alt text, ARIA roles, form labels, color contrast |
Does the scanner interact with the page, or only observe it?
Some checks require limited interaction — for example, distinguishing scripts that fire only after a consent banner is dismissed from ones that fire regardless. The scanner does not create accounts, submit forms with real data, or take actions beyond what's needed to observe consent-gated behavior.
How GetGDPRScan checks this: GetGDPRScan's GDPR module specifically compares script and cookie activity before and after consent-gated inline scripts are accounted for, so a tracker that only appears to load after consent isn't misreported as loading before it.
Key takeaways
- •The scanner renders pages in a real browser engine rather than fetching raw HTML, so it sees scripts and consent behavior the way a visitor's browser does.
- •A rendered page becomes a structured snapshot — scripts, cookies, DOM, consent state before/after — that every compliance module reads.
- •Adding a new compliance module means writing new checks against existing (or extended) snapshot data, not rebuilding the scan mechanism.
- •The scanner observes consent-gated behavior; it does not create accounts or submit real data into forms.
FAQ
Related
What Is a Website Compliance Platform?
The category this mechanism belongs to, and which modules are live today.
What Automated Compliance Scanners Can (and Can't) Detect
The limits of this mechanism — and why it isn't a legal audit.
GDPR compliance scan
Run a free scan and see this mechanism produce a report.
FAQ
Short answers to common compliance questions.