SEO-миграция магазина без потери трафика

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

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

Что такое SEO-миграция и почему проседает трафик

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

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

Отсюда простой вывод: задача SEO-миграции — не «перенести файлы», а сохранить или аккуратно перенести все сигналы, привязанные к страницам. Если робот после переезда без труда находит те же адреса с тем же содержимым — или получает чёткое указание, что старый адрес переехал сюда, — просадки почти нет. Если сигналы теряются, трафик падает ровно настолько, насколько их потеряли.

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

Типы миграций: домен, платформа, редизайн, URL

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

• Смена домена. Меняется только имя сайта, структура URL после домена сохраняется. Технически один из самых предсказуемых сценариев: настраиваются постраничные редиректы со старого домена на новый и оформляется переезд в панелях вебмастеров.
• Смена платформы (CMS). Магазин переезжает, например, с самописной системы или другой CMS на 1С-Битрикс. Риск в том, что новая система генерирует URL по своим правилам, и адреса разделов, карточек и фильтров почти наверняка изменятся, если специально не позаботиться об обратном.
• Изменение структуры URL. Иногда переезда как такового нет, но меняется схема адресов: вводят ЧПУ вместо параметров, реорганизуют разделы каталога, меняют шаблон пути к карточке товара. Это чистая SEO-миграция, где всё держится на карте редиректов.
• Редизайн без смены URL. Обновляется оформление и вёрстка, но адреса остаются прежними. Самый безопасный сценарий — при условии, что вместе с дизайном не переписывают контент и не выкидывают текстовые блоки.
• Смена протокола или сервера. Переход с http на https, переезд на новый хостинг, консолидация зеркал. Обычно проходит незаметно, но требует проверки склейки www/без-www, http/https и корректных заголовков.

Часто в одном проекте совпадает сразу несколько типов: например, магазин одновременно переезжает на 1С-Битрикс, меняет домен и получает новый дизайн. Это не значит, что риск удваивается — просто список проверок становится длиннее, а карта редиректов и тестирование важнее. Разделите такой переезд на слои и убедитесь, что каждый слой отработан отдельно.

Где именно теряется поисковый трафик

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

• Битые или отсутствующие редиректы. Старый адрес отдаёт 404 вместо 301 на новую страницу. Накопленный вес и внешние ссылки уходят в никуда — самая частая и самая дорогая ошибка миграции.
• Редиректы «в кучу». Все старые адреса перенаправлены на главную вместо релевантных страниц. Формально 404 нет, но поисковик считает такой редирект «мягкой 404» и не переносит вес.
• Потерянный контент. При переносе выпали текстовые описания разделов, характеристики, отзывы, блоки перелинковки. Страница осталась, а её содержательный сигнал обеднел.
• Сброшенные метатеги. Новая CMS сгенерировала свои шаблонные title и description вместо перенесённых, и уникальность метаданных потерялась.
• Закрытая индексация. Тестовый контур был закрыт в robots.txt или метатегом noindex, и при запуске эту заглушку забыли снять. Робот честно перестаёт индексировать сайт.
• Изменившаяся структура заголовков. Новый шаблон переписал H1 или спрятал их, изменил иерархию H2/H3 — семантика страницы для поисковика поплыла.
• Потеря скорости и доступности. Новый сервер медленнее, каталог не закэширован, робот получает таймауты и снижает частоту обхода.

Обратите внимание: почти все эти потери — не про «поисковик наказал за переезд», а про конкретный технический недосмотр. Именно поэтому миграция — это в первую очередь дисциплина и чек-листы, а не удача. Если пройтись по каждому пункту заранее, просадка сжимается до короткого технического колебания.

Главный принцип: сохранить сигналы, а не только данные

Разработчики часто мыслят миграцию как перенос данных: выгрузили товары, залили на новую платформу, проверили, что каталог открывается. С точки зрения работоспособности магазина этого достаточно. С точки зрения SEO — нет, потому что за кадром остаётся всё, что поисковик привязал к старым адресам.

