UTM tags: what they are, how to create them, what breaks

In short. UTM tags are parameters appended to a URL (?utm_source=…&utm_medium=…) that an analytics script reads on load and records as the traffic source. The server ignores them, serving the same page. Five exist: source, medium, campaign, content, term. They do not affect rankings, but they break SEO when parameterised URLs reach the index or vanish on redirect.

What a UTM tag actually is

A UTM tag is a key=value pair appended to a URL after a question mark. Multiple pairs are joined with an ampersand. The acronym comes from Urchin Tracking Module — an analytics product Google acquired in the mid-2000s. The name stuck and became a de facto industry standard, although no RFC defines UTM.

Here is a tagged link, broken down:

https://example.com/pricing?utm_source=vk&utm_medium=social&utm_campaign=autumn-sale

   https://example.com/pricing   — the page address, unchanged
   ?                             — start of the query string
   utm_source=vk                 — first pair
   &                             — pair separator
   utm_medium=social             — second pair
   &utm_campaign=autumn-sale     — third pair

The key thing to internalise: a tag is not an instruction to the server. The web server returns exactly the same page it would for a clean /pricing. No processing, no redirect, no content change — unless you wrote code that reads those parameters yourself.

What happens on the analytics side

The work is done by the tracking script on the page — Google Analytics, Yandex.Metrica or anything else. The sequence:

• The browser loads the page at the parameterised address.
• The tracking script reads the current URL from the browser (location.search) and extracts everything starting with utm_.
• Those values are sent to the analytics backend with the first hit and stored as session attributes.
• Every later action — pageviews, goals, purchases — is attributed to that source under the platform's attribution rules.

Two practical consequences follow. First: if the tracking script never loads or throws, nothing is recorded at all. Second: if the parameters disappear from the URL before the script runs — on an intermediate redirect, say — there is nothing left to record, and the visit lands in "direct" or in a referral bucket.

A tag lives exactly until the first hit. If there is a redirect between the ad click and the page load that strips the query string, you have not lost "some data" — you have lost the entire source. Check the redirect chain before the campaign launches, not after.

The five UTM parameters: source, medium, campaign, content and term

The standard set is five parameters. Formally none of them is required: analytics will happily accept a link carrying only utm_source. The practical minimum is source + medium + campaign, because without medium the report collapses into an unreadable list of platform names.

Parameter	Practical minimum	What goes in it	Example value	Common mistake
utm_source	yes	The specific platform or sender — "where exactly did they come from"	google, vk, newsletter, partner-blog	Putting a channel type (cpc) in place of a platform name
utm_medium	yes	The channel type — "how did they get here". Drawn from a short closed vocabulary	cpc, email, social, banner, referral	Free improvisation: ppc, paid, cpc-ads in one account
utm_campaign	yes	Campaign or promotion name — the field you will group the report by	autumn-sale, black-friday-2026	Free-form dates that break sorting
utm_content	no	Distinguishes variants inside one campaign: creative, banner size, link position in an email	banner-300x250, footer-link, variant-b	Duplicating campaign instead of separating variants
utm_term	no	The keyword. Historically for paid search	utm-tags, buy-hosting	Pasting an unencoded phrase with spaces

utm_source vs utm_medium — the main confusion

This distinction ruins more reports than every other mistake combined. The rule is simple:

• source answers "where?" — a proper noun. google, bing, vk, telegram, newsletter-weekly.
• medium answers "how?" — the traffic type, a category. cpc (paid click), organic, email, social, referral, banner, qr.

A sanity check: a healthy account has 5–10 distinct medium values for the entire business, and as many source values as it likes. If your medium report has thirty rows, something that belonged in source or campaign leaked into it.

The same platform easily produces different mediums: an organic post on a social network is utm_source=vk&utm_medium=social, a paid post on the same network is utm_source=vk&utm_medium=cpc. And one medium collects many sources: utm_medium=email arrives from newsletter, from trigger-abandoned-cart and from partner-digest alike.

Beyond the classic five, current Google Analytics versions understand additional parameters such as utm_id for stitching with ad platforms. The set keeps expanding, so check your platform's current documentation rather than blog posts; the base five are supported everywhere.

How to create a UTM link by hand — and what a UTM builder really does

Building one manually takes about twenty seconds and requires a few mechanical rules:

