Reading the Page indexing report in Search Console

What the report is for

The Page indexing report in Search Console shows which pages on your site Google has indexed and which it has not, with a reason for each page it left out. It is the first place to look when an important page is missing from search, when a site has just moved, or when the number of indexed pages changes suddenly.

It is easy to misread. The chart shows a gray bar for pages not indexed, and on most sites that bar is larger than the green one. That alarms people. In most cases it is not a problem, because many of those addresses were never meant to be indexed: redirects, duplicates, filtered versions of pages, old addresses and so on.

The skill is telling the reasons that matter from the ones that do not. Google's own help page for the report lists every status; this guide focuses on how to prioritize them.

How to open it

In Search Console, choose the property, then open Pages under Indexing in the left menu. The chart at the top shows indexed and not indexed pages over time. Below it, a table lists the reasons pages are not indexed, with a count for each.

Two settings help before you start reading:

• use the filter above the chart to view all known pages, or only pages listed in your submitted sitemaps
• check the date of the last update, because the report is not live and can lag behind changes you have made

Viewing only sitemap pages is often the clearer view. Those are the pages you have told Google you want indexed, so any that are not indexed deserve a look.

The reasons that are usually fine

Several statuses describe Google doing exactly what you asked, or what it should:

• Page with redirect. The address redirects elsewhere. Expected after any rebuild or move.
• Alternate page with proper canonical tag. A duplicate that correctly points to the main version.
• Excluded by noindex tag. You told Google not to index it. Fine if that was deliberate.
• Not found (404). The page no longer exists. Fine if it was removed on purpose and has no valuable links.

The check for each is the same: is this what we intended? If a page you want in search appears under any of these, something is set up wrongly.

The reasons that often need action

Other statuses usually point to a decision Google made that you may want to change:

1. Crawled, currently not indexed. Google fetched the page and chose not to index it, often because it judged the page too similar to others or not useful enough. Our answer on what Crawled, currently not indexed means covers this one in detail.
2. Discovered, currently not indexed. Google knows the address but has not fetched it yet. On a small site this often points to weak internal links or a page Google does not see as a priority.
3. Duplicate without user-selected canonical. Google found several similar pages and picked one itself, because none was marked as the main version.
4. Duplicate, Google chose different canonical than user. You marked a main version, but Google disagreed.
5. Server error (5xx). Google could not fetch the page because the server failed. Even a few deserve attention.
6. Blocked by robots.txt. Google was told not to crawl the address. Fine for private areas, harmful if it covers real pages.

Deciding where to start

Do not try to clear every gray row. Work in this order:

1. Filter to sitemap pages. Look for any important page that is not indexed.
2. Check server errors and robots.txt blocks first, because they can affect many pages at once.
3. Look at the crawled and discovered statuses for your main service and location pages.
4. Leave redirects, intended noindex pages and genuine 404s alone unless a valuable page has ended up there by mistake.

For any single page, use the URL inspection tool at the top of Search Console. It shows whether the page is indexed, which canonical Google chose, when it was last crawled and whether it could be fetched.

After you fix something

Search Console lets you tell Google that you have fixed the cause of a status. Open the reason in the table, check the example pages, and choose Validate fix. Google then rechecks the affected pages over the following days or weeks and reports whether the fix held.

Validation is worth using for real problems such as server errors, accidental noindex tags or pages blocked by robots.txt. It is not needed for statuses that were never problems, such as intended redirects.

Keep a short note each time you change something: the date, the status, the pages affected and what was done. When the chart moves a month later, that note is how you know whether the change caused it. Without it, every change in the report becomes a guess.

How often to look

For most small business sites, a monthly look at the Page indexing report is enough. Check it more often in three situations:

• in the weeks after a new site launches or an old one moves to a new address
• after a large batch of new pages is published
• when Search Console sends an email about a new indexing issue

In each case, compare the indexed count with the number of pages you expect to be indexed. A gap that keeps growing is the signal to dig in. A gap that stays stable, made up of expected statuses, is normal.

A worked example

A small law firm's site shows a few dozen indexed pages and several hundred not indexed. The owner assumes something is badly wrong.

Filtering to sitemap pages shows that almost all the sitemap pages are indexed. The large gray number is made up of old addresses from a previous site that now redirect, tag and author archive pages, and addresses with tracking parameters. All are expected.

Two pages in the sitemap are under Crawled, currently not indexed: two practice area pages that repeat much of the same text. Rewriting one so that it serves a clearly different search, and linking to both from the main practice page, is the real task. Everything else in the report can wait.

What to check first

Open the report, filter to sitemap pages and ask one question: is every page we care about indexed? If yes, the gray bar is mostly noise. If no, inspect those pages one by one. That habit, repeated monthly, catches indexing problems while they are small. If the report shows a pattern you cannot explain, our indexing problems work starts from exactly this view.