When Google Analytics stops after a redesign, the cause is almost never Analytics and almost always the new pages: the tracking tag was not carried over. A redesign rebuilds your templates, and if the GA4 tag or Tag Manager container was not added back to each one, the site looks perfect while collecting no data at all. The fix is direct, confirm the tag is present and firing on every template, then verify in real-time. The deeper lesson is that tracking broke for the same reason redirects and metadata break: nothing was inventoried before the rebuild. WPBuildAI checks tags, redirects, and metadata as part of a migration so none of it drops silently.
Check the AI channel separately while you are repairing analytics, because it does not behave like organic search: SE Ranking measured AI referral traffic growing sixteenfold between 2024 and 2026 to 0.32 percent of all site traffic, with those visitors spending 67.7 percent longer on site than visitors from organic results.
Why the site looks perfect while collecting nothing
This is what makes the break so easy to miss. The tracking tag is invisible to visitors, so the redesigned site can look flawless, load fast, and work in every browser while recording not a single session. There is no error page, no broken layout, no warning in the dashboard beyond a line that quietly goes flat. Most people notice days later, when they open a weekly report and find it empty. The gap between “the site is fine” and “the data is gone” is exactly why a tag belongs on a launch checklist rather than in someone’s memory, because nothing on the page itself will tell you it is missing.
How to confirm the tag is actually missing
Start with the real-time report, because it gives an answer in seconds. Open GA4’s real-time view, load your site in another tab, and watch for your own visit to appear. If it does not show up within a minute, the tag is missing or misconfigured. To confirm where, view the page source and search for your measurement ID, or use Google’s Tag Assistant to see which tags fire on the page. Google’s own guide to adding the Analytics tag describes what a correctly installed tag looks like, which is the reference to check the new pages against. Test on more than the homepage, because that is where this fails.
Where the tag usually got dropped
The tag rarely vanishes from the whole site at once. A redesign rebuilds templates one at a time, and the tag is typically pasted back into the one template someone tested, usually the homepage, and missed on the others: blog posts, product pages, the contact form, the checkout. So tracking appears to work when you spot-check the front page and silently fails everywhere else. The 2024 Web Almanac documents how many sites run analytics and tag-manager scripts, and how easily those third-party tags are dropped when markup is regenerated, which is exactly what a redesign does to every template at once.
A worked example: the homepage that tracked
Picture a redesign where the developer adds the GA4 tag to the global header, tests the homepage, sees the visit land in real-time, and calls it done. For a week the data looks plausible, because the homepage does get traffic. Then someone notices that blog sessions have collapsed to nothing. The cause: the blog uses a different template whose header was rebuilt separately, and the tag never made it there. The homepage tracked perfectly the whole time, which is precisely why no one caught it. The lesson is to verify every distinct template, not the one page that happens to be easiest to check.
The break you noticed is rarely the only one
Lost tracking is the visible failure, but it travels with quieter ones. Redirects, metadata, and structured data all disappear the same way, by not being carried over, and those cost rankings rather than dashboards. Ahrefs found in its search traffic study that a small share of pages carries most organic traffic, so a redesign that quietly drops the wrong URLs can cost far more than a tracking gap ever will. You only see the analytics break first because the report goes flat overnight, while a ranking slide takes weeks to show. Treat the missing tag as a prompt to audit the rest, covered in the migration SEO checklist.
How to restore tracking, step by step
- Confirm the measurement ID in your GA4 property, so you are installing the right one.
- Add the tag to every template, not just the homepage, either directly in the shared header or through a Tag Manager container loaded site-wide.
- Clear caches so the new markup is actually served, since a caching layer can keep serving the old tag-less page.
- Verify in real-time across several page types, loading a blog post, a product page, and a form, watching each visit land.
- Check Tag Assistant to confirm the tag fires once per page, not zero times and not twice.
Done in that order, you fix the cause rather than the homepage, and you catch the templates that silently dropped the tag.
Can you recover the data lost while tracking was off?
No, and it is worth being honest about it. Analytics only records what it observes, so any session that happened while the tag was missing is gone for good; there is no backfill. What you can do is restore tracking from now, and use other sources to estimate the dark period: Search Console still has impressions and clicks for that window, your server logs may have request data, and any ad platform you run kept its own records. None of that reconstructs GA4 perfectly, but it lets you annotate the gap rather than mistake it for a real traffic collapse. The permanence of the loss is the strongest argument for verifying tags before launch, not after.
GA4 versus Tag Manager: where each breaks
The failure point differs slightly by setup, and knowing which you run narrows the search. With a hard-coded GA4 tag, the break is a missing snippet in a rebuilt template, so you are looking for the gtag code in the page source. With Google Tag Manager, the GA4 tag may be configured correctly inside the container while the container snippet itself is what got dropped from the new templates, so the whole container goes silent at once. Check the container loads first, then check the tag inside it fires. Either way the root cause is the same, a script that did not survive the template rebuild, but where you look depends on which layer your site uses.
Prevent it with a crawl-first launch
Google’s site move guidance frames a migration as an inventory problem: list everything on the old site, carry it to the new one, and verify after launch. Tags belong on that list alongside URLs, metadata, and schema. Inventory first and nothing depends on remembering it at the end, the same discipline behind the pre-launch migration checklist and behind avoiding soft 404s after a redesign. A crawl of the old site captures the tag, the URL set, and the metadata in one pass, so the new build has a definitive list to check itself against rather than a developer’s memory.
When tracking did not actually break
Before you go hunting for a missing tag, rule out the cases where the data is fine and only looks wrong. A new GA4 property started fresh shows no history, which can read as “tracking stopped” when it never started on the new property. A misapplied filter, a changed data-stream, or consent settings that now suppress unconsented hits can all reduce recorded sessions without any tag being missing. And a few hours of real-time lag during launch day is normal. Confirm the property and stream you are looking at match the tag on the page, and that no filter or consent change explains the drop, before concluding the tag itself is gone.
Common mistakes that hide a tracking gap
A handful of habits let a tracking break go unnoticed for weeks. Spot-checking only the homepage misses the templates where the tag actually dropped. Trusting that “the tag is in the theme” without verifying ignores that a redesign rebuilt the theme. Forgetting to clear caches means you test the old cached page and see a tag that the live page no longer serves. And launching without a before-and-after tag check leaves the whole thing to chance. Each mistake is a version of assuming the invisible tag survived a rebuild that touched every template, which is the one assumption a redesign should never get.
Key points to remember
Analytics stops after a redesign because the tag did not make it onto the new templates, so confirm it fires on every page type and verify in real-time, not just on the homepage. The data lost while the tag was missing is gone for good, which is why the check belongs before launch. Treat the silent tag as a warning that redirects, metadata, and schema may have dropped the same way, and prevent all of it with a crawl-first launch that inventories everything up front. WPBuildAI carries tags, redirects, and metadata through a migration and verifies them after cutover, so the new site measures and ranks from day one; send your site URL for a fixed quote.
Not affiliated with Google, WordPress, or Lovable.