• The first parameter is separated by ?, every following one by &.
• If the URL already has parameters (/catalog?page=2), tags are appended with &, never with a second ?.
• Lowercase Latin letters, digits, hyphen and underscore only. No spaces, no non-Latin characters, no punctuation inside values.
• Anything outside that set must be percent-encoded: a space becomes %20 or +, non-Latin characters become %D0%… sequences.
• Tags go before the fragment. Correct: /page?utm_source=vk#faq. Wrong: /page#faq?utm_source=vk — in the second case the browser never sends anything after the hash to the server and it never lands in the query string.

# Bad: spaces, mixed case, a second question mark
https://example.com/catalog?page=2?utm_source=Google&utm_medium=CPC&utm_campaign=autumn 2026

# Good: one ?, then &, all lowercase
https://example.com/catalog?page=2&utm_source=google&utm_medium=cpc&utm_campaign=autumn-2026

# If a value genuinely needs non-Latin characters, encode it
https://example.com/?utm_source=yandex&utm_medium=cpc&utm_term=%D1%85%D0%BE%D1%81%D1%82%D0%B8%D0%BD%D0%B3

You can verify how the string parses on the client side straight from a terminal:

# Split a query string into parameters (python3 is available almost everywhere)
python3 - <<'EOF'
from urllib.parse import urlsplit, parse_qsl
u = "https://example.com/catalog?page=2&utm_source=google&utm_medium=cpc"
for k, v in parse_qsl(urlsplit(u).query):
    print(f"{k:15} = {v}")
EOF

# Encode a value correctly before pasting it into a link
python3 -c "from urllib.parse import quote; print(quote('autumn sale'))"

What a UTM builder does — and what it does not

A builder is a form with five fields that concatenates a string. Three things about it are genuinely useful: it will not let you forget an &, it encodes special characters correctly, and it usually offers a dropdown of allowed medium values, which keeps a team disciplined. Better ones add saved templates and history so that different people do not invent email, e-mail and mail in parallel.

What a builder does not do:

• it does not verify that a tracking script exists on the destination page;
• it does not verify that the parameters survive the redirect chain to that page;
• it does not remove parameterised duplicates from the search index;
• it does not know your internal vocabulary and will not stop a fourth spelling of the same campaign.

In other words, a builder solves syntax. Every interesting problem — vocabulary semantics and the technical behaviour of your site — remains yours.

UTM tags in Google Analytics 4: where the report lives

GA4 reads UTM parameters automatically; there is nothing to enable. The values arrive with the first hit of the session and become available as traffic-acquisition dimensions.

There are two ways to use them. The first is the ready-made acquisition report, which groups traffic by source, medium and campaign. The second, far more useful one, is adding a UTM parameter as a dimension to any other report or exploration — so you can look at conversion rate broken down by utm_content, or isolate a single campaign. Exact menu labels in analytics interfaces change periodically, so navigate by the acquisition report group and by the available dimension list rather than by a memorised click path.

Technical details that most often distort the picture:

• Session vs user scope. Campaign parameters are session-scoped. A tag encountered on the landing page defines that session. A tag encountered mid-session is a source override, with all the consequences described below.
• The script must actually run. If the tracking snippet is loaded asynchronously at the bottom of a heavy page, some users leave before it fires and their tag is never recorded.
• Auto-tagging is a separate mechanism. Ad platforms append their own click identifiers — gclid for Google Ads, yclid for Yandex Direct. These are not UTM tags; they are a direct link between the ad account and the analytics account. Both can live in the same URL simultaneously. If your traffic includes Russian-language markets, the counter on the other side of that pairing is covered in our guide to Yandex.Metrica and Webvisor.

UTM tags in Google Ads and Yandex Direct

Ad platforms give you two independent ways to pass data into analytics, and they get confused constantly.

Auto-tagging means the platform appends its own click ID and analytics pulls campaign, ad and placement details straight from the ad account. It works without UTM and carries far more detail than manual tags — but the data is only visible inside that one vendor's ecosystem.

Manual UTM tagging is what you need when the data has to travel somewhere else: a third-party analytics stack, a CRM, a cross-channel report, a spreadsheet that sits next to every other channel. Here the platforms' substitution macros help — placeholders in braces that the system replaces with real values at click time.

# Yandex Direct tracking template
?utm_source=yandex
&utm_medium=cpc
&utm_campaign={campaign_id}
&utm_content={ad_id}
&utm_term={keyword}

