Lokal- og flerpositions-SEO-tjekliste

Et lokalt program bliver svært at kontrollere, når én virksomhedsidentitet gengives på tværs af profiler, mapper, sider, anmeldelsesplatforme og AI-svar. Denne tjekliste behandler lokal SEO som et data- og publiceringssystem: hver lokation har en godkendt post, hver side har fortjent sin eksistens, og hver ændring har en ejer og dokumentation.

Tjekliste: lokal og flerpositions-SEO. Tidsramme: 2–4 timer for én lokation; 2–5 arbejdsdage til at etablere en baseline for 10–50 lokationer, derefter månedlig undtagelsesgennemgang og kvartalsvis fuld revision. Ejer: lokal SEO-ansvarlig eller marketingoperations-ejer, med lokationsledere ansvarlige for faktuel verifikation og kundeoplevelsesteams ansvarlige for anmeldelsesanmodninger.

Målet er én pålidelig identitet pr. lokation, dokumenterede platformvarianter, nyttige lokale destinationer og dokumentation for, at personer og søgesystemer kan finde den rigtige afdeling til den rigtige tjeneste.

Hvorfor denne fase, og hvorfor her

Denne tjekliste forbruger validerede markeder, tjenester, målgrupper og begrænsninger fra discovery; forespørgsels- og promptsæt fra søgeord og prompt-undersøgelse ; og godkendt URL-ejerskab fra det topiske kort og informationsarkitektur . Kør den efter disse beslutninger, fordi en lokationsmatrix uden efterspørgsel skaber sider ved multiplikation, mens efterspørgsel uden operationel verifikation lover tjenester, en afdeling ikke kan levere.

Kører man den for tidligt, bliver hver by-og-service-kombination til en formodet side. Kører man den for sent, overlades søgemaskiner, kortprodukter, mapper og AI-systemer til at forene modstridende navne, lukkede lokationer, duplikatprofiler og tynde sider. Resultatet er ikke blot et rangeringsproblem: kunder kan ringe til det forkerte nummer, ankomme uden for åbningstid eller anmode om en tjeneste, den valgte afdeling ikke tilbyder.

Outputtet er et kontrolleret lokalt datasæt og en godkendt sideplan. Disse bliver kontrakter for implementering på siden, struktureret data, intern linkning, anmeldelsesdrift, rapportering og senere opdateringsarbejde i den bredere SEO-proces .

Inputs og outputs

Outputs er versionsstyrede tabeller, som downstream-ejere kan sammenkæde via stabilt lokations-ID, side-URL og profil-URL uden at matche fritekst-afdelingsnavne manuelt.

Tjeklisten

1. Etablér lokationens kilde til sandheden

Opret én kanonisk post pr. reel lokation. Hvad: tildel et stabilt ID og godkendt navn, adresse, telefonnummer, åbningstider, status, koordinater, webstedsdestination og operationsejer. Hvorfor: NAP-konsistens —overensstemmelse af navn, adresse og telefonnummer—er umulig at revidere, når den “korrekte” værdi lever i e-mailtråde. Hvordan: eksporter poster fra operations, kundesupport, butikssystemer og webstedet; løs konflikter med den person, der er ansvarlig for den fysiske afdeling. Værktøj: regneark eller database med ændringshistorik. Udført når: hver aktiv, åbnende, flyttet, midlertidigt lukket og permanent lukket lokation har præcis én godkendt post, en ejer, en sidst-verificeret dato og ingen uløste påkrævede felter.

Definér acceptable varianter før fejlmarkering. Hvad: registrér platformspålagte forkortelser, sporingsnummerpolitik, suiteformatering og handelsnavneundtagelser. Hvorfor: “Street” versus “St” kan være harmløst, mens et gammelt opkaldssporingsnummer kan dirigere kunder til den forkerte afdeling; at behandle begge som lige støj spilder korrektionstid. Hvordan: normaliser store/små bogstaver, tegnsætning, mellemrum, landekoder og adressetokens, sammenlign derefter identitet og routing frem for rå strenge alene. Værktøj: normaliseringsregler plus en række-diff. Udført når: hver observeret værdi er klassificeret som nøjagtig, godkendt variant, væsentlig uoverensstemmelse, duplikat eller ukendt, og hver væsentlig uoverensstemmelse har en ejer og deadline.

2. Revidér profiler og citeringer som data

