URL Inspection tool
Where you see it: Search Console → URL Inspection, or the search bar at the top of any Search Console page
URL Inspection shows what Google knows about one URL on your site: whether it’s indexed, when Google last crawled it, how Google found it and which canonical it chose. Its second mode, Test live URL, fetches the page as it is right now. Paste any address from your property into the bar at the top of Search Console to open it.
Nothing to fix: it’s the tool you diagnose and confirm fixes with.
Open it when a page is missing from Google, after you change a page’s noindex, canonical or robots.txt rule, and before you click Validate fix in a report. Read the indexed result first, because it shows what Google did. Use the live test to prove your change is live.
Check the URL Search Console listed
The indexability checker reads the same fields from outside, for any public URL. Run it next to URL Inspection: where the two disagree, Google’s last crawl predates your fix, or your firewall treats Googlebot and the checker differently.
Indexability report
Enter a URL to see whether Google can crawl and index it, and which Search Console status any problem causes.
What each finding means in Search Console
The Page indexing report in Search Console names the reason a page is not indexed. This is the setting behind each reason, and the guide that fixes it on WordPress. For the full list, see Search Console Errors: Fixes for WordPress.
| What the checker finds | Search Console status | Fix guide |
|---|---|---|
| robots.txt Disallow rule matches the URL | Blocked by robots.txt | Blocked by robots.txt on WordPress: How to Fix |
| noindex in robots meta or X-Robots-Tag | Excluded by ‘noindex’ tag | Excluded by Noindex Tag in WordPress: How to Fix |
| Canonical points to another URL | Alternate page with proper canonical tag | Alternate Page With Proper Canonical Tag: Meaning |
| No canonical, duplicates exist | Duplicate without user-selected canonical | Fix Duplicate Without User-Selected Canonical |
| Conflicting canonicals or weak signals | Duplicate, Google chose different canonical than user | Fix Google Chose Different Canonical Than User |
| URL redirects elsewhere | Page with redirect | Page With Redirect: What It Means on WordPress |
| Returns 404 or 410 | Not found (404) | Fix 404 Errors in Search Console on WordPress |
| Error page that returns 200 | Soft 404 | Soft 404 Errors on WordPress: Causes and Fixes |
| Returns 5xx or times out | Server error (5xx) | Fix 404 Errors in Search Console on WordPress |
| Redirect loop or overly long chain | Redirect error | Fix 404 Errors in Search Console on WordPress |
| Nothing blocks it, but few links or thin content | Discovered – currently not indexed / Crawled – currently not indexed | Discovered – Currently Not Indexed on WordPress |
Reading the result
- robots.txt: the same decision as Crawl allowed, plus the exact rule that made it.
- HTTP status and the redirect chain: what Page fetch would get. A 3xx means Google indexes the destination; a 4xx or 5xx is a failed fetch.
- Robots directives: the noindex behind Indexing allowed, from the meta tag or the X-Robots-Tag header.
- The canonical finding: the tag behind User-declared canonical. Only Search Console shows the Google-selected one.
- Sitemap: whether your sitemap lists the URL, which URL Inspection shows under Discovery.
The same tool with its full guide: Indexability Checker
Why it happens on WordPress
The tool only reports. But the problems it turns up on WordPress sites repeat, each in a particular field, and these settings are usually behind them.
Crawl allowed? No
A Disallow rule matches the path. Check for a physical robots.txt in the site root, which replaces the one WordPress generates, and for lines your SEO plugin’s robots.txt editor added.
Page fetch: Failed
With a 404, the post is a draft, private or trashed, or its slug changed. A 5xx points to PHP errors, host limits or maintenance mode. A 403 means a security plugin, host firewall or CDN rule refused Googlebot.
Indexing allowed? No
A noindex from the post’s own setting, a content-type default in Yoast SEO, Rank Math or SEOPress, or Settings → Reading → “Discourage search engines from indexing this site”. If the page source shows none, look for an X-Robots-Tag header from the server.
User-declared canonical: None, or the wrong URL
None on a category or tag page means no SEO plugin covers it, because core prints canonicals only on single posts, pages and attachments. A wrong URL usually comes from a post’s Canonical URL field, an old address in Settings → General, or a theme printing its own tag.
Google-selected canonical: another URL
Google indexed a different member of a duplicate group. On WordPress that is typically a post winning over its one-post tag archive, https over http, or the older of two posts on one topic.
Discovery: no sitemap, no referring page
Google’s help says an empty Referring page doesn’t prove nothing links there. Still, a new post that no older post links to, and that your sitemap leaves out, gives Google little reason to come back for it.
How to fix it
The order that saves time: indexed result, then live test, then Request indexing only when the live test passes.
1. Inspect the right URL in the right property
Type the full URL, with https and the host you use, into the bar at the top of Search Console, or click the inspect icon next to a URL in a report. The tool only inspects URLs in the property you have open.
2. Read the indexed result first
The verdict at the top is URL is on Google, URL is on Google, but has issues, or URL is not on Google. Everything below it comes from Google’s last crawl, dated under Last crawl, so it can be older than your latest edit.
3. Expand Page indexing and read it top to bottom
The fields follow the order Google works in.
- Discovery: Sitemaps lists sitemaps that include the URL; Referring page shows a page that may have led Google to it.
- Crawl: Last crawl, Crawled as (mobile or desktop), Crawl allowed? and Page fetch.
- Indexing allowed?: a No means a noindex. If robots.txt blocks the page, this always reads Yes, since Google couldn’t see a noindex.
- User-declared canonical and Google-selected canonical: when they match, Google agreed with your tag.
4. Purge caches, then click Test live URL
Clear your page cache and CDN first, or the test may fetch the old version. The result reads URL is available to Google or URL is not available to Google, with a Page availability section explaining any block.
5. Open View tested page
It shows the HTML Google received, a screenshot of the rendered page, and under More info the page resources and JavaScript console messages. Search the HTML for rel="canonical" and noindex to confirm what your SEO plugin printed.
6. Request indexing only when it counts
After a passing live test, Request indexing queues the page for another index attempt. Only owners and full users can use it, there is a daily limit, it’s refused while the live test finds the page non-indexable, and repeating it doesn’t help. Use it for a new post or a fixed key page; after a site-wide change, resubmit your sitemap instead.
Indexed result or live test: which answers what
The indexed result is history; the live test is a preview. Most misreadings come from mixing them up.
| Question | Indexed result | Live test |
|---|---|---|
| Is the page in Google? | Yes, that’s the verdict | No |
| Can Google fetch it and is it allowed to index it? | As of Last crawl | Right now |
| Which canonical did Google choose? | Yes | No, duplicates aren’t checked |
| What does the page look like to Google? | HTML and headers, for indexed URLs | Screenshot, HTML and resources |
Check the fix in Search Console
URL Inspection is also how you prove a WordPress fix landed. A clean sequence:
- Make the change, purge every cache, and run the indexability checker above until it shows the result you want.
- Run Test live URL and look at the field you changed: Crawl allowed?, Indexing allowed?, or the canonical in View tested page.
- Request indexing if the page matters on its own.
- If a report listed the URL, click Validate fix on that reason in Indexing → Pages once every URL under it should leave it; if it mixes real problems with URLs you meant to exclude, skip validation and let the report update as Google recrawls. Google’s help allows up to about two weeks for most validations.
- After the next crawl, inspect the URL again without a live test. A Last crawl date after your change and the verdict you wanted close the loop.
Can RankHive fix this?
There is nothing to fix in the tool itself. RankHive can run the URL Inspection API on your pages during an analysis, read-only, and base post and page fixes on the result; the API returns only the indexed result, so live tests stay with you.
What it writes, once you approve
- A corrected canonical on a post or page in Yoast SEO, Rank Math or SEOPress, when the inspection shows a wrong one.
- Internal links from related posts to a URL Google hasn’t found or crawled.
- Lines in the virtual robots.txt WordPress generates, when a rule there blocks a page you want crawled.
What it can’t do here
- Run Test live URL, Request indexing or Validate fix.
- Set or remove noindex.
- Fix Page fetch failures caused by your host, firewall or CDN.
- Inspect URLs outside the Search Console property you connected.
Every change is drafted next to the current value and waits for your approval. Each one written is logged in the Change Log, with Revert.
Check the rest of your site while you’re here
The free site check reads your public pages for titles, meta descriptions, headings, canonical tags and schema, and shows what needs fixing. If you sign up, RankHive reads your Google Search Console data every week, drafts the fixes, and writes the ones you approve to WordPress. Nothing changes on your site until you say yes.
Related issues
- URL is not on GoogleFix it if you want this page in search, after reading the reason.
- Duplicate, Google chose different canonical than userAct if your choice was the right one; otherwise accept Google’s.
- Excluded by ‘noindex’ tagKeep it on pages you hid on purpose; remove it from pages you want found.
- Blocked by robots.txtFix it only for URLs you want found in Google.
- Discovered – currently not indexedGive new posts time; act when posts you care about stay stuck.
Common questions
What is the URL Inspection tool?
A Search Console tool that shows Google’s indexed information about one URL on a site you own, and tests whether the live page could be indexed.
How many times a day can I use Request indexing?
Google doesn’t publish the number. Its help says only that there is a daily limit, and points to sitemaps when many URLs change.
Why does URL Inspection show old information after I fixed the page?
Because the default view is Google’s last crawl. Click Test live URL to see the current page, and check Last crawl to know which version you’re reading.
Does a passing live test mean my page will be indexed?
No. It means nothing blocks indexing. It doesn’t check duplicates, manual actions or quality, and Google still decides whether to keep the page.
Can I inspect a URL on a site I don’t own?
No. It works only for URLs in a property you can access; Google points to public tests such as the Rich Results Test for other sites. The indexability checker above works on any public URL.
Is there a URL Inspection API?
Yes. The Search Console API returns the indexed result for a URL, including both canonicals, but it can’t test the live page.
Sources
Checked against these pages on .
- Google Search Console Help: URL Inspection tool
- Google Search Console Help: Inspect and troubleshoot a single page
- Google Search Console Help: Check if a URL is available to Google
- Google Search Console Help: Validation details
- Google Search Central: Ask Google to recrawl your URLs
- Search Console API: urlInspection.index.inspect