After every publish, we fetch the public URL and record what actually came back. A platform accepting the write isn't the same thing as your article being live — a CMS can say "saved" while the page 404s. So the publish record carries a verification state, and Published only shows when the page was fetched and found.
Trust the states instead of spot-checking URLs by hand. One habit worth keeping: after connecting a new platform, watch the first few posts reach Published — that proves the whole chain, including the platform's own rendering, once.
The states
| State | Meaning | Your move |
|---|---|---|
Published | The public URL was fetched and the page is there | None |
Checking… | Verification hasn't concluded yet | Wait |
Not live (404) | The URL returned not-found past the grace window | See below |
Sent | Delivered, but there was no public URL to check | Open it from the platform's admin |
We stopped checking | Five fetches, and your site never gave an answer that settled anything (a server error or no response each time) | Open the page yourself, then press Check again in the delivery history |
Two deliberate subtleties:
- A fresh 404 doesn't fail immediately. Hosts deploy asynchronously — a page can honestly take minutes to appear. The state stays pending through a grace window and only then concludes unreachable.
- A server error or dead connection never concludes the page is missing. A 5xx means the host had a bad moment, not that your article is gone. Verification retries rather than recording a false failure.
GitHub publishes are the exception: a repository file URL resolving proves nothing about your site, so git-hosted publishes aren't URL-verified — the final page is your build pipeline's to confirm.
Limits and usage
- Verification fetches run on a short schedule after each publish and cost nothing.
- The check is reachability, not rendering quality. A live page with a broken layout reads as
Published— layout is the theme's territory.
If something isn't working
It says Not live (404) after publishing. The write to your CMS succeeded but the public URL still returns not-found. Most hosts deploy asynchronously, so a fresh 404 stays Checking… for a grace window and re-verifies on its own — give it a few minutes before investigating. If it settles on Not live (404), that verdict is final — the post is usually a draft on the platform, the blog page itself is unpublished, or the site needs its own publish step (Webflow). Fix it on the platform, then publish the article again: the new publish gets its own fresh verification and updates the same post.
It shows Sent and never verifies. The platform's public URL was never derivable — usually a platform configuration where the connection can't know the final URL. The post may be fine; open it from the platform's admin.
How often does verification recheck, and for how long?
Every 5 minutes, up to 5 checks per publish. If all 5 pass without an answer, verification stops and the publish shows We stopped checking rather than being called missing. It stays there until you press Check again; nothing keeps trying in the background, and the state says so.
It settled on Not live (404) and I've fixed the site. Will it recheck?
Not on its own. That is a settled verdict, and the sweep only re-fetches publishes that are still open. Open the delivery in the Publishing tab's history and press Check again: the same publish goes back into the queue and is fetched within five minutes. Publishing the article again also works, and updates the same post.
What does the Content Calendar show while all this is happening?
The item reads In Progress with a Going live badge from the moment your platform accepts the article until we have fetched the page. Done is written only when the page was fetched and found. If verification concludes the page is not there, the item goes back to For Review, even if it had been marked Done, so the calendar never says Done about a page nobody could open.
My site is password-protected — will verification mark it Not live?
No. A 401 or 403 counts as verified: the publish did its job, and access control is yours. A server error never concludes the page is missing either.
Why does my draft never show Published?
Because we never URL-check drafts. A draft's public URL correctly returns not-found, so only live publishes are queued for verification — drafts show as Draft.