После переезда сайта упали позиции в Яндексе: что проверить на сервере, в коде и логах

Падение позиций в Яндексе после переезда сайта на новый сервер не всегда означает фильтр, санкции или “Яндекс не любит новый хостинг”. В большинстве реальных случаев причина проще: робот получил другие ответы сервера, увидел другой robots.txt, не смог загрузить часть страниц, попал на 403 от WAF, столкнулся с медленным TTFB, получил 502/504, увидел измененный canonical или начал обходить другую версию сайта.

Переезд сайта — это не только перенос файлов и базы. Для поисковой системы это момент повторной проверки: доступен ли сайт, совпадает ли структура URL, не изменился ли контент, отдают ли страницы 200 OK, не закрыт ли сайт в robots.txt, работает ли HTTPS, не появились ли массовые редиректы, ошибки и дубли.

Эта инструкция написана для вебмастеров, которые боятся миграции или уже видят падение позиций после переезда. Цель — не гадать, а быстро проверить сервер, код, robots.txt, sitemap, редиректы и логи так, чтобы понять, где именно сломалась видимость в Яндексе.

Сначала не паникуйте: падение может быть временным, но проверка обязательна

После переезда поисковая система может переобходить сайт, обновлять данные о доступности, скорости, зеркалах, редиректах и контенте. Небольшие колебания возможны. Но если падение резкое, затронуло много страниц или совпало с ошибками в Яндекс Вебмастере, ждать “само пройдет” — плохая стратегия.

Правильный подход такой:

• сравнить дату переезда и дату падения;
• проверить Яндекс Вебмастер;
• проверить коды ответа важных страниц;
• проверить robots.txt;
• проверить sitemap.xml;
• проверить редиректы;
• проверить canonical;
• проверить логи Яндекс-робота;
• проверить скорость и стабильность сервера;
• проверить, не изменился ли HTML и контент.

Если все эти пункты в норме, можно смотреть глубже: поведенческие, конкурентов, апдейты, качество страниц, коммерческие факторы. Но после миграции сначала всегда проверяется техника.

Главная ошибка после переезда: смотреть сайт только глазами

Открыть сайт в браузере и увидеть, что он работает, недостаточно. Ваш браузер может получать 200 OK, а Яндекс-робот — 403. Вы можете видеть кэшированную страницу через CDN, а робот — ошибку origin-сервера. Главная страница может открываться, а старые статьи — отдавать 404. Десктоп может работать, а мобильная версия — быть битой.

Проверять нужно не “сайт вообще”, а конкретные URL и конкретные ответы сервера:

• главная страница;
• топовые страницы по трафику из Яндекса;
• топовые страницы по доходу;
• категории;
• старые URL;
• страницы с ЧПУ;
• мобильная версия;
• robots.txt;
• sitemap.xml;
• страницы с параметрами, если они индексировались;
• страницы, которые пропали из выдачи.

Если после переезда упали позиции, главная страница обычно не главный источник проблемы. Проблема часто сидит в массовых URL, шаблонах, категориях, пагинации, canonical, редиректах или серверных ошибках.

Шаг 1. Проверьте Яндекс Вебмастер

Первое место для проверки — Яндекс Вебмастер. Не потому что там всегда сразу видна причина, а потому что там есть сигналы о доступности, обходе, индексировании и ответах сервера.

Проверьте разделы:

• Индексирование;
• Страницы в поиске;
• Исключенные страницы;
• Статистика обхода;
• Проверка ответа сервера;
• Анализ robots.txt;
• Файлы Sitemap;
• Диагностика сайта;
• Безопасность и нарушения;
• Переезд сайта, если менялось зеркало, домен, www или HTTPS.

Ищите не одну ошибку, а изменение до и после миграции. Например, было много 200 OK, стало много 404. Был стабильный обход, стали 5xx. Был доступный robots.txt, появилась ошибка. Было зеркало без www, после переезда часть URL стала отдавать www без правильного редиректа.

Шаг 2. Проверьте, что Яндекс видит правильный код ответа

Для важных страниц сервер должен отдавать 200 OK. Если страница была в поиске, а после переезда стала отдавать 404, 500, 502, 503, 504, 403 или бесконечный редирект, позиции закономерно упадут.

Проверяйте не браузером, а HTTP-ответом:

curl -I https://example.com/page/

Проверьте с user-agent Яндекса:

curl -I -A "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)" https://example.com/page/

