NAP-blokke: Kanonisk navn, adresse og telefon

En NAP-blok publicerer en virksomhedslokations navn, adresse og telefonnummer i én kanonisk registrering. “Kanonisk” betyder, at organisationen har valgt én autoritativ underliggende værdi for hvert felt, selv når en mappe forkorter gaden, eller et telefonlink bruger et internationalt maskinformateret nummer.

Det gengivne element er bevidst uopsigtsvækkende. Dets opgave er identitet, ikke overtalelse: én lokation, ét kundevendt navn, én leveringsdygtig adresse, ét overvåget nummer og tilstrækkelig proveniens til at revidere alle kopier mod kilden.

Hvorfor dette element er vigtigt

Lokale beslutninger har en høj omkostning ved at være forkerte. En læser vælger måske, hvorhen de skal køre, hvilken afdeling de skal ringe til, hvor de skal sende et dokument, eller om en virksomhed betjener deres område. Når footeren viser et hovedkontornummer, lokationssiden viser et afdelingsnummer, og kortpanelet peger på en gammel indgang, må læseren gætte, hvilket faktum der styrer den næste handling. Den usikkerhed skader tilliden, før en samtale overhovedet begynder.

Den psykologiske fordel er tryghed gennem specificitet. En komplet gadeadresse signalerer, at siden beskriver et virkeligt sted frem for en generisk by-målrettet landingsside. Et lokationsspecifikt telefonnummer fortæller læseren, hvem de vil få fat i. Et stabilt navn hjælper dem med at genkende den samme afdeling i søgeresultater, kort, anmeldelsesplatforme, fakturaer og skiltning. Ingen af disse detaljer beviser servicekvalitet, men tilsammen fjerner de unødig tvivl om identitet og adgang.

Maskinudvindelighed er evnen hos en crawler, søgemaskine, mappe, assistent eller syndikeringsproces til at bevare hver værdi og dens relation til én lokation. En sætning som “Ring til vores Washington-team nær Capitol Hill” kan lyde naturlig, men den eksponerer ikke en komplet postadresse eller en utvetydig telefonværdi. En mærket blok med et stabilt lokations-ID producerer en registrering, der kan sammenlignes felt for felt.

Konsistens bør behandles som et reviderbart dataproblem, ikke en typografiritual. Normaliser versaler, Unicode, mellemrum, gadesuffikser, enhedsidentifikatorer, postnumre, landekoder og telefoncifre, før du sammenligner registreringer. “1200 Example Ave., Ste 210” og “1200 Example Avenue, Suite 210” kan normaliseres til samme adresse; “Suite 120” gør ikke. Ligeledes kan (202) 555-0147 og +1 202-555-0147 repræsentere samme nummer, mens et opkaldssporingsnummer måske bevidst adskiller sig og skal registreres som en godkendt alias med sin routing-ejer.

Hvornår skal det bruges

Brug en NAP-blok, når en side repræsenterer en fysisk virksomhedslokation, som kunder kan besøge, ringe til, sende post til, verificere eller skelne fra en anden afdeling. Den er påkrævet på lokations- og afdelingssider, nyttig i kontrollerede mapperegistreringer og passende på en virksomhedsprofil, når adressen reelt er en del af den offentlige identitet.

Opret én blok pr. lokation. Et multi-lokationsindeks kan gengive tyve blokke, men det skal gengive tyve separate registreringer frem for ét firmanavn efterfulgt af en blandet liste af adresser og numre. Hver instans bør løses til et lokations-ID, så et indholdssystem ikke kan parre Afdeling A’s adresse med Afdeling B’s telefon.

Næsten-missere kræver forskellig behandling:

