# Single Page Apps Break Consent in a Specific Place: The Route Change

Source: https://cookiecitadel.com/blog/2026-11-04-spa-route-change-consent-recheck.html

[Home](../index.md) / [Blog](index.md) / Consent on Smart TVs and Streaming Apps: Viewing Data Nobody Agreed To Share


Published 2026-11-04

A single page app loads the consent tool once and then navigates without reloading. Any tag logic that assumed a fresh page load, a fresh consent read, a fresh page view event, silently runs on stale assumptions. Consent itself may be stored correctly while the firing logic built around page loads never revisits it.

## The page load assumption hiding in your tags

Classic tag setups lean on the page load as the moment everything is evaluated: consent state read, page view sent, triggers matched. An SPA fires that sequence once, at the shell load, and then swaps views internally. If consent is withdrawn in a settings panel on one route, tags keyed to page load have no natural moment to notice, and they keep firing under the old state until a full reload happens to occur.

Analytics feels it first, as route changes either vanish from reporting or arrive as custom events that each team wired differently. Consent feels it second and worse, because the error direction is asymmetric: firing under a withdrawn consent is a compliance failure, while missing page views is a reporting annoyance the team will actually investigate.

## What to wire to the router instead

Treat the router as the page load's replacement and say so in the implementation spec. On every route change, the app should re read the current consent state, push a page view event carrying that state, and let the tag manager evaluate consent dependent tags against the fresh value. Withdrawal inside the app must also push a consent update event immediately, the same event a banner save would fire on a classic site.

Embeds mounted by components need the same discipline. A video or reviews component that loads when its route mounts is an embed decision made by a developer who may never have seen the consent spec. Gate component level third party loads on the same consent check the banner uses, ideally through one shared consent service the whole app calls. Our explainer on [Embedded Maps, Videos, and Widgets Set Cookies Your Banner Never Mentions](https://cookiecitadel.com/blog/2026-11-03-consent-embedded-widgets-maps.md) covers the embed side of this problem.

## Testing an SPA consent flow

The test script differs from a classic site test. Land, refuse, navigate three routes, and record the network throughout: no new marketing requests should appear on route changes. Then grant consent in the settings page mid session, navigate again, and confirm tags begin only from that point. Then withdraw mid session and navigate: firing must stop on the next route change at the latest, not at the next reload.

Persist the results with build numbers. SPA consent bugs are usually regressions introduced by a router or tag manager change, and the recording from the last good build is what lets a team bisect instead of argue. Consent in an SPA is a software behaviour, and it needs software style regression tests around it.

Keep reading: [Embedded Maps, Videos, and Widgets Set Cookies Your Banner Never Mentions](https://cookiecitadel.com/blog/2026-11-03-consent-embedded-widgets-maps.md) [How Long to Keep Consent Logs: Retention That Survives the Data It Covers](https://cookiecitadel.com/blog/2026-11-03-consent-log-retention-periods.md) [Consent for Connected TV Apps: The Living Room Screen Nobody Audits](https://cookiecitadel.com/blog/2026-11-02-consent-connected-tv-apps.md).

## Frequently asked questions

### Why do SPAs have special consent problems?

Because the page load, which classic tag setups use as their evaluation moment, happens once. Route changes, consent withdrawals, and component mounted embeds all occur without a reload, so logic keyed to page load runs on stale consent state unless the router events are wired to recheck it.

### What event should fire when consent changes inside an app?

A consent update event on the data layer, the same one the banner produces, pushed at the moment the settings save completes. Tags listen for that event and start or stop accordingly. If only the banner can produce the event, in app settings changes will not affect firing until reload.

### How should route changes handle analytics consent?

Each route change should push a page view event that carries the current consent state, and the tag manager should evaluate consent dependent tags against that fresh state. That keeps reporting consistent and ensures a withdrawal takes effect on the next navigation rather than the next full load.

### Do component embeds need consent checks too?

Yes. Any component that loads a third party resource when it mounts, a player, a reviews widget, a chat tool, must check the same consent service the banner writes to. Component level loads are the most common SPA consent gap because they bypass the tag manager entirely.