SEO при миграции сайта: как не потерять позиции в Google

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

В большинстве случаев падение позиций после миграции - это не “наказание” от Google за новый домен или новый дизайн. Это набор технических ошибок: отсутствующие 301-редиректы, изменённая структура URL без карты соответствия, потерянные meta title и description, удалённая структурированная разметка. Все эти ошибки видны заранее, если знать куда смотреть.

В проектах миграции сайтов мы регулярно видим один и тот же сценарий: команда полностью меняет платформу - переезжает с WordPress или Tilda на современный стек, обновляет дизайн - и только на этапе публикации вспоминает про SEO. К этому моменту URL уже поменялись, редиректы не настроены, и часть трафика уже потеряна на несколько недель вперёд. В этой статье - как зафиксировать текущее состояние сайта до переезда, не потерять технические сигналы во время миграции и что делать в первые недели после запуска, чтобы позиции не просто вернулись, а выросли.

Эту боль обычно первым замечает не разработчик, а CMO или фаундер: трафик из органического поиска - самый дешёвый канал привлечения, и просадка на 30-40% на два-три месяца означает конкретные недополученные заявки. Именно поэтому SEO-чек-лист должен обсуждаться до старта разработки нового сайта, а не всплывать как проблема постфактум.

Почему сайты теряют позиции при миграции

Падение позиций после переезда почти всегда объясняется техническими причинами, а не алгоритмическими санкциями Google. Вот самые частые ошибки.

• Отсутствующие 301-редиректы. Старые URL возвращают 404, и Google теряет накопленный вес страницы вместо того чтобы передать его новому адресу.
• Изменённая структура URL без карты соответствия. Переход вида /blog/statya в /articles/statya без редиректа - для поисковика это по сути новая, никому не известная страница.
• Потерянные meta title и description. Новая CMS часто генерирует их автоматически по шаблону, затирая формулировки, которые годами собирали клики в выдаче.
• Удалённая структурированная разметка. Schema.org для статей, FAQ и хлебных крошек не переносится автоматически при смене движка - её нужно пересобирать вручную.
• robots.txt случайно блокирует новый сайт. На staging-окружении почти всегда стоит Disallow: /, и эту строку забывают снять при переносе на боевой домен.
• Потерянная структура внутренних ссылок. Старые страницы ссылались друг на друга по определённой логике; если она не воспроизведена на новом сайте, распределение веса между страницами меняется непредсказуемо.
• Старый сайт остаётся доступным параллельно с новым. Если оба домена или оба окружения индексируются одновременно, Google видит дублирующийся контент и может понизить обе версии, пока не разберётся, какая из них основная.

Аудит до миграции - что зафиксировать

Ещё до начала работ по переезду нужно зафиксировать текущее состояние сайта - без этого невозможно проверить, что именно потерялось после запуска.

• Текущие позиции по коммерческим запросам - скриншот или экспорт из Google Search Console и трекера позиций.
• Полный список URL с трафиком по каждой странице - экспорт из GA4 за последние 12 месяцев.
• Текущие meta title и description всех проиндексированных страниц.
• Типы структурированной разметки, которые уже используются: Article, FAQPage, BreadcrumbList, Product.
• Снимок профиля обратных ссылок - откуда именно ссылаются на конкретные URL сайта.
• Текущие показатели Core Web Vitals (LCP, INP, CLS) по ключевым страницам - иначе после переезда нечем будет доказать, что новый сайт объективно быстрее.

Этот аудит стоит один рабочий день и снимает 90% рисков миграции - без него любое падение позиций после запуска превращается в расследование вслепую, потому что нет базовой точки для сравнения.

Мы делаем такой аудит первым шагом в любом проекте переезда сайта - без него миграция превращается в гадание на кофейной гуще, а не в управляемый процесс.

Редиректы - самая частая ошибка

Редиректы - единственный технический элемент, который решает, унаследует ли новая страница позиции старой в выдаче.

301 редирект: постоянное перенаправление, которое передаёт накопленный вес страницы новому URL; в отличие от временного редиректа 302, Google интерпретирует его как окончательный переезд контента.

• Карта соответствия 1:1 обязательна - каждый старый URL должен вести на свой конкретный новый эквивалент, а не на общий раздел каталога.
• Никогда не редиректить всё подряд на главную страницу - Google расценивает это как потерю контента, а не как аккуратный переезд.
• Использовать именно 301, а не 302 - временный редирект не передаёт накопленный вес страницы.
• Тестировать каждый редирект до запуска - вручную или скриптом, который проверяет весь список старых URL на корректный код ответа сервера.

Отдельная частая ошибка - цепочки редиректов (redirect chains): старый URL ведёт на промежуточный адрес, а тот - на финальный. Каждое лишнее звено замедляет обход страницы роботом Google и постепенно размывает передаваемый вес. Правило простое: один редирект должен вести сразу на финальный адрес, без промежуточных прыжков.

while read -r url; do
  code=$(curl -o /dev/null -s -w "%{http_code} %{redirect_url}\n" "$url")
  echo "$url -> $code"
done < old-urls.txt

Технические сигналы которые нельзя терять

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

• Canonical-теги должны указывать на новый домен и новый URL, а не оставаться привязанными к старому адресу.
• hreflang, если сайт многоязычный - карту соответствия между языковыми версиями нужно пересобрать заново, а не копировать со старой платформы.
• Структурированная разметка (schema.org) - Article, Product, FAQPage, BreadcrumbList - без неё сайт теряет право на расширенные сниппеты в выдаче.
• XML sitemap - новую карту сайта нужно повторно отправить в Google Search Console сразу после запуска, старая ссылка на sitemap перестаёт быть актуальной.

