areza.
Блог
Миграция сайта без потери трафика: Руководство по выживанию SEO, GEO и AEO на 2026 год
AI SEO

Миграция сайта без потери трафика: Руководство по выживанию SEO, GEO и AEO на 2026 год

13 апреля 2026 г.

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

А потом трафик исчезает.

Это не редкое исключение. Исследования показывают, что большинство миграций сайтов незаметно теряют от 20% до 40% органической видимости. Анализ 892 доменных миграций выявил, что среднее время восстановления составляет 523 дня — а 17% сайтов так и не восстановились полностью.

Но вот что делает 2026 год принципиально отличным от всех предыдущих: вы защищаете уже не только позиции в Google. Вы защищаете своё присутствие в совершенно новом слое обнаружения — AI-поисковиках: ChatGPT, Perplexity, Google AI Overviews и Claude. Потеряйте структурированные данные или нарушьте архитектуру контента в процессе миграции — и вы не просто упадёте в Google. Вы исчезнете из AI-ответов полностью.

Это руководство охватывает всё, что действительно важно — от технической карты редиректов до AI-слоя видимости, который 95% гайдов по миграции по-прежнему игнорируют.

Почему миграции идут не так: проблема скрытого угасания

Самое опасное в провальной миграции — не резкий обвал трафика. Это медленное, невидимое кровотечение, которое начинается примерно на десятый день.

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

Один задокументированный случай: e-commerce сайт потерял 67% трафика за две недели после миграции на новую платформу без корректных редиректов. Было утрачено более 340 топовых позиций по ключевым словам. Частичное восстановление заняло шесть месяцев. Другая software-компания лишилась 44% органического трафика после миграции — около 500 000 пользователей в месяц.

И наконец, собственная миграция WooCommerce на Woo.com в ноябре 2023 года: немедленное падение органической видимости более чем на 90%, от которого они так и не оправились полностью.

Контрпример? TransferWise перенёс более миллиона проиндексированных страниц на Wise.com в марте 2021 года. Трафик сначала упал примерно с 32 миллионов месячных визитов до 12,9 миллиона. Но благодаря жёсткой стратегии — поэтапная миграция, пред-миграционное тестирование, предварительная индексация домена — восстановление произошло за восемь месяцев, а в итоге сайт масштабировался до более 200 миллионов визитов в месяц. Новый домен стал примерно в 5 раз успешнее исходного.

Разница — никогда не везение. Это подготовка.

Контекст 2026 года: почему этот год особенный

В 2026 году изменились три вещи, которые переписали логику миграции.

Мартовское core update Google 2026 года повысило планку. Выход обновления пришёлся на 10–22 марта (вторая волна — с 27 марта); оно ужесточило пороги Core Web Vitals, усилило оценку E-E-A-T и совпало со spam update — создав максимальную волатильность SERP за год. Сайты с нерешённым техническим долгом, тонким контентом или слабым мобильным опытом пострадали сильнее всего. Если вы мигрируете на сайт, не соответствующий новым порогам, — вы мигрируете прямо в штраф.

AI Overviews теперь появляются в более чем 40% поисковых запросов. Те же сигналы контента, которые Google оценивает в веб-поиске, всё больше определяют, попадёт ли ваш контент в AI Overviews, будет ли процитирован ChatGPT или упомянут в Perplexity. Переходы из AI-источников выросли на 527% год к году в первой половине 2025 года, а около 31% населения США уже использует генеративный AI-поиск. Потеря структурированных данных при миграции означает полную невидимость для этого быстрорастущего канала.

Mobile-first indexing стал жёстким требованием. С июля 2026 года сайты без функциональной мобильной версии будут полностью исключены из индекса Google. Миграция — ваш последний чистый шанс исправить это.

Фаза 1: Пред-миграционный аудит

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

Зафиксируйте текущие показатели