Inventarér de kilder, kunder rent faktisk kan støde på. Hvad: registrér webstedet, Google Business Profile , Apple- og Bing-kortopslag, større aggregatorer, relevante branchemapper, sociale profiler og højsynlige anmeldelsessider. Hvorfor: at korrigere en lavkvalitetsmappe, mens den dominerende kortprofil er forkert, reducerer ikke kunderisikoen. Hvordan: søg på virksomhedsnavn, gamle navne, telefonnumre, adresser og lokations-ID’er; gem kilde-URL’en og observerede værdier frem for kun et bestået/ikke-bestået-mærkat. Værktøj: søgemaskine, platformdashboards, listingudbyder-eksporter og citeringstabel. Udført når: hver lokation har en kontrolleret post for hver prioritetskilde, plus eventuelle opdagede duplikat- eller forældede profiler, med dokumentationsdato og adgangsstatus.

Ret højpåvirknings-uoverensstemmelser i risikorækkefølge. Hvad: prioritér forkert status, adresse, telefonnummer, åbningstider, websted og duplikatejerskab før kosmetisk formatering. Hvorfor: en fejl med lukket lokation eller fejldirigeret opkald svigter direkte kunden; inkonsekvent brug af store/små bogstaver gør det normalt ikke. Hvordan: indsend ændringer ved kilden, bevar bekræftelses-ID’er, og genkontrollér efter platformens angivne behandlingsperiode. Værktøj: kildeplatform, sagsmængde og dokumentationslog. Udført når: nul prioritetskilder viser forkert åben/lukket-status, fysisk placering, telefonrute, åbningstider eller webstedsdestination; resterende undtagelser har sags-ID’er og genkontrolsdatoer.

3. Valider profilfuldstændighed og ejerskab

Verificér og sikr hver profil. Hvad: bekræft, at organisationen ejer hver profil, autoriserede brugere er aktuelle, og genoprettelsesveje ikke afhænger af en tidligere medarbejder. Hvorfor: datanøjagtighed er midlertidig, når ingen kan vedligeholde posten, eller en ukendt bruger kan ændre den. Hvordan: revidér brugere, forretningsgrupper, e-mail-domæner, to-faktor-godkendelse, genoprettelseskontakter og agenturadgang. Værktøj: platformadgangspaneler og adgangsregister. Udført når: hver prioritetsprofil har en verificeret status, hvor det tilbydes, mindst to nuværende organisationskontrollerede administratorer, ingen uforklarlig ejer og en testet genoprettelsesvej.

Udfyld felter fra operationel sandhed. Hvad: udfyld kategorier, åbningstider, ferieåbningstider, tjenester, bookingslinks, tilgængelighedsattributter, billeder og beskrivelse uden at tilføje ubegrundede påstande. Hvorfor: ufuldstændige profiler kan ikke besvare almindelige lokale beslutninger, men opdigtet fiktion skaber en værre fejl end et tomt felt. Hvordan: kortlæg hvert felt til kilde-til-sandheden-kolonnen eller en ansvarlig lokal verificerer. Værktøj: profildashboards og masterdata. Udført når: alle relevante højværdifelter er udfyldt, hver værdi spores til en godkendt kilde, og profilens landings-URL opløses til den korrekte lokationsside uden en undgåelig omdirigering.

4. Beslut hvilke lokationssider der fortjener at eksistere

Kræv et distinkt job for hver side. Hvad: opret en side kun, når den repræsenterer en reel bemandet lokation, et legitimt serviceområde eller en væsentlig anderledes lokal beslutning. Hvorfor: sider, der kun differentieres af et by-token, er udskiftelige og kan blive et doorway-side -mønster: mange tynde indgange bygget til at fange forespørgsler frem for at hjælpe besøgende. Hvordan: bedøm hver kandidat på verificeret efterspørgsel, operationel dækning, unikke fakta, lokale beviser, konverteringsvej og vedligeholdelsesejerskab. Værktøj: forespørgselsæt, servicematrix, sideinventar og indholdsbrief. Udført når: hver godkendt side har en navngiven primær hensigt, mindst tre lokationsspecifikke dokumentationsfelter, en distinkt konverteringsvej eller afdelingsdestination og en ejer; hver afvist kandidat har en konsolideringsdestination.

