contact_page On-Page & Content

NAP Consistency Checker

Check that the business name, address, and phone (NAP) in your structured data match what visitors see.

Check whether the business name, phone number, and street address in your structured data (schema markup) match what visitors see on the page. It also checks for a click-to-call link and counts the phone numbers shown.

build_circle Try the free tool
list On this page expand_more
star

Key takeaways

  • check_circle NAP means name, address, and phone, and consistent details are a basic local trust signal.
  • check_circle This tool compares the name, telephone, and street address in your JSON-LD with the visible text of the same page.
  • check_circle Matching is literal for name and street, so St versus Street counts as a mismatch, while phone numbers match on the last nine digits.
  • check_circle A tel: link and a single primary phone number help both mobile visitors and local search clarity.
  • check_circle It checks one page only and does not compare Google Business Profile or directory listings.
  • check_circle Phone detection is best-effort, so review the detected count for false positives such as long IDs.
  • check_circle Give each location its own page and its own LocalBusiness markup, and recheck after any move or rebrand.
contact_page

What is NAP Consistency Checker?

NAP stands for name, address, and phone number. In local SEO these three details identify a business, and search engines compare them across your website, your Google Business Profile, and third-party directories. When they agree, systems can confidently treat the sources as one business. When they differ, listings can split, duplicate, or lose trust. It starts on your own site.

The HeyLead NAP Consistency Checker starts with your own page. It reads the LocalBusiness or Organization data in your JSON-LD, picks out the business name, telephone, and street address, and then looks for the same details in the visible page. Six checks report the result: schema has NAP, phone matches the page, address matches the page, name matches the page, a tel: link exists, and the page shows no more than two distinct phone numbers. The summary shows phones on the page, whether schema NAP is complete, and the number of mismatches.

The scope is deliberately narrow. It does not look at Google Business Profile, directories, or social listings, and it cannot see details added by JavaScript. Its address check covers the street line, and matching is literal, which is useful for catching abbreviation drift. Use it to prove that a single page and its markup agree, then extend the audit to your profiles and citations.

insights

Why NAP consistency matters

Local visibility depends on search engines trusting that a business exists where and how it says it does. Contradictory details make that harder and can lead to duplicate listings, misrouted calls, and wrong information in maps and assistants. Aligning page, schema, and profile is inexpensive and worth doing early.

arrow_forward Consistent details help search engines confirm one business identity across sources.
arrow_forward Customers reach you faster when the number, address, and name are correct and tappable.
arrow_forward Matching schema and visible content follows structured data guidelines and avoids trust issues.
arrow_forward Clean details reduce duplicate listings and wrong information appearing in maps or assistants.
play_circle

How to use this tool

  1. 1

    Enter your contact or location page

    Use the page that carries your business details.

  2. 2

    Compare schema to page

    We look for name, address, and phone in your markup and on the page.

  3. 3

    Fix mismatches

    Make the page, schema, and Google Business Profile say the same thing.

fact_check

What this tool checks

verified

Schema contains NAP

Reads your JSON-LD for a business name, a telephone value, and a streetAddress inside an address object. The check passes when both the phone and the street address are present in schema.

verified

Phone matches the page

Compares the schema telephone with numbers found in tel: links and visible text, matching on the last nine digits so spacing, brackets, and dashes do not cause false mismatches.

verified

Address matches the page

Looks for the schema street address as a case-insensitive phrase in the visible page text. Abbreviations such as St versus Street will not match, which is the point of the test.

verified

Name matches the page

Checks that the business name in schema, taken from a business, organization, or service entity, appears somewhere in the visible text, so brand spelling stays consistent between markup and page.

verified

Click-to-call link

Looks for at least one tel: link in the page HTML. A tappable number helps mobile visitors call in one touch and gives crawlers an unambiguous phone value.

verified

Number of phone numbers

Counts distinct phone numbers detected on the page and passes when there are two or fewer. Many different numbers can confuse visitors and weaken a clear local signal.

engineering

Technical guide

Signals, standards, and what to fix when checks fail.

code

How the schema is read

The tool parses every JSON-LD block, unpacks arrays and @graph containers, and scans the entities. The name comes from the first entity whose type looks like a business, organization, or service, or a trade type such as Dentist or Restaurant. Names may be a string or a list. The telephone comes from the first entity that has one. The street comes from a PostalAddress streetAddress, a string address, or the first item in an address list. Addresses written in Microdata are not read. Only the first match for each field is used, so extra entities do not change the comparison.
code

How phone numbers are found

