You log into Search Console and the indexed page count is down 200 from last week. Or up 1,500 with no explanation. The Page indexing report shows one aggregate number for the whole property, and that number hides which part of the site is actually drifting. The fix is to slice the report by folder: a 15-minute investigation that turns “something is off” into a specific URL pattern with a specific, named reason.
TL;DR
- The default Page indexing report averages every URL family together, so two folders moving in opposite directions look like a flat line.
- Isolate one folder at a time with a URL filter (Option A, zero setup) or a dedicated URL prefix property (Option B, savable + email alerts).
- Read three numbers per folder: indexed count vs. expected, the top “not indexed” reason, and the 90-day trend shape.
- Since Google’s November 2025 update, “Crawled - currently not indexed” now exposes sub-reasons like low quality signals and insufficient unique content, which tells you whether it’s a quality problem or a config problem.
- Cross-check the date of any cliff against your deploy log; spot-check 3 URLs with URL Inspection (capped at roughly 10-12 manual index requests per property per day as of June 2026).
Why the default view lies to you
Search Console’s default Page indexing view shows totals for the whole property. That works for the first month of a new site, then stops being useful. Real sites have multiple URL families: articles, categories, tags, internal search, product pages, language variants. Each family has its own indexing profile, and changes usually hit one family at a time. The default view averages them all and buries the signal.
The trap is week-over-week comparison on that global chart. If /tags/ loses 400 pages to a thin-content sweep the same week /articles/ gains 400 newly indexed posts, the global number reads flat and you miss both events. Slicing by folder is the only way to see them.
When to reach for this
- Total indexed pages dropped 5% or more week-over-week with no obvious deploy.
- A new category or content type shipped 2-4 weeks ago and you cannot tell if it is being indexed.
- “Discovered - currently not indexed” or “Crawled - currently not indexed” counts are climbing and you do not know which folder owns them.
- A migration moved content between folders and you need to track old vs. new paths separately.
- You publish in two languages and want to know which one is suffering.
Setting up folder-level views
Two options. Option A is faster; Option B is more powerful for ongoing monitoring.
Option A: URL filter inside an existing domain property. Open the Pages report, then Filter > URL contains > /zh/articles/. Apply, then read the chart and the indexed / not-indexed breakdown for that folder only. Repeat per folder. No setup, but you cannot save the view or get a per-folder email alert.
Option B: URL prefix property per folder. Settings > Add property > URL prefix > paste https://yoursite.com/zh/articles/. A URL prefix property is scoped to that exact string, so anything that does not begin with it is excluded. Verification usually inherits from your domain property. Each prefix gets its own Page indexing report, Performance report, and email alerts.
| Option A: URL filter | Option B: URL prefix property | |
|---|---|---|
| Setup time | None | ~2 min per folder |
| Savable view | No | Yes (separate property) |
| Per-folder email alerts | No | Yes |
Works on query strings (?type=article) | Yes (contains) | No (path-prefix only) |
| Data backfill on creation | Inherits property history | Performance backfills ~16 months; Page indexing starts fresh, ~2-3 days to populate |
| Best for | A one-off investigation | Folders you watch every week |
A practical setup: domain property for the whole site, plus a URL prefix property for each high-value folder you monitor weekly. Google explicitly notes the two property types are complementary, not mutually exclusive.
Reading the folder-level report
Within a folder, look at three numbers:
- Indexed pages — compare against the count of URLs you actually have in that folder. A 1,200-article folder showing 800 indexed is a 33% deficit. Investigate.
- Not indexed, by reason — sort by count. The largest reason is your biggest leak. Note: the example-URL list per reason is capped at 1,000 items, so for big folders treat the URL samples as a sample, not the full list.
- Trend over 90 days — a smooth growth curve is healthy. A cliff or a step-down marks a deploy date worth investigating.
Google’s Page indexing report names each not-indexed status precisely. The ones that matter most for folder drift:
| Status (exact GSC label) | What it usually means at the folder level | First move |
|---|---|---|
| Crawled - currently not indexed | Google fetched the page and passed on it; since the Nov 2025 update this expands to sub-reasons like low quality signals / insufficient unique content | Improve the page; do not just re-request indexing |
| Discovered - currently not indexed | Google knows the URL exists but hasn’t crawled it (crawl-budget or internal-link starvation) | Add internal links, submit the folder’s sitemap |
| Duplicate, Google chose different canonical than user | Your canonical tag points one way, Google another | Check the template’s canonical after the last deploy |
| Alternate page with proper canonical tag | Expected for hreflang/pagination alternates; only worrying if it spikes | Confirm it’s intentional, not a template regression |
| URL marked ‘noindex’ | A noindex tag (often shipped by accident) | Grep the template; check internal-search and filter routes |
| Page with redirect | Folder URLs 301’d elsewhere, often after a migration | Map old → new paths; confirm redirects are intended |
The most common folder-level patterns:
- Tag / category folder shrinking — the thin-content threshold finally caught up. Either deepen the pages or
noindexthem. - Article folder shrinking — canonical or hreflang misconfiguration after a template change. Spot-check 5 URLs with URL Inspection.
- Search / filter URLs growing in “Discovered, not indexed” — internal search is leaking URLs. Add
noindexand reduce internal links to them. - One language much smaller than the other — hreflang mismatch, or the sitemap for that language is missing or stale.
A 15-minute debug script
1. Open Search Console; switch to the property covering the suspect folder.
2. Page indexing > URL filter > paste the folder path.
3. Read the indexed count. Compare to what you expect.
4. Click each "not indexed" reason in turn; read the example URLs (and any sub-reason).
5. Pick 3 URLs sharing the same reason. Run URL Inspection on each.
6. Compare the live test result against the indexed result. Find what diverged.
7. Cross-check the date of the divergence against your deploy log.That script catches roughly 80% of indexing drift in 15 minutes. The rest needs server logs, sitemap state, or canonical chains — but at least you already know which folder. One quota note: as of June 2026 the URL Inspection tool’s Request Indexing button is capped at about 10-12 submissions per property per day (Google does not publish the exact figure, and the button greys out once you hit it), so inspect deliberately rather than spraying requests.
Track drift with a weekly baseline snapshot
The most underused move in Search Console is exporting a snapshot of folder-level counts once a week. From the Page indexing report, use the top-right Export > Google Sheets. Save it with the date. After three weeks you have a small table that makes drift obvious: when a folder count moves outside its normal range, you spot it the same week instead of two months later.
For an indie site, three columns are enough: date, folder, indexed count. Add a fourth for the biggest “not indexed” reason. Update the sheet during a 10-minute Monday-morning ritual. Heads up on one limit: the Search Console UI and its exports cap at 1,000 rows, so for big folders export the counts (which is all the baseline needs), and if you ever need the full URL list, pull it via the Search Console API or an add-on like Search Analytics for Sheets.
Cross-reference with sitemaps and server logs
The folder view answers “what did Google decide.” It does not tell you whether Google ever saw the URL. Two sources fill that gap.
Sitemap status (Indexing > Sitemaps) shows submission counts per sitemap. If you split sitemaps by folder (/sitemap-articles.xml, /sitemap-tags.xml), the discovered-vs-indexed gap per sitemap is the most precise version of the folder report.
Server logs (or your CDN’s analytics, e.g. Cloudflare) show actual Googlebot fetches per path. If a folder’s indexed count is dropping and your logs show Googlebot is not fetching it at all, the problem is upstream — robots.txt, broken internal linking, or a sitemap regression — not a quality issue with the pages themselves. Verify any suspicious bot hit is real Googlebot via Google’s verifying-crawlers guide before you trust the log line.
Common mistakes
- Comparing the global chart across weeks without slicing. Two folders moving in opposite directions cancel out and you see a flat line that hides both problems.
- Forgetting the report lags. Page indexing data is not real-time; it updates as Google re-crawls, so today’s deploy may take days to surface. (Performance-report impressions also lag 2-4 days, and longer for low-traffic sites.)
- Adding a URL prefix property and forgetting to submit a sitemap for it. The property works without one, but a submitted sitemap speeds up the report’s accuracy.
- Filtering by
containswhen you needed an exact path./articles/also matches/draft-articles/and inflates the count. - Reading “Crawled - currently not indexed” as a bug. Since Nov 2025 the sub-reason tells you the truth: if it says low quality signals or insufficient unique content, the page needs work, not repeated index requests.
FAQ
- How many folder properties should I have?: One per major URL family. Five to ten covers most sites — articles, blog, category, tags, search, plus one per language if you publish bilingually.
- Does adding properties slow down my main property?: No. They are independent views over the same underlying data; nothing competes.
- Can I see canonical issues per folder?: Yes. “Duplicate, Google chose different canonical than user” appears under the folder filter. Use it right after a canonical-related deploy.
- My folders are query-string-based, not path-based — now what?: Use Option A. The URL filter supports
contains, so?type=articleworks. A URL prefix property only matches a path prefix, so it cannot do query strings. - How long until a new URL prefix property has data?: Usually 2-3 days for Page indexing. Performance data backfills about 16 months; the Page indexing data starts fresh from creation.
- What changed in the November 2025 GSC update?: The Page indexing report added more granular exclusion sub-reasons. “Crawled - currently not indexed” now distinguishes quality signals (e.g. insufficient unique content) from technical exclusions, which makes the quality-vs-config diagnosis far quicker.