The store had 18,608 products on WooCommerce, behind Cloudflare. The complaint was ordinary: it felt slow, it sometimes timed out, and search traffic was lower than a catalogue that size should bring in. When I pulled the last 24 hours of response codes from Cloudflare, one line did not belong there.
| Response code, 24 hours | Requests |
|---|---|
| 200 OK | 257,790 |
| 403 Forbidden | 112,530 |
| 410 Gone | 43,080 |
| 429 Too Many Requests | 14,890 |
| 408 Request Timeout | 14,430 |
What the two codes say
A 404 means the server found nothing at that address right now. The HTTP specification is careful to say it does not indicate whether that is temporary or permanent. A 410 is narrower and stronger: the resource is no longer available, and that condition is likely to be permanent. It is the code for something removed on purpose.
For indexing, Google documents treating the two the same: either one gets a URL dropped. So the difference is not that one code removes a page and the other does not. The difference is the claim. A 410 tells every crawler and every tool reading your logs that the page was deliberately and permanently deleted.
Why that claim was wrong here
Product URLs on this store changed often, often enough that the catalogue had accumulated 2,437 redirect rules. Every rename, duplicate or re-slug left an old address behind, and the redirect table was how those addresses found their way to the current page.
Any address that fell outside that table, even for a short window before a redirect was written, did not answer "not here right now". It answered "deleted, permanently". For a page that was only missing because nobody had written its redirect yet, that is false, and it was being said 43,080 times a day.
The worst status code is not the one that loses the visitor. It is the one that tells search engines the loss was intentional.
Why nobody had noticed
Inside WordPress everything looked correct. The products existed, the redirects were listed, and no screen anywhere showed a response code. The 410s only existed at the edge, in what the server actually sent back to whoever asked. You find them by asking the way a crawler asks, not by reading the admin panel.
What I changed, and how I checked it
Missing pages now return 404. I verified it two ways: by requesting deleted product addresses directly and reading the status line, and, more conclusively, by watching 410 disappear from the site's top response codes in Cloudflare entirely.
A 404 still loses the visitor, so the code was never the whole fix. The redirect table still has to be kept up, and the addresses with real traffic still need pointing at the nearest equivalent product. But a 404 is at least an honest description of a page that might come back.
If you run a large catalogue, check this
- Pull the last 24 hours of response codes from your CDN or server logs, not from the CMS. If 410 is in the top five, find out what is sending it.
- Request a deleted product address yourself, for example with curl -I, and read the status line rather than the page.
- Check what your SEO or redirect plugin does with deleted content. Several offer to answer it with a 410, and the setting is easy to switch on and forget.
- Keep 410 for things that really are gone on purpose and should stay gone, such as spam pages injected into a hacked site. For anything you are not sure about, say 404.
- Keep the redirect table maintained. The status code decides what a crawler is told. Only a redirect gets the visitor to the product.
The figures are from Cloudflare's own analytics for the store in the WooCommerce audit, read on 30 July 2026. The full write-up, including what else the audit found, is case study 01.