Reference guide · search-console · Published 2026-08-15 · 3 min read
Search Console indexing analysis workflow
Search Console indexing analysis workflow: start from Pages report reasons, sample URLs, find shared causes and measure the fix.
- ·Start with a reason
- ·Sample, do not guess
- ·Change one variable, remeasure
The analysis loop that finds broken patterns
A not-indexed URL without context is a data point. The search-console-indexing-analysis workflow is the loop that turns data points into a fix: pick a reason, sample its URLs, hunt for the shared cause, change it, remeasure.
Storage warning: the report keeps the log of every page Google knows about, not just the good pages. The loops described below default to reading one reason branch at a time, but the Pages report surface is a tree: Indexing > Pages groups by reason, and every reason is a URL list. Start there.
Step 1: Pick the reason that has volume
Open the Pages report and sort by number of URLs per reason. Work the biggest actionable reason first, not the scariest name. A 4,000-row Duplicate-without-user-selected-canonical group is more valuable than 8 rows of 404 errors, because one template change fixes the 4,000.
Step 2: Sample the URL list
Open the reason's URL list and read ten to twenty URLs spread across the list, not the first ten alphabetically. You are looking for a shared factor. Ask the same questions for each:
- Is the page canonical-addressable in the index (unique content)?
- Does the page have at least one internal link from a page Google indexes?
- Does it resolve to a status that matches its intent (200, 301, 404)?
- Does it share a template, a parameter, or a section of the site?
If the sample shows a shared factor, you have a pattern. If the sample is only noise, widen it or switch reason.
Step 3: Confirm with URL inspection on three representatives
For three of the sampled URLs, run the URL inspection live test (URL inspection guide). The Pages report lists a reason and a last crawl; inspection says now. Mismatches happen when the report snapshot is old.
| Report says | Inspection live test says | Verdict |
|---|---|---|
| Not indexed | Available to Google, indexable | The fix already landed; request indexing |
| Not indexed | Blocked by robots/noindex | The blocker is real, fix the signal |
| Not indexed | Duplicate, canonical points elsewhere | Consolidate canonical or add value |
Step 4: Design the one change that covers the pattern
Work from cause, not from page. A parameter-based duplicate tail is fixed by a redirect map or canonical rule, not by editing 4,000 pages. A noindex tail is fixed in the template, then propagated by a rebuilt crawl. The canonical and redirect guides cover the two most common pattern causes.
Step 5: Remeasure on the same slice
After a fix there is no instant refresh. The report updates on crawls, the request indexing route is for singles, and the sitemap is the bulk nudge. Remeasure on the same reasons group three to four weeks later, not twenty-four hours, except for the sitemap where surfaced pages can move within a week.
The sequence in one run
Pages report reason -> sample URLs -> shared-factor find -> template-level fix -> sitemap or request -> remeasure the same slice. This is the exact loop that the Pages report reference and the crawl budget guide together define for the site side.