NAP-blokker: Kanonisk navn, adresse og telefon

En NAP-blokk publiserer en forretningslokasjons navn, adresse og telefonnummer i én kanonisk oppføring. «Kanonisk» betyr at organisasjonen har valgt én autoritativ underliggende verdi for hvert felt, selv når en katalog forkorter gatenavnet eller en telefonlenke bruker et internasjonalt maskinformat.

Det gjengitte elementet er med hensikt lite spennende. Dets oppgave er identitet, ikke overtalelse: én lokasjon, ett kundevendt navn, én leveringsdyktig adresse, ett overvåket nummer, og nok proveniens til å revidere alle kopier mot kilden.

Hvorfor dette elementet betyr noe

Lokale avgjørelser har høy kostnad ved feil. En leser velger kanskje hvor de skal kjøre, hvilken avdeling de skal ringe, hvor de skal sende et dokument, eller om et selskap betjener deres område. Når bunnteksten viser et hovedkontornummer, lokasjonssiden viser et avdelingsnummer, og kartpanelet peker til en gammel inngang, må leseren gjette hvilket faktum som styrer neste handling. Den usikkerheten skader tilliten før en samtale i det hele tatt begynner.

Den psykologiske fordelen er trygghet gjennom spesifisitet. En fullstendig gateadresse signaliserer at siden beskriver et virkelig sted snarere enn en generisk byrettet landingsside. Et lokasjonsspesifikt telefonnummer forteller leseren hvem de vil nå. Et stabilt navn hjelper dem med å gjenkjenne den samme avdelingen i søkeresultater, kart, anmeldelsesplattformer, fakturaer og skilting. Ingen av disse detaljene beviser tjenestekvalitet, men sammen fjerner de unødvendig tvil om identitet og tilgang.

Maskinuttrekkbarhet er evnen til en crawler, søkemotor, katalog, assistent eller syndikeringsprosess til å bevare hver verdi og dens tilknytning til én lokasjon. En setning som «Ring vårt Washington-team nær Capitol Hill» kan leses naturlig, men den eksponerer ikke en fullstendig postadresse eller en entydig telefonverdi. En merket blokk med en stabil lokasjons-ID produserer en oppføring som kan sammenlignes felt for felt.

Konsistens bør behandles som et reviderbart dataproblem, ikke en typografiritual. Normaliser store/små bokstaver, Unicode, mellomrom, gate suffikser, enhetsidentifikatorer, postnumre, landskoder og telefonsifre før du sammenligner oppføringer. «1200 Example Ave., Ste 210» og «1200 Example Avenue, Suite 210» kan normaliseres til samme adresse; «Suite 120» gjør ikke det. Likeledes kan (202) 555-0147 og +1 202-555-0147 representere samme nummer, mens et samtaletrackingnummer kan være bevisst forskjellig og må registreres som en godkjent alias med sin rutingeier.

Når du skal bruke det

Bruk en NAP-blokk når en side representerer en fysisk forretningslokasjon som kunder kan besøke, ringe, poste til, verifisere eller skille fra en annen avdeling. Den er påkrevd på lokasjons- og avdelingssider, nyttig i kontrollerte katalogoppføringer, og passende på en bedriftsprofil når adressen virkelig er en del av den offentlige identiteten.

Opprett én blokk per lokasjon. En flerlokasjonsindeks kan gjengi tjue blokker, men den må gjengi tjue separate oppføringer snarere enn ett firmanavn etterfulgt av en blandet liste med adresser og numre. Hver instans må løses til en lokasjons-ID slik at et innholdssystem ikke kan pare Avdeling As adresse med Avdeling Bs telefon.

Nesten-treff trenger forskjellig behandling:

