Why Yandex Metrica isn't showing website traffic

No data doesn't always mean no traffic

An empty chart in Yandex Metrica doesn't prove that nobody is visiting the site. Metrica records a visit only when the visitor's browser has loaded and executed the tag code and then sent a request to the analytics server. A user can open a page, submit a form or click an ad but never appear in the report because of a blocked script, a browser error or a filter in the settings.

First, separate the absence of real clicks from a data collection failure. You shouldn't compare the overall chart but rather the same period, a specific URL and a source. For example, a link from an ad, a stream description, an email or a social media post.

How to tell no traffic from no data

An ad platform usually shows clicks on an ad, while a server log shows requests to the site. To check, open the server access log and find the landing page for the relevant time range. In Nginx logs this might be a request like: grep "GET /promo" /var/log/nginx/access.log. If the path changes because of UTM tags, search for the URL itself without parameters or use part of the landing page address.

A click in an ad platform doesn't equal a page load: the user may have closed the tab, the connection may have dropped, or the link may lead to an unavailable URL. A server log also doesn't equal a real visit, because bots, link previews and technical checks end up in it. But if there are clicks in the logs and none in Metrica, the problem is most likely in the tag or its settings.

What discrepancies between ads, logs and Metrica mean

If there are clicks in the ad platform but no requests to the landing page in the logs, check the final URL, redirects, domain availability and tracker settings. If there are entries in access.log but the browser isn't sending requests to mc.yandex.ru, the tag isn't starting or is blocked. If requests to mc.yandex.ru are going out but the report is empty, check the tag number, filters, period and domain settings.

For an accurate cross-check, use a short interval and a single source. Compare the time, page path, response status, IP address and User-Agent only within the data processing rules adopted on the project. Manual cross-checking is inconvenient with high traffic volumes: it helps find a breakdown but doesn't replace ongoing monitoring.

The tag code is missing on some pages

The tag may be on the home page but missing on a landing page, in the blog, catalog, account area, mobile template or on a subdomain. This error often appears after a site migration, creating a separate promo page or updating a CMS theme. A visitor opens the site, but on that specific URL there's simply nothing for Metrica to run.

Open the page source code via your browser's view source and look for the mc.yandex.ru fragment or the tag number. Check the addresses that links from ads and social media actually lead to, not just the home page. The downside of this check is that it's easy to miss rare pages and scenarios manually, such as a post-payment screen or a form in the mobile version.

A different tag number is installed on the site

The code may work correctly but send data to an old, test or someone else's tag. This happens after copying a template, changing contractors, migrating to a new domain or running several versions of the site at once. Requests are visible in the browser, but the channel or site owner is looking at a different tag's report.

Find the identifier in the page code and compare it with the number in your Metrica account. In the browser console you can run: document.documentElement.innerHTML.includes("mc.yandex.ru"). It will show whether the Metrica address appears in the HTML but won't confirm that the script executed. For that you need to check network requests.

How to check Metrica loading in the browser

Open the page in a browser without ad blockers, press F12, go to the Network tab and refresh the page. In the filter field, type mc.yandex.ru. If everything works, requests to the script loading address and data collection requests should appear, usually containing the path metrika/tag.js or watch with the tag number.

Then open the Console tab and check for errors. Useful signs of a problem: messages like "Refused to load the script", "blocked by client", "Content Security Policy" or JavaScript errors that occur before the tag starts. Checking in a single browser has a downside: an extension, browser version or network settings of a specific user may produce a different result.

Ad blockers hide some visits

Ad blocking extensions, private DNS services, built-in browser protection and antiviruses can stop requests to analytics. In Network this often shows up as blocked by client. The page still opens normally, the server records the request, but Metrica doesn't receive information about the visit.

Compare the page in a regular browser window without extensions and in a profile with a blocker. This test will show the fact of blocking but won't let you accurately estimate the share of lost visits: protection settings vary across audiences. Attempts to disguise analytics requests complicate maintenance and may conflict with the site's security policies.

Content Security Policy blocks requests to Metrica

The Content Security Policy header restricts the sources from which a page can load scripts and images and make network requests. After connecting a CDN, proxy or strengthening site protection, the site may start blocking requests to Metrica. The browser console will show a CSP violation message indicating the blocked mc.yandex.ru address.

