Пропала половина трафика после смены хостинга: ищем причину

MAATRIX

Утром после переноса сайта на новый хостинг вы открываете отчёт в Яндекс.Метрике или GA4 — и вместо привычных цифр видите провал. Сайт при этом открывается нормально, друзья и коллеги заходят без проблем, в панели хостинга нагрузка в норме. Прежде чем писать в поддержку регистратора или бить тревогу из-за «потерянных клиентов», разберитесь, что именно пропало: реальные посетители или только их запись в счётчике. Это разные проблемы, и чинятся они по-разному.

Первая паника: сайт работает, а трафик как будто пропал

Первая реакция в такой ситуации всегда одна: «мы потеряли позиции в поиске» или «хостинг что-то сломал». Логика понятная — вы ничего не меняли в контенте, ссылки те же, дизайн тот же, но график в аналитике за день до переезда и после него выглядит как обрыв. При этом:

• сайт открывается по домену с любого устройства, которое вы проверили;
• в панели нового хостинга видно нормальное количество запросов к серверу;
• поисковики продолжают присылать переходы (это видно по прямым заходам с известных ключевых слов, которые кто-то вводит и переходит).

Это классический признак того, что упал не трафик, а измерение трафика. Счётчик аналитики — это JavaScript-код, который выполняется в браузере посетителя и отправляет событие на сервер Яндекса или Google. Если этот код физически не выполнился или выполнился, но отправил данные не туда — в отчёте будет дыра, даже если человек прекрасно долистал страницу до конца.

Разница принципиальная: если трафик реально упал, теряются деньги и клиенты, и чинить нужно позиции в поиске, ссылки, репутацию домена. Если упало только измерение — сайт как работал, так и работает, ничего страшного не произошло, просто вы временно ослепли. В 2026 году при переезде на VPS именно вторая причина встречается значительно чаще первой, потому что перенос кода счётчика — это ручная операция, которую легко забыть.

Причина первая: код счётчика потерялся при переносе

Самая частая находка. Код Яндекс.Метрики или GA4 почти никогда не хранится в базе данных — это несколько строк JavaScript, вставленные вручную в шаблон темы, в футер CMS или через плагин вроде «Yandex Metrika for WordPress». Когда перенос делается штатными средствами — экспорт базы данных, копирование файлов wp-content, bitrix, data — специфическая правка шаблона, сделанная когда-то руками через админку или FTP, может не попасть в бэкап, если:

• счётчик был вставлен через визуальный редактор темы (хранится в кастомных полях, которые бэкап-плагин не считает частью «контента»);
• код добавляли через отдельный плагин, который не перенесли вместе с сайтом (типично для WordPress: плагин остался в списке «неактивных» или вовсе не установлен на новом хостинге);
• правки вносили напрямую в файл темы (header.php, footer.php), а при переносе взяли «чистую» версию темы из репозитория, а не с продакшена;
• в конструкторе сайта (Tilda, Craftum и подобные) счётчик прописан в настройках проекта, а не в самом экспорте HTML — и при переносе на VPS этот экспорт залили как статику, без последующей донастройки счётчика на новом движке.

Проверяется это за минуту: открываете сайт в браузере, жмёте Ctrl+U (просмотр исходного кода страницы) и ищете mc.yandex.ru/metrika или googletagmanager.com/gtag. Быстрее — прямо из терминала:

curl -s https://example.ru/ | grep -oE "id=[0-9]{7,9}"
curl -s https://example.ru/ | grep -i "gtag\|googletagmanager\|mc.yandex"

Если команда ничего не вернула — код счётчика отсутствует физически, и это стопроцентная причина провала в отчётах. Чинится просто: возьмите номер счётчика из старого бэкапа или из личного кабинета Метрики/Google Analytics и вставьте код заново в шаблон, желательно через официальный плагин, а не руками в файл темы — так он переживёт следующий перенос.

Причина вторая: подросла задержка загрузки, и вырос процент отказов

Смена хостинга почти всегда меняет физическое расположение сервера и его IP. Если переезд был, например, с общего хостинга в России на VPS в другом регионе (или наоборот), для части аудитории вырастет время до первого байта (TTFB) и общее время загрузки страницы. Это не катастрофа сама по себе, но у неё есть побочный эффект именно для аналитики.

Код счётчика обычно грузится асинхронно и не в первую очередь — браузер сначала выполняет критичный рендеринг, а скрипты аналитики могут стоять в очереди дальше, особенно если подключены не через async/defer, а обычным тегом в середине <body>. Если пользователь на медленном мобильном интернете открывает страницу, видит, что она грузится долго, и закрывает вкладку до того, как скрипт счётчика успел выполниться и отправить хит, — визит просто не попадёт в статистику. Чем выше стала задержка после переезда, тем больше таких «недосчитанных» отказов.

Отдельно от IP на скорость может влиять сама конфигурация нового сервера: если на старом общем хостинге стоял настроенный годами Varnish или встроенное кэширование, а на VPS вы пока не подняли аналог, каждая страница генерируется заново при каждом запросе. Проверить разницу можно сразу:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s, Total: %{time_total}s\n" https://example.ru/

Если total время ощутимо выросло по сравнению с замером на старом хостинге (сохраните такой замер до переезда — это дешёвая страховка), логично, что часть отказов и «неучтённых» визитов связана именно с этим. Решение — reverse-proxy с кэшированием на nginx перед приложением и вынесение счётчика аналитики в начало <head> с атрибутом async, чтобы он успевал сработать раньше, чем пользователь потеряет терпение.

Причина третья: http/https и путаница с доменами в отчётах

