Seven checks you can run on your own site today

This is not a list of what I do. It is what you can do, today, on your own site, without hiring anyone and without installing anything for the first six.

Each one says what it measures, how to run it, what every possible result means and —the part almost nobody writes— what it does NOT prove. A check without its limit invites you to conclude too much.

If after running them you want me to run them across your whole site and put it in writing, that is the free diagnosis.

Nothing to install

Six checks you run with the browser you already have open. The longest is eight minutes, and most of those are waiting.

From the browser · 2 min

What Google receives from your page

Whether the crawler gets your content or an empty container. It is the first thing I check on any site, and the one that most often changes the whole diagnosis.

1.
Open your site in the browser.
2.
Right click → «View page source». A tab full of text opens: that is what Google receives before anything runs.
3.
Press Ctrl+F (Cmd+F on Mac) and search for <h1.

What comes out tells you which of the three cases you are in.

Your headline is there.: Google is receiving it. Your page is communicating.
There is no <h1> at all, and the whole source fits in two screens.: Google receives an empty container. You see a finished page because your browser assembles it; the crawler does not.
There is an <h1>, but it is not yours.: It says «Home», «Welcome» or the template name. Google does receive a page: the template's, not the one you wrote.

What this check does NOT prove: This looks at one page, not the site. And at the first response: Google may run the JavaScript afterwards, in a second pass with limited resources, and sometimes it does.

From the browser · 1 min

Whether your site has a real 404

What your site does with an address that does not exist. On platforms that assemble the page in the browser, the usual answer is «all fine» plus the home page, and Google treats that as a duplicate.

1.
Type your domain in the address bar followed by something invented: your-site.com/this-does-not-exist-12345.
2.
Look at what appears.
3.
Then right click → «View page source» and search for <title: it tells you which page the server thinks it gave you.

What comes out tells you which of the three cases you are in.

A page saying it does not exist, with links back.: Good. What is left is checking it also answers with status 404, and that does need a terminal or an extension.
Your home page, with its normal content.: Your site is saying «this page exists» for any address anyone mistypes or mislinks. Google can index copies of your home page under addresses you never created.
A blank screen or a platform error.: Nobody comes back from that, and the crawler does not know what to do with it either.

What this check does NOT prove: From the browser you see the screen, not the status code. A page that says «not found» and answers 200 is still a false 404 to Google.

From the browser · 1 min

Whether a tag telling Google not to index it got left behind

It is the most common cause on recently migrated sites, or sites just taken out of a staging environment. The tag protected the draft and nobody removed it.

1.
Open the page that is not appearing in Google.
2.
Right click → «View page source».
3.
Ctrl+F and search for noindex.

What comes out tells you which of the three cases you are in.

Nothing comes up.: Not this one, then. What is left is ruling out the X-Robots-Tag header, which does not show in the page source.
It appears inside <meta name="robots".: There it is. That page is asking Google not to keep it, and Google complies. Removing it is a one-line change.
It appears, but inside a comment or a script.: Probably does not count. Check whether it is inside a real meta tag or only mentioned in the code.

What this check does NOT prove: The same value can travel in the X-Robots-Tag HTTP header, which the browser does not show in «view source». That needs the Network tab of the developer tools, or a terminal.

From the browser · 8 min

Why your performance score changes by itself

That one speed measurement is not a data point. Lighthouse's own documentation says most of the variance comes from the environment, not from the page.

1.
Open PageSpeed Insights and paste your page URL.
2.
Run it five times in a row, changing nothing on the site.
3.
Write down the LCP of each run. Five numbers.

What comes out tells you which of the three cases you are in.

The five are close: say 2.1 · 2.2 · 2.0 · 2.3 · 2.1.: The median is a data point and you can decide on it. Your page is stable.
They scatter: 2.1 · 5.9 · 2.4 · 1.8 · 4.7.: Your problem is not the median, it is the spread. Something external —a third-party script, an ad, a font— answers at a different speed each time.
The «real user data» section says there is no data.: Your site does not have enough traffic for the field report. What you are seeing is the lab, and it is not the same thing. You say so; you do not paper over it.