Phone detection is best-effort. The tool collects numbers from tel: links, then scans the visible text for digit patterns of 9 to 13 digits, skipping anything that resembles a date or year. Numbers are compared by their last nine digits, so a +44 number and its 0-prefixed local format match. Digits in postcodes, invoice numbers, or IDs can occasionally look like phone numbers, so review the count rather than trusting it blindly. That keeps false alarms low but not zero. Numbers inside images or scripts are never seen, so confirm the count against the page yourself.
code

How name and address are compared

Name and street are compared as lowercase text against the page's visible text, with spaces collapsed. That means the comparison is literal: 12 High Street will not match 12 High St. The check covers the street line only, not city, state, postcode, or country. Text in headers and footers counts as visible, so a match anywhere on the page passes, even if it is far from your contact block. Rewrite whichever source differs so both use one wording. Separate address lines that break the phrase may also cause a miss.
code

What the tool does not check

It analyzes one page and its structured data. It does not query Google Business Profile, directories, data aggregators, or social profiles, so it cannot confirm citation consistency across the web. It also reads only served HTML, so numbers and addresses inserted by JavaScript, or embedded in images, are missed. Treat a pass as evidence that page and schema agree, not that your whole local footprint does. Plan a separate citation audit for the wider web.
school

Deep dive

contact_page

What NAP is and why search engines compare it

Local search works by matching real-world businesses to online records. Name, address, and phone number are the simplest identifiers a system can compare. When your website, Google Business Profile, and directory listings all carry the same details, engines gain confidence that they are one entity and can show it accurately in results and maps. When details vary, they have to guess. Inconsistency does not usually cause a penalty, but it can produce duplicate listings, wrong pins, misdialed calls, and hesitation about which source to trust. AI assistants that assemble answers from multiple sources face the same problem. That is why the safest habit is to define one canonical version of each detail, publish it everywhere, and change it in every place at once when reality changes.

Name

Use the trading name people know, written the same way everywhere. Add a legal suffix only if you show it consistently, and avoid keyword additions.

Address

Use one format for the street line, unit or suite, city, region, and postcode. Decide on Street or St, and Suite or Ste, then stick with it. Copy it from your official profile.

Phone

Choose a primary local number for each location and use it in schema, on the page, and on your profile. Keep secondary numbers clearly secondary. Write it identically each time.

data_object

Keeping schema and the visible page aligned

Structured data is supposed to describe what visitors can see. If schema lists one phone number and the page shows another, the markup is inaccurate at best and misleading at worst. Build your LocalBusiness markup from the same data source that renders the contact block, so the two cannot drift. A template that pulls name, street, and telephone from one settings record is safer than three hand-typed copies. Use a PostalAddress object rather than a single string, and write the telephone with the country code. On the page, show the number in a local format and wrap it in a tel: link. After any update, run the checker to confirm the street and phone still match, especially on staging-to-production releases, where old details often reappear.

One source of truth

Store name, address, and phone once, then render both visible text and schema from that record. Duplicated hand-typed copies inevitably diverge. Editors then change one place, not five.

Use PostalAddress properly

Split the address into streetAddress, addressLocality, addressRegion, postalCode, and addressCountry. A single string may be readable by people but is harder for tools.

Verify after releases

Rerun the check after theme changes, page builder edits, and migrations. These are the moments when old footers and cached templates resurrect outdated details. Save the results for comparison.

phone

Phone numbers, tracking, and click-to-call

Phone numbers cause most NAP problems because businesses have many: a main line, a mobile, a sales line, a call-tracking number for each campaign. Every extra number on a page dilutes clarity. A sound approach is to keep the real, primary number in schema, on the Google Business Profile, and in directories. If you need call tracking, limit it to specific landing pages or use dynamic number insertion carefully, and understand how it changes the visible page. Make the number tappable with a tel: link so mobile visitors call in one touch. Use the international format inside the link, for example +44 or +61, and display the format locals recognize. This tool counts distinct numbers and passes at two or fewer, but the goal is one obvious primary number per location.

Primary versus secondary

Designate one primary number per location. Secondary numbers, such as fax or after-hours lines, should be labeled and kept out of schema unless needed. Keep the choice documented for editors.

Call tracking trade-offs

Tracking numbers improve attribution but can create inconsistency. Keep the primary number in markup and profiles, and document any dynamic swaps for your team. Review the impact with your local SEO lead.

Tap to call

A tel: link turns the number into a button on phones. Use full international digits in the link and the local format in the visible text. Test the link on a real phone.

storefront

Regional formats and multi-location pages

Address and phone conventions differ by market, and consistency means following the local convention every time. In the US, addresses include a state and ZIP code and numbers are ten digits with the +1 country code. In the UK, addresses end with a postcode and numbers use +44, with the leading zero dropped in international format. Australian addresses include a state abbreviation and four-digit postcode, with numbers under +61. Singapore addresses use a six-digit postal code and numbers under +65. Use the correct addressCountry and local spelling on each regional page. For multi-location brands, publish one page per location with its own address, its own number, and its own LocalBusiness markup, then run this check on every location page. A template that swaps in the right details per branch is the scalable way to keep them consistent.

