Миграция с 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 и ЧПУ, настройка редиректов, перенос пользователей. Каждый этап можно выполнять на копии БД, чтобы не трогать прод до финальной проверки.

1. Экспорт данных из WordPress
2. Импорт в Bitrix
3. Сохранение структуры URL
4. Настройка 301
5. Перенос пользователей

---

1. Экспорт постов и страниц из 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');

---

2. Импорт в 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 для всех записей.

---

3. Сохранение структуры 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#/"
]

---

4. 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/",
]);

---

5. Перенос пользователей

Из 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 записывать её в отдельные свойства инфоблока или в отдельные поля; в шаблоне детальной страницы выводить эти поля в <title> и мета-тегах.

---

❌ Изменили структуру 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 и корректным редиректам: нарушил — заплатил трафиком.