What a 200 OK means
Per the HTTP spec, a 200 response means the request was understood, accepted, and the response body contains the result. For GET requests, that's the entity matching the URL. For POSTs, it's typically a representation of the result of the action. Servers should not return 200 if there's been an error — that's what 4xx and 5xx codes are for — but in practice, many do, because returning 200 with an error in the body is easier than wiring up correct status codes. This loose adherence is why scrapers can't treat 200 as proof of success without also validating the body.
Why 200 isn't always success for scrapers
Bot-detection systems often return 200 with a challenge page, a "please enable JavaScript" notice, or an empty layout. Your HTTP client sees status 200 and reports success; your parser then runs over the wrong HTML and either crashes or silently extracts nothing. This is called a soft block, and it's the most insidious failure mode in scraping because monitoring based on status codes alone misses it entirely. Production scrapers validate two things after every fetch: status code AND a structural signal that the expected content is present (a known selector, a JSON field, a minimum response length).
How to validate a 200 response correctly
Three checks, layered. First, confirm the status code is 200 — anything else short-circuits the rest. Second, confirm the response body has a minimum reasonable size — a real product page is rarely under 5KB; a 1KB "200 OK" is almost always a block page. Third, confirm at least one expected element exists — `soup.select_one('.product-title')` should return a node, not None. If any of the three fails, treat the request as failed, queue a retry with a different proxy/fingerprint, and increment a separate "soft block" counter so you can tell apart "site is broken" from "we're being detected."