Consent in single-page apps: route changes that never fire a new scan
Hook your consent platform into the SPA router so every route change re-evaluates which tags may fire, and block route-specific trackers until consent covers them.
Why SPAs break page-load consent models
Traditional consent tools assume a page load: scan on load, gate tags, done. A single-page app loads once and then swaps views via the router, so a video embed on the pricing route or a chat widget on the support route can initialize without any new consent check.
The result is a site whose homepage is perfectly compliant and whose checkout flow fires unconsented tags. Scanners that only test the landing page never see it.
Wiring consent into the router
The fix is an event listener on route changes that tells the consent platform to re-evaluate: which tags does this route need, and does the current consent state allow them. Tags that are not covered stay blocked until the user grants the relevant purpose.
Most consent platforms expose a JavaScript API for this. Call it in your router's after-navigation hook, not in individual components, so no route can forget. Test by navigating the full user journey in a clean profile and watching the network tab.
Handling consent changes mid-session
Users can open cookie settings mid-session and revoke a purpose. In a traditional site the next page load enforces it; in an SPA you must enforce it immediately by tearing down the affected trackers and clearing their state.
Implement a consent-change handler that stops data collection for revoked purposes without requiring a reload. If a tracker cannot be stopped cleanly, reload the route. A broken session is better than unconsented collection.
Scanning an SPA properly
Automated scanners need a scripted journey, not a URL list. Record the key routes, feed them to the scanner, and review the per-route tag report. Any route whose tags are not covered by the homepage consent state is a finding.
Add the checkout and account routes to every scan. Those are the routes with the most third parties and the least testing.
Do we need to re-scan on every deploy?
If the deploy changes routes or adds third parties, yes. Tie the consent scan into your release checklist for frontend deploys.
What if our consent vendor has no SPA mode?
Use its JavaScript API manually in the router hook, or switch vendors. Page-load-only consent on an SPA is a known gap regulators understand.
How do we test route-level consent?
Navigate the full journey in a clean browser profile with the network tab open, rejecting optional categories first, and confirm no marketing calls fire on any route.
Get a free consent audit of your website
Free consent auditFrequently asked questions
What is the Transparency and Consent Framework (TCF)?
The TCF is an industry standard for passing consent signals between publishers, ad tech vendors, and consent platforms in programmatic advertising. It standardizes how a visitor's choice is encoded so hundreds of vendors can read it, which also means a misconfigured TCF string broadcasts the wrong consent widely.
Should our banner list every vendor by name?
Vendors in frameworks like the TCF are presented through the standardized vendor list, which can number in the hundreds. You do not hand-type them all, but you should verify the list your platform shows matches reality and that vendors you do not work with are not enabled by default.
What is a legitimate interest claim and can it replace consent?
Legitimate interest is an alternative legal basis for some processing, but regulators have narrowed where it applies in advertising and tracking contexts. It does not cover most behavioral advertising. Treat claims in vendor configurations skeptically and document your own basis per purpose.