SEO-миграция без потерь: чек-лист для безопасного переноса сайта

Безопасная миграция сайта зависит от одного решения больше, чем от любого другого: каждый проиндексированный URL старого сайта должен быть сопоставлен с тематически эквивалентным URL на новом сайте и перенаправлен с кодом состояния 301 (или 308). Восстановление обычно занимает от 2 до 8 недель при хорошо выполненном переносе, при этом Джон Мюллер из Google утверждает, что стабилизация ранжирования может длиться от 4 до 12 недель в зависимости от масштаба. Исследование Ahrefs за 2025 год показало, что примерно 60% миграций приводят к измеримой потере органического трафика, а отдельный анализ 892 миграций, процитированный Search Engine Journal, показал, что среднее время восстановления трафика до уровня до миграции составляет 523 дня. Разница между коротким и длинным окном почти полностью определяется качеством сопоставления URL и логики перенаправлений.

Остальная часть этой статьи рассматривает типы миграций, которые несут наибольший SEO-риск, временные рамки, на которые следует ориентироваться, пошаговый чек-лист, настройку перенаправлений для Apache и Nginx, инструмент «Смена адреса» в Google Search Console, а также ошибки, которые превращают рутинный перенос в измеримое событие, влияющее на доход.

Типы миграций и их профиль SEO-риска

В Google Search Central перечислены семь сценариев миграции, которые изменяют URL: смена протокола, смена имени хоста, смена домена, смена поддомена или подкаталога, смена структуры сайта, полная замена сайта и смена системы управления контентом. Каждый из них несет разный уровень SEO-риска. Требуемый чек-лист масштабируется в зависимости от риска.

Тип миграции	SEO-риск	Основные необходимые шаги
Смена протокола (HTTP на HTTPS)	Средний	Перенаправления 301, обновление канонических URL, HTTPS-карта сайта, устранение смешанного контента
Смена имени хоста (www на без www или наоборот)	Низкий – Средний	Перенаправления 301, обновление канонических URL, добавление свойства в GSC
Смена домена	Высокий	Полное сопоставление URL, перенаправления 301, инструмент «Смена адреса», карта сайта, свойства GSC для обоих доменов
Изменение структуры URL	Высокий	Перенаправления 301 на основе шаблонов, переписывание внутренних ссылок, обновление канонических URL, карта сайта
Смена CMS или платформы	Высокий	Сопоставление URL (часто невозможно 1:1), перенаправления 301, проверка структурированных данных, контроль качества шаблонов
Перестройка дизайна с сохранением URL	Низкий	Аудит внутренних ссылок, проверка производительности, верификация структурированных данных
Объединение или разделение	Очень высокий	Ручное сопоставление, проверка контента, возможные коды 410 для удаленных страниц, перестроение карты сайта

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

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

Три фазы графика миграции

Миграция — это не единичное событие. Это проект, включающий предмиграционную фазу, переход и послемиграционный период мониторинга. Для сайта среднего размера планируйте от 8 до 16 недель в общей сложности, примерно в следующем соотношении.

Предмиграционная фаза охватывает аудит, сбор базовых показателей, сопоставление URL, подготовку правил перенаправления, контроль качества контента на новой платформе и проверку заинтересованными сторонами. Обычно это занимает от 4 до 10 недель. Сам переход — это день или неделя, когда изменяются DNS, активируются перенаправления и новый сайт заменяет старый. Переход при запланированном переносе часто выполняется в выходные или в единое окно с низкой нагрузкой. Послемиграционная фаза включает верификацию и мониторинг, длится от 3 до 6 месяцев и именно здесь большая часть SEO-работы либо окупается, либо проваливается.

Упомянутый выше период восстановления от 2 до 8 недель находится внутри послемиграционной фазы. Легкие миграции (обновление дизайна, смена имени хоста) могут стабилизироваться за 2–3 недели. Более тяжелые миграции (смена домена с изменением структуры URL) часто требуют полных 8 недель для стабилизации, при этом отчеты Search Console могут продолжать колебаться в течение нескольких месяцев после.

