The URL Inspection tool and the Page indexing report disagree more often than people expect, and the disagreement is not a bug. They are reading three different datasets, and the toggle at the top of the inspection screen hides which one you are looking at. Once you know which dataset answers which question, the conflict resolves itself in about a minute, usually as “the report is behind”.
Which one should I trust, the URL Inspection tool or the Page indexing report?
For a single page, Google’s own help page settles it in one sentence. The Page indexing report “isn’t used to investigate the index status of specific pages. To find the index status of a specific page, use the URL Inspection tool.” I quote that line to clients more than any other in the help centre. The report is a population view. The inspection is a per-URL view. When they conflict about one URL, the inspection wins.
The report has a second limit that most people never notice. Its example URL list is capped at 1,000 items, and Google says it “isn’t guaranteed to show all URLs in a given status, even when less than 1,000 items”. So the report is structurally incomplete for anything beyond a small site. It tells you how big a problem is. It does not tell you which URLs are in it.
Why does the report say not indexed when inspection says URL is on Google?
Because you are looking at three snapshots taken at different times by different systems.
The Page indexing report is an aggregate that refreshes on its own schedule. Google does not publish that schedule, so I will not put a number on it. The URL Inspection tool with Google Index selected shows the stored indexed version of one URL, and it prints the exact last crawl time that version came from. Those two can be days apart. A URL that was crawled and indexed on Tuesday can sit in the report as “Crawled, currently not indexed” until the report catches up, which is a different problem from the status itself: discovered vs crawled, currently not indexed covers what the status means once the report is caught up.
The third dataset is the live test, and it is the one that causes the most confusion, because the button that switches between it and the indexed view is small and the two screens look alike.
Does the live test tell me whether my page is indexed?
No. Google’s help page is direct about it: “This is a live test: the tool fetches and examines the URL in real time. The information shown in the live test can differ from the indexed URL.” The live test answers one question, which is whether the page as it exists right now could be indexed. It does not check for the URL in any sitemap or referring page, it does not test “whether this is a duplicate or alternate page”, and it skips manual actions, removals and quality checks entirely.
So a green live test on a page the report calls a duplicate is not a contradiction. The live test never looked for duplicates. The indexed view did.
Where the live test earns its place is after a fix. If you removed a noindex or a robots.txt block ten minutes ago, the indexed view still shows the old state and will until the next crawl. The live test shows the new state immediately. That is its only job, and it is the same reason I gave in why Search Console data is delayed: each report answers “did my change work” on a different clock.
Does “URL is on Google” mean my page will show in search?
Not quite. The help page defines the green result as “eligible to appear in Search results, but is not guaranteed to be there”. Indexed is a precondition for ranking, not a promise of it. If the inspection says the URL is on Google and a search for the exact title finds nothing, that is a third situation, not a disagreement between the two tools. The page is indexed and is not ranking, which is a content and demand question, not an indexing one. I covered the flat-line version of that in impressions but no clicks.
What I do when they disagree
I keep a ledger. For every client URL I track, and there are more than 800 of them across the current pipelines, each check records the coverage state and the last crawl time from the inspection result. When the report and the inspection disagree, the ledger turns the argument into a timestamp: the inspection says indexed as of a crawl on this date, the report has not moved since before that date, so the report is behind. No guessing.
The clearest example I have is a junk removal client from June 2026. Two pages had sat in “Crawled, currently not indexed” long enough that the owner assumed they were rejected. I ran the inspection, saw nothing wrong with the indexed version, and requested indexing on both. Both came back as “URL is on Google” the same day. The Page indexing report still listed them under the old status for days afterwards. Anyone reading only the report would have concluded the request failed. The full write-up is in the junk removal case study.
The procedure, in order:
- Inspect the URL and make sure Google Index is selected, not Live Test. Read the verdict and the last crawl date.
- Compare that date with the report’s “last updated” date. If the crawl is newer, the report is behind and there is nothing to fix.
- If the indexed view agrees with the report and both say not indexed, read the reason in the Page availability section. That reason is the real problem, and each one has its own page in my Search Console status guide.
- Only then run the live test, and only to confirm that whatever you changed is actually live.
How many URLs can I inspect per day?
In the browser, Google says only that there is “a per-property daily limit of live inspections” and does not publish the figure. Through the URL Inspection API the limits are documented: 2,000 queries per day and 600 per minute per property. That pool is shared by every tool pointed at the property, so a crawler running the API integration in the morning eats the budget a checker needs in the afternoon.
That quota is the reason the bulk URL inspection tool on this site exists, and why I wrote the guide to bulk URL inspection tools and the quota nobody explains. Inspecting 1,000 example URLs from the report by hand is a full working day. Inspecting them through the API is twenty minutes and half a day’s quota, and it turns the report’s incomplete sample into a complete per-URL answer.
Should I request indexing when they disagree?
Only after step 3 above, and only when the indexed view shows a reason you have actually fixed. Requesting indexing on a URL the report is merely late about does nothing except spend a request. Requesting it on a URL Google has judged and declined does the same. The button works when the page changed and Google has not seen the change yet, which is the case I described in does request indexing work. Everything else is a refresh-rate problem, and refresh-rate problems fix themselves.
Sources
- Google Search Console Help, URL Inspection tool, for the eligible-not-guaranteed definition, the Google Index and Live Test views, what the live test does not check, and the unpublished daily live inspection limit, checked 3 September 2026
- Google Search Console Help, Page indexing report, for the instruction to use URL Inspection for specific pages and the 1,000 example URL cap, checked 3 September 2026
- Google Search Central, Search Console API usage limits, for the 2,000 per day and 600 per minute URL Inspection API quota per property, checked 3 September 2026
- First-hand: per-URL tracking ledger across current client pipelines, and the junk removal company case study, two pages requested and indexed on 16 June 2026