NAP Blocks: Canonical Name, Address, and Phone

A NAP block publishes a business location’s name, address, and phone number in one canonical record. “Canonical” means the organization has chosen one authoritative underlying value for each field, even when a directory abbreviates the street or a phone link uses an international machine format.

The rendered element is deliberately unexciting. Its job is identity, not persuasion: one location, one customer-facing name, one deliverable address, one monitored number, and enough provenance to audit all copies against the source.

Why this element matters

Local decisions have a high cost of being wrong. A reader may be choosing where to drive, which branch to call, where to send a document, or whether a company serves their area. When the footer shows a head-office number, the location page shows a branch number, and the map panel points to an old entrance, the reader must guess which fact controls the next action. That uncertainty damages trust before a conversation begins.

The psychological benefit is confidence through specificity. A complete street address signals that the page describes a real place rather than a generic city-targeted landing page. A location-specific phone number tells the reader whom they will reach. A stable name helps them recognize the same branch in search results, maps, review platforms, invoices, and signage. None of these details proves service quality, but together they remove avoidable doubt about identity and access.

Machine extractability is the ability of a crawler, search engine, directory, assistant, or syndication process to preserve each value and its relationship to one location. A sentence such as “Call our Washington team near Capitol Hill” may read naturally, but it does not expose a complete postal address or an unambiguous telephone value. A labelled block with a stable location ID produces a record that can be compared field by field.

Consistency should be treated as an auditable data problem, not a typography ritual. Normalize case, Unicode, whitespace, street suffixes, unit identifiers, postal codes, country codes, and phone digits before comparing records. “1200 Example Ave., Ste 210” and “1200 Example Avenue, Suite 210” may normalize to the same address; “Suite 120” does not. Likewise, (202) 555-0147 and +1 202-555-0147 can represent the same number, while a call-tracking number may intentionally differ and must be recorded as an approved alias with its routing owner.

When to use it

Use a NAP block whenever a page represents a physical business location that customers may visit, call, mail, verify, or distinguish from another branch. It is required on location and branch pages, useful in controlled directory records, and appropriate on a company profile when the address is genuinely part of the public identity.

Create one block per location. A multi-location index may render twenty blocks, but it must render twenty separate records rather than one business name followed by a mixed list of addresses and numbers. Each instance should resolve to a location ID so a content system cannot pair Branch A’s address with Branch B’s phone.

Near misses need different treatment:

• A service-area business with no customer-facing premises should not publish an owner’s home address. State the service area and contact route without pretending there is a visitable NAP location.
• A postal box, registered-agent address, billing address, warehouse, and returns address are not interchangeable with a customer location. Label each operational purpose and keep it outside the primary block unless that is the address customers are instructed to use.
• Opening hours, appointment availability, directions, parking, and accessibility details may sit near the block, but they are separate facts with separate update cycles.
• A call-tracking number is not automatically inconsistent. It is acceptable when routing is reliable, the ownership and canonical destination are documented, and the visible number does not change unpredictably for crawlers or returning users.
• An online-only company may have a legal address for compliance but no local premise. Do not turn a legal disclosure into local-presence marketing.
• A practitioner inside a clinic may need a practitioner record and the clinic may need a location record. Do not merge their names and phone numbers into a hybrid identity.

The element writing rules take precedence: choose the element by the passage’s purpose. If the passage’s job is to state a location’s canonical name, address, and phone, use a NAP block even when a generic card or footer could display similar text.

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Get Started Contact

Where to place it

On a dedicated location page, place the primary NAP block immediately after the opening identification and direct answer, before directions, hours, services, reviews, or booking controls. The reader should know which place the page represents before interpreting any local claim. If the hero already renders the full canonical record, the later contact section may repeat it only from the same data object.

On a company profile, put it in a clearly labelled “Head office” or “Public contact location” section rather than beneath a generic “About” heading. On a directory index, put one compact block inside each corresponding listing and link the entire identity group to the correct branch profile. In a site footer, use only the primary public location or an explicit location selector; a footer is too cramped for an unlabeled mix of several offices.

The block may sit beside hours, a map, directions, parking information, or a booking action only when every adjacent component uses the same location ID. It may not sit beside a map pin for another entrance, an organization-wide switchboard labelled as a branch line, a delivery-only warehouse address, or a location selector whose current selection is unclear. Do not place an advertisement, testimonial, newsletter form, or promotional offer between the name and its address or between the address and phone. Those interruptions break the record visually and in reading order.

On mobile, preserve the order name, street, locality, region and postal code, country when needed, then phone. Do not let a sticky call button replace the visible number or obscure which branch it calls.

Anatomy

1. Location name: the approved customer-facing name, including a branch qualifier only when it is used consistently.
2. Street address: the delivery-valid street number and name, not a landmark description.
3. Subpremise: a suite, unit, floor, building, or department needed to reach the correct destination.
4. Locality and region: the city or locality plus the governed state, province, county, or region value.
5. Postal code and country: the complete routing code and country, including country when the audience or syndication crosses borders.
6. Display phone: the human-readable number formatted for the location’s audience.
7. Telephone target: the same number normalized for dialing, normally in E.164 format inside a tel: link.
8. Location ID: a stable internal key that prevents branch details from being mixed during rendering or syndication.
9. Verification metadata: the date and authoritative system or owner against which the record was checked.