Предмиграционный чек-лист: базовые показатели и план

Предмиграционная фаза — это этап, на котором устраняется большая часть рисков. Работа здесь неприметна и в значительной степени невидима для тех, кто не смотрит в Search Console, но именно она определяет разницу между чистым восстановлением и постоянными потерями.

Соберите базовые метрики существующего сайта. Выгрузите данные об органическом трафике за последние 12 месяцев по посадочным страницам из Google Analytics 4 или вашей аналитической платформы. Экспортируйте лучшие запросы по URL из Search Console. Запишите количество проиндексированных страниц из отчета об индексации. Сохраните снимок средней позиции по запросам для топ-100–500 запросов. Запустите проверку Core Web Vitals и сохраните результаты. Эти цифры будут набором для сравнения всего последующего.

Выполните полный обход сайта и задокументируйте текущее состояние. Используйте краулер, такой как Screaming Frog или Sitebulb, чтобы извлечь каждый URL, код состояния, канонический тег, мета-описание, заголовок, H1, аннотации hreflang и количество внутренних ссылок. Сохраните экспорт. Этот файл является источником истины, с которым будет сравниваться новый сайт.

Постройте карту URL. Это самый важный шаг с точки зрения эффективности. Для каждого URL в результатах обхода, возвращающего статус 200, определите его назначение на новом сайте. Большинство должны сопоставляться 1:1 с тематическим эквивалентом. Некоторые будут сопоставляться многие-к-одному (объединение). Небольшое количество будет удалено и должно быть помечено для ответа 410. Избегайте сопоставления несвязанных URL с главной страницей, так как Google может рассматривать перенаправления только на главную как мягкие ошибки 404 и удалять передаваемую сигнальную ценность.

Задокументируйте правила перенаправления. Сгруппируйте карту URL в правила на основе шаблонов, где это возможно. Изменение с /blog/category-name/post-slug на /articles/category-name/post-slug может быть реализовано одним регулярным выражением. Элементы, которые нельзя шаблонизировать, должны быть в явном списке «один к одному». Полный набор станет конфигурацией .htaccess или Nginx.

Создайте новую XML-карту сайта. Сгенерируйте sitemap.xml для нового сайта, перечисляя только канонические URL, которые возвращают 200. Карта сайта не должна включать перенаправленные URL, URL с noindex или URL, возвращающие коды ошибок.

Проверьте robots.txt для обеих сторон миграции. robots.txt нового сайта не должен блокировать URL, которые необходимо сканировать. Убедитесь, что среда для тестирования имеет правило Disallow: / или защиту паролем, чтобы Google не проиндексировал её до запуска. Запланируйте замену robots.txt во время перехода.

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

Проверьте аннотации hreflang на интернационализированных сайтах. Каждый тег hreflang на новом сайте должен ссылаться на новые URL, а не на старые. Кросс-языковые пары должны оставаться взаимными. Несогласованные теги hreflang и канонические теги — одна из наиболее распространенных причин сбоев при многоязычных миграциях, которая выявляется в отчете Search Console «Интернациональная адресация» после запуска.

Проверьте структурированные данные. Разметка Schema.org, которая работала на старом сайте, должна быть воспроизведена или улучшена на новом. Запустите тест расширенных результатов на выборке шаблонов до запуска. Ошибки схемы при переходе являются частой причиной потери расширенных результатов.

Настройте новое свойство в Google Search Console. Для смены домена или имени хоста добавьте свойство нового домена и подтвердите его до перехода. Инструмент «Смена адреса» требует, чтобы оба свойства (старое и новое) существовали и были доступны под одной учетной записью Google. Одновременно настройте свойство в Bing Webmaster Tools, если трафик из Bing значим.

Проверьте, что все работает: новое свойство в Search Console должно отображаться как подтвержденное, при этом одна и та же учетная запись электронной почты имеет доступ к обоим свойствам.

