Skip to main content
← All news

July 15, 2026

37 Towns, Zero Doorway Pages: How We Engineered a Service-Area Site

City pages are not doorway spam. Thin, interchangeable ones are. The test is whether each page has its own reason to exist. We shipped a 37-town service-area architecture for batsandwildlife.ca, a brand we built. It is 41 towns today — the gate has let four more through since. A town got a page only if the business genuinely served it and the page could say something true and specific about that town.

Are city landing pages doorway pages?

Google's doorway definition has nothing to do with templates. It describes pages that exist only to catch a query and shovel the visitor somewhere else — no independent value, no reason a human would want to land there.

A city page fails that test when:

  • The body is one paragraph with the town name swapped in.
  • The business does not actually work in that town.
  • The "local" detail is a population figure and a Wikipedia founding date.

None of those are templating problems. They are truth problems. The doorway failure is pretending forty pages are unique when they are one page in forty costumes — and readers spot it faster than crawlers do.

The way out is the opposite of what most agencies sell: be honest about which parts are the same. Local sections genuinely local, shared sections openly shared. That page is not a doorway. It is a service-area page.

How many location pages is too many?

There is no number. There are two supplies, and the smaller one sets your cap.

  1. Service supply. How far a crew will actually drive, on a Tuesday, for a normal job. Not the map circle on your About page — the real one.
  2. Knowledge supply. How many towns you can describe in specifics a competitor could not copy without going there.

Most home-service businesses have plenty of the first and almost none of the second. That is why 200-page "programmatic local SEO" packages read like a mail merge: the service supply justified them, the knowledge supply never existed.

Thirty-seven was an output, not a target. We started with a candidate list across four Ontario counties — and, as it turned out, one town in a fifth — ran every candidate through a gate, and 37 came out the other side. It is 41 now. The number is a result, not a plan. Publishing the towns that failed would have made the site bigger and the architecture worse.

Which towns should get a page — and which should not

Three gates. A town had to clear all three or it did not get a URL.

  1. Does the business genuinely serve it? Every town record carries a real drive time from base. If nobody would take the call, the town is not a service area — it is a wish.
  2. Can the page say something true and specific? It needs local species behaviour, local housing stock, local seasonality, local access conditions. If the only honest sentence is "we also serve here," that is a list entry, not a page.
  3. Is the demand distinct? People have to search the town by name. Hamlets that locals file under the next town over get folded into that town's page instead of splitting it.

One judgment call is worth stealing. Grand Bend sits in Lambton, outside the four target counties. Geographically it broke the pattern. Locally, everyone thinks of it as the same shoreline. It ships inside the Huron hub — which is why that hub is labelled Huron County & South Lake Huron Shore rather than just Huron — with a comment in the code explaining why, because the reader's mental map beats the surveyor's.

The list only grows when a new town passes the same gate. That is the whole discipline: the gate does not loosen because the sitemap looks short.

How do you avoid duplicate content across town pages?

You do not avoid it — you localize the sections that can be local and stop pretending about the rest. Google does not penalize shared boilerplate across your own service-area pages; it discounts it. The risk was never duplication. It is thinness.

Every town is one typed record in a data file, and the interface documents the contract field by field — including the target word count for each local section — so "local" is not left to a writer's memory at 4 p.m. on a Friday. Here is the split, plainly.

SectionPer-town or sharedWhy
Intro under the H1Per-town (80–120 words)Geography, landmarks, which neighbourhoods actually call.
Common problems herePer-town (150–200 words)Species mix and colony patterns genuinely differ by town.
Homes and constructionPer-town (100–150 words)Heritage core vs. post-war vs. new subdivision changes the job.
Seasonal patternsPer-town (80–120 words)Lake-effect towns run weeks behind inland ones.
Neighbourhoods servedPer-town, optionalOnly where sub-areas exist and matter. Otherwise omitted.
What drives cost herePer-town (80–100 words)Access, roof pitch, entry-point count. Drivers only — no figures.
How the work is doneShared, identicalThe method is the method. Rewriting it once per town would be lying.
FAQ blockShared, identicalThe questions genuinely do not change by town.
CTA and trust barShared, templatedConversion furniture. Nobody expects it to be bespoke.

Five sections are per-town, and together they carry most of the body copy on the page. The rest is shared and unashamed. That ratio is the design. Inflating it with spun paragraphs is exactly how a good architecture turns into doorway spam.