Stay Updated on AI Visibility Trends

Get the latest insights on AI mentions, brand monitoring, and optimization strategies.

Email address

Subscribe

Design examples

Every variant uses the same underlying location record. Density and surrounding actions may change, but the renderer may not abbreviate away a suite, substitute an organization-wide number, or hide an address required to distinguish the branch.

Standard location. The default variant shows every component in a vertical, easy-to-copy group. Use it on a dedicated location or branch page.

Compact contact band. Use in a footer or contact band when one public location represents the page. It may collapse to rows on narrow screens, but it must not truncate the unit, postal code, or phone.

Directory card. Repeat one compact NAP instance per location. Keep filters, distance, “open now,” and service labels outside the identity fields so dynamic states cannot rewrite the canonical record.

Appointment-only location. Show the full public NAP when customers are permitted to visit, then add “Appointment required” as a separate operational note. Do not insert the phrase into the address line.

International. Preserve the address order expected in the destination country while storing each component separately. Display the local phone convention for readers and retain an international dialing value for the link and data layer.

Parameters

“Source” below means where the renderer obtains a field. The business’s governed location registry, not the article body, remains authoritative for identity values.

Store components separately even when the renderer joins them for display. A single address="1200 Example Avenue, Washington..." blob prevents country-specific ordering, reliable comparisons, and targeted correction of a wrong suite or postal code.

Syntax and code examples

All three forms encode the same location ID and canonical fields. The portable directive is the authored contract; a project must register and test its Hugo and WordPress adapters before publishing the syntax.

Portable Markdown directive

:::nap{location-id="NSH-DC-01" name="Northstar Heating — Capitol Hill" street-address="1200 Example Avenue|Suite 210" locality="Washington" region="DC" postal-code="20001" country="US" phone="+12025550147" phone-display="(202) 555-0147" verified="2026-08-27" source="location-registry"}
## Northstar Heating — Capitol Hill

Note: Visits by appointment.
:::

Hugo shortcode

{{< nap location-id="NSH-DC-01" name="Northstar Heating — Capitol Hill" street-address="1200 Example Avenue|Suite 210" locality="Washington" region="DC" postal-code="20001" country="US" phone="+12025550147" phone-display="(202) 555-0147" verified="2026-08-27" source="location-registry" >}}
## Northstar Heating — Capitol Hill

Note: Visits by appointment.
{{< /nap >}}

All shortcode parameters are named. The adapter must escape text, generate an <address> group and tel: link, expose the location ID to the data layer, and preserve the body note outside the postal address.

WordPress block

<!-- wp:amicited/nap {"locationId":"NSH-DC-01","name":"Northstar Heating — Capitol Hill","streetAddress":["1200 Example Avenue","Suite 210"],"locality":"Washington","region":"DC","postalCode":"20001","country":"US","phone":"+12025550147","phoneDisplay":"(202) 555-0147","verified":"2026-08-27","source":["location-registry"],"variant":"standard"} -->
<div class="wp-block-amicited-nap">Server-rendered from canonical location fields.</div>
<!-- /wp:amicited/nap -->

The WordPress block should use typed inspector fields and server rendering. Authors may choose a location record and add an approved note, but should not retype the canonical name, address, or phone into Rich Text.

Examples

Good: one complete, attributable location

Northstar Heating — Capitol Hill
1200 Example Avenue, Suite 210
Washington, DC 20001, United States
(202) 555-0147
Location NSH-DC-01 · Verified 27 August 2026 against the approved location registry

This works because the branch qualifier, suite, postal code, country, display number, dial target, stable ID, date, and source all describe one record. A reader can visit or call; a crawler can extract the same values; an auditor can compare the block with a directory listing without guessing which office controls the page.

Bad: a plausible-looking composite

Northstar Heating Washington
Near Capitol Hill, Washington DC
Call our team: 555-0147 or the main office
Open near you

This fails because “near Capitol Hill” is not a deliverable address, the local number lacks an area and country context, “main office” has no number, and the name does not identify a governed branch. “Open near you” mixes hours and proximity into identity without a location or time basis. The block cannot be matched confidently to a map record, directory citation, schema entity, or internal source.

Repair it by selecting the exact location ID, resolving every field from the registry, publishing the complete public address and monitored phone, and moving hours or proximity claims to their own components.

Schema markup and accessibility

A NAP block can feed an eligible Organization, LocalBusiness subtype, or other place-based entity. Map the visible name, telephone, and address components to a PostalAddress: streetAddress, addressLocality, addressRegion, postalCode, and addressCountry. Use the most specific truthful business type supported by the page; do not choose a category solely to gain a search feature.

