How to Use Google Search Console's Page Indexing Report

Google Search Console's Page Indexing report can show thousands of URLs under Not indexed. That does not mean thousands of pages are broken.

Some URLs should stay outside Google's index: redirects, duplicates, alternate canonical versions, deliberately removed pages and private or low-value utilities. Other groups expose real failures, such as server errors, accidental noindex directives or a whole commercial section that Google cannot crawl.

The useful question is not “How do I make the grey number disappear?” It is:

Are the canonical pages that matter to this website indexed, and do the excluded URL groups match our intent?

This guide shows you how to answer that question. You will define the expected index, read the report's trends and reason groups, inspect representative URLs, prioritise shared causes, and use Validate fix without treating it as an indexing button.

For the wider relationship among crawling, rendering, canonicals, mobile delivery and monitoring, begin with the Technical SEO guide.

What the Page Indexing report actually shows

The report shows the indexing status of URLs Google knows about in the Search Console property you selected. Its top-level view separates URLs into Indexed and Not indexed, then groups non-indexed URLs by the reason Google recorded.

According to Google's Page Indexing guide, the report can help you see which pages Google can find and index and which indexing problems it encountered. It does not show a complete crawl of your website.

That distinction creates several limits:

• a URL Google does not know about may be absent from both totals;

• the totals may not match your CMS, sitemap or crawler exactly;

• the chart shows the number of URLs in each state on a date, not the number crawled that day;

• example lists can contain up to 1,000 URLs and may not show every affected URL;

• you cannot search the report for one exact URL; and

• an indexed URL remains eligible for Search but is not guaranteed to rank or appear for a particular query.

Use URL Inspection when you need the status of one specific URL. Use the Page Indexing report when you need to understand patterns across a property or sitemap.

Does a small website need this report?

Google says a site with fewer than about 500 pages probably does not need the report for routine monitoring. On a small brochure site, checking the homepage and key service pages with URL Inspection may be more useful than analysing every exclusion.

The report still becomes valuable after a redesign, migration, CMS change or sudden site-wide problem. The deciding factor is not only site size. It is whether grouping URLs can reveal a shared cause that individual inspections would miss.

1) Select the correct Search Console property

The report only covers the property currently selected in Search Console. Before interpreting a count, confirm the property scope.

A Domain property can include protocols and subdomains under the verified domain. A URL-prefix property covers only URLs beginning with its exact prefix. That means these views can report different inventories:

Domain property: example.co.ke
URL-prefix property: https://www.example.co.ke/
URL-prefix property: https://www.example.co.ke/shop/

If your canonical site uses https://www.example.co.ke/ but you open an old HTTP or non-www prefix, the report can appear incomplete or dominated by redirects.

Record:

• selected property;

• canonical protocol and hostname;

• whether important subdomains belong in scope;

• report review date; and

• any launch, migration or template change that may explain the trend.

This short header makes exported evidence understandable later.

2) Define which URLs should be indexed

You cannot judge the report until you know what success looks like for your website.

Create an intended-index inventory by page type. For a typical Kenyan business site, it may look like this:

Your target is not 100% coverage. Google explicitly says duplicate and alternate URLs generally should not be indexed. The goal is to have the canonical version of every important page indexed while expected alternatives remain excluded.

Compare this intended inventory with:

• XML sitemap URLs;

• CMS or database exports;

• a crawl of internal links;

• analytics landing pages;

• important pages from Search Console Performance; and

• known legacy, parameter and utility patterns.

This comparison changes the report from a generic warning list into an audit of your publishing intent.

3) Read the summary without chasing the percentage

Open Search Console, select the property, then go to Indexing → Pages. The summary contains:

• a chart of indexed and not-indexed totals over time;

• a Why pages aren't indexed table;

• an Improve page experience table when applicable; and

• a link to view example indexed pages.

Read the chart as a timeline. Ask what changed near a spike or drop:

• Did the site publish a large catalogue?

• Did a sitemap change?

• Did a migration introduce redirects?

• Did a CMS expose filter or tag URLs?

• Did an outage or firewall rule block Googlebot?

• Did you intentionally remove obsolete content?

A rise in Not indexed can be healthy when old URLs now redirect correctly or a duplicate URL space has been consolidated. A drop in indexed URLs can be expected after pruning. The same shape can signal a serious error when important canonical pages disappear.

Do not compare totals without context. Keep a release log so you can connect report changes with site changes.

4) Use sitemap filtering to isolate the intended inventory

The report becomes more useful when you filter it by a clean XML sitemap containing canonical URLs that you want indexed.

Suppose Google knows about 12,000 URLs, but your submitted product and category sitemap contains 1,800 approved canonical pages. The unfiltered report may be dominated by parameters, redirects and historical URLs. The sitemap-filtered view asks the more relevant question: what happened to the 1,800 URLs you explicitly identified as index candidates?

