← ЖУРНАЛ KODERA

SEO / ≈ 5 МИН ЧТЕНИЯ

SEO-миграция сайта: перенос без потери важных страниц

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

Контрастная архитектура из стекла и чёрно-золотых поверхностей
ANALYTICS / VISUAL THINKING

01 / РАЗДЕЛ

Снимите карту текущих адресов

Соберите индексируемые URL, канонические адреса, метаданные, внутренние ссылки и страницы с органическим трафиком.

Не ограничивайтесь sitemap: часть важных адресов может присутствовать только во внутренних ссылках или поисковой выдаче.

02 / РАЗДЕЛ

Составьте таблицу соответствий

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

Не перенаправляйте все удалённые страницы на главную: это не помогает пользователю найти ожидаемый материал.

03 / РАЗДЕЛ

Проверьте окружение до релиза

На тестовом стенде проверьте маршруты, метатеги, каноникализацию, robots, sitemap и ссылки.

Убедитесь, что временные запреты индексации не попадут на рабочий сайт.

04 / РАЗДЕЛ

Контролируйте запуск

Проверьте HTTP-статусы, цепочки перенаправлений, основные формы, мобильную версию и доступность важных страниц.

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

Авторская иллюстрация к материалу: SEO-миграция сайта: перенос без потери важных страниц
KODERA / ИЛЛЮСТРАЦИЯ К ТЕМЕ МАТЕРИАЛА

05 / РАЗДЕЛ

Наблюдайте за результатом

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

Колебания после миграции возможны; диагностируйте причины по данным, а не по одной позиции в выдаче.

06 / РАЗДЕЛ

Сначала инвентаризируйте старые адреса

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

Не удаляйте старый контент без осознанного решения. Иногда страницу можно объединить с более сильной, иногда — обновить, а иногда она действительно устарела. Для каждой важной страницы укажите целевой новый адрес и причину переноса; пустые строки в таблице соответствий требуют отдельного обсуждения.

07 / РАЗДЕЛ

Настройте корректные перенаправления

Используйте постоянные перенаправления для окончательно переехавших адресов, ведите пользователя на наиболее близкую по смыслу страницу. Массовое перенаправление всех старых URL на главную почти всегда ухудшает опыт. Избегайте цепочек из нескольких переходов, циклов и ссылок на удалённые страницы. Список соответствий лучше хранить в репозитории или конфигурации инфраструктуры.

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

08 / РАЗДЕЛ

Проверьте тестовый контур до релиза

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

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

09 / РАЗДЕЛ

Подготовьте план релиза и отката

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

После запуска выполните автоматический обход старых адресов и проверьте коды ответов. Затем наблюдайте за ошибками 404, статистикой индексирования и переходами из поиска. Изменения видимости могут проявляться постепенно, поэтому делать вывод на следующий день по одному графику преждевременно.

10 / РАЗДЕЛ

Что считать успешной миграцией

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

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

11 / РАЗДЕЛ

Пример переноса большого каталога услуг

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

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

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

12 / РАЗДЕЛ

Практический протокол миграции

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

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

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