• En tjenesteområdebedrift uten kundevendte lokaler bør ikke publisere eierens hjemmeadresse. Oppgi tjenesteområdet og kontaktruten uten å late som om det finnes en besøkbar NAP-lokasjon.
• En postboks, en adresse for registrert representant, fakturaadresse, lageradresse og returadresse er ikke utskiftbare med en kundelokasjon. Merk hvert operasjonelt formål og hold det utenfor den primære blokken, med mindre det er adressen kundene blir bedt om å bruke.
• Åpningstider, timebestilling, veibeskrivelse, parkering og tilgjengelighetsdetaljer kan ligge i nærheten av blokken, men de er separate fakta med separate oppdateringssykluser.
• Et samtaletrackingnummer er ikke automatisk inkonsistent. Det er akseptabelt når rutingen er pålitelig, eierskap og kanonisk destinasjon er dokumentert, og det synlige nummeret ikke endres uforutsigbart for crawlkere eller tilbakevendende brukere.
• En nettbasert bedrift kan ha en juridisk adresse for etterlevelse, men ingen fysisk lokasjon. Ikke gjør en juridisk opplysning om til lokalt tilstedeværelsesmarkedsføring.
• En behandler inne i en klinikk kan trenge en behandleroppføring og klinikken kan trenge en lokasjonsoppføring. Ikke slå sammen deres navn og telefonnumre til en hybrididentitet.

Element-skrivereglene har forrang: velg elementet etter avsnittets formål. Hvis avsnittets oppgave er å oppgi en lokasjons kanoniske navn, adresse og telefon, bruk en NAP-blokk selv når et generisk kort eller en bunntekst kunne vise lignende tekst.

Hvor du skal plassere det

På en dedikert lokasjonsside, plasser den primære NAP-blokken umiddelbart etter den innledende identifikasjonen og direkte svaret, før veibeskrivelser, åpningstider, tjenester, anmeldelser eller bestillingsfunksjoner. Leseren bør vite hvilket sted siden representerer før de tolker noen lokal påstand. Hvis hero-seksjonen allerede gjengir den fullstendige kanoniske oppføringen, kan den senere kontaktdelen gjenta den kun fra samme dataobjekt.

På en bedriftsprofil, plasser den i en tydelig merket «Hovedkontor»- eller «Offentlig kontaktlokasjon»-seksjon i stedet for under en generisk «Om»-overskrift. I en katalogindeks, plasser én kompakt blokk inni hver tilsvarende oppføring og lenk hele identitetsgruppen til riktig avdelingsprofil. I en bunntekst, bruk kun den primære offentlige lokasjonen eller en eksplisitt lokasjonsvelger; en bunntekst er for trang for en umerket blanding av flere kontorer.

Blokken kan ligge ved siden av åpningstider, et kart, veibeskrivelse, parkeringsinformasjon eller en bestillingshandling bare når hver tilstøtende komponent bruker samme lokasjons-ID. Den kan ikke ligge ved siden av et kartnål for en annen inngang, en organisasjonsomfattende sentralbord merket som en avdelingslinje, en leveringslageradresse, eller en lokasjonsvelger der gjeldende valg er uklart. Ikke plasser en annonse, et vitnesbyrd, et nyhetsbrevskjema eller et reklametilbud mellom navnet og adressen eller mellom adressen og telefonnummeret. Disse avbruddene bryter oppføringen visuelt og i leserekkefølge.

På mobil, bevar rekkefølgen navn, gate, sted, region og postnummer, land ved behov, deretter telefon. Ikke la en bestikkende ringeknapp erstatte det synlige nummeret eller skjule hvilken avdeling den ringer.

Anatomi

1. Lokasjonsnavn: det godkjente kundevendte navnet, inkludert en avdelingskvalifikator kun når det brukes konsistent.
2. Gateadresse: det leveringsdyktige gatenummeret og -navnet, ikke en landemerke-beskrivelse.
3. Underlokasjon: en suite, enhet, etasje, bygning eller avdeling som trengs for å nå riktig destinasjon.
4. Sted og region: byen eller stedet pluss den styrte staten, provinsen, fylket eller regionverdien.
5. Postnummer og land: den fullstendige ruteingskoden og landet, inkludert land når målgruppen eller syndikeringen krysser grenser.
6. Visningstelefon: det menneskelesbare nummeret formatert for lokasjonens målgruppe.
7. Telefonmål: samme nummer normalisert for oppringing, normalt i E.164-format inni en tel:-lenke.
8. Lokasjons-ID: en stabil intern nøkkel som hindrer at avdelingsdetaljer blandes under gjengivelse eller syndikering.
9. Verifiseringsmetadata: datoen og det autoritative systemet eller eieren som oppføringen ble kontrollert mot.

Designeksempler