Use sitemap groups that match operational ownership where possible:

• products;

• categories;

• services;

• locations;

• articles; and

• language or country sections.

Do not create sitemap files merely to make the report tidy. Each sitemap should contain absolute, preferred canonical URLs that return the intended content. Remove redirects, errors, noindex pages and duplicate variants.

A sitemap filter also affects fix validation. Google's documentation warns that when you request validation from a sitemap-filtered view, validation applies only to URLs in that sitemap at the time of the request. Record the filter before you click.

5) Sort every URL group into four queues

Do not prioritise only by affected count. Assign every group to one operational queue:

The indexed-reference queue matters because it gives you healthy siblings from the same site. A template used by both indexed and excluded pages may not be the whole explanation; a failed renderer shared only by the affected group becomes a stronger lead.

Expected exclusions

These groups may require confirmation rather than repair:

An expected exclusion can still expose housekeeping work. A correct 404 does not need a redirect, but internal links to it should be repaired.

Investigate

These groups need evidence before you decide:

• Discovered – currently not indexed;

• Crawled – currently not indexed;

• Duplicate, Google chose different canonical than user;

• Soft 404;

• Indexed, though blocked by robots.txt; and

• unusual changes in indexed totals.

The label tells you where to start, not the whole cause. For example, Discovered – currently not indexed means Google knows the URL but has not crawled it yet. Use Amplify's Discovered diagnosis without rewriting a page Google has not fetched.

Fix promptly when important pages are affected

These groups often indicate owner-controlled technical failures:

• Server error (5xx);

• Redirect error;

• accidental URL marked ‘noindex’;

• unintended URL blocked by robots.txt;

• 401, 403 or other access failures; and

• shared template output that removes content or sends conflicting canonicals.

The Source column helps triage. Google says Website generally indicates something the site owner can fix. Google often describes Google's decision, which may require investigating content identity, canonical signals or overall page value rather than correcting a literal error.

6) Prioritise by impact, pattern and severity

Use four fields to rank work:

1. Importance: Does the group contain priority services, products, locations or guides?

2. Pattern size: Does one template or directory explain many examples?

3. Trend: Is the count stable, improving or rising after a release?

4. Severity: Is this an intentional exclusion, a selection decision or an access failure?

A 5xx affecting 40 main service pages outranks 20,000 expected tracking-parameter duplicates. A canonical mismatch affecting the homepage may outrank a larger archive group.

Create a triage register:

Avoid calling the report count a complete list when the group exceeds the example limit.

7) Inspect representative URLs, not random examples

Open a reason group and examine URLs that help distinguish possible causes. Select:

• one high-value page;

• one recently created page;

• one older page that previously worked;

• one URL from each affected template or directory; and

• one unexpected or edge-case URL.

For each URL, open URL Inspection and record:

• index verdict;

• last crawl date;

• referring page or sitemap where shown;

• crawl permission;

• page fetch result;

• indexing permission;

• user-declared canonical; and

• Google-selected canonical.

Then run Test Live URL when you need to confirm the current response. Google's URL Inspection guidance distinguishes the two states:

If the report records an old noindex but the live test no longer detects it, the page may already be repaired and awaiting recrawl. Compare the last crawl with the deployment time.

The live test does not evaluate every issue. Google specifically notes that it does not test all duplicate and canonical conditions. Do not use a successful live test to dismiss a recorded canonical mismatch without comparing both URLs and their signals.

For a complete URL-level sequence across discovery, access, response, rendering, indexability and canonical selection, use the indexing diagnosis.

8) Find the shared cause behind the group

The report groups outcomes. Your job is to find the system that produced them.

Trace affected URLs back to:

• CMS templates and plugins;

• routing and redirect rules;

• canonical components;

• robots.txt generation;

• page- or header-level noindex logic;

• internal navigation and pagination;

• XML sitemap generators;

• product availability rules;

• JavaScript rendering;

• CDN, firewall and server behaviour; and

• recent deployments or migrations.

If 300 category pages share the same accidental noindex, fix the category template rather than editing 300 records. If only expired product URLs return soft 404s, repair the product-retirement workflow.

Test the repair at three levels:

1. the exact reported example;

2. representative URLs across the affected template; and

3. a control group that should remain unchanged.

The control group catches broad fixes that solve one report reason by creating another problem elsewhere.

9) Use Validate fix at the right time

Validate fix asks Google to check whether all known instances in a reason group have been repaired. It does not request ranking, guarantee indexing or make Google accept a page as canonical.

Before requesting validation:

1. Confirm that the reason represents an actual problem.

2. Fix all known instances in the selected scope.

3. Test representative live URLs.

4. Confirm no template, sitemap or deployment process will recreate the issue.

5. Record whether the report is filtered by sitemap.

