Checking exactly what happened to one page

What it reports

Whether the page is in the index. When it was last crawled and what the server returned. Which address was chosen as canonical, and whether that matches your choice.

Any robots or noindex instruction that applied. Whether the page is eligible for search features.

It also shows the markup the crawler received, which is frequently different from what you expected.

It will also tell you which sitemap it found the address in, and which page it followed to get there. That referring page is often the missing piece when an address you did not expect turns up.

• Whether the page is in the index
• When it was last crawled, and what the server returned
• Which address was chosen as canonical
• Any robots or noindex instruction found
• The markup the crawler actually received
• Which sitemap it was found in
• The page it followed to get there

Indexed status versus live test

The first result describes the stored version, which may be weeks old. That is what is in search right now.

The live test fetches the page as it is at this moment. That is what you use after making a change.

Confusing the two causes a lot of wasted effort, because a fix will not show in the stored version until the page is crawled again.

The live test can also fail while the stored version looks fine, which usually means something broke recently. That is worth catching before the next crawl makes it real.

Confusing the two wastes a lot of effort, because a fix will not show in the stored version until the page is crawled again.

Reading the rendered markup

The tool shows the markup after scripting has run. Compare it against what you see in your browser.

Missing content here is the clearest possible evidence that something depends on scripting the crawler did not complete.

It is also where you discover a noindex added by a plugin, a theme or a staging setting nobody remembers.

Compare the word count too. A page that looks full in a browser and arrives nearly empty in the rendered markup is depending entirely on scripting, which is a fragile way to publish anything you want found.

Compare the word count too. A page that looks full in a browser and arrives nearly empty here is depending entirely on scripting.

Requesting indexing

After a real change, request indexing once. It adds the page to a queue for a fresh look.

It does not force a decision, and asking repeatedly does nothing. There is a daily limit on requests for good reason.

Use it for a genuinely new or genuinely changed page, not as a routine habit.

When the canonical disagrees

If the tool says a different address was chosen as canonical, the engine has decided two pages are the same and preferred the other one.

That is a content signal, not a technical one. The pages are too similar.

The fix is to make them genuinely different or to merge them. Changing the tag alone rarely settles it.

That is a content signal rather than a technical one, and changing the tag alone rarely settles it — see duplicate content.

Using it as a habit

Inspect any important new page a few days after publishing. Inspect any page you just fixed. Inspect anything that disappeared.

Three lookups a month is enough for a small site, and it replaces every conversation that begins with a guess.

Every page written by Website Builder Studio ships with the mechanical parts already right, so an inspection usually confirms rather than surprises.

It is also the right way to settle an argument. When somebody insists a page is fine, the tool reports what the engine actually saw, and that ends the discussion in ten seconds.

It is also the right way to settle an argument. The tool reports what the engine actually saw, which ends the discussion in ten seconds.

What it cannot tell you

Why you do not rank. It reports storage and status, not competitive position.

It also does not evaluate quality. A page can be perfectly indexed and never useful to anybody.

For the ranking question, the performance report and an honest read of the page are the right tools.