Every automated check we had looked inside a single article. Links resolve, disclosures are present, no duplicate of anything published before. Nine checks, all of them scoped to one piece of writing at a time.
Our three worst failures were all outside that scope. A sitemap frozen for ninety-three days. An article that went twenty-seven days without a crawl. A site with no internal links at all. Each individual article was fine. The site was not.
So we wrote a second checker, at a different scale. This is what it looks at, what it found immediately, and where it runs.
The six checks and where each one came from
None of these are clever. Each exists because we lived through the thing it now catches.
Is the sitemap current? Ours had been frozen since June. It was still advertising eleven pages we had deleted while listing none of the ones we had published since.
Do the URLs in the sitemap resolve? Those eleven returned 404 to anything that followed them.
How many article-to-article links exist? Across our English site the answer was six. On the Japanese site it was two, and both of those were between the same pair of posts.
Which articles have nothing pointing at them? These are dead ends for a crawler. A reader who lands there has nowhere to go except back.
Which articles point at nothing? The same problem from the other side.
How old is the newest article? A site that has not published in a month is a different kind of broken, and nothing reports it.
Six checks, a few hundred lines, standard library only. Writing it took about an hour, most of which was spent on the link graph.
What it found
The Japanese site had four articles with no article-to-article links in either direction. They had been that way since publication. All four were still linking correctly to legal pages, which is why a visual check had passed them for months — the links were there, they just went nowhere useful.
Then it caught something while we were still working.
We publish through a script. That script now runs the site checker immediately after a successful publish. On the first article we shipped after building it, the output read:
Gates passed, article published, then a failure line: one article with nothing pointing at it. The article it was complaining about was the one we had just published, forty seconds earlier.
We fixed it before the page had been crawled. The same thing happened again a few hours later with an article on the Japanese site. Two catches on the first day, both of which would otherwise have sat there until somebody noticed.
Where it runs
Two places, for two different reasons.
Immediately after every publish. A new article starts life with nothing pointing at it. That is the default state, not an unusual one, so the moment of publishing is exactly when the check is worth running. The site check does not block the publish and cannot undo it — the article is already live, and the check is telling you what to do next.
Every morning at nine. Rot is not an event. The sitemap did not break on a particular Tuesday; it stopped updating and then stayed stopped for three months. Only a repeated check finds that kind of failure.
The part that decides whether any of this works
The checker writes a dated report to a folder. If that were the whole design, it would be worthless.
A report nobody opens is not monitoring. It is a second copy of the original problem, because the entire failure mode we are trying to fix is information that existed and was never read. The sitemap was visible in a browser the whole time. Search Console would have answered the crawl question for anyone who asked it. Nobody asked.
So the check raises a system notification when something fails. That notification is the actual product; the report is just where the detail lives.
We verified that the notification appears. This sounds like an unnecessary step until you remember that the command to display one returns success whether or not the operating system shows anything, which is the same shape as a publishing API that returns 201 for an article that reaches readers as raw markup. An exit code describes the call. It does not describe what a person saw.
What it cannot do
It does not know whether an internal link is any good. A link exists or it does not; whether it was worth placing where it sits is a judgment. Nothing here stops you from satisfying every check with a block of related links at the bottom of each article, which passes the counter while helping nobody.
It also has no opinion about whether the articles are worth reading. That was true of the per-article gates as well. Both checkers clear the floor so the attention goes somewhere that needs it.
If your site is small
You can run the first three checks by hand in under two minutes, today, without writing anything.
Open your sitemap in a browser. Look at the date on it, then click two or three of the URLs inside.
Take your newest article and inspect its URL in Search Console. Not the ranking. Whether it has been crawled at all.
Open any article and try to reach a different one by clicking. If you cannot, a crawler cannot either.
If all three pass, you do not need a checker yet. If any of them fails, you have learned something more useful than a month of traffic data would have told you.
Editorial note. Written and edited by the operator of this site. The counts, the dates, and the day-one results are from our own two sites and our own tooling, recorded on 2026-09-15.
Disclosure. This article contains no affiliate or sponsored links. This site may earn commissions from links in other articles, and those articles carry their own disclosure at the top. Nothing here is professional advice.
Leave a Reply