Diagnosing "not indexed" for free, once the sweep has run
Inspecting a URL costs quota. Explaining what the inspection meant does not. The two are separate calls so that the expensive one happens when somebody asked for it.
Diagnosing why a URL is not indexed costs nothing in Market4, because the diagnosis is built from an observation that was already paid for. Inspecting a URL spends Search Console quota; reading back what that inspection said, deciding which known cause fits and saying how confident the reading is spends nothing at all. The two are deliberately separate calls, and the free one refuses when no sweep has seen the URL rather than quietly buying an inspection to answer with.
Asking for an explanation of a URL nothing has inspected returns a refusal that names the fix: nothing has inspected this URL yet, run a sweep first, the explanation is built from the observation rather than from a fresh call. That refusal is the feature. A read path that can spend money or quota is a read path that eventually does, usually inside a loop nobody meant to write, and the person who finds out is the one whose daily allowance is gone by lunchtime.
The separation also puts the cost where the decision is. Running a sweep is an act somebody chooses, with a budget attached and a record of what it spent. Reading a diagnosis is something an agent can do as often as it likes, on every URL it holds, without anyone having to think about it first.
A sweep spends that allowance in batches, up to the budget given to the run, and the allowance is shared: every time somebody clicks Inspect URL in the Search Console interface they draw on the same pool. Three things keep a sweep from wasting it. A URL asked about in the last 24 hours is skipped rather than re-asked. A reserved slice of the daily quota is never touched, so a sweep cannot leave a person unable to inspect anything by hand. A failed inspection is not retried inside the run, because it has already cost a call.
What the sweep buys that a single status check cannot is time. Whether a page is indexed today is one observation. How long indexing takes needs two observations of the same URL in different states, which is why the sweep stores what it saw rather than printing it and forgetting it. The median time to index stays unreported until enough URLs have been watched across that transition to measure one.
The submit call is a PUT that returns an empty body. Whether Google fetched the file, whether it parsed and how many URLs it holds all come back from a different call, on Google's schedule rather than yours.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
The diagnosis is assembled from the columns the sweep stored plus the site's own content signals, which are read from the posts rather than trusted from the stored row. The stored side is the verdict Google returned, the coverage state, the robots.txt state, the indexing state, the last crawl time, the canonical Google chose, the canonical the page declared, the page fetch state, and counts of referring URLs and sitemaps.
| Stored field | What it tells you | What to look at next |
|---|---|---|
| Coverage state | Google's own summary of why the page is or is not in the index | The wording is the starting point for everything below |
| Robots.txt state | Whether crawling was allowed at fetch time | The live robots.txt, and which user agent the rule matched |
| Page fetch state | Whether the page could be retrieved at all | Server errors, redirects and anything requiring a session |
| Google canonical against declared canonical | Whether Google agreed with the page about which URL is the real one | Duplicate or near-duplicate pages competing for the same content |
| Referring URL count | Whether Google found any link into the page | Internal links; a page reachable only from the sitemap is weakly discovered |
| Sitemap count | Whether the URL was in a sitemap Google fetched | The sitemap, and whether the publish that should have added it did |
The referring URL count is stored as a number rather than as a list, because the diagnosis only ever asks whether that number is zero. That is also why a diagnosis can tell you a page has no links into it but cannot tell you which pages ought to link to it. Finding those is a different job, done against the site's own posts, and it costs no quota either.
The general shape here is worth stealing for any tool that talks to a metered API: buy once, store the observation, and make every reading of it free. It means the expensive call happens when a person asked for it, and the interpretation — which is the part that improves as you learn more — can be rerun over old observations without paying again.
No. The explanation is built from an inspection a sweep already stored, so it makes no call to Google and can be repeated as often as you like. Quota is spent only by the sweep that recorded the observation. If no sweep has ever seen the URL, the explanation refuses and tells you to run a sweep rather than buying an inspection on your behalf.
Because a read path that can spend eventually does, usually inside an automated loop nobody intended. Keeping the spend in one explicit call means the daily allowance is only ever consumed by an action somebody chose, with a budget attached. The refusal names the fix, so the caller loses one round trip rather than a day's quota.
Up to the budget given to that run, against a per-property allowance of 2,000 calls a day that is shared with every manual inspection somebody performs in the Search Console interface. A reserved slice is never touched by the sweep, URLs inspected within the last 24 hours are skipped, and failed inspections are not retried inside the run.
Not through the Indexing API, which is restricted to job postings and livestream pages; using it for ordinary articles risks the property's access to it. What is left is the ordinary route: make sure the page is crawlable, canonical to itself, present in the sitemap and linked from pages Google already visits, then wait for a recrawl.
Google's five words say the page was fetched and left out of the index. They say nothing about why. Here is what the string reports, how it differs from "discovered", and the evidence that narrows it to a cause.
Publishing writes to a database and tells search engines about an address. Preflighting is the step that asks the server answering that address whether it serves a page. What to check, which findings block an announcement, and why the check must never fail a publish.