NAP on your location pages: how name, address and phone should appear (and when to hide the address)

On a location page, your name and phone should match your Google Business Profile exactly. A service-area business with no public address shows the city or region it serves, not a street address, and never invents a per-area address. Get those two rules right and NAP stops being a thing you worry about.

NAP stands for name, address and phone, the three details a search engine uses to work out which real-world business a page is about. Most advice treats NAP as a citations-and-directories chore: get the same details listed identically on Yell, Yelp and a hundred other sites. That matters, but it is not the question you actually have when you are building pages for a dozen towns. The question is what name, address and phone should appear on the pages themselves, and what a service-area business with no shopfront is supposed to put where the address would go. This guide answers that.

The rule in one line: match the profile, do not invent

Pick the business details that appear on your Google Business Profile and reproduce the name and phone number on every location page character for character. Same legal or trading name, same number, same formatting. The address is the part that depends on what kind of business you are, and it is where most location-page estates go wrong.

If you have a real premises a customer can walk into, a shop or a clinic, show that one address on the location page that corresponds to it, and only there. If you are a service-area business, a plumber, an electrician, a mobile groomer, you do not have a public address to show, and Google’s own guidance is to keep it that way. Its service-area business help page tells you to “hide your address” so customers see the areas you cover rather than a location they cannot visit. A plumber who drives to jobs has no shopfront, so there is no street address to put on a page for each town.

What to do and what not to do

Here is the whole policy as a list you can check a page against:

Do show the same business name on every location page, exactly as it appears on your Google Business Profile.
Do show the same phone number on every page, in the same format, matching the profile.
Do show the city, county or region you serve in the visible text, so a reader and a crawler both know the page’s patch.
Do not invent a per-area street address, a virtual office, or a relative’s house used as a “branch”. Fabricated addresses are a known local-spam risk.
Do not create a separate phone number for each town to look local. One number, used consistently, is the trust signal.
Do not show a street address at all if you are a service-area business with no public premises. Show the area served instead.

Why per-area addresses and phone numbers backfire

The fake-address trick is the dangerous one. Google’s guidelines for representing your business on Google prohibit listing a location you do not staff during stated hours, and creating a profile or a page at an address you cannot meet customers at is exactly the kind of misrepresentation that gets profiles suspended. Putting an invented address on a location page does not earn you local relevance for that town; it builds a contradiction between your page, your profile and any genuine citation you hold, and contradictions are what a spam system is built to catch.

Per-town phone numbers are milder but pointless. They fragment the trust signal and give Google several numbers to reconcile against one profile, for no ranking gain. A local dialling code has not been a meaningful ranking lever for years; a consistent, answerable number is worth far more than a spread of tracking lines that point nowhere a human picks up.

What to show when you hide the address

Hiding the address does not mean hiding where you work. It means swapping a precise street line for a precise service area. On a UK page that reads naturally as the county or region, not a postcode you do not occupy: “Serving Rye, Battle and the wider Rother district of East Sussex” tells a reader and a search engine exactly as much as they need, and all of it is true. Name the towns you genuinely cover, name the county, and let the page stand on the work you describe rather than a borrowed address.

This is also where Google’s practical limits matter. A single profile is meant to cover the area you can actually reach, not the whole country, which is why the service-area radius is realistically about a two-hour drive at the outside. If your towns span more than one profile can credibly serve, that is a structural question, not a NAP one, and the guide on how many cities a Google Business Profile service area should cover works through it. For the broader setup, the service-area business SEO guide covers how the pages and the profile fit together.

A trust signal, not a ranking dial

It is worth being precise about what NAP consistency does, because the marketing language around it oversells it. Consistent NAP is primarily a trust and disambiguation signal: it helps Google be confident that the business on your website, the profile in the map pack and the mention in a directory are all the same entity. It is not a dial you turn up to rank higher. You do not get a tenth-place boost for listing your phone number in a tidier format.

The flip side is the real risk. When the details disagree, Google’s confidence drops, and the local search firm BrightLocal puts the consequence plainly in its October 2025 guidance: inconsistencies mean Google “can’t trust that search users are being served reliable information”. So the upside of getting NAP right is modest and the downside of getting it wrong is real. That asymmetry is the whole reason to be careful, and it is best-practice consensus across local-SEO practitioners rather than a single published Google rule.

Make the schema match the visible NAP

Whatever name, area and phone a visitor reads on the page, your structured data has to say the same thing. For a service-area business that means the LocalBusiness + Service + areaServed pattern, where areaServed lists the towns or region in the visible text and there is no address street line invented to fill a gap. Mismatched or invisible markup, an address in the schema that no human can see on the page, is the kind of thing that risks a structured-data manual action. The rule is simple: schema mirrors the page, never the other way round.

This guide does not re-teach the markup itself. The LocalBusiness schema guide sets out the full pattern for service-area businesses, including how areaServed should be expressed and why you leave the street address out. While you are matching things up, do not bolt self-serving review stars onto your own LocalBusiness markup. Google has not shown self-serving review stars from a site’s own markup since 2019, and adding them only invites a manual action; stars still come from third-party platforms and from Product markup, not from a business rating you award yourself.

How Townsmith keeps NAP consistent across every page

This is the part a content mill cannot tell you, because it comes from building the engine. Townsmith holds your name, phone and served area as site-level data, not as something retyped into each page. When it generates a location page, the same name and number are written into the visible text and into the LocalBusiness and Service schema from that one source, so the two cannot drift apart. There is no field anywhere that lets you set a different phone number for one town, because the consistency is the point.

The served area is handled the same way. The town or region you assign to a page flows into both the on-page sentence a reader sees and the areaServed value in the schema, so they match by construction rather than by you remembering to keep them in step. And because the engine never has a street-address field for a service-area page, it cannot emit a fabricated address even if you wanted one. The structure makes the safe choice the only choice. If you want to see the mechanism rather than read about it, the features page shows how the engine generates pages from one set of business details.

Before any of this goes live, a location page still needs the rest of the fundamentals right. The local landing page checklist covers the full set of pre-publish checks, NAP among them.

Common questions

Should each location page have its own address?

Only if you genuinely have a separate premises customers can visit at that location, and even then only the address that truly belongs there. A service-area business with no public premises should show the city or region it serves on each page, not a street address. Inventing an address per town to look local is a misrepresentation risk, not a ranking tactic.

Can I use a different phone number on each location page?

Better not to. One consistent number that matches your Google Business Profile is the trust signal; a different number per town fragments it and gives Google several numbers to reconcile against one profile for no ranking benefit. If you need call tracking, use a system that keeps a single public number while still attributing calls.

Does fixing NAP consistency improve my rankings?

Not directly. Consistent NAP is mainly a trust and disambiguation signal that helps Google connect your site, profile and external mentions to one business. It rarely lifts you up the results on its own. Inconsistent NAP can hurt, because contradictory details reduce Google’s confidence, so the value is in avoiding the downside rather than chasing an uplift.

Where do I put the service area if I am hiding my address?

In the visible page text and in the areaServed property of your schema, named as the towns, county or region you actually cover. For UK businesses that usually reads as the town plus its district or county, for example “serving Lewes and the wider East Sussex area”. Keep the two in step: the schema should say exactly what the page says.

Written by Stephen Evans. The figures here are current as of 21 July 2026, and the BrightLocal figure above is dated at its source.