How to Write City-Based Local Service Pages

Scroll down to the footer of almost any service business website and you will find a box called "Areas We Serve" with dozens of district names listed one under the other. You click the link for Kadıköy — a large district on the Asian side of Istanbul — and this is what comes up: "If you are looking for a dental clinic in Kadıköy, you have come to the right place. In Kadıköy we serve our patients with modern equipment and an experienced team." You go back and click Ataşehir. The same sentence, one word swapped: "If you are looking for a dental clinic in Ataşehir, you have come to the right place." Üsküdar reads the same. So does Maltepe — all of them Istanbul districts, all of them the same page. Scroll further down and you meet the same three bullet points, the same "Why choose us?" heading, the same contact form.

None of these pages tells you the address in that district, which line gets you there, the name of the dentist who actually works at that branch, or the question patients from that neighbourhood ask most often. The only thing that changes is a proper noun; the rest is stamped out of a mould. It is cheap to produce: one spreadsheet, one template, one afternoon. The catch is that both classical search and language models are now perfectly capable of noticing that cheapness.

Why the template page does not work

The first reason is simple: these pages are copies of one another. Search engines reduce clusters of near-identical pages to a single representative page; they crawl the rest but keep them out of the index. In Search Console this shows up as "Duplicate, submitted URL not selected as canonical" or "Crawled - currently not indexed". So even if you have opened forty district pages, one single page usually represents you in the results — and you are not the one who decides which one it is.

The second reason has a name in Google's own spam policies: the doorway page. The definition covers sets of pages produced for minor variations of the same query, with no function other than funnelling the user to the same destination. Service pages multiplied by swapping out the city name are the textbook example. The risk here is not only failing to rank; it is dragging down the quality assessment of the whole site.

The third reason sits on the AI side and is becoming more decisive. When a language model answers "is there a dental clinic in Kadıköy open after 7pm?", it looks in the source page for a fact it can quote: an address, an hour, a practitioner's name, a condition. The template page holds none of those facts; it holds adjectives. Adjectives cannot be quoted. In the model's view all forty of your pages sit at the same semantic point; none of them carries information that tells it apart from the others, so none of them gives a reason to enter the answer. We looked at the wider frame of this distinction in the difference between local SEO and GEO.

To be straight about it: this site also published template-generated articles for a while, and every one of them later had to be rewritten from scratch. The mould costs more to pay back than it ever cost to produce.

Six kinds of information that make a city page unique

A city page earns its existence by carrying information that appears on no other page about that city. In practice that information falls under six headings.

A real address and how to get there. Street, building, floor; the nearest metro or metrobus stop; whether there is parking and, if not, where people park. The sentence "in central Kadıköy, walking distance from Söğütlüçeşme station" — Söğütlüçeşme being one of the city's main rail and bus interchanges — does more work than ten paragraphs of "quality service", because it can be verified and it can be quoted.

The team at that location. Who works there, and in what speciality. Writing names and titles is the fastest way to make a page impossible to copy; a template generator cannot fill this field, because every city requires a different fact.

Local price and condition differences. If something varies by region, write it down: different payment options, a different appointment load, a device or a service available only at that branch. If there is no difference, do not invent one; "our prices are the same at every branch" is information too.

Questions specific to that city. In real estate, zoning status and urban renewal areas change from district to district; in accountancy, the tax office you report to and the chambers you belong to change by city; in healthcare, the insurers a branch has agreements with change by branch. Asking your front desk "what do callers from this area ask about most?" is the most productive content research there is. The logic in local visibility for real estate agencies applies here one to one.

Local references. Work completed in that city, the institutions you have worked with, the local chamber or association you belong to. Even when a client's name cannot be shared, describing the type of work at neighbourhood level is still possible.

Opening hours and access. Hours specific to that branch, holiday closures, the phone number that belongs to that location. Stamping the same number onto forty pages is the most visible sign that the pages cannot be told apart.

If you cannot fill at least four of these six headings with real data, do not open a separate page for that city.

How many pages should you open?

The distinction is this: the places you actually serve and the places you would like to target are not the same thing. If you have an office, a team, a warehouse, a field vehicle or completed work in an area, you have material for a page. "We would like to find customers there too" is a wish; it is not enough to produce a page.

A practical threshold: one page for every city or district where you have a physical presence, plus a single "service areas" page — not one page each — for the neighbouring regions you work in regularly. Three full pages perform better than forty empty ones in both search results and AI answers; forty empty pages also spread your crawl budget and your own internal link equity thin.

If you are moving into a new region, ranking starts with doing work there, not with publishing a page. First a reference, then a page.

For courses, schools and language academies, we described how these pages are built around programmes as well as locations in GEO for educational institutions.

The page skeleton

The skeleton below can be used as it stands, but the fields marked [BY HAND] cannot be generated from a template; they have to be written separately for every city. If you do not have real information to fill a field with, do not leave the section empty — do not open the page at all.

• Title (H1): Service plus city. One line, can be generated automatically.
• Opening paragraph — [BY HAND]: The location, who is served, and one sentence specific to that area. A template opening sentence does more damage here than anywhere else on the page.
• Address and directions block — [BY HAND]: Full address, nearest stop, parking, map link.
• The team at this location — [BY HAND]: Name, title, and a photo where there is one.
• Service list: A short list linking to the main service pages. Shared copy is fine here; the full description of a service belongs on the service page, not on the city page.
• Conditions specific to this area — [BY HAND]: Tax office, zoning status, insurer agreements, seasonal load — it varies by sector.
• Local work or references — [BY HAND]: A concrete example, even at neighbourhood level.
• Opening hours and contact — [BY HAND]: The hours and the phone number that belong to this location.
• FAQ — [BY HAND]: Real questions from that city, not a copy of the general service FAQ.
• Closing and a single call to action: An appointment, a quote or a call. Instead of pasting the form onto every page, leave one clear step.

