Миграция на WordPress и интеграции: переносим сайт с конструктора, подключаем CRM, 1С и почту

Меня зовут Евгений Семёнов, я технический директор компании «АйТи Фреш». Мы больше пятнадцати лет занимаемся IT-аутсорсингом для московских компаний до 50 рабочих мест, держим собственные серверы в дата-центре МТС и в среднем раз в месяц перевозим чей-нибудь сайт на WordPress. В первой статье серии я объяснял, почему из всех CMS мы чаще всего ставим именно его, а в материале про развёртывание — как готовим под него боевой сервер. Сегодня — самая нервная часть темы: как перевезти живой сайт со старого места, ничего не потеряв, и как затем встроить его в рабочий контур компании — CRM, 1С, почту, аналитику.

Почему к нам мигрируют на WordPress: три типовых триггера

За последние годы у нас накопилась статистика обращений «перевезите наш сайт», и почти все они укладываются в три сюжета:

• Конструктор упёрся в потолок. Tilda или Wix прекрасно закрывают первый год жизни сайта, а потом выясняется, что нужной функции нет, тариф подорожал в очередной раз, а главное — сайт нельзя забрать с собой. Экспортированные страницы без подписки мертвы: формы, CMS-блоки и «магазинная» часть остаются на стороне сервиса.
• Самописный движок остался без автора. Классика: сайт десять лет назад написал знакомый программист, программист уехал/пропал/сменил профессию, документации нет, PHP на сервере обновлять страшно. Каждая правка страницы превращается в квест.
• Joomla или Drupal нечем поддерживать. Движки сами по себе достойные, но специалистов по ним на рынке РФ с каждым годом меньше, а стоимость их часа — выше. Обновления откладываются, сайт обрастает уязвимостями.

Общий знаменатель я формулирую заказчикам одной фразой: сайт на конструкторе вы арендуете, сайт на WordPress — принадлежит вам. Перестали платить Tilda — сайта нет. Перестали платить подрядчику по WordPress — сайт продолжает работать, а папку с файлами и дамп базы вы можете отдать любому другому исполнителю хоть завтра.

Инвентаризация перед переносом: что фиксируем на берегу

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

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

Сценарий 1: переезд с конструктора (Tilda, Wix)

Экспорт контента: что отдаёт конструктор, а что нет

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

Вёрстка заново: почему «пиксель-в-пиксель» не нужен

Соблазн скопировать дизайн один в один велик, но мы почти всегда отговариваем. Во-первых, копирование чужой вёрстки со всеми её костылями стоит дороже, чем аккуратная пересборка на Gutenberg или блочной теме. Во-вторых, у конструкторов свои типографика и сетка, которые в WordPress всё равно придётся эмулировать хаками. Мы сохраняем логотип, палитру, порядок блоков и смысловую структуру страниц — то, что узнают посетители и поисковики, — а техническую реализацию делаем нативной для WordPress. Клиент получает сайт, который его контент-менеджер сможет править стандартными блоками, а не бояться тронуть.

Карта редиректов 301: главная страховка SEO

URL на конструкторах почти никогда не совпадают с новой структурой: у Tilda страницы вида /page12345.html либо алиасы, у Wix — свои пути. На каждый старый адрес из инвентаризации назначаем новый и оформляем постоянный редирект 301. На небольших сайтах хватает плагина Redirection, но на наших серверах мы предпочитаем nginx — быстрее и не зависит от здоровья самого WordPress:

# /etc/nginx/conf.d/redirect-map.conf
map $request_uri $redirect_target {
    /page12345.html          /uslugi/it-autsorsing/;
    /page12346.html          /uslugi/obsluzhivanie-1c/;
    /stariy-catalog          /catalog/;
    ~^/news/(?<y>\d{4})-(.*) /blog/$2;   # шаблонные правила regex
}

# в блоке server {}
if ($redirect_target) {
    return 301 $redirect_target;
}

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

