SEO for estate agents with multiple branches: area pages that are not just a swapped town name

A good branch or area page for an estate agent differs in substance, not just in the place name: the local property stock and typical price band, the school catchments and transport links buyers actually ask about, recent local market movement you have seen, and a branch-specific valuation call to action. If the page would still read the same after swapping the town name, it is too thin. The fix is property-specific proof that does not transfer between areas, not another templated page with the postcode changed.

Estate agency is where the “swap the town name” test gets brutal, because so much of an agency website is genuinely the same everywhere. The fees are the same. The process – valuation, instruction, viewings, offers, sale agreed – is the same. The reassurances are the same. So when an agent spins up an area page for every village within reach of a branch, the template does most of the work and the only thing that changes is the heading. That is exactly the pattern Google singles out, and it is the pattern that quietly stops ranking.

This page is about what genuinely differs per area for a property business, and why a valuation or instruction goal changes what a good area page needs. It does not re-argue why near-duplicate pages get demoted – that case, with the similarity thresholds and the survivor-page effect, is made in full in our guide to duplicate content on location pages. Read that for the mechanism. Read this for the property substance that beats it.

What does Google actually say about templated area pages?

Two of Google’s spam policies apply directly to an estate agent’s area-page estate, and they are worth reading in Google’s own words rather than in an SEO summary.

The first is doorway abuse. Google’s spam policies documentation (Google Search Central, accessed 7 August 2026) describes doorway abuse as when “sites or pages are created to rank for specific, similar search queries” that “lead users to intermediate pages that are not as useful as the final destination”, and gives as a direct example “having multiple domain names or pages targeted at specific regions or cities that funnel users to one page”. An agency that publishes forty near-identical area pages, each funnelling to the same valuation form, is describing that example almost line for line.

The second is scaled content abuse. The same documentation defines it as the case where “many pages are generated for the primary purpose of manipulating search rankings and not helping users”, and lists “creating multiple sites with the intent of hiding the scaled nature of the content” among the examples. The intent test matters here: a branch page that exists because you genuinely have a branch and genuinely serve that town is not scaled content. Forty area stubs that exist only to catch “[service] in [town]” searches are.

The honest industry shorthand for both, the one you will hear from agents and SEOs alike, is the swap-the-town-name test. If you can change every instance of “Uckfield” to “Lewes” on a page and it still reads as true and complete, the page was never about Uckfield. It was about the template. Google does not penalise you for having a page per town. It demotes pages whose only local content is the town in the title.

Branch page, coverage-area page, or one broad page: which do you need?

Most multi-branch agents conflate three different page types and then wonder why half of them never rank. They are not interchangeable. Pick the wrong one and you either create thin pages with nothing to say or bury a real branch inside a generic county page. Here is the distinction, front-loaded so you can lift it:

• Branch page – for a town where you have a physical office. It carries a real street address, a branch phone number, opening hours, the named people who work there, and LocalBusiness schema that mirrors that address. There is one per office and it is the strongest local page you own.
• Coverage-area page – for a town you serve from a nearby branch but where you have no office. It must NOT invent a street address or a local phone number. It describes the property in that area honestly and routes to the real branch that covers it. This is where the swap-the-town-name failure happens most, because it is the page with the least built-in substance.
• Single broad page – one “areas we cover” page listing the towns, with a short, true line about each, linking out to the pages that earn their own substance. The right answer when you cannot say anything genuinely distinct about a town yet. Far better than a stub.

How the three compare

Page type	Use when	Address and phone	Schema	Risk if misused
Branch page	You have a physical office in the town	Real branch address and phone	LocalBusiness + Service + areaServed	Low – this is provable and unique
Coverage-area page	You serve the town from a nearby branch, no office there	No invented address or local number – point to the branch	Service + areaServed, NAP of the covering branch	High – thin if it carries no real local property detail
Single broad page	You cannot yet say anything distinct per town	Branch network contacts	Organisation-level only	Low – honest breadth, no stubs

The most common mistake is treating a coverage-area page as a branch page: giving it a fake-feeling local number, claiming a presence you do not have, and inventing per-area NAP that schema validators and buyers both see through. Never put an address or phone number in schema that does not match a real, visible office. For why areaServed and NAP must mirror the visible text exactly, see our guide on service-area pages and the broader question of how many location pages you can actually support.

What must genuinely differ on an estate agent area page?