Hver variant bruker den samme underliggende lokasjonsoppføringen. Tetthet og omkringliggende handlinger kan endres, men gjengiveren kan ikke forkorte bort en suite, erstatte med et organisasjonsomfattende nummer, eller skjule en adresse som trengs for å skille avdelingen.

Standard lokasjon. Standardvarianten viser hver komponent i en vertikal, enkel å kopiere gruppe. Bruk den på en dedikert lokasjons- eller avdelingsside.

Kompakt kontaktbånd. Bruk i en bunntekst eller et kontaktbånd når én offentlig lokasjon representerer siden. Den kan kollapse til rader på smale skjermer, men må ikke forkorte enhet, postnummer eller telefon.

Katalogkort. Gjenta én kompakt NAP-instans per lokasjon. Hold filtre, avstand, «åpen nå» og tjenestetiketter utenfor identitetsfeltene slik at dynamiske tilstander ikke kan overskrive den kanoniske oppføringen.

Kun timebestilling. Vis full offentlig NAP når kunder har lov til å besøke, legg deretter til «Time kreves» som en separat operasjonell merknad. Ikke sett inn uttrykket i adresselinjen.

Internasjonal. Bevar adresserekkefølgen som forventes i destinasjonslandet, mens du lagrer hver komponent separat. Vis den lokale telefonkonvensjonen for lesere og behold en internasjonal oppringsverdi for lenken og datalaget.

Parametere

«Kilde» nedenfor betyr hvor gjengiveren henter et felt. Virksomhetens styrte lokasjonsregister, ikke artikkelens brødtekst, forblir autoritativ for identitetsverdier.

Lagre komponenter separat selv når gjengiveren slår dem sammen for visning. En enkelt address="1200 Example Avenue, Washington..."-klump forhindrer landspesifikk sortering, pålitelige sammenligninger og målrettet korrigering av feil suite eller postnummer.

Syntaks og kodeeksempler

Alle tre former koder samme lokasjons-ID og kanoniske felt. Det bærbare direktivet er den forfatterskrevne kontrakten; et prosjekt må registrere og teste sine Hugo- og WordPress-adaptere før syntaksen publiseres.

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

Merk: Besøk kun etter avtale.
:::

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

Merk: Besøk kun etter avtale.
{{< /nap >}}

Alle shortcode-parametere er navngitte. Adapteren må escape tekst, generere en <address>-gruppe og tel:-lenke, eksponere lokasjons-ID-en til datalaget, og bevare brødtekstmerknaden utenfor postadressen.

WordPress-blokk

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

WordPress-blokken bør bruke typede inspektørfelt og servergjengivelse. Forfattere kan velge en lokasjonsoppføring og legge til en godkjent merknad, men bør ikke skrive om det kanoniske navnet, adressen eller telefonnummeret i rik tekst.

Eksempler

God: én fullstendig, tilskrivbar lokasjon

Northstar Heating — Capitol Hill
1200 Example Avenue, Suite 210
Washington, DC 20001, United States
(202) 555-0147
Lokasjon NSH-DC-01 · Verifisert 27. august 2026 mot det godkjente lokasjonsregisteret

Dette fungerer fordi avdelingskvalifikatoren, suite, postnummer, land, visningsnummer, ringemål, stabil ID, dato og kilde alle beskriver én oppføring. En leser kan besøke eller ringe; en crawler kan hente de samme verdiene; en revisor kan sammenligne blokken med en katalogoppføring uten å gjette hvilket kontor som styrer siden.

Dårlig: en plausibel sammensetning

Northstar Heating Washington
Nær Capitol Hill, Washington DC
Ring vårt team: 555-0147 eller hovedkontoret
Åpent nær deg

Dette feiler fordi «nær Capitol Hill» ikke er en leveringsdyktig adresse, lokalnummeret mangler område- og landkontekst, «hovedkontoret» har ikke noe nummer, og navnet identifiserer ikke en styrt avdeling. «Åpent nær deg» blander åpningstider og nærhet inn i identitet uten et lokasjons- eller tidsgrunnlag. Blokken kan ikke matches sikkert med en kartoppføring, katalogsitering, skjemaenhet eller intern kilde.

Reparer den ved å velge den eksakte lokasjons-ID-en, hente hvert felt fra registeret, publisere den fullstendige offentlige adressen og overvåkede telefonen, og flytte åpningstider eller nærhetspåstander til sine egne komponenter.