Почему скорость сайта - часть SEO-уравнения

Core Web Vitals - набор метрик Google (LCP, INP, CLS), измеряющих скорость загрузки, отзывчивость на действия пользователя и визуальную стабильность страницы. Core Web Vitals - официальный ранжирующий фактор Google с 2021 года, поэтому скорость сайта при миграции - это не техническая деталь, а часть SEO-стратегии.

Много компаний переезжают именно потому, что старая платформа физически не может выдать хорошие показатели: WordPress с десятком плагинов или конструктор вроде Tilda ограничивают скорость на архитектурном уровне, а не на уровне настроек.

Сайты, которые Exceltic.dev строит на связке Astro и headless CMS, в среднем получают 96 баллов по Google PageSpeed. Это напрямую влияет на SEO: раз Core Web Vitals входят в официальные ранжирующие факторы, высокий балл PageSpeed при прочих равных условиях контента коррелирует с лучшими позициями в выдаче. Миграция на быстрый стек - это не только про удобство пользователей, это про сам алгоритм ранжирования Google.

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

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

• Отправить новую sitemap.xml в Google Search Console сразу после публикации нового сайта.
• Ежедневно проверять отчёт “Покрытие” (Coverage) на предмет ошибок сканирования: 404, soft 404, случайно заблокированные страницы.
• Следить за позициями по ключевым запросам минимум 2-4 недели - краткосрочная просадка на этом этапе типична и сама по себе не означает провал миграции.
• Быть готовым быстро чинить сломанные редиректы - подавляющее большинство проблем обнаруживается именно в первую неделю после запуска.

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

Реальный кейс

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

В миграциях без карты соответствия URL картина обратная: типична потеря позиций свыше 40% в первый месяц, причём часть трафика не восстанавливается вовсе. Google успевает деиндексировать старые URL раньше, чем команда замечает проблему и чинит редиректы, а переиндексация новых страниц с нуля занимает недели, иногда месяцы - и в этот период сайт по факту недополучает заявки из органического поиска.

Для кого актуально

Этот чек-лист особенно важен для компаний, у которых органический трафик уже приносит заявки: маркетинговый сайт SaaS-продукта, блог с накопленной историей публикаций, сайт агентства с проиндексированными кейсами. Чем больше проиндексированных страниц и чем выше зависимость от органического канала, тем дороже обходится небрежная миграция - и тем важнее провести аудит и карту редиректов до начала разработки, а не после запуска.

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

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

При корректно настроенных 301-редиректах и сохранённых технических сигналах восстановление занимает в среднем 2-6 недель. Google должен повторно обойти и переиндексировать изменённые URL, на это уходит время даже при идеальной миграции. Если карта редиректов неполная или содержит ошибки, восстановление может растянуться на несколько месяцев, а часть позиций может не вернуться вовсе из-за деиндексации старых страниц.

Нужно ли менять URL при миграции сайта?

По возможности - нет. Если структура URL не меняется, риск потери позиций минимален: остаются только редиректы протокола (http на https) или домена. Если смена URL неизбежна, например при переходе на новую CMS с другой логикой маршрутизации, обязательна карта соответствия 1:1 для каждого старого адреса, а не общий редирект на раздел или главную страницу.

Что делать если позиции упали после миграции сайта?

Сначала проверить отчёт “Покрытие” в Google Search Console на ошибки сканирования и убедиться, что редиректы работают именно как 301, а не как 302 или ошибка 404. Затем сверить список старых URL с трафиком (из GA4) с текущими редиректами - часто выясняется, что часть страниц была пропущена при построении карты соответствия. Просадка до 5% в первые 2 недели - это норма, дальнейшая динамика важнее одной точки на графике.

Влияет ли смена CMS на SEO напрямую?

Смена CMS сама по себе не влияет на ранжирование - Google оценивает контент и технические сигналы, а не платформу. Но смена CMS почти всегда меняет скорость загрузки, структуру URL и способ генерации meta-данных, а это уже прямые факторы ранжирования. Именно поэтому миграция на более быстрый стек, например Astro или другой headless-подход, обычно улучшает позиции в среднесрочной перспективе, если технические сигналы перенесены без потерь.

Нужно ли уведомлять Google о миграции сайта?

Если домен не меняется, отдельное уведомление не требуется - достаточно отправить новую sitemap.xml в Google Search Console и следить за отчётом “Покрытие”. Если меняется домен целиком, в Search Console нужно использовать инструмент смены адреса и убедиться, что старый домен продолжает отвечать редиректами 301, пока Google не завершит перенос сигналов на новый адрес.

Как проверить что новый сайт случайно не закрыт от индексации?

Перед запуском откройте robots.txt нового сайта и убедитесь, что там нет строки Disallow: /, которая обычно ставится на staging-окружении для защиты от индексации черновика. Дополнительно проверьте мета-тег robots на ключевых страницах - он не должен содержать noindex. После запуска стоит вручную запросить индексацию нескольких ключевых страниц через инструмент проверки URL в Search Console, чтобы не ждать планового обхода.

Итоги

• Зафиксируйте текущие позиции, meta-данные и структуру URL до начала работ по миграции.
• Постройте карту редиректов 1:1 и протестируйте каждый редирект до запуска, а не после.
• Перенесите структурированную разметку, canonical-теги и hreflang вручную, не полагаясь на автоматику новой CMS.
• Мониторьте Google Search Console ежедневно в первые две-четыре недели после запуска.

Если вы планируете переезд сайта и хотите избежать просадки позиций - опишите текущую платформу и объём страниц команде Exceltic.dev. Проведём аудит и разберём карту редиректов ещё до того как начнётся разработка.