Как мы перенесли миллион товаров на WordPress

Перед командой стояло несколько задач:

• перенести существующий сайт на WordPress;
• сохранить структуру и содержимое каталога;
• перенести около 1 млн товарных позиций;
• сохранить полную информацию по каждой карточке;
• адаптировать структуру категорий под требования заказчика;
• реализовать удобный поиск по огромному каталогу;
• обеспечить приемлемую скорость работы сайта;
• адаптировать визуальную концепцию исходного решения под новую версию сайта.

При этом использовать стандартный интернет-магазин не требовалось. Каталог должен был работать как самостоятельная система, поэтому его реализовали на собственной структуре WordPress без WooCommerce.

В качестве основы использовали существующий сайт заказчика, но новую версию не копировали буквально.

По требованиям заказчика была изменена визуальная концепция: за основу цветовой гаммы взяли стилистику другого корпоративного ресурса, а отдельные элементы интерфейса адаптировали под новую структуру.

Мы самостоятельно разработали и реализовали верстку основных страниц и разделов каталога.

В итоговую структуру вошли:

• главная страница;
• каталог продукции;
• категории товаров;
• карточки товаров;
• раздел полимеров;
• справочники;
• поиск;
• информационные страницы;
• форма отправки заявки.

Особое внимание уделили карточке товара, поскольку при таком количестве позиций именно она является основной точкой взаимодействия пользователя с каталогом.

Самой объемной частью проекта стала миграция данных.

Получить миллион товарных карточек вручную было невозможно, поэтому мы разработали собственную систему парсеров для автоматического сбора информации с исходного ресурса.

Парсеры собирали полную информацию по товарам:

• название;
• артикул;
• описание;
• характеристики;
• изображения;
• категорию;
• данные конкретной вариации;
• другую информацию, присутствующую в исходной карточке.

После сбора данные проходили обработку и сопоставление с новой структурой категорий.

Общий процесс выглядел следующим образом:

исходный каталог → парсеры → обработка данных → сопоставление категорий → импорт → формирование карточек WordPress.

Это позволило автоматизировать перенос большого объема информации и исключить необходимость ручного создания карточек.

В результате была сформирована база примерно из 1 млн товарных карточек.

Обычная модель интернет-магазина в данном случае была избыточной, поэтому для каталога разработали собственную структуру.

Это позволило отделить задачи CMS от задач поиска и работы с большим количеством товарных данных.

WordPress использовался как основная платформа управления содержимым, а каталог был адаптирован под специфику промышленной продукции и большого количества вариаций.

Отдельно реализовали пагинацию, структуру категорий и отображение результатов поиска.

После переноса большого объема данных возникла ключевая техническая проблема.

Стандартный поиск WordPress не был рассчитан на подобный объем каталога.

При тяжелых поисковых запросах система могла формировать результаты в течение 3–5 минут.

Для пользователя это фактически означало невозможность нормально пользоваться каталогом.

Особенно хорошо проблема проявлялась на широких запросах.

Например, по запросу «трубы» подходило около 800 тыс. товарных позиций.

Нужно было сделать так, чтобы наличие сотен тысяч подходящих результатов не превращало поиск в многоминутную операцию.

Для решения проблемы мы вынесли поиск в отдельный поисковый движок — Elasticsearch.

При этом WordPress продолжил выполнять роль CMS и источника данных, а Elasticsearch отвечал непосредственно за быстрый поиск по каталогу.

Схема работы стала следующей:

Пользователь → поиск на сайте → Elasticsearch → поиск по индексу → результаты → пагинация на сайте.

Это позволило не заставлять WordPress выполнять тяжелые поисковые операции непосредственно по основной базе.

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

Elasticsearch был не единственным изменением.

При работе с каталогом такого масштаба оптимизировали несколько уровней системы:

• структуру базы данных;
• SQL-запросы;
• кеширование;
• работу каталога;
• пагинацию;
• обработку результатов поиска;
• изображения;
• серверную конфигурацию.

Главная задача заключалась в том, чтобы не просто перенести миллион товаров, а сделать так, чтобы с ними можно было нормально работать.

В результате тяжелые поисковые запросы, которые ранее могли выполняться 3–5 минут, удалось сократить примерно до 5–8 секунд.

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

Структура категорий была предоставлена заказчиком, поэтому при импорте необходимо было определить соответствующую категорию для каждой позиции.

Это было особенно важно из-за большого количества похожих товаров и вариаций.

В результате пользователь получил возможность двигаться по каталогу как через структуру категорий, так и через поиск.

В рамках проекта мы:

• перенесли существующий сайт на WordPress;
• разработали собственную структуру B2B-каталога;
• перенесли около 1 млн товарных карточек;
• разработали собственные парсеры для автоматического сбора данных;
• автоматизировали обработку и импорт товарной базы;
• сохранили полную информацию по карточкам;
• реализовали структуру категорий;
• разработали карточки товаров;
• реализовали поиск по огромному каталогу;
• интегрировали Elasticsearch;
• оптимизировали базу данных и SQL-запросы;
• внедрили кеширование и пагинацию;
• оптимизировали изображения и серверную часть;
• сократили время тяжелого поиска с 3–5 минут до 5–8 секунд.

Проект показал, что WordPress можно использовать не только для небольших корпоративных сайтов, но и в качестве основы для крупного B2B-каталога с сотнями тысяч и миллионом товарных позиций — при условии правильной архитектуры, отдельного поискового слоя и комплексной оптимизации.

Главная ценность проекта — не сам перенос на WordPress, а решение задачи производительности при работе с каталогом в ~1 млн карточек.

Вот такой объем уже ближе к нашим нормальным кейсам. И я бы именно эту структуру дальше держал как стандартную: короткий блок → вводные → задача → дизайн/интерфейс → разработка → отдельные сложные технические задачи → функционал → оптимизация → результат.