A WordPress Update Broke Your Tracking and Nobody Told You

WordPress runs a large share of the sites media buyers send traffic to, and it breaks tracking in ways that are specific to WordPress. The tag was there on Monday. A plugin auto-updated overnight. On Tuesday the conversions stopped, and the first person to notice was the client, three weeks later.

The frustrating part is that nothing announces itself. The site loads normally, the admin panel still shows the tracking plugin as active, and the ad account carries on spending at the same rate against nothing. This is the general problem with tracking failures, and WordPress has more ways than most platforms to arrive at it.

The five ways WordPress loses your tags

1. A theme update overwrites header.php

The oldest and still the most common. Someone pasted the pixel or the tag manager snippet directly into header.php, which lives inside the theme. Updating the theme replaces the theme files, and the snippet goes with them.

This is why child themes exist, and why “we never edit theme files directly” is a rule worth having. If a site has tracking in header.php of a parent theme, it is not a question of whether it will be lost, only when the next update ships.

2. The tracking plugin updates and resets

Plugins that manage pixels store their configuration in the database, and most updates leave it alone. Occasionally a major version changes the settings schema, and the pixel ID field comes back empty or reverts to a default. The plugin is still installed, still active, still showing a green tick, and emitting nothing.

Automatic updates make this worse, because the change happens at three in the morning with nobody watching, and the plugin version in the admin panel is now the only evidence anything happened.

3. A caching or optimisation plugin eats the script

This is the most confusing one to diagnose, because the tracking is present in the source and still does not run. Performance plugins defer, combine, minify and lazy load JavaScript, and tag manager snippets do not always survive the treatment.

• Deferred or delayed JavaScript can push the container load until after a user interaction, so visitors who bounce are never counted.
• Script combining can change execution order so the pixel fires before the thing it depends on is defined.
• Page caching can serve a version of the page generated before the tag was added, sometimes for days, and often only to logged out visitors, which is why it looks fine when you check it while signed into the admin.

That last point is the trap. Always check in a private window. A cached page served to the public can differ from the one an administrator sees.

4. A consent plugin starts blocking it

Consent management plugins for WordPress often ship with a scanner that categorises scripts automatically. An update can recategorise your tag manager as marketing rather than necessary, at which point it stops firing for every visitor who has not actively accepted.

Technically this is the plugin working correctly, and the tracking is not broken so much as gated. It still shows up in your ad account as a sudden drop. The wider version of this is covered in Consent Mode v2 and your tracking.

5. The page builder changes the thank you page URL

Elementor, Divi, WPBakery and the form plugins that go with them all have their own notion of what happens after a form submits. A redirect that used to land on /thank-you now lands on /thank-you-2 because a duplicate page was created, or the form now shows an inline success message and never navigates at all.

The conversion tag is fine. The trigger that fires it no longer matches anything. This is the WordPress flavour of a problem that is worth understanding generally, since the reverse mistake is the much more expensive conversion tag on an All Pages trigger.

6. A security or firewall plugin blocks the request

Less common than the others and much harder to spot, because the tag loads perfectly and the outbound request is what gets stopped. Some firewall and privacy plugins block third party requests by domain, and an update to their blocklist can start catching connect.facebook.net or googletagmanager.com without anybody choosing that.

The signature is a tag that is present in the source, executes without error, and produces nothing in the ad platform. The browser console or network tab on the live site is the only place this shows up.

Diagnosing it in order

Work from the outside in. Most of these steps need no WordPress access at all, which matters when the site belongs to a client and you are waiting on credentials.

1. Check what is actually on the live page. Load the site in a private window and read the source. Is the container or pixel snippet present? Our free tracking scan does this across several pages at once and lists every tag it finds with its real ID, which also catches the case where the tag is on the homepage but missing from the pages that matter.
2. Compare the homepage against a conversion page. Theme template differences are a common cause of partial coverage, and a tag that is missing only from checkout will not show up in any homepage test.
3. Check whether it loads but does not fire. Present in the source and not executing points at caching, deferral or consent. Absent from the source points at the theme or the plugin.
4. Read the WordPress update history. Most managed hosts keep an update log, and plugins record their own version history. Line the dates up against the day conversions dropped in your ad account. The correlation usually identifies the culprit immediately.
5. Test with caching disabled. If the host offers a cache purge or a bypass cookie, use it. If the tag appears once the cache is bypassed, you have your answer.

Installing it so it survives the next update

The goal is to put the tracking somewhere that updates do not touch.

• Never edit parent theme files. If direct insertion is genuinely necessary, use a child theme, which updates do not overwrite.
• Prefer a tag manager container over individual pixels. One snippet to protect instead of six, and changes to tracking afterwards happen in GTM rather than in WordPress, which removes the developer from the loop entirely.
• Exclude the container from script optimisation. Every serious caching plugin has an exclusion list. Put the tag manager and the pixel domains in it, and document that you have.
• Turn off automatic updates for the tracking plugin specifically. Keep them on for security updates. The point is that somebody should be awake when the tracking configuration changes.
• Use a staging site for theme and builder updates,and make “confirm the pixel still fires” a line on the deployment checklist. Our version of that list is in the pre-launch tracking QA checklist.

Confirming the fix actually worked

Reinstalling the tag is the easy half. The half people skip is proving it works for a real visitor rather than for an administrator with a bypassed cache, and the two are genuinely different.

1. Purge every cache in the chain.WordPress sites commonly have three: the caching plugin, the host's server cache, and a CDN in front of both. Clearing one and testing proves very little.
2. Test logged out, in a private window. Most caching plugins exclude logged-in users entirely, so an administrator sees the uncached page and the public does not.
3. Test on mobile as well as desktop.Several optimisation plugins apply different rules by device, and “delay JavaScript until interaction” behaves very differently on a phone.
4. Complete a real conversion end to end. Submit the actual form or place a real order, and confirm the event arrives in Events Manager or Google Ads. A tag that loads is not the same as a conversion that records.
5. Check a page nobody thinks about. A blog post, a landing page built in the page builder, a category page. These use different templates and are where partial coverage hides.

Allow for reporting delay before you panic. Google Ads conversions can take hours to surface, so an event that appears in the browser but not yet in the account is usually patience rather than a fault.

The part you cannot checklist your way out of

Every control above depends on somebody following a process at the moment of change. On client sites you usually do not control who makes changes, when they make them, or whether they tell you. A freelancer the client hired directly can update a theme on a Saturday and have no idea the conversion tracking lived in it.

That is the real gap. Not knowledge, and not care. Simply that the person making the change and the person who depends on the tracking are different people, and nothing connects them.

Taglert closes it by watching rather than relying on being told. It checks every connected account every thirty minutes and emails you the day conversion tracking stops, so a Saturday theme update becomes a Saturday email instead of a conversation with the client three weeks later. If you want to see the current state of a WordPress site right now, the free scan will read it in about thirty seconds without touching the site.