LOCATION PAGES THAT AREN'T DOORWAY PAGES

This step exists mostly to give you permission not to build the page, which is the most valuable thing in the guide and the hardest to accept when someone has told you more pages means more traffic.

Three questions. All three need a yes:

1. Do you actually serve this city? Not would you like to. Would you drive there on a Tuesday for a normal job at a normal price. If the honest answer is that you'd go for a big enough job, that's a no.
2. Have you worked there? At least one real job, or a genuine plan to get one. A page for a city you've never worked in has nothing true to say and you'll feel it by paragraph two.
3. Can you say something specific? Before writing, can you name one thing about working there that differs from your home city. If nothing comes, that's information, not a temporary block.

Two yes answers and a maybe means the honest move is a regional page covering the wider area, naming the city inside it where that's true. One good regional page beats four thin municipal ones, and it's far easier to keep accurate.

The bar is five things that are true of this city and false of the next one on your list. Five is deliberate. One or two can be padded around; five forces you to actually know the place.

Facts that travel are useless here. Fast response times, free quotes and fully insured are true everywhere, which is why they appear on every page and differentiate none of them. Look in four places:

• The housing stock. Age, style, roofline, lot size, how tight the driveways are. This is the richest source for most trades, because it changes the job itself rather than the marketing.
• The conditions. Tree cover, exposure, drainage, what the winter does to that specific area. Anything that changes what you carry in the van.
• The competitive picture. Search your main phrase plus the city in a private window and look at who's there. National directories mean an opening; three strong local firms mean you need a sharper angle.
• The practical friction. Permit rules, parking, access, the drive itself. Naming a real constraint reads as experience because it is.

Write them as sentences, not keywords. A note reading mature trees isn't usable; older streets are full of forty-year maples, so gutters there fill twice a season instead of once is a sentence that can go straight in the page.

Facts describe the place. Proof shows you were in it. A page can have all five facts and still read like research rather than experience, and proof is what closes that gap.

One genuine item is enough. In rough order of strength:

• A job you did there, described specifically: the street or neighbourhood, the problem, what you did about it.
• A photo of your own work in that city. Not a stock image, and not the same photo as the sibling page.
• A review from a customer in that area, quoted with the neighbourhood named.
• A named area you regularly work in, if you can't share job detail. Weakest of the four, but still specific.

Say the true thing in the true way. One job in the city means writing about that one job, not implying a decade. A single honest example outweighs a page hinting at volume it can't show, and it survives a customer asking about it.

Open your nearest existing location page beside the new one and work on the headings alone. They're the skeleton, they're what a skim-reader and a crawler both take first, and they're where templating is most obvious.

The rule: if swapping the city name makes your headings identical to the sibling's, they aren't headings, they're a template.

Generic headings look like Our Services in Oakville, Why Choose Us, Areas We Serve. Every one works for any city and any company. Specific headings come out of your step 2 facts and are unmistakably about somewhere.

The H1 is worth its own minute. Name the service and the place plainly, because that's what the page is, and let the H2s underneath carry the differentiation. Don't make the H1 clever. Make it accurate.

Five facts don't make a page. A page needs a spine, and the spine is one angle: the single reason this page exists that the sibling pages can't claim.

Pick the fact from step 2 that most changes the job, and build around it. Everything else supports it. This is the difference between a page with local details sprinkled through it and a page that's genuinely about a place.

In the worked example, Oakville's angle is the tree canopy on older streets, so the page is about seasonal load, guard choice and a twice-a-year schedule. Milton is new-build subdivisions with young trees, so its page is about builder-grade installs, downspout placement and capacity. Same company, same service, two pages with almost nothing in common, because the work genuinely differs.

Keep the standard material, but keep it short. Pricing, service list, contact and coverage all still belong on the page. They aren't what it's about, and they shouldn't be the first three sections.

The FAQ block is where templating survives longest, because it feels like boilerplate by nature. It's also the part most likely to be read, and increasingly the part quoted back by an assistant, so sameness here's expensive.

Don't take the same five questions and insert the city. Ask what somebody in this city actually wants to know, which usually comes straight out of your step 2 facts: how often the job is needed there, what the local housing stock changes about it, what the access or permit situation is, whether you charge differently for the drive.

Then mirror them exactly in FAQPage JSON-LD. The visible text and the schema text must match word for word, because a mismatch is a structured data problem rather than a clever one. The schema guide covers the markup mechanics if that part is new.

One honest note on rich results: FAQ rich results were cut back to government and health sites, so on a local business page the markup is for parsing rather than for a visible result in Google. Add it because assistants and other consumers read it, not because it will draw a rich snippet, and don't let anyone tell you otherwise.

Short step, and the least likely to go wrong, but skipping it wastes the two hours you just spent.

1. URL. Put the service and the location in the path, like /eavestrough-cleaning/oakville. A bare /oakville doesn't say what the page is and stops scaling the moment you add a second service. Keep the pattern identical across the set.
2. Canonical. Self-referencing, pointing at this page. Sibling pages canonicalising to each other is a real and self-inflicted way to make a good page invisible.
3. Schema. Service with areaServed naming the city, plus your FAQPage from step 6. The artifact below is the shape.
4. Internal links, both directions. Link down from the parent service page, and sideways between siblings. A location page nobody links to is exactly the orphan structure the doorway policy describes.
5. Title and meta description. Written for this page, not generated from a pattern. If your descriptions differ only by city, that's the same problem in miniature.

The last gate, it takes five minutes, and it's the one step that would have prevented most of the thin location pages on the web.

1. Copy the finished page into a plain text document.
2. Find every instance of the city name and replace it with the sibling city.
3. Read it as though it were the real page for that city.

Every sentence that's still true isn't local content. That's the whole test. It doesn't mean the sentence is bad, since pricing and contact details are supposed to travel, but those sentences aren't why the page deserves to exist.

Then count. If the majority of the body survives the swap intact, you have written a template. If the page now reads as obviously wrong, with claims about tree cover that don't apply and a job description that doesn't match the housing, the page is genuinely about somewhere and you can publish it.

Do this before publishing, not after. Fixing a thin page that's already indexed means editing it, waiting for a recrawl, and wondering for weeks whether it recovered. Five minutes now avoids all of that.