NAP-blokken: canonical naam, adres en telefoon

Een NAP-blok publiceert de naam, het adres en het telefoonnummer van een bedrijfslocatie in één canonical vermelding. ‘Canonical’ betekent dat de organisatie één gezaghebbende onderliggende waarde per veld heeft gekozen, zelfs wanneer een bedrijvengids de straat afkort of een telefoonlink een internationaal machineformaat gebruikt.

Het weergegeven element is opzettelijk onopvallend. Zijn taak is identiteit, niet overtuiging: één locatie, één klantgerichte naam, één bezorgbaar adres, één bewaakt nummer en voldoende herkomst om alle kopieën tegen de bron te kunnen controleren.

Waarom dit element belangrijk is

Lokale beslissingen hebben een hoge prijs bij fouten. Een lezer kiest wellicht waarheen te rijden, welke vestiging te bellen, waar een document heen te sturen of of een bedrijf hun regio bedient. Wanneer de footer een hoofdkantoornummer toont, de locatiepagina een vestigingsnummer en het kaartpaneel naar een oude ingang verwijst, moet de lezer raden welk gegeven de volgende actie bepaalt. Die onzekerheid beschadigt het vertrouwen voordat een gesprek begint.

Het psychologische voordeel is vertrouwen door specificiteit. Een volledig straatadres signaleert dat de pagina een echte plek beschrijft in plaats van een generieke, op een stad gerichte landingspagina. Een locatiespecifiek telefoonnummer vertelt de lezer wie ze zullen bereiken. Een stabiele naam helpt hen dezelfde vesting te herkennen in zoekresultaten, kaarten, reviewplatforms, facturen en bewegwijzering. Geen van deze details bewijst servicekwaliteit, maar samen verwijderen ze vermijdbare twijfel over identiteit en toegang.

Machine-uitleesbaarheid is het vermogen van een crawler, zoekmachine, bedrijvengids, assistent of syndicatieproces om elke waarde en de relatie ervan tot één locatie te behouden. Een zin als ‘Bel ons Washington-team nabij Capitol Hill’ leest misschien natuurlijk, maar geeft geen volledig postadres of een ondubbelzinnige telefoonwaarde bloot. Een gelabeld blok met een stabiele locatie-ID produceert een vermelding die veld voor veld kan worden vergeleken.

Consistentie moet worden behandeld als een controleerbaar gegevensprobleem, niet als een typografieritueel. Normaliseer hoofdletters/kleine letters, Unicode, spaties, straatachtervoegsels, eenheidsaanduidingen, postcodes, landcodes en telefooncijfers voordat u vermeldingen vergelijkt. ‘1200 Example Ave., Ste 210’ en ‘1200 Example Avenue, Suite 210’ kunnen naar hetzelfde adres normaliseren; ‘Suite 120’ niet. Evenzo kunnen (202) 555-0147 en +1 202-555-0147 hetzelfde nummer vertegenwoordigen, terwijl een calltrackingnummer bewust kan afwijken en moet worden geregistreerd als een goedgekeurd alias met zijn routeringseigenaar.

Wanneer te gebruiken

Gebruik een NAP-blok wanneer een pagina een fysieke bedrijfslocatie vertegenwoordigt die klanten mogelijk bezoeken, bellen, mailen, verifiëren of van een andere vestiging willen onderscheiden. Het is vereist op locatie- en vestigingspagina’s, nuttig in gecontroleerde bedrijvengidsvermeldingen en geschikt op een bedrijfsprofiel wanneer het adres daadwerkelijk deel uitmaakt van de publieke identiteit.

Maak één blok per locatie. Een index met meerdere locaties mag twintig blokken weergeven, maar moet twintig afzonderlijke vermeldingen tonen in plaats van één bedrijfsnaam gevolgd door een gemengde lijst van adressen en nummers. Elke instantie moet naar een locatie-ID verwijzen, zodat een contentsysteem niet het adres van vestiging A kan koppelen aan de telefoon van vestiging B.

Bijna-juiste gevallen vereisen een andere aanpak:

• Een servicegebied-bedrijf zonder klantgerichte locatie mag het thuisadres van de eigenaar niet publiceren. Vermeld het servicegebied en de contactroute zonder te doen alsof er een bezoekbare NAP-locatie is.
• Een postbus, adres van een gemachtigde, factuuradres, magazijn en retouradres zijn niet uitwisselbaar met een klantlocatie. Label elk operationeel doel en houd het buiten het primaire blok, tenzij dat het adres is dat klanten wordt geïnstrueerd te gebruiken.
• Openingstijden, afspraakbeschikbaarheid, routebeschrijvingen, parkeer- en toegankelijkheidsgegevens mogen naast het blok staan, maar zijn aparte feiten met aparte updatecycli.
• Een calltrackingnummer is niet automatisch inconsistent. Het is acceptabel wanneer de routering betrouwbaar is, het eigendom en de canonical bestemming gedocumenteerd zijn en het zichtbare nummer niet onvoorspelbaar verandert voor crawlers of terugkerende gebruikers.
• Een online-only bedrijf kan een juridisch adres hebben voor naleving, maar geen lokale locatie. Maak van een juridische melding geen lokale-aanwezigheidsmarketing.
• Een zorgverlener in een kliniek heeft mogelijk een zorgverlenersregistratie nodig en de kliniek een locatieregistratie. Voeg hun namen en telefoonnummers niet samen tot een hybride identiteit.

De schrijfregels voor elementen hebben voorrang: kies het element op basis van het doel van de passage. Als de passage tot doel heeft een canonical naam, adres en telefoon van een locatie te vermelden, gebruik dan een NAP-blok, zelfs wanneer een generieke kaart of footer soortgelijke tekst zou kunnen weergeven.

Waar te plaatsen

Plaats op een speciale locatiepagina het primaire NAP-blok onmiddellijk na de openingsidentificatie en het directe antwoord, vóór routebeschrijvingen, openingstijden, diensten, beoordelingen of boekingsmogelijkheden. De lezer moet weten welke locatie de pagina vertegenwoordigt voordat hij een lokale claim interpreteert. Als de hero al de volledige canonical vermelding weergeeft, mag het latere contactgedeelte deze alleen herhalen vanuit hetzelfde gegevensobject.

Zet het op een bedrijfsprofiel in een duidelijk gelabelde sectie ‘Hoofdkantoor’ of ‘Openbare contactlocatie’ in plaats van onder een generieke kop ‘Over ons’. Zet op een bedrijvengidsindex één compact blok in elke overeenkomstige vermelding en link de gehele identiteitsgroep naar het juiste vestigingsprofiel. Gebruik in een sitefooter alleen de primaire openbare locatie of een expliciete locatieselector; een footer is te krap voor een ongelabelde mix van meerdere kantoren.

Het blok mag naast openingstijden, een kaart, routebeschrijvingen, parkeerinformatie of een boekingsactie staan, alleen wanneer elk aangrenzend component dezelfde locatie-ID gebruikt. Het mag niet naast een kaartmarkering voor een andere ingang staan, een organisatiebrede centrale naast een vestigingslijn, een alleen-voor-bezorging magazijnadres, of een locatieselector waarvan de huidige selectie onduidelijk is. Plaats geen advertentie, getuigenis, nieuwsbriefformulier of promotionele aanbieding tussen de naam en het adres of tussen het adres en de telefoon. Die onderbrekingen breken de vermelding visueel en in leesvolgorde.

Behoud op mobiel de volgorde naam, straat, plaats, regio en postcode, land indien nodig, dan telefoon. Laat een plakkerige belknop het zichtbare nummer niet vervangen of verdoezelen welke vestiging wordt gebeld.

Anatomie

1. Locatienaam: de goedgekeurde klantgerichte naam, inclusief een vestigingstoevoeging alleen wanneer deze consistent wordt gebruikt.
2. Straatadres: het bezorgvalide straatnummer en -naam, geen oriëntatiepuntbeschrijving.
3. Sublocatie: een suite, unit, verdieping, gebouw of afdeling die nodig is om de juiste bestemming te bereiken.
4. Plaats en regio: de stad of plaats plus de bestuurde staat, provincie, county of regio-waarde.
5. Postcode en land: de volledige routeringscode en het land, inclusief land wanneer het publiek of de syndicatie landsgrenzen overschrijdt.
6. Weergavetelefoon: het voor mensen leesbare nummer, geformatteerd voor het publiek van de locatie.
7. Telefoondoel: hetzelfde nummer genormaliseerd om te bellen, normaal in E.164-formaat binnen een tel:-link.
8. Locatie-ID: een stabiele interne sleutel die voorkomt dat vestigingsgegevens worden gemengd tijdens weergave of syndicatie.
9. Verificatiemetadata: de datum en het gezaghebbende systeem of eigenaar waartegen de vermelding is gecontroleerd.

Ontwerpvoorbeelden

