Миграция сайта без потери SEO: руководство 2026 для редизайна, смены платформы и домена

В феврале к нам в панике обратился управляющий партнёр средней пражской юридической фирмы. За две недели до этого их агентство запустило долгожданный редизайн сайта. Дизайн был аккуратный, ребрендинг — выверенный, партнёры наконец после полугода правок утвердили тексты главной. Запуск состоялся в пятницу днём. К утру понедельника органический трафик упал на 60%, форма обратной связи не работала, а три самые конверсионные страницы услуг возвращали ошибку 404.

Агентство сделало то, что в 2026 году по-прежнему делает удивительное число агентств: построило красивый новый сайт, переключило DNS и понадеялось на лучшее. Никакой карты редиректов. Структура URL изменилась, но никто не связал старые адреса с их новыми эквивалентами. Страницы, которые годами зарабатывали позиции в Google, просто исчезли — на их месте появились 404, которые Googlebot вскоре перестанет посещать.

Миграция сайта — одно из самых рискованных мероприятий, которые бизнес проводит онлайн. Если сделано хорошо, ни клиенты, ни поисковики ничего не заметят. Если плохо — за выходные стирается SEO-капитал, накопленный годами. Это руководство — то, что мы используем, когда ведём миграцию: полный редизайн, переход с устаревшей CMS, смена домена после ребрендинга или спасение проекта, чья прежняя команда исчезла. Если вы собираетесь переносить сайт, прочитайте это сначала.

Что на самом деле значит «миграция сайта» в 2026 году

Слово «миграция» используется широко. На практике оно покрывает по меньшей мере пять разных типов проектов, и каждый несёт свой риск. Понимание, какой именно тип вы делаете, меняет всю стратегию.

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

Смена платформы. Переход с WordPress на собственный стек на Nuxt или Next.js, с Wix на headless CMS, с самописного сайта на Shopify. Средний и высокий риск, потому что структура URL обычно меняется и новая платформа может рендерить контент иначе. Аргументы за такие переходы мы разбирали в статье о headless CMS и в матрице WordPress или индивидуальная разработка.

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

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

Миграция хостинга или инфраструктуры. Тот же домен, тот же код, новые серверы или новый CDN. Обычно низкий риск при аккуратном выполнении, но ошибки в TLS-конфигурации, изменения IP-геолокации или сдвиг robots.txt во время переезда могут вызвать настоящие проблемы.

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

Аудит перед миграцией: что нужно инвентаризовать, прежде чем что-то трогать

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

Начните с полного обхода существующего сайта. Подойдёт Screaming Frog или Sitebulb, как и большинство агентских SEO-платформ. Вам нужны все URL, до которых дотянется паук, все существующие редиректы, все title и meta description, все canonical, все H1 и все внутренние ссылки. Сохраните этот экспорт надолго. Это самый полезный артефакт всей миграции.

Из Google Analytics и Search Console вытяните топ-200 органических точек входа за последние 12 месяцев. Это ваши высокоценные URL. Каждый из них должен иметь явное место назначения на новом сайте. Если страница из топ-200 не попала в карту редиректов к моменту запуска, вы сознательно теряете этот трафик.

Проинвентаризуйте профиль обратных ссылок. Ahrefs, Semrush или отчёт по ссылкам в Search Console покажут URL, на которые ссылаются другие сайты. Обратные ссылки — это актив, который дольше всего восстанавливается, и они ведут на конкретные URL. Если авторитетная обратная ссылка указывает на URL, возвращающий 404 после запуска, вы теряете не только трафик, но и ссылочный вес, который та страница передавала остальной части сайта.

Зафиксируйте базовый уровень Core Web Vitals для основных шаблонов. PageSpeed Insights, Chrome User Experience Report и ваши данные real-user monitoring должны сходиться в том, как выглядит «норма». После запуска именно по этой базовой линии вы будете отлавливать регрессы быстрее, чем клиенты.

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

301-редиректы: главная причина, по которой миграции проваливаются

Если вы сделаете правильно только одну вещь во время миграции — пусть это будут редиректы. Каждый URL на старом сайте, который имеет хоть какую-то ценность — органический трафик, индексацию, внутренние или внешние ссылки — должен иметь 301-редирект на ближайший эквивалент на новом сайте. Не 302. Не soft 404, который возвращает статус 200 со страницей «не найдено». Чистый 301.

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

Граничные случаи, на которых команды спотыкаются всегда: query-параметры (нужно ли /produkty?id=42 куда-то редиректить?), слеши в конце (/about и /about/ ведут на одну и ту же страницу?), регистр (/Services редиректит на /services?) и языковые префиксы (есть ли у /en/about, /about и /ru/about правильные кросс-локальные редиректы?). Каждый случай тестируйте явно перед запуском.