The rule should be extended precisely rather than disabling CSP entirely. Example directive on one line: script-src 'self' https://mc.yandex.ru; connect-src 'self' https://mc.yandex.ru; img-src 'self' data: https://mc.yandex.ru;

This line can't be blindly substituted into an existing header: it must be merged with the site's already required sources. If the tag code is inserted directly into the HTML, an inline script may also require separate permission via nonce or hash. Adding unsafe-inline is simpler, but its downside is weaker protection against third-party JavaScript injection.

Cookie consent doesn't let the tag start

On sites with a consent banner, Metrica sometimes starts only after a button is clicked. A bug in the banner logic can leave the tag off after consent, start it only on the first page or fail to save the user's choice. As a result, some visits are lost, especially on short visits from landing pages.

Check the scenarios for first entry, consent, refusal, repeat visit, mobile browser and private mode. Starting analytics before the user's choice may increase the data volume, but this option has a legal and reputational downside: the data processing procedure must comply with the requirements applicable to your project.

Tag filters exclude the visits you need

Metrica settings may have filters by IP addresses, domains, URLs, parameters or technical traffic. They're usually added to remove team visits and test clicks. After changing offices, VPN, corporate network or URL structure, such a filter may start excluding more than just internal visits.

Review active filters and check the purpose of each rule. For diagnostics, you can temporarily change one filter and repeat a test click. The downside of disabling a filter is that visits from employees, developers and automated tests will end up in the statistics, so changes are best documented separately.

The wrong period, report or time zone is open

Sometimes the data is already there, but a different tag, too narrow a period, date comparison mode or an unsuitable time zone is selected in the account. With a small number of visits, a difference of a few hours can completely change the picture for a specific day. You shouldn't evaluate the tag's performance based only on a few minutes after a click.

Turn off period comparison, open a wider range and check the date of the test visit. Then go to the pages report and find the exact landing page path. A wide period is convenient for finding data, but its downside is that on the overall chart it's harder to notice the moment when the tag stopped working after a site update.

Redirects and domains change the visitor's path

A click may go through a link shortener, tracker, HTTP version of the site, www domain, mobile subdomain and only then reach the final landing page. If a redirect is misconfigured, the page responds slowly or the visitor is sent to another domain, the correct site's tag may not load. This is especially important for links from stream descriptions and ad campaigns.

Check the chain with the command curl -I -L "https://example.com/promo" and look at the statuses with redirect addresses. The command will show server-side redirects but won't replace a browser test: curl won't see JavaScript redirects or blocking by extensions. Shortened links are convenient in posts, but the extra hop complicates diagnostics.

SPA doesn't send pageviews on internal navigation

On a single-page site, navigating between sections often happens without a full reload. A user opens a pricing plan, product card, form or thank-you page, but Metrica records only the first screen. Visits may be in the report, but entry pages, page depth and conversions look incomplete.

Check in Network whether a new request to Metrica appears after a route change within the app. Test navigation with browser buttons, modal windows, language switching and dynamic URLs. Automatic pageview sending via the router is convenient, but its downside is that a logic error can easily produce duplicate pageviews and inflated visit depth.

Goals don't fire despite visits

An empty goal report doesn't mean there's no traffic on the site. Visits may be collected normally, but form submission, button click, purchase or navigation to a thank-you page isn't recorded. Causes include a changed CSS selector, an event before the tag initializes, an AJAX form without result handling or a different Metrica number on the page.

Perform the action manually and watch Network at the same time: a request related to sending the event should appear after it. A click goal is quick to set up, but it has a downside — it records the click, not a successful form submission. For leads, it's more useful to track the start of filling out, an error and the confirmed result separately.

Five-minute diagnostic checklist

1. Open the link that should be receiving traffic in a regular browser without blockers.
2. In DevTools, open Network, refresh the page and filter requests by mc.yandex.ru.
3. In the Console tab, check for JavaScript errors, CSP and the blocked by client message.
4. Compare the tag number in the page code with the report number in your Metrica account.
5. Check access.log for a request to the relevant URL during the test, for example grep "GET /promo" /var/log/nginx/access.log.
6. Match the server log against clicks in the ad platform for a single link and a single period.
7. Review the filters, selected dates, time zone, subdomains and the cookie consent scenario.
8. For an SPA, perform an internal navigation and make sure a new request is sent after the route change.