Спланируйте стек мониторинга. Определите, какие панели будут проверяться ежедневно в первые две недели после перехода. Минимум: отчет «Покрытие» в Search Console, отчет «Эффективность» (показы, клики, средняя позиция), органический трафик в Google Analytics, серверные лог-файлы для анализа поведения краулеров и мониторинг доступности.

Проведите предзапусковую проверку качества нового сайта. При все еще активной защите паролем на тестовом сайте просканируйте новый сайт так, как это сделал бы Googlebot. Убедитесь, что все канонические теги ведут на реальные URL (а не на тестовые, что является частой ошибкой при запуске). Убедитесь, что не осталось мета-тегов noindex с тестового сайта. Убедитесь, что robots.txt не блокирует важные пути.

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

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

Запустите конфигурацию перенаправлений. Разверните .htaccess, конфигурацию Nginx или карту перенаправлений платформы. Перенаправления должны возвращать статус 301 (или 308), а не 302.

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

Обновите DNS, если меняется домен или имя хоста. Снизьте TTL для DNS-записей за 24–48 часов до переключения, чтобы распространение было быстрым.

Отправьте новую карту сайта. Добавьте URL-адрес нового sitemap.xml в новый ресурс Search Console и запросите повторное сканирование. Отправьте карту сайта в Bing, если это применимо.

Запустите инструмент «Смена адреса». Это относится только к перемещениям на уровне домена. Инструмент выполняет предварительные проверки и подтверждает, что с прежнего домена настроены редиректы 301.

Протестируйте выборку редиректов с помощью curl или инструмента проверки редиректов. Убедитесь, что репрезентативные URL-адреса возвращают ожидаемый код 301 и что целевой URL-адрес возвращает 200. Короткий shell-скрипт может проверить от 50 до 200 редиректов и отметить неудачные.

Начните период мониторинга. С момента переключения отслеживайте данные Search Console Coverage, серверные логи и аналитику трафика на новом домене. Первые 72 часа обычно показывают наибольшие колебания в количестве проиндексированных страниц и частоте сканирования.

Реализация редиректов: Apache и Nginx

Серверные редиректы 301 являются канонической реализацией. Клиентские редиректы (meta refresh, JavaScript) медленнее и менее надежны для SEO, и документация Google отдает предпочтение серверным.

Для серверов Apache с mod_rewrite правила редиректов размещаются в файле .htaccess в корне документа или в основной конфигурации сервера. Ниже приведен пример редиректа на уровне домена.

# Перенаправление всего старого домена на новый с сохранением пути RewriteEngine On RewriteCond %{HTTP_HOST} ^(www.)?oldsite.com$ [NC] RewriteRule ^(.*)$ https://newsite.com/$1 [L,R=301] # Изменение шаблона URL в пределах одного домена RedirectMatch 301 ^/blog/(.*)$ /articles/$1 # Конкретные редиректы «один к одному» Redirect 301 /old-page.html /new-page/ Redirect 301 /retired-product/ /products/

Для Nginx редиректы настраиваются в server block конфигурационного файла сайта. Ниже приведен аналогичный пример.

# Перенаправление всего старого домена на новый server { listen 80; listen 443 ssl; server_name oldsite.com www.oldsite.com; return 301 https://newsite.com$request_uri; } # Изменение шаблона URL в новом server block server { listen 443 ssl; server_name newsite.com; location ~ ^/blog/(.*)$ { return 301 /articles/$1; } location = /old-page.html { return 301 /new-page/; } }

После развертывания на Nginx выполните nginx -t, чтобы проверить конфигурацию перед перезагрузкой. На Apache синтаксические ошибки в .htaccess возвращают ошибку 500, а не отказ загружаться, поэтому проверка с помощью curl более важна.

Простая команда проверки:

curl -I -L https://oldsite.com/old-page.html

Флаг -I возвращает только заголовки, а -L переходит по цепочке редиректов. В ответе должен отображаться один переход 301 на новый URL-адрес, за которым следует 200 от целевого адреса. Два или более переходов 301 подряд указывают на цепочку редиректов, чего, согласно документации Google, следует избегать. Цепочки длиннее 3 переходов могут привести к тому, что Googlebot прекратит их отслеживание.