Follow local conventions

Use ZIP codes and state abbreviations in the US, postcodes in the UK and Australia, and six-digit postal codes in Singapore, formatted as locals expect. Do not mix conventions.

One page per location

Give each branch its own URL, address, phone, and markup. Pages that list many branches make it unclear which details belong to which place.

Templates at scale

Drive branch pages from a data table so every location follows the same format. Then sample-check several branches after each template change.

compare

Examples

thumb_up Strong examples

Schema and page agree

Schema: "streetAddress":"12 High Street" | Page: 12 High Street, Leeds LS1 4AB

The street line is identical in markup and visible text, so a literal comparison passes, and the same wording can be reused in profiles and directories.

Tappable primary number

<a href="tel:+442071234567">020 7123 4567</a>

The tel: link uses full international format for machines, while the visible text uses the local format people expect. Both resolve to the same last nine digits.

Complete LocalBusiness markup

{"@type":"LocalBusiness","name":"Harbour Dental","telephone":"+61 2 9123 4567","address":{"@type":"PostalAddress","streetAddress":"5 Quay Street"}}

Includes name, telephone, and an address object with a streetAddress, which is the minimum the tool needs to run a full comparison against the page.

thumb_down Weak examples

Abbreviation drift

Schema: 12 High Street | Page: 12 High St.

The wording differs between markup and page, so the literal comparison fails. Pick one style and use it in schema, on the page, and in your profiles.

Different phone in schema

Schema: +1 555 010 0100 | Page: (555) 010 0199

The last nine digits differ, so the phone mismatch is flagged. Visitors and crawlers see two numbers, and it is unclear which one is the official contact.

Schema without an address object

{"@type":"LocalBusiness","name":"Harbour Dental","address":"5 Quay Street, Sydney"}

A plain address string is read as the street line, but a PostalAddress object with separate street, locality, region, and postal code fields is clearer for search tools and validators.

rule

Best practices and common mistakes

check_circle Best practices

  • done Use one primary phone number per location, in the same format in schema and on the page.
  • done Write the street address in schema exactly as it appears on the page and on your Google Business Profile.
  • done Use the same business name everywhere, including punctuation and legal suffixes such as Ltd, Pty Ltd, or LLC where you show them.
  • done Wrap the phone number in a tel: link with the full international format so mobile visitors can tap to call.
  • done Give each branch its own page with its own LocalBusiness schema instead of listing every branch on one page.
  • done Recheck contact pages after any rebrand, move, phone change, or theme update.

cancel Common mistakes

  • close Showing a call-tracking number on the page while schema lists a different number, without a documented plan.
  • close Abbreviating the street name differently in the footer, contact page, and schema.
  • close Putting several branch addresses in one schema block for a single location page.
  • close Stuffing city names or keywords into the business name field.
  • close Leaving old addresses or numbers in footers, sidebars, and legacy templates after a move.
lightbulb

Common use cases

task_alt

Auditing a location page before a local SEO campaign.

task_alt

Checking a template that was rolled out to many branch pages.

task_alt

Verifying contact details after a move, rebrand, or phone change.

task_alt

Reviewing a franchisee or agency-built page against the head office standard.

task_alt

Preparing a page so it matches the Google Business Profile.

groups

Who should use this

person Local businesses with a single storefront or office. person Multi-location brands managing many branch pages. person Agencies delivering local SEO for clients. person Service-area businesses that publish city landing pages. person Developers building LocalBusiness schema templates.
dictionary

Glossary

NAP
Name, address, and phone number: the core identifying details of a local business, compared across websites, profiles, and directories.
Citation
An online mention of your business name, address, and phone number, often in a directory, that supports local search trust.
Google Business Profile
Google's free business listing, which shows in Search and Maps and should match the details on your website exactly.
LocalBusiness
A schema.org type for a physical business or branch, with properties such as name, telephone, address, and openingHours.
PostalAddress
A schema.org type that holds an address in separate fields, including streetAddress, addressLocality, addressRegion, postalCode, and addressCountry.
tel: link
A link that starts a phone call when tapped on a mobile device, written as href="tel:" followed by the number.
Call tracking
A method that shows different phone numbers to different sources to measure marketing, which can create NAP inconsistency if unmanaged.
Service-area business
A business that serves customers at their locations rather than at a public storefront, which affects how addresses are shown.
quiz

Frequently asked questions

Ready for a deeper audit?

HeyLead reviews your site, competitors, and growth opportunities with no sales pressure.

Get a Free Audit arrow_forward