A page can return HTTP 200 and still be functionally gone.
An out-of-stock product page that shows "no longer available" with an empty layout. An expired listing that renders a blank state. A search result page with zero matches.
To a browser, a user, and most uptime checks: fine, 200, page loaded.
To Google: a soft 404. And soft 404s get dropped from the index, quietly. On Google's schedule, not yours.
A question for the technical SEO crowd:
A deploy changes the canonical on 200 product pages from self-referencing to the category URL. Nothing errors. Rankings hold for three weeks, then start sliding.
Would you call that an incident?
Genuinely asking: where do you draw the line between "an SEO issue" and "an incident"?
Worth knowing about robots.txt:
Disallow doesn't remove a URL from the index. It stops the crawl.
If Google already knows the URL, it can keep listing it without being able to see the page. And once it can't crawl the page, it can't read the noindex tag you added to fix it.
Blocking and removing are two different jobs. Using the first for the second is how pages get stuck.
Every check in a deploy pipeline can pass while the deploy quietly breaks crawling.
Build green. Tests green. Health check 200.
And one changed line in robots.txt that no check is looking at.
Nothing failed. That's exactly why nobody looked.
A technical SEO check you can run this week, no tooling required:
Take your robots.txt, your sitemap URL count, and the canonical tag on your top 20 pages.
Compare them to what they were last month. Not to what you think they should be, to what they actually were.
Most traffic drops aren't one bad deploy. They're four small changes nobody diffed.
The most dangerous SEO problems don't throw errors.
They happen quietly.
Uptime is green. Tests pass. Nobody gets paged.
And organic traffic starts sliding six weeks later.