What does each part of a URL Inspection tool result mean?
I open Google's URL Inspection tool when one address matters: a page that should be earning clicks and isn't, or a page I've just changed. It's the nearest thing Search Console has to asking Google what it holds on a single URL, and it's where the Search Console indexing fixes for WordPress I make start. Report totals show me a trend. One inspection shows me the facts for one page.
You paste the full URL into the bar at the top of Search Console, and it has to belong to the property you're in. The first thing you'll see is a verdict. URL is on Google means the page is indexed and can appear in results, though Google's help adds that it doesn't guarantee the page is appearing. URL is on Google, but has issues means the same, with a problem that might stop it showing with all its enhancements. URL is not on Google means it won't appear at all.
| Field | What it records | What I take from it |
|---|---|---|
| Discovery | Sitemaps that list the URL, and a referring page Google may have used to find it | If a sitemap is the only way Google found a page I care about, its internal links are too thin |
| Last crawl | The last time Google crawled the page, in your local time | If it's older than my last edit, Google's judging the old version |
| Crawled as | The user agent type, desktop or mobile | Which version of the page Google fetched, so I check that version when I test |
| Crawl allowed | Whether robots.txt let Google in | A No on a page that should rank is a rule to fix, and on WordPress I look for a Disallow left over from staging |
| Page fetch | Whether Google could fetch the page | A failure points at the server, a firewall or a redirect, not at the content |
| Indexing allowed | Whether a noindex blocked indexing | I check the Search engine visibility setting and the SEO plugin's rules for that post type |
| User-declared canonical | The canonical the page itself declares | For a page I want ranked, it should name the URL I'm inspecting |
| Google-selected canonical | The URL Google chose when it found similar pages | If it isn't my URL, I've got a duplication question, not an indexing one |
What's the difference between the indexed result and the live test?
They answer two different questions. The indexed result is the record from the most recently indexed version of the page, not the live version on the web. Press Test live URL and the tool fetches the page in real time instead. So the first view says what Google concluded last time, and the second says what Google would find if it came back now.
The live test gives its own verdict: URL is available to Google, URL is available to Google, but has issues, or URL is not available to Google. The first one isn't the good news it sounds like. Google's help says a positive live test isn't a guarantee the page will appear in results, and the live test can't tell you whether the page is a duplicate. Google's canonical choice is made at indexing time, so the Google-selected canonical only shows in the indexed view.
| Question | Indexed result | Live test |
|---|---|---|
| When is it from? | The last time Google indexed the page | Right now |
| Does it show the Google-selected canonical? | Yes | No, that's decided at indexing time |
| Can it spot a duplicate? | Yes, through the canonical fields | No |
| Does it include a screenshot? | No | Yes, under View tested page |
| What does a good verdict mean? | Indexed and able to appear | Fetchable now, with no promise about indexing |
Both views open a panel, View crawled page for the indexed result and View tested page for the live one, with the HTML, the HTTP headers, the JavaScript console output and the page resources that loaded. On a WordPress site built with a page builder, I read the tested HTML for the main copy. If the words a visitor sees aren't in it, Google isn't reading them either, and that's when you can have me compare source and rendered HTML across the templates.
The gap between the two views is usually the finding. If the indexed result says the page was blocked by a noindex and the live test says indexing's allowed, the block has been fixed since Google last looked. If both views agree the page is fine and it still isn't indexed, the cause isn't technical access, and pressing a button won't reach it.
What does the URL Inspection tool show for rich results?
Below Page indexing sits the Enhancements and experience section. If the page has structured data, Google's help says you'll see the rich result types found on it, the number of valid items, a description of each and any warnings or errors. I read it in three ways.
- i.
Valid items
The markup parses and the type is one Google supports. It isn't a promise the rich result will show, so I only check that the count matches what the page should carry, like one BreadcrumbList, not two.
- ii.
Valid with warnings
The item counts as valid, with issues listed beside it. I read each one against the page and only add information the page really has, because a filled-in field has to be true.
- iii.
Errors
An error marks an item with a problem Google flagged. Expanding Detected items shows it, and clicking the issue shows the problem code where possible. The fix usually belongs in the theme or plugin template, not the single page.
Rather have me do this? One person, whole job.
Book a call on UpworkWhy would Google pick a different canonical from mine?
Because a rel=canonical tag is a signal, not an order. Google's documentation calls redirects and rel=canonical annotations strong signals, and sitemap inclusion a weak one, and it says these signals stack when they agree. When the signals point in different directions, Google weighs them and makes its own choice, and that choice shows up as a Google-selected canonical that isn't yours.
When I see a mismatch, I don't start with the tag. I start with everything else that's voting: the site's own links, the sitemap, any redirect that lands on the other version, a trailing slash or parameter duplicate, and near copies of the page. Google's advice is to link internally to the canonical URL and keep only canonical URLs in sitemaps, and most mismatches I find break one of those two. A page with no user-declared canonical that Google treats as a copy is a different case: there's no tag to overrule, so I first ask whether that URL should be indexed at all.
Translated sites add their own twist, because Google also reads hreflang clusters when it picks, and a canonical that fights the hreflang set is a common way to lose a language version. Where several pages cover one subject, my multilingual SEO services consolidate them so only one ranks.
When is Request Indexing worth pressing?
My rule has three parts, and all three have to hold: the live test passes, the page deserves a place in the index, and something has changed since the last crawl. You also need to be an owner or a full user of the property, since Google's permission table gives restricted users fetch only. When those line up, these are the cases where I press it.
- i.
A new page that matters
A new service or landing page that's linked from the site and listed in the sitemap. The request just asks for this one URL a little sooner.
- ii.
A page I've just unblocked
A noindex removed, a robots.txt rule lifted or a broken redirect fixed. The indexed result still shows the old block, the live test shows it's gone, and that difference is exactly what a recrawl is for.
- iii.
A page whose content changed in a way that counts
A rewritten opening, a corrected fact or a new section. If Last crawl is older than the change, Google's still holding the old version.
- iv.
A canonical I've just straightened out
Once the internal links, sitemap and redirects all agree, I request the URL I want as canonical, so Google weighs the new set of signals.
- v.
The key pages after a move
After a platform or URL change, I request a handful of the new URLs that earned the most clicks once the redirect map is live and tested. The sitemap carries the rest.
Press it once. Google says requesting a recrawl of the same URL several times won't get it crawled any faster, and it doesn't guarantee the page will be included at all.
When is it a waste of the daily quota?
Google confirms there's a daily limit on indexing requests, so every press I spend on a page that can't benefit is one I can't spend on a page that can. For many new or updated pages at once, Google's own answer is a sitemap, not the button. These are the cases where I leave it alone.
| Situation | Why the button won't help | What I do instead |
|---|---|---|
| The live test says the page isn't indexable | Google won't take the request while the live test finds a block | Fix the noindex, robots rule or failed fetch, then test again |
| Google chose another URL as canonical | The choice comes from signals, and the signals haven't changed | Line up the links, sitemap and redirects behind one URL |
| Nothing has changed since the last crawl | Google would find the same page it already judged | Leave it, or change what's actually holding it back |
| I already requested it | Repeat requests for one URL don't speed the crawl | Wait, and watch Last crawl |
| A long list of URLs | The button is one URL at a time against a daily limit | Submit or fix the sitemap, and read their status through the URL Inspection API |
| Tag archives, filters and other pages that shouldn't rank | Getting them indexed doesn't help the site | Noindex them and take them out of the sitemap |
For checking many URLs, the URL Inspection API returns the same indexed record without clicking through each one. Google's usage limits page gives it 2,000 calls a day and 600 a minute per site. Bing has its own version too: Bing Webmaster Tools' URL Inspection, which Bing says covers crawling, indexing, SEO and markup details and errors.
Two more cases get pressed a lot. The first is a page that's indexed but not ranking. The tool doesn't look at manual actions, removals or security issues, so it's the wrong place to look for why a page sits on page four. The second is a page in Discovered or Crawled, currently not indexed, and the guide to both statuses covers why the button isn't the fix for them.
If you've got pages you keep requesting that keep coming back with the same verdict, finding the pattern behind them is the work I do, remotely, on WordPress.
Book a call on Upwork