Контрольный список после миграции: проверка и мониторинг

Работа после переключения повторяется и основана на данных. Первые две недели — ежедневные проверки. Следующие 8–12 недель — еженедельные проверки. Для крупных миграций период продлевается до 6 месяцев.

Сканируйте новый сайт и сравните с базовым уровнем до миграции. Запустите тот же сканер, который использовался на этапе 1. Убедитесь, что количество проиндексированных страниц находится в пределах 5–10% от базового (некоторые отклонения ожидаемы, пока Google переиндексирует). Убедитесь, что канонические теги правильно разрешаются на каждом шаблоне.

Используйте инструмент «Проверка URL» в Search Console для основных URL-адресов. Отправьте на переиндексацию 20–50 наиболее важных URL-адресов (с наибольшим трафиком в базовом периоде). Это не гарантирует быструю индексацию, но сигнализирует о приоритете.

Ежедневно в течение двух недель отслеживайте отчет «Охват». Следите за всплесками в категориях «Исключено по noindex», «Мягкая 404», «Сканировано – в настоящее время не индексируется» и «Обнаружено – в настоящее время не индексируется». Небольшой рост числа мягких 404 часто указывает на то, что при сопоставлении редиректов значимый URL-адрес был отправлен на менее релевантную страницу.

Отслеживайте отчет «Эффективность». Сравнивайте клики, показы и среднюю позицию с аналогичным периодом предыдущего месяца. Падение на 10–25% в первые 1–4 недели является нормой для чистой миграции. Падение более чем на 30% после 4-й недели требует исследования.

Проверяйте файлы журналов сервера на предмет поведения сканера. Googlebot должен обращаться к URL-адресам нового сайта и следовать редиректам 301 со старого домена. Если Googlebot продолжает активно сканировать старые URL-адреса через 30 дней, возможно, внутренние ссылки не были обновлены, или внешние сайты по-прежнему указывают на старые URL-адреса. Последнее является нормальным и частично объясняет, почему Google рекомендует сохранять редиректы активными как минимум 180 дней, а Джон Мюллер предлагает как минимум год.

Повторно запустите Core Web Vitals. Полевым данным в отчете Core Web Vitals в Search Console требуется 28 дней для заполнения после изменения. Отметьте дату и вернитесь к проверке на 4-й и 8-й неделях. Лабораторные данные (PageSpeed Insights) доступны немедленно и полезны для выявления регрессий на критически важных шаблонах.

Проверьте структурированные данные и расширенные результаты. Тест расширенных результатов должен проходить для образцов URL-адресов каждого типа шаблона. Отчеты Search Console «Улучшения» покажут новые ошибки в течение нескольких дней после сканирования новых шаблонов.

По возможности обновите внешние ссылки. Свяжитесь с владельцами высокоценных обратных ссылок (топ-50–100 ссылающихся доменов) с просьбой обновить URL-адреса. Это необязательно, но уменьшает зависимость от редиректов для наиболее ценных входящих ссылок.

Инструмент «Смена адреса» в Google Search Console

Инструмент «Смена адреса» — официальный способ сообщить Google о смене домена. Это инструмент уровня домена. Он не применяется к изменениям структуры URL в пределах одного домена, изменениям имени хоста, остающегося в том же домене, или миграциям на уровне путей.

Чтобы использовать инструмент, старый и новый домены должны быть подтвержденными ресурсами в Search Console под одной учетной записью Google. Инструмент выполняет набор предварительных проверок перед отправкой запроса. Критические проверки должны быть пройдены: должны быть настроены репрезентативные редиректы 301 со старого на новый, новый домен должен быть доступен и подтвержден, а тип ресурса должен быть «Домен» или «Префикс URL» на корневом уровне.