• En serviceområdevirksomhed uden kundevendte lokaler bør ikke offentliggøre ejerens hjemmeadresse. Angiv serviceområdet og kontaktvejen uden at foregive, at der er en besøgbar NAP-lokation.
• En postboks, registreret agentadresse, faktureringsadresse, lageradresse og returadresse kan ikke ombyttes med en kundelokation. Mærk hvert operationelt formål og hold det uden for den primære blok, medmindre det er den adresse, kunder får besked på at bruge.
• Åbningstider, tidsbestillingsmuligheder, kørselsvejledning, parkering og tilgængelighedsoplysninger kan ligge i nærheden af blokken, men de er separate fakta med separate opdateringscyklusser.
• Et opkaldssporingsnummer er ikke automatisk inkonsistent. Det er acceptabelt, når routing er pålidelig, ejerskab og kanonisk destination er dokumenteret, og det synlige nummer ikke ændrer sig uforudsigeligt for crawlers eller returnerende brugere.
• En online-only virksomhed kan have en juridisk adresse til overholdelse, men ingen fysisk lokation. Gør ikke en juridisk oplysning til lokal tilstedeværelsesmarkedsføring.
• En praktiserende læge inde i en klinik kan have brug for en praktiserende registrering, og klinikken kan have brug for en lokationsregistrering. Sammenbland ikke deres navne og telefonnumre til en hybrid identitet.

Elementets skriveregler har forrang: vælg elementet ud fra afsnittets formål. Hvis afsnittets opgave er at angive en lokations kanoniske navn, adresse og telefon, så brug en NAP-blok, selv når et generisk kort eller en footer kunne vise lignende tekst.

Hvor skal det placeres

På en dedikeret lokationsside placeres den primære NAP-blok umiddelbart efter åbningsidentifikationen og det direkte svar, før kørselsvejledning, åbningstider, services, anmeldelser eller bookingfunktioner. Læseren bør vide, hvilket sted siden repræsenterer, før de fortolker nogen lokal påstand. Hvis hero-sektionen allerede gengiver den fulde kanoniske registrering, kan den senere kontaktsektion gentage den kun fra det samme dataobjekt.

På en virksomhedsprofil placeres den i et tydeligt mærket afsnit “Hovedkontor” eller “Offentlig kontaktlokation” frem for under en generisk “Om”-overskrift. På et mappeindeks placeres én kompakt blok inde i hver tilsvarende listing og linkes hele identitetsgruppen til den korrekte afdelingsprofil. I en sidefooter bruges kun den primære offentlige lokation eller en eksplicit lokationsvælger; en footer er for trang til en umærket blanding af flere kontorer.

Blokken må stå ved siden af åbningstider, et kort, kørselsvejledning, parkeringsoplysninger eller en bookinghandling, kun når hver tilstødende komponent bruger det samme lokations-ID. Den må ikke stå ved siden af et kortpunkt for en anden indgang, en organisationsomspændende omstilling mærket som en afdelingslinje, en leverings-only lageradresse eller en lokationsvælger, hvis nuværende valg er uklart. Placer ikke en annonce, testimonial, nyhedsbrevsformular eller kampagnetilbud mellem navnet og dets adresse eller mellem adressen og telefonen. Disse afbrydelser bryder registreringen visuelt og i læserækkefølge.

På mobil bevares rækkefølgen navn, gade, lokalitet, region og postnummer, land når det er nødvendigt, derefter telefon. Lad ikke en sticky opkaldsknap erstatte det synlige nummer eller skjule, hvilken afdeling den ringer til.

Anatomi

1. Lokationsnavn: det godkendte kundevendte navn, inklusive en afdelingskvalifikation kun når det bruges konsekvent.
2. Gadeadresse: det leveringsgyldige gadenummer og -navn, ikke en vartegnsbeskrivelse.
3. Underlokation: en suite, enhed, etage, bygning eller afdeling, der er nødvendig for at nå den korrekte destination.
4. Lokalitet og region: byen eller lokaliteten plus den styrede stat, provins, county eller regionsværdi.
5. Postnummer og land: den komplette routingkode og land, inklusive land når målgruppen eller syndikeringen krydser grænser.
6. Visningstelefon: det menneskelæsbare nummer formateret til lokationens målgruppe.
7. Telefonmål: det samme nummer normaliseret til opkald, normalt i E.164-format inde i et tel: link.
8. Lokations-ID: en stabil intern nøgle, der forhindrer, at afdelingsdetaljer blandes under gengivelse eller syndikering.
9. Verifikationsmetadata: datoen og det autoritative system eller ejer, som registreringen blev kontrolleret mod.

Designeksempler

