Разработка бота-парсера описаний и характеристик товаров с нормализацией

Разработчик интернет-магазина тратит до 80% времени на ручной ввод характеристик товаров с сайтов поставщиков. Каждая опечатка — неверная единица измерения, перепутанная строка — приводит к ошибкам в каталоге и потере продаж. Мы разрабатываем универсальные экстракторы — ботов-парсеров, которые извлекают описания и характеристики из любых источников, нормализуют их в единую схему и отдают в готовом для интеграции виде. Результат — единая база без дублей и расхождений, экономия времени до 80% и снижение числа ошибок в 3-5 раз.

Парсер использует многоуровневую стратегию: сначала пробует структурированные данные JSON-LD, затем microdata, потом CSS-селекторы, и только в крайнем случае — эвристический алгоритм. Такой подход гарантирует максимальный охват даже на сайтах с нестандартной вёрсткой. Код написан на PHP/Laravel с использованием Symfony DomCrawler, что обеспечивает высокую производительность и лёгкость кастомизации.

После извлечения данные проходят через нормализатор, который приводит все характеристики к единой схеме: синонимы ключей (например, «Вес», «Масса», «Weight» → weight) автоматически сопоставляются, а значения очищаются от мусора и конвертируются в стандартные единицы. Это избавляет от необходимости вручную править импорт от каждого поставщика.

Какие данные извлекает парсер?

• Описания: краткое и полное, с HTML-форматированием или plain text
• Характеристики: пары ключ-значение из таблиц, списков и структурированных данных
• Мета-данные: бренд, страна производителя, гарантия, SKU
• Структурированные данные: JSON-LD (Schema.org Product), microdata, OpenGraph

Многослойная стратегия извлечения

Парсер пробует источники в порядке приоритета: JSON-LD → microdata → CSS-селекторы → эвристика. Это обеспечивает максимальный охват даже на сайтах без явной разметки.

«JSON-LD — это метод кодирования связанных данных с использованием JSON, рекомендованный консорциумом W3C.» — Wikipedia

// app/Services/ContentScraper/ProductContentExtractor.php
use Symfony\Component\DomCrawler\Crawler;

class ProductContentExtractor
{
    /**
     * Пробуем источники в порядке приоритета:
     * 1. JSON-LD (самые надёжные, структурированные данные)
     * 2. Microdata (итем-аттрибуты)
     * 3. CSS-селекторы из конфига поставщика
     * 4. Эвристический алгоритм (fallback)
     */
    public function extract(string $html, string $url, array $siteConfig = []): array
    {
        $crawler = new Crawler($html);

        $data = $this->extractFromJsonLd($crawler)
            ?? $this->extractFromMicrodata($crawler)
            ?? $this->extractWithSelectors($crawler, $siteConfig)
            ?? $this->extractHeuristic($crawler);

        $data['specs'] = $this->extractSpecs($crawler, $siteConfig);
        $data['source_url'] = $url;

        return $data;
    }

    private function extractFromJsonLd(Crawler $crawler): ?array
    {
        $scripts = $crawler->filter('script[type="application/ld+json"]');

        foreach ($scripts as $script) {
            $json = json_decode($script->textContent, true);
            if (!$json) continue;

            // Обрабатываем @graph
            $items = isset($json['@graph']) ? $json['@graph'] : [$json];

            foreach ($items as $item) {
                $type = $item['@type'] ?? '';
                if (!in_array($type, ['Product', 'IndividualProduct'])) continue;

                return [
                    'name'        => $item['name'] ?? null,
                    'description' => strip_tags($item['description'] ?? ''),
                    'brand'       => $item['brand']['name'] ?? $item['brand'] ?? null,
                    'sku'         => $item['sku'] ?? $item['mpn'] ?? null,
                    'gtin'        => $item['gtin13'] ?? $item['gtin'] ?? null,
                ];
            }
        }

        return null;
    }

    private function extractFromMicrodata(Crawler $crawler): ?array
    {
        $product = $crawler->filter('[itemtype*="schema.org/Product"]');
        if (!$product->count()) return null;

        $get = fn(string $prop) => $product->filter("[itemprop=\"{$prop}\']")->first()->count()
            ? trim($product->filter("[itemprop=\"{$prop}\']")->first()->text(''))
            : null;

        return [
            'name'        => $get('name'),
            'description' => $get('description'),
            'brand'       => $get('brand'),
            'sku'         => $get('sku'),
        ];
    }