Skjemamarkering og tilgjengelighet

En NAP-blokk kan mate en kvalifisert Organization, LocalBusiness-undertype, eller annen stedsbasert enhet. Kartlegg de synlige name, telephone og adressekomponentene til en PostalAddress: streetAddress, addressLocality, addressRegion, postalCode og addressCountry. Bruk den mest spesifikke sannferdige forretningstypen som støttes av siden; ikke velg en kategori utelukkende for å få en søkefunksjon.

Strukturerte data må identifisere samme lokasjon som siden identifiserer. Ikke sett hovedkontoret i JSON-LD mens du viser en avdeling i blokken, ikke kombiner flere avdelinger til én adresse, og ikke legg til bredde- og lengdegrad gjettet fra et postnummer. Hvis hver avdeling har sin egen side og vedvarende enhet, bruk en stabil kanonisk URL og styrt identifikator for å holde grafen separat. Verifiseringsdatoen og kilden støtter intern styring, men krever ikke offentlige Schema.org-egenskaper.

Bruk et <address>-element for kontaktinformasjonen til lokasjonen som siden eller seksjonen representerer. Ikke anta at <address> betyr en hvilken som helst postadresse; dens HTML-betydning er kontaktinformasjon for den relevante artikkelen eller sideeieren. Hold lokasjonsnavnet i en overskrift, merk gjentatte katalogkort, og bevar en logisk kilde-rekkefølge.

Det synlige telefonnummeret må forbli tekst, ikke et ikon eller et bilde. Lenk det med href="tel:+12025550147" når det er hensiktsmessig å ringe, men behold en lesbar lokal visning. Ikke del opp enkeltsifre i stilte spenn, ikke uttal tegnsetting gjennom en unøyaktig tilgjengelig etikett, og ikke skjul essensielle tilleggsnumre i et verktøytips. Sørg for at tastaturfokus er synlig, lenkeformålet inkluderer avdelingen når flere ringelenker vises sammen, og at zooming eller omflytning ikke skiller suite eller postnummer fra adressen.

Skriveregler

Disse reglene beskytter identitetsoppløsning først; visuell ryddighet er sekundært:

• Bruk nøyaktig ett kundevendt navn, én adresse og én primærtelefon per blokk. Hvis et sekundært nummer er operasjonelt nødvendig, merk formålet utenfor den kanoniske NAP-trioen.
• Hold navnet på 2–100 tegn. Bruk det virkelige offentlige merkevarenavnet og en styrt avdelingskvalifikator; ikke legg til nøkkelord som «beste nød-rørlegger i Washington.»
• Bruk 1–3 gatelinjer, hver ikke mer enn 100 tegn. Bevar suite, enhet, etasje, bygning og retningsinformasjon som kreves for levering eller ankomst.
• Bruk en fullstendig postadresse for offentlige lokaler. Erstatt den aldri med «sentrum,» «nær stasjonen,» et kartnål eller veibeskrivelse.
• Lagre landet som en to-bokstavskode og gjengi dets menneskelesbare navn når målgruppekonteksten krever det. Aldri utled et land fra et toppnivådomene alene.
• Lagre telefonnumre i E.164-form og gjengi en kjent lokal form. Inkluder et tilleggsnummer som en separat styrt verdi når ruting avhenger av det.
• Bruk en saklig, administrativ tone. Blokken kan si «Time kreves» eller «Ingen offentlig tilgang»; den må ikke inneholde slagord, tjenestepåstander, anmeldelser, priser, rabatter, hastverksappeller eller nøkkelordlister.
• Ikke legg åpningstider, veibeskrivelser, parkeringsinstruksjoner, tjenesteområder, bestillingsmuligheter, e-postadresser, faksnumre eller sosiale profiler inni de tre identitetsfeltene. Tilstøtende merkede felt er akseptable når deres eierskap og oppdateringsrytme er tydelig.
• Ikke overskriv en kanonisk verdi stille for å matche en tredjepartskatalog. Undersøk om den eksterne oppføringen er utdatert, et godkjent alias, eller en virkelig forskjellig lokasjon, og korriger deretter riktig kilde.
• Registrer en verifiseringsdato og kilde for hver publisert instans. Verifiser på nytt etter flyttinger, rebrandinger, telefonruteendringer, fusjoner, avdelingsnedleggelser, suiteskifter og katalogmigreringer.
• Behandle tegnsetting og forkortelser som presentasjonsforskjeller først etter at normalisering beviser at de underliggende komponentene stemmer overens. Et endret siffer, suite, postnummer eller avdelingskvalifikator er vesentlig.