Hver variant bruger den samme underliggende lokationsregistrering. Tæthed og omkringliggende handlinger kan ændre sig, men rendereren må ikke forkorte en suite, erstatte med et organisationsomspændende nummer eller skjule en adresse, der er nødvendig for at skelne afdelingen.

Standardlokation. Standardvarianten viser hver komponent i en vertikal, let-kopiérbar gruppe. Brug den på en dedikeret lokations- eller afdelingsside.

Kompakt kontaktbånd. Brug i en footer eller kontaktbånd, når én offentlig lokation repræsenterer siden. Det kan kollapse til rækker på smalle skærme, men må ikke afkorte enheden, postnummeret eller telefonen.

Mappekort. Gentag én kompakt NAP-instans pr. lokation. Hold filtre, afstand, “åben nu” og servicemærkater uden for identitetsfelterne, så dynamiske tilstande ikke kan overskrive den kanoniske registrering.

Kun-tidsbestilling lokation. Vis den fulde offentlige NAP, når kunder har tilladelse til at besøge, tilføj derefter “Tidsbestilling påkrævet” som en separat operationel note. Indsæt ikke sætningen i adresselinjen.

International. Bevar den adresserækkefølge, der forventes i destinationslandet, mens hver komponent opbevares separat. Vis den lokale telefonkonvention for læsere og behold en international opkaldsværdi til linket og datalaget.

Parametre

“Kilde” nedenfor betyder, hvor rendereren henter et felt. Virksomhedens styrede lokationsregister, ikke artikelteksten, forbliver autoritativ for identitetsværdier.

Opbevar komponenter separat, selv når rendereren sammenføjer dem til visning. En enkelt address="1200 Example Avenue, Washington..." klump forhindrer landespecifik sortering, pålidelige sammenligninger og målrettet korrektion af en forkert suite eller et forkert postnummer.

Syntaks og kodeeksempler

Alle tre former koder det samme lokations-ID og kanoniske felter. Det bærbare direktiv er den forfattede kontrakt; et projekt skal registrere og teste sine Hugo- og WordPress-adaptere, før syntaksen publiceres.

Bærbart Markdown-direktiv

:::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: Besøg efter tidsbestilling.
:::

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: Besøg efter tidsbestilling.
{{< /nap >}}

Alle shortcode-parametre er navngivne. Adapteren skal escape tekst, generere en <address>-gruppe og tel: link, eksponere lokations-ID’et til datalaget og bevare brødtekstnoten uden for postadressen.

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-gengivet fra kanoniske lokationsfelter.</div>
<!-- /wp:amicited/nap -->

WordPress-blokken bør bruge typed inspektionsfelter og servergengivelse. Forfattere kan vælge en lokationsregistrering og tilføje en godkendt note, men bør ikke gentaste det kanoniske navn, adresse eller telefon i Rich Text.

Eksempler

Godt: én komplet, tilskrivningsbar lokation

Northstar Heating — Capitol Hill
1200 Example Avenue, Suite 210
Washington, DC 20001, United States
(202) 555-0147
Lokation NSH-DC-01 · Verificeret 27. august 2026 mod det godkendte lokationsregister

Dette virker, fordi afdelingskvalifikationen, suite, postnummer, land, displaynummer, opkaldsmål, stabil ID, dato og alle kilde beskriver én registrering. En læser kan besøge eller ringe; en crawler kan udtrække de samme værdier; en revisor kan sammenligne blokken med en mappeoptagelse uden at gætte på, hvilket kontor der styrer siden.

Dårligt: en plausibel sammensætning

Northstar Heating Washington
Nær Capitol Hill, Washington DC
Ring til vores team: 555-0147 eller hovedkontoret
Åbent nær dig

Dette fejler, fordi “nær Capitol Hill” ikke er en leveringsdygtig adresse, det lokale nummer mangler område- og landekontekst, “hovedkontoret” har intet nummer, og navnet identificerer ikke en styret afdeling. “Åbent nær dig” blander åbningstider og nærhed ind i identitet uden et lokations- eller tidsgrundlag. Blokken kan ikke matches med sikkerhed til en kortregistrering, mappehenvisning, skemaenhed eller intern kilde.