Differentiér sider med fakta, ikke adjektiver. Hvad: inkludér lokationens adresse eller erklærede serviceområde, åbningstider, tjenester, personale eller legitimationsoplysninger, hvor relevant, vejledning eller adgangsinformation, lokale politikker, originale billeder, anmeldelsesdokumentation og afdelingsspecifikke ofte stillede spørgsmål. Hvorfor: at ændre “betroet blikkenslager i Bristol” til “betroet blikkenslager i Bath” ændrer ikke svaret. Hvordan: indsaml strukturerede fakta fra lokale ejere, forhindr gengivelse af tomme moduler, og sammenlign søskendesider side om side. Værktøj: lokalitetsbrief, lighedsgennemgang og gengivne sider. Udført når: ingen to publicerede lokationssider deler en identisk hovedbesvarelse, servicebevis, vejledningstekst, ofte stillede spørgsmål-sæt og CTA-kombination; enhver fælles politik er tydeligt organisationsdækkende frem for præsenteret som lokalt bevis.

5. Godkend serviceområde- og service-på-lokation-kombinationer

Opbyg matrixen før opbygning af URL’er. Hvad: kryds lokationer eller serviceområder med tjenester og marker tilbudt, begrænset, kun-henvisning, sæsonbestemt eller ikke tilgængelig. Hvorfor: et søgeordsværktøj kan identificere efterspørgsel, men kan ikke bekræfte rejseradius, licenser, lager, personale eller svartid. Hvordan: få operations til at godkende hver kombination og vedhæft begrænsninger og effektive datoer. Værktøj: service-lokation-matrix og efterspørgselsdata. Udført når: hver publiceret kombination er både efterspørgselsunderstøttet og operationelt sand, hver begrænsning er synlig på destinationen, og ingen URL påstår en ikke-tilgængelig tjeneste.

Vælg én destination pr. hensigt. Hvad: beslut, om lokationssiden, servicesiden eller en ægte specifik service-på-lokation-side bedst besvarer hver forespørgsel. Hvorfor: at publicere alle tre for den samme hensigt får webstedets egne URL’er til at konkurrere og spreder dokumentation på tværs af nær-duplikater. Hvordan: tildel en primær URL, kortlæg understøttende interne links, og konsolidér lav-efterspørgselskombinationer i nyttige moduler eller filtre på en stærkere side. Værktøj: hensigt-til-URL-kort og Search Console landingsside-dokumentation. Udført når: hver sporet lokal hensigt har én primær indekserbar destination, ingen uforklarlig konkurrerende URL, og hver indekserbar service-lokation-side består den ovenstående distinkt-side-test.

6. Gør lokale sider teknisk entydige

Tilpas identitet på tværs af synligt indhold og maskinlæsbare felter. Hvad: brug den samme godkendte afdelingsidentitet i titel, hovedoverskrift, kontaktblok, kanonisk tag, interne links og relevant struktureret data. Hvorfor: modstridende enhedsnavne eller adresser tvinger crawlere og AI-systemer til at gætte, hvilken afdeling siden repræsenterer. Hvordan: generér felter fra den stabile lokationspost, og test den server-leverede HTML. Værktøj: kildeinspektør, struktureret data-validator og crawleksport. Udført når: hver indekserbar side returnerer 200, har ét selvhenvisende kanonisk tag, eksponerer én entydig lokationsidentitet, og dens synlige kontaktoplysninger matcher den godkendte post.

Forbind sider uden at skabe en by-link-væg. Hvad: tilvejebring en nyttig lokaliseringsfunktion eller regionalt hierarki og kontekstuelle links til validerede tjenester. Hvorfor: kunder har brug for at bevæge sig mellem nærliggende muligheder, men hundredvis af gentagne søgeordslinks skjuler siden og antyder dækning, virksomheden måske ikke har. Hvordan: gruppér lokationer efter geografi, brugere forstår, begræns servicelinks til verificeret tilgængelighed, og sørg for, at hver godkendt side har en indgående rute. Værktøj: crawl-graf og gengivet navigation. Udført når: nul godkendte lokationssider er forældreløse, hvert link opløses, linketiketter identificerer destinationen tydeligt, og ingen lokation linker til en ikke-tilgængelig tjeneste.

7. Opbyg et politik-sikkert anmeldelsessystem

