Почему это вообще кейс? Да потому что обычно при таких объемах (100к+ SKU) все бегут в обратную сторону. Типа, Вордпресс загнется, база лопнет, иди на Битрикс, плати бешеные деньги за лицензии, арендуй кластер серверов и чувствуй себя корпорацией. Но тут ситуация обратная. И, честно говоря, такие запросы к нам прилетают всё чаще. Бизнес устает платить. Просто устает от ежегодных продлений лицензий, от того, что каждый чих разработчика стоит как крыло от самолета, и от того, что админка грузится дольше, чем вы успеваете состариться.
В общем, к нам пришел клиент. Ниша — автозапчасти и расходники (или что-то очень близкое, с огромной номенклатурой). У них был монстр на Битриксе. Старый, тяжелый, как танкер, и такой же неповоротливый. И самое главное — дико дорогой в обслуживании.
Задача стояла простая и страшная одновременно: «Ребята, перенесите нам эти 128 тысяч позиций на WordPress. Но! Если упадет SEO — мы вас убьем. Если не будет работать синхронизация с 1С (а там выгрузки по гигабайту) — мы разоримся. И сделайте это вчера».
Ну, мы и взялись. Слабоумие и отвага, как говорится.
Почему вообще бегут с Битрикса? (Лирическое отступление, накипело)
Слушайте, я не хейтер. Битрикс — мощная система. Для каких-нибудь госкорпораций или маркетплейсов — ок, может быть. Но даже для крупного магазина… Зачем эти страдания?
Вот что сказал наш клиент, когда мы спросили «Почему?»:
- Деньги. «Я каждый год отстегиваю за продление лицензии сумму, на которую мог бы содержать небольшой штат». На объемах в 100к+ товаров лицензии стоят совсем других денег.
- Разработчики. Найти адекватного битриксоида на проект такого масштаба — это квест. Они либо заняты, либо просят рейты уровня Кремниевой долины. А WordPress-разработчиков — море.
- Скорость. «У меня карточка товара открывается 5-6 секунд. Сервер стоит как чугунный мост, а толку ноль».
WordPress в этом плане — глоток свободы. Он бесплатный. Он держит нагрузку, если руки растут из плеч и стоит нормальный кэш (Redis, привет).
Подготовка: «Не навреди» — главная заповедь сеошника
Перед тем как вообще что-то трогать, мы сели за SEO-анализ. Потому что перенос 128 000 страниц — это риск масштаба катастрофы. Это как пересадка мозга. Чуть-чуть пережал капилляр — и пациент (трафик) овощ.
Сайт клиента жил годами. Сотни тысяч проиндексированных страниц в Яндексе и Google. Если бы мы просто накатили новый сайт и забыли про старые URL, бизнес потерял бы колоссальные деньги.
Что мы сделали первым делом? Мы спарсили весь старый сайт. Вообще весь. Screaming Frog чуть не умер, оперативка на компе закончилась, пришлось парсить частями. Выгрузили всё. Получилась не «простыня», а «одеяло» на полмиллиона строк (с учетом картинок и пагинации). Excel, естественно, послал нас нафиг, работали через CSV и базы данных.
Главная проблема Битрикса — его URL. Видели когда-нибудь такое: /catalog/avtozapchasti/dvigatel/porshen-v-sbore-kamaz-740-1000128-0601217100/? И таких ссылок — сотни тысяч. В WordPress структура другая. /product/porshen-kamaz-740/. И вот тут начинается магия — 301 редиректы.
Мы составили карту редиректов. Файл весил столько, что открывать его в текстовом редакторе было больно. Там было прописано: «Если кто-то стучится по любому из 128 000 старых адресов, кидай его на новый». Это критически важно! Иначе — «404», вылет из индекса, банкротство.
Этап 1: Экспорт данных или «Как переварить слона»
Перенести 128 000 товаров вручную? Ага, лет через 50 закончим. Нужна жесткая автоматизация.
И тут начинается ад. Битрикс держит данные в своих инфоблоках так, словно это гостайна. Свойства размазаны по сотням таблиц. При таком объеме базы стандартные методы типа «экспорт в CSV» просто вешают сервер наглухо. 500 ошибку мы видели чаще, чем своих жен.
Пришлось писать свой скрипт прямого доступа к БД. Мы залезли в MySQL Битрикса. Написали сложнейшие SQL-запросы, чтобы вытянуть всё и не уронить прод.
- Название
- Артикул (SKU) — 128 тысяч уникальных кодов.
- Цена.
- Остаток.
- Категория (и полная вложенность: Главная -> Запчасти -> Двигатель -> Поршневая).
- Картинки (прямые ссылки).
- Характеристики (для фильтров, их там тысячи вариаций).
- SEO-данные (Title, Description).
Получилось несколько CSV-файлов по 500-800 Мб каждый. Мы их скармливали WP All Import в Вордпрессе, но не через браузер (он бы отвалился), а через консоль (WP-CLI). Это единственный способ переварить такой объем.
Сервер гудел как трансформаторная будка. 5 000… 20 000… 50 000… Процесс шел сутками. Мы разбивали импорт на пачки по 10 000 товаров, чтобы контролировать ошибки.
Факап №1: Картинки. Битрикс хранит картинки в /upload/. У каждого товара по 3-4 фотки. 128 000 * 4 = более полумиллиона изображений. 500 000 файлов! Вы представляете, сколько времени нужно, чтобы просто скачать полмиллиона файлов, нарезать из каждого миниатюры (3-4 размера) и разложить по папкам? Сервер молотил неделю. Без шуток. Неделю он просто обрабатывал картинки. Мы уже думали, что диск сгорит. В итоге папка uploads весит под 100 Гб. Пришлось подключать объектное хранилище (S3), чтобы не забивать сам сервер.
Этап 2: Битва за дизайн и функционал
Клиент сказал: «Хочу, чтобы новый сайт выглядел так же, но летал». На 128 000 товаров «летал» — это вызов. Мы взяли оптимизированную тему (типа WoodMart), но вырезали из неё всё лишнее. Каждый лишний скрипт на таком объеме — тормоза.
Главная боль была с фильтрами. Фильтровать 128 000 товаров по 50 характеристикам — это задача не для слабаков. Стандартные фильтры WP/WooCommerce тут умирают сразу. Вы нажимаете «Показать», и сайт задумывается на минуту. Мы поставили ElasticSearch. Без вариантов. Это отдельный поисковый движок. Мы настроили интеграцию. Теперь, когда юзер ищет «Поршень 740» или фильтрует по «Диаметр 120мм», запрос идет не в медленную базу MySQL, а в быстрый индекс Elastic. Результат? Мгновенная выдача. Доли секунды. На 128 тысячах товаров! Это была победа.
Этап 3: Великая и ужасная 1С (Big Data edition)
Вот мы и подошли к боссу уровня «Dark Souls». Интеграция с 1С на таких объемах. Файл выгрузки import.xml весит под полтора гигабайта. Если попытаться скормить его сайту целиком — сервер упадет в обморок.
Стандартные плагины захлебывались. Ошибка памяти, тайм-ауты. Пришлось допиливать логику. Настроили пошаговую выгрузку (partial upload). 1С отправляет только изменения (changes only). Поменялась цена у 100 товаров — прилетел маленький файлик. Но полная выгрузка всё равно нужна раз в какое-то время. Её разбили на пакеты. 1С кидает zip-архивы по частям. Сайт распаковывает, жует, говорит «давай дальше».
Проблема №1: Вариации. Сотни тысяч торговых предложений. В 1С бардак, который копился 10 лет. Дубли, разные написания характеристик. На сайте это вылезало в дубли товаров. Пришлось писать скрипты нормализации прямо на лету при импорте. «Красн.», «Красный», «Red» — всё склеивали в один атрибут.
Проблема №2: Склад и Цены. Обновление цен на 128 000 товаров. Даже прямой SQL-запрос выполняется долго. Оптимизировали базу данных. Добавили индексы. Теперь полная синхронизация цен занимает около 40 минут (раньше было часов 5).
Этап 4: SEO-оптимизация (Спасаем трафик)
128 000 страниц. Если Google решит переобходить их все разом — он положит нам сервер.
- Sitemap.xml. Один файл карты сайта не может содержать больше 50 000 ссылок. Пришлось генерировать индексный файл и разбивать карту на 3-4 части (sitemap-1.xml, sitemap-2.xml…).
- Скорость. Битрикс с такой базой еле шевелился (30 баллов PageSpeed). На WP с ElasticSearch, Redis (для кэширования запросов в БД) и оптимизацией картинок мы выжали 80-85 баллов. Каталог с сотней тысяч товаров листается как лента в Инстаграме.
- Те самые Редиректы. Загрузить 150 000 правил в .htaccess — плохая идея. Файл будет весить мегабайты, и Apache будет тупить при каждом запросе. Мы перенесли редиректы на уровень Nginx (сервера) или использовали специальные высокопроизводительные таблицы в БД. Протестировали. Работает. Ссылки из 2015 года ведут куда надо.
Запуск и результаты
День Х. Руки дрожат. Переключаем DNS. Нагрузка на базу подскакивает. Мониторинг краснеет. Тюним конфиги MySQL на лету. Добавляем памяти. Всё стабилизировалось. 1С начала плеваться ошибками, но мы быстро поправили таймауты.
Что в итоге? Прошло 3 месяца.
- Трафик. Из-за смены структуры была просадка, врать не буду. Гуглу нужно время переварить 128 000 новых URL. Но через 2 месяца трафик не просто вернулся, он пошел вверх. Сайт быстрый, поведенческие факторы улучшились. Люди просматривают по 10-15 страниц за сеанс, потому что не ждут загрузки.
- Деньги. Экономия на лицензиях Битрикса (редакция Энтерпрайз + продления) и серверах — колоссальная. WordPress жрет ресурсы, но меньше, чем Битрикс на таких объемах. Поддержка стала дешевле в разы. Найти разраба пофиксить верстку на WP — дело 5 минут.
- Масштабируемость. Все кричали, что WP не потянет 100к+ товаров. Потянул. И потянет еще столько же, если грамотно работать с базой и кэшем.
- Проблемы? База данных весит гигабайты. Бэкапы делаются долго. Нужен хороший сисадмин, чтобы следить за всем этим хозяйством (Redis, Elastic, Nginx). Но это всё равно проще, чем администрировать Битрикс-кластер.
Выводы (без воды)
Перенос гиганта на 128 000 товаров с Битрикса на WordPress — это возможно. Мы доказали это на практике. Это не «сайт за выходные». Это сложный инженерный проект. Нужна ElasticSearch, нужен Redis, нужен мощный VPS и прямые руки.
Но если ваш Битрикс-монстр сжирает бюджет и нервы, а развиваться не дает — миграция реальна. Главное — не экономьте на аналитике и тестах. При таких объемах ошибка стоит дорого. Мы в Spartan.by уже поседели на этих переносах, но зато теперь знаем, как работать с Big Data в WordPress.
Так что не слушайте тех, кто говорит «WP только для блогов». Это было 10 лет назад. Сейчас на нем можно строить маркетплейсы. Было бы желание (и бэкап!).
Всем аптайма и зеленого PageSpeed!
