Thirty Location Pages, One Page: Fixing Templated Local Content

We had thirty location pages, one per city we serve. They were generated from a template, which is the sensible way to build thirty pages. The problem was what the template varied: the city name, and essentially nothing else.

We found out the hard way. A link on one page had broken text — the words had run together into "Recoverypage" where a space had been lost. We fixed it, then checked the others. It was on all thirty, identically, because it came from a template string every page shared.

That is a small bug. What it revealed was the real issue: if a single string is wrong on thirty pages in exactly the same way, those thirty pages are one page with thirty headings.

Why near-duplicate location pages underperform

Search engines are good at recognising templated variation. Thirty pages differing only in a place name read as what they are, and the usual outcome is that one ranks and the rest are effectively ignored — or all of them are treated as thin and none does well.

More importantly, they are useless to the person reading. Someone searching for a provider in their city wants to know whether you are actually there and what that means for them. "We provide managed IT services in [City]" with the same four paragraphs as every other city answers nothing.

The test is simple and brutal: swap the city name for a different one. Does anything become false? If not, the page contains no local information.

What we changed

Say something only true of that place

For the three cities with a physical office, the pages now carry the actual address, the local phone number, opening hours, and the fact that support runs around the clock for customers while the office itself is staffed during business hours. That is specific, verifiable and useful, and it is false for every other city.

For cities we serve without an office, the honest version is different and should be: how we serve them, response expectations, which office covers the area. Do not imply a presence you do not have — it is the most common failure of location pages, it is the one customers notice, and in some jurisdictions it is a legal problem rather than just a credibility one.

Mark up what is real, and only that

Structured data for a local business should be emitted only where there is a business to describe:

{location.office && (
  <script type="application/ld+json" dangerouslySetInnerHTML={{ __html: JSON.stringify({
    "@context": "https://schema.org",
    "@type": "ProfessionalService",
    name: `intSignal — ${location.city}`,
    address: { "@type": "PostalAddress", streetAddress: office.street, addressLocality: office.city,
               addressRegion: office.region, postalCode: office.postalCode },
    openingHoursSpecification: [{ "@type": "OpeningHoursSpecification",
      dayOfWeek: ["Monday","Tuesday","Wednesday","Thursday","Friday"],
      opens: office.opens, closes: office.closes }],
  }) }} />
)}

Conditional on the office existing. Emitting an address for a city where you have none is misrepresentation, dressed up as markup.

Vary the substance, not the adjectives

The weak fix is spinning sentences — same content, synonyms swapped. That fools nobody and reads badly. The things actually worth varying:

• which services the local team leads with, where that genuinely differs
• the industries concentrated in that area, if you serve them
• regional compliance that applies — state breach-notification rules, sector regulators
• connectivity realities, carrier availability, typical infrastructure in that market
• the office that covers the area and what response from there looks like

If you cannot find three genuinely local things to say about a city, that is useful information: you probably should not have a page for it. Ten strong location pages beat thirty thin ones.

Give each one a real image

Every one of our location pages now shows a photograph of that city. Not stock cityscapes that could be anywhere — the actual place. It is a small signal, and it is one of the few that cannot be templated.

The lint worth adding

The broken link text is the most instructive part of this. It survived because nobody looked at a second location page after checking the first — they were known to be identical, so checking one felt sufficient.

That logic is self-reinforcing and it is how templated content rots. Two cheap guards:

Diff the rendered pages against each other. If two pages in a set are more than ~90% identical after stripping the varying token, flag it in CI. We ran a Jaccard similarity pass over shingled page text and it immediately showed how little varied.

Spot-check a different page each time. When you touch a template, open the third or the seventeenth rendering, not the first. The first is the one that was looked at during development; the others are where templated mistakes live.

What it is reasonable to expect

Location pages are a long game and a modest one. They help when someone is searching with local intent and you genuinely serve that area. They do not conjure demand, and a page for a city you have never worked in will not change that.

The question to ask before creating one is not "can we rank for this city" but "if someone in this city calls us, do we have a real answer about how we serve them?" If yes, the page writes itself and it will be different from the others, because the answer is different. If no, the page will be templated filler no matter how carefully it is worded — because there is nothing specific to say.