Экспортируйте всё. Это ваш бенчмарк и страховой полис:

  • Полный инвентарь URL. Обходите текущий сайт с помощью Screaming Frog или Sitebulb. Каждый URL, каждый статус-код, каждая уже существующая цепочка редиректов. Для e-commerce это страницы товаров, категорий, фильтрованных/фасетных URL, блог, статичные страницы — каждый тип со своей логикой миграции.
  • Снимок из Search Console. Экспортируйте топ-500 ключевых слов с кликами, показами, CTR и средней позицией. Разделите брендовый и небрендовый трафик — брендовые запросы часто маскируют деградацию небрендовых.
  • Профиль обратных ссылок. Экспортируйте полный бэклинк-профиль из Ahrefs или Semrush. Страницы с внешними ссылками критически важно редиректить правильно; 94–95% страниц не имеют ни одной обратной ссылки, что делает немногочисленные исключения экспоненциально ценнее.
  • Аудит структурированных данных. Обходите всю schema-разметку, развёрнутую на сайте. Зафиксируйте Organization, Product, Article, FAQ и любую review-разметку. Всё это должно перенестись 1:1 на новую платформу.
  • Бенчмарк Core Web Vitals. Запустите PageSpeed Insights для топ-20 посадочных страниц. Новый сайт должен соответствовать этим показателям или превышать их. Порог LCP стал жёстче, а TTFB выше 600 мс теперь является прямым сигналом ранжирования.
  • Бенчмарк 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/custom: То, что вы определите в routing layer

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

Правила редиректов, которые защищают авторитет

Каждый редирект должен подчиняться следующим обязательным правилам:

  1. Используйте 301, никогда 302. Временные редиректы не передают link equity. Это самая распространённая ошибка при миграции.
  2. Никаких цепочек редиректов. Если /old-url-1/ редиректит на /intermediate-url/, который редиректит на /new-url/, — вы теряете сигналы на каждом переходе. Каждый редирект должен указывать непосредственно на конечный адрес.
  3. Проверьте, что каждый пункт назначения возвращает 200. 301 на 404 не передаёт ничего. Google полностью игнорирует такой редирект.
  4. Обновите внутренние ссылки напрямую. Не полагайтесь на редиректы для внутренней навигации. Укажите все внутренние ссылки на новые URL с первого дня.
  5. Никогда не редиректируйте всё на главную страницу. Это расценивается как soft 404. Сопоставьте каждый старый URL с его ближайшим эквивалентом: сначала точное совпадение, затем похожий контент, потом наиболее релевантная страница категории. Редирект на главную — крайняя мера.

Где реализовывать редиректы

Выбор влияет на производительность:

  • Уровень CDN/сервера (Cloudflare, Fastly, Vercel): Быстрее всего. Обрабатываются до загрузки application layer. Файл _redirects Cloudflare обрабатывает тысячи правил менее чем за 1 мс.
  • Уровень приложения: Нативный менеджер редиректов Shopify поддерживает до 20 000 правил (расширяется через API). WooCommerce использует плагины вроде Redirection. Функционально, но медленнее.
  • Уровень веб-сервера: Конфиги Apache .htaccess или Nginx. Работает, но сложнее поддерживать в масштабе.

Фаза 3: Сохранение технического SEO

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

Что должно перейти 1:1

  • Мета-заголовки и описания. Они не всегда переносятся автоматически между платформами. Проверьте каждую приоритетную страницу вручную.
  • Иерархия заголовков. Сохраните структуру H1, H2, H3. Не позволяйте редизайну сгладить архитектуру контента.
  • Schema-разметка. Перенесите все структурированные данные — Product, Organization, Article, FAQ, Review, BreadcrumbList. В 2026 году структурированные данные служат двойной цели: они помогают Google и помогают AI-системам понять ваш контент для цитирования.
  • Архитектура внутренних ссылок. Сохраните поток link equity. Битые внутренние ссылки создают страницы-сироты и размывают PageRank.
  • Alt-текст изображений. Часто теряется при миграции. Убедитесь, что он переносится, особенно для товарных изображений в e-commerce.
  • Canonical-теги. Убедитесь, что они указывают на корректные новые URL, а не на устаревшие пути.
  • Hreflang-теги. Если вы обслуживаете несколько языков или регионов, каждой версии требуется отдельная карта редиректов и проверка hreflang.

Производительность: соответствуйте или превосходите

Новая платформа должна быть равна или быстрее старого сайта. Мартовское обновление Google 2026 года ужесточило пороги CWV. Исследования показывают, что 53% мобильных пользователей покидают страницу, загружающуюся дольше 3 секунд, а лишние 2 секунды могут увеличить показатель отказов более чем на 100%.

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

Фаза 4: Слой GEO/AEO — то, что упускают все остальные

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

Традиционные гайды по миграции исходят из того, что вы защищаете только позиции в Google. В реальности вы также защищаете свою видимость в AI-answer engines — тех, что цитируют, резюмируют и рекомендуют контент способами, которые традиционные SEO-метрики не фиксируют.

Как AI-движки обнаруживают и цитируют ваш контент

