Kembali ke blog

Parsing Mercado Libre di 2026: mengapa parser mengumpulkan harga dari zona yang salah

Mercado Libre menetapkan indeks default untuk semua yang tidak menetapkan zona pengiriman, dan menghitung harga, pengiriman gratis, dan pemenang buy box dari situ. Endpoint API publik memberikan respons 403 PolicyAgent, dan etalase melakukan pemeriksaan perangkatnya sendiri. Mari kita bahas fakta-fakta yang terverifikasi tentang cara mengumpulkan data dari tujuh etalase Mercado Libre dengan benar dan proxy apa yang diperlukan untuk itu.

📅12 September 2026
Parsing Mercado Libre di 2026: mengapa parser mengumpulkan harga dari zona yang salah

Anda telah mengunduh 40 ribu kartu Mercado Libre, menghitung harga rata-rata di Argentina, dan menyerahkan laporan. Masalahnya adalah bahwa ini bukan harga di Argentina. Ini adalah harga untuk kode pos 1430 — zona default yang digunakan platform untuk semua yang tidak menyebutkan tujuan pengiriman.

Mercado Libre beroperasi di 18 negara di Amerika Latin, pendapatan grup untuk tahun 2025 mencapai 28,9 miliar dolar, dengan 123.670 karyawan di perusahaan. Untuk analitik e-commerce, ini adalah sumber data utama di wilayah tersebut dan sekaligus jebakan yang paling diremehkan: platform memberikan harga yang berbeda, pengiriman yang berbeda, dan pemenang buy box yang berbeda tergantung dari mana permintaan datang dan zona pengiriman mana yang dilihat oleh sesi. Mari kita bahas apa yang sebenarnya rusak dan bagaimana cara mengumpulkan dengan benar.

Apa yang berubah selama tahun 2026: API secara efektif ditutup

Beberapa tahun yang lalu, "parsing Mercado Libre" dapat dilakukan melalui API publik: GET api.mercadolibre.com/sites/MLA/search?q=iphone memberikan hasil tanpa otorisasi. Hari ini, itu tidak lagi berlaku.

