Torna al blog

Parsing di Mercado Libre nel 2026: perché il parser raccoglie i prezzi della zona sbagliata

Mercado Libre imposta un indice predefinito per tutti coloro che non hanno specificato un'area di consegna e calcola da esso il prezzo, la consegna gratuita e il vincitore del buy box. Gli endpoint pubblici dell'API rispondono con 403 PolicyAgent, la vetrina incontra un controllo del dispositivo. Analizziamo fatti verificati su come raccogliere dati da sette vetrine di Mercado Libre in modo corretto e quali proxy sono necessari per questo.

📅12 settembre 2026
Parsing di Mercado Libre nel 2026: perché il parser raccoglie i prezzi della zona sbagliata

Hai estratto 40.000 schede di Mercado Libre, hai calcolato il prezzo medio in Argentina e hai consegnato il rapporto. Il problema è che questi non sono i prezzi per l'Argentina. Questi sono i prezzi per il codice postale 1430 — la zona predefinita che la piattaforma assegna a chi non specifica dove spedire.

Mercado Libre opera in 18 paesi dell'America Latina, il fatturato del gruppo per il 2025 è stato di 28,9 miliardi di dollari, l'azienda conta 123.670 dipendenti. Per l'analisi e-commerce, questa è la principale fonte di dati nella regione e allo stesso tempo la trappola più sottovalutata: la piattaforma fornisce prezzi diversi, diverse modalità di spedizione e diversi vincitori del buy box a seconda di dove proviene la richiesta e quale zona di spedizione vede la sessione. Vediamo cosa si rompe esattamente e come raccogliere correttamente.

Cosa è cambiato nel 2026: l'API è di fatto chiusa

Ancora un paio di anni fa, il "parsing di Mercado Libre" si risolveva tramite API pubbliche: GET api.mercadolibre.com/sites/MLA/search?q=iphone restituiva i risultati senza autorizzazione. Oggi non è più così.