Сценарий 2: со старой CMS или самописки

Перенос базы: штатный импорт против SQL-хирургии

Если источник — Joomla, Drupal или самописка с внятной базой, путей два. Первый — экспорт в формат WXR и штатный wp import (или специализированные плагины-мигранты): медленно на больших объёмах, зато безопасно, все хуки и связи WordPress отрабатывают как положено. Второй — прямая заливка SQL-скриптами в wp_posts и wp_postmeta: быстро, но вы обязаны сами позаботиться о slug-ах, GUID, привязке рубрик и миниатюр. Наше правило: до нескольких сотен материалов — только штатный импорт; тысячи записей со сложными связями — скриптовая миграция, но с обязательным прогоном на копии и сверкой количества записей до и после.

Медиафайлы и миниатюры

Картинки переносим в wp-content/uploads с сохранением структуры по годам и месяцам, затем регистрируем их в медиабиблиотеке и перегенерируем все размеры миниатюр под новую тему — у неё почти наверняка другие размеры превью:

# зарегистрировать «сиротские» файлы в медиабиблиотеке
wp media import wp-content/uploads/2024/*/*.jpg --skip-copy

# перегенерировать миниатюры под размеры новой темы
wp media regenerate --yes

На каталоге в несколько тысяч изображений wp media regenerate может работать часы — запускаем в tmux на staging заранее, а не в ночь переключения.

Сериализованные данные: почему замену домена делаем только через wp search-replace

Самая коварная особенность WordPress — он хранит часть настроек в базе в сериализованном виде PHP: строка сопровождается своей длиной, например s:24:"https://old-site.example". Если заменить домен «в лоб» SQL-запросом с REPLACE(), длина строки перестанет совпадать с содержимым — и виджеты, настройки темы и половина опций плагинов молча превратятся в тыкву. Правильный инструмент один:

# сначала репетиция: показать, что будет заменено
wp search-replace 'https://old-site.example' 'https://new-site.example' \
    --all-tables --report-changed-only --dry-run

# затем боевой прогон
wp search-replace 'https://old-site.example' 'https://new-site.example' \
    --all-tables --precise

wp search-replace распаковывает сериализованные значения, меняет содержимое и пересчитывает длины. Флаг --dry-run обязателен: сперва смотрим отчёт, потом жмём на курок.

Сохранение структуры URL: лучший редирект — тот, который не понадобился

Если у старого сайта человеческие адреса вида /uslugi/podderzhka-serverov/, часто дешевле не строить карту редиректов, а воспроизвести структуру: настроить в WordPress кастомные пермалинки, совпадающие со старой схемой, и сохранить slug-и при импорте. Тогда для поисковика страница вообще «не переезжала» — сменился движок, адрес остался. Редиректы в этом случае нужны только точечно: для страниц, которые вы сознательно объединили или удалили.

Переключение без простоя: репетиция, TTL и вечер пятницы наоборот

Сам момент переезда мы превращаем из прыжка веры в скучную процедуру:

1. Staging-поддомен. Новый сайт живёт на new.site.ru, закрытом от индексации и посторонних глаз. На нём принимает работу заказчик, на нём же прогоняем краулер и тестируем формы.
2. Снижение TTL DNS за сутки. У A-записи домена TTL нередко стоит 4–24 часа. За день до переключения снижаем до 300 секунд — тогда в час X мир увидит новый адрес за минуты, а не за сутки.
3. Переключение вечером буднего дня. Не в пятницу (впереди выходные без техподдержки заказчика) и не в понедельник утром (пиковый трафик). Вторник–четверг после 19:00 — золотое окно: трафик минимален, впереди рабочие дни для наблюдения.
4. Мониторинг 404 первые двое суток. Смотрим access-лог nginx на предмет адресов, которые мы упустили в карте редиректов: awk '$9==404 {print $7}' access.log | sort | uniq -c | sort -rn | head -30. Всё осмысленное тут же дописываем в map-файл.
5. Откат-план. Старый сайт не выключаем минимум две недели. Если что-то пошло не так — возвращаем A-запись, и через пять минут (спасибо низкому TTL) работает старая версия.

Интеграция с CRM и телефонией: заявки должны падать туда, где их видят

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

Формы → CRM: вебхуки и UTM-метки

Формы собираем на Contact Form 7 или WPForms, а в CRM (amoCRM, Битрикс24, Planfix — у наших клиентов встречаются все три) отправляем вебхуком: либо готовым плагином-коннектором, либо коротким хуком на PHP, который постит JSON в API CRM. Принципиальный момент, который упускают в девяти случаях из десяти: вместе с полями формы надо передавать UTM-метки и адрес страницы-источника. Мы кладём UTM из адресной строки в cookie первым же визитом, а скрытые поля формы подхватывают их при отправке. Без этого через полгода никто не ответит на вопрос «какая реклама приносит заявки», и рекламный бюджет продолжит расходоваться вслепую.

Чаты и коллтрекинг: что через GTM, а что плагином

Онлайн-чат, квизы, пиксели ретаргетинга и коллтрекинг мы подключаем через Google Tag Manager — маркетологи потом сами включают и выключают теги, не дёргая разработчика и не залезая в тему. Плагином ставим только то, что должно менять сам HTML до загрузки страницы: например, подмену номера коллтрекинга в шапке лучше делать на стороне сервера, чтобы номер не «мигал» при загрузке.

REST API как универсальный мост

У WordPress из коробки есть REST API: любая запись, товар или заявка доступны по HTTP в JSON. Это выручает, когда готового коннектора нет. Свежий пример: заказчику нужно было выгружать заявки с сайта в общую таблицу для отдела продаж — вместо покупки интеграции мы написали скрипт на двадцать строк, который раз в десять минут забирает новые записи формы через REST API и дописывает их в таблицу. Час работы, ноль абонентской платы.

Каталог и 1С: WooCommerce, CommerceML и честные пределы

WooCommerce как каталог — даже без онлайн-оплаты

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

Обмен с 1С по CommerceML: как работает и когда начинает болеть

Стандартный протокол обмена «1С ↔ сайт» — CommerceML: та же схема, по которой 1С штатно обменивается с Битриксом, работает и с WooCommerce через плагины обмена. Мы обычно используем бесплатный «EDI – Обмен данными между WooCommerce и 1С» из официального каталога WordPress: он принимает номенклатуру, категории, характеристики, картинки, цены и остатки, а заказы умеет отдавать обратно в 1С вместе со статусами. Со стороны 1С настройка штатная — узел обмена с сайтом в «Управлении торговлей» или УНФ, расписание хоть каждые 15 минут.

Теперь честно про пределы, потому что это спрашивает каждый второй заказчик. По нашему опыту, до 3–5 тысяч SKU обмен живёт комфортно: полная выгрузка проходит за десятки минут, обновление цен и остатков — за минуты. Дальше начинаются нюансы: полный обмен упирается в лимиты PHP и время выполнения, картинки раздувают выгрузку, база WooCommerce тяжелеет от метаданных. На 10+ тысячах позиций мы либо переводим обмен на частичные выгрузки только изменённых позиций, либо честно говорим клиенту, что его масштабу нужна другая платформа — об этом я писал ещё в обзорной статье серии.

Онлайн-оплата и 54-ФЗ

Если оплата на сайте всё же нужна, подключаем российский платёжный шлюз официальным плагином (ЮKassa, Robokassa и аналоги — у всех есть модули под WooCommerce) и сразу решаем вопрос фискализации: по 54-ФЗ каждый онлайн-платёж требует чека. Проще всего, когда чеки пробивает облачная касса, интегрированная с тем же шлюзом, — тогда сайту не нужно знать о кассе вообще ничего. Этот блок настраивается за день, но только если о нём вспомнили до запуска, а не после первого платежа без чека.

Почта и уведомления: сайт не должен слать письма через mail()

По умолчанию WordPress отправляет почту PHP-функцией mail() прямо с веб-сервера. Такие письма мир встречает недоверием: у shared-хостинга репутация IP сомнительная, обратной DNS-записи и подписей нет — и уведомления о заявках тихо уезжают в спам. Это худший вид поломки: форма работает, посетитель уверен, что ему ответят, а менеджер даже не знает, что заявка была. Потерянные лиды, которых никто не считал.

Поэтому в чек-листе каждой миграции отдельным пунктом стоит почта:

• SMTP-плагин (WP Mail SMTP или FluentSMTP — оба справляются) переключает всю исходящую почту сайта на полноценный SMTP-аккаунт корпоративного ящика вида site@company.ru. Мы подключаем клиентов к нашему почтовому серверу — он живёт на нашей инфраструктуре, с нормальной репутацией и мониторингом доставляемости.
• SPF и DKIM для домена: в SPF-записи должен быть разрешён сервер, с которого реально уходит почта сайта, DKIM-подпись — включена. После любого переезда почты эти записи проверяем заново — они регулярно остаются указывающими на старый хостинг.
• Тест доставляемости: отправляем письма с каждой формы на ящики в разных сервисах (корпоративный, Яндекс, Mail.ru, Gmail) и смотрим, куда они попадают и что в заголовках. Сервисы вроде mail-tester дают удобную сводку по баллам.

Чем меряем успех миграции: контрольные точки через 2 и 6 недель

«Сайт переехал и открывается» — это не критерий успеха, а минимальное условие. Мы закрываем проект миграции по чек-листу с двумя контрольными точками. Через две недели: индексация новых URL идёт (смотрим Вебмастер и Search Console), 404 в логах сведены к фоновым, формы доставляют заявки в CRM, счётчики считают. Через шесть недель: позиции по контрольным запросам вернулись к исходным или выше, конверсия форм не упала, Core Web Vitals лучше, чем до переезда.

Цифры одного из недавних переносов — компания-поставщик инженерного оборудования, переезд с самописного движка 2012 года на WordPress с WooCommerce-каталогом:

Оговорюсь честно: рост заявок здесь — заслуга не «магии WordPress», а совокупности: быстрее сайт, актуальные цены из 1С, формы с UTM, которые наконец-то видно в CRM. Миграция — повод навести порядок во всём контуре, и именно в этом её главная ценность.

Смета и сроки типовой миграции

Вилка по сложности из нашей практики:

• Визитка или лендинг с конструктора (до 15 страниц, без каталога): 3–5 рабочих дней. Основное время съедает пересборка вёрстки и карта редиректов.
• Корпоративный сайт с Joomla/самописки (50–300 страниц, новости, формы): 1,5–2 недели, из них треть — миграция базы и проверки.
• Каталог с обменом 1С (до 3–5 тысяч SKU, CRM, оплата): 2–3 недели; тут уже половина бюджета — интеграции, а не перенос.

Из чего складывается цена: инвентаризация и карта редиректов (10–15% сметы), пересборка темы и шаблонов (30–40%), перенос контента и базы (20%), интеграции — CRM, 1С, SMTP, аналитика (20–30%), переключение и два контрольных замера (оставшееся). Дешевле всего миграция обходится тем, кто приходит до того, как старый сайт окончательно сломался: переезд в спокойном режиме по графику всегда дешевле переезда-пожара, когда конструктор заблокировал аккаунт или самописка легла вместе со старым PHP.

Если ваш сайт живёт на конструкторе, который стал тесен, или на движке, который все боятся трогать, — напишите, разберём вашу ситуацию: посчитаем объём, покажем карту рисков и честно скажем, что переносить, а что проще пересобрать. Telegram @ITfresh_Boss или +7 903 729-62-41.