Reparér den ved at vælge det præcise lokations-ID, løs hvert felt fra registret, publicér den komplette offentlige adresse og overvågede telefon, og flyt åbningstider eller nærhedspåstande til deres egne komponenter.

Skemamarkering og tilgængelighed

En NAP-blok kan fodre en berettiget Organization, LocalBusiness-undergruppe eller anden stedsbaseret enhed. Kortlæg de synlige name, telephone og adressekomponenter til en PostalAddress: streetAddress, addressLocality, addressRegion, postalCode og addressCountry. Brug den mest specifikke sandfærdige virksomhedstype, der understøttes af siden; vælg ikke en kategori udelukkende for at opnå en søgefunktion.

Strukturerede data skal identificere den samme lokation, som siden identificerer. Placer ikke virksomhedens hovedkvarter i JSON-LD, mens du viser en afdeling i blokken, kombiner ikke flere afdelinger til én adresse, eller tilføj bredde- og længdegrad gættet ud fra et postnummer. Hvis hver afdeling har sin egen side og vedvarende enhed, brug en stabil kanonisk URL og styret identifikator til at holde grafen separat. Verifikationsdatoen og kilden understøtter intern styring, men kræver ikke offentlige Schema.org-egenskaber.

Brug et <address>-element til kontaktinformationen for den lokation, siden eller sektionen repræsenterer. Antag ikke, at <address> betyder en hvilken som helst postadresse; dets HTML-betydning er kontaktinformation for den relevante artikel eller sideejer. Hold lokationsnavnet i en overskrift, mærk gentagne mappekort, og bevar en logisk kildeorden.

Det synlige telefonnummer skal forblive tekst, ikke et ikon eller billede. Link det med href="tel:+12025550147" når det er passende at ringe, men behold en læsbar lokal visning. Opdel ikke individuelle cifre i stylede spans, udtal ikke tegnsætning gennem en unøjagtig tilgængelig etiket, eller skjul væsentlige udvidelser i et tooltip. Sørg for, at tastaturfokus er synligt, linkformålet inkluderer afdelingen, når flere opkaldlinks optræder sammen, og zoom eller reflow ikke adskiller suite eller postnummer fra adressen.

Skriveregler

Disse regler beskytter identitetsopløsning først; visuel pænhed er sekundær:

• Brug præcis ét kundevendt navn, én adresse og én primær telefon pr. blok. Hvis et sekundært nummer er operationelt nødvendigt, mærk dets formål uden for den kanoniske NAP-trekløver.
• Hold navnet på 2–100 tegn. Brug det reelle offentlige brand og en styret afdelingskvalifikation; tilføj ikke søgeord som “bedste akutte VVS i Washington.”
• Brug 1–3 gadelinjer, hver højst 100 tegn. Bevar suite, enhed, etage, bygning og retningsinformation, der kræves til levering eller ankomst.
• Brug en komplet postadresse for offentlige lokaler. Erstat den aldrig med “centrum,” “nær stationen,” et kortpunkt eller kørselsvejledning.
• Opbevar landet som en to-bogstavs kode og gengiv dets menneskelæsbare navn, når målgruppekontekst kræver det. Udled aldrig et land alene fra et topdomæne.
• Opbevar telefonnumre i E.164-form og gengiv en velkendt lokal form. Inkludér en omstilling som en separat styret værdi, når routing afhænger af den.
• Brug en faktuel, administrativ tone. Blokken må sige “Tidsbestilling påkrævet” eller “Ingen offentlig adgang”; den må ikke indeholde slogans, servicepåstande, anmeldelser, priser, rabatter, uopsættelighed eller søgeordslister.
• Placer ikke åbningstider, kørselsvejledning, parkeringsinstruktioner, serviceområder, bookingsmuligheder, e-mailadresser, faxnumre eller sociale profiler inde i de tre identitetsfelter. Tilstødende mærkede felter er acceptable, når deres ejerskab og opdateringsrytme er tydelig.
• Overskriv ikke stille en kanonisk værdi for at matche en tredjeparts mappe. Undersøg, om den eksterne registrering er forældet, en godkendt alias eller en reelt anden lokation, ret derefter den relevante kilde.
• Registrér en verifikationsdato og kilde for hver offentliggjort instans. Genverificér efter flytninger, rebrandinger, telefonrouting-ændringer, fusioner, afdelingslukninger, suiteændringer og mappemigrationer.
• Behandl tegnsætning og forkortelser som præsentationsforskelle kun efter normalisering beviser, at de underliggende komponenter matcher. Et ændret ciffer, suite, postnummer eller afdelingskvalifikation er væsentligt.

