Name, address, phone — mismatched across directories splits your local entity. A checklist and a priority order for fixes.
Name, address, phone — three fields that should be boring. When they disagree across your site, Google Business Profile, and directories, local entity resolution gets noisy. Assistants that lean on Maps-style data and business listings inherit that noise.
NAP consistency will not make you famous in ChatGPT overnight. It will stop you from looking like two different clinics on the same block.
What NAP means here
| Field | Include | Watch-outs |
|---|---|---|
| Name | Canonical public brand name | Legal Inc. vs DBA vs store nickname |
| Address | Deliverable street address (or service-area rules) | Suite lines, directional abbreviations, city spelling |
| Phone | Primary customer number in one format | Tracking numbers that replace the main line everywhere |
If you are organization-only with no public walk-in location, you may not need LocalBusiness markup — see Organization vs LocalBusiness. This checklist is for brands that do publish places.
Why answer engines care
Local answers pull from GBP, maps providers, directories, and on-site contact blocks. Mismatched NAP splits signals: one system thinks you moved; another thinks you are a duplicate. Users get the wrong phone. Models get conflicting facts.
Your Organization or LocalBusiness schema should match the same NAP you show in the footer. Same for the Google Business Profile.
Priority order for fixes
Fix high-authority, high-traffic surfaces first. Do not spend Friday normalizing a forgotten niche directory while GBP is wrong.
| Priority | Surface | Why first |
|---|---|---|
| 1 | Google Business Profile | Feeds Maps and many local panels |
| 2 | On-site contact / footer / schema | Your canonical self-description |
| 3 | Apple Business Connect / major maps (if used) | Parallel local graphs |
| 4 | Top directories you actually earn from | Citations that still get fetched |
| 5 | Social about fields (LinkedIn, Facebook) | sameAs and knowledge panels |
| 6 | Long-tail directories | Only if time remains |
NAP consistency checklist
Use this as a working sheet (hypothetical: you run 20 location pages — same process, more rows).
| Check | Pass looks like | Fail action |
|---|---|---|
| Exact same public name on GBP and site H1/schema | Character match for core name | Pick one canonical; update outliers |
| Address line breaks and suite identical | Same suite token everywhere | Standardize abbreviations (Ste vs Suite) once |
| City/state/ZIP match postal format | Valid, consistent | Fix typos; do not "pretty print" differently per site |
| Phone in one canonical format | Same digits; one primary | Retire rogue tracking numbers from NAP fields |
Schema telephone / address match visible text | No schema-only fiction | Align JSON-LD to footer |
| Multi-location pages do not share one phone | Each place has its place | Split LocalBusiness entities |
| Closed locations marked closed | Not still "Open" in directories | Update or remove |
| Service-area businesses not inventing a fake storefront | Honest area served | Follow GBP service-area rules; no fake pin |
Step-by-step cleanup
- Declare the canonical NAP in an internal doc (one row per location).
- Export GBP data and compare to the doc.
- Fix the website footer, contact page, and LocalBusiness/Organization JSON-LD.
- Update the top five directories you care about; leave the junk tier for later.
- Search for old addresses/phones on your domain (
site:queries, crawl) and redirect or edit. - Re-check in 30 days — syndication lags; do not thrash daily.
- Assign an owner so the next move or number change updates the sheet first.
Multi-location table (template)
| Location ID | Canonical name | Street | City | Region | Postal | Phone | GBP URL | On-site URL |
|---|---|---|---|---|---|---|---|---|
| LOC-01 | ||||||||
| LOC-02 |
Fill it once. Make every vendor row match.
Mistakes
Using call-tracking numbers as the only published phone in schema.
Put the stable customer number in NAP; keep tracking in ads/UTM landers if you must.
Updating the blog and forgetting GBP hours/address.
GBP wins a lot of local retrieval fights.
Creating a second LocalBusiness for the same pin with a slightly different name.
Duplicates confuse more than they help.
Copy-pasting headquarters NAP onto franchise pages.
Each place needs its place.
Blocking AI crawlers on the contact page while allowing them elsewhere.
If you want accurate phone quotes, let fetchers read the page — after you settle bot access.
How to verify
- Spot-check GBP vs footer vs schema for each location
- Call the published number once (yes, really)
- Ask a teammate in another city to search the brand + city and read back the phone
- Optional: BrandKnown scan for on-site identity/access issues — it will not certify every directory on earth
Honest ceiling: clean NAP will not overcome bad reviews or a closed kitchen. It removes preventable contradiction. Do the boring sheet. Then stop tweaking commas weekly.
Special cases worth a paragraph
Service-area businesses.
If you do not serve customers at a storefront, do not invent one for directory juice. Use GBP service-area settings, publish cities or regions you actually cover on-site, and keep the phone consistent. Schema should not invent a street you cannot receive mail at.
Seasonal or pop-up locations.
Mark hours and end dates honestly. Leaving a December market address live in July is how assistants send people to an empty lot.
Rebrands mid-move.
Change the canonical NAP doc first, then GBP, then site, then directories. Simultaneous half-updates create two weeks of conflicting answers — unavoidable to some degree, but shorter if you sequence on purpose.
Northstar Analytics opened a small Austin office for customer workshops. They added one LocalBusiness node for that address and kept the SaaS product on Organization schema at the marketing domain. Two entities, two jobs — not one blended NAP blob.
When you finish the sheet, stop. Consistency is a maintenance habit, not a forever project board.