Миграция с WordPress на Bitrix без потери SEO
Поисковый запрос «миграция с WordPress на Bitrix» обычно означает одно: нужно перенести проект без падения трафика и без пересборки индекса с нуля. Статья для тех, кто уже решил перейти на Bitrix и кому важно не потерять позиции и переходы из поиска.
Цель — сохранить структуру URL, метаданные (title, description, canonical), пользователей и поведенческие факторы. Ниже — конкретные шаги: экспорт из БД WordPress, импорт в Bitrix с сохранением slug, настройка ЧПУ и 301, проверка и типичные ошибки.
Сниппеты по статье
Готовые проверенные фрагменты по шагам миграции:
- WordPress: экспорт постов и SEO-меты для миграции (SQL) — выгрузка из wp_posts и wp_postmeta
- Bitrix: SEF и шаблон URL для блога — настройка ЧПУ с ELEMENT_CODE
- Nginx: 301 rewrite при смене структуры URL — постоянный редирект ветки адресов
- Bitrix: UrlRewriter — правило 301 редиректа — точечные редиректы через API
В чём проблема
Типичные симптомы при кривой миграции: старые ссылки из поиска и закладок перестают открываться, в панелях вебмастеров растёт число ошибок доступа, трафик из органики падает.
- ❌ 404 на старых URL
- ❌ Потеря meta title / description
- ❌ Слетевшие canonical
- ❌ Обнулённые позиции в Яндексе и Google
- ❌ Пользователи не могут авторизоваться
Подробнее про работу WordPress «под капотом» и настройку окружения — в статьях «WordPress: системный cron вместо WP-Cron» и «WordPress: долгая загрузка, TTFB, nginx и PHP-FPM».
WordPress хранит данные в:
- wp_posts
- wp_users
- wp_usermeta
- wp_terms
- wp_term_relationships
- wp_postmeta
Bitrix работает через инфоблоки и таблицы:
- b_iblock_element
- b_iblock_section
- b_user
- b_utm_*
Если просто «залить HTML» или перенести только текст без сохранения адресов и метаданных, поисковики перестают считать страницы теми же самыми: меняется URL — теряется история ссылок и поведенческие факторы. В итоге позиции обнуляются, трафик падает. Поэтому миграция без потери SEO — это всегда экспорт структуры (slug, meta, категории), настройка ЧПУ в Bitrix и обязательные 301-редиректы со старых адресов.
Рабочее решение
Миграция делится на 5 этапов: экспорт из WordPress, импорт в Bitrix, настройка URL и ЧПУ, настройка редиректов, перенос пользователей. Каждый этап можно выполнять на копии БД, чтобы не трогать прод до финальной проверки.
- Экспорт данных из WordPress
- Импорт в Bitrix
- Сохранение структуры URL
- Настройка 301
- Перенос пользователей
- Экспорт постов и страниц из WordPress
Нужны посты и страницы из wp_posts и метаданные SEO из wp_postmeta (плагины вроде Yoast или Rank Math хранят там title, description и canonical). Прямой доступ к БД быстрее и надёжнее, чем выгрузка через админку. Оба запроса ниже можно выполнить в phpMyAdmin или из консоли MySQL; результат сохраняем в JSON для следующего шага. Готовый сниппет с пояснениями и ссылками на документацию: WordPress: экспорт постов и SEO-меты для миграции (SQL).
-- Посты и страницы
SELECT ID, post\_title, post\_name, post\_content, post\_date, post\_type, post\_status
FROM wp\_posts
WHERE post\_type IN ('post','page') AND post\_status = 'publish';
-- Мета SEO (title, description, canonical)
SELECT post\_id, meta\_key, meta\_value
FROM wp\_postmeta
WHERE meta\_key IN ('\_yoast\_wpseo\_title', '\_yoast\_wpseo\_metadesc', '\_yoast\_wpseo\_canonical');
- Импорт в Bitrix через Python
Пример скрипта (через REST или прямой PHP endpoint):
import requests
import json
with open("wp\_export.json", "r", encoding="utf-8") as f:
data = json.load(f)
for post in data:
payload = {
"IBLOCK\_ID": 5,
"NAME": post["post\_title"],
"CODE": post["post\_name"], # важно для URL
"ACTIVE": "Y",
"PREVIEW\_TEXT": post["post\_content"],
}
requests.post(
"https://staging-site.ru/api/import.php",
json=payload
)
Ключевой момент — поле CODE в Bitrix должно совпадать с post_name из WordPress. Тогда адрес вида /blog/post-name/ останется тем же, и поисковики увидят тот же URL. Импорт можно делать через REST API Bitrix или через свой PHP-скрипт на временном endpoint; в примере выше используется один общий endpoint для всех записей.
- Сохранение структуры URL
В WordPress адреса часто выглядят как /blog/post-name/ или /category/design/. В Bitrix нужно явно включить ЧПУ (SEF) и задать шаблон так, чтобы символьный код элемента подставлялся в URL. Создаём раздел с псевдонимом blog, в настройках сайта включаем SEF и указываем папку, например /blog/. Шаблон детальной страницы — #ELEMENT_CODE#/, тогда адрес будет /blog/имя-element-code/. В компоненте списка новостей (например, news) задаём (подробнее — в сниппете Bitrix: SEF и шаблон URL для блога):
"SEF\_MODE" => "Y",
"SEF\_FOLDER" => "/blog/",
"SEF\_URL\_TEMPLATES" => [
"detail" => "#ELEMENT\_CODE#/"
]
- 301 редиректы
Если часть URL изменилась (например, был /category/, стал /blog/), все старые адреса должны отдавать 301 с новым Location. Иначе поисковики будут считать страницы удалёнными или дублями. Редиректы можно настроить в nginx для массовых правил (один rewrite на целую ветку старых URL) или в Bitrix через UrlRewriter для точечных перенаправлений. Готовые сниппеты: Nginx: 301 rewrite при смене структуры URL, Bitrix: UrlRewriter — правило 301 редиректа. Базовые приёмы nginx — в «Nginx: основы веб-сервера»:
rewrite ^/old-category/(.\*)$ /blog/$1/ permanent;
Или массово через таблицу редиректов Bitrix (модуль «Управление структурой» или API UrlRewriter в том же проекте, где настраивали SEF):
use Bitrix\Main\UrlRewriter;
UrlRewriter::add([
"CONDITION" => "#^/old-url/$#",
"RULE" => "",
"ID" => "",
"PATH" => "/new-url/",
]);
- Перенос пользователей
Из WordPress: SELECT ID, user_login, user_email, user_pass FROM wp_users;. В Bitrix создаём пользователей так:
$user = new CUser;
$arFields = [
"LOGIN" => $wpUser["user\_login"],
"EMAIL" => $wpUser["user\_email"],
"PASSWORD" => bin2hex(random\_bytes(8)),
"ACTIVE" => "Y"
];
$user->Add($arFields);
Пароли из WordPress (хеш в user_pass) нельзя подставить в Bitrix: алгоритмы и соль разные. Поэтому при переносе пользователей задаём временный пароль (в коде выше — случайная строка) и при первом входе отправляем пользователю сброс пароля по email либо даём инструкцию сменить пароль в личном кабинете. Так вы сохраните учётки и доступ без взлома старых хешей.
Проверка результата (диагностика)
Диагностика после миграции сводится к трём проверкам: новый URL отдаёт 200, старые адреса отдают 301 с правильным Location, в sitemap перечислены те же URL, что и раньше (или новые, если вы сознательно сменили структуру и настроили редиректы). Команды ниже выполняйте с подставленным вашим доменом.
URL страницы — ожидаем HTTP/1.1 200 OK
curl -I https://site.ru/blog/post-name/
Старый URL — ожидаем 301 Moved Permanently и Location: https://site.ru/new-url/
curl -I https://site.ru/old-url/
Sitemap: URL в файле должны совпадать со старыми
curl https://site.ru/sitemap.xml
Проверка индексации
После переключения прод-домена на Bitrix в Яндекс.Вебмастер и Google Search Console нужно заново отправить sitemap и при необходимости запросить переобход важных URL. Раздел «Покрытие» (coverage) покажет, какие страницы в индексе и нет ли массовых 404. Первые дни возможны временные просадки; если 301 настроены и URL совпадают, через 1–2 недели индекс стабилизируется.
Если не работает
Ниже — частые причины сбоев и что проверить в первую очередь. Если после миграции часть страниц отдаёт 404, трафик падает или пользователи не могут войти — пройдите по пунктам ниже и сверьтесь с разделом «Проверка результата (диагностика)». Чаще всего проблема в пропущенном этапе: забыли мету, поменяли slug или не настроили редиректы. Проверка по чек-листу выше обычно выявляет причину.
Типичные ошибки
❌ Не перенесли meta description
Причина: выгрузили только wp_posts и не учли wp_postmeta, где лежат title, description и canonical от Yoast/Rank Math. Решение: выгрузить мету (запрос выше) и при импорте в Bitrix записывать её в отдельные свойства инфоблока или в отдельные поля; в шаблоне детальной страницы выводить эти поля в
и мета-тегах.❌ Изменили структуру URL
Причина: в Bitrix включили SEF, но символьный код элемента (CODE) задали произвольно или из названия, а не из post_name WordPress. В итоге адреса отличаются, старые ссылки ведут в никуда. Решение: при импорте строго задавать CODE = post_name для каждой записи и проверять по списку, что URL совпадают.
❌ Не сделали 301
Причина: надеялись, что поисковик «переиндексирует» или что достаточно обновить sitemap. Без 301 старые URL считаются мёртвыми, ссылочный вес и поведенческие факторы не передаются на новый адрес. Решение: для каждого старого адреса настроить 301 на новый (nginx или UrlRewriter в Bitrix), затем проверить через curl -I.
❌ Потеряли теги
Причина: в WordPress теги и категории хранятся в wp_terms и wp_term_relationships; если их не выгрузить и не завести в Bitrix (разделы инфоблока или HighloadBlock), на новом сайте пропадут рубрики и теги. Решение: экспортировать термины и связи, при импорте создавать разделы или записи в HighloadBlock и привязывать элементы к ним.
Где применять
Подход подходит для продакшена при полной смене CMS с WordPress на Bitrix, в том числе в Docker или на BitrixVM (после переноса имеет смысл проверить SSL и при необходимости обновить сертификаты). Особенно важно сохранять URL и 301 для проектов с существенным SEO-трафиком и для интернет-магазинов, у которых блог или статьи переносятся в Bitrix отдельно от каталога. Перед выкатом на прод стоит прогнать все шаги на копии сайта и убедиться, что количество записей, разделов и пользователей совпадает с выгрузкой из WordPress.
Итог
Миграция с WordPress на Bitrix — это не «экспорт-импорт» одной кнопкой, а последовательность: выгрузка постов и меты, импорт с сохранением символьного кода, настройка ЧПУ, 301 и проверка. Если сохранить slug, структуру URL, meta-поля, настроить 301 и актуальный sitemap, позиции не падают. Если хоть один пункт пропустить — получите просадку трафика на 30–70% в первые две недели. SEO здесь сводится к структуре, предсказуемым URL и корректным редиректам: нарушил — заплатил трафиком.
Top comments (0)