Análisis de Mercado Libre en 2026: ¿por qué el parser recoge precios de la zona incorrecta?

Has descargado 40 mil tarjetas de Mercado Libre, calculado el precio promedio en Argentina y entregado el informe. El problema es que estos no son precios de Argentina. Son precios para el código postal 1430 — la zona predeterminada que la plataforma asigna a todos los que no han indicado a dónde enviar.

Mercado Libre opera en 18 países de América Latina, los ingresos del grupo para 2025 fueron de 28,9 mil millones de dólares, y la empresa cuenta con 123,670 empleados. Para el análisis de e-commerce, esta es la principal fuente de datos en la región y, al mismo tiempo, la trampa más subestimada: la plataforma ofrece diferentes precios, diferentes opciones de envío y diferentes ganadores del buy box dependiendo de dónde provenga la consulta y qué zona de entrega ve la sesión. Vamos a desglosar qué es lo que realmente falla y cómo recolectar correctamente.

Qué ha cambiado en 2026: API prácticamente cerrado

Hace un par de años, el "parseo de Mercado Libre" se resolvía a través de la API pública: GET api.mercadolibre.com/sites/MLA/search?q=iphone devolvía resultados sin necesidad de autorización. Hoy en día, ya no es así.

Verificación del 12 de septiembre de 2026 desde una IP de servidor normal, sin token:

• /sites — HTTP 403, cuerpo {"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, el mismo PolicyAgent

Y no se trata solo de la falta de un token. Vendedores e integradores en quejas públicas describen el mismo escenario con un token de acceso válido: /users/me y pedidos responden normalmente, mientras que los endpoints de catálogo y calificaciones devuelven blocked_by: PolicyAgent. La política de acceso a la API se está endureciendo de manera puntual, por endpoints, y la documentación no está al día.

Paralelamente, la plataforma tiene dos plazos técnicos para aquellos que aún viven en la API oficial:

• desde el 30 de agosto de 2026 las aplicaciones deben estar separadas: una aplicación para Mercado Libre, otra para Mercado Pago. Se verifica a través de GET applications/$APP_ID — si en los scopes quedan permisos del tipo urn:mp:..., la aplicación necesita ser reformulada, de lo contrario perderá acceso a la API de Mercado Libre;
• la transmisión del token de acceso en parámetros de consulta se considera insegura: tales solicitudes la plataforma comenzará a rechazarlas con una respuesta 301. El token debe enviarse solo en el encabezado Authorization: Bearer.

La conclusión práctica es simple: la API oficial en 2026 es un canal para el vendedor que trabaja con su cuenta, y no una herramienta de análisis de mercado. Si la tarea es monitorear competidores y precios por región, trabajas con la vitrina pública. Qué elegir para una tarea específica, lo discutimos en el material API oficial, conjunto de datos listo o tu propio parser.

Siete vitrinas en lugar de un solo sitio

Mercado Libre no es un solo catálogo con un filtro por país, sino un conjunto de plataformas independientes con sus propios dominios, monedas y ofertas de productos. En la API se les llama site_id:

• MLA — Argentina (mercadolibre.com.ar, ARS)
• MLB — Brasil (mercadolivre.com.br, BRL)
• MLM — México (mercadolibre.com.mx, MXN)
• MLC — Chile, MCO — Colombia, MLU — Uruguay, MPE — Perú, MLV — Venezuela

El mismo artículo en MLA y MLB son dos tarjetas diferentes, dos vendedores diferentes, dos esquemas logísticos diferentes. Compararlos "de frente" no tiene sentido: se necesita normalización por moneda y por condiciones de entrega. Hablando de moneda, la plataforma misma proporciona las reglas de formato en HTML: para Argentina es "currency_id":"ARS", "decimal_separator":",", "thousands_separator":".", "time_zone":"GMT-03:00". Los parsers que cortan el precio con expresiones regulares por punto, en las vitrinas latinoamericanas, se equivocan mil veces.

Lo principal: el precio y el envío se calculan desde la zona del destinatario

Aquí hay un fragmento que está integrado directamente en el HTML de la página de resultados listado.mercadolibre.com.ar al hacer una consulta sin dirección:

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

Esto se lee así: el código 1430, que no se ha derivado de tu IP (inferred_zipcode: false), es predeterminado (default_zipcode: true). En la parte superior dice "Enviar a Capital Federal" — es decir, la plataforma decidió en silencio que estás en el área metropolitana de Buenos Aires, y a partir de ahí calcula todo precisamente para esa zona.

Y calcula mucho. En el mismo HTML hay etiquetas de envío vinculadas a la zona: same_day_free_shipping con el texto "Llega gratis hoy", ícono vpp_full_icon — "Enviado por FULL" (producto desde el almacén de la plataforma). En una sola página de resultados para la consulta "iphone", se encontraron 96 menciones de envío gratuito. Además, el bloque buy_box con "Otra opción de compra": qué vendedor ganará la tarjeta se determina, entre otras cosas, por quién entrega más barato y rápido a un código postal específico.

Resultado: un parser que nunca ha establecido la zona de entrega no recolecta "el mercado de Argentina", sino un corte de una sola ciudad. Para un informe sobre el país con ciudades de un millón de habitantes a mil kilómetros de la capital, esto es un defecto que no se manifiesta de ninguna manera: los números parecen creíbles, simplemente no responden a la pregunta correcta.

Bloqueo en la entrada: /gz/account-verification

La segunda sorpresa espera a nivel de transporte. La consulta a listado.mercadolibre.com.ar/iphone no devuelve resultados de inmediato: llega un HTTP 302 a /gz/account-verification?go=...&tid=... — su propia página de verificación del dispositivo. No es Cloudflare ni DataDome: en el código del bloqueo no hay reCAPTCHA, ni Turnstile, ni marcadores de bots externos, pero sí decenas de llamadas a la mecánica del dispositivo. La página pesa alrededor de 41 KB, se construye en JavaScript y sin él no muestra nada.

El comportamiento durante la verificación resultó ser indicativo. La primera consulta desde una IP de servidor limpia pasó el bloqueo: llegó un resultado real de 2,425,906 bytes — 50 bloques ui-search-layout y 120 nodos de precio andes-money-amount__fraction, todo renderizado en el servidor. Las consultas repetidas desde la misma dirección ya se encontraron con /gz/account-verification y no avanzaron más. Las vitrinas brasileñas y mexicanas desde esta misma IP no permitieron el acceso en absoluto.

Esta es una mecánica típica de "reputación": la dirección recibe un pequeño crédito de confianza, lo gasta en un par de consultas y se cierra. Ninguna prueba única demuestra nada aquí — lo importante es que no hay acceso sostenible desde el pool de centros de datos, y el comportamiento varía de un país a otro.

Otro detalle de los encabezados de respuesta: la plataforma establece _d2id (identificador del dispositivo con un plazo de un año, que también se duplica en x-request-device-id) y _mldataSessionId con Max-Age=1800. Treinta minutos — esa es la longitud natural de la sesión, para la cual vale la pena ajustar la retención de IP.

Qué dice robots.txt

Antes de comenzar la recolección, es recomendable leer las reglas de la plataforma. En robots.txt de ambas vitrinas (argentina y brasileña), el bloque superior es idéntico y bastante claro:

• prohibición total (Disallow: /) para crawlers de IA: Amazonbot, GPTBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User;
• permitido para bots de vista previa de redes sociales: FacebookExternalHit, FacebookBot, Twitterbot, LinkedInBot;
• para Bingbot — Crawl-delay: 5 y una larga lista de secciones cerradas: /gz/cart/, /gz/checkout/, /perfil/vendedor/, /perfil/comprador/, /navigation/, /noindex/ y otras.

De esto se derivan dos cosas prácticas. Primero: el carrito, el checkout y los perfiles de usuarios están claramente cerrados — no se debe acceder a ellos ni técnica ni legalmente. Segundo: Crawl-delay: 5 para el bot de búsqueda es un indicador honesto del ritmo que la plataforma espera de la automatización. Cinco segundos por consulta desde una dirección es un punto de partida razonable, y no un número sacado de la nada.

Cómo recolectar correctamente: orden de acciones

1. Fija la matriz de recolección. No "Mercado Libre", sino una lista de pares "país × zona de entrega". Para Argentina, por ejemplo, Capital Federal, Córdoba, Rosario, Mendoza; para Brasil — São Paulo, Río, Belo Horizonte, Recife. El precio sin indicar la zona no tiene sentido, y esta decisión se toma antes de la primera línea de código.
2. Obtén una IP residencial del país necesario. Las direcciones de servidor en las vitrinas brasileñas y mexicanas no pasaron el bloqueo en absoluto, en la argentina se agotaron después de la primera consulta. Una dirección residencial local resuelve tanto la cuestión de acceso como la de veracidad: la plataforma te muestra inicialmente lo mismo que le mostraría a un comprador local.
3. Mantén la IP durante toda la sesión. La cookie de sesión vive 30 minutos — la rotación en cada consulta restablece tanto la cookie como la zona seleccionada, y vuelves a obtener el índice predeterminado. Una sesión pegajosa de 10 a 30 minutos para una zona, luego un cambio. Cómo elegir la longitud de la ventana, lo discutimos en la guía sobre sesiones pegajosas.
4. Utiliza un motor de navegador, no un cliente HTTP puro. La página /gz/account-verification está completamente construida en JavaScript: sin la ejecución de scripts, permanecerás para siempre en el bloqueo. Playwright o un análogo que mantenga el estado entre pasos.
5. Establece explícitamente la zona de entrega. El enlace lleva a /addresses/v3/navigation/hub; después de establecer la dirección, el estado vive en la cookie de la sesión. Realiza este procedimiento una vez por sesión, no por cada tarjeta.
6. Haz de location_info un checksum. En cada página guardada, verifica que zipcode coincida con el objetivo, y que default_zipcode se haya convertido en false. Si la bandera permanece true — no escribimos la fila en la vitrina de datos, se ha recolectado para la zona incorrecta. Solo esta verificación elimina la mayor parte del defecto silencioso.
7. Recoge precios del HTML del servidor. El precio y las etiquetas de envío ya están renderizadas en el servidor — no es necesario perseguir los endpoints JSON internos. Guarda junto al precio el mismo zipcode, user_zone, currency_id y la marca de tiempo: sin ellos, el número no es verificable.
8. Mantén el ritmo. La referencia de la propia plataforma es de cinco segundos entre consultas desde una dirección. Si necesitas velocidad, amplía el pool de direcciones, no la frecuencia desde una IP: precisamente el aumento de solicitudes desde una sola dirección cierra el bloqueo.

Trampas que se descubren tarde

Defecto silencioso de la zona predeterminada. El error más costoso no se manifiesta con una excepción. Los datos se recolectan, se construye el informe, se toma una decisión sobre la formación de precios — y solo después de un trimestre se descubre que toda la analítica de Brasil describe un solo barrio de São Paulo.

Peso de las páginas. Una página de resultados — 2,4 MB. Mil páginas al día en cuatro países y cuatro zonas — son decenas de gigabytes de tráfico al mes. Con una tarifa residencial que cobra por gigabyte, este es el principal artículo de gastos, por lo que tiene sentido desactivar la carga de imágenes y fuentes en el motor de navegador desde el principio: los precios están en HTML, las imágenes para el parser son un gasto innecesario.

Comparación de países sin normalización. ARS, BRL, MXN y diferentes separadores de miles. Normaliza a una sola moneda según el tipo de cambio en la fecha de recolección y guarda el precio original y la moneda por separado, de lo contrario, no podrás recalcularlo a posteriori.

Apuesta por la API oficial. Si la integración se realiza a través de la API, ten en cuenta el requisito de aplicaciones separadas desde el 30 de agosto de 2026 y el traslado del token de parámetros de consulta a encabezados. La pérdida silenciosa de acceso a la API se ve exactamente igual que un error en tu código.

Qué proxies se necesitan para esta tarea

Residenciales — una opción viable para recolectar precios y envíos. Necesitas una dirección del país cuya vitrina estás extrayendo, y preferiblemente de la región cuya zona de entrega estás verificando: así los datos se obtienen y permanecen verídicos. Proxies residenciales con retención de sesión cumplen ambos requisitos a la vez.

Móviles — donde el bloqueo es especialmente obstinado. América Latina es una región con una alta proporción de tráfico móvil, y una dirección de operador celular se ve para la plataforma como algo muy común. Son justificables en cortes estrechos pero críticos, no en descargas masivas.

Proxies de centros de datos — para exploración y tareas administrativas: leer robots.txt, extraer la estructura de la página, verificar la disponibilidad del dominio. Para la recolección regular de precios, como mostró la verificación, el recurso no es suficiente.

En resumen

Mercado Libre en 2026 no entrega datos de forma anónima. La API oficial se ha cerrado por políticas de PolicyAgent, la vitrina encuentra con su propia verificación de dispositivo, y el número principal — el precio con envío — se calcula desde la zona del destinatario, que la plataforma asigna por defecto si no se especifica. Un parser correcto aquí se diferencia de uno incorrecto no por astucia en el elusión, sino por disciplina: país, zona, moneda y location_info junto a cada fila. Todo lo demás es cuestión de dónde provienen tus consultas.