What this check does NOT prove: Five runs give you an idea, not a distribution. And the lab simulates one device on one network: what your visitor lives is in the field data, when it exists.

From the browser · 3 min

How many pages you think you have, and how many Google kept

The distance between what your site declares and what the crawler accepted. It is the first real finding of almost any audit.

1.
Open your-site.com/sitemap.xml in the browser and count the addresses. If you get a list of sitemaps, open them and add up.
2.
Go to Search Console, Page Indexing report, and look at the number of indexed pages.
3.
Subtract.

What comes out tells you which of the three cases you are in.

The two numbers are close.: Your site and Google's index agree. Whatever happens with traffic is no longer an indexing problem.
Google has far fewer.: Open the report and read the reasons. «Discovered, currently not indexed» is usually linking or crawl budget; «Crawled, currently not indexed» is content, and it is the hard one.
Google has more than you declare.: There are addresses you never put in the sitemap that the crawler found anyway. That can be normal, or they can be parameter duplicates.

What this check does NOT prove: A sitemap is a hint, not an instruction: Google indexes addresses that are not in it and skips addresses that are. The gap tells you where to look, not what is wrong.

From the browser · 3 min

Whether what your code declares matches what the page shows

Structured data is what a search engine or an assistant reads to know who you are and what you sell. If it declares something the page does not say, or the other way round, you are the one who loses.

1.
Open Google's Rich Results Test and paste your URL.
2.
Wait for the result and open each detected type.
3.
Compare each field against what your page actually shows: the price, the name, the address, the FAQs.

What comes out tells you which of the three cases you are in.

It detects nothing.: Your site declares no structured data. Not an error, but you are giving up on telling the machine what you already tell the person.
It detects types and every field matches the page.: Good. That is parity, and it is what Google asks for.
It detects fields that do not exist on the page.: An invented address, a price that is not there, questions nobody sees. That is the typical output of an automatic generator, and it contradicts what the page shows.

What this check does NOT prove: The tool validates syntax and eligibility, not truth. Perfectly formed markup that says something false passes green.

With a terminal

This one needs a console. It comes with both variants because on Windows it is not the same command, and that is measured, not assumed.

From the terminal · 2 min

The same thing, asked for the way Google asks

The terminal version of the first check, and the only one that also sees the status code. It is the first thing I run on any site.

$ in Git Bash, macOS or Linux

curl -s -A "Googlebot" https://your-site.com/ | wc -w
curl -s -o /dev/null -w "%{http_code}" https://your-site.com/does-not-exist
curl -sI https://your-site.com/sitemap.xml

PS> in PowerShell (Windows)

(Invoke-WebRequest -Uri "https://your-site.com/" -UserAgent "Googlebot").Content.Split().Count
(Invoke-WebRequest -Uri "https://your-site.com/does-not-exist" -SkipHttpErrorCheck).StatusCode
(Invoke-WebRequest -Uri "https://your-site.com/sitemap.xml" -Method Head).Headers

In PowerShell, curl is an alias for Invoke-WebRequest and accepts neither -s nor -A; and grep does not exist on Windows. That is why both variants are here: the first works in Git Bash, on macOS and on Linux.

What comes out tells you which of the three cases you are in.

The first number is in the hundreds or more.: Google receives text. How many words exactly depends on the page, but an empty container returns fewer than fifty.
The second returns 404.: Your site tells what exists from what does not. That is correct.
The second returns 200.: Your site claims a page you just invented exists. Google can index it as a duplicate of your home page.

What this check does NOT prove: It measures the first server response. Google may run the JavaScript in a second pass and see more than this shows; what the check proves is what it receives BEFORE that.

All of these come from what I do in the portfolio case studies and explain in the guides. If one gives you a result you do not understand, write to me and tell me what you got: it is the fastest way for this page to get better.

Ran one and the result does not add up?

Tell me what you got. The diagnosis is free and I send it in writing.

Get a free diagnosis