Checking what Google actually sees on your own pages

Aug 29
3 min read

Updated: 2 days ago

Introduction

A page looks complete. The content is there, the images load, the menu works, and everybody assumes search engines receive the same thing.

They may not. Content assembled by script, resources blocked in a configuration file, a page served differently to different visitors, or a template change that removed a heading from the delivered code — all produce a gap between what a person sees and what was actually sent. Closing that gap is a ten-minute exercise, and it ends most technical disputes because it replaces opinion about what might be happening with a record of what actually was.

1. Checking what Google actually sees starts with the inspection tool

The authoritative source.

Your search console can fetch any page on your site and show the delivered code, the rendered result, a screenshot and any resources that failed. That is the closest available answer to the question, and it should be the first thing consulted rather than the last resort after a fortnight of theorising.

2. Read the delivered source, not the developer view

An important distinction.

Viewing the page source shows what arrived; the developer inspector shows the page after scripts have modified it. Those can differ substantially, and it is the first version that determines what is available immediately.

3. Search the source for your main content

The quickest useful test.

Load the source and search for your main heading and a sentence from the body. If they are absent, the content depends on rendering, which is slower to be processed and more fragile than content delivered directly.

4. Check the title, description and canonical

Where template errors surface.

Confirm each page's title, meta description and canonical declaration in the delivered code. Wrong values here are common after migrations, invisible to visitors, and capable of removing pages from search entirely.

5. Load the page with scripting disabled

A quick approximation.

Turning scripts off in a browser shows roughly what is available before any rendering step. It is not exactly what a search engine experiences, and it identifies the most serious dependencies in a few seconds.

6. Check that resources are not blocked

A common self-inflicted problem.

The inspection tool lists resources that could not be loaded, which usually means a robots file is blocking scripts or stylesheets. Blocking those prevents the page being rendered as visitors see it and serves no purpose.

7. Compare the mobile version

The version that matters most.

Indexing is based primarily on the mobile page, so check that version specifically. Sites that serve reduced content on mobile are effectively hiding that content from search, which is rarely the intention.

8. Look for content served differently to different visitors

Occasionally accidental, always worth checking.

Location-based redirects, paywalls and personalisation can deliver something quite different to a crawler than to a person. Where this happens by accident, it is usually a plugin doing something nobody realised it did.

9. Test a page from each template

Proportionate coverage.

Check one home page, one service page, one product page and one article. Problems live in templates rather than in individual pages, so a handful of well-chosen checks covers the entire site more reliably than working through pages at random would.

Repeat this after every significant change to the site. Template edits, plugin updates and platform migrations all alter what is delivered without altering what anybody sees, and this check is the only reliable way to catch that before the traffic data does.

Conclusion

Use the inspection tool in your search console as the authoritative view of what was delivered and rendered.

Read the delivered source rather than the developer view, search it for your main heading and body text, verify the title, description and canonical values in the code, load the page with scripting disabled as a quick approximation, check that no resources are blocked, examine the mobile version because that is what indexing is based on, look for content served differently to different visitors, test one page from each template rather than the whole site, and repeat the check after every significant change.