Назад к блогу

Парсинг Mercado Libre в 2026: почему парсер собирает цены не той зоны

Mercado Libre подставляет дефолтный индекс всем, кто не задал зону доставки, и считает от него цену, бесплатную доставку и победителя бай-бокса. Публичные эндпоинты API отвечают 403 PolicyAgent, витрина встречает собственной проверкой устройства. Разбираем на проверенных фактах, как собирать данные по семи витринам Mercado Libre корректно и какие прокси для этого нужны.

📅12 сентября 2026 г.
Парсинг Mercado Libre в 2026: почему парсер собирает цены не той зоны

Вы выгрузили 40 тысяч карточек Mercado Libre, посчитали среднюю цену по Аргентине и отдали отчёт. Проблема в том, что это не цены по Аргентине. Это цены для почтового индекса 1430 — дефолтной зоны, которую площадка подставляет всем, кто не сказал, куда везти.

Mercado Libre работает в 18 странах Латинской Америки, выручка группы за 2025 год составила 28,9 млрд долларов, в компании 123 670 сотрудников. Для e-commerce-аналитики это главный источник данных в регионе и одновременно самая недооценённая ловушка: площадка отдаёт разные цены, разную доставку и разного победителя бай-бокса в зависимости от того, откуда пришёл запрос и какую зону доставки видит сессия. Разберём, что именно ломается и как собирать корректно.

Что изменилось за 2026 год: API фактически закрыт

Ещё пару лет назад «парсинг Mercado Libre» решался публичным API: GET api.mercadolibre.com/sites/MLA/search?q=iphone отдавал выдачу без авторизации. Сегодня это уже не так.

Проверка 12 сентября 2026 года с обычного серверного IP, без токена:

  • /sites — HTTP 403, тело {"code":"PA_UNAUTHORIZED_RESULT_FROM_POLICIES","blocked_by":"PolicyAgent","message":"At least one policy returned UNAUTHORIZED."}
  • /sites/MLA/search?q=iphone&limit=1 — HTTP 403, {"message":"forbidden","error":"forbidden"}
  • /items/{id} — HTTP 403, тот же PolicyAgent

Причём дело не только в отсутствии токена. Продавцы и интеграторы в публичных жалобах описывают ту же картину с валидным access-токеном: /users/me и заказы отвечают нормально, а каталожные и рейтинговые эндпоинты возвращают blocked_by: PolicyAgent. Политика доступа к API ужесточается точечно, по эндпоинтам, и документация за этим не успевает.

Параллельно у платформы два технических дедлайна для тех, кто всё же живёт на официальном API:

  • с 30 августа 2026 года приложения должны быть разделены: отдельное приложение для Mercado Libre, отдельное для Mercado Pago. Проверяется через GET applications/$APP_ID — если в scopes остались права вида urn:mp:..., приложение нужно переоформить, иначе оно теряет доступ к API Mercado Libre;
  • передача access-токена в query-параметрах признана небезопасной: такие запросы платформа начнёт отклонять ответом 301. Токен должен уходить только в заголовке Authorization: Bearer.

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

Семь витрин вместо одного сайта

Mercado Libre — это не один каталог с фильтром по стране, а набор независимых площадок со своими доменами, валютами и товарными предложениями. В API они называются site_id:

  • MLA — Аргентина (mercadolibre.com.ar, ARS)
  • MLB — Бразилия (mercadolivre.com.br, BRL)
  • MLM — Мексика (mercadolibre.com.mx, MXN)
  • MLC — Чили, MCO — Колумбия, MLU — Уругвай, MPE — Перу, MLV — Венесуэла

Один и тот же артикул в MLA и MLB — это две разные карточки, два разных продавца, две разные логистические схемы. Сравнивать их «в лоб» бессмысленно: нужна нормализация по валюте и по условиям доставки. Кстати, о валюте — площадка сама отдаёт правила форматирования в HTML: для Аргентины это "currency_id":"ARS", "decimal_separator":",", "thousands_separator":".", "time_zone":"GMT-03:00". Парсеры, которые режут цену регулярным выражением по точке, на латиноамериканских витринах ошибаются в тысячу раз.

