We submitted to Hacker News twice. Both submissions were auto-killed on
arrival. Both of them rendered a completely normal item page while we were
logged in — title, points, timestamp, our username, everything. We found out
days later, from an API endpoint, and by then we had already written a second
post aimed at a channel that was never going to carry it.
That is not a Hacker News quirk. It is the default across almost every
platform that moderates anything: removed content looks normal to the person
who posted it. It is deliberate — a system that told spammers exactly what
tripped it would be teaching them how to get around it — and the cost lands on
everyone else, because the honest first-time poster gets the same silence.
So the useful question after you post something is not "did it work?" It is
"what would I have to fetch to find out?" Here is the answer for four
platforms, and what each one's false result looks like.
The rule
Verify on the resource itself, logged out. Never on your own view of it, and
never on a feed.
Those are two different mistakes and they fail in opposite directions.
Your logged-in view lies about removal. You are the one account guaranteed to
see your own content, so you are the worst available witness.
A cached feed lies about success. A profile listing or a "recent posts"
endpoint can lag behind a write by minutes. We nearly recorded a perfectly good
post as a failure because the author feed had not caught up yet — which would
have been the mirror image of the HN mistake, and just as wrong.
Between those, the thing to fetch is the individual resource, with no cookies,
asserting on something that would only be present if the post were genuinely
live.
Hacker News
Every item is readable from the public Firebase API, including the field that
matters:
curl -s https://hacker-news.firebaseio.com/v0/item/<id>.json
{ "by": "you", "dead": true, "title": "...", "type": "story" }
"dead": true means it was killed and nobody saw it. The item page will still
look completely ordinary to you.
There is one visible tell if you know to look for it: HN hides the comment
box on dead items. If you open your own submission and there is nowhere to
comment, that is usually why.
New accounts submitting links to a domain with no history on the site are the
classic trigger — that was us, on both counts, one day old and pointing at a
domain we owned. The recovery route is emailing hn@ycombinator.com and
waiting. Resubmitting makes it worse, because now it looks like someone
retrying past a filter.
dev.to
Two endpoints, and only one of them is safe:
curl -s https://dev.to/api/articles/<id> # the article itself — trust this
curl -s "https://dev.to/api/articles?username=me" # the feed — do NOT trust this
The feed is cached. We have watched it return an empty list for an article that
was already live and publicly fetchable at its own URL. Reading that as a
failed post would have been a false negative on a perfectly successful write.
If you cross-post, check the canonical while you are there:
curl -s https://dev.to/you/your-post | grep -o '<link rel="canonical"[^>]*>'
You want that pointing at your own site, not at dev.to.
This is the one where the honest answer is that you cannot check it right now.
As of August 2026: old.reddit.com serves a login interstitial to an anonymous
fetch, the .json endpoint returns HTTP 403 to scripted requests, and the
authenticated comment endpoint returns no moderation fields at all. Third-party
removal checkers are broken by the same API changes.
Two things follow, and the second one is the one people get wrong.
A failed fetch is a broken instrument, not a negative result. If you cannot
load the page, you have learned nothing about whether the post is visible. Do
not record it as removed.
Reading listings is a different question from verifying your own post. We
tested one instrument — anonymous curl against .json — got a 403, and
concluded that Reddit reads were closed in general. They are not. An authorised
API client reads listings perfectly well. The 403 only ever described anonymous
access, and generalising from it cost us a working tool for a while.
So: record it as "posted, not verified", and set a reminder. The one honest
signal is delayed — your account karma moving.
Your own site
Assert on the page's own content. Never on the status code.
curl -s https://yoursite.example/your-post | grep -o '<title>[^<]*</title>'
Then, and this is the part worth doing today rather than after a launch:
curl -s -o /dev/null -w "%{http_code}\n" https://yoursite.example/definitely-not-a-real-page
If that prints 200, your host is serving your homepage for every URL that
does not exist. Ours did, for days.
It has two consequences and both are nasty. Every check of the form "the page
is live, it returns 200" becomes a check that can never fail — we logged
exactly that as evidence our articles were reachable. And it shows search
engines an unlimited supply of duplicate homepages, which is a soft-404 pattern
they are specifically built to penalise.
Search Console, which answers a different question
Being visible and being indexed are not the same thing, and URL Inspection
states the mechanism outright rather than making you infer it.
Two coverage states look similar and mean opposite things:
| State | What it means | What actually helps |
|---|---|---|
| Discovered — currently not indexed | Google knows the URL and has not fetched it | An inbound link from a page it already crawls; requesting indexing by hand |
| Crawled — currently not indexed | Google fetched it and declined | More substantive unique content. Asking again is weak |
Do not read your ranking position as a signal about any of this. Position is a
symptom. We once treated "they rank above us" as evidence of a canonical
problem, rewrote things on that basis, and were simply wrong — URL Inspection
had been reporting the Google-selected canonical the whole time, and it was
ours.
One more thing measured rather than assumed: a healthy sitemap report is not
evidence your recent URLs have been discovered. Ours read Success, no errors
while three articles in it were unknown to Google.
What to write down
Whatever you check, record the number you measured rather than the conclusion
you drew from it.
The most valuable row in our own log is a cross-post that got zero
reactions. At the time that read as a total failure. Weeks later Search
Console named that exact post as the referring page that got the original
article indexed, while a comparable article we had not cross-posted was still
sitting undiscovered. The number that mattered was not the one we had been
looking at.
Had the log said "dev.to didn't work" instead of "0 reactions, canonical
verified", that would have been unrecoverable. You cannot re-derive a
measurement from a verdict.
The cheapest version of all this is two columns in whatever you already use:
what you checked, and what it said. Not "did it work" — the actual response.
Every one of the mistakes above was a case of writing down the verdict and
throwing away the reading it came from.
And keep a date on each row. Every claim on this page was true on 22 August
2026 and several of them are the kind that stop being true without announcing
it. The most expensive error we made was not a wrong measurement; it was a
correct one that went stale while everybody kept quoting it.
Originally published at fewparts.co.uk.
Top comments (1)
This is a really useful distinction, especially the point about recording the measurement instead of the conclusion.
One thing I’d add is that there are really three separate states worth keeping apart: the state of the resource, the state visible to the observer, and the state of the instrument you’re using to measure it.
A missing post, a 403, an empty feed, and a dead: true API response are all different kinds of evidence. None of them should automatically inherit the same conclusion.
That separation has saved me from a lot of bad assumptions in OSINT work. The observation can be completely accurate while the interpretation is still wrong because the acquisition path itself changed.
Really liked this one.