Чтобы перенести сайт без потери позиций, нужно сохранить доступность и содержание значимых страниц, настроить прямые 301-редиректы со старых URL на соответствующие новые адреса, перенести метаданные и внутренние ссылки, а затем проконтролировать индексацию. Полностью исключить временные колебания трафика нельзя, но подготовка и поэтапная проверка существенно снижают риски.
Ниже — пошаговая инструкция для переноса на другой домен, CMS, протокол или новую структуру. Она поможет составить карту URL, подготовить техническое задание, провести запуск и понять, какие показатели отслеживать после миграции.
Какие виды переноса влияют на SEO
Переносом сайта часто называют разные изменения. Их риски и набор обязательных работ отличаются:
- Смена домена. Меняются адреса всех страниц, поэтому поисковым системам необходимо передать сигналы со старого домена на новый.
- Переход с HTTP на HTTPS. Адреса также меняются, хотя доменное имя остается прежним. Требуются редиректы, обновление внутренних ссылок и проверка сертификата.
- Смена CMS или технологической платформы. URL могут остаться прежними, но есть риск потерять контент, метатеги, микроразметку, правила индексации и функциональность страниц.
- Изменение структуры. Перенос разделов, новая вложенность и другой формат URL требуют точного сопоставления старых и новых страниц.
- Редизайн. Даже без смены адресов позиции могут измениться, если сокращен текст, удалены навигационные блоки, ухудшилась скорость или важный контент стал недоступен поисковому роботу.
- Переезд на другой сервер. При сохранении домена и URL поисковые риски обычно связаны с доступностью, временем ответа, настройкой DNS и конфигурацией сервера.
Самый рискованный сценарий — одновременная смена домена, CMS, структуры и содержания. Если проект позволяет, крупные изменения лучше разделять на этапы. Такой подход упрощает диагностику: при снижении видимости легче определить причину.
Шаг 1. Проведите аудит и зафиксируйте исходные данные
До начала разработки необходимо сохранить сведения о текущем состоянии сайта. Без исходных данных команда не сможет проверить полноту переноса и отличить последствия миграции от проблем, существовавших раньше.
Соберите перечень всех известных URL из нескольких источников:
- выгрузка страниц с помощью краулера;
- XML-карты сайта;
- отчеты систем веб-аналитики;
- отчеты панелей для вебмастеров;
- страницы с показами и переходами из поиска;
- URL, на которые ведут внешние ссылки;
- адреса из базы данных или CMS.
Один источник не дает полной картины. Например, краулер не всегда найдет страницы без внутренних ссылок, а аналитика не покажет URL без посещений за выбранный период.
Для каждого адреса желательно зафиксировать код ответа, canonical, robots directives, title, description, H1, объем и тип контента, глубину вложенности, органический трафик и наличие внешних ссылок. Отдельно отметьте коммерчески важные и трафиковые страницы: их нужно проверять в первую очередь.
Перед переносом также сохраните базовые показатели: видимость по приоритетным запросам, органический трафик по посадочным страницам, число индексируемых URL, конверсии и серверные характеристики. Сравнивать следует сопоставимые периоды с учетом сезонности и изменений спроса.
Не закрывайте старый сайт сразу после запуска нового. Старый домен и серверная конфигурация должны оставаться под контролем, чтобы редиректы продолжали работать и их можно было исправить.
Шаг 2. Составьте карту соответствия URL
Карта редиректов — таблица, в которой каждому старому адресу назначен релевантный новый URL. Это основной документ для переноса структуры или домена.
| Старый URL | Новый URL | Действие | Комментарий |
|---|---|---|---|
| /catalog/item-a/ | /products/item-a/ | 301 | Товар сохранен |
| /services/old/ | /services/new/ | 301 | Услуга заменена близкой по смыслу |
| /news/event/ | — | 410 или 404 | Материал удален, аналога нет |
Лучший вариант — соответствие один к одному: старая страница направляет пользователя и робота на новую страницу с тем же назначением. Массовая переадресация всех удаленных URL на главную не заменяет карту соответствий. Такой редирект не помогает найти нужный материал и может восприниматься как нерелевантный.
Если точного аналога нет, выберите ближайшую по смыслу страницу. Когда подходящей замены не существует, корректнее вернуть 404 или 410 и удалить URL из внутренних ссылок и XML-карты. Редирект на случайный раздел создает плохой пользовательский путь и затрудняет обработку сайта поисковыми системами.
Используйте постоянный серверный редирект 301 для окончательно перемещенных страниц. Каждый старый URL должен вести сразу на конечный новый адрес. Цепочка вида «старый URL → промежуточный URL → новый URL» увеличивает число запросов, замедляет обход и усложняет поддержку.
Проверьте варианты адресов с параметрами, разным регистром, завершающим слешем, префиксом www и без него. Правила не должны создавать циклы или направлять несколько разных страниц на нерелевантный общий URL.
Шаг 3. Подготовьте новую версию к индексации
Новый сайт нужно проверять на тестовом окружении, закрытом от индексации. При этом блокировка не должна мешать специалистам и краулеру проводить технический аудит. Перед запуском временные ограничения необходимо снять.
На новую версию переносят не только тексты и изображения. Для поисковой видимости важны следующие элементы:
- title, description и заголовки страниц;
- основной и дополнительный контент;
- атрибуты изображений и документы для скачивания;
- canonical и директивы robots;
- структурированные данные;
- хлебные крошки и внутренняя перелинковка;
- пагинация, фильтры и правила обработки параметров;
- мультиязычные связи, если сайт представлен на нескольких языках;
- коды аналитики, цели и события.
Все внутренние ссылки должны вести на новые конечные URL без перехода через редирект. Это касается меню, логотипа, хлебных крошек, ссылок в текстах, карточек, пагинации, canonical, XML-карты и адресов в структурированных данных.
Сравните старую и новую версии по шаблонам. Важно проверить главную страницу, категории, карточки товаров или услуг, статьи, контакты, страницы фильтров и другие типы URL. Ошибка в одном шаблоне способна затронуть весь раздел.
Отдельного внимания требует JavaScript. Значимый контент, ссылки и метаданные должны быть доступны поисковым системам в итоговом HTML. Если новая платформа использует клиентский рендеринг, нужно проверить, видит ли робот те же элементы, что и пользователь.
Перед запуском проведите полный обход тестовой версии и найдите:
- внутренние ссылки с кодами 3xx, 4xx и 5xx;
- страницы, случайно закрытые от индексации;
- canonical на тестовый домен или старые адреса;
- дубли title и заголовков;
- пустые страницы и потерянный контент;
- ошибки мобильной версии;
- существенное ухудшение скорости и стабильности интерфейса;
- формы, корзину, поиск и другие неработающие функции.
Шаг 4. Выполните перенос в правильной последовательности
Дата запуска должна учитывать доступность разработчиков, SEO-специалиста, администратора сервера и аналитика. Не стоит проводить миграцию перед периодом максимального спроса или в момент, когда команда не сможет оперативно исправлять ошибки.
- Создайте резервные копии. Сохраните файлы, базу данных, конфигурацию сервера, правила редиректов и настройки аналитики.
- Подготовьте DNS и сервер. Новый хостинг должен выдерживать рабочую нагрузку, а сертификат — корректно действовать для нужных вариантов домена.
- Разверните проверенную версию. Убедитесь, что на рабочий сервер попала именно та сборка, которая прошла аудит.
- Снимите временные запреты. Проверьте robots.txt, meta robots, HTTP-заголовки и ограничения доступа. Частая ошибка — оставить на рабочем сайте noindex или блокировку из тестовой среды.
- Включите 301-редиректы. Протестируйте приоритетные URL и случайную выборку из каждого типа страниц.
- Обновите служебные файлы. XML-карта должна содержать только канонические новые URL с успешным кодом ответа. В robots.txt указывают актуальный адрес карты сайта.
- Проверьте аналитику. Просмотры, события, формы, звонки и транзакции должны фиксироваться после запуска так же корректно, как до него.
- Добавьте новую версию в панели вебмастеров. Подтвердите права на домен или нужные варианты протокола и отправьте новую XML-карту. При смене домена используйте доступные инструменты уведомления о переезде.
После переключения выполните обход нового сайта и отдельно проверьте список старых URL. Старые страницы должны возвращать предусмотренный ответ: прямой 301 на релевантный адрес либо 404/410, если материал удален без замены.
Шаг 5. Контролируйте индексацию и находите отклонения
Работа не заканчивается в момент запуска. В первые дни проверка должна быть чаще, затем периодичность можно снижать. Продолжительность наблюдения зависит от размера сайта, частоты обхода и масштаба изменений.
Контролируйте четыре группы показателей:
- Доступность. Ошибки 5xx, время ответа, нагрузка на сервер, сбои DNS и сертификата.
- Обход и индексация. Активность поисковых роботов, число обработанных новых URL, исключенные страницы, ошибки XML-карты.
- Поисковая эффективность. Показы, клики, позиции и органический трафик по отдельным посадочным страницам и типам шаблонов.
- Бизнес-показатели. Заявки, продажи и другие целевые действия из органического поиска.
Небольшие временные колебания после изменения URL возможны: поисковым системам требуется обойти редиректы, сопоставить страницы и обновить индекс. Продолжительное или резкое падение требует диагностики, а не ожидания.
Сначала проверьте страницы, которые раньше приносили больше всего органического трафика. Типовые причины снижения — отсутствующий редирект, неверный canonical, запрет индексации, потеря текста, изменение интента страницы, удаление внутренних ссылок, серверные ошибки или существенное ухудшение производительности.
Редиректы не следует удалять сразу после переиндексации. Старые URL могут долго оставаться в закладках, документах, внешних ссылках и базах поисковых систем. Если старый домен использовался для почты или других сервисов, его дальнейшее обслуживание также нужно учесть.
Для сложной миграции полезно заранее включить технический аудит и мониторинг в план SEO-продвижения сайта. Это позволяет связать технические изменения с динамикой посадочных страниц и поискового спроса, а не оценивать перенос только по общему трафику.
Чек-лист безопасного переноса
Краткий список помогает принять работу перед запуском и не пропустить критические настройки:
- собраны URL из краулинга, аналитики, XML-карт и панелей вебмастеров;
- зафиксированы позиции, трафик, конверсии и индексируемые страницы;
- составлена и проверена карта соответствия старых и новых URL;
- значимый контент, метатеги и структурированные данные перенесены;
- внутренние ссылки ведут сразу на новые канонические адреса;
- 301-редиректы не образуют цепочек и циклов;
- robots.txt, meta robots и canonical не закрывают рабочие страницы;
- XML-карта содержит только актуальные индексируемые URL;
- аналитика и целевые действия работают на новой версии;
- настроен контроль ошибок сервера, индексации, трафика и конверсий;
- старый домен и правила редиректов остаются под управлением владельца сайта.
Частые вопросы
Можно ли гарантированно перенести сайт без просадки позиций?
Гарантировать полное отсутствие колебаний нельзя. На результат влияют масштаб изменений, качество редиректов, сохранность контента, скорость обхода и состояние сайта до миграции. Подготовка сокращает риск и ускоряет обнаружение ошибок.
Нужно ли сохранять старую структуру URL?
Если структура понятна и не мешает развитию сайта, сохранение URL уменьшает объем изменений. Менять адреса стоит при объективной необходимости, например из-за новой архитектуры каталога или технических ограничений платформы.
Что делать со страницами, которых нет на новом сайте?
При наличии близкого аналога настройте 301-редирект на него. Если равноценной замены нет, верните 404 или 410, удалите адрес из внутренней перелинковки и XML-карты. Не направляйте все удаленные страницы на главную.
Сколько времени хранить редиректы?
Единого срока для всех проектов нет. Редиректы следует сохранять длительно, особенно если на старые URL ведут внешние ссылки или ими продолжают пользоваться посетители. При смене домена безопаснее поддерживать старый домен и переадресацию постоянно.
Можно ли одновременно менять домен, CMS и дизайн?
Технически можно, но диагностика становится сложнее, а число потенциальных причин снижения растет. Если нет жестких ограничений, разделите изменения на этапы и оценивайте результат каждого этапа отдельно.
Когда перенос лучше отложить?
Миграцию стоит перенести, если не готова карта URL, не протестированы редиректы, новая версия закрыта от полноценного аудита, не настроена аналитика или команда не сможет контролировать сайт после запуска.