Elke variant gebruikt dezelfde onderliggende locatievermelding. Dichtheid en omringende acties mogen veranderen, maar de renderer mag geen suite afkorten, een organisatiebreed nummer in de plaats stellen of een adres verbergen dat nodig is om de vestiging te onderscheiden.

Standaard locatie. De standaardvariant toont elk component in een verticale, gemakkelijk te kopiëren groep. Gebruik dit op een speciale locatie- of vestigingspagina.

Compacte contactbalk. Gebruik dit in een footer of contactbalk wanneer één openbare locatie de pagina vertegenwoordigt. Het mag op smalle schermen samenvouwen tot rijen, maar mag de unit, postcode of telefoon niet afkappen.

Bedrijvengidskaart. Herhaal één compacte NAP-instantie per locatie. Houd filters, afstand, ’nu open’ en servicelabels buiten de identiteitsvelden zodat dynamische toestanden de canonical vermelding niet kunnen herschrijven.

Alleen-op-afspraak locatie. Toon het volledige openbare NAP wanneer klanten mogen bezoeken, voeg dan ‘Afspraak verplicht’ toe als een aparte operationele notitie. Plaats de frase niet in de adresregel.

Internationaal. Behoud de adresvolgorde die in het bestemmingsland wordt verwacht terwijl elk component afzonderlijk wordt opgeslagen. Toon de lokale telefoonconventie voor lezers en behoud een internationale belwaarde voor de link en de gegevenslaag.

Parameters

‘Bron’ hieronder betekent waar de renderer een veld verkrijgt. Het beheerde locatieregister van het bedrijf, niet de artikeltekst, blijft gezaghebbend voor identiteitswaarden.

Sla componenten afzonderlijk op, zelfs wanneer de renderer ze voor weergave samenvoegt. Een enkele address="1200 Example Avenue, Washington..."-klomp verhindert landspecifieke ordening, betrouwbare vergelijkingen en gerichte correctie van een verkeerde suite of postcode.

Syntax en codevoorbeelden

Alle drie de vormen coderen dezelfde locatie-ID en canonical velden. De draagbare richtlijn is het geschreven contract; een project moet zijn Hugo- en WordPress-adapters registreren en testen voordat de syntax wordt gepubliceerd.

Draagbare Markdown-richtlijn

:::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 >}}

Alle shortcodeparameters zijn benoemd. De adapter moet tekst escapen, een <address>-groep en tel:-link genereren, de locatie-ID aan de gegevenslaag blootstellen en de body-notitie buiten het postadres behouden.

WordPress-blok

<!-- 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 -->

Het WordPress-blok moet getypeerde inspectievelden en serverrendering gebruiken. Auteurs mogen een locatievermelding kiezen en een goedgekeurde notitie toevoegen, maar moeten de canonical naam, het adres of de telefoon niet opnieuw typen in Rich Text.

Voorbeelden

Goed: één complete, toerekenbare locatie

Northstar Heating — Capitol Hill
1200 Example Avenue, Suite 210
Washington, DC 20001, United States
(202) 555-0147
Locatie NSH-DC-01 · Geverifieerd op 27 augustus 2026 tegen het goedgekeurde locatieregister

Dit werkt omdat de vestigingstoevoeging, suite, postcode, land, weergavenummer, beldoel, stabiele ID, datum en bron allemaal één vermelding beschrijven. Een lezer kan bezoeken of bellen; een crawler kan dezelfde waarden extraheren; een auditor kan het blok vergelijken met een bedrijvengidsvermelding zonder te raden welk kantoor de pagina beheert.

Slecht: een aannemelijk ogend samenstel

Northstar Heating Washington
Nabij Capitol Hill, Washington DC
Bel ons team: 555-0147 of het hoofdkantoor
Open bij u in de buurt

Dit faalt omdat ‘Nabij Capitol Hill’ geen bezorgbaar adres is, het lokale nummer geen regio- en landcontext heeft, ‘hoofdkantoor’ geen nummer heeft en de naam geen beheerde vestiging identificeert. ‘Open bij u in de buurt’ mengt openingstijden en nabijheid met identiteit zonder locatie- of tijdsbasis. Het blok kan niet met vertrouwen worden gekoppeld aan een kaartvermelding, bedrijvengidscitatie, schema-entiteit of interne bron.

Repareer het door de exacte locatie-ID te selecteren, elk veld uit het register op te lossen, het volledige openbare adres en bewaakte telefoonnummer te publiceren, en openingstijden of nabijheidsclaims naar eigen componenten te verplaatsen.