Spørg hver berettiget kunde gennem den samme neutrale vej. Hvad: udløs en anmeldelsesanmodning efter en reel gennemført interaktion, med samme offentlige anmeldelsesmulighed uanset forventet stemning. Hvorfor: anmeldelsesportning—at sende glade kunder til en offentlig platform, mens utilfredse kaderes til privat feedback—forvrænger registreringen og kan overtræde platformregler. Hvordan: definér berettigelse, timing, undertrykkelse, samtykke, ordlyd og lokationsspecifik destination; hold privat support tilgængelig uden at gøre det til en betingelse for offentlig anmeldelse. Værktøj: CRM eller messaging-workflow, platformens anmeldelseslink og anmodningslog. Udført når: én dokumenteret regel gælder for alle berettigede kunder, intet spørgsmål screener for tilfredshed før præsentation af anmeldelsesmuligheden, hvert link lander på den korrekte lokation, og workflowet gemmer sendte, undertrykte, fejlede og fravalgte resultater.

Overvåg og svar uden at skrive ansvarlighed væk. Hvad: spor anmeldelsessignaler såsom antal, vurdering, aktualitet og lokation, router derefter svar og operationelle problemer. Hvorfor: et mål for “flere femstjernede anmeldelser” inviterer til pres og incitamenter; et mål for repræsentativ feedback og løste problemer forbedrer den underliggende oplevelse. Hvordan: brug faktuelle, ikke-defensive svarretningslinjer, forbyd medarbejderskrevne anmeldelser og uoplyste incitamenter, og eskalér sikkerheds-, juridiske eller privatlivsproblemer. Værktøj: anmeldelsesplatform, svarkø og månedligt lokationsresultatkort. Udført når: hver ny anmeldelse er tildelt eller besvaret inden for organisationens serviceniveau, hvert alvorligt problem har en sagsansvarlig, og revisionen finder nul portede, fabrikerede, medarbejderforfattede eller ukorrekt incitamenterede anmodninger.

8. Baseline-måling pr. lokation

Adskil tilstedeværelse, trafik og konvertering. Hvad: registrér profils nøjagtighed, sides indekserbarhed, organiske klik og visninger, sporede lokale prompter, opkald, bookinger, vejledningsanmodninger og kvalificerede leads, hvor tilgængelige. Hvorfor: en rangeringsbevægelse er ikke et forretningsresultat, og en samlet total kan skjule, at én afdeling vinder, mens en anden forsvinder. Hvordan: sammenkæd poster efter lokations-ID og URL, bevar utilgængelige værdier som ukendt frem for nul, og annotér åbninger, lukninger, flytninger og sporingsændringer. Værktøj: AmICited, Search Console, analyse, opkaldssporing, bookingdata og rapporteringstabel. Udført når: hver aktiv lokation har en dateret baseline, kilde, periode og ejer; målinger kan filtreres efter lokation; og manglende sporing er en eksplicit handling frem for stille behandlet som ingen præstation.

Værktøjer i AmICited

AmICited måler ejede-sider og AI-synlighedsresultater; det redigerer ikke eksterne forretningslistinger. Foretag korrektioner i kildeplatformene, brug derefter disse rapporter til at verificere, om lokationsområdet er opdageligt og præsterende.

1. Åbn Google Search Pages med Google Search Pages for at sammenligne klik, visninger, klikrate og gennemsnitlig position efter lokations-URL, inspicér derefter en side, der er fraværende eller uventet svag.
2. Åbn Google Search Directories med Google Search Directories , når lokationssider deler en mappe. Et sektionsniveau-fald kan identificere et skabelon-, navigations- eller udrulningsproblem, før individuelle afdelinger gennemgås.
3. Åbn Prompt Tracking med Prompt Tracking & Management for at indlæse repræsentative service-plus-lokation og “i nærheden”-prompter. Spor kun prompter, der matcher faktisk dækning, og hold lande- og sprogindstillinger eksplicitte.
4. Åbn AI Rank Tracker med AI Rank Tracker for at se, om organisationen er nævnt eller citeret for det godkendte lokale promptsæt på tværs af understøttede AI-motorer.
5. Åbn Content Freshness med Content Freshness for at opdage lokations-URL’er tilføjet, opdateret eller fjernet fra sitemaps. Brug hændelsen som en gennemgangsudløser; det beviser ikke, at kontaktoplysninger er korrekte.

Beslutningsregler

Brug tal til at gøre “dårligt” handlingsdygtigt. Disse er operationelle porte, ikke påstande om rangeringsfaktor-vægte.

