You click publish, the page loads, your article is there. You check the link, it works. You move on.
That verification is worth less than it looks. Over three days I published on four platforms and, because two of my articles quietly disappeared, I started measuring what happens to a post in the hours after it goes live. Every platform does something. None of them tell you.
Disclosure: I build BlueTicks for Gmail, a Chrome and Firefox extension. That is not what this article is about, but you should know I have a product before you read a thousand words from me.
dev.to marks every new article noindex, and nobody mentions it
An article I published carried <meta name="robots" content="noindex"> in its head. My first reaction was that we had been flagged.
The check that settled it took a minute. I pulled dev.to/api/articles/latest, kept the five articles published in the same minute as mine by five other authors, and read their heads. All five carried the same tag. Established accounts, unrelated topics, same result.
So it is not a sanction. It is a quarantine applied to everything new, and it lifts on its own.
How long it lasts is not fixed, which is the part that caught me out. I measured one article still marked more than five hours after publication, and another clear after forty three minutes. I had written down "between five and six hours" as a finding after the first measurement, and the second one destroyed it. One article is not a sample.
The practical consequence is bigger than it sounds. Any indexing check you run in the hours after publishing tests a page the platform is actively asking search engines to ignore. A negative result means nothing. I had already drawn a wrong conclusion from exactly this, deciding one morning that nothing we published was getting indexed, when in fact I was querying quarantined pages.
Medium's RSS feed will tell you your article does not exist
After publishing on Medium I checked the account feed, which is the only endpoint that answers without authentication, since the article pages themselves return 403 to anything that is not a browser.
The feed showed the previous article as the most recent. My new one was absent. It stayed absent for a while, and the profile page did not list it either.
The article was live the whole time. Opening its canonical URL in a browser showed it complete, with every link intact.
So on Medium the feed is not evidence. Neither is the profile listing. The only thing that settles it is the article URL in a real browser, which is inconvenient and is nonetheless the answer.
The dev.to API contradicts itself depending on the page size
This one is small and it would have cost me a false conclusion if I had trusted it.
dev.to/api/articles?username=X&per_page=10 returned three articles for my account. per_page=1 returned a fourth, more recent than all of them. I ran it three times, stable result.
Presumably a cache mismatch between the two query shapes on their side. It does not matter why. What matters is that counting your own published articles from the list endpoint will undercount them, and a verification built on that list will report an article missing when it is live.
Check existence with per_page=1 or with /articles/{id} directly. Never with the list.
Automated moderation can remove a verified article an hour later
The one that actually cost me something.
I published an article on Hashnode, verified it live in a browser, saw it listed on the blog, counted its outbound links. Everything correct.
I name it because I named the other two, and singling out the one platform I am about to keep publishing on would be the wrong kind of tact. What follows is not a complaint about them. It ends better than it starts.
Roughly thirty seven minutes later it had been archived by an automated moderation system, with no reason given. The public URL returned a not found page. The only recourse offered was an appeal button, with no explanation of what rule had been triggered.
I formed a theory about the cause, wrote it down, and published a second article as a test. The second one was archived too, which killed the theory. Two out of three articles on that account were gone, and I still do not know why.
Then I clicked the appeal button, and both came back.
That is the part I nearly did not write, because I had already decided the platform was a write off and had drafted this section as a loss. The appeal offers no form, no field to explain yourself, no confirmation message. You click it and nothing visibly happens. In each case the article was public again in under twenty four hours, and the only notification was an email saying the post had been restored.
I want to be exact about what this does and does not settle. It does not tell me why the articles were removed. No appeal produced an explanation, only a reversal. I am publishing there again without knowing what triggers their detection, which is not a comfortable position and is the honest one.
What it does settle is the cost. An automated removal there is not a loss, it is a delay of about a day plus one click, provided you notice. Noticing is the whole problem, and it brings this back to the counter.
One update, because a section that ends on two removals out of three would leave a false impression of the current state. Since then I have published more on the same blog and the counter reads five published, none archived. Whatever triggered the first two has not fired again, and I still do not know what it was. That is a better outcome than the one I expected when I drafted this, and it does not change the advice: watch the counter, not the page.
What I take from it, and what I would suggest to anyone publishing regularly: the platform's own counter is the truth, not the page. That dashboard showing published and archived counts is the only place the removal was visible. I found it by accident, while publishing the next article and noticing the blog listed one fewer post than it should.
What I do now, in order
Verify at publication, but treat it as a snapshot with a timestamp. It says nothing about an hour later.
Read the platform's own counter, not just the public page. If it exposes published and archived counts, that is your source of truth.
Keep a local copy of everything you publish. Four of my articles existed only on their platforms, including the one post that survived on the account where two were removed. If that one had gone, it was gone. I now pull the source of every published article, through the API where one exists, from the browser where it does not.
Use the recourse before you decide the platform is lost. I had suspended publishing on that platform and written up its abandonment as a recommendation, and I was wrong twice over: I thought one of the two articles was not worth appealing, and I thought appeals against automated moderation were theatre. Two clicks disproved both. A button that costs nothing to press should be pressed before you write the postmortem.
Never conclude from a single measurement. I did it three times in one evening: the cause of the removals, the duration of the quarantine, and the right time of day to publish. All three were plausible, all three were wrong, and each took one extra check to disprove.
And check what a timing intuition means in your reader's timezone. I delayed a post twice to catch a North American audience "in the morning", which would have been three in the morning in New York. Midnight in Paris is late afternoon on the west coast.
None of this is about any platform being badly run. Quarantines and automated moderation exist for good reasons, and caches are how the web stays fast. It is about the gap between what publishing feels like, one click and a working link, and what it actually is, a request whose consequences unfold over several hours in systems you cannot see.
BlueTicks for Gmail is my Chrome and Firefox extension showing WhatsApp-style read receipts in Gmail. It costs 4 dollars a year and there is a free tier. blueticks.io | Chrome Web Store | Firefox Add-ons
Top comments (0)