Google says validation can stop when it finds an unresolved instance. Starting validation after repairing only one example creates noise rather than evidence.

Validation states can include Not started, Started, Looking good, Passed, Failed and N/A. Individual instances may show Pending, Passed, Failed or Other.

Google says validation typically takes up to about two weeks but can take longer. Treat that as general product guidance, not a deadline for your site. Google also updates issue counts as it recrawls pages even if you do not request validation.

Do not validate intentional exclusions merely to make the interface look clean.

10) Monitor transitions, not only disappearance

A URL can move from one reason to another after your fix. That movement may show progress.

Examples:

• Blocked by robots.txt → Crawled – currently not indexed means Google crossed the access stage and made a later indexing decision.

• Page with redirect remaining stable is correct when the source should redirect.

• Discovered – currently not indexed → Indexed shows Google crawled and selected the page.

• Duplicate, Google chose different canonical → Alternate page with proper canonical may show that publisher and Google signals now agree.

Track:

• affected group count;

• indexed canonical count in the relevant sitemap;

• representative URL verdicts and crawl dates;

• server or rendering evidence where relevant;

• deployment and validation dates; and

• Search performance for the canonical pages.

Review the report monthly or after major changes such as a migration, large content release, new CMS template or broad blocking rule. During an incident, monitor more frequently, but expect report data to lag behind the live site.

11) Do not confuse these four actions

Search Console exposes several actions that solve different problems.

Repeatedly using all four does not strengthen a broken page. Fix the earliest failed dependency first.

A hypothetical Kenyan ecommerce example

Consider a hypothetical Nairobi retailer with 6,400 URLs known to Google. Its clean product, category and guide sitemaps contain 1,250 canonical URLs that the business wants indexed.

The Page Indexing report shows:

• 3,700 duplicate parameter URLs;

• 600 redirected legacy products;

• 450 removed products returning 404;

• 230 products marked noindex;

• 120 categories under Discovered – currently not indexed; and

• 50 URLs with server errors.

The team does not start with the largest group. It confirms that parameter duplicates, relevant redirects and retired-product 404s match the intended inventory.

The 230 noindex products need segmentation. Most are out-of-stock products intentionally excluded, but 35 available products inherited the directive from a faulty template condition. The team fixes that shared rule and tests available, out-of-stock and discontinued control pages.

The 50 server errors receive immediate infrastructure review because several include priority categories. The team uses logs and live tests to find a timeout in the category API.

For the 120 discovered categories, it checks the sitemap, internal links, host health and unnecessary filter expansion using the focused Discovered-status workflow.

Only then does it request validation for the repaired noindex group within the product sitemap. It records the filter, deployment date and representative URLs. Success means Google no longer finds that accidental directive on the known scoped URLs; it does not promise that all 35 products will rank.

The example is hypothetical, but the prioritisation rule applies: preserve intended exclusions, repair shared failures and measure canonical pages that matter.

Page Indexing report operating checklist

Scope and baseline

• Correct Domain or URL-prefix property selected.

• Canonical protocol, hostname and relevant subdomains confirmed.

• Intended indexed page types documented.

• Sitemap, CMS, crawl and high-value landing-page inventories compared.

• Recent deployments, migrations and content releases recorded.

Report interpretation

• Chart reviewed as a trend, not a one-day crawl count.

• Relevant sitemap filter selected and recorded.

• Each reason classified as expected, investigate or fix.

• Business importance and technical severity considered before count.

• Example-list limits acknowledged.

Diagnosis

• Representative URLs selected by page type and value.

• Recorded data compared with the live page and deployment date.

• Crawl, fetch, indexability and canonical fields captured.

• Shared template, routing, sitemap or infrastructure cause identified.

• Repair tested across affected pages and controls.

Validation and monitoring

• All known instances in the selected scope fixed before validation.

• Sitemap-filter scope understood.

• Validation status and failed examples monitored.

• Transitions into new reason groups interpreted by dependency stage.

• Indexed canonical URLs and search performance reviewed separately.

When the report points to a wider technical problem

You can manage expected exclusions and a small template issue internally when ownership is clear. The problem needs deeper investigation when several templates conflict, a migration changed canonical URLs, JavaScript hides primary content, server logs show crawler failures, or report groups do not match the site's intended inventory.

Glarify can help organise connected Search Console page and query data into reviewable groups. Use it to prioritise observations, then verify the Page Indexing reason, representative URLs and live responses in Search Console and on your server. No dashboard can guarantee that Google will index or rank a page.

For a broader baseline, run Amplify's SEO scorecard. If the affected groups span templates, rendering, infrastructure or migration signals, an SEO audit can connect the report to the underlying site implementation.

The Page Indexing report becomes useful when you stop treating every exclusion as a defect. Define the URLs that should win, confirm the exclusions that should exist, and trace unexpected groups back to the system that created them.