What is NAP data

NAP is the abbreviation of Name, Address, Phone. The three fields identify a business with a physical presence, and they are the ones a search engine cross-checks in order to decide that the profile, the website and the mention in a directory are talking about the same establishment.

Consistency is the point, not the data itself. A system that finds “3 High Street” on the website, “High St. 3a” in a directory and “High Street 3, ground floor” in a listing has to decide whether that is one business or three. Every variant adds disambiguation work, and that work can come out wrong. When it comes out wrong, the reviews, mentions and signals of a single location end up split across separate records.

Two neighbouring terms are worth keeping apart. Local SEO is the full discipline, with reviews, location content and links from the area. The local pack is the block of results with a map that appears on the search page. NAP data is the raw material both of them take for granted: the identity of the business written the same way everywhere it appears.

The guidelines for representing a business are explicit on all three fields. The name has to be the one the business uses in the real world, the same one on the sign, the website and the stationery. Adding taglines, opening hours, service descriptions, store codes, phone numbers or web addresses to the name field is not permitted and can end in suspension of the profile.

The address has to correspond to a real location, with a precise street and number or with a declared service area. PO boxes and virtual offices fall outside, and a business that shows an address has to keep permanent fixed signage with its name at that point. The phone number has to connect to that specific location and be under the direct control of the business; Google prefers a local number over the corporate call centre and prohibits premium rate numbers.

In markup, the same three items are declared with Schema.org. The LocalBusiness type carries name and telephone, and the address is nested as PostalAddress with streetAddress, addressLocality, postalCode, addressRegion and addressCountry, the last one in two-letter format. For its local business rich result, Google requires name and address, and places telephone among the recommended properties.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Panadería Sol",
  "telephone": "+34931234567",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Carrer Gran 12",
    "addressLocality": "Barcelona",
    "postalCode": "08003",
    "addressRegion": "CT",
    "addressCountry": "ES"
  }
}
</script>

The decision that depends on NAP data is whether it is worth investing in local presence before the identity has been sorted out. Reviews, neighbourhood content and press notes all point at a business the search engine has to recognise as one. If the name wobbles between four versions, part of that investment is spread across records the system has not yet merged.

It also decides the order of work in a relocation or a rebrand. Changing the sign, the legal name or the phone number means going through the Google profile, the website, the markup and the directories where the business already appears. Done piecemeal, it leaves two live versions of the same item for months, and the old one keeps taking calls nobody answers.

On the effect on rankings, caution is in order. Specific figures circulate about how much NAP consistency weighs in local ranking, almost always with no published sample or method, so they are no basis for promising an outcome. What is documented is the operational risk: a name with keywords bolted on can cost the suspension of the profile, and a suspended profile appears nowhere.

• Write the canonical version of the three items once and store it where the team will find it. Everything else gets copied from there.
• Use the name from the sign in the profile, with no city, service or tagline bolted on, however tempting the keyword is.
• Declare the same phone number on the website, in the profile and in the markup, in international format with the country code.
• Add LocalBusiness with its nested address on every location page and check the outcome with the rich results test.
• Inventory the directories where the business already appears before creating new listings, including the ones somebody registered years ago.
• Document every change of address or phone number with its date and go through the full list within the same week.

• Putting keywords or the city into the profile name. It is the violation that triggers the most suspensions, and it does not deliver what it promises.
• Using one call centre number for every location, which leaves none of them identifiable by its phone.
• Publishing the address only inside an image or an embedded map, where no crawler reads it as text.
• Registering a listing at a virtual office or a shared workspace with no signage of its own.
• Updating the Google profile after a move and forgetting the footer, the markup and the old directories.