Миграция сайта без потери трафика: SEO, GEO и AEO в 2026
Как сменить платформу, не угробив видимость в поиске — и в Google, и в AI. Аудиты до миграции, карта редиректов, перенос structured data, доступ AI-краулеров.
Каждый год тысячи компаний решают, что пора наконец оставить позади свою стареющую платформу. Конфликты плагинов, патчи безопасности, неуклюжий чекаут — всё это накапливается. И они нажимают на курок миграции.
А потом трафик пропадает.
Это не редкий случай. Исследования показывают, что большинство миграций сайтов тихо теряет от 20% до 40% органической поисковой ценности. Анализ 892 миграций доменов выявил: средний срок восстановления — 523 дня, а 17% таких сайтов не восстановились вовсе.
Но вот что делает 2026 год принципиально не похожим ни на один предыдущий: Вы больше не просто защищаете позиции в Google. Вы защищаете видимость в совершенно новом слое поиска — AI-движках вроде ChatGPT, Perplexity, Google AI Overviews и Claude. Потеряйте при миграции structured data или сломайте архитектуру контента — и Вы не просто просядете в Google. Вы исчезнете из AI-ответов целиком.
Этот гайд о том, что реально важно — от технической карты редиректов до слоя AI-видимости, который 95% гайдов по миграции до сих пор игнорируют.
Почему миграции идут не так: проблема тихого распада
Самое опасное в проваленной миграции — не драматичный обвал трафика. Это медленное, незаметное кровотечение, которое начинается где-то на 10-й день.
Вот что обычно происходит: основные брендовые запросы держат позиции. Дашборды аналитики выглядят стабильно. Все выдохнули. Но под поверхностью long-tail-запросы — те самые, что приводят горячий, хорошо конвертящий трафик, — начинают осыпаться. Показы падают внутри отдельных кластеров запросов. На страницы по-прежнему заходят, но вовлечённость снижается. К тому моменту, когда общий трафик отразит ущерб, потеря SEO-ценности уже укоренилась, и откатить её куда труднее.
В одном задокументированном случае e-commerce-сайт потерял 67% трафика в течение двух недель после миграции на новую платформу без нормальных редиректов. Они потеряли более 340 топовых позиций по ключам. Частичное восстановление заняло полгода. Другая софтверная компания потеряла 44% органического трафика после миграции — примерно 500 000 пользователей в месяц.
А ещё есть собственная миграция WooCommerce на Woo.com в ноябре 2023-го: мгновенное падение органической видимости на 90%+, от которого они так и не оправились полностью.
Контрпример? TransferWise перенёс более миллиона проиндексированных страниц на Wise.com в марте 2021-го. Трафик поначалу упал примерно с 32 миллионов визитов в месяц до 12,9 миллиона. Но поскольку у них была дотошная стратегия — поэтапная миграция, тестирование до запуска, предварительная индексация домена, — они восстановились за восемь месяцев и в итоге выросли до более чем 200 миллионов визитов в месяц. Новый домен оказался примерно в 5 раз успешнее исходного.
Разница — никогда не удача. Это подготовка.
Контекст 2026 года: почему этот год другой
Три вещи изменили арифметику миграции в 2026 году.
Мартовский core-апдейт Google 2026 года поднял планку. Раскатываясь с 10 по 22 марта (со второй волной с 27 марта), этот апдейт ужесточил пороги Core Web Vitals, усилил оценку E-E-A-T и совпал со spam-апдейтом — создав самую высокую волатильность выдачи за год. Сильнее всего пострадали сайты с неразобранным техдолгом, тонким контентом и слабым мобильным опытом. Если Вы мигрируете на сайт, который не дотягивает до новых порогов, Вы мигрируете прямиком под санкцию.
AI Overviews теперь появляются более чем в 40% поисковых запросов. Те же сигналы контента, которые Google оценивает для веб-поиска, всё чаще определяют, попадёт ли Ваш контент в AI Overviews, процитирует ли его ChatGPT, сошлётся ли на него Perplexity. Сессии с переходами из AI выросли на 527% год к году в первой половине 2025-го, и примерно 31% населения США уже пользуется генеративным AI-поиском. Сломать structured data при миграции — значит стать невидимым для этого быстрорастущего канала.
Mobile-first indexing теперь жёсткое требование. С июля 2026 года сайты без рабочей мобильной версии будут полностью исключены из индекса Google. Миграция — Ваша последняя чистая возможность сделать это правильно.
Фаза 1. Аудит перед миграцией
Нельзя защитить то, чего не понимаешь. Вся миграция держится на том, что Вы задокументируете до того, как тронете хоть одну строку кода.
Зафиксируйте текущую производительность как baseline
Экспортируйте всё. Это станет Вашим эталоном и Вашей страховкой:
- Полный инвентарь URL. Просканируйте текущий сайт через Screaming Frog или Sitebulb. Каждый URL, каждый статус-код, каждая уже существующая цепочка редиректов. Для e-commerce это значит страницы товаров, категорий, фильтрационные/фасетные URL, контент блога и статические страницы — у каждого своя логика миграции.
- Снимок Search Console. Выгрузите топ-500 ключей с кликами, показами, CTR и средней позицией. Отделите брендовый трафик от небрендового — брендовые запросы часто маскируют распад по небрендовым.
- Профиль ссылок. Выгрузите полный профиль обратных ссылок из Ahrefs или Semrush. Страницы с внешними ссылками критичнее всего перенаправить корректно; у 94–95% страниц обратных ссылок нет вовсе, что делает те немногие, у которых они есть, во много раз ценнее.
- Аудит structured data. Просканируйте всю текущую schema-разметку. Зафиксируйте Organization, Product, Article, FAQ и любую разметку отзывов. Всё это нужно перенести на новую платформу один в один.
- Baseline по Core Web Vitals. Прогоните PageSpeed Insights по топ-20 посадочных страниц. Новый сайт обязан совпасть с этими цифрами или превзойти их. Порог LCP стал жёстче, а TTFB выше 600 мс теперь прямой ранжирующий сигнал.
- Baseline по AI-видимости. Этот шаг не делает никто. Задайте ChatGPT, Perplexity и Google AI Overviews те запросы, которыми пользовались бы Ваши клиенты. Отметьте, какие Ваши страницы цитируются. Задокументируйте это — это Ваш GEO-эталон.
Проведите аудит текущего техдолга
Прогоните полный технический аудит и зафиксируйте каждую ошибку, предупреждение и замечание. Новый сайт должен запуститься практически без унаследованных проблем. Передайте этот список разработчикам, чтобы они точно знали, что не тащить с собой. Миграция — Ваш шанс починить старые проблемы, а не унаследовать их.
Фаза 2. Карта URL и редиректы
Это технический стержень миграции. Сделаете правильно — сохраните авторитет. Сделаете неправильно — всё остальное не имеет значения.
Сопоставьте каждый URL
Составьте полноценную карту редиректов — таблицу, где каждому старому URL присвоен его аналог на новой платформе. Разбейте URL по типам, потому что у каждого своя логика сопоставления:
- Страницы товаров
- Страницы категорий/коллекций
- URL фильтрации и фасетной навигации
- Страницы блога/контента
- Статические страницы (о нас, контакты, доставка, FAQ)
- URL изображений
Разберитесь в различиях URL между платформами
Каждая платформа строит URL по-своему. Узнайте это до того, как напишете хоть один редирект:
- Magento:
/catalog/product/product-name.html - Shopify:
/products/product-name - WooCommerce:
/product/product-name/ - PrestaShop:
/en/category-name/product-name.html - Headless/кастом: что определите в своём слое маршрутизации
В зависимости от платформы имена категорий могут появляться в URL товаров или исчезать из них. Завершающие слэши, расширения файлов, чувствительность к регистру — всё это даёт расхождения, если не сопоставлено явно.
Правила редиректов, которые защищают Ваш авторитет
Каждый редирект должен следовать этим непреложным правилам:
- Только 301, никогда 302. Временные редиректы не передают ссылочный вес. Это самая частая ошибка миграции.
- Никаких цепочек редиректов. Если
/old-url-1/ведёт на/intermediate-url/, а тот — на/new-url/, Вы размываете сигналы на каждом шаге. Каждый редирект должен указывать напрямую на финальный пункт назначения. - Проверьте, что каждый пункт назначения отдаёт 200. Редирект 301 на 404 не передаёт ничего. Google игнорирует такой редирект целиком.
- Обновите внутренние ссылки напрямую. Не полагайтесь на редиректы во внутренней навигации. С первого дня нацельте все внутренние ссылки на новые URL.
- Никогда не перенаправляйте всё на главную. Это трактуется как soft 404. Сопоставьте каждый старый URL с ближайшим аналогом: сначала точное совпадение, затем похожий контент, затем самая релевантная страница категории. Редирект на главную — крайняя мера.
Где реализовать редиректы
Выбор влияет на производительность:
- Уровень CDN/сервера (Cloudflare, Fastly, Vercel): самый быстрый. Обрабатывается ещё до загрузки слоя приложения. Файл
_redirectsв Cloudflare обрабатывает тысячи правил менее чем за 1 мс. - Уровень приложения: нативный менеджер редиректов Shopify поддерживает до 20 000 правил (расширяется через API). WooCommerce использует плагины вроде Redirection. Рабочий вариант, но медленнее.
- Уровень веб-сервера: блоки в
.htaccessApache или в конфиге Nginx. Работает, но при масштабе сложнее в сопровождении.
Фаза 3. Сохранение технического SEO
Редиректы необходимы, но недостаточны. Новый сайт обязан перенести каждый сигнал, по которому поисковики и AI-системы понимают Ваш контент.
Что должно перенестись один в один
- Meta-заголовки и описания. Между платформами они переносятся не всегда автоматически. Проверьте каждую приоритетную страницу вручную.
- Иерархия заголовков. Сохраните структуру H1, H2, H3. Не дайте редизайну сплющить архитектуру контента.
- Schema-разметка. Перенесите все structured data — Product, Organization, Article, FAQ, Review, BreadcrumbList. В 2026 году structured data служит двум целям: помогает Google и помогает AI-системам понять Ваш контент для цитирования.
- Архитектура внутренних ссылок. Сохраните поток ссылочного веса. Битые внутренние ссылки создают страницы-сироты и размывают PageRank.
- Alt-текст изображений. Часто теряется при миграции. Проверьте, что он перенёсся, особенно для картинок товаров в e-commerce.
- Canonical-теги. Убедитесь, что они указывают на правильные новые URL, а не на оставшиеся старые пути.
- Hreflang-теги. Если Вы обслуживаете несколько языков или регионов, каждой версии нужна отдельная карта редиректов и проверка hreflang.
Производительность: совпасть или улучшить
Новая платформа обязана сравняться со скоростью старого сайта или превзойти её. Мартовский апдейт Google 2026 года ужесточил пороги CWV. Исследования показывают: 53% мобильных пользователей бросают страницу, которая грузится дольше 3 секунд, а лишние 2 секунды могут повысить показатель отказов более чем на 100%.
Замерьте baseline до миграции. Замерьте после. Если производительность деградирует, Вы потеряете позиции даже при идеальных редиректах.
Фаза 4. Слой GEO/AEO — то, что упускают все остальные
Вот где гайд по миграции 2026 года расходится с любым чек-листом, написанным до него.
Традиционные гайды по миграции исходят из того, что Вы защищаете только позиции в Google. На деле Вы защищаете ещё и видимость в AI-движках ответов, которые цитируют, резюмируют и рекомендуют контент способами, которые традиционные SEO-метрики не улавливают.
Как AI-движки находят и цитируют Ваш контент
AI-поисковики работают не как Google. Когда кто-то задаёт вопрос ChatGPT или Perplexity, система разбивает его на подзапросы («fan-out queries»), ищет по каждому, извлекает релевантный контент, оценивает авторитет источников и синтезирует ответ — цитируя источники, которым доверяет больше всего.
При миграции Вы рискуете потерять доверие AI, если:
- Ранее цитируемый контент удалён, объединён или перемещён без сохранения его идентичности
- Structured data, которые AI использует для контекста, исчезают
- Ваш robots.txt или CDN (особенно Cloudflare) начинает блокировать AI-краулеры на новом сайте
- Контент переезжает с серверного рендеринга на клиентский JavaScript, который AI-краулеры не могут разобрать
Чек-лист по AI-краулерам
До запуска нового сайта проверьте:
- robots.txt пропускает AI-краулеров. Убедитесь, что не блокируете GPTBot, PerplexityBot, ClaudeBot или Google-Extended. Многие платформы и CDN блокируют их по умолчанию. Cloudflare недавно сменил дефолт на блокировку AI-ботов — если используете Cloudflare, проверьте это отдельно.
- Контент рендерится на сервере. AI-краулеры не выполняют JavaScript так, как браузеры. Если Ваш новый headless-сайт рендерит всё на клиенте, контент для AI невидим. Используйте SSR или статическую генерацию для всех индексируемых страниц.
- Контент не спрятан за взаимодействиями. Вкладки, аккордеоны и выпадающие списки, требующие кликов для раскрытия контента, для AI-краулеров невидимы. Если важный контент живёт в сворачиваемых элементах, перестройте его.
- Подумайте о внедрении
llms.txt. Это текстовый файл в корне сайта, который даёт AI-системам структурированную карту Ваших важнейших страниц. Тема ещё ранняя — его используют лишь 5–15% сайтов, и крупные AI-провайдеры пока не приняли его до конца. Но он малорисковый, дешёвый и ставит Вас впереди конкурентов. Считайте его sitemap, спроектированным специально под языковые модели. - Schema-разметка цела и усилена. AI-системы сильно взвешивают structured data, решая, что процитировать. Схемы FAQ, HowTo, Product и Review напрямую влияют на то, появится ли Ваш контент в AI-ответах.
Структура контента под цитирование AI
AI-движки извлекают отдельные фрагменты, а не страницы целиком. Структурируйте контент так, чтобы каждый раздел стоял сам по себе как цитируемый ответ:
- Начинайте каждый раздел с прямого ответа, прежде чем давать контекст
- Используйте чёткие заголовки H2/H3, совпадающие с тем, как пользователи формулируют вопросы
- Держите абзацы в 2–3 предложения
- Включайте конкретные данные, статистику и названные источники — AI-системы предпочитают контент с конкретикой, а не общие слова
- Сохраняйте единые названия сущностей (бренд, товары, люди) по всему тексту — AI строит графы сущностей из этих паттернов
Измеряйте AI-видимость после миграции
После запуска добавьте это в стек мониторинга рядом с традиционными SEO-метриками:
- Трекинг цитирований. Еженедельно прогоняйте по AI-платформам свои целевые запросы. Вас всё ещё цитируют? Не вытеснил ли Вас конкурент?
- Реферальный трафик из AI. Проверьте аналитику на трафик из ChatGPT (приходит как реферер
chatgpt.com), Perplexity и других AI-источников. Эти сессии конвертят выше среднего органического — переходы из ChatGPT конвертят примерно в 15,9%. - Активность AI-краулеров. Проверьте логи сервера на user-agent’ы GPTBot, ClaudeBot, PerplexityBot. Если после миграции они исчезли — их что-то блокирует.
Фаза 5. Тестирование перед запуском
Находите проблемы до запуска, а не после.
Протокол staging-окружения
Поднимите staging-сайт, зеркалящий продакшен, но убедитесь, что поисковики не могут его индексировать. Staging в выдаче создаёт огромные проблемы с дублированием контента.
- Протестируйте все редиректы на staging до выхода в прод
- Просканируйте staging через Screaming Frog — ищите битые ссылки, отсутствующие meta-данные, страницы-сироты и цепочки редиректов
- Убедитесь, что robots.txt разрешает сканирование в проде, но блокирует на staging
- Подтвердите, что XML-sitemap генерируется корректно со всеми новыми URL
- Прогоните Core Web Vitals против Ваших baseline
- Проверьте, что вся schema-разметка валидна (используйте Schema Validator от Google)
- Проверьте ошибки 404 по всем типам страниц
- Тестируйте на реальных мобильных устройствах, а не только в адаптивном предпросмотре
Фаза 6. День запуска
Когда Вы дёргаете рубильник, дорога каждая минута.
Чек-лист запуска
- Раскатайте все редиректы одновременно с новым сайтом
- Обновите внутренние ссылки, чтобы они указывали на новые URL
- Отправьте новый XML-sitemap в Google Search Console
- Обновите трекинг Google Analytics/GA4
- При смене домена обновите адрес ресурса в Search Console
- Мониторьте логи сервера на ошибки в реальном времени
- Проверьте, что редиректы работают вживую (протестируйте выборку приоритетных URL)
- Убедитесь, что robots.txt на живом сайте пропускает всех нужных краулеров — и традиционных, и AI
Фаза 7. Мониторинг после запуска
90 дней после запуска определяют, восстановитесь Вы или просядете.
Неделя 1 (критично)
- Ежедневно проверяйте Search Console на ошибки сканирования
- Проверяйте покрытие редиректами — все ли старые URL ведут на новые?
- Отслеживайте и сразу чините ошибки 404
- Проверяйте статус индексации приоритетных страниц
- Ежедневно мониторьте органический трафик, отдельно по брендовому и небрендовому сегментам
Недели 2–8
- Отслеживайте изменения позиций по целевым кластерам ключей
- Сравнивайте динамику трафика с baseline до миграции
- Чините любые битые внутренние или внешние ссылки
- Обновляйте XML-sitemap при добавлении новых страниц
- Переотправляйте важные страницы на индексацию, если они появляются медленно
- Документируйте таймлайн восстановления — эти данные бесценны для будущего планирования
Постоянно
- Продолжайте ежемесячно мониторить AI-видимость
- Обновляйте контент ежеквартально, чтобы поддерживать сигналы свежести (AI-движки сильно взвешивают актуальность)
- Держите правила редиректов активными минимум 12 месяцев — слишком раннее их снятие приводит к повторному появлению 404, когда закешированные ссылки истекают
Частые пути миграции: особенности по платформам
PrestaShop → Shopify (или Medusa)
PrestaShop использует URL с именем категории внутри (/en/category/product.html), тогда как Shopify сплющивает до /products/product-name. Меняется каждый URL товара. Закладывайтесь на крупномасштабную карту редиректов. Мультиязычная структура URL в PrestaShop к тому же требует отдельной карты редиректов на каждый язык.
Magento → Shopify
Самая сложная из частых миграций. Magento использует /catalog/product/product-name.html против /products/product-name у Shopify. У крупных проектов часто тысячи фильтрационных URL, требующих явной обработки. Рассмотрите Shopify Plus с headless CMS (вроде Contentful или Strapi), если у Вас обширные контентные страницы, приводящие органику, — нативный блог Shopify рабочий, но ограничен для контентоёмких SEO-стратегий.
WordPress → Headless (Next.js, Webflow, Astro)
Главный риск здесь — рендеринг. WordPress по умолчанию отдаёт HTML, отрендеренный на сервере. Многие headless-фреймворки рендерят на клиенте, что ломает доступ и для Google, и для AI-краулеров. Если идёте в headless, обеспечьте SSR или статическую генерацию для всех контентных страниц. Также проверьте, что у плагинов, управляющих редиректами, schema и генерацией sitemap, есть аналоги в новом стеке.
Bitrix/1C → современный стек
Частое явление на рынке СНГ. Основные сложности — миграция данных из плотно связанных интеграций с ERP и сохранение кириллических структур URL. Закладывайтесь на тщательное тестирование кодировки символов в редиректах.
Любая платформа → любая платформа
Каким бы ни был конкретный путь миграции, принципы универсальны: сопоставьте каждый URL, делайте редиректы правильно, сохраните structured data, проверьте доступ AI-краулеров и агрессивно мониторьте после запуска.
Матрица решения о миграции
Не каждому сайту нужна полная пересборка. Прежде чем решаться, честно оцените, где Вы стоите:
Мигрировать, когда: у текущей платформы неустранимые технические ограничения, уязвимости безопасности невозможно пропатчить, платформа подходит к концу жизненного цикла или Вы тратите более 40% ресурсов разработки на сопровождение, а не на рост.
Лучше редизайн, когда: проблемы в основном косметические или связаны с UX. Редизайн на той же платформе несёт долю SEO-риска от миграции.
Делать и то и другое — осторожно: если нужно сменить платформу и провести редизайн, не делайте всё разом. В идеале сначала мигрируйте с минимальными изменениями дизайна, стабилизируйте позиции, а потом итерируйте по дизайну. Одновременная смена платформы, структуры URL, контента и дизайна перемножает каждый риск.
Суть
Миграция сайта, сделанная правильно, не просто сохраняет трафик — она может стать катализатором экспоненциального роста. Wise это доказал. А миграция, сделанная небрежно, может отбросить Вас на месяцы или годы.
В 2026 году ставки выше, чем когда-либо. Вы мигрируете не просто сайт. Вы мигрируете своё присутствие во всей экосистеме поиска — традиционном, AI-генерируемом, голосовом и агентном. Каждый пропущенный редирект, каждый брошенный кусок structured data, каждый случайно заблокированный AI-краулер — это накапливающаяся потеря на всех этих поверхностях сразу.
Планируйте так, будто это важно. Потому что это важно.
Если Вы планируете миграцию — или восстанавливаетесь после той, что пошла наперекосяк, — именно такой разговор мы ведём в areza.digital каждую неделю. Мы проводим аудиты перед миграцией, охватывающие SEO, GEO и AEO, чтобы Вы не просто пережили переход, а вышли из него сильнее. Записаться на 30-минутный созвон-знакомство → За контекстом по рискам миграции в разрезе стран (регуляторный слой, локальные сигналы, проникновение AI-overviews) загляните в наш хаб рынков роста.
Текст: Nikita Janockin, основатель areza.digital — консалтинг по SEO, AEO и GEO для бизнесов, проходящих смену платформы и наращивающих органический рост. Последнее обновление — 13 апреля 2026.