Для сайтов с числом URL более нескольких сотен не тестируйте редиректы вручную. Прогоните полный список старых URL через httpstatus.io или напишите небольшой скрипт. Каждый URL должен возвращать единственный 301 на правильный адрес назначения, без цепочек и петель. Цепочка редиректов (URL A → URL B → URL C) теряет ссылочный вес на каждом шаге и замедляет краулеры. Петля редиректов — гарантированная проблема индексации.

Если вы используете Cloudflare или другую современную edge-платформу, редиректы можно обрабатывать на уровне CDN с задержкой меньше миллисекунды. На большинстве проектов мы делаем именно так — это держит код приложения чистым и позволяет менять редиректы без полного релиза.

Сохранение on-page SEO: title, meta description, заголовки, schema, alt-тексты

Карта редиректов отвечает за то, чтобы загрузился правильный URL. On-page аудит гарантирует, что когда этот URL загрузится, Google по-прежнему увидит страницу, которая заслуживает прежних позиций.

Для каждого URL из топ-200 скопируйте существующий title, meta description, H1 и основной контент на новый сайт дословно, если у вас нет конкретной причины что-то менять. «Улучшение» title-тега страницы, которая занимает второе место по высокочастотному ключевому запросу, — одна из самых дорогих оптимизационных ошибок. Если страница уже работает, цель миграции — сохранить её работоспособность, а не переизобрести её.

Schema-разметка — второе по величине on-page обязательство. Если у старого сайта была разметка Article, FAQPage, BreadcrumbList, Organization или LocalBusiness, новый сайт должен реализовать те же типы на тех же URL. Перед запуском валидируйте каждый шаблон в Google Rich Results Test. Отсутствующая schema не даст вам 404, но тихо удалит ваши rich snippets из результатов поиска, и это падение CTR в отчётах выглядит идентично падению позиций.

Alt-тексты у изображений — самое лёгкое забываемое. Когда дизайн-команда перестраивает компоненты изображений, атрибут alt часто пропадает или заменяется заглушкой. Просканируйте новый staging и подтвердите, что у каждого изображения, имевшего alt на старом сайте, alt есть и на новом. Подробнее об этом — в нашем техническом SEO-чек-листе для запуска сайта, где разобран полный pre-flight инвентарь.

Техническое SEO во время переключения: robots.txt, sitemap, hreflang, canonical

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

Robots.txt. Самая частая катастрофа дня запуска — отправить в продакшен robots.txt, который из staging-окружения по-прежнему говорит Disallow: /. Каждый staging должен быть закрыт от краулеров. У каждого продакшена этот блок должен быть снят. Аудитуйте продакшен-robots.txt перед переключением DNS и ещё раз после того, как новый сайт станет доступен.

XML sitemap. Сразу после запуска отправьте свежий sitemap в Google Search Console. Sitemap должен отражать новую структуру URL с точными датами lastmod. Если на старый sitemap ссылается robots.txt, обновите ссылку на новый.

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

Canonical-теги. Каждый URL на новом сайте должен декларировать self-referencing canonical, кроме случаев, когда вы сознательно консолидируете (например, постраничные архивы канонически указывают на версию без параметров). Отсутствующий canonical на шаблонной странице может привести к тому, что Google выберет в качестве «правильной» другую URL — и часто это не та, на которой вы хотели ранжироваться.

Производительность и Core Web Vitals: не мигрируйте на более медленный сайт

Один из самых удручающих паттернов — красивый новый дизайн, который ранжируется хуже старого, потому что он медленнее. Современные дизайн-тренды, кастомные шрифты, анимации, видео-фоны и большие hero-изображения — всё это стоит производительности. Если у нового сайта Core Web Vitals хуже, чем у старого, миграция — это шаг назад, как бы она ни выглядела.

Прогоните новый staging через Lighthouse и PageSpeed Insights перед запуском и сравните цифры с предмиграционной базовой линией. Самые важные метрики: Largest Contentful Paint (LCP) меньше 2,5 секунд, Interaction to Next Paint (INP) меньше 200 миллисекунд, Cumulative Layout Shift (CLS) меньше 0,1. Если хоть одна из них регрессировала по сравнению со старым сайтом, исправьте до запуска, а не после.

Типичные виновники в 2026: hero-видео, которые автоплеют до того, как страница станет интерактивной; веб-шрифты без font-display: swap; сторонние теги, блокирующие основной поток; компоненты изображений, отправляющие один и тот же JPEG на каждое устройство вместо адаптивных вариантов в WebP. Наша страница оптимизации скорости сайта детально расписывает диагностический процесс, а услуга оптимизации производительности — это то, что мы предлагаем, когда сайт уже запущен медленным и должен стать быстрым.