Structured data must identify the same location the page identifies. Do not put the corporate headquarters in JSON-LD while showing a branch in the block, combine several branches into one address, or add latitude and longitude guessed from a postal code. If each branch has its own page and persistent entity, use a stable canonical URL and governed identifier to keep the graph separate. The verification date and source support internal governance but do not require public Schema.org properties.

Use an <address> element for the contact information of the location represented by the page or section. Do not assume <address> means any postal address; its HTML meaning is contact information for the relevant article or page owner. Keep the location name in a heading, label repeated directory cards, and preserve a logical source order.

The visible phone number must remain text, not an icon or image. Link it with href="tel:+12025550147" when calling is appropriate, but keep a readable local display. Do not split individual digits into styled spans, pronounce punctuation through an inaccurate accessible label, or hide essential extensions in a tooltip. Ensure keyboard focus is visible, link purpose includes the branch when several call links appear together, and zooming or reflow does not separate the suite or postal code from the address.

Writing rules

These rules protect identity resolution first; visual neatness is secondary:

• Use exactly one customer-facing name, one address, and one primary phone per block. If a secondary number is operationally necessary, label its purpose outside the canonical NAP trio.
• Keep the name to 2–100 characters. Use the real public brand and a governed branch qualifier; do not add keywords such as “best emergency plumber in Washington.”
• Use 1–3 street lines, each no more than 100 characters. Preserve suite, unit, floor, building, and directional information required for delivery or arrival.
• Use a complete postal address for public premises. Never replace it with “downtown,” “near the station,” a map pin, or driving directions.
• Store the country as a two-letter code and render its human-readable name when audience context requires it. Never infer a country from a top-level domain alone.
• Store phone numbers in E.164 form and render a familiar local form. Include an extension as a separate governed value when routing depends on it.
• Use a factual, administrative tone. The block may say “Appointment required” or “No public access”; it must not contain slogans, service claims, reviews, awards, discounts, urgency, or keyword lists.
• Do not put hours, directions, parking instructions, service areas, booking availability, email addresses, fax numbers, or social profiles inside the three identity fields. Adjacent labelled fields are acceptable when their ownership and update cadence are clear.
• Do not silently overwrite a canonical value to match one third-party directory. Investigate whether the external record is stale, an approved alias, or a genuinely different location, then correct the appropriate source.
• Record a verification date and source for every published instance. Re-verify after moves, rebrands, phone routing changes, mergers, branch closures, suite changes, and directory migrations.
• Treat punctuation and abbreviations as presentation differences only after normalization proves the underlying components match. A changed digit, suite, postal code, or branch qualifier is substantive.

Post types that use it

The table is governed by postTypes[] in frontmatter. Add or remove a row only when the corresponding array changes.

QA checklist

• The block resolves from one stable location ID rather than independently typed fields.
• The public name matches the governed brand and branch naming policy without keyword additions.
• The street number, street name, directional, suite or unit, locality, region, postal code, and country were checked against the authoritative source.
• The address is valid for the stated customer action: visiting, mailing, collection, or another explicitly labelled purpose.
• Private homes, registered-agent offices, warehouses, and virtual offices are not presented as customer locations.
• The displayed phone and tel: target normalize to the same monitored destination.
• Nearby hours, map, directions, booking, and CTA components use the same location ID.
• No adjacent block contradicts the address, phone, branch name, visit policy, or location selection.
• Normalized comparison distinguishes harmless formatting differences from changed digits, units, or postal components.
• Visible content and Organization, LocalBusiness, or PostalAddress markup agree field for field.
• Repeated blocks have unique headings or accessible labels, and every phone link has clear purpose.
• The complete record remains readable, copyable, keyboard accessible, and correctly ordered at 200% zoom and on a narrow screen.
• Verification date and source are present, and a named owner receives discrepancy reports.
• Moves, closures, rebrands, number changes, and approved aliases have an update path across the website, profiles, directories, and data feeds.

FAQ

What does NAP mean in local SEO?

NAP means name, address, and phone. A NAP block publishes those three identity facts for one business location in a canonical, labelled form that people and machines can retrieve without combining details from different branches.

Must the punctuation be identical on every website?

No. Harmless presentation differences such as “Suite” versus “Ste.” or locally formatted versus international phone display do not create a different entity when the underlying values normalize to the same facts. Audit normalized fields, while keeping one preferred display form under your control.

Should a service-area business publish a home address?

No. Do not expose a private or customer-ineligible address merely to complete the block. Publish the customer-facing business name and monitored phone, state that service is provided at customer locations, and keep any private address in governed systems that genuinely require it.

Can one NAP block contain several branches?

No. One block represents one location record. A directory may repeat the component once per branch, but each instance needs its own location identifier, address, phone, source, and destination page so details cannot be recombined accidentally.

How often should NAP information be checked?

Check it whenever a location, number, naming policy, or directory listing changes, and include it in a recurring local-data audit. The appropriate interval depends on operational change rate; the block should record its last verification date and authoritative source rather than imply permanent accuracy.