Verifica del 12 settembre 2026 da un normale IP server, senza token:

  • /sites — HTTP 403, corpo {"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, stesso PolicyAgent

Il problema non è solo l'assenza di un token. I venditori e gli integratori nelle lamentele pubbliche descrivono la stessa situazione con un access-token valido: /users/me e gli ordini rispondono normalmente, mentre gli endpoint catalogo e rating restituiscono blocked_by: PolicyAgent. La politica di accesso all'API si sta inasprendo in modo mirato, per endpoint, e la documentazione non riesce a tenere il passo.

Parallelamente, la piattaforma ha due scadenze tecniche per coloro che vivono ancora sull'API ufficiale:

  • dal 30 agosto 2026 le applicazioni devono essere separate: un'app per Mercado Libre, un'altra per Mercado Pago. Si verifica tramite GET applications/$APP_ID — se negli scopes rimangono diritti del tipo urn:mp:..., l'app deve essere ri-registrata, altrimenti perde l'accesso all'API di Mercado Libre;
  • la trasmissione dell'access-token nei parametri di query è stata riconosciuta come non sicura: tali richieste la piattaforma inizierà a rifiutarle con una risposta 301. Il token deve essere inviato solo nell'intestazione Authorization: Bearer.

La conclusione pratica è semplice: l'API ufficiale nel 2026 è un canale per il venditore che lavora con il proprio account, non uno strumento di analisi di mercato. Se l'obiettivo è monitorare i concorrenti e i prezzi nella regione, si lavora con la vetrina pubblica. Cosa scegliere per un compito specifico, lo abbiamo discusso nel materiale API ufficiale, dataset pronto o il proprio parser.

Sette vetrine invece di un sito

Mercado Libre non è un unico catalogo con filtro per paese, ma un insieme di piattaforme indipendenti con i propri domini, valute e offerte di prodotti. Nell'API sono chiamati site_id:

  • MLA — Argentina (mercadolibre.com.ar, ARS)
  • MLB — Brasile (mercadolivre.com.br, BRL)
  • MLM — Messico (mercadolibre.com.mx, MXN)
  • MLC — Cile, MCO — Colombia, MLU — Uruguay, MPE — Perù, MLV — Venezuela

Lo stesso articolo in MLA e MLB è due schede diverse, due venditori diversi, due schemi logistici diversi. Confrontarli "faccia a faccia" è inutile: è necessaria una normalizzazione per valuta e condizioni di spedizione. A proposito di valuta, la piattaforma fornisce le regole di formattazione in HTML: per l'Argentina è "currency_id":"ARS", "decimal_separator":",", "thousands_separator":".", "time_zone":"GMT-03:00". I parser che tagliano il prezzo con espressioni regolari usando il punto, nelle vetrine latinoamericane sbagliano di mille volte.

Importante: prezzo e spedizione sono calcolati dalla zona del destinatario

Ecco un frammento che è incorporato direttamente nell'HTML della pagina di risultati listado.mercadolibre.com.ar quando si effettua una richiesta senza indirizzo:

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

Si legge così: codice 1430, esso non è stato dedotto dal tuo IP (inferred_zipcode: false), è predefinito (default_zipcode: true). In cima c'è scritto "Enviar a Capital Federal" — cioè la piattaforma ha silenziosamente deciso che sei nell'area metropolitana di Buenos Aires e calcola tutto proprio per essa.

E calcola molte cose. Nello stesso HTML ci sono le etichette di spedizione legate alla zona: same_day_free_shipping con il testo "Llega gratis hoy", icona vpp_full_icon — "Enviado por FULL" (prodotto dal magazzino della piattaforma). In una pagina di risultati per la richiesta "iphone" ci sono stati 96 riferimenti a spedizioni gratuite. Anche il blocco buy_box con "Otra opción de compra": quale venditore vincerà la scheda, è determinato anche da chi consegna più velocemente e a un prezzo inferiore a un codice specifico.

In sintesi: un parser che non ha mai specificato la zona di spedizione raccoglie non "il mercato dell'Argentina", ma un campione di una sola città. Per un rapporto sul paese con città di un milione di abitanti a mille chilometri dalla capitale, questo è un difetto che non si manifesta in alcun modo — i numeri sembrano plausibili, ma non rispondono alla domanda giusta.

Barriera all'ingresso: /gz/account-verification

Una seconda sorpresa attende a livello di trasporto. La richiesta a listado.mercadolibre.com.ar/iphone non restituisce immediatamente i risultati: arriva HTTP 302 su /gz/account-verification?go=...&tid=... — la propria pagina di verifica del dispositivo. Non è Cloudflare e non è DataDome: nel codice della barriera non ci sono né reCAPTCHA, né Turnstile, né marcatori di bot esterni, ma una decina di richieste alla meccanica del dispositivo. La pagina pesa circa 41 KB, è costruita su JavaScript e senza di esso non mostra nulla.

Il comportamento durante la verifica si è rivelato indicativo. La prima richiesta da un IP server pulito è stata accettata dalla barriera: è arrivato un vero risultato di 2.425.906 byte — 50 blocchi ui-search-layout e 120 nodi di prezzo andes-money-amount__fraction, tutto renderizzato sul server. Le richieste successive dallo stesso indirizzo si sono bloccate su /gz/account-verification e non sono andate oltre. Le vetrine brasiliane e messicane dallo stesso IP non hanno lasciato passare nulla.

Questa è una tipica meccanica "reputazionale": l'indirizzo riceve un piccolo credito di fiducia, lo consuma dopo un paio di richieste e si chiude. Nessun test singolo dimostra nulla — è importante che non ci sia accesso sostenibile dal pool di data center e il comportamento varia da paese a paese.

Un'altra dettaglio dagli header di risposta: la piattaforma imposta _d2id (identificatore del dispositivo con durata di un anno, duplicato in x-request-device-id) e _mldataSessionId con Max-Age=1800. Trenta minuti è la lunghezza naturale della sessione, per cui vale la pena adattare il mantenimento dell'IP.

Cosa dice robots.txt

Prima di iniziare la raccolta, è opportuno leggere le regole della piattaforma. Nel robots.txt di entrambe le vetrine (argentina e brasiliana) il blocco superiore è identico e piuttosto chiaro:

  • divieto totale (Disallow: /) per i crawler AI: Amazonbot, GPTBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User;
  • consentito ai bot di anteprima dei social media: FacebookExternalHit, FacebookBot, Twitterbot, LinkedInBot;
  • per Bingbot — Crawl-delay: 5 e un lungo elenco di sezioni chiuse: /gz/cart/, /gz/checkout/, /perfil/vendedor/, /perfil/comprador/, /navigation/, /noindex/ e altri.

Da questo seguono due cose pratiche. Prima: il carrello, il checkout e i profili utente sono chiaramente chiusi — non è necessario accedervi né tecnicamente né legalmente. Seconda: Crawl-delay: 5 per il bot di ricerca è un'indicazione onesta sul ritmo che la piattaforma si aspetta dall'automazione. Cinque secondi per richiesta da un unico indirizzo è un punto di partenza ragionevole, non un numero casuale.

Come raccogliere correttamente: ordine delle azioni

  1. Fissa la matrice di raccolta. Non "Mercado Libre", ma un elenco di coppie "paese × zona di spedizione". Per l'Argentina, ad esempio, Capital Federal, Córdoba, Rosario, Mendoza; per il Brasile — São Paulo, Rio, Belo Horizonte, Recife. Il prezzo senza indicazione della zona non ha senso, e questa decisione deve essere presa prima della prima riga di codice.
  2. Prendi un IP residenziale del paese desiderato. Gli indirizzi server sulle vetrine brasiliane e messicane non hanno superato la barriera, mentre su quella argentina si sono esauriti dopo la prima richiesta. Un indirizzo residenziale locale risolve sia il problema dell'accesso che della veridicità: la piattaforma ti mostra inizialmente ciò che mostrerebbe a un acquirente locale.
  3. Mantieni l'IP per tutta la sessione. Il cookie di sessione vive 30 minuti — la rotazione ad ogni richiesta resetta sia questo che la zona selezionata, e ottieni di nuovo l'indice predefinito. Una sessione persistente di 10-30 minuti per una zona, poi cambio. Come scegliere la lunghezza della finestra, l'abbiamo discusso nella guida su sessioni sticky.
  4. Utilizza un motore browser, non un semplice client HTTP. La pagina /gz/account-verification è interamente costruita su JavaScript: senza l'esecuzione degli script rimarrai per sempre bloccato. Playwright o un analogo con mantenimento dello stato tra i passaggi.
  5. Specifica esplicitamente la zona di spedizione. Il link porta a /addresses/v3/navigation/hub; dopo aver impostato l'indirizzo, lo stato vive nel cookie di sessione. Esegui questa procedura una volta per sessione, non per ogni scheda.
  6. Fai di location_info un checksum. Su ogni pagina salvata verifica che zipcode corrisponda a quello target e che default_zipcode sia diventato false. Se il flag è rimasto true — non scriviamo la riga nella vetrina dei dati, è stata raccolta non per quella zona. Solo questa verifica esclude la maggior parte dei difetti silenziosi.
  7. Recupera i prezzi dall'HTML del server. Il prezzo e le etichette di spedizione sono già renderizzati sul server — non è necessario inseguire gli endpoint JSON interni. Accanto al prezzo, conserva zipcode, user_zone, currency_id e il timestamp: senza di essi il numero non è verificabile.
  8. Mantieni il ritmo. L'indicazione della piattaforma è cinque secondi tra le richieste da un unico indirizzo. Se hai bisogno di velocità — espandi il pool di indirizzi, non la frequenza da un IP: è proprio l'impennata da un indirizzo che chiude la barriera.

Insidie che si scoprono tardi

Difetti silenziosi della zona predefinita. L'errore più costoso non si manifesta con un'eccezione. I dati vengono raccolti, il rapporto viene costruito, la decisione sui prezzi viene presa — e solo dopo un trimestre si scopre che tutta l'analisi sul Brasile descrive un solo quartiere di San Paolo.

Peso delle pagine. Una pagina di risultati pesa 2,4 MB. Mille pagine al giorno su quattro paesi e quattro zone — sono decine di gigabyte di traffico al mese. Con una tariffa residenziale che paga per gigabyte, questa è la principale voce di spesa, quindi ha senso disattivare immediatamente il caricamento di immagini e font nel motore browser: i prezzi sono nell'HTML, le immagini per il parser sono pura sovraccarico.

Confronto tra paesi senza normalizzazione. ARS, BRL, MXN e diversi separatori delle migliaia. Porta a una sola valuta secondo il tasso alla data di raccolta e conserva il prezzo originale e la valuta separatamente, altrimenti non sarà possibile riconvertire retroattivamente.

Affidarsi all'API ufficiale. Se l'integrazione è comunque sull'API, tieni a mente il requisito di applicazioni separate dal 30 agosto 2026 e il trasferimento del token da query a intestazione. La perdita silenziosa dell'accesso all'API appare esattamente come un bug nel tuo codice.

Quali proxy sono necessari per questo compito

Residenziali — una soluzione funzionante per la raccolta di prezzi e spedizioni. È necessario un indirizzo proprio di quel paese la cui vetrina stai raccogliendo, e preferibilmente quella regione la cui zona di spedizione stai verificando: così i dati vengono estratti e rimangono veritieri. I proxy residenziali con mantenimento della sessione soddisfano entrambi i requisiti contemporaneamente.

Mobile — dove la barriera è particolarmente ostinata. L'America Latina è una regione con una alta percentuale di traffico mobile, e un indirizzo di un operatore mobile appare per la piattaforma in modo molto ordinario. Giustificati in campioni ristretti ma critici, non in scarichi di massa.

Data center — per esplorazione e compiti di servizio: leggere robots.txt, estrarre la struttura della pagina, controllare la disponibilità del dominio. Per la raccolta regolare di prezzi, come ha dimostrato la verifica, le risorse non sono sufficienti.

In breve

Mercado Libre nel 2026 non restituisce dati in forma anonima. L'API ufficiale è stata chiusa dalle politiche PolicyAgent, la vetrina incontra una propria verifica del dispositivo, e il numero principale — prezzo con spedizione — è calcolato dalla zona del destinatario, che la piattaforma assegna per impostazione predefinita se non specificata. Un parser corretto qui si distingue da uno errato non per astuzia di bypass, ma per disciplina: paese, zona, valuta e location_info accanto a ogni riga. Tutto il resto è una questione di dove provengono le tue richieste.