UTM tags for SEO specialists: where to use them, where not to, and how to read them in Metrica and GA4

SEO specialists rarely run ads, so UTM tags look like someone else's job. In practice you run into them all the time: tagging links in a newsletter or a channel, untangling a client's messy analytics, spotting parameterised URLs in the webmaster consoles. And some of the most visible damage done with UTM tags comes from the SEO side, when they get put on a site's internal links. This article covers where tags are worth using, where they must not go, how to design a naming scheme that both Yandex Metrica (the analytics tool most Russian sites run) and Google Analytics 4 understand, and how to read the results in each. Everything taken from the help pages was checked on 15 October 2026.

What a UTM tag is and which fields are required

A UTM tag is a set of parameters appended to a link after the question mark. There are five classic parameters:

The two systems define "required" differently. Google Analytics Help on collecting campaign data with custom URLs (support.google.com, checked 15 October 2026) says you should always use utm_source, utm_medium and utm_campaign; missing parameters show up in reports as (not set). The same page lists extra parameters: utm_id for a campaign ID, utm_source_platform, and utm_creative_format and utm_marketing_tactic, which GA4 does not currently report.

Yandex Metrica's help page on how it processes tags (checked 15 October 2026) puts it another way. utm_source is required for traffic from social networks and ad platforms other than Yandex Direct, which Metrica recognises on its own. utm_medium is required for QR codes, social networks, messengers, email and recommendation platforms. Tags are only read correctly if the site uses UTF-8.

One rule is shared: tag values are case-sensitive. Google's help gives the example that utm_source=google and utm_source=Google are different sources. Metrica's help makes the same point with Vkontakte and vkontakte. One capital letter in a newsletter splits a campaign into two report rows.

Where an SEO specialist needs tags

Start with where you do not. You cannot tag organic results: the search engine builds those links, and both analytics systems identify search visits by the referrer. Your main channel needs no tags at all.

Tags are for links you place yourself and want to separate from everything else:

• Email newsletters. Metrica's help says visits from email are identified only by UTM, Openstat and from tags. Without a tag, a click from an email easily ends up as direct traffic.
• Posts in your own Telegram channel, on VK and other social networks, if you use them to promote articles.
• QR codes on printed material. Metrica identifies QR-code visits by UTM tags.
• The website link in a Yandex Business listing or a Google Business Profile. This is our practice, not a help-page requirement: a tag separates visits from the map listing from visits from ordinary results, so you can show the client the maps contribution on its own.
• Links in PDF checklists, slide decks and partner materials that travel beyond your control.
• Paid placements: reviews, round-ups, articles in niche media. The tag shows how many people came from a given placement, and utm_content tells you which of the links inside it they clicked.

Where tags must not go

The main ban is on internal links, the links from one page of your site to another. People tag a header banner or a "read next" block to count clicks and get the opposite of what they wanted. Two documented rules explain why.

Metrica reads a tag only from the first pageview of a visit. Its help gives an example: someone arrives from a browser bookmark, leaves, and within 30 minutes comes back through a tagged link in a newsletter, and the whole visit is recorded as direct. An internal tag in the middle of a visit is simply ignored, so it counts no banner clicks. In GA4 the session's attribution is carried by the session_start event that opens it (GA4 Help on sessions, checked 15 October 2026), so an internal tag mid-session does not change the session's source either.

The damage arrives later. People copy the tagged URL from the address bar, send it to a colleague, bookmark it. Every later visit that starts on that URL is credited to your banner's "campaign", although the person came directly or from a messenger. GA4 adds its non-direct last-click model for sessions on top: in the help page's example, someone arrives from organic search and returns directly 68 days later, and the second session is also credited to organic. A fake internal campaign can absorb later direct visits the same way.

Clicks on page elements are what goals and events are for: a goal in Metrica, an event in GA4. You get the click count, your sources stay clean, and you do not generate parameterised URLs for crawlers to find.

A few more places tags are better left out:

• SEO links on other sites, such as guest posts. In our practice these are better left untagged: the visits already show up in the referring-sites report, and the link signal goes to a parameterised URL the search engine then has to fold into the clean one. Paid placements, where counting visits matters, are the exception, and there a tag earns its place.
• Yandex Direct ads. Metrica recognises them by Direct's own yclid parameter, and utm_source is not required.
• URLs in your sitemap, in rel="canonical" and in hreflang attributes. These must carry the clean URL you want indexed.

Tags and indexing: duplicate URLs