Pemeriksaan pada 12 September 2026 dari IP server biasa, tanpa token:

  • /sites — HTTP 403, tubuh {"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, sama dengan PolicyAgent

Dan masalahnya bukan hanya karena tidak adanya token. Penjual dan integrator dalam keluhan publik menggambarkan pola yang sama dengan token akses yang valid: /users/me dan pesanan merespons dengan normal, tetapi endpoint katalog dan peringkat mengembalikan blocked_by: PolicyAgent. Kebijakan akses ke API semakin ketat secara bertahap, berdasarkan endpoint, dan dokumentasi tidak dapat mengikuti.

Secara bersamaan, platform memiliki dua tenggat teknis untuk mereka yang masih menggunakan API resmi:

  • mulai 30 Agustus 2026 aplikasi harus dipisahkan: aplikasi terpisah untuk Mercado Libre, aplikasi terpisah untuk Mercado Pago. Diperiksa melalui GET applications/$APP_ID — jika dalam scopes masih ada hak jenis urn:mp:..., aplikasi perlu diperbarui, jika tidak, ia kehilangan akses ke API Mercado Libre;
  • pengiriman token akses dalam parameter query dianggap tidak aman: permintaan semacam itu akan mulai ditolak oleh platform dengan respons 301. Token harus dikirim hanya dalam header Authorization: Bearer.

Kesimpulan praktisnya sederhana: API resmi pada tahun 2026 adalah saluran untuk penjual yang bekerja dengan akun mereka sendiri, bukan alat analisis pasar. Jika tugasnya adalah memantau pesaing dan harga di wilayah tersebut, Anda bekerja dengan etalase publik. Apa yang harus dipilih untuk tugas tertentu, telah kami bahas dalam materi API resmi, dataset siap pakai, atau parser Anda sendiri.

Tujuh etalase alih-alih satu situs

Mercado Libre bukanlah satu katalog dengan filter berdasarkan negara, melainkan kumpulan platform independen dengan domain, mata uang, dan penawaran produk masing-masing. Dalam API, mereka disebut site_id:

  • MLA — Argentina (mercadolibre.com.ar, ARS)
  • MLB — Brasil (mercadolivre.com.br, BRL)
  • MLM — Meksiko (mercadolibre.com.mx, MXN)
  • MLC — Chili, MCO — Kolombia, MLU — Uruguay, MPE — Peru, MLV — Venezuela

Satu artikel yang sama di MLA dan MLB adalah dua kartu yang berbeda, dua penjual yang berbeda, dua skema logistik yang berbeda. Membandingkan mereka "secara langsung" tidak ada gunanya: perlu normalisasi berdasarkan mata uang dan kondisi pengiriman. Ngomong-ngomong, tentang mata uang — platform sendiri memberikan aturan format dalam HTML: untuk Argentina ini "currency_id":"ARS", "decimal_separator":",", "thousands_separator":".", "time_zone":"GMT-03:00". Parser yang memotong harga dengan ekspresi reguler berdasarkan titik, akan salah seribu kali di etalase Amerika Latin.

Yang utama: harga dan pengiriman dihitung dari zona penerima

Berikut adalah fragmen yang terintegrasi langsung ke dalam HTML halaman hasil listado.mercadolibre.com.ar saat permintaan dilakukan tanpa alamat:

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

Ini dibaca sebagai berikut: kode pos 1430, ia tidak diambil dari IP Anda (inferred_zipcode: false), ia default (default_zipcode: true). Di bagian atas tertera "Enviar a Capital Federal" — artinya platform diam-diam memutuskan bahwa Anda berada di wilayah ibu kota Buenos Aires, dan selanjutnya menghitung semuanya khusus untuknya.

Dan ia menghitung banyak hal. Dalam HTML yang sama terdapat label pengiriman yang terikat pada zona: same_day_free_shipping dengan teks "Llega gratis hoy", ikon vpp_full_icon — "Enviado por FULL" (produk dari gudang platform). Di satu halaman hasil untuk permintaan "iphone", terdapat 96 penyebutan pengiriman gratis. Dari zona juga tergantung blok buy_box dengan "Otra opción de compra": penjual mana yang akan memenangkan kartu, ditentukan juga oleh siapa yang lebih murah dan lebih cepat mengantarkan ke kode pos tertentu.

Kesimpulannya: parser yang tidak pernah menetapkan zona pengiriman, mengumpulkan bukan "pasar Argentina", tetapi potongan dari satu kota. Untuk laporan di negara dengan kota-kota besar yang berjarak seribu kilometer dari ibu kota, ini adalah cacat yang tidak menunjukkan diri — angka-angka terlihat masuk akal, tetapi mereka tidak menjawab pertanyaan yang tepat.

Penghalang di pintu masuk: /gz/account-verification

Ke kejutan kedua menunggu di tingkat transportasi. Permintaan ke listado.mercadolibre.com.ar/iphone tidak memberikan hasil segera: datang HTTP 302 ke /gz/account-verification?go=...&tid=... — halaman pemeriksaan perangkat miliknya sendiri. Ini bukan Cloudflare dan bukan DataDome: dalam kode penghalang tidak ada reCAPTCHA, tidak ada Turnstile, tidak ada penanda dari anti-bot pihak ketiga, tetapi ada sepuluh permintaan ke mekanik perangkat. Halaman ini memiliki berat sekitar 41 KB, dibangun dengan JavaScript dan tanpa itu tidak menunjukkan apa-apa.

Perilaku saat pemeriksaan ternyata menunjukkan. Permintaan pertama dari IP server yang bersih dilewatkan oleh penghalang: hasil nyata datang sebesar 2.425.906 byte — 50 blok ui-search-layout dan 120 simpul harga andes-money-amount__fraction, semuanya dirender di server. Permintaan berulang dari alamat yang sama sudah terhalang di /gz/account-verification dan tidak dapat melanjutkan. Etalase Brasil dan Meksiko dari IP yang sama tidak dibuka sama sekali.

Ini adalah mekanik "reputasi" yang khas: alamat mendapatkan sedikit kredit kepercayaan, menghabiskannya dalam beberapa permintaan dan kemudian ditutup. Tidak ada tes tunggal di sini yang membuktikan apa pun — yang penting adalah bahwa tidak ada akses yang berkelanjutan dari kumpulan data center, dan perilakunya berbeda dari negara ke negara.

Satu detail lagi dari header respons: platform menetapkan _d2id (identifikasi perangkat dengan masa berlaku satu tahun, juga diduplikasi dalam x-request-device-id) dan _mldataSessionId dengan Max-Age=1800. Tiga puluh menit — ini adalah panjang sesi yang alami, yang harus disesuaikan dengan pengaturan IP.

Apa yang dikatakan robots.txt

Sebelum membangun pengumpulan, penting untuk membaca aturan platform. Dalam robots.txt kedua etalase (Argentina dan Brasil) blok atasnya sama dan cukup jelas:

  • larangan penuh (Disallow: /) untuk crawler AI: Amazonbot, GPTBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User;
  • diizinkan untuk bot pratinjau media sosial: FacebookExternalHit, FacebookBot, Twitterbot, LinkedInBot;
  • untuk Bingbot — Crawl-delay: 5 dan daftar panjang bagian yang ditutup: /gz/cart/, /gz/checkout/, /perfil/vendedor/, /perfil/comprador/, /navigation/, /noindex/ dan lainnya.

Dari sini muncul dua hal praktis. Pertama: keranjang, checkout, dan profil pengguna jelas ditutup — tidak perlu mengaksesnya baik secara teknis maupun hukum. Kedua: Crawl-delay: 5 untuk bot pencari adalah panduan yang jujur tentang kecepatan yang diharapkan platform dari otomatisasi. Lima detik per permintaan dari satu alamat adalah titik awal yang masuk akal, bukan angka yang diambil dari udara.

Bagaimana cara mengumpulkan dengan benar: urutan tindakan

  1. Catat matriks pengumpulan. Bukan "Mercado Libre", tetapi daftar pasangan "negara × zona pengiriman". Untuk Argentina, ini misalnya, Capital Federal, Córdoba, Rosario, Mendoza; untuk Brasil — São Paulo, Rio, Belo Horizonte, Recife. Harga tanpa menyebutkan zona tidak ada artinya, dan keputusan ini diambil sebelum baris kode pertama.
  2. Ambil IP residensial dari negara yang diperlukan. Alamat server di etalase Brasil dan Meksiko tidak melewati penghalang sama sekali, di Argentina sudah habis setelah permintaan pertama. Alamat lokal yang tinggal menyelesaikan masalah akses dan keandalan: platform pada awalnya menunjukkan kepada Anda apa yang akan ditunjukkan kepada pembeli lokal.
  3. Jaga IP selama seluruh sesi. Cookie sesi hidup selama 30 menit — rotasi pada setiap permintaan mengatur ulang cookie tersebut, dan Anda kembali mendapatkan indeks default. Sesi lengket selama 10–30 menit untuk satu zona, kemudian ganti. Bagaimana memilih panjang jendela, telah kami bahas dalam panduan tentang sesi lengket.
  4. Gunakan mesin browser, bukan klien HTTP kosong. Halaman /gz/account-verification sepenuhnya dibangun dengan JavaScript: tanpa menjalankan skrip, Anda akan selamanya terjebak di penghalang. Playwright atau alternatif dengan penyimpanan status antara langkah-langkah.
  5. Secara eksplisit tetapkan zona pengiriman. Tautan mengarah ke /addresses/v3/navigation/hub; setelah menetapkan alamat, statusnya disimpan dalam cookie sesi. Jalankan prosedur ini sekali per sesi, bukan untuk setiap kartu.
  6. Jadikan location_info sebagai checksum. Pada setiap halaman yang disimpan, periksa bahwa zipcode cocok dengan yang ditargetkan, dan default_zipcode menjadi false. Jika bendera tetap true — baris tidak ditulis ke etalase data, karena itu tidak dikumpulkan untuk zona yang tepat. Hanya pemeriksaan ini yang memisahkan sebagian besar cacat yang tidak terlihat.
  7. Ambil harga dari HTML server. Harga dan label pengiriman sudah dirender di server — tidak perlu mengejar endpoint JSON internal. Simpan di samping harga itu sendiri zipcode, user_zone, currency_id, dan cap waktu: tanpa mereka, angka tidak dapat diverifikasi.
  8. Jaga kecepatan. Panduan dari platform itu sendiri — lima detik antara permintaan dari satu alamat. Membutuhkan kecepatan — perluas kumpulan alamat, bukan frekuensi dari satu IP: justru lonjakan dari satu alamat yang menutup penghalang.

Perangkap yang akan diketahui terlambat

Cacat diam dari zona default. Kesalahan termahal tidak muncul dengan pengecualian. Data dikumpulkan, laporan dibangun, keputusan tentang penetapan harga diambil — dan hanya setelah satu kuartal terungkap bahwa seluruh analitik untuk Brasil menggambarkan satu daerah di São Paulo.

Berat halaman. Satu halaman hasil — 2,4 MB. Seribu halaman per hari untuk empat negara dan empat zona — itu puluhan gigabyte lalu lintas per bulan. Dengan tarif residensial yang membayar per gigabyte, ini adalah pos utama pengeluaran, jadi ada baiknya segera mematikan pemuatan gambar dan font dalam mesin browser: harga ada di HTML, gambar untuk parser adalah pemborosan murni.

Perbandingan negara tanpa normalisasi. ARS, BRL, MXN dan pemisah ribuan yang berbeda. Sesuaikan ke satu mata uang berdasarkan kurs pada tanggal pengumpulan dan simpan harga awal dan mata uang secara terpisah, jika tidak, menghitung kembali di kemudian hari tidak akan mungkin.

Bergantung pada API resmi. Jika integrasi tetap pada API, ingatlah persyaratan untuk aplikasi terpisah mulai 30 Agustus 2026 dan pemindahan token dari query ke header. Kehilangan akses ke API yang tidak terdeteksi terlihat persis seperti bug dalam kode Anda.

Proxy apa yang dibutuhkan untuk tugas ini

Residensial — pilihan yang bekerja untuk mengumpulkan harga dan pengiriman. Dibutuhkan alamat dari negara yang Anda ambil etalasenya, dan sebaiknya dari wilayah yang Anda periksa zona pengirimannya: dengan cara ini data diperoleh dan tetap dapat dipercaya. Proxy residensial dengan sesi yang terjaga memenuhi kedua persyaratan sekaligus.

Mobile — di mana penghalang sangat keras kepala. Amerika Latin adalah wilayah dengan proporsi lalu lintas seluler yang tinggi, dan alamat operator seluler terlihat sangat biasa bagi platform. Diterima untuk potongan yang sempit tetapi kritis, bukan untuk pengunduhan massal.

Data center — untuk eksplorasi dan tugas administratif: membaca robots.txt, mengambil struktur halaman, memeriksa ketersediaan domain. Untuk pengumpulan harga reguler, seperti yang ditunjukkan oleh pemeriksaan, sumber daya tidak mencukupi.

Singkatnya

Mercado Libre pada tahun 2026 tidak memberikan data secara anonim. API resmi ditutup oleh kebijakan PolicyAgent, etalase menyambut dengan pemeriksaan perangkatnya sendiri, dan angka utama — harga dengan pengiriman — dihitung dari zona penerima, yang platform tetapkan secara default jika tidak ditentukan. Parser yang benar di sini berbeda dari yang salah bukan karena trik penghindaran, tetapi karena disiplin: negara, zona, mata uang, dan location_info di samping setiap baris. Semua yang lainnya adalah masalah dari mana permintaan Anda berasal.