Count Your Indexed Pages Before You Do Anything Else

There is one number I ask for before any other, on every engagement: how many pages do you think this site has, and how many are actually indexed?

The gap between those two numbers diagnoses more problems in five minutes than a week of keyword research.

Reading the gap

Far fewer indexed than expected. Something is blocking or diluting. Common culprits: a stray noindex from a staging deploy, canonical tags pointing everything at the homepage, pagination that buries deeper pages, or thin pages that simply were not kept.

Far more indexed than expected. Usually parameter URLs — filters, sorts, session identifiers — generating effectively infinite variants of the same page. Every one of those splits signals and wastes crawl budget.

Roughly equal. Genuinely rare, and it means your problems are elsewhere. Good news, in a way.

What to do with each

For the first case, work backwards from a sample of missing pages. Fetch one as a crawler would and read what comes back — not what your CMS says should come back. I have found noindex tags that had been live for eleven months this way.

For the second, the fix is rarely robots.txt. Blocking a URL stops it being crawled, not indexed, and you lose the ability to consolidate. Canonical tags plus parameter handling is slower and correct.

The part people skip

Do this again a month after any change. Indexation moves slowly and non-linearly, and the only way to know whether a fix worked is to have the before number written down. Most teams do not record it, then argue about whether things improved.

Why it comes first

Content strategy for a site that cannot be crawled properly is expensive decoration. Whenever I start with an agency team — this was the first month of work with TopSeoMasters on a recent project — the audit and repair phase feels like nothing is happening, because the output is a list of things that stopped being broken.

That is what progress looks like at this stage. Publish afterwards.