We had a game in our catalogue with 1,731 recorded plays that showed players a blank rectangle. Its status was 200. Every automated check we ran reported it healthy, and each was answering the question it was asked.
The two headers
A server can refuse to be embedded in two ways. The older is X-Frame-Options, set to DENY or SAMEORIGIN. The newer is a Content-Security-Policy containing frame-ancestors with a list that does not include you.
Either way the browser refuses to render the frame. Your page loads correctly, your request succeeded, and the player sees nothing.
A 404 is honest. A 200 that will not render is worse, because your monitoring agrees with it.
Why this is worse than a dead link
A dead link gets caught on the next sweep and removed. An unembeddable one passes every sweep indefinitely, so it stays in rotation forever, quietly wasting a fraction of every visitor session.
In our case the host had also redirected the old game path to a completely unrelated homepage, which then set SAMEORIGIN. The game had been gone for some time and nothing had noticed.
The fix costs nothing
If your checker already issues a HEAD or GET, the framing headers are on the response you have. Evaluating them adds no extra request. We treat a 200 that refuses framing as its own verdict and retire it on first sighting, the same as a 404, because a browser cannot render it either and the refusal is a deliberate header rather than a transient fault.
Measure before you enable it
This check had been deliberately left out of our sweep, with a comment warning that a new criterion could mass-retire the catalogue. That was a reasonable fear. The answer was to measure it: across every active game, the new rule flagged exactly one. Then we turned it on.
Any new automated removal rule deserves that treatment. Run it in reporting mode, count the hits, then decide.