AI-поисковые платформы работают иначе, чем Google. Когда пользователь задаёт вопрос в ChatGPT или Perplexity, система разбивает его на подзапросы («fan-out queries»), ищет каждый из них, извлекает релевантный контент, оценивает авторитетность источника и синтезирует ответ — цитируя источники, которым доверяет больше всего.

В процессе миграции вы рискуете потерять доверие AI, если:

  • Ранее цитируемый контент удалён, объединён или перемещён без сохранения идентичности
  • Структурированные данные, используемые AI для контекста, исчезают
  • Ваш robots.txt или CDN (особенно Cloudflare) начинает блокировать AI-краулеры на новом сайте
  • Контент переходит с server-side rendering на client-side JavaScript, который AI-краулеры не могут разобрать

Чеклист AI-краулеров

Перед запуском нового сайта проверьте:

  1. robots.txt разрешает AI-краулеры. Убедитесь, что вы не блокируете GPTBot, PerplexityBot, ClaudeBot или Google-Extended. Многие платформы и CDN блокируют их по умолчанию. Cloudflare недавно изменил дефолтную настройку на блокировку AI-ботов — если вы используете Cloudflare, проверьте это явно.
  2. Контент рендерится на стороне сервера. AI-краулеры не исполняют JavaScript так, как это делают браузеры. Если новый headless-сайт рендерит всё на стороне клиента, ваш контент невидим для AI. Используйте SSR или static generation для всех индексируемых страниц.
  3. Контент не скрыт за взаимодействиями. Вкладки, аккордеоны и выпадающие элементы, требующие кликов для раскрытия содержимого, невидимы для AI-краулеров. Если важный контент находится в сворачиваемых элементах — реструктурируйте его.
  4. Рассмотрите внедрение llms.txt. Это текстовый файл в корне сайта, предоставляющий AI-системам структурированную карту ваших наиболее важных страниц. Пока это ранняя практика — её используют лишь 5–15% сайтов, и крупные AI-провайдеры не взяли на себя полных обязательств. Но это малозатратно, не несёт рисков и ставит вас впереди конкурентов. Думайте об этом как о sitemap, созданном специально для языковых моделей.
  5. Schema-разметка цела и усилена. AI-системы придают значительный вес структурированным данным при определении того, что цитировать. FAQ, HowTo, Product и Review schema напрямую влияют на попадание вашего контента в AI-ответы.

Структура контента для AI-цитирования

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

  • Начинайте каждую секцию с прямого ответа, прежде чем давать контекст
  • Используйте чёткие заголовки H2/H3, соответствующие формулировкам пользовательских вопросов
  • Ограничивайте абзацы 2–3 предложениями
  • Включайте конкретные данные, статистику и именованные источники — AI-системы отдают предпочтение контенту с конкретными утверждениями, а не обобщениями
  • Сохраняйте согласованные имена сущностей (ваш бренд, продукты, людей) — AI строит графы сущностей из этих паттернов

Измерение AI-видимости после миграции

После запуска добавьте следующее в стек мониторинга наряду с традиционными SEO-метриками:

  • Отслеживание цитирований. Еженедельно запрашивайте AI-платформы с целевыми промптами. Вас по-прежнему цитируют? Вас заменил конкурент?
  • AI-реферальный трафик. Проверяйте аналитику на предмет трафика с ChatGPT (отображается как реферер chatgpt.com), Perplexity и других AI-источников. Эти сессии конвертируются с более высоким показателем, чем средний органический трафик — реферралы из ChatGPT конвертируются примерно на уровне 15,9%.
  • Активность AI-краулеров. Проверяйте server logs на user agents GPTBot, ClaudeBot, PerplexityBot. Если они исчезли после миграции — что-то их блокирует.

Фаза 5: Пред-запусковое тестирование

Находите проблемы до запуска, а не после.

Протокол staging-среды

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

  • Тестируйте все редиректы на staging до выхода в продакшн
  • Обходите staging-сайт с Screaming Frog — ищите битые ссылки, отсутствующие мета-данные, страницы-сироты и цепочки редиректов
  • Убедитесь, что robots.txt разрешает обход в продакшне, но блокирует на staging
  • Подтвердите, что XML-sitemap генерируется корректно со всеми новыми URL
  • Протестируйте Core Web Vitals относительно ваших бенчмарков
  • Проверьте, что вся schema-разметка валидна (используйте Google Schema Validator)
  • Проверьте наличие 404-ошибок по всем типам страниц
  • Тестируйте на реальных мобильных устройствах, а не только в responsive preview

Фаза 6: День запуска

Когда вы переключаете тумблер, каждая минута на счету.