После отправки запроса Google активизирует сканирование и индексацию нового домена, передает сигналы со старого домена и предпочитает новые URL-адреса в качестве канонических. Эти действия выполняются в течение 180 дней. Старые редиректы также следует сохранять как минимум 180 дней, а дольше, если Search Console все еще показывает трафик, идущий через старые URL-адреса.

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

Распространенные ошибки при миграции

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

Перенаправление всех старых URL-адресов на главную страницу. Google расценивает это как мягкие 404 для нетривиальных страниц. Сигнальная ценность старого URL-адреса теряется.

Допущение цепочек редиректов. Старый URL -> промежуточный URL -> конечный URL замедляет сканирование и может привести к тому, что Googlebot перестанет следовать по цепочке после 3 или более переходов.

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

Забыли снять блокировку staging robots.txt. Правило Disallow: /, сохранившееся после переключения, полностью блокирует сканирование нового сайта.

Разрешение Google индексировать промежуточный сайт до запуска. Это приводит к проблемам с дублированным контентом и вынуждает выполнять очистку после запуска.

Пропуск обновления внутренних ссылок. Заставляет Googlebot проходить через цепочку редиректов при каждой внутренней навигации, расходуя бюджет сканирования.

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

Удаление структурированных данных из новых шаблонов. Приводит к потере права на расширенные результаты без предупреждения до тех пор, пока Search Console «Улучшения» не обнаружит проблему.

Пропуск сбора базовых показателей. Без показателей до миграции невозможно обнаружить или количественно оценить аномалии после миграции.

Отключение редиректов через 30 или 60 дней. Google может потребоваться гораздо больше времени для переиндексации внешних обратных ссылок. Отраслевой стандарт — минимум 12 месяцев.

Смешивание 302 с основным набором редиректов. 302 сигнализирует о временном перемещении. Целевой адрес не является предпочтительным каноническим, и передача SEO-ценности происходит медленнее.

Сопоставление URL-адресов с менее релевантными страницами, чтобы избежать редакционной работы. Страница снятого с производства продукта, перенаправленная на общую страницу категории, часто показывает более низкие результаты, чем та же страница, возвращающая 410 с рабочей ссылкой на новые продукты в теле ответа.

Часто задаваемые вопросы

Сколько времени занимает восстановление после миграции сайта?

По словам Джона Мюллера, восстановление обычно занимает от 4 до 12 недель при хорошо выполненной миграции. Исследование 892 миграций 2024 года, цитируемое Search Engine Journal, показало, что в среднем требуется 523 дня, чтобы полностью восстановить трафик до уровня до миграции, при этом 17% сайтов не смогли восстановиться в течение 1000 дней. Такой широкий диапазон отражает, насколько сильно результат зависит от качества сопоставления URL-адресов, объема изменений и размера сайта.

Стоит ли использовать редиректы 301 или 302 для миграции сайта?

Используйте 301 для постоянных перемещений и 302 (или 307) только когда изменение действительно временное. Джон Мюллер заявил, что влияние на SEO между 301 и 302 невелико, но Google предпочитает технически корректный тип. 301 передает сигналы более чисто и сообщает Google обновить канонический адрес на новый URL, в то время как 302 сохраняет старый URL как канонический.

Как долго следует сохранять редиректы 301 после миграции?

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

Что такое инструмент «Смена адреса» в Google Search Console?

Это функция Search Console, которая сообщает Google, что верифицированное свойство домена переместилось на новый домен. Она перенаправляет акцент сканирования на новый сайт на 180 дней и помогает Google выбирать новые URL как канонические. Это применимо только к перемещениям на уровне домена, когда оба свойства верифицированы под одной учетной записью Google.

Какая самая распространенная ошибка SEO при миграции сайта?

Перенаправление каждого старого URL на главную страницу вместо сопоставления каждой страницы с ее ближайшим тематическим аналогом. Google может рассматривать редиректы только на главную как мягкие 404, что удаляет SEO-ценность старой страницы. Решение — это карта URL один к одному для индексированных страниц с измеримым трафиком или обратными ссылками.

Можно ли мигрировать сайт поэтапно?

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