Cookie Consent in Single Page Apps: Routing Without Reloads
Consent tools were built for a web of page loads. A single page app breaks that assumption: the document loads once, and every navigation after that is a state change inside the same page. Tags that were blocked correctly on first load can fire freely on the fifth route change, because nothing re-runs the checks that stopped them.
This guide covers where consent logic belongs in a single page app, how to handle route level events and virtual pageviews, what to do about tags injected by components, and how to test the whole flow so consent survives navigation, refresh, and login.
Put consent state in the app, not the page
In a traditional site the consent script runs on each load and the page inherits its decisions. In an app, the consent state should live alongside your other global state, loaded once from storage, exposed to every component, and updated in one place when the user chooses. Components and tag helpers then ask that state before doing anything measurable. If consent logic is scattered across components, each team will implement it slightly differently, and the gaps will appear exactly where a new feature shipped fastest.
Route changes are pageviews
Analytics treats a route change as a pageview, so consent has to treat it the same way. Before the router emits a view event, confirm the stored choice covers analytics. The same applies to events fired by components mounting on the new route: a product carousel that loads a measurement pixel on mount is firing a tracker, whatever the component is called. A practical pattern is a small wrapper around event firing that checks consent centrally, so individual features cannot bypass it by accident.
Components that inject their own tags
Embedded video, chat widgets, payment frames, and A B testing tools all bring their own scripts, and in an app they often load when a component first renders rather than at startup. Inventory these per route, not per site, because the checkout route and the help route rarely carry the same tools. Gate each loader on the relevant consent category and render a placeholder with an activation option where the content itself needs a third party, such as a video player the user can choose to load.
Test navigation, not just first load
A consent test that only checks the landing route proves very little for an app. Test a full session: arrive, refuse, navigate through the main routes, log in, and confirm no blocked requests fire at any step. Then accept and confirm tags begin without a manual refresh, and withdraw mid session and confirm they stop. Automate the network checks where you can, because route level regressions arrive with ordinary feature work, and manual spot checks will miss the route nobody remembered to list.
Related reading
These earlier guides cover connected questions in more depth: Cookie Scanner False Positives: A Triage Routine That Keeps Notices Accurate, Cookie Consent for Webinars and Event Registration Pages, and Consent and Age Verification Overlays: Two Gates, Two Different Jobs.
Frequently asked questions
Why does our banner reappear on every route change?
Usually because the app re-mounts the banner component on navigation and it re-reads consent state before the stored value loads. Load the stored choice once in the app shell and keep the banner mounted there.
Do virtual pageviews need consent?
Yes. A virtual pageview sends the same data to the same analytics tools as a traditional pageview. The fact that the browser did not reload does not change what is collected.
How should login change consent handling?
If you sync consent to an account, apply the stricter of the device choice and the account choice until the user confirms, and record which source set the current state.
What about server side rendering and hydration?
Decide consent dependent rendering on the client after hydration, and avoid rendering tracker scripts on the server for a page whose consent state the server cannot know.