Чеклист запуска

  • Разворачивайте все редиректы одновременно с новым сайтом
  • Обновите внутренние ссылки, чтобы они указывали на новые URL
  • Отправьте новый XML-sitemap в Google Search Console
  • Обновите трекинг Google Analytics/GA4
  • При смене домена обновите адрес свойства в Search Console
  • Мониторьте server logs на предмет ошибок в реальном времени
  • Проверьте работу редиректов в продакшне (протестируйте выборку приоритетных URL)
  • Убедитесь, что robots.txt на живом сайте разрешает всем нужным краулерам — как традиционным, так и AI

Фаза 7: Мониторинг после запуска

90 дней после запуска определяют, восстановитесь вы или продолжите снижение.

Неделя 1 (критическая)

  • Ежедневно мониторьте Search Console на предмет ошибок обхода
  • Проверяйте покрытие редиректами — все ли старые URL резолвятся в новые?
  • Немедленно отслеживайте и исправляйте 404-ошибки
  • Проверяйте статус индексации приоритетных страниц
  • Ежедневно мониторьте органический трафик с разделением брендового и небрендового сегментов

Недели 2–8

  • Отслеживайте изменения позиций по целевым кластерам ключевых слов
  • Мониторьте тенденции трафика относительно пред-миграционного бенчмарка
  • Исправляйте все битые внутренние и внешние ссылки
  • Обновляйте XML-sitemaps при добавлении новых страниц
  • Повторно отправляйте важные страницы на индексацию, если они появляются медленно
  • Документируйте хронологию восстановления — эти данные бесценны для будущего планирования

На постоянной основе

  • Продолжайте ежемесячно мониторить 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. У enterprise-клиентов часто тысячи filter URL, требующих явной обработки. Рассмотрите Shopify Plus с headless CMS (например, Contentful или Strapi), если у вас есть обширные контентные страницы, генерирующие органический трафик, — нативный блоггинг Shopify функционален, но ограничен для контент-стратегий, ориентированных на SEO.

WordPress → Headless (Next.js, Webflow, Astro)

Главный риск здесь — рендеринг. WordPress по умолчанию отдаёт server-rendered HTML. Многие headless-фреймворки рендерят на стороне клиента, что ломает доступ и для Google, и для AI-краулеров. При переходе на headless убедитесь, что SSR или static generation реализованы для всех контентных страниц. Также проверьте, что плагины, управляющие редиректами, schema-разметкой и генерацией sitemap, имеют аналоги в новом стеке.

Bitrix/1C → современный стек

Распространено на рынке СНГ. Основные сложности — миграция данных из тесно связанных ERP-интеграций и сохранение кириллических структур URL. Планируйте обширное тестирование кодировки символов в редиректах.

Любая платформа → любая платформа

Независимо от конкретного пути миграции, принципы универсальны: составьте карту каждого URL, настройте редиректы правильно, сохраните структурированные данные, проверьте доступ AI-краулеров и агрессивно мониторьте после запуска.

Матрица решений о миграции

Не каждому сайту нужен полный перестройки. Прежде чем принять решение, честно оцените свою ситуацию:

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

Вместо этого делайте редизайн, когда: ваши проблемы преимущественно косметические или связаны с UX. Редизайн на той же платформе несёт ничтожную долю SEO-рисков.

Делайте и то, и другое — осторожно: если нужно сменить платформу и сделать редизайн — не делайте всё одновременно. В идеале сначала мигрируйте с минимальными изменениями дизайна, стабилизируйте позиции, затем итеративно работайте над дизайном. Одновременная смена платформы, структуры URL, контента и дизайна умножает каждый риск.

Итог

Правильно проведённая миграция сайта не просто сохраняет трафик — она может стать катализатором экспоненциального роста. Wise это доказали. Но миграция, выполненная небрежно, может отбросить вас на месяцы или годы назад.

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

Планируйте так, как будто это важно. Потому что это так.

Если вы планируете миграцию — или восстанавливаетесь после той, что пошла не так — именно об этом мы говорим в areza.digital каждую неделю. Мы проводим пред-миграционные аудиты, охватывающие SEO, GEO и AEO, чтобы вы не просто пережили переход, а вышли из него сильнее. Забронировать 30-минутный ознакомительный звонок →

Автор: Никита Яночкин, основатель areza.digital — SEO, AEO и GEO-консалтинг для компаний, проходящих миграцию платформ. Последнее обновление: 13 апреля 2026 г.

Перестаньте терять лидов из-за медленного сайта

Забронируйте бесплатный friction audit и увидьте, где именно ваш сайт теряет деньги.

Забронировать звонок →