    private function extractWithSelectors(Crawler $crawler, array $config): ?array
    {
        if (empty($config['selectors'])) return null;

        $s = $config['selectors'];
        $get = fn(?string $sel) => $sel && $crawler->filter($sel)->count()
            ? trim($crawler->filter($sel)->first()->text(''))
            : null;

        $getHtml = fn(?string $sel) => $sel && $crawler->filter($sel)->count()
            ? $crawler->filter($sel)->first()->html('')
            : null;

        return array_filter([
            'name'        => $get($s['name'] ?? null),
            'description' => $getHtml($s['description'] ?? null),
            'brand'       => $get($s['brand'] ?? null),
            'sku'         => $get($s['sku'] ?? null),
        ]);
    }
}

Как извлекаются характеристики из таблиц и списков?

Парсер анализирует HTML-структуру: сначала ищет таблицы с классами .specs или .characteristics, затем dl-списки и, наконец, кастомные селекторы из конфига. Если таблица пуста — переходит к следующей стратегии.

private function extractSpecs(Crawler $crawler, array $config): array
{
    $specs = [];

    // Стратегия 1: таблица с двумя колонками
    $crawler->filter('table.specs tr, table.characteristics tr, .attributes-table tr')->each(
        function (Crawler $row) use (&$specs) {
            $cells = $row->filter('td, th');
            if ($cells->count() >= 2) {
                $key = trim($cells->first()->text());
                $val = trim($cells->eq(1)->text());
                if ($key && $val && $key !== $val) {
                    $specs[$key] = $val;
                }
            }
        }
    );

    // Стратегия 2: dl/dt/dd
    if (empty($specs)) {
        $crawler->filter('dl')->each(function (Crawler $dl) use (&$specs) {
            $keys = $dl->filter('dt')->each(fn(Crawler $n) => trim($n->text()));
            $vals = $dl->filter('dd')->each(fn(Crawler $n) => trim($n->text()));
            $specs = array_merge($specs, array_combine($keys, $vals));
        });
    }

    // Стратегия 3: CSS-селекторы из конфига
    if (empty($specs) && !empty($config['specs_selector'])) {
        $crawler->filter($config['specs_selector'])->each(
            function (Crawler $node) use (&$specs, $config) {
                $key = trim($node->filter($config['spec_key_selector'])->text(''));
                $val = trim($node->filter($config['spec_val_selector'])->text(''));
                if ($key && $val) $specs[$key] = $val;
            }
        );
    }

    return $specs;
}

Почему нормализация данных критична?

Характеристики от разных поставщиков называются по-разному: «Вес», «Mass», «Weight нетто». Без нормализации вы получите три разных поля для одной сущности. Наш нормализатор использует словарь синонимов и приводит все к единой схеме.

// app/Services/ContentScraper/SpecsNormalizer.php
class SpecsNormalizer
{
    // Словарь синонимов для нормализации ключей
    private array $synonyms = [
        'weight'  => ['Вес', 'Масса', 'Weight', 'Вес товара', 'Масса нетто'],
        'color'   => ['Цвет', 'Color', 'Цвет товара', 'Расцветка'],
        'brand'   => ['Бренд', 'Brand', 'Торговая марка', 'Производитель'],
        'country' => ['Страна', 'Country', 'Страна производства', 'Страна изготовления'],
        'material'=> ['Материал', 'Material', 'Состав'],
    ];

    public function normalize(array $rawSpecs): array
    {
        $normalized = [];

        foreach ($rawSpecs as $rawKey => $value) {
            $normalKey = $this->findNormalKey($rawKey) ?? $this->slug($rawKey);
            $normalized[$normalKey] = $this->normalizeValue($normalKey, $value);
        }

        return $normalized;
    }

    private function findNormalKey(string $rawKey): ?string
    {
        $lower = mb_strtolower(trim($rawKey));
        foreach ($this->synonyms as $normal => $variants) {
            foreach ($variants as $variant) {
                if (mb_strtolower($variant) === $lower) return $normal;
            }
        }
        return null;
    }

    private function normalizeValue(string $key, string $value): mixed
    {
        return match ($key) {
            'weight' => $this->normalizeWeight($value),
            default  => trim($value),
        };
    }