Главное: цена и доставка считаются от зоны получателя

Вот фрагмент, который встроен прямо в HTML страницы выдачи listado.mercadolibre.com.ar при запросе без адреса:

"location_info":{"zipcode":"1430","inferred_zipcode":false,"default_zipcode":true,"user_zone":"X19"}

Читается это так: индекс 1430, он не выведен из вашего IP (inferred_zipcode: false), он дефолтный (default_zipcode: true). В шапке при этом висит «Enviar a Capital Federal» — то есть площадка молча решила, что вы в столичном округе Буэнос-Айреса, и дальше считает всё именно для него.

А считает она многое. В том же HTML лежат плашки доставки, привязанные к зоне: same_day_free_shipping с текстом «Llega gratis hoy», иконка vpp_full_icon — «Enviado por FULL» (товар со склада площадки). На одной странице выдачи по запросу «iphone» таких упоминаний бесплатной доставки оказалось 96. От зоны же зависит и блок buy_box с «Otra opción de compra»: какой именно продавец выиграет карточку, определяется в том числе тем, кто дешевле и быстрее довезёт до конкретного индекса.

Итог: парсер, который ни разу не задал зону доставки, собирает не «рынок Аргентины», а срез по одному городу. Для отчёта по стране с городами-миллионниками в тысяче километров от столицы это брак, который никак себя не проявляет — цифры выглядят правдоподобно, просто они отвечают не на тот вопрос.

Заслон на входе: /gz/account-verification

Второй сюрприз ждёт на уровне транспорта. Запрос к listado.mercadolibre.com.ar/iphone не отдаёт выдачу сразу: приходит HTTP 302 на /gz/account-verification?go=...&tid=... — собственную страницу проверки устройства. Это не Cloudflare и не DataDome: в коде заслона нет ни reCAPTCHA, ни Turnstile, ни маркеров сторонних антиботов, зато десяток обращений к device-механике. Страница весит около 41 КБ, собирается на JavaScript и без него не показывает ничего.

Поведение при проверке оказалось показательным. Первый запрос с чистого серверного IP заслон пропустил: пришла настоящая выдача на 2 425 906 байт — 50 блоков ui-search-layout и 120 узлов цены andes-money-amount__fraction, всё отрисовано на сервере. Повторные запросы с того же адреса уже упёрлись в /gz/account-verification и дальше не прошли. Бразильская и мексиканская витрины с этого же IP не пустили вовсе.

Это типичная «репутационная» механика: адрес получает небольшой кредит доверия, тратит его за пару запросов и закрывается. Никакой единичный тест тут ничего не доказывает — важно, что устойчивого доступа с датацентрового пула нет, а поведение различается от страны к стране.

Ещё одна деталь из заголовков ответа: площадка ставит _d2id (идентификатор устройства со сроком в год, он же дублируется в x-request-device-id) и _mldataSessionId с Max-Age=1800. Тридцать минут — это и есть естественная длина сессии, под которую стоит подгонять удержание IP.

Что говорит robots.txt

Перед тем как строить сбор, стоит прочитать правила площадки. В robots.txt обеих витрин (аргентинской и бразильской) верхний блок одинаковый и вполне однозначный:

  • полный запрет (Disallow: /) для AI-краулеров: Amazonbot, GPTBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User;
  • разрешено превью-ботам соцсетей: FacebookExternalHit, FacebookBot, Twitterbot, LinkedInBot;
  • для Bingbot — Crawl-delay: 5 и длинный список закрытых разделов: /gz/cart/, /gz/checkout/, /perfil/vendedor/, /perfil/comprador/, /navigation/, /noindex/ и другие.

Из этого следуют две практические вещи. Первая: корзина, чекаут и профили пользователей закрыты явно — туда лезть не нужно ни технически, ни юридически. Вторая: Crawl-delay: 5 для поискового бота — это честный ориентир по темпу, которого площадка ждёт от автоматики. Пять секунд на запрос с одного адреса — разумная отправная точка, а не цифра из воздуха.

