The wall answers HTTP 200, which is why status codes cannot find it
Mercado Libre's anti-bot response is a well-formed page with a 200 status and zero listings. Six different responses have to be told apart, and only one of them is data.
Mercado Libre's anti-bot wall returns HTTP 200 with a well-formed page containing zero listings, which makes it indistinguishable from a legitimately exhausted result page to anything that checks status codes. Six responses have to be separated: a page with data, an exhausted page, the wall, a CAPTCHA, a page that had not finished rendering, and a page returning a plausible but nearly empty result set. Only the first is treated as data. A wall retires the proxy session rather than being retried on it, a sustained CAPTCHA rate stops the run, and a run that scraped nothing because everything was blocked fails instead of reporting success with zero rows.
Key points
Mercado Libre's anti-bot wall answers HTTP 200 with a well-formed page and zero listings, so a status-code check cannot detect it.
An exhausted results page and a blocked results page look identical from the outside, and treating them the same turns a block into a false 'no results' conclusion.
Six distinct responses are separated — data, exhausted, wall, CAPTCHA, unfinished render and a plausible near-empty page — and only the first is treated as data.
A wall retires the proxy session instead of being retried on it, because retrying a burned session produces another wall.
A run that scraped nothing because every page was blocked fails rather than reporting success with zero rows, which is the difference between a broken run and an empty market.
CAPTCHAs are never solved by any method, and a sustained CAPTCHA rate stops the run instead of escalating against it.
The hardest blocks to handle are the ones that look like success.
A block that looks like a success
Mercado Libre's anti-bot response is a well-formed HTML page, served with HTTP 200, containing zero listings. Every reflex a scraper has — check the status, check the page parsed, check for an error string — passes. What comes back is an empty result set, and an empty result set is a perfectly normal thing for a search to return.
Six responses, one of which is data
The Actor separates six outcomes:
A page with data — the only one treated as data.
An exhausted page: the query genuinely has no more results.
The wall: well-formed, HTTP 200, zero listings.
A CAPTCHA.
A page that had not finished rendering when it was read.
A page returning a plausible but nearly empty result set.
The second and third are the pair that matters. Collapsing them turns every block into a confident “this market has no results”, which is the kind of conclusion that ends up in somebody's slide deck.
Retiring a session instead of retrying it
A wall means the proxy session is burned. Retrying on it produces another wall, and a retry loop on a burned session is how a run turns a small block rate into a total one. The session is retired and the request goes out on a fresh one, with sessions_retired counted.
Failing loudly on a fully blocked run
Why CAPTCHAs are never solved
Not by any method, and a sustained CAPTCHA rate stops the run instead. A CAPTCHA is a site asking a request to prove it is a person; answering it with automation is a different activity from reading a public page, and the line is worth keeping even when crossing it is technically available.
Who pays for a blocked page
The Actor does. A blocked page costs a full browser load of 2.4 to 4.5 MB and returns nothing, and it is never charged — nor is a product page that failed to open, which falls back to the listing row at the listing rate. Charging for attempts would make the wall rate the customer's problem, and the wall rate is not something a customer can influence. That principle is worked through in how listing and detail events are priced, and the wall is also why the pagination measurement looks the way it does.
Frequently asked questions
▸How do I detect Mercado Libre's anti-bot wall?
Not by the status code, because the wall returns HTTP 200 with a well-formed page. It has to be detected by content: a results page that parses correctly and contains zero listings is either exhausted or blocked, and those two need separating before either is believed.
▸What happens when a page hits the wall?
The proxy session is retired and the request is retried on a fresh one, because retrying a burned session simply produces another wall. The blocked page is counted in `wall_hits` and is never charged, since it cost a full browser load and returned nothing.
▸Does the Actor solve CAPTCHAs?
Never, by any method. A sustained CAPTCHA rate stops the run instead. Escalating against a site that is actively asking a request to prove it is a person is a line this Actor does not cross, and stopping is the honest response to it.
▸What if every page in my run gets blocked?
The run fails rather than reporting success with zero rows. An empty dataset from a fully blocked run and an empty dataset from a genuinely empty market are different outcomes, and reporting both as success would make the difference invisible.
Sources
Every URL below was requested and returned a page on the date shown.
A working method for extracting listings and product pages from any of the 17 Mercado Libre marketplaces, including the two decisions — pagination and detail pages — that decide what a run costs.
The official Mercado Libre API requires OAuth and returns 403 to an anonymous request. A comparison of what the API gives an authorised caller, what scraping gives anyone, and which fields exist in only one of the two.
Mercado Libre results mix `articulo.…/MLA-…`, `/p/MLA…` and `/up/MLAU…` links. Deriving the item id from the URL looks fine until the third shape appears, which can be nearly half a page.