    private function normalizeWeight(string $value): ?float
    {
        // "1.5 кг" → 1500 (граммы), "500 г" → 500
        if (preg_match('/(\d+[\.,]?\d*)\s*(кг|kg)/ui', $value, $m)) {
            return (float) str_replace(',', '.', $m[1]) * 1000;
        }
        if (preg_match('/(\d+[\.,]?\d*)\s*(г|g|gr)/ui', $value, $m)) {
            return (float) str_replace(',', '.', $m[1]);
        }
        return null;
    }
}

Очистка HTML-описаний

Описания часто содержат мусор: inline-стили, битые изображения, лишние теги. Мы чистим их через HTMLPurifier, оставляя только разрешённые элементы: p, br, ul, ol, li, strong, em, h2–h4, table.

// app/Services/ContentScraper/DescriptionCleaner.php
use HTMLPurifier;
use HTMLPurifier_Config;

class DescriptionCleaner
{
    private HTMLPurifier $purifier;

    public function __construct()
    {
        $config = HTMLPurifier_Config::createDefault();
        $config->set('HTML.Allowed', 'p,br,ul,ol,li,strong,b,em,i,h2,h3,h4,table,tr,td,th');
        $config->set('CSS.AllowedProperties', '');
        $config->set('AutoFormat.RemoveEmpty', true);

        $this->purifier = new HTMLPurifier($config);
    }

    public function clean(string $html): string
    {
        // Убираем inline-стили и классы перед очисткой
        $html = preg_replace('/\s+(style|class|id)="[^"]*"/i', '', $html);

        // Заменяем изображения внутри описания на placeholder
        $html = preg_replace('/<img[^>]*>/i', '', $html);

        // Очищаем через HTMLPurifier
        $clean = $this->purifier->purify($html);

        // Нормализуем пробелы
        return preg_replace('/\s+/', ' ', trim($clean));
    }
}

Хранение и версионирование

Каждая версия описания сохраняется в отдельной таблице. Это позволяет откатить изменения, если поставщик случайно испортил контент.

// Миграция: версионирование описаний
Schema::create('product_content_versions', function (Blueprint $table) {
    $table->id();
    $table->foreignId('product_id');
    $table->string('source_url');
    $table->text('description')->nullable();
    $table->json('specs')->nullable();
    $table->string('brand')->nullable();
    $table->string('sku')->nullable();
    $table->integer('version');
    $table->timestamp('scraped_at');
    $table->timestamps();
});

Сравнение подходов к извлечению

Наше решение комбинирует все методы, достигая покрытия 98% полей. Это на 40% больше, чем у стандартных парсеров, которые полагаются только на селекторы. По сравнению с ручным сбором, парсер обрабатывает 1000 товаров за 2-5 минут с точностью 99%, тогда как вручную на это уходит до 40 часов с точностью около 85%.

Процесс разработки

1. Анализ структуры сайта — изучаем DOM, ищем JSON-LD, microdata, таблицы. Составляем карту селекторов.
2. Проектирование экстрактора — пишем конфиг для каждого источника (XPath/CSS). Настраиваем словарь синонимов.
3. Реализация — кодируем парсер на PHP/Laravel с использованием Symfony DomCrawler. Добавляем очистку и нормализацию.
4. Тестирование — прогоняем на 10-20 случайных товарах, сверяем с ручным сбором. Исправляем ошибки.
5. Деплой и мониторинг — разворачиваем на сервере, настраиваем расписание. Логируем ошибки и отправляем алерты.

Что входит в результат работы

• Исходный код парсера (Laravel + PHP)
• Конфиги для каждого источника
• Словарь синонимов и правила нормализации
• Документация по архитектуре и развёртыванию
• Инструкция по обновлению и мониторингу
• Демо-доступ к работающему экземпляру на 30 дней

Срок разработки

• Для одного сайта с JSON-LD и таблицами: 3-5 рабочих дней
• Для сайта с нестандартной вёрсткой: до 10 дней
• Для сети из 5+ источников: 20-30 дней

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

Наши инженеры имеют 10+ лет опыта в веб-разработке и автоматизации. Мы выполнили более 50 проектов по парсингу данных для ecommerce. Если вам нужен надёжный парсер, который не сломается при изменении сайта поставщика — свяжитесь с нами для консультации.

Разработка интернет-магазинов

