Редизайн сайта часто воспринимается как визуальный проект: обновить интерфейс, сделать страницы удобнее, ускорить загрузку и перенести всё на современную CMS. С точки зрения SEO этого недостаточно.
При смене CMS или структуры сайта могут измениться URL, HTML-код, метатеги, внутренняя перелинковка, правила индексации, canonical, Sitemap и даже сам способ формирования контента. Для поисковой системы это уже не просто новый дизайн, а существенное изменение сайта.
Поэтому ситуация «после запуска сайт выглядит лучше, но органического трафика стало меньше» встречается довольно часто.
При этом сама миграция не означает обязательную потерю позиций. Риск появляется тогда, когда новая версия сайта перестает корректно передавать поисковым системам информацию о старой структуре.
Google рекомендует заранее подготовить соответствие старых и новых URL, настроить постоянные серверные редиректы, обновить внутренние ссылки и Sitemap, а после запуска отслеживать старые и новые адреса через Search Console. Ниже разберем, как организовать такую миграцию на практике.
Быстрая навигация по статье:
- Сначала зафиксируйте состояние старого сайта
- Составьте полный список URL
- Создайте карту соответствия URL
- Не меняйте URL без необходимости
- Проверьте старые страницы перед удалением
- Настройте постоянные редиректы
- Проверьте редиректы после запуска
- Перенесите не только тексты, но и SEO-данные
- Проверьте canonical
- Обновите внутреннюю перелинковку
- Проверьте robots.txt
- Проверьте noindex
- Обновите XML Sitemap
- Проверьте JavaScript
- Не забудьте про изображения
- Проверьте staging до публикации
- Проведите контрольный crawl
- Подготовьте Search Console
- Не запускайте новую версию без плана отката
- Контролируйте сайт сразу после запуска
- Какие показатели отслеживать после миграции
- Нормальное падение или техническая проблема?
- Самые частые ошибки при смене CMS
- Что делать, если после миграции резко упал трафик
- Миграция — хороший момент для проверки E-E-A-T
- Практическая схема безопасной миграции
- Чек-лист SEO-миграции
Что происходит с сайтом после смены CMS
Предположим, раньше статья находилась по адресу:
/blog/seo-migration
После перехода на новую CMS она стала доступна здесь:
/articles/seo-migration/
Для пользователя разница минимальна. Для поисковой системы это два разных URL.
Старая страница уже могла:
- получать органический трафик;
- иметь внешние ссылки;
- участвовать во внутренней перелинковке;
- находиться в индексе;
- ранжироваться по десяткам или сотням запросов;
- накапливать историю и поисковые сигналы.
Если просто удалить старый URL и опубликовать новый, поисковая система не обязана автоматически понять, что эти страницы являются продолжением друг друга.
Именно эту связь и необходимо правильно передать.
Google отмечает, что после значительного изменения сайта возможны временные колебания видимости, пока новые URL обнаруживаются, сканируются и обрабатываются. Для сайтов среднего размера процесс может занимать несколько недель или больше.
Когда миграция действительно становится SEO-риском
Не каждый переход на новую CMS требует масштабной миграции.
Если новый сайт сохраняет:
- домен;
- URL;
- содержание страниц;
- внутреннюю структуру;
- метаданные;
- перелинковку;
- технические настройки,
работа может свестись к проверке новой реализации.
Риск существенно возрастает, когда одновременно меняются несколько элементов:
- CMS;
- URL;
- структура разделов;
- домен;
- протокол;
- шаблоны страниц;
- контент;
- фильтры;
- pagination;
- canonical;
- robots.txt;
- Sitemap;
- JavaScript-логика.
Особенно сложным становится сценарий, когда компания одновременно запускает новый дизайн, меняет CMS, переписывает контент и перестраивает URL.
В случае падения трафика будет трудно определить, что именно стало причиной.
Поэтому крупные изменения желательно планировать поэтапно. Для больших сайтов Google также допускает перенос по частям, чтобы было проще контролировать проблемы.
Сначала зафиксируйте состояние старого сайта
До начала миграции нужно сохранить исходные данные. Это ваша точка сравнения.
Минимальный набор:
- список индексируемых URL;
- органический трафик по страницам;
- клики и показы;
- основные поисковые запросы;
- позиции приоритетных страниц;
- title;
- description;
- H1;
- canonical;
- robots directives;
- количество внутренних ссылок;
- Sitemap;
- страницы с внешними ссылками;
- изображения и важные файлы.
Для коммерческого сайта я бы дополнительно сохранил данные по конверсиям.
Например, страница может получать всего 300 органических переходов в месяц, но приносить больше заявок, чем информационная статья с 5000 посещений. Поэтому ориентироваться только на объем трафика недостаточно.
Составьте полный список URL
Это одна из самых важных частей подготовки. Источников URL должно быть несколько.
Используйте:
- XML Sitemap;
- Google Search Console;
- систему аналитики;
- данные CMS;
- краулер;
- серверные логи;
- внешние ссылки;
- внутренние ссылки.
Почему нельзя взять URL только из Sitemap?
Потому что Sitemap не всегда содержит абсолютно все адреса, которые когда-либо использовались сайтом.
Например, URL может:
- отсутствовать в текущем Sitemap;
- получать внешние ссылки;
- продолжать получать трафик;
- находиться в старых материалах;
- присутствовать в поисковом индексе.
Для миграции такие адреса тоже имеют значение.
Создайте карту соответствия URL
После сбора старых адресов составляется URL mapping.
Простейший вариант выглядит так:
| Старый URL | Новый URL | Статус | Действие |
| /blog/seo-migration | /blog/seo-migration/ | 301 | перенаправить |
| /services/seo | /services/technical-seo/ | 301 | перенаправить |
| /old-page | — | 404/410 | удалить |
| /category/seo | /blog/seo/ | 301 | перенаправить |
Такая таблица нужна не только SEO-специалисту. Она позволяет разработчику понять, какие правила необходимо реализовать на сервере, а контент-команде — какие страницы сохраняются, объединяются или удаляются.
Google также рекомендует заранее подготовить сопоставление старых и новых URL перед запуском переноса.
Не меняйте URL без необходимости
Новая CMS не является достаточной причиной для изменения адресов страниц. Если URL уже хорошо работает, получает трафик и внешние ссылки, его сохранение зачастую значительно упрощает миграцию.
Например, нет особой пользы менять:
/blog/seo/
на:
/articles/search-engine-optimization/
только потому, что новая CMS позволяет создать более длинную структуру.
Новый URL имеет смысл вводить тогда, когда он действительно решает конкретную задачу:
- исправляет архитектуру;
- устраняет дубли;
- упрощает навигацию;
- объединяет разделы;
- соответствует новой структуре бизнеса.
Любое изменение URL должно иметь понятную причину.
Проверьте старые страницы перед удалением
Старый контент часто удаляют слишком легко. Фраза «эта статья устарела» сама по себе еще не означает, что URL бесполезен.
Перед удалением проверьте:
- есть ли органический трафик;
- какие запросы приводит страница;
- есть ли внешние ссылки;
- сколько внутренних ссылок ведет на URL;
- есть ли потенциально полезный контент;
- можно ли обновить материал;
- существует ли релевантная новая страница.
Если старый материал объединяется с другим, редирект должен вести именно на страницу, которая действительно продолжает его тему.
Массово отправлять все удаленные страницы на главную не стоит. Google отдельно предупреждает, что нерелевантные редиректы могут восприниматься как soft 404. При объединении нескольких материалов один новый URL, наоборот, может быть корректной точкой назначения.
Настройте постоянные редиректы
Если URL изменился, старый адрес должен корректно передавать пользователя на новый.
Например:
https://site.ru/blog/old-article
↓ 301
https://site.ru/blog/new-article/
Google рекомендует использовать серверные постоянные редиректы, в частности 301 и 308, если это технически возможно. Важно не только наличие редиректа, но и его конечная точка.
Плохой вариант:
URL A
↓
URL B
↓
URL C
Лучше:
URL A
↓
URL C
Google рекомендует по возможности направлять пользователя сразу на конечный URL и избегать длинных цепочек.
Проверьте редиректы после запуска
Не ограничивайтесь выборочной проверкой.
Для крупных проектов проверку лучше автоматизировать.
В итоговой таблице полезно видеть:
| Старый URL | HTTP | Конечный URL | HTTP | Результат |
| /old-1 | 301 | /new-1 | 200 | OK |
| /old-2 | 301 | /new-2 | 200 | OK |
| /old-3 | 301 | /new-4 | 200 | проверить |
| /old-4 | 404 | — | — | проверить |
Особое внимание уделите страницам, которые до миграции получали значительный органический трафик или внешние ссылки.
Перенесите не только тексты, но и SEO-данные
При миграции часто происходит следующая ситуация.
Контент перенесли.
Дизайн перенесли.
Картинки перенесли.
А SEO-поля остались в старой CMS.
В результате новая страница получает другой:
- title;
- description;
- H1;
- canonical;
- robots;
- structured data.
Поэтому переносить нужно не только видимую часть страницы.
Для статей стоит проверить:
- заголовок;
- основной текст;
- автора;
- дату публикации;
- дату обновления;
- изображения;
- alt;
- внутренние ссылки;
- структурированные данные.
Для коммерческих страниц дополнительно:
- описание услуги;
- преимущества;
- цены;
- условия;
- контактную информацию;
- формы;
- связанные страницы.
Проверьте canonical
После миграции canonical особенно легко настроить неправильно.
Новая страница:
https://site.ru/blog/seo-migration/
должна иметь согласованный канонический URL.
Например:
<link rel="canonical" href="https://site.ru/blog/seo-migration/">
Проблемой будет ситуация, когда новая страница случайно указывает canonical на старый адрес.
Canonical является сигналом для выбора основной версии страницы, но Google может выбрать другую каноническую страницу, если считает ее более подходящей на основании совокупности сигналов.
Поэтому canonical необходимо проверять вместе с:
- редиректами;
- внутренними ссылками;
- Sitemap;
- доступностью страницы;
- содержанием.
Обновите внутреннюю перелинковку
После переноса внутренние ссылки должны указывать на новые URL напрямую.
Допустим, старая статья:
/blog/technical-seo
стала:
/blog/technical-seo-audit/
Не стоит оставлять сотни внутренних ссылок на старый адрес, чтобы пользователь каждый раз проходил через 301.
Лучше заменить их:
старый URL
↓
новый URL
непосредственно в HTML.
Проверьте:
- главное меню;
- хлебные крошки;
- статьи;
- категории;
- футер;
- блоки связанных материалов;
- страницы услуг;
- пагинацию;
- ссылки изображений.
Google прямо рекомендует обновлять внутренние ссылки при переносе сайта.
Проверьте robots.txt
Одна из классических ошибок миграции выглядит очень просто:
User-agent: *
Disallow: /
На тестовом сервере такая настройка может быть оправдана.
На рабочем сайте — уже нет.
После публикации проверьте:
- доступен ли robots.txt;
- нет ли случайного Disallow: /;
- не заблокированы ли важные разделы;
- указан ли актуальный Sitemap;
- совпадает ли файл с утвержденной SEO-конфигурацией.
Google отдельно указывает блокировку через robots.txt как одну из распространенных причин проблем при переносе.
Проверьте noindex
Еще один типичный сценарий:
На staging:
<meta name="robots" content="noindex">
После запуска директива остается.
В результате поисковый робот может посещать страницы, но они не должны попадать в индекс.
Проверяйте не только главную страницу, а выборку из каждого типа шаблона:
- статья;
- категория;
- услуга;
- товар;
- посадочная;
- фильтр;
- пагинация;
- мультиязычная страница.
Обновите XML Sitemap
После миграции Sitemap должен содержать новые канонические URL.
Если актуальная страница:
/blog/seo-migration/
то именно этот адрес должен находиться в Sitemap.
Не следует оставлять там старые URL, которые теперь возвращают 301.
После запуска новый Sitemap стоит отправить в Search Console. Google указывает Sitemap как один из способов помочь поисковой системе быстрее обнаружить новые URL при переносе.
Проверьте JavaScript
Современные CMS могут активно использовать JavaScript для формирования интерфейса.
Сам по себе JavaScript не является проблемой. Вопрос в другом: видит ли поисковая система основной контент и ссылки страницы?
После миграции стоит проверить:
- HTML;
- основной текст;
- заголовки;
- ссылки;
- canonical;
- structured data;
- изображения;
- навигацию.
Особенно внимательно нужно тестировать сайты, где новая CMS работает преимущественно через client-side rendering.
Не забудьте про изображения
Изображения тоже получают URL.
Например, было:
/images/blog/seo.jpg
стало:
/media/2026/09/seo.webp
Для сайта это может быть обычной технической заменой.
Но старые изображения могли:
- получать переходы из поиска;
- иметь внешние ссылки;
- использоваться на других страницах;
- присутствовать в индексах.
Поэтому при крупных переносах стоит составлять отдельный список важных медиа-URL.
Проверьте staging до публикации
Новый сайт необходимо просканировать до того, как он станет основной версией.
Проверяйте как минимум:
Индексацию
- нет случайного noindex;
- robots.txt не блокирует сайт;
- важные страницы доступны.
URL
- структура соответствует плану;
- редиректы подготовлены;
- нет циклов и длинных цепочек.
Метаданные
- title;
- description;
- H1;
- canonical.
Контент
- тексты на месте;
- изображения загружаются;
- ссылки работают.
Техническую часть
- HTTPS;
- HTTP-коды;
- мобильная версия;
- скорость;
- JavaScript;
- Sitemap.
Лучше обнаружить ошибку на staging, чем увидеть ее в Search Console после запуска.
Проведите контрольный crawl
Перед релизом полезно просканировать новую версию сайта краулером.
В отчете особенно интересны:
- 4xx;
- 5xx;
- redirect chains;
- redirect loops;
- broken links;
- duplicate titles;
- отсутствующие H1;
- неправильные canonical;
- noindex;
- orphan pages;
- чрезмерная глубина вложенности.
Отдельно проверьте страницы, которые являются источниками большей части органического трафика.
Подготовьте Search Console
До запуска убедитесь, что доступ к Search Console не потерян. Если меняется домен или субдомен, необходимо корректно оформить перенос соответствующего ресурса. Для смены домена Google предусматривает инструмент Change of Address; при изменениях внутри одного домена он не требуется.
После запуска Search Console становится одним из главных источников информации о состоянии миграции.
Не запускайте новую версию без плана отката
Резервная копия — обязательная часть миграции. Но полезно иметь не только backup базы данных.
Заранее определите:
- какую версию сайта можно восстановить;
- где находятся старые файлы;
- как вернуть старую CMS;
- кто отвечает за DNS;
- кто отвечает за сервер;
- кто может изменить redirect rules;
- кто принимает решение об откате.
Это особенно важно для коммерческих проектов, где даже несколько часов технических проблем могут быть критичными.
Контролируйте сайт сразу после запуска
Не стоит ждать неделю, чтобы впервые проверить новую версию. Первые проверки нужно сделать практически сразу.
Порядок может быть таким:
Запуск
↓
Проверка главной
↓
Проверка ключевых страниц
↓
Проверка HTTP-кодов
↓
Проверка редиректов
↓
Проверка robots.txt
↓
Проверка noindex
↓
Проверка canonical
↓
Проверка Sitemap
↓
Проверка Search Console
↓
Мониторинг логов и трафика
На этом этапе особенно важна скорость реакции. Если обнаружена массовая ошибка, лучше исправить ее через час после запуска, чем через неделю после того, как проблема уже повлияла на индексацию.
Какие показатели отслеживать после миграции
Общий график organic traffic — только один из показателей. Смотрите несколько уровней данных.
Индексация
Контролируйте:
- количество страниц;
- ошибки;
- исключенные URL;
- Sitemap;
- состояние ключевых страниц.
Органический трафик
Сравнивайте:
- весь organic;
- отдельные разделы;
- отдельные URL;
- брендовый и небрендовый трафик;
- коммерческие страницы;
- информационный раздел.
Search Console
Следите за:
- кликами;
- показами;
- CTR;
- средней позицией;
- поисковыми запросами.
Сервер
Отслеживайте:
- 404;
- 5xx;
- всплески нагрузки;
- обращения поисковых роботов;
- скорость ответа.
Для крупных проектов серверные логи особенно полезны: они показывают, какие URL действительно запрашиваются роботами, а не только какие страницы существуют в CMS.
Нормальное падение или техническая проблема?
После миграции позиции действительно могут колебаться. Это не обязательно означает ошибку.
Google прямо указывает, что при переносе сайта возможны временные изменения видимости, пока система повторно обрабатывает URL.
Но есть разница между временной нестабильностью и технической проблемой.
Например:
Органический трафик ↓
Индексация ↓
404 ↑
5xx ↑
старые URL не редиректятся
Это уже повод срочно искать техническую причину.
Другой сценарий:
Органический трафик ↓
Индексация стабильна
404 отсутствуют
301 работают
контент сохранен
Тогда нужно анализировать уже не только техническую часть, но и изменения структуры, контента, релевантности страниц и внутренних ссылок.
Самые частые ошибки при смене CMS
Редиректы настраивают после запуска
Сначала публикуется новая структура, затем несколько дней сайт живет с 404, и только после этого команда начинает создавать редиректы.
Так делать не стоит.
Redirect map должна быть подготовлена заранее.
Все старые страницы отправляют на главную
Это выглядит как простой способ избавиться от 404:
1000 старых URL
↓
Главная
Но такой подход не сохраняет смысл старых страниц. Если для старого материала существует релевантная новая версия — перенаправляйте туда.
Если такой страницы нет, иногда корректнее оставить URL удаленным.
Переносят дизайн, но забывают SEO
Новая CMS может выглядеть значительно лучше старой, но при этом потерять:
- title;
- H1;
- description;
- canonical;
- текст;
- внутренние ссылки;
- structured data.
Визуально сайт будет готов. SEO-миграция — нет.
Изменяют слишком много одновременно
Когда одновременно меняются:
- CMS;
- URL;
- контент;
- структура;
- дизайн;
- внутренняя перелинковка;
становится трудно определить причину изменений органики. Если проект позволяет, изменения лучше разделять.
Не проверяют тестовую версию
Staging может содержать:
noindex
или:
Disallow: /
и это нормально до момента запуска.
Проблема возникает, когда такие ограничения попадают на production.
Не обновляют внутренние ссылки
Даже если 301 работают правильно, внутренние ссылки должны вести непосредственно на новые URL.
Это уменьшает количество лишних переходов и упрощает структуру сайта.
Что делать, если после миграции резко упал трафик
Не начинайте с предположения, что «Google понизил сайт».
Сначала проверьте техническую цепочку.
Шаг 1. Проверить доступность
Открываются ли:
- главная;
- услуги;
- категории;
- статьи;
- товары.
Шаг 2. Проверить HTTP-коды
Есть ли массовые:
404
403
5xx
Шаг 3. Проверить редиректы
Работает ли:
старый URL
↓
301
↓
правильный новый URL
Шаг 4. Проверить индексацию
Нет ли случайного:
noindex
или блокировки в robots.txt.
Шаг 5. Проверить canonical
Не указывают ли новые страницы на старые URL.
Шаг 6. Проверить Sitemap
Содержит ли он актуальные канонические адреса.
Шаг 7. Проверить внутренние ссылки
Не осталась ли большая часть сайта привязанной к старой структуре.
Шаг 8. Сравнить потерявшие трафик страницы
Для каждой страницы сравните старую и новую версии:
- URL;
- title;
- H1;
- содержание;
- внутренние ссылки;
- canonical;
- robots;
- изображения;
- structured data.
Такой анализ обычно гораздо полезнее, чем сравнение только общего количества посетителей.
Миграция — хороший момент для проверки E-E-A-T
Технический перенос можно использовать не только для сохранения старых SEO-сигналов.
Если сайт информационный или экспертный, стоит заодно проверить качество авторских страниц.
Для материалов могут быть полезны:
- имя автора;
- профиль автора;
- информация об опыте;
- дата публикации;
- дата обновления;
- ссылки на источники;
- оригинальные исследования;
- реальные кейсы;
- описание методологии;
- информация о компании.
При этом не стоит пытаться создать E-E-A-T исключительно с помощью Schema.org.
Структурированные данные помогают поисковой системе интерпретировать информацию на странице, но не заменяют сам экспертный материал, опыт и другие сигналы доверия.
Практическая схема безопасной миграции
Удобно разделить работу на четыре этапа.
До разработки
SEO-аудит
↓
Сбор URL
↓
Анализ трафика
↓
Анализ ссылок
↓
Фиксация метаданных
Во время разработки
Новая архитектура
↓
URL mapping
↓
Перенос контента
↓
SEO-шаблоны
↓
Canonical
↓
Robots
↓
Sitemap
↓
Structured Data
Перед запуском
Crawl
↓
Проверка URL
↓
Проверка редиректов
↓
Проверка индексации
↓
Проверка ключевых страниц
↓
Backup
После запуска
HTTP-коды
↓
301/308
↓
robots.txt
↓
canonical
↓
Sitemap
↓
Search Console
↓
Логи
↓
Organic traffic
Чек-лист SEO-миграции
До начала работ
- Собран полный список URL
- Сохранены данные Search Console
- Сохранены данные аналитики
- Выделены страницы с максимальным трафиком
- Выделены страницы с внешними ссылками
- Зафиксированы title, description и H1
- Сохранен текущий Sitemap
- Проверены robots.txt и canonical
Подготовка новой версии
- Утверждена структура URL
- Создана таблица соответствий
- Подготовлены 301/308
- Перенесен контент
- Перенесены метаданные
- Настроены canonical
- Настроен robots.txt
- Создан новый Sitemap
- Обновлена внутренняя перелинковка
- Проверена структурированная разметка
Перед запуском
- Проведен crawl
- Исправлены 4xx и 5xx
- Проверены redirect chains
- Проверены noindex
- Проверены canonical
- Проверены ключевые страницы
- Сделана резервная копия
- Подготовлен план отката
После запуска
- Проверена главная страница
- Проверены основные разделы
- Проверены старые URL
- Проверены редиректы
- Проверен Sitemap
- Проверен robots.txt
- Проверена Search Console
- Отслеживаются 404
- Отслеживаются 5xx
- Контролируется органический трафик
- Анализируются серверные логи
Успешная SEO-миграция — это не перенос файлов из одной CMS в другую.
По сути, нужно перенести структуру поисковых сигналов, которую сайт накапливал годами.
У каждой ценной старой страницы должно быть понятное продолжение:
- сохранить тот же URL;
- либо создать новый URL и корректно связать его со старым;
- либо осознанно удалить страницу, если она действительно больше не нужна.
При этом все элементы должны работать согласованно: редиректы, внутренние ссылки, canonical, Sitemap, robots.txt, контент и настройки индексации.
После запуска не нужно ожидать идеально ровного графика позиций. Google предупреждает, что при переносе сайта временные колебания видимости являются нормальной частью процесса, а полная обработка большого количества URL может занять некоторое время.
Гораздо важнее другое: новая версия сайта должна быть технически доступной, логично связанной со старой структурой и понятной поисковой системе.
Хорошая миграция — это не просто новый сайт без 404. Это управляемая передача существующего SEO-капитала от старой версии сайта к новой.