Lighed er en gennemgangsudløser, ikke en automatisk sletningsregel. To lokationer kan dele organisationsdækkende garantier eller servicedefinitioner. De har stadig brug for distinkte lokale beviser og en anden virkelig destination; en lav lighedsscore kan ikke redde en fiktiv afdeling.

Leverance

Overlever et arbejdsark eller databaseeksport plus en kort beslutningslog. CSV er acceptabelt, når én tabel bruges; brug separate relationelle faner, når programmet har flere lokationer og tjenester.

locations: location_id, status, approved_name, address_or_service_area,
phone, hours, coordinates, owner, verified_at

profiles: location_id, platform, profile_url, access_status, observed_values,
match_class, issue_severity, ticket_id, owner, recheck_at

pages: location_id, url, primary_intent, page_decision, unique_evidence,
canonical, indexability, inbound_route, content_owner

service_matrix: location_id_or_area, service_id, availability, constraints,
evidence, approved_by, effective_date

reviews: location_id, platform, request_trigger, neutral_flow_verified,
destination_checked, response_owner, policy_exception

baseline: location_id, period, page_metrics, prompt_set, AI visibility,
conversions, data_source, annotation, measured_at

Inkludér korrektionskøen, den afviste-side-liste, konsolideringsbeslutninger, uløste platformsager, dokumentation og næste revisionsdato. Den lokale SEO-ansvarlig godkender data- og sidebeslutninger; operations godkender tilgængelighed; kundeoplevelse godkender anmeldelsesworkflowet.

Hvad går galt

• At bruge webstedet som masterdatabase. En gammel side kan se autoritativ ud, mens operations, kort og opkaldere bruger forskellige fakta.
• At behandle NAP som rå streng-lighed. Teams retter harmløs tegnsætning, mens de overser et telefonnummer, der når en anden afdeling.
• At publicere det kartesiske produkt. Halvtreds steder ganget med tyve tjenester skaber 1.000 URL’er, ikke 1.000 nyttige svar.
• At kalde skabelonprosa for “lokal”. Et bynavn, en vejrsætning og et stockfoto demonstrerer ikke lokalt personale, adgang, dokumentation eller servicetilgængelighed.
• At skjule adressen på en serviceområde-virksomhed uden at definere dækning. Kunder har stadig brug for et ærligt område, begrænsninger, forventning til svar og en bookingsvej.
• At lade lokale ledere improvisere profilnavne. Tilføjelse af søgeord til virksomhedsnavnet fragmenterer identiteten og kan være i konflikt med platformspolitik.
• At gennemsnitliggøre alle lokationer sammen. En national gevinst kan skjule en lukket afdeling, der stadig modtager opkald, eller en ny afdeling, der aldrig blev indekserbar.
• At optimere anmeldelsesscoren i stedet for anmeldelsesprocessen. Portning, pres og incitamenter gør den synlige vurdering mindre repræsentativ og introducerer politisk risiko.
• At lancere uden vedligeholdelsesejerskab. Åbningstider, tjenester, personale, lejemål, telefonruter og anmeldelseslinks ændrer sig; en nøjagtig lancering forfalder uden en ændringsvej.

Næste fase

Denne tjekliste overdrager kontrollerede lokationsdata, godkendt URL-ejerskab, servicetilgængelighed og undtagelser til implementering og måling. Sideejere kan nu anvende on-page og struktureret data-arbejde uden at opfinde lokale fakta; rapporteringsejere kan gruppere resultater efter stabilt lokations-ID; kundeoplevelsesteams kan køre én neutral anmeldelsesproces pr. berettiget interaktion.

Det gentagne næste trin er løbende opdatering og iteration . Det har brug for baseline, sidst-verificerede datoer, korrektionskø, platformsags-ID’er, sidebeslutninger, anmeldelsespolitik-attestation og navngivne ejere fra denne tjekliste. Genåbn tjeklisten straks ved flytning, lukning, åbning, rebranding, telefonændring, serviceændring, fusion eller profil-ejerskabs-hændelse.

Ofte stillede spørgsmål

Ofte stillede spørgsmål

Fuldfør baselinen før udvidelse af sidesættet. Hvis organisationen ikke kan angive det korrekte telefonnummer, servicedækning, sideejer og anmeldelsesvej for en lokation, er den næste nyttige handling datakorrektion—ikke en ny lokal landingsside.