The technical side of the page — title tag, canonical, speed, mobile layout — has to meet the same standard as your service pages; the GEO-ready website infrastructure guide for small businesses covers that part in detail. The template and information architecture those city pages sit on are settled during a corporate website build.

Structured data: LocalBusiness and areaServed

The machine-readable counterpart of a city page is the LocalBusiness schema, or one of its subtypes such as Dentist, LegalService or RealEstateAgent. If you have a physical location, these are the fields to fill: name, address (as a PostalAddress, street and postal code included), telephone, openingHoursSpecification, geo, url, and an @id unique to the page.

Two things to watch. First, every physical branch is a separate entity; giving all of them the same @id and the same address makes the schema meaningless. Each branch page has to carry its own @id value and connect back to the head organisation through parentOrganization or branchOf.

Second, and more important: if you have no physical location in that city, do not write LocalBusiness. If you work remotely or in the field, the correct structure is the areaServed field on Service; areaServed is given as a City or an AdministrativeArea and carries no claim that you have an office there. The rule is that the schema must not contradict what is visible on the page: writing an address into the schema that does not appear on the page turns structured data from a trust signal into a source of risk. We went through the relationship between schema and credibility signals in detail in schema markup and E-E-A-T.

Internal linking and cannibalisation

City pages can eat each other from two directions. The first is among themselves: when title tags and content resemble one another too closely, which page turns up for a generic query like "dental clinic" moves out of your control and shifts from one period to the next. The second is against the main service page: if the city page re-explains the whole service, it starts trying to take the service page's place.

The arrangement that works is this: the main service page explains the service and targets the generic queries; the city page explains the location, does not explain the service, and links to the service page. Do not build horizontal links between city pages — a link from the Kadıköy page to the Ataşehir page means nothing to a user. Build a hub page that lists every city page instead, and return to that hub from each city page. Set the breadcrumb (BreadcrumbList) structure up along the same hierarchy.

Separate the title tags as well: forty titles that differ only in the city name lower both the click-through rate and how distinguishable the pages are. Draw the differentiator from the real information the page carries, not from the city name itself.

Measurement: deciding which page to close

Once the city pages are live, the decision should belong to the data, not to you. Wait at least one quarter — roughly three months — then check three things for every URL in Search Console: is it indexed, which queries is it shown for, is it getting clicks. Add on-site behaviour to that: does a user who lands on the page move on to a search, a form or a phone step.

The picture that comes out usually produces three buckets. Pages that are indexed and shown for queries about their own city stay; where they are thin, fill them in with the six kinds of information. Pages that are indexed but shown only for your brand name probably carry no local information at all; they either get filled in or get closed. Pages that were never indexed, or were marked "duplicate", are already invisible: merging them into the nearest real location page with a 301 lightens the site and collects the signal of the pages that remain.

For the AI side, run a manual check as well: type your own city query into a chat interface and look at which sources the answer shows. If a directory site comes up instead of your page, what is missing is not ranking but quotable information. We collected the mistakes that keep recurring when writing content for AI in this article.

One of the fields where the need for city pages runs heaviest is real estate; we described the sector-specific setup on our estate agencies solution page.

Closing a page is not a sign of failure; it is the natural result of measuring. A site that starts with forty pages and keeps six ends up both faster and more visible than a site that leaves all forty where they are.

Frequently Asked Questions

Does Google penalise you for publishing city-based service pages?

The city page itself is not the problem; pages that describe a real location or a real service area are an ordinary part of search. The problem is multiplying the same text by changing the city name. Google names that pattern in its spam policies as a doorway page. A small number of pages, each written by hand and each carrying distinguishing information, stays on the safe side; hundreds of pages stamped from a mould do not get indexed and drag the overall quality assessment of the site down with them.

Can I publish a page for a district where I work but have no office?

You can, but the page must not give the impression that you have an office there. Inventing an address, presenting a virtual office address as a real branch, or writing LocalBusiness schema for that district is a false statement. The right approach is to say plainly that it is a service area and to use the areaServed field under the Service type in your structured data. The page still has to be filled with real information specific to that area — work you have done there, travel time, conditions particular to the region.

How many city pages do I need?

Setting a number as the target is the wrong starting point. The criterion is this: if you can fill in at least four of the items — real address, team, local conditions, references, opening hours — for a given city, that page gets published. If you cannot, it does not. For most small and medium-sized businesses that comes out somewhere between three and ten pages. The remaining regions can be listed on a single "areas we serve" page.

What should I do if the city page and the main service page collide on the same query?

First confirm which page is being shown for which query, using the query and page breakdown in Search Console. Generic service queries should be answered by the main service page, and queries containing a city name by the city page. Where they collide, the fix is usually a content split: take the service description off the city page and link to the service page instead, leaving only location-specific information on the city page. Separate the title tags clearly from one another as well.

How do I tell whether my city page appears in AI answers?

There is no direct report for this; it takes a manual check. Type your own city and service queries into different chat interfaces, look at which sources are given as links in the generated answer, and repeat this at regular intervals. Your server logs will also show you whether AI crawlers are fetching the relevant URLs. If your page is being fetched but does not appear in the answer, what is missing is not accessibility but concrete, quotable information.