Schema-opmaak en toegankelijkheid

Een NAP-blok kan een in aanmerking komende Organization, LocalBusiness-subtype of andere op een locatie gebaseerde entiteit voeden. Wijs de zichtbare name, telephone en adrescomponenten toe aan een PostalAddress: streetAddress, addressLocality, addressRegion, postalCode en addressCountry. Gebruik het meest specifieke waarheidsgetrouwe bedrijfstype dat door de pagina wordt ondersteund; kies geen categorie alleen om een zoekfunctie te krijgen.

Gestructureerde gegevens moeten dezelfde locatie identificeren als de pagina. Plaats het hoofdkantoor niet in JSON-LD terwijl een vestiging in het blok wordt getoond, combineer meerdere vestigingen niet in één adres, en voeg geen lengte- en breedtegraad toe die uit een postcode zijn geraden. Als elke vestiging een eigen pagina en persistente entiteit heeft, gebruik dan een stabiele canonical URL en beheerde ID om de grafiek gescheiden te houden. De verificatiedatum en bron ondersteunen intern beheer, maar vereisen geen openbare Schema.org-eigenschappen.

Gebruik een <address>-element voor de contactinformatie van de locatie die de pagina of sectie vertegenwoordigt. Neem niet aan dat <address> elk postadres betekent; de HTML-betekenis is contactinformatie voor de relevante artikel- of paginaeigenaar. Houd de locatienaam in een kop, label herhaalde bedrijvengidskaarten en behoud een logische bronvolgorde.

Het zichtbare telefoonnummer moet tekst blijven, geen pictogram of afbeelding. Link het met href="tel:+12025550147" wanneer bellen gepast is, maar behoud een leesbare lokale weergave. Splits afzonderlijke cijfers niet in opgemaakte spans, spreek interpunctie niet uit via een onnauwkeurig toegankelijk label en verberg essentiële extensies niet in een tooltip. Zorg dat het toetsenbordfocus zichtbaar is, het linkdoel de vestiging omvat wanneer meerdere bellinks samen verschijnen, en dat in- of uitzoomen of herschikken de suite of postcode niet van het adres scheidt.

Schrijfregels

Deze regels beschermen eerst de identiteitsresolutie; visuele netheid is secundair:

• Gebruik precies één klantgerichte naam, één adres en één primair telefoonnummer per blok. Als een secundair nummer operationeel noodzakelijk is, label dan het doel ervan buiten het canonical NAP-drietal.
• Houd de naam op 2–100 tekens. Gebruik het echte publieke merk en een beheerde vestigingstoevoeging; voeg geen trefwoorden toe zoals ‘beste noodloodgieter in Washington.’
• Gebruik 1–3 adresregels, elk niet langer dan 100 tekens. Behoud suite, unit, verdieping, gebouw en richtingsinformatie die nodig is voor bezorging of aankomst.
• Gebruik een volledig postadres voor openbare locaties. Vervang het nooit door ‘centrum’, ’nabij het station’, een kaartmarkering of routebeschrijvingen.
• Sla het land op als een tweeletterige code en geef de voor mensen leesbare naam weer wanneer de publiekscontext dit vereist. Leid een land nooit alleen af uit een topleveldomein.
• Sla telefoonnummers op in E.164-vorm en geef een vertrouwde lokale vorm weer. Neem een toestelnummer op als aparte beheerde waarde wanneer routering ervan afhangt.
• Gebruik een feitelijke, administratieve toon. Het blok mag ‘Afspraak verplicht’ of ‘Geen openbare toegang’ zeggen; het mag geen slogans, serviceclaims, beoordelingen, prijzen, kortingen, urgentie of trefwoordlijsten bevatten.
• Plaats geen openingstijden, routebeschrijvingen, parkeerinstructies, servicegebieden, boekingsmogelijkheden, e-mailadressen, faxnummers of socialemediaprofielen in de drie identiteitsvelden. Aangrenzende gelabelde velden zijn acceptabel wanneer hun eigendom en updatefrequentie duidelijk zijn.
• Herschrijf een canonical waarde niet stilzwijgend om overeen te komen met één externe bedrijvengids. Onderzoek of de externe vermelding verouderd is, een goedgekeurd alias of een daadwerkelijk andere locatie, en corrigeer vervolgens de juiste bron.
• Registreer een verificatiedatum en bron voor elke gepubliceerde instantie. Verifieer opnieuw na verhuizingen, herbrandingen, telefoonrouteringswijzigingen, fusies, vestigingssluitingen, suitewijzigingen en bedrijvengidsmigraties.
• Behandel interpunctie en afkortingen als presentatieverschillen alleen nadat normalisatie aantoont dat de onderliggende componenten matchen. Een gewijzigd cijfer, suite, postcode of vestigingstoevoeging is inhoudelijk.