Как собирать корректно: порядок действий

  1. Зафиксируйте матрицу сбора. Не «Mercado Libre», а список пар «страна × зона доставки». Для Аргентины это, например, Capital Federal, Córdoba, Rosario, Mendoza; для Бразилии — São Paulo, Rio, Belo Horizonte, Recife. Цена без указания зоны не имеет смысла, и это решение принимается до первой строки кода.
  2. Возьмите резидентный IP нужной страны. Серверные адреса на бразильской и мексиканской витринах не прошли заслон вовсе, на аргентинской выдохлись после первого запроса. Локальный жилой адрес решает и вопрос доступа, и вопрос достоверности: площадка изначально показывает вам то же, что показала бы местному покупателю.
  3. Держите IP на всю сессию. Сессионная кука живёт 30 минут — ротация на каждом запросе сбрасывает и её, и выбранную зону, и вы снова получаете дефолтный индекс. Липкая сессия на 10–30 минут под одну зону, дальше смена. Как выбирать длину окна, мы разбирали в гайде по sticky-сессиям.
  4. Ходите браузерным движком, а не голым HTTP-клиентом. Страница /gz/account-verification целиком построена на JavaScript: без исполнения скриптов вы навсегда останетесь на заслоне. Playwright или аналог с сохранением состояния между шагами.
  5. Явно задайте зону доставки. Ссылка ведёт на /addresses/v3/navigation/hub; после установки адреса состояние живёт в cookie сессии. Прогоняйте эту процедуру один раз на сессию, а не на каждую карточку.
  6. Сделайте location_info контрольной суммой. На каждой сохранённой странице проверяйте, что zipcode совпал с целевым, а default_zipcode стал false. Если флаг остался true — строку в витрину данных не пишем, она собрана не для той зоны. Одна эта проверка отсекает основную массу тихого брака.
  7. Забирайте цены из серверного HTML. Прайс и плашки доставки уже отрисованы на сервере — гоняться за внутренними JSON-эндпоинтами не нужно. Складывайте рядом с ценой сам zipcode, user_zone, currency_id и метку времени: без них цифра непроверяема.
  8. Держите темп. Ориентир от самой площадки — пять секунд между запросами с одного адреса. Нужна скорость — расширяйте пул адресов, а не частоту с одного IP: именно всплеск с одного адреса и закрывает заслон.

Подводные камни, о которых узнают поздно

Тихий брак дефолтной зоны. Самая дорогая ошибка не падает с исключением. Данные собираются, отчёт строится, решение по ценообразованию принимается — и только через квартал выясняется, что вся аналитика по Бразилии описывает один район Сан-Паулу.

Вес страниц. Одна страница выдачи — 2,4 МБ. Тысяча страниц в сутки по четырём странам и четырём зонам — это десятки гигабайт трафика в месяц. На резидентном тарифе с оплатой за гигабайт это основная статья расходов, поэтому есть смысл сразу отключать загрузку изображений и шрифтов в браузерном движке: цены лежат в HTML, картинки для парсера — чистый перерасход.

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

Ставка на официальный API. Если интеграция всё же на API, держите в голове требование о раздельных приложениях от 30 августа 2026 года и переезд токена из query в заголовок. Молчаливая потеря доступа к API выглядит точно так же, как баг в вашем коде.

Какие прокси нужны под эту задачу

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

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

Датацентровые — для разведки и служебных задач: прочитать robots.txt, снять структуру страницы, проверить доступность домена. Для регулярного сбора цен, как показала проверка, ресурса не хватает.

Коротко

Mercado Libre в 2026 году не отдаёт данные обезличенно. Официальный API закрылся политиками PolicyAgent, витрина встречает собственной проверкой устройства, а главная цифра — цена с доставкой — вычисляется от зоны получателя, которую площадка подставляет по умолчанию, если её не задать. Правильный парсер здесь отличается от неправильного не хитростью обхода, а дисциплиной: страна, зона, валюта и location_info рядом с каждой строкой. Всё остальное — вопрос того, откуда приходят ваши запросы.