How to Use the URL Inspection Tool Effectively
Every other report deals in aggregates. This is the one place you can ask what Google actually holds for a single page. The most useful thing it shows is the gap between the version Google is working from and the version on your site today.
One Page, Everything Google Has
The reports tell you that a number of pages are in a particular state. This tells you about one address specifically, which is what you actually need when somebody asks why a page is not working. It is the fastest way to settle an argument in this whole field.
What the aggregates cannot do. Answer about your page.
Knowing that four hundred pages are excluded does not tell you whether the service page you rewrote last month is one of them. Inspection does, in seconds.
What it is for, in practice. Three situations.
A page that will not appear at all. A change that seems to have had no effect. A suspicion that Google is treating two addresses as one. All three are answered here rather than in a report.
What it does not do. Change anything.
Inspecting a page has no effect on how it is treated. It is a question rather than an instruction, which block six covers properly because people assume otherwise.
Why so few people use it. It is not on the way to anywhere.
The reports are what you land on. Inspection has to be reached for deliberately, with an address in mind, so it gets skipped by everybody who opens the tool to have a general look.
What to do with it. Use it when you have a question.
This is not a monthly check. It is what you reach for the moment something specific looks wrong, which makes it the most useful thing in the tool and the least routinely used.
Indexed Is Not The Same As Current
Google is working from the copy it took the last time it visited. That copy can be weeks old. So a page can be reported as stored and perfectly healthy while the version being used bears little resemblance to what is on your site now.
Why that matters so much. It explains the mystery.
Businesses rewrite a page, see nothing change, conclude the rewrite failed and change it again. Nothing failed. Google has simply not been back yet.
How to see the difference. Test the live address.
Inspecting shows what is stored. Testing fetches the page as it exists now. Running both and comparing them is the single most useful thing in this guide and almost nobody does it.
What a large gap tells you. Visit frequency.
A stored version months out of date means Google is not visiting often, which is itself a finding about how important it considers the page. That is more useful than any single error message.
What it prevents. Changing things twice.
Knowing the change has not been seen yet is what stops you making a second change on top of it, which is how businesses lose the ability to tell what worked.
We will not tell you how long it takes. It varies enormously.
Revisit frequency depends on the site, the page and how much Google thinks it matters. Anybody quoting a number of days for this is guessing.
What It Tells You
Four questions get answered. Reading each one for its implication rather than as a status is what turns this from a curiosity into a diagnostic.
Whether the page is stored. The entry requirement.
Stored means it can appear. It does not mean it will appear for anything in particular. Treating stored as success is the commonest misreading here.
How it was found. The route in.
Whether Google reached it through your sitemap, through a link or some other way. A page discoverable only through the sitemap is a page nothing on your site points at, which is a finding in itself.
Which version is treated as preferred. The interesting one.
Where several addresses show the same content, Google picks one. If it named a different address than the one you inspected, block four is about what that means.
Whether anything blocked it. The technical answer.
An instruction on the page or in the site's rules preventing storage. This is the category people expect to find and it is less common than the others.
How to read them together. As a sequence.
Was it found, was it fetched, was it kept and which version won. Working through in that order tells you where the problem actually sits, which the indexing errors guide then covers.
The Canonical Answer Is The Interesting One
Being told that a different address is the preferred version is how most businesses discover a duplication problem they had no idea existed. It is quietly the most valuable output of the whole inspection.
What is happening. Google chose.
Several addresses show similar content, so one is treated as the real page and the others as versions of it. Only the chosen one competes.
When that is fine. You intended it.
Where you have deliberately pointed several addresses at one preferred version, Google agreeing with you is the system working. Nothing to do.
When it is a problem. It picked differently.
Where Google names an address you did not intend, your instruction is being overridden or contradicted. That usually means two pages are more similar than you realised.
Where this bites hardest. Near duplicate pages.
Sets of service pages or town pages that differ only slightly. One gets chosen and the rest are treated as copies. The business cannot understand why eleven of its twelve pages do nothing.
What to do about it. Make them different or merge them.
Either give each page a genuine reason to exist or consolidate them into one good page. Our technical material owns how the preference is declared and why it gets ignored.
Testing The Live Page
A live test fetches the page as it stands now and shows how it comes together, which is different from showing the source. That distinction matters enormously on modern sites where a good deal of the content is assembled by scripts after the page arrives.
What it reveals. What Google can actually see.
Content built by scripts may or may not be picked up. A live test is where you find out whether the paragraphs you care about are visible to Google or exist only for visitors.
Who this affects. More sites than expect it.
Anything built on a modern framework. Sites with content behind tabs or accordions. Any page where the interesting text loads after everything else.
What a bad result looks like. A thin page.
The rendered version showing far less than a visitor sees. That page is competing on what Google can see rather than on what you wrote, which is a considerably weaker position.
Whose problem it is. Usually a developer's.
This is not a content fix or a settings change. It needs somebody who can alter how the page is built. Our advanced material covers what to ask for.
What else the live test catches. Server behaviour.
A page that fails to fetch when tested, while loading perfectly in your browser, points at something intermittent or at something blocking automated access.
It Is A Diagnosis, Not A Fix
Inspection tells you the state of things. It changes nothing by itself. The request that sits alongside it does considerably less than people hope.
What inspecting achieves. Information.
You now know what Google holds. Nothing about the page, the site or its treatment has altered because you looked, in the same way that reading a thermometer does not warm the room.
What requesting achieves. A place in a queue.
It asks for the page to be looked at sooner. It does not compel storage. A page declined for a reason will be declined again after the visit.
What people do instead. Request repeatedly.
Inspect, request, wait a day, request again. The page has not changed, so the answer does not either. That loop consumes a surprising amount of people's time.
The order that works. Diagnose, change, then ask.
Use the inspection to find out why, change the thing responsible, then request once. Requesting indexing covers the narrow cases where asking genuinely helps.
Where this fits. The cluster position.
Every report here diagnoses and acting on it is separate work. Everything sits on the Google Search Console guide.
Google may
still be reading
last year's
version.
The commonest reason a change appears to have done nothing is that it has not been seen yet. Comparing the stored version against the live page takes a minute and it settles the question, which is considerably cheaper than making a second change on top of the first.
What we check on a page that will not perform:
If Google has chosen a different address as the real page, that is the finding worth acting on rather than the rewrite.
Every guide.
One tool.
Getting set up and verified, using the reports properly, the performance and indexing data, finding what is broken, finding what is being passed over and turning any of it into work worth doing.