Innleggstyper som bruker det

Tabellen styres av postTypes[] i front matter. Legg til eller fjern en rad kun når den tilsvarende matrisen endres.

QA-sjekkliste

• Blokken løses fra én stabil lokasjons-ID snarere enn uavhengig skrevne felt.
• Det offentlige navnet samsvarer med den styrte merkevaren og avdelingsnavnepolicyen uten nøkkelordtillegg.
• Gatenummer, gatenavn, retningsangivelse, suite eller enhet, sted, region, postnummer og land ble sjekket mot den autoritative kilden.
• Adressen er gyldig for den angitte kundehandlingen: besøk, postforsendelse, henting eller et annet eksplisitt merket formål.
• Private hjem, adresser for registrert representant, lager og virtuelle kontorer presenteres ikke som kundelokasjoner.
• Det viste telefonnummeret og tel:-målet normaliseres til samme overvåkede destinasjon.
• Nærliggende åpningstider, kart, veibeskrivelser, bestilling og CTA-komponenter bruker samme lokasjons-ID.
• Ingen tilstøtende blokk motsier adressen, telefonnummeret, avdelingsnavnet, besøkspolicyen eller lokasjonsvalget.
• Normalisert sammenligning skiller harmløse formateringsforskjeller fra endrede sifre, enheter eller postkomponenter.
• Synlig innhold og Organization-, LocalBusiness- eller PostalAddress-markering samsvarer felt for felt.
• Gjentatte blokker har unike overskrifter eller tilgjengelige etiketter, og hver telefonlenke har et tydelig formål.
• Den fullstendige oppføringen forblir lesbar, kopierbar, tastaturtilgjengelig og korrekt sortert ved 200 % zoom og på en smal skjerm.
• Verifiseringsdato og kilde er til stede, og en navngitt eier mottar avviksrapporter.
• Flyttinger, nedleggelser, rebrandinger, nummerendringer og godkjente aliaser har en oppdateringsvei på tvers av nettsiden, profiler, kataloger og datafeeder.

FAQ

Hva betyr NAP i lokal SEO?

NAP står for navn, adresse og telefon. En NAP-blokk publiserer disse tre identitetsfaktaene for én forretningslokasjon i en kanonisk, merket form som mennesker og maskiner kan hente uten å kombinere detaljer fra forskjellige avdelinger.

Må tegnsetting være identisk på alle nettsider?

Nei. Harmløse presentasjonsforskjeller som «Suite» versus «Ste.» eller lokalt formatert versus internasjonal telefonvisning skaper ikke en annen enhet når de underliggende verdiene normaliseres til samme fakta. Revider normaliserte felt, mens du beholder én foretrukket visningsform under din kontroll.

Bør en tjenesteområdebedrift publisere en hjemmeadresse?

Nei. Ikke eksponer en privat adresse eller en adresse som ikke er kvalifisert for kunder, bare for å fullføre blokken. Publiser det kundevendte firmanavnet og overvåkede telefonnummeret, oppgi at tjeneste leveres hos kunden, og hold private adresser i styrte systemer som faktisk trenger dem.

Kan én NAP-blokk inneholde flere avdelinger?

Nei. Én blokk representerer én lokasjonsoppføring. En katalog kan gjenta komponenten én gang per avdeling, men hver instans trenger sin egen lokasjonsidentifikator, adresse, telefon, kilde og måleside, slik at detaljer ikke kan kombineres ved en feiltakelse.

Hvor ofte bør NAP-informasjon kontrolleres?

Kontroller den når en lokasjon, et nummer, en navne policy eller en katalogoppføring endres, og inkluder den i en regelmessig revisjon av lokale data. Det passende intervallet avhenger av operativ endringstakt; blokken bør registrere sin siste verifiseringsdato og autoritative kilde i stedet for å antyde varig nøyaktighet.