Why duplicate location pages keep triggering spam updates

Ten pages fell out of search together, in the same week, because they were never really ten pages. Here is what changed, and what came back.

Fabrice Ficerai · 6 min read · Reviewed 2 Sept 2026

Serving the Greater Metro Area with excellence. Written once, published to eleven cities.

The client runs a small service business with a handful of physical locations, and, like a lot of multi-location sites, had one page per city. In effect, ten duplicate location pages: same layout, same three paragraphs, same list of services, with the city and postcode swapped in each time. It is the fastest way to get a location page live, and for years it was good enough to rank.

In the third week of July, all ten pages fell out of search together. Not one, not gradually. The same week, the same shape.

That is the signature to look for. A single page losing rankings is usually about that page, or that page's backlinks, or a competitor outranking it. Ten pages falling in the same week, by the same amount, is a pattern applied to the group, not a verdict on any one of them.

What a spam update is actually built to catch

Worth naming precisely, because "a spam update in July" undersells what happened. Google's confirmed spam update that cycle rolled out on 24 June 2026. On this site the effect did not show up in Search Console until the back half of July, which is normal: a spam-focused update typically takes two to four weeks to fully settle across the index, so a site can feel it weeks after the date on the announcement.

What it is built to catch, structurally, is scaled, near-duplicate content: many pages that exist to rank for many keyword variants rather than to say something a reader could not get from any of the other pages. A location-page template with the city swapped in is close to the textbook case. It is not spam in the sense of being deceptive. It is spam in the sense of being the same page, published repeatedly, and that is the exact shape recent spam updates have targeted.

What actually changed on each page

Nothing about the layout changed. What changed was whether the words on the page could have been written about a different office without anyone noticing, the same discipline behind how I approach page content generally, not something specific to location pages.

None of it is clever. All of it is the kind of detail a template structurally cannot contain, because a template is written once and a location is not.

Asking Google to look again

After the rewrite, each page was resubmitted through Search Console's URL Inspection tool and requested for indexing. Worth being precise about what that does, because it is not what people assume: it asks Google to recrawl the page sooner than it otherwise would. It does not change how the page is ranked. If the rewrite had not been enough, faster recrawling would just have shown that faster.

What came back, and what I cannot claim

Impressions across the ten pages went from under 6 a week to around 120 within a handful of weeks of the rewrite going live. That is a real recovery, and it is close to, not fully back to, the 180-a-week peak the pages had reached in early July.

One site, one change, one recovery. That is a case, not a proof.

Two things I cannot rule out, and would rather say than let the chart imply more than it shows. The recovery lands inside the same window a spam update typically continues settling in, so some of it could be the algorithm's own tail rather than purely the rewrite. And requesting indexing changes when Google looked, which makes it hard to separate "the content fixed it" from "Google would have re-evaluated these pages eventually and I just asked it to happen sooner." Both are probably true at once, in proportions I do not have a way to measure from one client.

What I would still stand behind: pages that read as the same page published under different names are a known, named target, not a hypothetical risk, and the fix for that is specific enough that it cannot be templated back into the problem it solved.

It is the same instinct behind reading a client's own numbers straight rather than taking a dashboard's word for it, which is the other piece here.