Cost is the section most businesses get wrong. The cost section names what changes the number in that town — access, height, envelope complexity — then links out to the quote explainer. No figures on a page where you cannot see the house. Same reason our own Local SEO work is scoped and quoted rather than listed on a price card.

The internal-linking topology (the part nobody publishes)

Forty-odd pages linked badly are a pile. Linked properly, they are an architecture. This is the topology, exactly as it ships.

/                            → /service-areas/
/service-areas/              → county hubs (Grey · Bruce · Simcoe · Huron)
  county hub                 → every town in that county, grouped + counted
/service-areas/owen-sound/   → 2-3 sibling towns  (hand-picked, geographic)
                             → the service page (the method)
                             → 2 supporting posts (timing · cost drivers)
                             → breadcrumb: Home › Service Areas › Town

Four rules make it work:

  • County hubs, not one flat list. The index groups towns by county with live counts. It mirrors how people describe where they live, and it gives crawlers four mid-level entities instead of one wall of forty-odd links.
  • Sibling towns are hand-picked, not alphabetical. Each record names two or three genuine neighbours — the towns a real customer would also consider. Peninsula and shoreline towns get two, because they only have two. Because the picks overlap, the towns form a mesh instead of a star, and no page is left orphaned.
  • Every town links up into the service. The town page describes the town; the service page describes the work. That link is what stops each town page from re-explaining the method — the pressure that forces people into spun duplication in the first place.
  • Depth is capped at two clicks. Home → hub → town. Nothing sits deeper. If a page takes three clicks to reach, it needed a hub you did not build.

The supporting posts matter more than they look. The seasonality section links to a post about timing; the cost section links to a post about what goes into a quote. Those two links turn the town pages into the bottom layer of a real topic cluster. The same shape scales down to a dense market, where the unit is a neighbourhood instead of a town — that variant is in local SEO for home-service businesses in the GTA.

Should every city page have FAQ schema?

No. The FAQ block is visible on every town page. Its structured data is emitted on none of them.

Same questions, same answers, one URL per town — shipping identical FAQPage JSON-LD across all of them is duplicate structured data with nothing to gain, so we do not. The FAQs stay for readers and the schema lives on the single canonical FAQ page. There is a comment in the component explaining the decision, because the next person to touch that file will otherwise "fix" it.

What each town page does emit: an Organization block, a Service block with areaServed set to that town, and a BreadcrumbList that matches the visible breadcrumb exactly. Organization rather than LocalBusiness, because the business has no public street address — that decision has its own post, service-area SEO with no address. Which types actually earn their place is covered in the schema a service business actually needs.

What we are not going to claim in this post

No ranking positions. No traffic curves. No before-and-after percentages.

Not out of modesty — out of the rule we apply to everything we publish: if you cannot verify it in one click, we do not print it.

Here is what you can check right now, yourself:

  • The architecture exists and is public. Open batsandwildlife.ca, walk the service-area index, click into any town, and read the local sections against each other.
  • The build standard is real. Run Lighthouse on a town page, or on thecritterguy.ca or cottagehero.ca. The scores are the receipt.
  • The stack is static — no database, no plugins, nothing to rot or reinfect. Which is also why a business we rescued from a roughly 1,200-page spam infestation now runs on it. We do not name that client, and we never will: discretion in a sensitive situation is worth more than a logo on our page.

These are portfolio builds — brands we build and rank, not brands we own. The rest of the work is on the case studies page.

How to run this for your own service area

The pattern transfers cleanly to HVAC, roofing, plumbing, landscaping, property care, and pest control — any business where the crew drives to the customer.

  1. Gate every candidate before you write a word. List everything inside real drive time, then write one honest paragraph about each from memory or from the crew. If you cannot write it, the town fails. Cut it.
  2. Interview the technicians, not the internet. The specifics that make these pages defensible — which subdivisions have the bad flashing, which shoreline runs three weeks late — live in your crew's heads, not in a keyword tool.
  3. Build hubs, then hand-pick neighbours. County or region hubs the moment you pass about a dozen towns, then two or three geographic neighbours per town, chosen rather than alphabetized. That single step is the difference between a mesh and a pile.
  4. Audit annually. A town you stopped serving keeps its page and quietly becomes a lie. Delete it or fix it.

Steps one and two are where every one of these projects actually dies. There is no tool that skips them.

Want this built for your service area?

If you serve more towns than your site admits to, the fix is an architecture, not more pages. Tell us the towns you actually drive to and what you want to rank for — one form, and a real reply from the people who'll do the work.