WordPress still registers a dozen legacy widgets, but on a modern site most of the clutter is now blocks. Here is what each method actually removes, tested on a current install.
A visitor mistypes a URL and lands on your tidy "page not found" screen. It looks correct. But if that screen was delivered with an HTTP 200, a search engine just saw a real page where there is nothing - and it may index the emptiness. The words say "not found"; the status code says "here's content."
You moved the site from staging to the live domain, ran a database search-replace for the old host, and most links updated - but some images 404, a widget points at the old URL, and a page-builder block still loads from staging. The replace didn't fail. It reached one kind of data and silently skipped two others.
You finished the site, applied to an ad network, and nothing serves. Often the block isn't your content or your traffic - it's a missing text file at your domain root that the network uses to confirm the ad space is really yours to sell.
You're mapping a messy source vocabulary onto a clean target taxonomy. The target has about 5,600 slots, so the job must be roughly 5,600 decisions — right? The backlog is already past 8,900, and still climbing.
You shipped a fix to how one field is computed, re-ran the pipeline across everything, and it reported a clean run. Then the consistency check still flags those records as wrong. The fix is in the code, the rebuild "ran" — and the records never changed. Your own optimisation skipped them.
The report said 80 duplicate groups still to resolve. You'd been resolving them for days. You run it again after a big batch and it *still* says 80-ish. The backlog isn't stubborn — the scan is counting work you already finished.
You hardened a skill in the repo, shipped the PR, and the agent kept loading the old one. Or you fixed the live skill by hand, and the versioned copy quietly stayed behind. Same root cause: the copy you run and the copy you version are two different files.