You log into Search Console and the indexed page count is down 200 from last week. Or up 1,500 with no explanation. The Pages report shows aggregate numbers that hide which part of the site is drifting. The fix is to slice coverage by folder — a 15-minute investigation that turns “something is off” into a specific URL pattern with a specific reason.
Background
Search Console’s default Pages view shows totals for the whole property. That works for the first month of a new site and then stops being useful. Real sites have multiple URL families — articles, categories, tags, search, product pages, language variants. Each family has its own indexing profile, and changes happen to one family at a time. The default view averages them all and hides the signal. URL prefix properties (or the folder filter on a domain property) let you isolate one family per query.
How to tell
- Total indexed pages dropped 5% or more week-over-week with no obvious deploy.
- A new category or content type was added 2-4 weeks ago and you cannot tell if it is being indexed.
- “Discovered — currently not indexed” or “Crawled — currently not indexed” counts are growing and you do not know which folder.
- A migration moved content between folders and you need to track the old vs new paths separately.
- You publish in two languages and want to know which one is suffering.
Quick verdict
For each major URL family on your site (e.g. /articles/, /en/, /zh/, /tags/, /category/), create either a URL prefix Search Console property or use the URL filter inside the existing property. Read the Pages report once per folder. The folder that moved the most is your suspect; the status that moved most within that folder is your diagnosis.
Setting up folder-level views
Two options. Option A is faster, option B more powerful.
Option A: URL filter inside an existing domain property. Pages > 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 email alerts per folder.
Option B: URL prefix property per folder. Settings > Add property > URL prefix > paste https://yoursite.com/zh/articles/. Verify (usually inherits verification from the domain property). Each prefix gets its own Pages report, performance report, and email alerts. Slightly more setup, much more powerful for ongoing monitoring.
Reading the folder-level Pages 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 with reason: sort by count. The largest reason is your biggest leak.
- Trend over 90 days: a smooth growth curve is healthy. A cliff or step-down marks a deploy date worth investigating.
The most common findings by folder, with their typical cause:
- Tag / category folder shrinking: thin-content algorithm 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. - One language much smaller than the other: hreflang mismatch, or sitemap missing for that language.
A 15-minute debug script
1. Open Search Console, switch to the property covering the suspect folder.
2. Pages > 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 URL examples.
5. Pick 3 URLs with 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 80% of indexing drift in 15 minutes. The other 20% require digging into server logs, sitemap state, or canonical chains — but at least you know which folder.
Tracking changes with a baseline snapshot
The most underused move in Search Console is exporting a snapshot of folder-level counts once a week. Pages report > top-right Export > Google Sheets. Save 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 column for the biggest “not indexed” reason. Update the sheet during a 10-minute Monday morning ritual. The first time a number jumps, you will already have the historical context to debug.
Cross-referencing with sitemap and server logs
The folder view in Search Console answers “what did Google decide.” It does not tell you whether Google ever saw the URL. For that, two sources help.
Sitemap status (Indexing > Sitemaps) shows submission counts per sitemap. If you have a per-folder sitemap (/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 Cloudflare’s analytics) 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.
Common mistakes
- Comparing the global Pages chart across weeks without slicing. Two folders moving in opposite directions cancel out and you see a flat line that hides both problems.
- Forgetting that the Pages report lags 2-3 days. Today’s deploy will not show up until Wednesday.
- Adding a URL prefix property and forgetting to submit a sitemap for it. The property works without one, but submission speeds up the report’s accuracy.
- Filtering by
containswhen you neededexact match./articles/also matches/draft-articles/and inflates the count. - Reading “Crawled — not indexed” as a bug. Sometimes it just means “Google does not think this page is worth indexing yet.” Improve the page, do not just request indexing repeatedly.
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 per-language if you have multiple languages.
- Does adding properties slow down my main property?: No. They are independent views over the same data.
- Can I see canonical issues per folder?: Yes. The “Duplicate, Google chose different canonical” reason is available per folder filter. Use it after a canonical-related deploy.
- What if my folders are not URL-based but query-string-based?: URL filter supports
contains, so?type=articleworks. URL prefix property does not. Use option A for query-string filters. - How long until a new URL prefix property has data?: Usually 2-3 days. The performance data backfills 16 months, the Pages data starts fresh.