SEO-чек-лист после смены CMS: что проверить в первую неделю

Главное правило переезда: адреса страниц остаются прежними. Всё остальное вторично. Дальше по списку проверяют заголовки и описания, картинки и их вес, служебные файлы, скорость и мобильную версию. Просадка на 5-10 дней нормальна, дольше уже симптом.

Сайт переехал на другую CMS, дизайн вроде остался тем же, а через полторы-две недели график в Яндекс Вебмастере начинает ползти вниз. Разработчик отвечал за вёрстку и функциональность, а SEO-хвосты вроде редиректов, мета-тегов и sitemap остались либо на владельца, либо на того, кто ведёт сайт после запуска. Эта статья для тех, кто перевёл сайт с Tilda на WordPress, с Битрикса на другой движок или наоборот, и хочет за первую неделю поймать всё, что обычно ломается при переезде. Ниже порядок проверок, который я прогоняю на каждом клиентском переезде: команды, таблица приоритетов и чек-лист на две недели.

Чек-лист проверки сайта после переезда на новую CMS

Главный принцип переезда: URL остаются прежними, всё остальное вторично

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

Tilda генерирует адреса вида /page12345 или /tproduct/123456789-nazvanie, WordPress по умолчанию строит их из slug записи и структуры ЧПУ. Битрикс кладёт товары в /catalog/section/element/, самописная CMS может использовать что угодно, вплоть до ?id=482. Когда я переносил клиента с Tilda на WordPress, из 40 страниц старого сайта совпадающих адресов было три: главная, /contacts, /privacy. Остальные 37 требовали ручной карты редиректов, иначе Яндекс индексировал бы два сайта одновременно: старый в кэше, новый на новых URL, и оба конкурировали бы за одни и те же запросы.

Если делаете переезд сейчас, самое дешёвое время исправить URL, это до запуска: спроектировать структуру нового сайта так, чтобы она максимально совпадала со старой, или заранее подготовить полную карту 301-редиректов старый адрес на новый. После запуска это уже не проектирование, а разбор завалов. Я подробно разбирал перенос именно с Tilda на WordPress в отдельной статье, там разница между конструктором и полноценной CMS видна особенно чётко: перенос сайта с Tilda на WordPress.

Проверка адресов: выгрузка старого sitemap, прогон списка, поиск 404

Первым делом нужен список всех URL, которые были у старого сайта. Три источника, по убыванию надёжности:

