Universal Analytics stopped processing data on July 1, 2023, and on July 1, 2024 for 360 properties. On a surprising number of websites, the code never got the message. The old tag still loads on every page, still builds hits, and still sends them to Google, where nothing happens to them.
It is rarely alone. Google Optimize snippets that outlived the product, a second GTM container from an agency that left three years ago, and pixels for ad platforms nobody has bought on since the last budget cycle all tend to sit side by side in the same page source.
None of this shows up in a dashboard. It shows up in slower pages, data leaving your site without a contract behind it, and reports that nobody quite trusts. Here is how to find it and remove it without breaking what still works.
Is Universal Analytics still running on my site?
Quite possibly, and you can check in a few minutes. Search your page source for "UA-" followed by numbers, look for a script loading analytics.js, and watch the Network tab for requests containing "collect?v=1". Any of those means the old tag is still firing.
Universal Analytics property IDs follow the pattern UA-12345678-1. GA4 uses measurement IDs that begin with G-. If you only see G- IDs, the legacy tag is probably gone. If you see UA- IDs anywhere, something is still referencing the old property.
There are three common ways it survives:
Hardcoded in the theme. A developer pasted the analytics.js or an older gtag.js snippet into the site header years ago. The GA4 migration was done in GTM, and nobody went back to the template.
Still configured in GTM. The old Google Analytics: Universal Analytics tag type is still in the container, sometimes paused, sometimes not. Newer containers cannot create this tag type, but existing ones kept theirs.
Bundled in a plugin or platform setting. CMS plugins and ecommerce platforms often had a field for a UA ID. Clearing the GTM container does nothing if a plugin is injecting its own copy.
A gtag.js snippet can also carry both a UA- ID and a G- ID in the same block. The GA4 half keeps working, which is exactly why nobody notices the UA half.
Universal Analytics is the most common, but it has company. Google Optimize remnants, orphaned GTM containers from past agencies, and pixels for platforms you no longer buy on are the other usual suspects, and they tend to accumulate during agency changes and site rebuilds.
Google Optimize. Google sunset Optimize in September 2023. Its snippet was usually installed high in the page head, often with an anti-flicker script that hides the page until the experiment loads or a timeout expires. With Optimize gone, that snippet has no job, but an anti-flicker script can still hold the page blank until its timeout runs out on every visit.
Orphaned GTM containers. Search the page source for "GTM-" and count the distinct IDs. Two containers are sometimes intentional. Often the second one belongs to a previous agency, lives in an account you cannot access, and still fires tags you cannot see or edit. Whoever controls that container can add anything to your site at any time.
Pixels for retired platforms. You stopped buying on a network, but its pixel is still on the confirmation page. Worse, the platform may still be recording conversions and, if you ever reactivate a campaign, attributing sales to itself based on data you forgot you were sending.
Old conversion tags. Previous Google Ads accounts, abandoned affiliate programs, call tracking vendors from a past contract, and heatmap tools on a trial that ended. Each one adds requests to every page it touches.
More than it appears. Legacy tags add page weight and main-thread work, send visitor data to vendors you have no agreement with, widen your consent and privacy exposure, and muddy the reports people use to make budget decisions. None of that buys you anything, because the tags no longer serve a purpose.
Speed. Every script downloads, parses, and executes on the visitor's device. A dead analytics library, an anti-flicker timeout, and a handful of retired pixels compete with your own code for the main thread, which is time the page cannot respond to taps and clicks. Slower pages convert worse, and on paid traffic you are paying for every visitor who leaves before the page is usable.
Data sent without a contract. When you stopped working with a vendor, you probably stopped paying them. You did not necessarily stop sending them your visitors' data. That data flow sits outside any current agreement, which is a legal and commercial problem regardless of what the vendor does with it.
Consent exposure. Consent setups are usually built around the tags someone knew about. A hardcoded pixel or a second container is typically not wired into your consent management platform at all, so it fires whether or not the visitor agreed. That is the kind of gap a privacy complaint or regulator finds first.
Confused reporting. An old pixel that still reports conversions produces numbers in a platform dashboard that someone may still look at. A second Google Ads conversion tag can inflate conversion counts in the account you actually use. Duplicate or phantom signals lead to real budget being moved on the wrong evidence.
How do I find every legacy tag on my site?
Build an inventory from three angles: what the browser actually requests, what your GTM container contains, and what the page source says. Each one catches things the others miss, so do all three on your homepage, a key landing page, and your conversion confirmation page.
The Network tab. Open Chrome DevTools, go to the Network tab, tick Preserve log, and load the page. Filter for "collect", "analytics.js", "optimize", "gtm.js", and the domains of every ad platform you have ever used. Note every destination. Anything you cannot name a current reason for goes on the list. Complete a test conversion too, because many pixels only fire on the confirmation page.
The GTM container review. Open each container you have access to and list every tag, including paused ones. Look for Universal Analytics tag types, Optimize tags, custom HTML tags containing third party scripts, and tags named after vendors you no longer use. Check the Custom HTML tags carefully, since that is where old pixels usually hide.
The page source search. View the source and search for "UA-", "GTM-", "G-", "AW-", "OPT-", and the pixel IDs of platforms you have used. Remember that rendered source can differ from the template, so check the live page as well as the theme files. Tags injected by plugins will only show up on the live page.
Put the findings in a single sheet: what the tag is, where it lives, who owns it, and whether anything current depends on it. An audit or scan can automate a large part of this, but the sheet is what makes the removal decisions possible.
Pause before you delete, check what depends on each tag, and write down every change. Most breakage during cleanup comes from removing something that looked dead but was quietly holding up something alive, such as a variable, a trigger, or a shared snippet.
Check dependencies first. In GTM, a legacy tag may use a variable or trigger that a current tag also relies on. An old custom HTML tag may push a data layer event that a GA4 tag listens for. A hardcoded gtag.js block may contain both a UA ID and a G- ID, so deleting the whole block removes your GA4 tag with it. Read the code before removing it.
Pause in GTM, then wait. Pause the tag, publish, and watch your GA4 and ad platform data for a week or two. If nothing moves, delete it in a later version. Pausing is reversible in one click. Deleting is reversible only if your version history is clean.
Write version notes. Name each GTM version for what it does: "Paused UA tag and Optimize snippet tag" rather than "update". When something changes in the data three weeks later, that note is how you trace it.
Handle hardcoded tags through the site's normal release process. Theme and template edits should go through staging, not straight to production. Remove one family of tags at a time so any side effect has an obvious cause.
Close the loop with the vendor and the container owner. Remove old agency users from your containers, request transfer or removal of containers you do not control, and delete conversion actions in ad accounts that no longer receive valid data so they cannot feed bidding.
The point of cleaning up
Legacy tags are not dramatic. They do not throw errors or crash pages. They just keep costing a little speed, a little privacy risk, and a little trust in your numbers on every page load, indefinitely.
An afternoon with the Network tab and your container will tell you what is still firing. Removing it carefully is one of the few tracking projects that makes your site faster, safer, and easier to measure at the same time.
FAQ
Is it safe to remove the Universal Analytics tag?
Yes, as long as you remove only the UA part. Universal Analytics no longer processes data, so the tag collects nothing useful. The risk is collateral damage: a gtag.js block that contains both a UA- ID and a G- ID, or a GTM variable the UA tag shares with a GA4 tag. Remove the UA reference specifically, then confirm GA4 still receives page views and conversions in its realtime and DebugView reports.
Does an old Universal Analytics tag hurt my site?
It does not break anything visible, which is why it survives. It still downloads a script, builds hits, and sends requests on every page, adding weight and main-thread work for no return. If it is hardcoded outside your consent setup, it may also fire before a visitor has agreed to analytics cookies, which creates privacy exposure for data that nobody can even use.
How do I know if an old agency's GTM container is still on my site?
Search your live page source for "GTM-" and list every distinct container ID. Then check which of those IDs exist in accounts you can access. Any container you cannot open is one you cannot see into or control, yet it can change what runs on your site at any time. Ask the previous agency to transfer it or remove the snippet yourself.
Should I delete old conversion pixels or just pause them?
Pause first. Pausing in GTM stops the tag from firing but keeps the configuration if something turns out to depend on it. After a week or two of stable data, delete it in a new, clearly described version. For hardcoded pixels, remove them through a staging release so you can reverse the change cleanly if a report moves unexpectedly.
Can leftover Google Optimize code slow down my pages?
It can. Optimize was often installed with an anti-flicker script that hides page content until the experiment loads or a timeout passes. With Optimize sunset in September 2023, there is no experiment to wait for, so that script can hold the page hidden until its timeout expires. Removing both the Optimize snippet and the anti-flicker code is a straightforward speed improvement.