To test consent after client-side navigation, save a choice, follow an internal link without reloading the document, and inspect the new route's tool activity. Then load that destination directly and reload it with the same choice. A clean direct load can miss a widget that starts only after navigation.
Single-page applications change visible routes while keeping the document alive. OneTrust's SPA guidance notes that head scripts don't rerun on each navigation and documents configuration and lifecycle handling for this case. Test your installed consent management platform (CMP) and its tool integrations rather than treating every route change as another fresh page load.
Compare three ways into the same destination
Keep rejection saved, switch to client-side navigation, and gate the new component. Compare that result with a reload. Try acceptance too; an accepted path alone won't reveal the rejection bug.
- 1Consent already saved
Rejected for the example analytics purpose
- 2Document starts and initial consent setup runs
The fixture's initial setup reads the saved choice
- 3Widget starts or remains blocked
Example cookie: not written
The saved denial keeps the example widget blocked on this measured transition.
This fixture assumes full loads are already gated correctly and the bug affects a later component. It is not a live navigation audit. Test consent changes and withdrawal as additional transitions in your own application.
Choose a route that loads a new tool
Use an internal link that mounts a component with its own loader: a chat widget, video embed, booking tool, or route-specific analytics. Record the starting URL, destination, build, expected permission, and exact interaction. Confirm the app actually used client navigation.
The demo assumes the initial setup reads saved consent correctly, while a later widget bypasses it. Your app might have a direct-load failure too. Inspect both paths before choosing a fix. For a regression after a performance update, inspect the consent load order.
Keep the choice while testing the transition
- In a fresh session, reject the relevant purpose on the starting page. Confirm the stored choice and establish the cookie and request baseline.
- Keep that session open. Follow the internal link, wait for the new component, and record what changes. Don't clear storage between the starting page and destination.
- Reload the destination with the same stored rejection, then compare with a direct-load session carrying an equivalent choice. Use a consistent observation window.
- Repeat with acceptance. Separately test a consent change while the component is already mounted, and withdrawal after a tool has started.
Preserve the network log for the transition and compare storage before and after. An existing cookie after withdrawal doesn't establish a new write. For Google tags, compare requests after rejection with their consent signals; a request alone doesn't identify a new cookie write.
Inspect component startup and consent updates
Find where the new component reads permission. Check the first startup, the CMP's documented update event, and teardown when permission changes. A hook that ran once on the original page may leave a later component outside the intended gate.
OneTrust provides SPA integration guidance and the OneTrustGroupsUpdated event for choice updates. Map group IDs to your site's categories and follow its configuration instructions. Reinitializing the banner on every route is not a universal fix; the tool consuming the choice still needs the correct lifecycle.
- OneTrust: single-page applications SPA configuration and banner lifecycle guidance.
- OneTrust: JavaScript events Documented consent-update events.
Keep navigation checks beside regional baselines
Run the transition in the locations whose rules or tools differ. Save the route, build, choice, and evidence for a matching regional retest. Claude can help inspect your component and build a navigation harness; your team still needs to maintain the routed browsers and result records.
CookieTrail supplies repeatable regional first-load, accept, and reject captures for a public URL in Germany, the UK, US East, US West, Canada, or Singapore. Use those as direct-entry baselines, then attach your separate within-session navigation trace to the investigation.