Сравните ответы для обычного пользователя и для робота. Если обычный user-agent получает 200, а YandexBot получает 403 или 503, проблема почти точно в firewall, WAF, CDN, антиботе, security-плагине или серверном правиле.

Минимально проверьте:

• главную страницу;
• 10-20 страниц, которые упали;
• категории;
• старые URL из Яндекса;
• robots.txt;
• sitemap.xml;
• страницы с www и без www;
• HTTP и HTTPS версии.

Шаг 3. Проверьте 5xx ошибки

После переезда сайт может открываться нормально для вас, но падать под нагрузкой роботов или пользователей. Для Яндекса это выглядит как нестабильный сервер.

Особенно опасны:

• 500 Internal Server Error;
• 502 Bad Gateway;
• 503 Service Unavailable;
• 504 Gateway Timeout;
• connection timeout;
• SSL handshake errors;
• upstream timed out;
• PHP-FPM max_children reached;
• database connection errors.

Проверьте логи веб-сервера:

grep " 5[0-9][0-9] " /var/log/nginx/access.log | tail -100

Для сайтов с несколькими логами:

grep " 5[0-9][0-9] " /var/log/nginx/*access*.log | tail -100

Проверьте ошибки nginx:

tail -200 /var/log/nginx/error.log

Проверьте PHP-FPM:

journalctl -u php*-fpm --no-pager -n 200

Если после переезда появились 502/504, проблема часто в связке nginx + PHP-FPM + база данных: мало workers, маленький memory_limit, медленные запросы, неправильный socket, нехватка RAM, OOM killer или слабый диск.

Шаг 4. Проверьте 404 после переезда

Массовые 404 после миграции — одна из самых частых причин просадки. Особенно на CMS, где ЧПУ, rewrite rules, .htaccess, nginx location или permalink-настройки не перенеслись корректно.

Проверьте 404 в логах:

grep " 404 " /var/log/nginx/access.log | tail -100

Найдите самые частые 404:

awk '$9==404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -50

Если среди 404 есть старые страницы, которые раньше давали трафик из Яндекса, это критично. Их нужно восстановить или настроить 301 на релевантные новые URL.

Частые причины 404 после переезда:

• не перенесли .htaccess;
• не настроили nginx rewrite;
• изменился формат ЧПУ;
• изменился регистр URL;
• не перенесли папку uploads/images;
• не перенесли старые статические страницы;
• изменились категории;
• изменился URL с trailing slash;
• слетел permalink в WordPress;
• не перенесли правила редиректов.

Шаг 5. Проверьте robots.txt

robots.txt — первое место, где часто ломают индексацию после переезда. На тестовом сервере сайт закрывали от индексации, а потом этот файл случайно попал в production.

Проверьте:

curl -I https://example.com/robots.txt

Файл должен отдавать 200 OK и быть доступен из корня сайта.

Посмотрите содержимое:

curl -s https://example.com/robots.txt

Опасные признаки:

• User-agent: * и Disallow: /;
• закрыты важные категории;
• закрыты страницы с трафиком;
• закрыты CSS и JS, которые нужны для рендера;
• закрыты изображения, если они важны для сайта;
• указан старый sitemap;
• robots.txt отличается для www и non-www;
• robots.txt отдает 403, 404, 500 или HTML вместо txt;
• CDN кэширует старую тестовую версию;
• в файле остались staging-директивы.

Дополнительно проверьте robots.txt через инструмент “Анализ robots.txt” в Яндекс Вебмастере. Важно смотреть не только файл глазами, а именно интерпретацию Яндекса.

Шаг 6. Проверьте meta robots и X-Robots-Tag

Даже если robots.txt правильный, сайт может закрывать страницы через meta robots или HTTP-заголовок X-Robots-Tag.

Проверьте HTML:

curl -s https://example.com/page/ | grep -i "robots"

Проверьте заголовки:

curl -I https://example.com/page/ | grep -i "x-robots"

Опасные варианты:

• noindex на важных страницах;
• nofollow без причины;
• X-Robots-Tag: noindex;
• разные meta robots для обычного пользователя и бота;
• noindex остался от staging-сайта;
• SEO-плагин сменил настройки после миграции;
• шаблон мобильной версии содержит noindex.

На форумах это одна из самых неприятных ошибок: визуально сайт работает, robots.txt чистый, но в HTML или заголовках стоит noindex. Владелец ищет проблему в сервере, а страница сама просит поисковик ее не индексировать.

Шаг 7. Проверьте sitemap.xml

Sitemap помогает Яндексу понимать, какие URL важны для обхода. После переезда sitemap часто ломается: старый домен, HTTP вместо HTTPS, тестовый поддомен, неправильные URL, 404 внутри карты.

Проверьте:

curl -I https://example.com/sitemap.xml

Посмотрите содержимое:

curl -s https://example.com/sitemap.xml | head

Проверьте:

• sitemap отдает 200 OK;
• URL внутри sitemap на основной версии сайта;
• нет staging-домена;
• нет старого IP;
• нет http вместо https, если сайт работает на https;
• нет массовых URL, которые отдают 404;
• нет закрытых robots.txt страниц;
• sitemap указан в robots.txt;
• sitemap загружен в Яндекс Вебмастер;
• дата lastmod не стала мусорной для всех страниц.

Если sitemap показывает одну структуру, а сайт фактически отдает другую, робот будет тратить обход на мусор и ошибки.

Шаг 8. Проверьте www, non-www, HTTP и HTTPS

После переезда часто меняется главное зеркало. Например, раньше сайт был на https://example.com, а новый сервер начал отдавать https://www.example.com. Или HTTP перестал редиректить на HTTPS.

Проверьте все варианты:

curl -I http://example.com/

curl -I https://example.com/

curl -I http://www.example.com/

curl -I https://www.example.com/

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

Плохие варианты:

• HTTP и HTTPS открываются как разные сайты;
• www и non-www открываются как разные сайты;
• редирект идет на главную вместо аналогичной страницы;
• редиректов больше двух-трех в цепочке;
• появился redirect loop;
• часть URL редиректит на старый домен;
• canonical указывает на другую версию, чем редирект;
• sitemap указывает не на основную версию.

Если Яндекс начинает видеть дубли, разные зеркала или противоречивые сигналы, позиции могут просесть до стабилизации.

Шаг 9. Проверьте canonical

Canonical после переезда часто ломается незаметно. Страница открывается, но canonical указывает на старый домен, тестовый домен, http-версию, www-версию или вообще на главную.

Проверьте:

curl -s https://example.com/page/ | grep -i "canonical"

Опасные признаки:

• canonical указывает на staging-домен;
• canonical указывает на старый домен;
• canonical указывает на http вместо https;
• canonical указывает на www, а основная версия без www;
• canonical всех страниц указывает на главную;
• canonical отсутствует там, где раньше был;
• canonical изменился после смены темы или SEO-плагина;
• мобильная версия содержит другой canonical.

Если после переезда позиции упали только у части страниц, canonical — один из первых кандидатов на проверку.

Шаг 10. Проверьте редиректы старых URL

Если при переезде изменилась структура URL, нужны 301-редиректы со старых адресов на новые аналогичные страницы. Редирект всех старых URL на главную — плохая практика.

Проверьте старые URL из Яндекса:

curl -I https://example.com/old-page/

Правильно:

• старый URL отдает 301;
• редирект ведет на релевантную новую страницу;
• новая страница отдает 200;
• цепочка редиректа короткая;
• нет редиректа на главную для всего подряд;
• не теряются параметры, если они важны;
• редирект одинаково работает для ботов и пользователей.

Плохо:

• старые URL отдают 404;
• старые URL редиректят на главную;
• редирект идет через несколько промежуточных URL;
• редирект циклический;
• редирект ведет на страницу с noindex;
• редирект ведет на страницу, закрытую robots.txt;
• редирект работает только для браузера, но не для бота.

Шаг 11. Проверьте, не изменился ли HTML важной страницы

Переезд “только на другой сервер” часто неожиданно меняет HTML. Причины: другая версия PHP, другой шаблон, другой кэш, другой плагин, другой режим CDN, другой mobile renderer, другой набор расширений.

Сравните старую и новую версию важной страницы, если у вас есть backup или старая копия.

Проверьте:

• title;
• description;
• h1;
• основной текст;
• внутренние ссылки;
• хлебные крошки;
• canonical;
• hreflang, если используется;
• schema.org;
• robots meta;
• рекламные блоки;
• блоки рекомендаций;
• меню и футер;
• мобильный HTML.

Если “серверный переезд” совпал со сменой темы, PHP, CMS, плагинов и кэша, это уже не просто переезд. Это изменение сайта. Тогда позиции могли упасть из-за измененного контента и структуры.

Шаг 12. Проверьте мобильную версию

Многие вебмастера проверяют сайт с десктопа, а проблема находится в мобильной версии. После переезда mobile cache, adaptive template, CDN rules или mobile redirect могут работать иначе.

Проверьте важные URL с мобильным user-agent:

curl -I -A "Mozilla/5.0 (Linux; Android 10; Mobile) AppleWebKit/537.36 Chrome/120.0 Mobile Safari/537.36" https://example.com/page/

Проверьте HTML:

curl -s -A "Mozilla/5.0 (Linux; Android 10; Mobile) AppleWebKit/537.36 Chrome/120.0 Mobile Safari/537.36" https://example.com/page/ | head

Ищите:

• мобильная версия отдает 200;
• нет отдельного noindex;
• нет редиректа на m-домен с ошибкой;
• не отдается пустой шаблон;
• основной контент присутствует;
• canonical правильный;
• CSS/JS доступны;
• нет 403 для мобильного user-agent;
• скорость приемлемая.

Если мобильный трафик основной, поломка мобильной версии может быстро ударить по позициям.

Шаг 13. Проверьте CSS, JS и изображения

Яндекс должен иметь доступ к ресурсам, которые нужны для понимания страницы. После переезда часто ломаются пути к CSS, JS, изображениям, шрифтам и CDN.

Проверьте в логах 404 по статике:

grep " 404 " /var/log/nginx/access.log | grep -E "\.css|\.js|\.jpg|\.png|\.webp|\.svg|\.woff" | tail -100

Проверьте:

• CSS отдает 200;
• JS отдает 200;
• основные изображения отдают 200;
• нет mixed content;
• нет блокировки static-директорий в robots.txt;
• пути не указывают на старый домен;
• CDN подключен к новому origin;
• не сломалась генерация WebP;
• не пропали thumbnails в CMS.

Если страница без CSS/JS для робота выглядит пустой или сломанной, это может повлиять на оценку страницы.

Шаг 14. Проверьте скорость ответа сервера

После переезда позиции могут просесть из-за ухудшения скорости и стабильности. Особенно если новый сервер формально “мощнее”, но плохо настроен: медленный PHP-FPM, слабый диск, нет кэша, плохие настройки базы, высокий CPU steal, маленький лимит workers.

Проверьте TTFB:

curl -o /dev/null -s -w "DNS:%{time_namelookup} Connect:%{time_connect} TLS:%{time_appconnect} TTFB:%{time_starttransfer} Total:%{time_total}\n" https://example.com/page/

Проверьте несколько страниц, а не только главную:

• главная;
• топовые статьи;
• категории;
• страницы с тяжелыми фильтрами;
• страницы с большим количеством комментариев;
• страницы с рекламой;
• страницы без кэша.

Если TTFB вырос в несколько раз после переезда, причина может быть в сервере, базе данных, PHP, кэше, CDN или DNS.

Шаг 15. Проверьте нагрузку и OOM killer

Сайт может периодически падать из-за нехватки RAM. Владелец видит, что “сейчас сайт работает”, но робот мог попасть в момент ошибки.

Проверьте память:

free -h

Проверьте нагрузку:

uptime

Проверьте процессы:

top

Проверьте OOM killer:

dmesg -T | grep -i "killed process\|out of memory"

Если OOM убивает PHP-FPM, MySQL/MariaDB или nginx, позиции могут падать не из-за “SEO”, а из-за нестабильности сервера.

Шаг 16. Проверьте PHP-FPM и базу данных

Для WordPress, Bitrix, Joomla, Drupal и других CMS после переезда часто ломается производительность на уровне PHP и базы.

Проверьте PHP-FPM:

systemctl status php*-fpm

Проверьте логи:

journalctl -u php*-fpm --no-pager -n 200

Проверьте MariaDB/MySQL:

systemctl status mariadb

или:

systemctl status mysql

Ищите:

• PHP Fatal error;
• upstream timed out;
• connect() to unix socket failed;
• database connection errors;
• too many connections;
• slow queries;
• memory exhausted;
• max_children reached;
• permission denied.

Если сервер под нагрузкой отдает 502/504, Яндекс может снижать доверие к страницам из-за недоступности.

Шаг 17. Проверьте логи Яндекс-робота

Это один из самых полезных шагов. Нужно посмотреть, что именно получал YandexBot после переезда.

Найдите запросы Яндекса в access log:

grep -i "Yandex" /var/log/nginx/access.log | tail -100

Посчитайте статусы для Яндекс-робота:

grep -i "Yandex" /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c | sort -nr

Найдите ошибки Яндекса:

grep -i "Yandex" /var/log/nginx/access.log | grep -E " 4[0-9][0-9] | 5[0-9][0-9] " | tail -100

Посмотрите, какие URL Яндекс получает с ошибкой:

grep -i "Yandex" /var/log/nginx/access.log | awk '$9 ~ /^[45]/ {print $9, $7}' | sort | uniq -c | sort -nr | head -50

Если YandexBot массово получает 403, 404, 500, 502, 503 или 504, вы нашли техническую причину. Дальше нужно чинить конкретные URL, правила доступа, WAF, PHP, базу или редиректы.

Шаг 18. Проверьте, настоящий ли это YandexBot

В логах user-agent можно подделать. Если вы видите подозрительные запросы с YandexBot, не стоит автоматически разрешать весь трафик с таким user-agent.

Для важных случаев проверяйте IP через reverse DNS и forward DNS. У Яндекса есть официальные рекомендации по проверке роботов. В практическом смысле: не блокируйте роботов по user-agent вслепую и не разрешайте всех “YandexBot” без проверки, если сервер под атакой.

Если WAF или firewall блокирует настоящий YandexBot, страницы могут выпасть. Если разрешить всех поддельных ботов, сервер может получить нагрузку. Нужен баланс: проверка настоящих роботов и аккуратные правила.

Шаг 19. Проверьте WAF, Cloudflare, антибот и security-плагины

После переезда часто меняется защита: включили Cloudflare, поменяли WAF, добавили антибот, поставили security-плагин, включили rate limit. Пользователи сайт видят, а робот может получать 403 или challenge.

Проверьте:

• не блокируется ли YandexBot;
• не блокируется ли YandexImages, если важен трафик из картинок;
• не блокируется ли YandexDirect, если сайт монетизируется через РСЯ;
• не получает ли робот JavaScript challenge;
• не требует ли сайт cookies для доступа;
• не срабатывает ли rate limit на обход;
• не блокируются ли IP дата-центров;
• не включена ли защита по стране;
• не блокируются ли HEAD-запросы;
• не закрыты ли CSS/JS от роботов.

Очень частая ошибка: включили агрессивную защиту от ботов и вместе с мусором отрезали поисковых роботов. В Яндексе это может проявиться как ухудшение обхода и выпадение страниц.

Шаг 20. Проверьте DNS после переезда

Если DNS переключили резко, часть роботов и пользователей могла еще ходить на старый сервер. Если старый сервер уже выключен, они получали ошибки.

Проверьте текущие A-записи:

dig example.com A +short

Проверьте www:

dig www.example.com A +short

Проверьте через разные публичные резолверы:

dig @8.8.8.8 example.com A +short

dig @1.1.1.1 example.com A +short

Проверьте:

• основной домен указывает на новый IP;
• www указывает корректно;
• AAAA-запись не ведет на старый или сломанный IPv6;
• CDN указывает на правильный origin;
• нет старых A-записей;
• старый сервер еще отвечает в переходный период;
• TTL был снижен заранее или хотя бы теперь понятен.

Отдельно проверьте IPv6. Иногда сайт по IPv4 работает, а AAAA-запись ведет на неработающий сервер. Часть клиентов и роботов может получать проблемы именно через IPv6.

Шаг 21. Проверьте SSL-сертификат

После переезда HTTPS может работать в браузере, но иметь проблемы для части клиентов или роботов: неправильная цепочка, не тот сертификат, просрочка, отсутствие SAN для www, ошибка на IPv6, несовместимая конфигурация.

Проверьте:

• сертификат выпущен на основной домен;
• сертификат покрывает www, если используется;
• цепочка сертификатов корректна;
• HTTP редиректит на HTTPS;
• нет mixed content;
• старый сертификат не отдается с нового IP;
• CDN и origin используют совместимый режим HTTPS;
• не истекает сертификат в ближайшие дни.

Если Яндекс Вебмастер показывает ошибки проверки HTTPS или ответа сервера, сначала чините сертификат и редиректы.

Шаг 22. Проверьте кодировку и контент

После переноса базы иногда ломается кодировка, обрезаются тексты, пропадают символы, меняются шаблоны или часть контента не выводится. Для поисковика это уже изменение страницы.

Проверьте:

• русский текст отображается нормально;
• нет кракозябр;
• не обрезаны статьи;
• не пропали блоки контента;
• не пропали таблицы;
• не пропали изображения;
• не сломалась верстка;
• не изменилась структура заголовков;
• не появились PHP warnings в HTML;
• не выводятся технические ошибки пользователю.

Если на страницах появились warning-и, stack trace, ошибки подключения или пустые блоки, это нужно исправлять сразу.

Шаг 23. Проверьте внутреннюю перелинковку

Переезд, смена CMS, темы или конфигов может сломать внутренние ссылки. Позиции могут просесть, если важные страницы потеряли внутренний вес или стали хуже доступны для обхода.

Проверьте:

• меню;
• хлебные крошки;
• блоки похожих материалов;
• ссылки из категорий;
• пагинацию;
• ссылки в тексте;
• карточки товаров или статей;
• ссылки на старый домен;
• ссылки на http вместо https;
• битые внутренние ссылки.

Если после переезда важные страницы стали доступны только из sitemap, а из интерфейса сайта на них нет ссылок, обход и позиции могут ухудшиться.

Шаг 24. Проверьте региональность и контакты

Для коммерческих сайтов в Яндексе важны региональные и коммерческие сигналы. После переезда или смены шаблона могли пропасть контакты, адрес, телефон, реквизиты, страница доставки, условия оплаты или микроразметка организации.

Проверьте:

• страница контактов доступна;
• телефон и адрес не пропали;
• регион в Яндекс Вебмастере не изменился неожиданно;
• Яндекс Бизнес/Справочник не потерял связь с сайтом;
• микроразметка Organization/LocalBusiness не сломалась;
• страницы доставки и оплаты открываются;
• коммерческие блоки остались на месте.

Если это информационный сайт, этот пункт менее критичен. Если коммерческий — потеря контактов и региональности может ударить по видимости.

Шаг 25. Проверьте, не изменился ли серверный IP и география критично

Сам по себе новый IP не должен автоматически обрушивать позиции. Но проблемы с новым IP и сетью могут влиять косвенно: сайт стал медленнее для основной аудитории, часто недоступен, попал под блокировки, имеет плохую маршрутизацию или находится за агрессивным антиботом.

Проверьте:

• ping и TTFB из регионов основной аудитории;
• нет ли сетевых потерь;
• нет ли блокировки IP у провайдеров пользователей;
• нет ли проблем с IPv6;
• не изменилась ли CDN-схема;
• не стал ли сайт открываться сильно медленнее в России/СНГ, если аудитория там;
• не режет ли хостинг ботов или высокий crawl rate.

Если сайт ориентирован на Яндекс и российскую аудиторию, проверяйте доступность именно из нужных регионов, а не только со своего компьютера.

Что делать, если нашли 403 для YandexBot

403 для Яндекс-робота после переезда — критичная проблема. Причина часто в WAF, Cloudflare, nginx rules, fail2ban, security-плагине, geo-blocking или антиботе.

Порядок действий:

• найти URL, где YandexBot получает 403;
• проверить, настоящий ли это робот;
• посмотреть nginx access/error logs;
• посмотреть WAF/CDN firewall events;
• проверить security-плагины CMS;
• проверить deny rules в nginx/apache;
• проверить fail2ban;
• убрать блокировку для настоящих роботов;
• проверить ответ через Яндекс Вебмастер;
• отправить важные страницы на переобход.

Не решайте проблему грубым “разрешить всех с user-agent Yandex”. User-agent подделывается. Лучше настроить корректную проверку и правила.

Что делать, если нашли массовые 404

Массовые 404 нужно разделить на две группы: мусорные URL и важные старые URL.

Мусорные URL можно оставить 404, если это реальные несуществующие страницы. Важные URL, которые раньше были в поиске и приносили трафик, нужно восстановить или редиректить на релевантные страницы.

Порядок:

• выгрузить топ 404 из логов;
• сравнить с URL из Яндекс Вебмастера;
• сравнить с топовыми страницами до переезда;
• восстановить страницы, если они должны существовать;
• настроить 301 на релевантные новые URL;
• не редиректить все на главную;
• обновить sitemap;
• проверить редиректы curl-ом;
• отправить важные URL на переобход.

Если у вас интернет-магазин или большой контентный сайт, массовые 404 после миграции могут быстро съесть видимость.

Что делать, если нашли 502/504

502/504 после переезда — это серверная проблема, не SEO-магия. Нужно смотреть backend.

Проверьте:

• PHP-FPM работает;
• не закончилась RAM;
• не срабатывает OOM killer;
• достаточно PHP-FPM workers;
• нет медленных запросов к базе;
• база не упирается в connections;
• nginx proxy/read timeout не слишком мал;
• диск не перегружен;
• кэш включен;
• нет cron-задач, которые кладут сервер;
• нет тяжелых ботов без rate limit.

После исправления отправьте важные страницы на переобход через Яндекс Вебмастер, но только когда сервер уже стабилен. Отправлять на переобход страницу, которая все еще периодически отдает 504, бессмысленно.

Что делать, если robots.txt закрыл сайт

Если после переезда в production попал Disallow: /, исправляйте сразу.

Порядок:

• вернуть корректный robots.txt;
• убедиться, что он отдает 200 OK;
• очистить CDN cache, если используется;
• проверить robots.txt через Яндекс Вебмастер;
• проверить несколько важных URL инструментом проверки ответа;
• обновить sitemap;
• отправить важные страницы на переобход.

Если сайт был закрыт недолго, восстановление обычно быстрее. Если запрет висел долго и Яндекс успел переобойти много страниц, возврат может занять больше времени.

Что делать, если canonical указывает не туда

Canonical нужно исправлять в шаблоне, CMS, SEO-плагине или конфиге, который его генерирует. Ручное исправление одной страницы не поможет, если проблема шаблонная.

Порядок:

• найти тип страниц с неправильным canonical;
• понять источник: тема, SEO-плагин, CMS, кастомный код, CDN;
• исправить генерацию;
• очистить кэш CMS;
• очистить CDN cache;
• проверить HTML нескольких URL;
• проверить sitemap и редиректы;
• отправить важные страницы на переобход.

Если canonical массово указывал на старый домен или главную, это могло сильно ударить по видимости конкретных URL.

Что делать, если старый сервер выключили слишком рано

Если после смены DNS старый сервер удалили сразу, часть пользователей и роботов могла получать ошибку. Это уже произошло, но можно снизить ущерб.

Сделайте:

• проверьте, что все DNS сейчас указывают на новый сервер;
• проверьте, нет ли старых A/AAAA записей;
• проверьте доступность сайта с разных резолверов;
• проверьте Яндекс Вебмастер на ошибки обхода;
• проверьте логи нового сервера;
• убедитесь, что новый сервер стабилен;
• отправьте важные страницы на переобход;
• если старый сервер еще можно восстановить, поднимите его на несколько дней.

На будущее: старый сервер после миграции нужно держать включенным минимум 48-72 часа, а для доходных и крупных сайтов — дольше.

Когда стоит откатиться

Откат на старый сервер нужен, если новый сервер явно ломает сайт, а быстро исправить не получается.

Откат оправдан, если:

• много важных страниц отдают 5xx;
• много важных страниц стали 404;
• robots.txt или noindex закрыли сайт, а причина не ясна;
• новый сервер не держит нагрузку;
• WAF режет роботов, а быстро настроить нельзя;
• база работает нестабильно;
• сайт потерял контент или шаблоны;
• доходный сайт теряет трафик и нет быстрого исправления.

Откат возможен только если старый сервер сохранен, DNS TTL был снижен, база не разъехалась или есть план синхронизации. Если старый сервер уже удален, отката нет — остается чинить новый.

Чего нельзя делать после падения позиций

• Не меняйте одновременно сервер, дизайн, структуру URL и тексты.
• Не отправляйте весь сайт на переобход, пока ошибки не исправлены.
• Не закрывайте сайт в robots.txt “на время ремонта”.
• Не редиректите все 404 на главную.
• Не отключайте firewall полностью без понимания.
• Не разрешайте всех ботов только по user-agent.
• Не удаляйте старый сервер, если еще идет диагностика.
• Не меняйте canonical вслепую.
• Не чистите логи до анализа.
• Не верьте только браузеру и PageSpeed.
• Не ищите санкции до проверки серверных ошибок.

Чек-лист: сервер

• Сайт доступен по основному домену.
• HTTP/HTTPS редиректы корректны.
• www/non-www приведены к основной версии.
• SSL-сертификат корректный.
• Нет массовых 5xx.
• Нет массовых 404 на важных URL.
• TTFB не хуже, чем до переезда.
• PHP-FPM стабилен.
• База данных стабильна.
• Нет OOM killer.
• Диск не заполнен.
• DNS-записи корректны.
• AAAA-запись не ведет на сломанный IPv6.
• Старый сервер не выключен слишком рано.
• CDN/WAF не блокирует Яндекс.

Чек-лист: код и SEO-сигналы

• robots.txt доступен и не закрывает важные страницы.
• meta robots не содержит noindex на важных страницах.
• X-Robots-Tag не закрывает страницы.
• sitemap.xml доступен и содержит правильные URL.
• canonical указывает на правильные страницы.
• title и h1 не изменились случайно.
• основной контент не пропал.
• внутренняя перелинковка работает.
• CSS/JS доступны роботам.
• изображения открываются.
• мобильная версия работает.
• микроразметка не сломалась.
• редиректы старых URL ведут на релевантные страницы.
• нет staging-домена в HTML, sitemap или canonical.

Чек-лист: логи

• YandexBot получает 200 на важных страницах.
• YandexBot не получает массовые 403.
• YandexBot не получает массовые 404 на старых URL.
• YandexBot не получает 500/502/503/504.
• robots.txt запрашивается и отдает 200.
• sitemap.xml запрашивается и отдает 200.
• нет резкого роста ошибок после даты переезда.
• нет rate limit для поисковых роботов.
• нет капчи или challenge для роботов.
• нет странных редиректов для user-agent Яндекса.

Как правильно подготовиться к переезду, чтобы не бояться миграции

Если сайт еще не переехал, лучшая защита позиций — подготовка до переключения DNS.

• Снять список топовых страниц из Яндекса.
• Сделать backup файлов и базы.
• Снизить DNS TTL заранее.
• Настроить новый сервер.
• Проверить сайт через hosts-файл.
• Сравнить robots.txt, sitemap, canonical и HTML.
• Проверить HTTP-статусы важных страниц.
• Проверить мобильную версию.
• Проверить скорость нового сервера.
• Проверить логи после тестовых запросов.
• Переключать DNS в спокойное окно.
• Старый сервер держать включенным минимум 48-72 часа.
• Первые 3-7 дней смотреть Яндекс Вебмастер и server logs.

Страх миграции обычно появляется не из-за самого переезда, а из-за отсутствия контроля. Если есть чек-лист, логи, backup, старый сервер и план отката, переезд становится управляемой операцией.

Как HSTQ может помочь с переездом сайта

Для сайта, который получает трафик из Яндекса, сервер важен не только как место хранения файлов. Важны стабильные ответы, скорость, правильный HTTPS, корректные редиректы, доступность для роботов, отсутствие 5xx, нормальная настройка PHP, базы данных, nginx/Apache, кэша и логов.

HSTQ может помочь с VPS/VDS или выделенным сервером для сайта, подготовкой окружения, переносом, первичной настройкой веб-сервера, SSL, PHP, базы данных, кэша и базовой диагностикой после миграции. Для вебмастера особенно важно заранее проверить robots.txt, sitemap.xml, canonical, редиректы, HTTP-статусы, логи Яндекс-робота и скорость важных URL.

Если позиции в Яндексе уже упали после переезда, при обращении лучше сразу подготовить: домен, дату миграции, старый и новый IP, CMS, список упавших URL, ошибки из Яндекс Вебмастера, access/error logs за период до и после переезда, конфиги nginx/Apache и информацию о CDN/WAF.

Посмотреть услуги HSTQ можно здесь: https://hstq.net/.

Короткий практический финал

Падение позиций в Яндексе после переезда почти всегда нужно начинать проверять с техники. Не с догадок про санкции, не с переписывания текстов и не с массовой смены SEO-настроек. Сначала серверные ответы, robots.txt, sitemap, canonical, редиректы, HTTPS, WAF, скорость и логи Яндекс-робота.

Самые частые причины просадки после миграции: важные URL стали 404, сервер отдавал 502/504, robots.txt закрыл сайт, meta robots получил noindex, canonical уехал на старый или тестовый домен, Яндекс получил 403 от WAF, sitemap содержит старые URL, www/non-www и HTTPS начали конфликтовать, старый сервер выключили слишком рано.

Правильная диагностика проста: берете список страниц, которые потеряли позиции, проверяете их HTTP-статус, HTML, canonical, robots, sitemap, редиректы и записи в access log для YandexBot. Если робот видит то же самое, что видел до переезда, сервер стабилен, ошибок нет и контент не изменился, тогда уже можно смотреть внешние факторы. Но пока техника не проверена, любые разговоры про “алгоритмы Яндекса” — преждевременная попытка не смотреть в логи.