Technically, every tagged URL is a separate page. When crawlers find such links, they learn about dozens of variants of one URL. The two engines handle this differently.

Yandex's help page on the Clean-param directive (checked 15 October 2026) says analytics and tracking parameters that do not change page content may be removed automatically if its algorithms judge them insignificant. The examples listed are ysclid, yrclid, utm_source, utm_medium, utm_term, utm_content, utm_campaign, utm_media, utm_group, utm_expid and utm_referrer. Yandex Webmaster marks such URLs as excluded by Clean-param, and the help page asks for nothing extra in robots.txt. "May" leaves the call to the algorithm, though, so on a site with many tagged links an explicit Clean-param rule listing the tags does no harm.

Google does not support Clean-param. For Google, parameterised duplicates are consolidated with a rel="canonical" pointing at the clean URL. How both mechanisms work, and why blocking tagged URLs with Disallow is a bad idea, is covered in detail in our article on robots.txt and noindex.

Tags do not fragment page reports in analytics. Metrica keeps tags out of its URL parameters report and shows them in dedicated reports instead. GA4 strips UTM parameters from the "Landing page + query string" and "Page path + query string" dimensions; they only appear in the full Page location.

A naming scheme both systems understand

A tag is only useful if its values can still be grouped six months later. That takes a scheme written down before the first link:

• Lowercase Latin letters only, with underscores instead of spaces. Both systems are case-sensitive, and Metrica also warns against stray characters such as %2B.
• utm_source names the platform: telegram, vk, mailchimp, yandex_business. Not the topic, not a person.
• utm_medium comes from a closed list agreed once. Free typing here is what breaks channels.
• utm_campaign starts with year and month: 2026-10_audit_checklist. Campaigns with the same name in different years then never merge.
• utm_content describes where the link sits: link_top, button, ps.

The subtle part is utm_medium, because Metrica and GA4 use different dictionaries. Metrica lists recommended values on its tag help page; GA4 documents its default channel rules (Default channel group help, checked 15 October 2026):

For social networks the values social, social-network, social-media, sm, social network and social media match word for word in both lists. The trouble starts with messengers and QR codes. A Telegram channel post tagged utm_medium=messenger lands under messengers in Metrica, but GA4 has no rule for that value, so the visit will most likely end up in Unassigned unless the source is on Google's list of social sites. With utm_medium=social it flips: Organic Social in GA4, and social networks rather than messengers in Metrica.

Make the decision once and write it down. If Metrica is the project's main system, use its dictionary and build a custom channel group in GA4: Google's default channel group cannot be edited, but a property's primary channel group can. Avoid the value ai-assistant entirely: GA4 uses it to define its AI Assistant channel, which collects visits from ChatGPT, Gemini and similar services.

Keep every tagged link in a shared sheet: date, full URL, parameter values, where the link was placed, who created it. If your content plan has a field for promotion channels, the tagged links can be generated straight from the plan row; how that row is structured is covered in our article on a quarterly content plan.

Reading tags in Yandex Metrica

Tagged traffic shows up in two places in Metrica. The UTM tags report in the Tags group shows parameter values as a tree or a flat list, in the order of the groupings you choose. The Sources summary report shows the same visits already sorted into source types: email, messengers, social networks, ad platforms.

Keep three rules from the help pages in mind when reading them:

• A tag is read only from the first pageview of a visit.
• A visit ends after 30 minutes of inactivity; the timeout can be set anywhere from 30 to 360 minutes in the tag settings. The first click from an ad platform always starts a separate visit.
• If a tab stayed open past the timeout, a new visit starts when activity resumes, with "internal traffic" as its source.

Check the attribution model as well. On 20 May 2026 Metrica and Yandex Direct switched off the First click, Last significant click, Last Yandex Direct click and Last Yandex Direct click cross-device models, and saved reports using them were moved to current models automatically (Metrica help on attribution models, checked 15 October 2026). What remains is Last click, First click cross-device, Last significant click cross-device and automatic attribution, with a 90-day attribution window. According to Metrica's troubleshooting page for tags, reports use Last click by default.

For judging a newsletter the difference is large. Someone reads the email, clicks through, buys nothing, comes back three days later from a bookmark and places an order. Under Last click the order goes to direct traffic. Under Last significant click cross-device, a direct visit counts as insignificant and the order is credited to the newsletter. If a report does not say which model it uses, its channel figures cannot be compared with last month's.

Reading tags in Google Analytics 4