Если при переносе изменился протокол (например, раньше был общий SSL-сертификат хостинга через shared-конфигурацию, а на новом VPS вы настраиваете HTTPS заново) или домен стал указывать на новый IP без правильных 301-редиректов между http:// и https://, а также между www.example.ru и example.ru, — аналитика начинает видеть два разных сайта там, где раньше был один.

Яндекс.Метрика и Google Analytics в некоторых конфигурациях считают http://example.ru, https://example.ru и https://www.example.ru разными счётчиками данных, если код или настройка привязаны к конкретному протоколу/поддомену, либо если в Search Console/Вебмастере эти варианты добавлены как отдельные, не связанные между собой ресурсы. Тогда часть трафика, которая раньше суммировалась в одном отчёте, после переезда расползается по двум-трём отдельным «сайтам», и в основном отчёте вы видите падение — хотя суммарно ничего не потерялось.

Проверка редиректов:

curl -IL http://example.ru
curl -IL http://www.example.ru
curl -IL https://www.example.ru

Смотрите на цепочку кодов: в правильной настройке любой из этих трёх адресов должен через один 301 Moved Permanently приводить к единственному каноническому варианту, например https://example.ru. Если где-то в цепочке 200 OK вместо редиректа — это отдельно живущая версия сайта, которая ворует долю трафика из общей статистики. Настраивается это на уровне конфигурации nginx как reverse-proxy: один серверный блок ловит все варианты домена и редиректит на канонический, и только он проксирует запрос дальше в приложение.

Причина четвёртая: CDN или прокси съедают реальный IP посетителя

Если вместе с переездом вы включили CDN или прокси-защиту (Cloudflare, свой nginx-прокси перед сервером, любой WAF), трафик пользователя физически идёт не напрямую к вашему серверу, а через промежуточный узел. Сам код счётчика аналитики от этого не ломается — он выполняется в браузере посетителя и достаёт до серверов Яндекса/Google напрямую, независимо от CDN. А вот что действительно портится — это серверные логи и любые серверные средства аналитики (например, модуль подсчёта уникальных посетителей в панели хостинга или самописный скрипт на базе логов nginx): без правильной настройки они видят IP-адрес самого CDN или прокси вместо IP посетителя, и все визиты через один и тот же выходной узел схлопываются в одного «уникального» пользователя.

Если ваша «пропажа трафика» — это на самом деле пропажа из отчёта посещаемости в панели хостинга (не из Метрики/GA), проверьте access.log на сервере:

tail -100 /var/log/nginx/access.log

Если в колонке IP видны одни и те же адреса из известного диапазона CDN (Cloudflare публикует свои диапазоны на cloudflare.com/ips/) — реальные IP посетителей теряются. Чинится добавлением модуля realip в конфиг nginx:

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
real_ip_header CF-Connecting-IP;
real_ip_recursive on;

(список диапазонов Cloudflare нужно взять актуальным с их страницы — он периодически меняется, конкретные подсети здесь для примера конфигурации, а не как исчерпывающий список). После этого в логах и в любой server-side аналитике снова появится настоящий IP посетителя, а не адрес прокси.

Диагностика: код на странице и логи сервера вместо веры в один отчёт

Прежде чем чинить что-либо, нужно понять, какая из четырёх причин ваша — а иногда работают сразу две. Порядок проверки, который экономит время:

1. Смотрите исходный код живой страницы. Не полагайтесь на память «мы вроде переносили всё» — откройте Ctrl+U на главной и на паре внутренних страниц, найдите код счётчика глазами или через curl | grep, как показано выше. Если кода нет — дальше можно не диагностировать, это причина №1.
2. Сверьтесь с логами сервера напрямую, не только со сторонней аналитикой. Логи nginx или Apache фиксируют каждый HTTP-запрос независимо от того, выполнился ли JavaScript в браузере посетителя:

   awk '{print $4}' /var/log/nginx/access.log | cut -d: -f1 | sort | uniq -c

Эта команда покажет число запросов по часам за текущий лог. Сравните порядок величин с тем, что было на старом хостинге (если там были доступны логи или встроенная статистика хостинг-панели). Если количество реальных HTTP-запросов к страницам совпадает с «допереездным» уровнем, а в Метрике или GA — провал, значит, реальный трафик не терялся, ломается только счётчик. Если и в логах сервера тоже провал именно на страницах контента (не на статике) — вероятно, дело не в аналитике, а в чём-то более серьёзном (например, DNS ещё не до конца разошёлся, и часть пользователей действительно попадает на старый хостинг — это отдельная и более редкая история).

1. Проверьте цепочку редиректов командой curl -IL для всех вариантов домена — так вы поймаете причину №3, если она есть.
2. Проверьте, не проксируется ли трафик через CDN без настроенной передачи реального IP — через access.log и список IP-диапазонов вашего CDN-провайдера, как описано в причине №4.
3. Отдельно замерьте TTFB и время полной загрузки через curl -w, чтобы понять, есть ли вклад причины №2 (замедление после переезда).

Итог этой диагностики — конкретный список: «код счётчика физически на странице отсутствует» или «код есть, но логи сервера показывают такой же поток запросов, как раньше» — и это два принципиально разных вывода, ведущих к разным действиям.

Что чинить в зависимости от найденной причины

Если после всех проверок логи сервера тоже показывают падение количества запросов к самим страницам (а не только к статике вроде картинок и CSS) — стоит проверить распространение DNS после переезда и убедиться, что старый хостинг действительно отдаёт 301 на новый адрес, а не продолжает молча обслуживать часть посетителей со старой версией сайта — такое тоже встречается, если перенос делался без учёта TTL записей.

Частые вопросы