# Google Ads uses its own ValueTrack macro syntax, for example:
?utm_source=google&utm_medium=cpc&utm_campaign={campaignid}&utm_content={creative}

A few rules that save time:

• Keep utm_medium=cpc constant across paid search, and set utm_source to the search engine, not the ad product. The temptation to write utm_source=adwords or utm_source=direct is real, but then paid and organic traffic from the same engine split by product name instead of by traffic type, which makes them awkward to compare.
• Put the campaign identifier in utm_campaign rather than its name: you will rename the campaign eventually, and historical data will split into two rows.
• A substituted keyword can contain spaces. Check what the final URL looks like after a click on a real ad, not just the template in the interface.
• The available macro set changes over time — check the ad platform's current help before bulk-reuploading campaigns.

UTM tags in Tilda, Webflow and other site builders

From a site builder's point of view a UTM tag is just extra baggage in the URL that it must ignore while serving the right page. Essentially every popular builder does exactly that: the query string does not affect routing. So "does this builder support UTM tags" almost always answers itself — there is nothing to support.

Real problems start not with recognising tags but in three other places where the builder makes decisions on your behalf:

1. Redirects and the canonical host

A builder usually merges www and the bare domain itself, and forces HTTPS. Those are redirects, and the only question that matters is whether the parameters reach the final address. The good news: on serious platforms they do. The bad news: if your own redirect sits on top — from an old domain to a new one, for instance — it may well eat the parameters. Test the actual production link, not the platform in the abstract.

2. Internal links inside prebuilt blocks

Blocks like "promo" or "banner" are configured through the same field as external links, and it is very tempting to put UTM tags in them. That is a mistake, and the most expensive one on this list: a tag on an internal link overrides the original session source. Someone arrives from paid search, clicks a banner carrying utm_source=site&utm_medium=banner, and all subsequent activity — including the purchase — is credited to that internal banner. The ad channel zeroes out in the report.

3. Canonical tags and the sitemap

Builders normally emit rel="canonical" for you. Make sure the canonical address is served without parameters — that is precisely what protects you from duplicates. And check that parameterised URLs never reach sitemap.xml: see our walkthrough of the XML sitemap.

Never put UTM tags on internal links of your own site. Analytics platforms have dedicated mechanisms for internal navigation — click parameters, events, goals. UTM exists for inbound traffic only.

What UTM tags do not do — and how they still break SEO

Tags do not influence ranking by themselves. A crawler arriving at a tagged URL receives exactly the same HTML as at the clean one: content, headings and speed are unchanged. There is no direct ranking bonus or penalty here.

The problem is elsewhere. To a crawler, every unique parameter combination is a separate URL. Three campaigns pointing at one landing page produce four addresses with identical content. Once those addresses become known to a search engine — through someone else's blog, a social post, your sitemap, your own internal links — measurable damage begins:

• Duplicates in the index. The same text under several addresses. The engine picks a primary one itself, and its choice need not match yours.
• Diluted signals. External links and behavioural data spread across clones instead of accumulating on one URL.
• Wasted crawl budget. The crawler spends fetches re-reading identical pages. Barely noticeable on a small site; very noticeable on a large catalogue. We cover crawl mechanics in how website indexing works.
• Junk in the SERP. A user sees a URL carrying someone else's campaign tag and, after clicking, lands in someone else's statistics.

Three defences, and which engine honours which