Posttyper, der bruger det

Tabellen styres af postTypes[] i frontmatter. Tilføj eller fjern en række kun når det tilsvarende array ændres.

QA-tjekliste

• Blokken løses fra ét stabilt lokations-ID frem for uafhængigt indtastede felter.
• Det offentlige navn matcher det styrede brand og afdelingsnavngivningspolitik uden søgeordstilføjelser.
• Gadenummer, gadenavn, retningsangivelse, suite eller enhed, lokalitet, region, postnummer og land blev kontrolleret mod den autoritative kilde.
• Adressen er gyldig for den angivne kundehandling: besøg, postforsendelse, afhentning eller et andet eksplicit mærket formål.
• Private hjem, registrerede agentkontorer, varehuse og virtuelle kontorer præsenteres ikke som kundelokationer.
• Den viste telefon og tel:-mål normaliseres til den samme overvågede destination.
• Nærliggende åbningstider, kort, kørselsvejledning, booking og CTA-komponenter bruger det samme lokations-ID.
• Ingen tilstødende blok modsiger adressen, telefonen, afdelingsnavnet, besøgspolitikken eller lokationsvalget.
• Normaliseret sammenligning skelner harmløse formateringsforskelle fra ændrede cifre, enheder eller postkomponenter.
• Synligt indhold og Organization, LocalBusiness eller PostalAddress markup stemmer overens felt for felt.
• Gentagne blokke har unikke overskrifter eller tilgængelige etiketter, og hvert telefonlink har et klart formål.
• Den komplette registrering forbliver læsbar, kopierbar, tastaturtilgængelig og korrekt ordnet ved 200 % zoom og på en smal skærm.
• Verifikationsdato og kilde er til stede, og en navngiven ejer modtager afvigelsesrapporter.
• Flytninger, lukninger, rebrandinger, nummerændringer og godkendte aliaser har en opdateringsvej på tværs af hjemmesiden, profiler, mapper og datafeeds.

FAQ

Hvad betyder NAP i lokal SEO?

NAP står for navn, adresse og telefon. En NAP-blok publicerer disse tre identitetsoplysninger for én virksomhedslokation i en kanonisk, mærket form, som mennesker og maskiner kan hente uden at blande oplysninger fra forskellige afdelinger.

Skal tegnsætningen være identisk på alle hjemmesider?

Nej. Harmløse præsentationsforskelle som “Suite” versus “Ste.” eller lokalt formateret versus international telefonvisning skaber ikke en anden enhed, når de underliggende værdier normaliseres til de samme fakta. Revider normaliserede felter, mens du beholder én foretrukken visningsform under din kontrol.

Bør en serviceområdevirksomhed offentliggøre en hjemmeadresse?

Nej. Eksponér ikke en privat eller kunde-uattraktiv adresse blot for at færdiggøre blokken. Offentliggør det kundevendte firmanavn og den overvågede telefon, angiv at service leveres på kundens lokation, og hold eventuelle private adresser i styrede systemer, der reelt kræver dem.

Kan én NAP-blok indeholde flere afdelinger?

Nej. Én blok repræsenterer én lokationsregistrering. En mappe kan gentage komponenten én gang pr. afdeling, men hver instans har brug for sin egen lokationsidentifikator, adresse, telefon, kilde og destinationsside, så oplysninger ikke kan blandes utilsigtet.

Hvor ofte bør NAP-oplysninger kontrolleres?

Tjek dem, når en lokation, et nummer, en navngivningspolitik eller en mappeændring finder sted, og inkludér det i en tilbagevendende lokaldata-revision. Det passende interval afhænger af den operationelle ændringshastighed; blokken bør registrere sin sidste verifikationsdato og autoritative kilde snarere end at antyde permanent nøjagtighed.