Сформулируем принцип, который стоит держать в голове на каждом этапе: у каждой страницы, которая приносила трафик или имела вес, после миграции должен быть «наследник» — либо тот же URL с тем же содержимым, либо новый URL, на который со старого ведёт 301-редирект, и на котором сохранён контент, заголовки и метатеги. Если наследника нет, сигнал потерян.

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

Аудит перед миграцией: снимок текущего состояния

Нельзя понять, потеряли вы трафик или нет, если не зафиксировали, сколько его было и откуда он шёл. Поэтому первый этап — снять детальный «снимок до». Этот снимок станет и точкой отсчёта для сравнения, и источником данных для карты редиректов.

Что зафиксировать перед началом работ:

• Базовые метрики трафика. Органический трафик за последние 6–12 месяцев по неделям, разбивка по разделам, топ страниц-точек входа. Это ваша линия, к которой график должен вернуться.
• Ядро позиций. Позиции по ключевым запросам, за которыми вы следите. После миграции их проверяют в первую очередь.
• Список проиндексированных страниц. Сколько URL в индексе Яндекса и Google, какие именно. Резкое падение этого числа после запуска — первый тревожный сигнал.
• Топ страниц по входящим ссылкам. Страницы, на которые ведут внешние ссылки, критично не потерять — их редиректы приоритетны.
• Текущие метатеги и заголовки. Выгрузка title, description и H1 всех значимых страниц. Понадобится, чтобы проверить, что после переноса они не потерялись.
• Технические параметры. Текущий robots.txt, sitemap.xml, настройки canonical, склейка зеркал. Их нужно воспроизвести на новом сайте осознанно, а не по умолчанию.

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

Инвентаризация URL: собираем все адреса

Карта редиректов настолько хороша, насколько полон список старых адресов, который в неё лёг. Главная ошибка на этом этапе — собрать URL из одного источника (например, только из sitemap) и решить, что этого достаточно. На практике часть трафикоприносящих страниц в карту сайта не попадает, а в индексе и в ссылочном профиле они есть.

Собирайте адреса минимум из трёх независимых источников и объединяйте их:

Объединив источники и убрав дубли, вы получите реестр всех адресов, которые нужно провести через миграцию. Пометьте в нём приоритет: страницы с трафиком и ссылками — высший приоритет, технические и «мусорные» URL (сортировки, служебные параметры) — низший, их часто вообще не нужно тащить на новый сайт. Кстати, разбор того, как чистить такие технические адреса и склеивать дубли, мы подробно разложили в статье про редиректы, 404 и склейку URL в 1С-Битрикс — при миграции эти же приёмы работают на полную.

Карта 301-редиректов — сердце миграции

Если структура URL меняется, карта редиректов — самый важный артефакт всей миграции. Это таблица соответствий «старый адрес → новый адрес», где каждому старому URL сопоставлен ровно один релевантный новый. От её полноты и точности напрямую зависит, переживёт ли переезд накопленный вес страниц.

Почему именно 301, а не 302? Код 301 означает «перемещено навсегда» и служит поисковику сигналом переносить накопленный вес со старого адреса на новый и заменять старый URL в индексе на новый. Код 302 («временно») такого переноса не гарантирует — робот может продолжать держать в индексе старый адрес. При постоянной миграции нужен именно 301.

Как строить карту, чтобы не наплодить проблем:

1. Сопоставляйте по смыслу, а не по шаблону. Каждый старый URL должен вести на страницу с максимально близким содержимым: раздел на аналогичный раздел, карточку на ту же карточку. Массовое перенаправление «всё на главную» вес не переносит.
2. Автоматизируйте типовое, проверяйте руками исключения. Если новая структура получается из старой по правилу (например, поменялся только префикс пути), напишите правило-шаблон. Но нетиповые адреса — объединённые разделы, удалённые товары, переименованные категории — размечайте вручную.
3. Избегайте цепочек. Редирект должен вести сразу на финальный адрес. Если старый URL уже когда-то куда-то редиректился, ведите его на конечную страницу напрямую, а не через промежуточные звенья.
4. Решите судьбу удалённых страниц. Товары, которых больше не будет, можно вести на родительский раздел или на замену. Отдавать по ним 404/410 стоит только осознанно — для действительно ненужных страниц без трафика и ссылок.
5. Сохраняйте регистр и слэши. Приведите правила к единому виду: один вариант со слэшем в конце, один регистр. Разнобой порождает дубли уже на новом сайте.

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