Posttypes die het gebruiken

De tabel wordt beheerd door postTypes[] in de frontmatter. Voeg een rij alleen toe of verwijder deze alleen wanneer de bijbehorende array verandert.

QA-checklist

• Het blok wordt opgelost vanuit één stabiele locatie-ID in plaats van onafhankelijk getypte velden.
• De openbare naam komt overeen met het beheerde merk en het vestigingsnaamgevingsbeleid zonder trefwoordtoevoegingen.
• Het straatnummer, de straatnaam, richtingsaanduiding, suite of unit, plaats, regio, postcode en land zijn gecontroleerd tegen de gezaghebbende bron.
• Het adres is geldig voor de gestelde klantactie: bezoeken, mailen, ophalen of een ander expliciet gelabeld doel.
• Privéwoningen, adressen van gemachtigden, magazijnen en virtuele kantoren worden niet gepresenteerd als klantlocaties.
• Het weergegeven telefoonnummer en het tel:-doel normaliseren naar dezelfde bewaakte bestemming.
• Nabijgelegen openingstijden, kaart, routebeschrijvingen, boekings- en CTA-componenten gebruiken dezelfde locatie-ID.
• Geen aangrenzend blok spreekt het adres, telefoonnummer, vestigingsnaam, bezoekbeleid of locatieselectie tegen.
• Genormaliseerde vergelijking onderscheidt onschuldige opmaakverschillen van gewijzigde cijfers, eenheden of postcomponenten.
• Zichtbare inhoud en Organization-, LocalBusiness- of PostalAddress-opmaak komen veld voor veld overeen.
• Herhaalde blokken hebben unieke koppen of toegankelijke labels, en elke telefoonlink heeft een duidelijk doel.
• De volledige vermelding blijft leesbaar, kopieerbaar, toegankelijk met toetsenbord en correct geordend bij 200% zoom en op een smal scherm.
• Verificatiedatum en bron zijn aanwezig en een benoemde eigenaar ontvangt afwijkingsmeldingen.
• Verhuizingen, sluitingen, herbrandingen, nummerwijzigingen en goedgekeurde aliassen hebben een updatepad voor de website, profielen, bedrijvengidsen en gegevensfeeds.

FAQ

Wat betekent NAP in lokale SEO?

NAP staat voor naam, adres en telefoon. Een NAP-blok publiceert deze drie identiteitsgegevens voor één bedrijfslocatie in een canonical, gelabelde vorm die mensen en machines kunnen ophalen zonder gegevens uit verschillende vestigingen te combineren.

Moet de interpunctie op elke website identiek zijn?

Nee. Onschuldige presentatieverschillen zoals ‘Suite’ versus ‘Ste.’ of lokaal geformatteerde versus internationale telefoonweergave creëren geen andere entiteit wanneer de onderliggende waarden naar dezelfde feiten normaliseren. Controleer genormaliseerde velden, terwijl u één voorkeursweergave onder uw controle houdt.

Moet een servicegebied-bedrijf een thuisadres publiceren?

Nee. Stel een privé- of voor klanten niet-bruikbaar adres niet bloot alleen om het blok compleet te maken. Publiceer de klantgerichte bedrijfsnaam en bewaakte telefoon, vermeld dat diensten op locatie van de klant worden verleend en bewaar privéadressen in beheerde systemen die dit daadwerkelijk vereisen.

Kan één NAP-blok meerdere vestigingen bevatten?

Nee. Eén blok vertegenwoordigt één locatievermelding. Een bedrijvengids mag het component één keer per vestiging herhalen, maar elke instantie heeft een eigen locatie-ID, adres, telefoon, bron en bestemmingspagina nodig zodat gegevens niet per ongeluk kunnen worden gecombineerd.

Hoe vaak moet NAP-informatie worden gecontroleerd?

Controleer het telkens wanneer een locatie, nummer, naamgevingsbeleid of bedrijvengidsvermelding verandert, en neem het op in een terugkerende lokale-gegevensaudit. Het juiste interval hangt af van de operationele veranderingssnelheid; het blok moet de laatste verificatiedatum en gezaghebbende bron registreren, in plaats van permanente nauwkeurigheid te suggereren.