This is the part that does not transfer between towns, and it is what separates a real area page from a name-swap stub. Property gives you more non-transferable material than almost any other local trade, so there is no excuse for thin. A good area page for a branch or coverage town should be able to answer most of these in specifics a rival agent could not lift wholesale:

• Local property stock and typical price band – what actually sells here. Victorian terraces and converted flats near the station, or detached family houses with gardens further out. A typical two-bed and a typical four-bed price band, stated as a range, with the month you are quoting it. Uckfield and Lewes are eight miles apart and have visibly different stock and price points – a buyer knows it, so the page should too.
• School catchments parents actually ask about – the named primaries and secondaries that move offers in this town, and the honest note that catchments shift year to year so buyers should confirm with the local authority. Catchments are the single most location-specific thing buyers raise, and they are completely non-transferable.
• Transport links that matter to this town’s buyers – the specific station, the realistic commute to the places people here commute to, the road that floods, the bus that does not run on Sundays. Generic “great transport links” is the tell of a stub.
• Recent local market movement you have observed – not a fabricated statistic, but what your branch has actually seen. Time to offer lengthening on three-beds, more chain-free buyers this quarter, a particular street selling above asking. First-hand observation is the clearest signal that a real agent wrote the page, and it is impossible to template.
• Branch contact and a branch-specific valuation call to action – which office covers this town, who to ask for, and a valuation request that names the area. The CTA is part of the substance, not decoration, for reasons covered next.

None of this needs to be invented. Every one of these points is something your negotiators already know and say on the phone every day. The job of the page is to write it down honestly per area, which is also why a tool that lets you generate whole paragraphs from nothing is the wrong tool. If you want a town-by-town checklist of what a strong page should carry before it goes live, our local landing page checklist sets the bar. More on the engine’s role below.

Why does a valuation CTA change what a good area page needs?

Compare two local pages. A boiler-repair firm’s town page serves someone with no heating in January who wants a phone number above the fold and a promise that someone can come today. The job is urgent and the decision is fast, so the page can be short. An estate agent’s area page serves someone deciding who to trust with the largest sale of their life, weeks or months before they instruct anyone. That difference changes the page.

A valuation or instruction goal is high-consideration. The visitor is comparing agents on local knowledge and credibility, not on who picks up first. So an area page whose only job is to surface a phone number fails the same way a stub fails: it gives a high-trust decision a low-trust page. The valuation CTA earns its click off the back of the property substance above it. Demonstrate that you know this town’s stock, catchments and recent movement, and the “request a valuation in Uckfield” button reads as a natural next step. Lead with the button on an empty page and it reads as a doorway.

This is why the tradesperson templates that circulate for service-area SEO do not port cleanly to agency. The emergency-call page is allowed to be lean because the intent is urgent. The valuation page is not, because the intent is deliberate. If you have come from advice written for local SEO for tradespeople, keep the structure but raise the substance bar: an instruction is worth more and the buyer is more careful, so the page has to carry more genuine local proof before the CTA does any work.

What does the Townsmith quality score do with a name-swap stub?

The Townsmith Local Pages Engine is a WordPress plugin that builds real, editable location pages, scores each one from 0 to 100, and holds back the thin ones before they publish. It runs entirely on your own server. The free engine has no AI and makes no external calls – the scoring is plain server-side analysis of the page you have, not a model writing pages for you.

Here is what that looks like for an estate agent. Suppose you draft a coverage-area page for a second town by duplicating your branch page and changing “Uckfield” to “Crowborough” in the heading and intro. The body still describes Uckfield’s stock, Uckfield’s station and Uckfield’s schools. Two things happen. The Safety Check, which gives an advisory portfolio-level read on doorway risk, flags the new page as near-identical to its sibling, and Twin Finder shows you which existing page it most resembles so you can see the overlap rather than guess at it. The quality score then refuses to clear it for publishing, because there is no Crowborough-specific stock, no Crowborough catchment, no Crowborough market observation and no branch-specific reason for the page to exist. You get told what is missing, not a green light on a stub.

The Safety Check is advisory: it is our read on doorway and scaled-content risk across your portfolio, not a guarantee from Google. Nothing any plugin does can guarantee a ranking or guarantee compliance – that decision is always Google’s. What the engine does is stop you from shipping the page that fails the swap-the-town-name test, and tell you the specific local facts it wants before it will publish.