Чек-лист дня запуска: пошаговый сценарий

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

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

Если у вас нет внутренней команды, способной отработать этот чек-лист, наша услуга поддержки проектов ведёт переключения как фиксированную работу. Мы прогоняли этот сценарий более чем на пятидесяти миграциях, и шаги намеренно скучные.

Первые 30 дней: что мониторить и когда паниковать (или нет)

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

День 1–7. Ожидайте небольшое падение органического трафика, обычно 5–15%. Search Console начнёт сообщать об активности обхода новых URL в течение часов, а отчёт о покрытии заполнится за несколько дней. Если в первый день вы видите падение 50% и более, что-то не так, почти всегда это редиректы или robots.txt.

День 7–21. Новые URL должны появляться в выдаче вместо старых. Самая важная метрика для отслеживания — CTR по запросу; если он резко падает по высокоценному запросу, meta description нового URL, вероятно, отличается от старого. Самый частый паттерн: трафик проседает, затем частично восстанавливается, по мере того как Google догоняет.

День 21–30. К концу первого месяца органический трафик должен быть в пределах 5% от предмиграционного уровня. Если нет, миграция что-то упустила, обычно категорию страниц, перенаправленных неправильно, или элемент schema, не переживший переезд.

Если цифры не восстанавливаются, не начинайте «оптимизировать» через изменение on-page элементов. Это усложняет диагностику. Сначала исследуйте саму миграцию: перепроверьте карту редиректов, валидируйте schema на топ-50 страниц, проаудитьте hreflang. Решение почти всегда в починке миграции, а не в наслоении нового SEO поверх неисправленного. Если подозреваете, что что-то сломано глубже, а оригинальной команды уже нет, наша услуга спасения проектов существует именно для этого сценария.

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

Сколько занимает миграция сайта от начала до конца?

Редизайн на той же платформе: 4–8 недель. Смена платформы со сменой URL: 6–12 недель. Смена домена: добавьте 1–2 недели на карту редиректов и настройку Search Console. Долгий этап редко сама разработка; это аудит, карта редиректов и QA. Команды, пытающиеся сжать эти фазы, расплачиваются за это после запуска. Наш разбор стоимости сайтов показывает, сколько такие проекты обычно стоят в 2026 году.

Я потеряю позиции, даже если миграция сделана хорошо?

Краткосрочно — почти всегда да, на небольшую величину. Первые одну-четыре недели — это нормальная волатильность, пока Google переобрабатывает сайт. Хорошо выполненная миграция полностью восстанавливается, и во многих случаях ранжируется лучше, чем раньше, потому что технический фундамент стал крепче. Плохо выполненная миграция теряет позиции и никогда полностью не восстанавливается; мы аудитили сайты, которые через год после неудачного переезда всё ещё были в минусе на 30% и более.

Нужно ли заморозить новый контент во время миграции?

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

Что произойдёт с обратными ссылками?

301-редиректы передают подавляющее большинство ссылочного веса со старой URL на новую. Современный Google не штрафует за сам редирект. Риск — когда обратная ссылка ведёт на URL, который вы забыли перенаправить, и тогда ссылка теряется впустую. Именно поэтому этап аудита смотрит конкретно на обратные ссылки, а не только на URL с трафиком.

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

Если у вас внутренняя команда, которая делала это раньше — да. Если вы впервые ведёте карту редиректов вручную в таблице, цена ошибки почти всегда выше цены найма. Агентства, у которых миграция получается, — это те, кто прогонял один и тот же сценарий двадцать раз. Если хотите второе мнение перед решением, наш материал о 12 вопросах для выбора веб-агентства включает миграционно-специфичные.

Итог

Миграция сайта — редкий проект, цель которого — чтобы с точки зрения клиентов ничего не изменилось, и с точки зрения Google ничего не изменилось, при том что под капотом изменилось почти всё. Дисциплина, которая туда приводит, не блестящая: тщательно аудитить, картировать каждый URL, сохранять on-page элементы, валидировать schema, неустанно мониторить. Ничего из этого не возбуждает. Всё это — разница между запуском, который двигает бизнес вперёд, и запуском, который стоит квартала органической выручки.

Если в 2026 году вы планируете редизайн, смену платформы или смену домена и хотите партнёра, который этот сценарий уже отрабатывал, свяжитесь с нами. Мы скажем прямо, недооценён ли в вашем проекте миграционный риск и что нужно, чтобы его снизить. Если уже на середине миграции и цифры выглядят неправильно, то же самое. Цены на проекты, ориентированные на миграцию, — на странице цен, а связанные сервисы описаны в веб-разработке, редизайне и дизайне.