UTM stripping and clean URLs
UTM parameters do their job at the moment of capture; leaving them in the visible URL invites messy shares, duplicate-looking URLs, and accidental re-tagging. This page explains stripping UTMs with history.replaceState after your analytics has read them, and how to keep canonical URLs clean without losing attribution.
Why strip UTMs
UTM parameters are for the inbound click. Once captured they add no value in the address bar and cause problems: visitors copy and re-share the tagged URL (creating fake campaign traffic and self-referrals), and search engines may treat ?utm_source variants as distinct URLs.
A clean canonical tag mitigates the indexing side, but removing the parameters from the visible URL after capture is the more complete fix.
How to strip after capture
Read the parameters with your analytics first, then rewrite the URL without them using the History API so the page does not reload:
const url = new URL(window.location.href); ['utm_source','utm_medium','utm_campaign','utm_content','utm_term'].forEach(p => url.searchParams.delete(p)); history.replaceState(null, '', url.toString());
This keeps the page, scroll position, and analytics intact while presenting a clean URL.
Canonical and clean URLs
Pair stripping with a canonical link element that points at the parameter-free URL. Even if a tagged URL is linked externally, the canonical tells search engines which version to index, avoiding duplicate-content dilution from infinite UTM variants.
How it appears in analytics and logs
If UTM-laden URLs get shared or indexed, you see self-referrals and inflated 'campaign' visits from people who never came through the campaign. Stripping after capture prevents that contamination.
Diagnostic use case
Remove UTM parameters from the address bar after they are recorded, so visitors who copy the URL share a clean link and search engines see a single canonical URL.
What WebmasterID can help detect
WebmasterID records the campaign server-side at the first request, so stripping the parameters client-side afterward is safe — the attribution is already captured before the URL is cleaned.
Common mistakes
- Stripping the parameters before analytics has read them, losing the attribution.
- Forcing a full navigation instead of using history.replaceState, causing a reload.
- Omitting a canonical tag, so UTM variants get indexed as separate pages.
- Stripping on a redirect hop where a later step still needs the parameters.
Privacy and accuracy notes
Stripping changes only the displayed URL; it does not touch visitor identity. Ensure your analytics has already recorded the campaign before removing the parameters, and never store personal data in them in the first place.
Frequently asked questions
- Does stripping UTMs hurt attribution?
- No, as long as your analytics reads the parameters before you remove them. The campaign is recorded at capture; the visible URL is cosmetic after that.
Related pages
- UTM and analytics view filters
Analytics filters (internal traffic, developer traffic, bot exclusion, source overrides) can quietly change how UTM-tagged visits are reported. This page explains the safe ways to filter without dropping legitimate campaign data, and the filter mistakes that make UTM numbers look wrong.
- The internal-link UTM mistake
Tagging links between pages of your own site is one of the most damaging UTM mistakes: a UTM on an internal click can start a new session and overwrite the original campaign source. This page explains the mechanism and what to do instead.
- UTM parameters in redirects
Redirects are where UTM attribution quietly dies. A 301/302 or a link shortener that does not forward the query string strips your tags before the visitor reaches the landing page. This page explains how to preserve UTM parameters through redirects, shorteners, and vanity URLs.
- Privacy-first analytics
Capture campaign attribution server-side, then keep URLs clean.
Sources and verification notes
- MDN — History.replaceState()API used to rewrite the URL without a reload.
- Google Search Central — Consolidate duplicate URLs (canonical)Canonicalization for parameterized URL variants.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.