Старый sitemap.xml, если вы его сохранили до переезда (обязательно сохраняйте, это отдельный урок).
Экспорт из Яндекс Вебмастера или Google Search Console: список проиндексированных страниц с историческим трафиком.
Wayback Machine через CDX API, если старого sitemap нет вообще: web.archive.org/cdx/search/cdx?url=example.ru/*&output=text&fl=original&collapse=urlkey.

Дальше список прогоняется скриптом против нового сайта, чтобы увидеть код ответа по каждому старому адресу:

while read -r url; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://example.ru$url")
  echo "$code $url"
done < old-urls.txt | sort -n > redirect-report.txt

Дальше смотрим на redirect-report.txt глазами. Код 200 на старом адресе означает, что страница осталась на месте, это нормально. Код 301 или 302 означает, что редирект есть, нужно проверить, ведёт ли он на смысловой аналог, а не на главную. Код 404 значит, что страницу забыли, у неё либо был трафик и её надо восстановить или отредиректить, либо трафика не было и можно оставить как есть.

По моему опыту на переезде среднего сайта услуг из 60-80 страниц находится 8-15 потерянных адресов. Обычно это старые лендинги под рекламу, забытые в архиве, или карточки услуг, которые переименовали при переносе и забыли прописать редирект.

Мета-теги и заголовки: не потерялись ли title и description

Вторая частая поломка, это не отсутствие мета-тегов, а их обезличивание. Новый движок подставляет свой шаблон по умолчанию, и вместо осмысленного title получается что-то вроде «Заголовок страницы | Название сайта» на всех страницах разом. Rank Math и Yoast в WordPress делают это тихо: если для записи не заполнено поле SEO-заголовка, используется дефолтный шаблон типа %title% %sep% %sitename%, и если исходный title записи после импорта оказался пустым или совпал с H1, вы получаете дубли title по всему сайту, что для Яндекса прямой сигнал «страница не отличается от соседних».

Проверить массово можно тем же curl, только с выдёргиванием тега:

while read -r url; do
  title=$(curl -s "https://example.ru$url" | grep -oP '(?<=<title>).*?(?=</title>)')
  echo "$url | $title"
done < old-urls.txt > titles-report.txt

Дальше смотрите на файл и ищите повторы: sort titles-report.txt -t'|' -k2 | uniq -c -f1 -d. Если одна и та же строка встречается на трёх разных URL, это дубли, которые надо развести руками. Заодно проверьте, что description после миграции не превратился в обрезок первого предложения текста статьи, это типичное поведение импортёров, которые в отсутствие поля description просто берут первые 160 символов контента.

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

Картинки: новые пути, редиректы со старых, alt и вес файлов

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

Смена пути. Tilda хранит изображения на static.tildacdn.com, WordPress кладёт их в /wp-content/uploads/2026/08/. Если на картинки старого сайта были внешние обратные ссылки (а Google Images и Яндекс Картинки индексируют такие URL отдельно от страниц), после переезда все эти ссылки превращаются в 404. Отдельного трафика с картиночного поиска на сайте услуг обычно немного, но если у вас блог с иллюстрациями к статьям, это заметная потеря, которую стоит закрыть редиректами по маске, а не поштучно.

Вес файлов. Импортёры медиатеки часто тянут оригинал изображения, а не оптимизированную версию, которая отдавалась на старом сайте через CDN конструктора. Я видел случаи, когда после переезда с Tilda средний вес изображения на странице вырастал с 80 КБ до 400 КБ, потому что Tilda автоматически сжимала и отдавала webp, а новый WordPress отдавал исходный JPEG в разрешении, в котором его когда-то залили в конструктор. Это не только вопрос скорости, тяжёлые картинки тянут вниз Core Web Vitals, а значит и позиции. Что с этим делать и какими форматами закрывать вопрос, я разбирал в статье про сжатие изображений в webp и avif.

Alt-тексты. Проверьте выборочно 10-15 картинок на разных типах страниц: карточки услуг, статьи блога, главная. Частая поломка, атрибут alt при импорте заполняется именем файла типа IMG_20260714_142233.jpg вместо смыслового текста, который был на старом сайте.

Технические файлы: robots.txt, sitemap, canonical и микроразметка

Здесь пять проверок, которые занимают пять минут, но их пропуск стоит недель индексации.

Файл или тег	Что проверить	Частая ошибка после переезда
robots.txt	Открыт ли сайт для индексации	Забытая строка `Disallow: /`, оставшаяся со стадии разработки на тестовом поддомене
sitemap.xml	Актуален ли, отдаёт ли реальные URL	Sitemap генерируется, но ссылается на staging-домен вместо боевого
rel=canonical	Указывает ли сам на себя	Canonical по умолчанию тянется от шаблона и ведёт на главную для всех страниц
RSS-лента	Работает ли `/feed` или аналог	Забыли перенести или отключили при миграции, а на неё были подписки и ссылки
Микроразметка	Есть ли Organization, Service, Article	Новый движок не генерирует schema.org вообще, старая была

Про sitemap отдельно: после переезда его нужно не просто проверить, а пересобрать и переотправить в Яндекс Вебмастер и Search Console вручную, не дожидаясь, пока поисковик найдёт новую версию сам. Как устроен файл и что в нём обязательно, я подробно разбирал в статье про карту сайта sitemap.xml.

Про canonical частый косяк отдельно заслуживает внимания: если движок ставит canonical по шаблону, а не программно от текущего URL, легко получить ситуацию, когда все страницы категории «услуги» технически говорят поисковику «настоящая версия этой страницы вот здесь» и указывают на первую попавшуюся. Пример из практики: после миграции интернет-магазина на новую версию движка у 40 карточек товара canonical ссылался на страницу категории, потому что шаблон карточки наследовал тег от родителя. Индекс просел на треть за десять дней, пока не нашли причину через выгрузку исходного кода всех страниц одним скриптом.

Скорость и мобильная версия: сравнение до и после

Соберите два отчёта PageSpeed Insights, один по нескольким ключевым страницам старого сайта (если он ещё жив на бэкапе или в архиве), второй по тем же страницам на новом движке. Сравните три метрики: LCP, CLS, время ответа сервера. Часто оказывается, что новая CMS технически современнее, но конкретная тема или сборка тяжелее старой конструкторской вёрстки: больше подключаемых шрифтов, больше JS-библиотек, которые тянутся ради одного слайдера на главной.

Отдельно прогоните мобильный тест: адаптивность на конструкторах вроде Tilda обычно настраивается визуально и предсказуемо, а на кастомной вёрстке WordPress можно случайно потерять точку перелома для планшетов, если тема собиралась и тестировалась только на телефоне и десктопе.

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

Вебмастер и Search Console: переотправка карты и мониторинг первые две недели

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

В Яндекс Вебмастере: раздел «Индексирование» и «Файлы Sitemap», переотправить актуальный sitemap.xml вручную, даже если адрес файла не изменился. В разделе «Переобход страниц» вручную отправить 15-20 самых важных URL (главная, топ-услуги, топ-статьи), это ускорит попадание изменений в индекс на несколько дней.

В Google Search Console: аналогично переотправить sitemap, дальше следить за отчётом «Страницы» (Coverage). Первую неделю имеет смысл заходить туда каждый день, вторую неделю раз в два-три дня. Смотрите на рост исключённых страниц: если число «Обнаружено, не проиндексировано» резко растёт, это обычно сигнал, что робот натыкается на технические проблемы, а не просто ждёт очереди.

Чек-лист на первые две недели после переезда:

[ ] Список старых URL выгружен и сохранён
[ ] Прогон всех старых URL, зафиксированы коды ответа
[ ] Редиректы 404 закрыты или осознанно оставлены
[ ] Title и description проверены на дубли и обрезки
[ ] Картинки: пути, вес, alt проверены выборочно
[ ] robots.txt открыт для индексации
[ ] sitemap.xml пересобран и содержит боевые адреса
[ ] canonical проверен на нескольких типах страниц
[ ] Микроразметка присутствует хотя бы в базовом виде
[ ] Скорость и мобильная версия сверены с состоянием до переезда
[ ] Sitemap переотправлен в Яндекс Вебмастере и Search Console
[ ] Отчёты об индексации проверяются ежедневно первую неделю

Что делать, если позиции всё равно просели

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

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

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

Что проверить после смены CMS

Что все старые адреса открываются или ведут на новые редиректом, что заголовки и описания не потерялись, что картинки на месте и не потяжелели, что карта сайта и robots.txt актуальны.

Как найти потерянные страницы

Взять старую карту сайта, прогнать список адресов и найти те, что отдают 404. Это самая быстрая проверка и самая полезная: именно эти страницы приносили трафик.

Сколько может проседать трафик

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

Что часто портится незаметно

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