SEO и миграция
Перенос сайта без потери SEO, трафика и заявок
Безопасный перенос сохраняет соответствие старых и новых страниц, а не просто отправляет весь старый сайт на новую главную.
Коротко
Чтобы перенести сайт без потери SEO, выгрузите все индексируемые URL и показатели до миграции, составьте карту соответствий один к одному, сохраните важный контент и метаданные, настройте серверные 301-редиректы, обновите внутренние ссылки, canonical, sitemap и robots.txt, перенесите аналитику и формы, а после запуска контролируйте ответы сервера, обход, индексирование и органический трафик минимум несколько недель.
Зафиксируйте исходное состояние сайта
До изменения домена, CMS или структуры сохраните полный список доступных URL. Источники нужно объединить: sitemap, выгрузку CMS, данные поисковых систем, аналитику, логи и внутренний обход. Один источник почти всегда неполный.
Для каждой страницы сохраните код ответа, canonical, title, description, H1, индексируемость, органические показы, клики, входы, конверсии и внешние ссылки. Так команда понимает, какие URL нельзя потерять и чем проверять результат.
Отдельно зафиксируйте формы, события аналитики, номера телефонов, email, цели, schema-разметку и файлы для скачивания. Потеря заявок после красивого редизайна опаснее временной просадки видимости.
- Полный список URL и кодов ответа.
- Страницы с органическим трафиком и конверсиями.
- Title, description, H1, canonical и robots.
- Внешние ссылки и важные посадочные страницы.
- Формы, цели, события и источники лидов.
- Изображения, документы и другие индексируемые файлы.
Составьте карту соответствий старых и новых URL
Каждый старый URL должен получить наиболее близкую новую страницу. Если услуга сохранилась, редирект ведёт на её новую версию. Если две слабые страницы объединены, обе могут вести на сильную объединённую страницу. Если эквивалента нет, иногда корректнее вернуть 404 или 410, чем отправить пользователя на нерелевантную главную.
Карта должна учитывать параметры, версии со слешем и без, HTTP/HTTPS, www, регистр, старые файлы и поддомены. Сначала нормализуют адреса, затем проверяют дубли.
Внутренние ссылки нужно сразу заменить на конечные новые URL. Сайт не должен постоянно ходить через редирект сам на себя.
| Старый URL | Новый URL | Решение |
|---|---|---|
| /services/site/ | /services/web-development/ | 301 на релевантную услугу |
| /old-case/ | /cases/project/ | 301 на обновлённый кейс |
| /articles/topic-1/ | /blog/topic/ | 301 после объединения контента |
| /expired-promo/ | Нет аналога | 404/410 или релевантный раздел по смыслу |
| http://example.ru/page | https://example.ru/page | Один 301 без цепочки |
Настройте серверные редиректы без цепочек
Google рекомендует постоянные серверные редиректы со старых URL на новые и советует сохранять их как можно дольше, обычно не менее года. Яндекс также требует переносить внутренние страницы на соответствующие новые адреса и не сводить весь сайт к главной.
Редирект должен вести сразу к конечному URL. Цепочка старый HTTP → старый HTTPS → новый HTTP → новый HTTPS замедляет обход и усложняет диагностику. Циклы делают страницу недоступной.
Canonical на новых страницах должен указывать на них самих. XML Sitemap содержит только конечные индексируемые URL с ответом 200. Robots.txt не блокирует новые страницы и файлы, необходимые для рендеринга.
| Элемент | До запуска | После запуска |
|---|---|---|
| 301 | Проверить карту на стенде | Проверить старые URL пакетно |
| Canonical | Новые адреса | Нет ссылок на старый домен |
| Sitemap | Собрать новые URL | Отправить в панели вебмастеров |
| Robots.txt | Разрешить production | Проверить доступ робота |
| Внутренние ссылки | Заменить в шаблонах | Нет переходов через 301 |
Что проверить в день запуска
Сначала откройте сайт без кэша и проверьте главный пользовательский путь на desktop и mobile. Затем пакетно проверьте коды новых страниц и старые URL. Нельзя ограничиваться главной.
Перенесите счётчики, цели, ecommerce, телефонию и CRM-интеграции. Сделайте реальные тестовые заявки с разных форм. Источник, URL и UTM должны попасть к менеджеру.
В Яндекс Вебмастере и Google Search Console отправьте новые sitemap. При смене домена используйте предусмотренный инструмент переезда после подтверждения обоих ресурсов и проверки редиректов.
- Заморозить измененияНе менять структуру параллельно с публикацией.
- Развернуть новую версиюПроверить HTTPS, домен, кэш и окружение.
- Проверить 200 и 301Пройти выборку важных и случайных URL.
- Протестировать заявкиПроверить форму, уведомление, CRM и аналитику.
- Отправить sitemapОбновить панели поисковых систем.
- Снять контрольный отчётЗафиксировать дату и состояние сразу после релиза.
Как контролировать миграцию после запуска
В первые дни проверяйте ошибки сервера, 404, редиректы и реальные заявки ежедневно. Затем сравнивайте индексирование, показы, клики и целевые страницы еженедельно. Просадка отдельной страницы важнее средней цифры по всему сайту.
Смотрите, какие старые URL продолжает обходить робот и куда они ведут. Новые 404 добавляйте в карту только при наличии релевантной цели. Не превращайте отчёт об ошибках в автоматический редирект всего на главную.
Сопоставляйте трафик с конверсиями. Если видимость сохранилась, а обращения упали, проблема может быть в форме, мобильной версии или изменившемся оффере.
| Период | Что смотреть | Действие |
|---|---|---|
| Первые 72 часа | 5xx, формы, аналитика, критичные 404 | Исправлять сразу |
| 1–2 недели | Обход, новые URL, цепочки редиректов | Обновлять карту |
| 3–6 недель | Показы, клики, позиции, целевые страницы | Разбирать отклонения |
| 2–3 месяца | Конверсии и качество трафика | Улучшать страницы по данным |
Ошибки, из-за которых миграция теряет трафик
Самые опасные ошибки — закрытый robots.txt от тестового стенда, отсутствие карты URL, редирект всех страниц на главную, новый canonical на старый домен, удаление сильного контента и неработающие формы.
Не меняйте одновременно домен, CMS, дизайн, структуру, тексты и бизнес-модель без необходимости. Чем больше переменных, тем труднее понять причину просадки. Если большой редизайн неизбежен, отдельно сохраните поисковое соответствие страниц.
Для подготовки можно заказать SEO-аудит и сопровождение миграции или техническую поддержку запуска. Технический процесс разработки описан на странице веб-разработки.
Цель миграции — не сохранить старую структуру любой ценой, а сохранить смысл каждой сильной страницы и понятный путь пользователя.
FAQ
Частые вопросы
01Будет ли просадка после переноса сайта?
Небольшие колебания возможны, пока поисковые системы переобходят адреса. Глубина и длительность зависят от качества соответствий, редиректов, доступности и сохранения контента.
02Нужно ли редиректить все старые URL?
Все ценные и имеющие релевантный аналог — да. Для удалённой страницы без близкой замены корректный 404/410 может быть лучше нерелевантного редиректа.
03Сколько держать 301-редиректы?
Google рекомендует сохранять их как можно дольше, обычно не менее года. Для старых внешних ссылок и закладок разумно держать редиректы дольше.
04Можно ли менять домен и дизайн одновременно?
Можно, но риск и сложность диагностики растут. Обязательно сохраните карту URL, важный контент, метаданные и аналитику, а изменения проверяйте на стенде.
Источники и документация
Материал подготовлен редакцией ХЭМС на основе проектной практики. Цены и технические условия актуальны на дату публикации и уточняются после разбора задачи.
Обсудить проект
Перенесём сайт с контрольной картой
Соберём старые URL, настроим соответствия, проверим формы и будем контролировать индексирование после запуска.