In GA4, tagged traffic is read in the Traffic acquisition report with the Session source / medium, Session source, Session medium and Session campaign dimensions. GA4 assigns its default channel using the rules on the Default channel group help page. A few are worth knowing by heart:

• Email: email, e-mail, e_mail or e mail as source or medium.
• Organic Social: a source on Google's list of social sites, or a medium among social, social-network, social-media, sm, social network, social media.
• Paid channels: the medium matches the regex ^(.*cp.*|ppc|retargeting|paid.*)$, and the source decides which one (search, social, video or Paid Other).
• Referral: medium referral, app or link.
• Unassigned: no rule matched.

Look closely at that paid-channel regex. Any utm_medium containing "cp" counts as paid. Invent a medium like cpost for an unpaid post and its visits land in paid traffic.

Unassigned in a report nearly always means a non-standard utm_medium. Open Session source / medium, filter to Unassigned and see which pairs are there: usually messenger, qr, post or typos. The fix belongs in the scheme, not the report.

GA4 attributes sessions by non-direct last click, as described above: a direct visit inherits the previous session's source within the lookback window, 90 days by default. That is one reason GA4 usually shows less direct traffic than Metrica reports using Last click.

Why Metrica and GA4 disagree

Put both systems on one site, compare channels for a month, and the figures will not match. That is normal, and there are several reasons:

• Different default attribution: Last click in Metrica reports, non-direct last click for GA4 sessions.
• Different channel dictionaries. Messengers and QR codes get their own groups in Metrica, while in GA4, without a custom channel group, they often fall into Unassigned.
• Bot filtering. Metrica runs a bot-filtering system, including bots that pose as people and are detected by behaviour, and its help names this as a reason for discrepancies with other systems.
• Blockers and cookie consent. Each tag is blocked at a different rate, so each loses a different share of visits.
• Different visit and session timeouts, if someone changed the setting in only one system.

For client reporting this leads to one rule: one system is the source of truth for channels, and the other is used to check it. Which one depends on where most of the project's traffic comes from; more on that in our article on SEO reporting for clients. Do not switch systems from month to month. A client will live with a bad month, but a change in counting method undermines trust in every figure that follows.

Common mistakes and a check before you send

The same tagging mistakes turn up on project after project:

• Mixed case within one campaign: Telegram in one post, telegram in the next.
• Non-Latin characters and spaces in values. They get encoded into long sequences that are hard to read in reports and easy to break when copied.
• A second question mark. If the URL already has parameters, the tag is added with &, or some parameters are lost.
• A redirect that drops the parameters. Metrica's help names lost tags on redirect as one cause of empty reports. Check every redirect on the path: http to https, www to non-www, adding a trailing slash.
• Tags copied along with an ad from one ad platform to another. Metrica then attributes that traffic to the wrong platform.
• Tagged internal links, covered above.

The check takes two minutes. Open the link in a private browser window and look at the address bar after all redirects: the parameters should still be there. Then find your visit in the GA4 Realtime report and, after a short delay, in Metrica's UTM tags report. If the visit is there but in the wrong channel, fix the utm_medium value before real people start clicking.

Frequently asked questions

Do I need UTM tags to see traffic from search?

No. The search engine builds the links in its results, so you cannot tag them. Metrica and GA4 identify search visits by the referrer and assign them to search engines on their own.

Can I tag internal links to count banner clicks?

Better not. Metrica reads a tag only from a visit's first pageview and GA4 takes the source from the start of a session, so you will not count clicks that way, and copied tagged URLs pollute your sources. Set up a goal in Metrica and an event in GA4 instead.

Which tag parameters are required?

GA4 needs utm_source, utm_medium and utm_campaign, or reports show (not set). Metrica needs utm_source for social networks and ads other than Yandex Direct, and utm_medium for email, messengers, social networks, QR codes and recommendation platforms.

Will tagged URLs hurt my site's indexing?

Usually not, if the duplicates are consolidated. Yandex may drop utm_* parameters by itself, and an explicit Clean-param rule makes sure of it. For Google, the page needs a rel="canonical" pointing at the URL without parameters.

Why did visits from a tagged link land in Unassigned in GA4?

The utm_medium value matched none of the default channel rules. Most often it is messenger, qr or a typo. Switch to a standard value or define it in a custom channel group.

Does case matter in tag values?

Yes, in both Metrica and GA4. utm_source=Telegram and utm_source=telegram become separate report rows. The simplest fix is to agree on lowercase for every value.