Парсинг Wildberries: как собирать данные без банов

17 августа 2026 · 8 минут чтения

Сбор данных с Wildberries упирается не в код — написать запрос к карточке товара умеет каждый. Упирается он в масштаб: на сотой странице приходит 429, на тысячной адрес перестают обслуживать вовсе. Разбираем, где проходят лимиты площадки, сколько адресов нужно под вашу задачу и как построить сборщик, который не падает на ровном месте.

Что и откуда собирают

Прежде чем писать парсер, стоит определиться с источником — их три, и они принципиально разные:

Почему прилетают блокировки

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

• Код 429 — превышен лимит, притормозите. Первый и главный сигнал.
• Пустые ответы или таймауты — адрес попал под временное ограничение.
• Долгая блокировка адреса — если после 429 нагрузка не снизилась.

Важная деталь: считают именно связку «адрес + частота». Поэтому проблема решается не хитрыми заголовками, а распределением запросов по пулу адресов и разумными паузами.

Сколько нужно прокси: считаем на практике

Отталкивайтесь от простого ориентира: один IP уверенно держит 1–2 запроса в секунду при небольших случайных паузах. Дальше арифметика:

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

Какие прокси брать

Для сбора публичных данных высокий уровень доверия не нужен — карточку товара отдают любому посетителю. Значение имеют скорость, стабильность и цена за адрес, а это сильная сторона серверных IPv4-прокси из дата-центров: гигабитный канал, пинг в единицы миллисекунд и стоимость, при которой пул из 30 адресов не разоряет бюджет.

Мобильные прокси для этой задачи избыточны: их преимущество — доверие антифрода при работе с аккаунтами, а платите вы за порт, а не за адрес. Держать на них массовый парсинг дорого и бессмысленно.

Рабочая схема сборщика

Минимальный набор правил, который отличает работающий парсер от падающего:

1. Ротация по кругу. Каждый следующий запрос уходит через следующий адрес пула — нагрузка размазывается равномерно.
2. Случайные паузы. Строго равные интервалы выглядят машинно; 0,3–1,2 секунды со случайным разбросом решают проблему.
3. Экспоненциальная задержка при 429. Пауза удваивается с каждой ошибкой, а адрес меняется.
4. Временное исключение адреса. Получил 429 дважды подряд — убираем из ротации на несколько минут.
5. Возобновляемость. Сохраняйте прогресс: обрыв на 80 000-й карточке не должен означать полный перезапуск.

Пример на Python

import random, time, itertools
import requests

PROXIES = [
    "http://user:pass@195.24.10.15:8000",
    "http://user:pass@91.108.44.62:8000",
    "http://user:pass@45.132.19.7:8000",
]
pool = itertools.cycle(PROXIES)
cooldown = {}  # адрес -> время, до которого он отдыхает

def next_proxy():
    for _ in range(len(PROXIES)):
        p = next(pool)
        if cooldown.get(p, 0) < time.time():
            return p
    time.sleep(30)  # весь пул на отдыхе — ждём
    return next(pool)

def fetch(url, attempts=5):
    delay = 1.0
    for attempt in range(attempts):
        proxy = next_proxy()
        try:
            r = requests.get(
                url,
                proxies={"http": proxy, "https": proxy},
                timeout=15,
                headers={"Accept": "application/json"},
            )
            if r.status_code == 200:
                time.sleep(random.uniform(0.3, 1.2))  # живая пауза
                return r.json()
            if r.status_code == 429:
                cooldown[proxy] = time.time() + 180  # адрес на паузу
                time.sleep(delay)
                delay *= 2  # экспоненциальная задержка
                continue
        except requests.RequestException:
            cooldown[proxy] = time.time() + 60
            time.sleep(delay)
            delay *= 2
    return None

Дальше остаётся обвязка: очередь артикулов, запись результата в базу или CSV и сохранение позиции для возобновления. Для больших объёмов имеет смысл перейти на aiohttp с ограничителем параллельности — логика ротации и пауз остаётся той же.

Региональность: почему цифры не сходятся

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

Для сборщика это означает две вещи. Во-первых, регион нужно фиксировать явно — иначе площадка подставит его сама, и вы будете сравнивать несопоставимые цифры. Во-вторых, если анализ ведётся по нескольким регионам, каждый из них — это отдельный проход по всему списку артикулов, то есть объём запросов умножается на количество регионов. Пул адресов планируйте с учётом этого множителя: пять регионов по 20 000 карточек — это уже 100 000 запросов, а не 20 000.

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

Проверка пула перед запуском

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

Типичные ошибки

• Пул из одной подсети. Самая частая и самая дорогая ошибка: платите за 30 адресов, а ведёте себя как один.
• Нулевые паузы. «Соберём быстрее» превращается в блокировку всего пула за пару минут.
• Игнорирование 429. Повтор того же запроса через тот же адрес только продлевает ограничение.
• Один поток на один адрес. Параллельные запросы через один IP считаются как один источник нагрузки — эффект тот же, что и без пауз.
• Отсутствие проверки адресов перед стартом. Один нерабочий IP в пуле создаёт пробелы в данных, которые вы заметите слишком поздно.

Частые вопросы

Законно ли парсить Wildberries?

Сбор общедоступных данных законом не запрещён. Ограничения — пользовательское соглашение площадки в части автоматизированного доступа и недопустимость чрезмерной нагрузки. По собственным товарам используйте официальный API продавца.

Сколько прокси нужно для парсинга?

Считайте от одного IP на 1–2 запроса в секунду. Для 100 000 карточек за ночь понадобится примерно 20–30 адресов из разных подсетей.

Какие прокси подходят для маркетплейсов?

Серверные IPv4: высокая скорость, низкий пинг и низкая цена за адрес. Высокий trust score для публичных данных не требуется.

Что делать при 429?

Увеличивать паузу вдвое с каждой ошибкой, менять адрес и отправлять текущий IP на несколько минут в отдых.

Подойдут ли мобильные прокси?

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