To fill those gaps, the engine works from facts you provide. The free plugin holds the page back and tells you what is thin. The paid Pro add-on adds an optional content assistant that is off by default and is built to assist, not generate: it only uses the local facts you type in, it never invents a price band or a catchment, and it never publishes anything for you. It is a way to phrase the Crowborough detail you already know, not a way to manufacture detail you do not have. If a tool offers to write the whole area page for you from the town name alone, it is building the exact doorway estate Google demotes.

How should the schema match the page?

Match every schema value to what a visitor can see. For a branch page where you have a real office, the engine emits LocalBusiness with the branch’s real address and phone, plus Service and areaServed describing the towns that branch covers, and a BreadcrumbList. For a coverage-area page with no office in the town, it emits Service and areaServed and uses the covering branch’s NAP – never an invented per-area address or number. The areaServed in the markup must mirror the service-area text on the page exactly. For the full pattern and worked examples, see the local business schema guide.

Two things to leave out. Do not add your own Review or AggregateRating markup to win stars – Google has not shown self-serving review stars in organic results since 2019, and the markup only invites a structured-data manual action. Genuine review stars come from third-party platforms and from Product markup, not from your own page marking up its own reviews. And do not add FAQPage markup expecting a rich result: FAQ rich results were removed from Google Search in 2026 (Google Search Central, May 2026). Keep FAQ-style content as plain on-page text – it still helps readers and AI engines extract answers, it just no longer produces a SERP feature.

Townsmith sits alongside your SEO plugin rather than replacing it. Rank Math, Yoast, AIOSEO or SEOPress own your base schema graph and meta. The engine adds the location-page schema and defers to whichever plugin you run.

What order should a multi-branch agency build its pages in?

If you are starting from a set of thin area pages, or from nothing, this order avoids both the stub problem and the bulk-publishing spike that itself reads as scaled content:

1. Write a real branch page for each physical office first. These are your strongest, most defensible pages and they anchor everything else.
2. For every other town, ask the swap-the-town-name question before you write. If you can say something true and specific about its stock, catchments, transport and recent movement, write a coverage-area page – our guide to writing a service-area page for a new town walks through doing this without slipping into a stub. If you cannot yet, list the town on a single “areas we cover” page instead.
3. Publish in small batches, not all at once, and check Search Console index coverage on each batch before adding the next. A page-per-town spike that lands in a single week looks like exactly the scaled pattern you are trying to avoid.
4. Link the pages sensibly: each coverage-area page to its covering branch, branch pages to the towns they cover, and the broad page to both. See near-me searches for local businesses for how this maps to how buyers actually search.
5. Let the quality score gate the whole set. If it holds a page back, the page is not ready – add the missing local substance rather than overriding the hold.

Common questions

Is a separate page for every village within reach of a branch a bad idea?

Only if the pages are stubs. A page for a village you genuinely serve, with that village’s real property stock, catchments and market detail, is fine and useful. A page that exists only to catch “estate agent in [village]” with the town name swapped into a template is a doorway. The deciding factor is whether you can say something true and specific about that village, not how many pages you publish.

Can I put a local phone number on a coverage-area page where I have no office?

No. Put the real phone number of the branch that covers that town, and be honest that the office is in the neighbouring town. Inventing a per-area number that rings the same branch is the kind of fabricated NAP that schema validators flag and that erodes trust with buyers who notice. Your branch page carries the real address and number; the coverage page borrows the branch’s, visibly.

Does the free Townsmith plugin write the area pages for me?

No. The free plugin has no AI and makes no external calls. It builds the real, editable page structure, scores it, holds back the thin ones, and outputs schema – all on your own server. The optional content assistant is part of the paid Pro add-on, is off by default, and assists rather than generates: it only phrases facts you type in and never invents specifics or publishes. There is no version of Townsmith that conjures a town’s property detail out of the town name.

If my area pages are near-duplicates now, what happens?

Google tends to collapse near-duplicate pages together and keep one survivor while quietly deprioritising the rest, so the symptom is usually lost visibility rather than a manual penalty. The full mechanism, the similarity thresholds and what to do about an existing estate are covered in our guide to duplicate content on location pages. The short version: add genuine per-area substance to the pages worth keeping, and consolidate the ones that have nothing distinct to say.

Figures and policy references current as of 7 August 2026. Written by Stephen Evans. See how the engine scores and holds back thin pages on the features page.