Сохранение URL и ЧПУ при переезде

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

1С-Битрикс это позволяет: через настройки ЧПУ инфоблоков, правила обработки адресов и символьные коды разделов и элементов можно воспроизвести практически любую схему URL. Если старый магазин отдавал карточки по пути /catalog/razdel/tovar/, новый на Битриксе можно настроить так же — задав символьные коды и шаблон ЧПУ, а не соглашаясь на дефолтные адреса с идентификаторами.

Что важно проверить при сохранении URL:

• Символьные коды. Убедитесь, что при импорте товаров и разделов их символьные коды (транслитерация названий) совпадают со старыми путями, а не генерируются заново.
• Завершающий слэш. Определитесь с единой политикой — со слэшем или без — и настройте её на уровне правил обработки URL, чтобы обе версии не открывались одновременно.
• Регистр. Приведите адреса к нижнему регистру и настройте склейку, если старый сайт был к регистру нечувствителен.
• Пагинация и фильтры. Схема адресов страниц каталога, фильтров и постраничной навигации тоже должна совпадать или получить продуманные редиректы.

Если же адреса всё-таки меняются, ЧПУ на новом сайте нужно проектировать осознанно — по-человечески и под SEO. Как выстроить чистые человекопонятные адреса для каталога и фильтров именно на Битриксе, мы подробно разобрали в отдельной статье про ЧПУ в 1С-Битрикс. При миграции лучше сразу заложить правильную схему URL, чтобы не переезжать ещё раз.

Перенос контента, метатегов и микроразметки

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

Что нужно перенести без потерь для каждой значимой страницы:

• Тексты и описания. Описания разделов, SEO-тексты внизу категорий, характеристики и описания товаров, статьи, отзывы. Всё, что было проиндексировано, должно остаться.
• Заголовки. H1 страницы и иерархия H2/H3. Новый шаблон не должен молча заменить H1 на название сайта или спрятать его.
• Метатеги. Title и description — по возможности точь-в-точь либо по тому же принципу генерации. Если старый сайт имел уникальные вручную заданные метатеги, их нельзя терять под шаблонными.
• Микроразметка. Разметка товаров, хлебных крошек, организации, отзывов (Schema.org). После переезда её нужно воспроизвести, иначе потеряются расширенные сниппеты.
• Внутренняя перелинковка. Блоки «похожие товары», «с этим покупают», ссылки из текстов, меню и хлебные крошки. Перелинковка — это тоже сигнал структуры, и её обеднение чувствуется.
• Атрибуты изображений. Alt и имена файлов картинок, особенно если магазин получал трафик из поиска по картинкам.

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

Технические сигналы: robots, sitemap, canonical

Даже при идеальных редиректах и сохранённом контенте миграцию можно сорвать одной строчкой в robots.txt. Технические директивы управляют тем, что робот вообще увидит, поэтому их проверяют особенно педантично.

Отдельно про canonical при переезде на новый домен: очень частая и коварная ошибка — когда на боевом сайте остаются канонические ссылки, указывающие на тестовый (staging) домен, где сайт собирали. Робот получает сигнал «настоящий адрес вон там», и весь свежий сайт начинает канонизироваться на несуществующий или закрытый контур. Проверка canonical на живом сайте — обязательный пункт дня запуска.

Ещё один нюанс — старый и новый sitemap. На время склейки полезно, чтобы поисковик увидел и переобошёл старые адреса (и получил по ним 301). Поэтому старую карту сайта не всегда стоит мгновенно удалять: иногда её оставляют доступной ненадолго, чтобы ускорить переобход и склейку, а затем заменяют новой.

Реализация в 1С-Битрикс

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

Правила обработки адресов (ЧПУ). Схема URL в Битриксе задаётся через настройки ЧПУ инфоблоков и файл правил обработки адресов (urlrewrite). Здесь воспроизводится нужный шаблон путей к разделам, товарам, фильтрам. Именно тут вы либо сохраняете старые адреса, либо задаёте новую чистую схему.

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

