How-to · Updated October 11, 2026
Track page changes on a site that doesn't reload pages
Updated October 11, 2026
40 minutes
If GA4 shows one page view per visit, the site probably swaps pages without reloading. Pick one sender for those page changes: GA4's browser history setting, or a History Change trigger in Tag Manager, never both. Then add a History Change trigger to every other tag that must run on each page, such as call tracking.
Before you start
- Editor access to GA4 and Edit access or higher in Tag Manager. Google's guide for this setup assumes edit rights in both products.
- Publish permission on the container, to put the triggers live.
- A list of the container's tags set to fire on page load, from the Tags screen, so none is missed in the last part.
Confirm the site changes pages without reloading
On these sites the first page loads once and every later page is drawn by script, so anything set to run on page load runs only when the site first loads, usually once per visit.
- Go to tagassistant.google.com, click Add domain, enter your website address and click Connect. This turns on debug mode for your browser.
- In GA4, click Admin and, under Data display, click DebugView.
- Load the home page, then click through to two other pages. Watch the address bar and the Seconds stream. If the address changes but no new page_view arrives, the site most likely changes pages without reloading, and nothing counts the change.
Count each page change once
Use one of two senders, because Google warns that turning on both the GA4 setting and Tag Manager history tags can count page views twice.
- If GA4 is installed without Tag Manager: in GA4, open Admin, then Data streams, click your web stream and turn Enhanced measurement on. Click the settings icon, and under Page views, click Show advanced settings and enable both Page loads and Page changes based on browser history events. Click Save.
- Then, on the same stream, under Google tag, click Configure tag settings, click Show all, open Manage automatic event detection, and make sure Page views on browser history change is on. Google says each event type must be on in the Google tag's settings too.
- If GA4 is set up in Tag Manager, Google's developer guide says to use Tag Manager for this instead. In the GA4 stream's Page views advanced settings, clear Page changes based on browser history events and save.
- In Tag Manager, click Triggers, then New, choose History Change, name it, and save.
- Click Tags, then New, choose Google tag, and enter the same tag ID as your existing Google tag. Under Configuration settings, add page_location set to {{Page URL}}, page_title set to {{Page Title}}, and update set to true. Leave Triggering empty and save. If Tag Manager asks you to add a trigger, save without one, because the next tag fires this one.
- Click Tags, then New, choose Google Analytics: GA4 Event, enter your Measurement ID and set the Event Name to page_view. Under Advanced Settings, Tag Sequencing, tick the box that reads Fire a tag before, followed by this tag's name, and choose the Google tag from the last step. Under Triggering, choose the History Change trigger and save.
Google notes that the update setting suppresses an immediate duplicate page_view when the Google tag runs again.
Run your other tags on every page change
On these sites a tag that fires only on page load runs when the site first loads, so it misses the pages reached after that.
- Go through your list of tags on page load triggers and pick the ones that must run after a page change, such as a call tracking script that swaps phone numbers, or a conversion tag tied to a thank-you page address.
- For a tag that should fire only on one page, such as the thank-you page conversion, make a second History Change trigger set to Some History Changes with Page URL containing that page's path, and add only that trigger. Do not add the plain History Change trigger to this tag: a tag fires when any one of its triggers is met, so the plain one would record a conversion on every page change.
- For a tag that should run on every page, such as a call tracking script, open it, click Triggering, and add the plain History Change trigger next to its page load trigger. A tag can have more than one firing trigger.
- Click Preview, click through the site, and confirm each tag fires on the page changes. Then click Submit, choose Publish and Create Version, and click Publish.
For a call tracking script, adding the History Change trigger is one way to keep numbers swapped on later pages, but it is not from Google, and some providers document their own method for sites like this. Check with your call tracking provider before relying on it, and confirm the script tolerates running again.
Check it worked
With Tag Assistant connected, watch DebugView as you click through the site. Each page change should add exactly one page_view, and its page_location should match the new address. Two page_view events per change usually means both senders are on, or the Google tag from the second part is missing update set to true.
Over the next days, GA4's page reports should list the pages people move to, not only the page they entered on.
When the address does not change at all
Some sites swap screens without changing the address. A History Change trigger and GA4's history setting both rely on the browser history changing, so neither sees those screens. Google's guide for that case is a custom event the site pushes for each screen, which a developer adds.
Why engagement time looks wrong before the fix
Google says that without a page view for each screen change, Analytics treats the whole site as a single page, so all engagement time is credited to the first page of the visit.