Ask Google to Recrawl: The URL Inspection Tool Explained
You rewrote a page three weeks ago and Google is still showing the old title in results. The instinct is to ask Google to recrawl it, and Search Console has a button for exactly that. The button works. What it does not do is tell you whether the crawl happened, or what Google decided about the new version once it did. The URL Inspection tool that surrounds the button holds most of those answers, and most people never read past its first line. This is what each field means, in the order you should read them.
What you are actually asking when you ask Google to recrawl
Two versions of your page exist at any moment. One is live on your server. The other is the copy Google fetched at some point in the past and stored in its index. They drift apart every time you publish an edit, and search results are drawn from the stored copy, not the live one.
A recrawl request asks Google to fetch the live version again and reconsider it. That is the whole transaction. Google’s documentation on recrawling is direct about the limits: crawling can take anywhere from a few days to a few weeks, submitting the same URL repeatedly does not move it up any queue, and there is a quota on individual URL requests. Asking Google to look does not oblige Google to keep what it finds, which is the same gap that separates submission from indexing for a brand-new page.
Read the report before you click anything
Paste a URL into the inspection bar and Google returns a verdict line plus a set of fields describing the indexed copy. The verdict is the headline: URL is on Google, the same with issues attached, URL is not on Google, or a note that the URL is an alternate version of another page. Each of the fields below tells you something the verdict does not.
Last crawl. The date Google last fetched the version it currently holds. For a freshness problem this is the field that settles the argument. If the date sits before your edit, Google has not seen the change yet and a recrawl request is reasonable. If the date sits after your edit and results still show the old copy, Google has seen the change and has not promoted it yet, and clicking again will not hurry that along.
Crawled as. Which crawler fetched the page, usually Googlebot smartphone. Worth checking if your mobile output differs from your desktop output, because that fetch is the one the indexed copy is built from.
Crawl allowed and Indexing allowed. Two separate permissions. The first reflects robots.txt, the second reflects a noindex directive in a meta tag or an HTTP header. A “No” on either is a cause, not a symptom, and no amount of requesting will override it.
Page fetch. What the server actually returned to Googlebot. A redirect, a 404, or a soft failure shows here, and it is often the first sign that a page behaves differently for a crawler than it does for you in a browser.
User-declared canonical and Google-selected canonical. If these two disagree, Google is indexing a different URL than the one you nominated, and the page you are inspecting is a duplicate in Google’s view. This is the single most misread pair of fields in the tool. A recrawl does not resolve a canonical disagreement.
Sitemaps and referring page. How Google found the URL in the first place. If both are empty, you do not have a freshness problem, you have a discovery problem, and the fix is internal links and a sitemap rather than a button.
View crawled page. The stored HTML Google holds, which you can open and read. If your new paragraph is not in there, Google does not have it. This answers the original question more plainly than any status label.
The live test answers a different question
Next to the indexed result sits Test live URL. It fetches the page as it exists right now and reports whether it could be crawled and indexed in its current state. It says nothing about what is in the index today, which is why running it first confuses people: a clean live test on a page that is not in results feels like a contradiction, and it is not one.
Read the two together and the diagnosis usually falls out. Stale indexed copy plus a clean live test means the request is worth making. A live test that fails means fix the page first, because a request for a page that cannot be fetched or cannot be indexed goes nowhere.
When a recrawl is the wrong request
The request queue is not an appeals process. If the page carries a noindex directive, a successful recrawl will confirm the directive and drop the page. If robots.txt blocks the path, the fetch does not happen at all. If Google has selected another canonical, the recrawl reconsiders the page and reaches the same conclusion. If the page has never been indexed and nothing in the report is broken, the question is not freshness but whether Google judges the page worth keeping, which is a separate problem with its own set of causes.
More than a handful of URLs
The inspection tool takes one URL at a time, requires a verified property, and enforces the quota Google places on individual URL requests. Google’s own advice for larger volumes is structural: keep an accurate sitemap and let the lastmod dates carry the freshness signal, as described in the guidance on building and submitting a sitemap. That works at scale, and it is slower and quieter than a per-URL request.
This is the seam AIndexify sits in. You paste URLs or upload a CSV, up to 10,000 per submission, with no Search Console connection or ownership proof needed, and each URL is then checked against live Google results on a fixed schedule so that submission and indexing are reported as two separate events with dates attached. If a URL cannot be indexed at all, a noindex tag or a robots block or a 404, the preflight catches it, marks it Couldn’t check, and refunds the credit rather than billing a check that cannot succeed.
Confirming the recrawl actually landed
Nothing notifies you when Google acts on a request. The confirmation is a second inspection some days later, and the field to read is Last crawl. If that date has moved past your edit, the crawl happened. If the stored HTML now contains your new copy, the index has your change. If the Google-selected canonical still points somewhere else, the crawl happened and the page is still not the one being indexed.
That sequence, request, wait, inspect again, is the honest workflow. The Ultimate Guide to Google Indexing covers the rest of the levers that decide the outcome once the crawl arrives.
If you would rather not run the follow-up inspection by hand on every page you have touched, submit your URLs and let the scheduled checks report where each one actually stands.