Programmatic city pages: noindex the thin ones or let Google sort them out?

Say a home services site has about 400 city-plus-service pages built from one template, and most of them get almost no impressions in Search Console. The "index everything and let Google decide" crowd would leave them all up. I'd noindex any page without unique local content, meaning real reviews, local pricing, or a service area that's genuinely different, and keep the handful that have real detail. Thin near-duplicates spread crawl attention thin and make the whole site look weaker.

I don't buy the idea that cutting pages will hurt the rest, though. Site-level quality seems tied more to the share of useful pages than to the raw count, but I'm not certain of that. Has anyone measured a before and after cleanup, especially on pages that were already getting some clicks?

I don't buy the crawl attention argument. At 400 URLs, crawl budget is rarely what limits a normal site, so thin sibling pages aren't really starving the good ones. The better question is demand. Almost no impressions for "plumber [city]" can mean the page is weak, or it can mean hardly anyone searches that exact phrase in that town. Pull search volume for the city-plus-service terms before you decide anything. If most show near-zero volume, noindexing just tidies up pages nobody would find anyway. If the volume is there and the pages still get nothing, the thin content is the real problem and noindex is a band-aid. Those two cases need different fixes, so it's worth knowing which one you're in before cutting anything.

Agreed on the demand check, but keyword volume for "plumber [city]" can undercount. A lot of local demand comes in as "plumber near me" or as nearby towns, and Keyword Planner doesn't always break those out cleanly. So a page can show near-zero exact-match volume and still be the one Google serves for real searches in its area.

Before deciding, pull the Search Console performance report filtered to each page, with the query dimension open, over the full 16 months. You'll often find the page is matching a different phrasing or a neighbouring town, which tells you whether it has a real audience or is just a template. Pages that show up for a cluster of related queries are worth keeping. Pages that only ever appear for one odd query with a single impression are the safe noindex candidates.

Search Console also hides a lot of low-volume queries for privacy, so a page that seems to get only one odd query may be getting more traffic than the report shows. Export the page and query data before you noindex anything, because once those pages are gone they drop out of the report.

You can measure how much is hidden. On a single URL, the page total in the performance report includes anonymized queries, but the query rows don't. Add up the clicks in the query table and compare that to the page total, and the difference is traffic from queries Google won't name. On a thin template page that gap can be bigger than all the visible rows combined, which is exactly when "one odd query" misleads you.

The UI export also caps at 1,000 rows, so for 400 city pages you'd want to pull the data through the API, filtered by page and paginated. Otherwise you end up trimming data without noticing. Save it with dates too, since the history disappears once the pages leave the index.

I don't think the history disappears when pages drop out of the index. Search Console keeps performance data for 16 months at the property level, and a URL that stops getting impressions just shows no rows. Noindexing doesn't delete anything.

The real clock is that rolling 16-month window. If you want a longer baseline for the before-and-after comparison, pull the data while the older months still exist and keep the export as a backup. Saving it is still worth doing, just for that reason and not because the pages vanish from the report.

Yeah, the 16-month window is the real constraint. Two things that bite people with the export: the API caps out at 25,000 rows per request, so with 400 pages plus the query dimension you need startRow paging, or you'll get a truncated export with no error at all. And the last few days of data are still settling, so end your "before" period a few days short of the cleanup date. Otherwise re-pulling the same range later gives slightly different numbers and the comparison gets murky.

Honestly, it depends on what else changes in that window. If you noindex 400 pages and also rewrite the core service pages or add internal links that month, a before-and-after can't isolate the cleanup. Either pick a period where nothing else moves, or hold back a comparable set of city pages as a control.

Agreed on the control, but I'd make the split random rather than hand-picked. If you choose the 200 weakest-looking city pages to noindex, they'll probably look better afterwards no matter what you did. The bottom of any distribution tends to drift back toward average on its own, so regression to the mean will make the cleanup look like it worked. A random split avoids that because both groups start out as the same kind of page.

My rule of thumb is to assign candidates to cut or keep by coin flip (or a random number column in the sheet), within the same template and the same date window, and only compare the groups over identical periods. It's crude, but it stops you from crediting the cleanup for a trend that was coming anyway.