Редиректы. Постраничные 301-редиректы реализуют несколькими способами в зависимости от объёма:

1. На уровне веб-сервера. Для больших карт редиректов правила выносят в конфигурацию Apache (.htaccess) или Nginx. Это самый быстрый способ — редирект отрабатывает до запуска PHP, не нагружая платформу.
2. Через ядро Битрикса. Небольшие и точечные редиректы удобно вести таблицей соответствий и обрабатывать в init.php или через обработчик события, отдавая заголовок 301 и корректный Location.
3. Через модуль SEO / инструменты. Для типовых задач подходят штатные инструменты управления редиректами и работой с URL, если они закрывают ваш сценарий.

Карта сайта и robots.txt. В Битриксе sitemap.xml генерируется штатным модулем поиска/SEO по расписанию — настройте его на новую структуру и включите автообновление. robots.txt редактируется в настройках модуля SEO; главное на запуске — убедиться, что там нет унаследованного со staging запрета на индексацию.

Кэширование и скорость. Чтобы новый сайт не встретил робота таймаутами, заранее прогрейте кэш и включите композитный режим для витрины. Медленный на старте каталог снижает частоту обхода как раз в тот момент, когда переобход особенно нужен. Об инвентаре чистки URL и склейке дублей на самой платформе — в материале про редиректы, 404 и склейку URL в 1С-Битрикс.

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

Миграцию нельзя проверять на боевом сайте — все проверки делают на тестовом контуре (staging), максимально похожем на будущий прод. Но именно staging порождает две самые обидные ошибки миграции, поэтому с ним нужна дисциплина.

Первая ловушка — тестовый контур должен быть закрыт от индексации, пока идёт работа, иначе поисковик проиндексирует черновик и получит дубль сайта. Закрывают через HTTP-авторизацию (надёжнее всего) или robots.txt с полным запретом.

Вторая ловушка — эту же заглушку нужно обязательно снять при переключении на прод. Забытый запрет индексации со staging — классическая причина, по которой новый сайт после запуска молча выпадает из индекса. Поэтому «снять запрет индексации» — первый пункт чек-листа дня запуска.

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

• Прогнать карту редиректов краулером — каждый старый URL отдаёт 301 на верный новый адрес, без цепочек и 404.
• Сверить метатеги и заголовки значимых страниц со снимком «до».
• Проверить микроразметку валидатором.
• Убедиться, что живые страницы отдают 200, удалённые — 404/410, canonical указывает на сам новый URL.
• Проверить скорость и доступность каталога под нагрузкой, прогреть кэш.

Сам день запуска лучше планировать на период низкого трафика и держать под рукой чек-лист переключения: снять запрет индексации, включить редиректы, обновить sitemap и robots.txt, оформить переезд в панелях вебмастеров (при смене домена — через штатный инструмент переезда), отправить новый sitemap на переобход. И сразу начать мониторинг.

Мониторинг индексации после запуска

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

За чем следить и как часто:

Особую ценность в первые недели дают логи сервера: они показывают, по каким именно старым адресам ходит робот и что он получает в ответ. Если в логах видно, что робот стучится по старому URL и получает 404, — вы нашли дырку в карте редиректов ещё до того, как это отразилось на трафике. Анализ логов вообще недооценён в SEO; тому, как выжимать из них пользу на Битриксе, посвящена отдельная статья рубрики SEO и продвижение.

Практический ритм мониторинга: первую неделю — ежедневно, второй-четвёртую — через день, дальше — раз в неделю до полной стабилизации. Каждую найденную ошибку (404 без редиректа, потерянный метатег, обеднённую страницу) заводите в список и закрывайте сразу — на свежем переезде это делается быстро.

Редизайн без смены URL: отдельный случай

Редизайн часто считают безопасным — «мы же не переезжаем, просто обновляем дизайн». На деле именно редизайны нередко роняют трафик, потому что под видом визуальной переработки меняют то, что видит поисковик. Разберём, как обновить оформление без последствий.

Хорошая новость: если URL остаются прежними, редиректы почти не нужны, и это резко снижает риск. Плохая — риск смещается в контент и разметку, которые легко потерять в новом шаблоне. Вот на что смотреть при редизайне:

• Сохранён контент. SEO-тексты категорий, характеристики, отзывы, описания не выкинуты ради «воздуха». Если что-то мешает дизайну — прячьте в аккордеон, а не удаляйте.
• Сохранены заголовки. H1 остались на месте и с тем же смыслом, иерархия H2/H3 не сломана визуальными заголовками без семантики.
• Сохранены метатеги. Новый шаблон не подменил уникальные title/description шаблонными.
• Сохранена перелинковка. Блоки «похожие», «с этим покупают», ссылки из текстов и меню не выпали.
• Сохранена микроразметка. Разметка товаров и хлебных крошек воспроизведена в новой вёрстке.
• Не пострадала скорость. Новый шаблон не утяжелил страницы настолько, что просели Core Web Vitals.

Редизайн тоже прогоняют через тестовый контур и сравнивают краулером старую и новую версии страниц: тот же ли объём текста, те же ли метатеги и заголовки. Если совпадает — редизайн переживётся практически без колебаний. Если новая версия «легче» — верните потерянное до выката.

Сроки восстановления и что считать нормой

Один из самых частых вопросов после запуска — «трафик просел, это нормально или мы что-то сломали?». Чтобы не паниковать раньше времени и не проспать реальную проблему, полезно держать в голове ориентиры.

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

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

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

• Собрали список старых URL только из sitemap и упустили страницы, которые были в индексе и приносили трафик, — по ним не оказалось редиректов.
• Перенаправили все старые адреса на главную вместо релевантных страниц — получили «мягкие 404», вес не перенёсся.
• Использовали 302 вместо 301 — поисковик не стал переносить вес и держит в индексе старые адреса.
• Забыли снять запрет индексации со staging при переключении на прод — сайт молча выпал из индекса.
• Оставили canonical, указывающий на тестовый домен, — свежий сайт канонизировался на несуществующий адрес.
• Выкинули при редизайне SEO-тексты и характеристики ради чистого вида — страницы обеднели для поиска.
• Позволили новой CMS сгенерировать свои шаблонные метатеги вместо перенесённых уникальных.
• Не проверили карту редиректов краулером до запуска — часть правил вела в 404 или в цепочки.
• Запустили сайт и «посмотрели через месяц» — потеряли недели, за которые ошибку можно было закрыть за день.

Чек-лист миграции

Сведём всё в практический список, по которому удобно вести переезд от подготовки до стабилизации:

1. Снимок «до» сделан. Зафиксированы трафик за год, позиции ядра, число страниц в индексе, топ страниц по ссылкам, метатеги и заголовки.
2. URL инвентаризированы. Список старых адресов собран из CMS, аналитики, панелей вебмастеров, ссылочного профиля и логов; проставлен приоритет.
3. Решён вопрос сохранения URL. Где возможно — адреса сохранены один в один; где нет — построена полная карта 301.
4. Карта редиректов готова и проверена. Каждый значимый старый URL ведёт на релевантный новый, без цепочек и без «всё на главную».
5. Контент перенесён без потерь. Тексты, H1, метатеги, микроразметка, перелинковка и alt изображений на месте.
6. Технические сигналы настроены. robots.txt открыт, sitemap на новые URL, canonical на сам новый адрес, коды ответов корректны.
7. Staging проверен и закрыт. Тестовый контур недоступен для индексации, все проверки пройдены краулером и валидатором.
8. День запуска отработан. Снят запрет индексации, включены редиректы, оформлен переезд в вебмастерах, sitemap отправлен на переобход.
9. Мониторинг запущен. Ежедневно отслеживаются индекс, 404, обход роботом, трафик и позиции; ошибки закрываются сразу.
10. Стабилизация подтверждена. Через 1–2 месяца трафик вернулся к прежнему уровню, список исправлений пуст.

Если переезд на 1С-Битрикс идёт с другой платформы и затрагивает не только SEO, но и бизнес-процессы, каталог и интеграции, — стоит посмотреть на него шире. Общую логику и подводные камни такого проекта мы разобрали в статье «Миграция интернет-магазина на 1С-Битрикс с другой платформы»: она хорошо дополняет этот SEO-разбор со стороны стратегии и данных.

Вывод

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