Mechanism	Google	Yandex	What it does
rel="canonical" without parameters	honoured	honoured	Declares the preferred address. The baseline, mandatory measure for both engines
Clean-param in robots.txt	no, not supported	yes, a Yandex directive	Tells the crawler to ignore the listed parameters and merge the addresses
Disallow: /*utm*	not recommended	not recommended	Blocks crawling. The crawler never sees the canonical and cannot merge anything — the cure is worse than the disease

Always start with canonical. It is the only mechanism both engines understand, and it fixes the problem at the root: the clean, parameter-free address is declared canonical.

<!-- In the <head> of a page opened at /pricing?utm_source=vk -->
<link rel="canonical" href="https://example.com/pricing">

<!-- Check a production page with one command -->
curl -sSL 'https://example.com/pricing?utm_source=vk&utm_medium=social'   | grep -io '<link[^>]*canonical[^>]*>'

The second layer is Clean-param. This is a robots.txt directive that only Yandex understands. Google has no equivalent, and the URL Parameters tool in Search Console was retired — Google's guidance is to rely on canonical instead. The two approaches must not be blended into a single recommendation; they belong to different search engines.

# robots.txt — Yandex section
User-agent: Yandex
Clean-param: utm_source&utm_medium&utm_campaign&utm_content&utm_term&yclid&gclid&fbclid /

# Syntax: Clean-param: parameters_joined_by_ampersand [path_prefix]
# The trailing path is optional; without it the rule applies site-wide.
# The directive has a length limit — long lists are split
# across several consecutive Clean-param lines.

A live example sits on this very domain: the robots.txt of enterno.io carries a Clean-param line covering the full set of advertising parameters, including utm_*, gclid, yclid and fbclid. The rest of the file's directives are covered in our robots.txt guide.

Do not block parameterised URLs with Disallow. Blocking a crawl does not remove a page from the index — it merely stops the crawler from reading it. The crawler will never see your canonical, will never learn it is a duplicate, and may well keep the URL in results without a description. The correct pair is open crawling plus a correct canonical, with Clean-param added for Yandex.

Common UTM mistakes: case, internal links, redirects

Case: Google and google are two different strings

Tag values are transmitted verbatim, character for character. Some analytics platforms lowercase source and medium when building reports, others preserve the original spelling, and you cannot know in advance which report you will open six months from now. The outcome is predictable: the table shows Google and google as two rows with half the traffic each, and period-over-period comparison falls apart.

The rule needs no exceptions: lowercase everything, always. That applies to values and to parameter names alike — many platforms will not recognise UTM_Source as a tag at all.

Tags on internal links reset the original source

Covered above for site builders, but the mistake appears in hand-built sites too: a tag in the abandoned-cart email, a tag on a banner inside the account area, a tag on the "proceed to checkout" button. Every one of those is a mid-session source override. Most analytics platforms treat the appearance of a new set of campaign parameters as the start of a new session with a new source: the old source closes, and the conversion goes to an internal button.

The symptom that catches it: the acquisition report shows an implausible number of sessions from your own domain or from a medium like banner/site, while paid channels convert noticeably worse than the ad platforms report.

Tags in canonical, sitemap and hreflang

Three places a parameterised URL must never appear. A canonical carrying a tag declares the tagged address canonical — you are personally asking the engine to index an advertising clone. The same goes for the sitemap: it means "these are the addresses I consider correct". If your sitemap generator builds URLs from logs or from internal links, tags leak in easily.

Losing tags on a redirect

The most technical and most frustrating failure: the link is tagged correctly and nothing arrives in analytics. The cause is a redirect along the way that returns a Location without the query string. The classic is a web server config that substitutes only the path:

# nginx — tags are lost: $uri does not include the query string
location /old { return 301 https://example.com$uri; }

# nginx — tags survive: $request_uri includes path AND parameters
location /old { return 301 https://example.com$request_uri; }

# Apache mod_rewrite — if the substitution contains its own '?',
# the original query string is discarded. The QSA flag brings it back:
RewriteRule ^old/(.*)$ /new/$1?lang=en [R=301,L,QSA]

The danger is that everything looks fine: the user lands on the right page and no error appears. The difference is visible only in the address bar and in the report. A related variant is link shorteners and tracking domains that add an extra hop — every hop is another chance to drop parameters. Full chain analysis is in how to check redirects.

An inconsistent vocabulary

After a year without a shared vocabulary, the report contains cpc, ppc, paid, cpc_ads and context — all meaning the same thing. The only cure is organisational: one document listing allowed medium values, one builder with a dropdown, a link review before every campaign launch.

Tags and caching

One more non-obvious side effect. CDN caches and server-side page caches are usually keyed on the full URL including the query string. That means every unique tag combination is a separate cache entry and a miss on first request. A mass mailing with a per-recipient tag can both bloat the cache and spike backend load.

The fix is cache key normalisation: exclude utm_* from the key so the page is served from the shared cache. This does not affect tracking — the script reads the URL from the browser, not from the server response, so the tag is still recorded. Caching headers on a production page are easy to inspect with the HTTP header checker.

How to check your UTM tags

Run the checks from mechanics to consequences. The first three belong before a campaign launch, the last two are recurring hygiene.

1. Do tags survive the redirects

The critical check. Take a real tagged link and see what is left at the end of the chain:

# Walk the whole chain, print the final URL and the redirect count
curl -sSIL 'http://example.com/pricing?utm_source=vk&utm_medium=social'   -o /dev/null   -w 'final=%{url_effective}
redirects=%{num_redirects}
code=%{http_code}
'

# Show every hop: status lines and Location headers
curl -sSIL 'http://example.com/pricing?utm_source=vk&utm_medium=social'   | grep -iE '^(HTTP/|location:)'

The final= line must contain all of your parameters. If it does not, a redirect along the way is stripping the query string, and the fix belongs in the server config, not in the link. The same chain, with every intermediate hop laid out, is shown by the redirect checker.

2. What canonical does a tagged page return

# canonical must point at the clean address WITHOUT utm parameters
curl -sSL 'https://example.com/pricing?utm_source=vk'   | grep -io '<link[^>]*canonical[^>]*>'

The expected result is a link to https://example.com/pricing. If tags appear inside the canonical, fix the page template: the canonical URL is most likely being assembled from the current request URL in full.

3. Is robots.txt correct

Verify that Clean-param is present in the Yandex section and that you have not accidentally blocked parameterised URLs with Disallow. Directive syntax and scope are analysed by the robots.txt checker.

4. Have tagged URLs reached the index

In Google, a search operator does the job: a query like site:example.com inurl:utm_ reveals indexed parameterised addresses. In Yandex, open the indexed-pages section of Yandex Webmaster and filter the list by the substring utm. Any hits mean an external or internal link carrying a tag exists somewhere and the canonical did not override it.

5. General duplicate hygiene

Once a quarter it is worth crawling the whole site: an SEO audit surfaces duplicate titles and descriptions, incorrect canonicals and pages reachable at several addresses at once — and parameterised clones show up in exactly those reports.

Frequently asked questions

Do UTM tags affect SEO?

Not directly. The mere presence of parameters in a URL neither improves nor harms rankings: the engine receives identical content. Indirectly, yes — if tagged addresses became known to the crawler and spawned duplicates. Page uniqueness in the index and signal consolidation both suffer. The fix is a parameter-free canonical, plus the Clean-param directive for Yandex.

Should I block UTM parameters in robots.txt?

Not with Disallow — that is actively harmful, because the crawler can no longer read the page and see the canonical. For Yandex the right tool is Clean-param, which permits crawling while instructing the engine to merge addresses. For Google nothing is needed in robots.txt at all; canonical handles it.

What is the difference between utm_source and utm_medium?

source is the name of a specific platform ("where"): google, vk, newsletter. medium is the channel type ("how"): cpc, social, email. A company should have a handful of medium values and any number of source values. If your medium report has dozens of rows, source or campaign content has leaked into it.

Do I have to fill in all five parameters?

Formally none is mandatory — analytics accepts a link with only utm_source. The practical minimum is source, medium and campaign. content and term matter when there is something to distinguish inside one campaign: different creatives, different link positions in an email, different keywords.

Why did one source split into two rows in my report?

Three usual causes, in descending order of frequency: differing case (Google vs google), differing spelling in the vocabulary (email vs e-mail), and a stray space or character that got into the value while copying the link. All three are fixable only at the input stage — analytics does not rewrite already recorded data retroactively.

Are UTM tags lost when redirecting from http to https?

It depends on how the redirect is configured. A correct config substitutes the full request including the query string and the parameters arrive intact. An incorrect one substitutes the path only, and tags vanish silently, without an error. One command settles it: curl -sSIL … -w '%{url_effective}' — every parameter must still be present in the final URL.

Pre-launch checklist

• All tag values are lowercase Latin, with no spaces or non-Latin characters.
• source, medium and campaign are filled in at minimum; medium comes from the shared vocabulary.
• The first parameter is separated by ?, the rest by &; if the page already has parameters, tags are appended with &.
• Tags sit before the # fragment, not after it.
• The production link is verified with curl -sSIL: parameters survive to the end of the redirect chain.
• The destination page carries a tracking script and it fires before users leave.
• The tagged page's rel="canonical" points at the clean, parameter-free address.
• The Yandex section of robots.txt contains Clean-param listing the advertising parameters.
• Parameterised URLs never reach sitemap.xml.
• No internal link on the site carries UTM tags.
• The CDN or server cache key ignores utm_*.
• Tagged URLs are confirmed absent from the index: site:… inurl:utm_ and the indexed-pages report in Yandex Webmaster.