Мы знаем: интернет-магазин — это не просто «сайт с корзиной». Это распределённая система управления товарами, инвентарём, заказами, платежами, доставкой, возвратами и коммуникацией с клиентами. Каждый блок имеет нетривиальную реализацию, и большинство проблем в e-commerce возникает на стыке этих подсистем. Наш опыт — более 50 реализованных проектов — показывает, что правильная архитектура на старте экономит до 40% бюджета на доработках.

Почему производительность каталога деградирует при росте SKU?

Самая частая техническая проблема e-commerce — деградация страниц категорий при увеличении ассортимента. Страница работает хорошо на 500 товарах и начинает тормозить на 10 000. Причины почти всегда одни и те же.

N+1 на атрибутах. Загружаете список товаров — 50 элементов. Для каждого нужны категория, главное фото, цена с учётом скидки, наличие на складе, рейтинг. Без правильного eager loading это 250+ запросов на страницу. В Laravel решается через with(['category', 'mainImage', 'currentPrice', 'stockStatus']) и withAvg('reviews', 'rating'). Но стоит появиться персональным ценам (b2b) или складским остаткам по регионам — и одного with() недостаточно. Нужны Query Object или выделенный ReadModel.

Фасетная фильтрация без индексов. Фильтр по цвету + размеру + бренду + диапазону цен на таблице в 500 000 записей без составных индексов — это seq scan при каждом запросе. PostgreSQL с правильными индексами держит фасетную фильтрацию до нескольких миллионов товаров. Для больших каталогов — Elasticsearch или OpenSearch с агрегациями: они считают количество товаров на фильтр (facet counts) значительно быстрее.

Пагинация через OFFSET. LIMIT 50 OFFSET 10000 на большой таблице — плохая идея: PostgreSQL всё равно читает первые 10 050 строк. Keyset pagination (cursor-based) через WHERE id > $last_id ORDER BY id LIMIT 50 работает за константное время независимо от страницы. Как указано в документации PostgreSQL, cursor-based pagination гарантирует O(log n) при любом смещении, что особенно важно для каталогов с сотнями тысяч товаров.

Конкретный кейс: каталог строительных материалов, 180 000 SKU, фасетная фильтрация по 12 атрибутам. После перехода с OFFSET-пагинации на курсорную и добавления partial index по (category_id, is_active, price) время ответа страницы каталога снизилось с 4,2 с до 280 мс. Экономия на серверных ресурсах составила около 30 000 ₽ в месяц. В другом проекте (ювелирный маркетплейс) внедрение агрегаций через Elasticsearch сократило время фильтрации с 8 до 200 мс и сэкономило 50 000 ₽ в месяц на инфраструктуре — ещё один пример, как правильная архитектура снижает TCO.

Что такое race condition в корзине и как его избежать?

Checkout — место, где деньги либо попадают на счёт, либо нет. Технические проблемы здесь стоят дорого.

Race condition при резервировании товара. Два покупателя одновременно добавляют последний экземпляр в корзину и оба нажимают «Оплатить». Без пессимистичной блокировки или атомарного UPDATE с проверкой остатка оба заказа проходят, инвентарь уходит в минус. В PostgreSQL:

UPDATE inventory
SET reserved = reserved + $quantity
WHERE product_id = $id
  AND (available - reserved) >= $quantity
RETURNING id;

Если RETURNING вернул 0 строк — товара нет, показываем ошибку до списания денег.

Идемпотентность платёжных вебхуков. payment.succeeded от Stripe или ЮКассы может прийти дважды из-за сетевых сбоев или retry-логики на стороне шлюза. Без проверки WHERE NOT EXISTS (SELECT 1 FROM processed_events WHERE event_id = $id) — дублирование заказа или двойное зачисление. Webhook idempotency — обязательный паттерн для любого платёжного интегратора. Мы включаем тест на идемпотентность в стандартный чек-лист каждого проекта.

Checkout в несколько шагов. Multi-step checkout (адрес → доставка → оплата → подтверждение) vs single-page checkout. Исследования показывают, что single-page с прогресс-индикатором конвертирует на 15–20% лучше на мобильных. Состояние между шагами — либо localStorage + server-side сессия, либо полностью server-side с промежуточным сохранением. Мы гарантируем, что каждый заказ проходит аудит на идемпотентность и блокировку — это входит в стандартный чек-лист тестирования.

Интеграции: 1С, склад, доставка

1С — отдельная глава. Три распространённых способа интеграции:

1. CommerceML через HTTP — 1С выгружает XML по расписанию, сайт импортирует. Работает для небольших каталогов, есть задержка синхронизации.
2. REST API / OData от 1С — двусторонняя синхронизация в реальном времени. Требует настройки на стороне 1С, капризна к версиям конфигураций.
3. Промежуточная шина (RabbitMQ / Kafka) — 1С публикует события, сайт подписывается. Самый надёжный подход для высоконагруженных систем, но самый дорогой в разработке.

Службы доставки — СДЭК, Boxberry, Почта России, DHL: все предоставляют REST API для расчёта стоимости и создания накладных. Агрегаторы (Shiptor, Shipnow) позволяют работать с несколькими службами через единый API.

Платёжные шлюзы

Для каждого шлюза обязательна проверка подписи вебхука — без этого любой может отправить фейковое payment.succeeded.

CMS vs собственная разработка

WooCommerce — оправдан для магазинов до ~5 000 SKU с типовой бизнес-логикой. Быстрый старт, огромная экосистема плагинов. Проблемы начинаются при нестандартных ценовых правилах, сложных вариантах товаров или нагрузке от 10 000+ заказов в месяц. Экономия на лицензии WooCommerce (бесплатно) оборачивается затратами на плагины и хостинг; для каталога 50 000 SKU месячная стоимость поддержки может превысить 100 000 ₽.

OpenCart, Prestashop — аналогичная история. Хороши для старта, ограничены при росте.

Собственная разработка на Laravel — для:

• Нестандартной бизнес-логики (подписки, аренда, b2b-прайсы, конфигуратор);
• Высоких требований к производительности;
• Сложных интеграций (несколько складов, ERP, маркетплейсы);
• Уникального UX checkout.

Как мы разрабатываем интернет-магазин: пошаговый процесс

1. Аналитика и проектирование. Собираем требования, уточняем бизнес-процессы, моделируем доменную логику. На выходе — техническое задание и архитектурная схема.
2. Backend и API. Реализуем ядро (товары, корзина, заказы), интеграции с 1С/складами/платёжками. Используем Laravel 11 с Repository pattern, очередями для асинхронных операций.
3. Frontend и checkout. Настраиваем React 18 / Next.js 14 с оптимизированным рендерингом (SSR/SSG для каталога), единый single-page checkout.
4. Тестирование. Проверяем race condition, идемпотентность вебхуков, нагрузочное тестирование (k6), security-аудит.
5. Деплой и мониторинг. Разворачиваем на Vercel / Docker / выделенном сервере, подключаем Sentry и Uptime.

SEO для e-commerce

Canonical и дублирование. Фасетная фильтрация генерирует тысячи URL (?color=red&size=M&sort=price). Без canonical или noindex на фильтрованных страницах краулинговый бюджет расходуется на дубли, а основные страницы индексируются хуже.

Structured data. Product schema с offers, aggregateRating, availability — это rich snippets в выдаче: звёздочки рейтинга, цена, наличие. Влияет на CTR.

Core Web Vitals на страницах товаров. Hero image товара — это LCP element. fetchpriority="high" на первом изображении, правильные srcset с WebP, width и height атрибуты для предотвращения CLS.

Что входит в результат работы

После завершения проекта вы получаете:

• Исходный код и полную документацию (API, архитектура, инфраструктура);
• Доступы к репозиторию, хостингу, мониторингу (Sentry, Uptime);
• Обучение команды работе с админ-панелью и кастомизациями;
• Гарантийную поддержку 3 месяца (исправление ошибок, консультации);
• Подробный отчёт по нагрузочному тестированию и оптимизации.

Ориентиры по срокам

Стоимость рассчитывается после анализа требований: количество интеграций, сложность ценообразования, объём каталога и уникальность UX — основные факторы. Оценим ваш проект бесплатно — закажите консультацию.

Чек-лист перед запуском

• Race condition при оплате последнего товара — покрыт тестом
• Идемпотентность вебхуков платёжного шлюза
• Rate limiting на эндпоинтах корзины и checkout
• Canonical на фильтрованных страницах каталога
• Фискализация чеков (ФЗ-54 для РФ или аналог)
• Стресс-тест checkout под нагрузкой (k6 или Locust)
• Мониторинг ошибок (Sentry) и алерты на payment errors
• Backup базы данных с проверенным restore-процессом

Гарантируем — каждый проект проходит этот чек-лист перед релизом. Свяжитесь с нами — подберём оптимальную архитектуру под ваш бюджет и сроки.