Почему миграции с WordPress на Bitrix рушат SEO

Коротко: SEO падает не из-за смены CMS. Оно падает из-за неправильной архитектуры миграции и игнорирования структуры URL.

За последние годы я участвовал в нескольких переносах проектов с WordPress на Bitrix с трафиком от 50 000 до 300 000 визитов в месяц. В 80% случаев просадка происходила не из-за «плохого Bitrix», а из-за управленческих и архитектурных ошибок. В оставшихся 20% причиной оказывались технические просчёты: не те редиректы, смена адресов «для красоты» или перенос только контента без метаданных. Ниже — о том, в чём именно спор, что происходит в реальности и при каких условиях миграция не бьёт по трафику.

В чём спор

Обычно говорят:

• «CMS не влияет на SEO»
• «Главное — контент, поисковик разберётся»
• «Редиректы можно сделать потом»

Формально доля правды в этом есть: сама по себе система управления контентом не ранжируется. Но то, что из неё следует — URL-модель, структура разделов, скорость ответа сервера и поведение при переезде — уже влияет на индексацию и ранжирование. Поисковые системы реагируют не на название CMS, а на то, остались ли прежними адреса страниц, не посылаете ли вы пользователей и роботов на 404 и не подменили ли вы один документ другим без явного сигнала (301). Игнорировать это — значит заранее закладывать просадку. То же касается тезиса «редиректы потом»: после переключения домена старые URL начинают отдавать 404, ссылочный вес и поведенческие факторы теряются, и «доделать потом» уже не восстанавливает прежнюю картину в глазах поисковика.

Что происходит в реальности

При типичной миграции с WordPress на Bitrix я сталкиваюсь с одними и теми же проблемами:

• Меняется структура URL: было «/blog/post-name/», стало «/news/123/» или «/katalog/stati/post-name/»
• Теряются slug: в WordPress адрес задаётся полем post_name, в Bitrix — полем CODE; при некорректном маппинге адреса расходятся
• Мета-поля не переносятся: title, description и canonical остаются в старой базе или подставляются шаблоном по умолчанию
• Не настроены 301-редиректы: старые ссылки из выдачи и с других сайтов оказываются битыми или ведут на временный редирект (302), что не передаёт вес
• Sitemap публикуется с задержкой или содержит уже неактуальные URL

В результате поисковик фиксирует: часть страниц пропала, часть появилась по новым адресам, часть ссылок ведёт на 404, canonical изменился. Он не «понимает», что вы переехали; он видит разрыв целостности сайта и переоценивает его. Типичный пример из практики: проект с примерно 120 000 визитов в месяц после «технического переноса» без сохранения slug через три недели снизил трафик примерно до 47 000. Причина — массовые 404 на старых URL и частичные редиректы вместо сквозных 301. В другом кейсе заказчик настаивал на смене структуры каталога «под новую логику»; через два месяца органический трафик упал почти вдвое, и возврат к старой схеме URL с 301 уже не вернул позиции в прежний вид — пришлось выводить сайт из просадки месяцами. Оба случая объединяет одно: решение о миграции принималось без жёсткого требования сохранить адреса и без плана по редиректам.

Когда миграция не убивает SEO

Перенос безопасен для трафика, если соблюдены условия:

• Slug полностью совпадает со старым: адрес страницы после переноса тот же, что и в WordPress
• Структура вложенности не изменилась: если были разделы и подразделы, они сохраняются в том же виде
• Meta title и description перенесены и отображаются в выдаче так же, как раньше (или осознанно улучшены)
• Все старые URL отдают 301 permanent на новый адрес, без 302 и без 404
• Sitemap обновлён в день релиза и содержит актуальные адреса

В такой постановке CMS вторична: поисковику важна стабильная структура и предсказуемое поведение. Структура и дисциплина первичны; платформа — лишь инструмент. Отсюда практический вывод: перед переездом нужен чёткий чек-лист (выгрузка всех URL, маппинг slug → CODE, перенос мета-полей, настройка 301, обновление sitemap и проверка на staging), и ни один пункт нельзя откладывать «на потом».

Когда я бы не стал переносить проект

Я бы отложил или пересмотрел миграцию в таких случаях:

• Если 80% трафика — органика, а бизнес не готов к просадке на 1–2 месяца. Восстановление индекса и доверие после сбоев занимает время; это нужно закладывать в планы
• Если нет staging или тестового окружения для полной проверки до переключения прод-домена
• Если нет выгрузки всех URL старого сайта: без полного списка адресов невозможно настроить 301 и проверить покрытие
• Если команда путает 302 и 301 или не понимает разницы между временным и постоянным редиректом

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

Технический аспект

Без эмоций, только факты:

• URL-модель: в WordPress slug хранится в поле post_name, в Bitrix — в поле CODE элемента инфоблока. Ошибка в маппинге при переносе ломает адреса и делает старые ссылки нерабочими
• SEO-поля: в WordPress метаданные страниц часто лежат в wp_postmeta (в том числе при использовании Yoast, Rank Math и аналогов), в Bitrix — в свойствах инфоблока или отдельных полях; перенос должен быть явно спроектирован
• Редиректы: эффективнее и надёжнее настраивать на уровне веб-сервера (nginx или аналог), а не только средствами CMS, особенно при массовых правилах
• Производительность: «голый» Bitrix без кеша и оптимизаций обычно тяжелее типового WordPress; это может отразиться на Core Web Vitals и косвенно на ранжировании

Проверка после миграции сводится к простым шагам: убедиться, что запрос к старому URL возвращает ответ 301 с заголовком Location на новый адрес, а запрос к новому URL — ответ 200. Если вместо этого вы видите 404 или 302, позиции и трафик будут падать, пока ситуация не исправлена. Имеет смысл заранее подготовить список ключевых страниц (топ по трафику и по ссылочному весу) и после переключения пройтись по нему вручную или с помощью скриптов, проверяя статус-коды и заголовки. То же касается sitemap и раздела «Покрытие» в панелях вебмастеров: расхождения между старым и новым списком URL нужно устранять сразу, а не «в следующем спринте».

Типичные ошибки при принятии решения

Чаще всего встречаются такие просчёты:

• Переносят только HTML-контент, не заботясь о slug, мета-тегах и редиректах
• Меняют структуру URL «чтобы стало красивее» или «логичнее», не оценивая последствия для индекса
• Игнорируют категории и теги: в WordPress они живут в своей модели данных, в Bitrix их нужно явно смоделировать (разделы, Highload и т.п.)
• Забывают снять запрет индексации или открыть сайт для роботов после переноса
• Не проверяют robots.txt и настройки в панелях вебмастеров после переключения

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

Моя позиция

SEO рушит не Bitrix и не WordPress. Его рушит небрежная миграция.

Если при переносе сохраняется структура URL, корректно настроены 301, перенесены метаданные и проведено тестирование на staging до выката на прод — трафик остаётся стабильным. Если хотя бы один из этих пунктов пропущен — просадка практически гарантирована.

CMS — инструмент. Структура и дисциплина — основа. Понимание этого и отличает миграцию, после которой сайт продолжает приносить трафик, от той, после которой месяцами разгребают последствия. Резюмируя: винить Bitrix или WordPress в просадке трафика после переезда — значит смотреть не туда. Смотреть нужно на то, сохранили ли вы адреса и сигналы для поисковика; если да — смена платформы остаётся прозрачной и для пользователей, и для роботов. Если нет — просадка почти неизбежна, и исправлять придётся уже по факту, с потерями во времени и в деньгах.