SEO-checklista för lokala och flerplatsföretag
Använd denna lokala SEO-checklista för att granska NAP-data, bygga distinkta platssidor, välja tjänsteområdestäckning och skaffa recensioner utan recensionsstyrning.
Ett lokalt program blir svårt att kontrollera när en företagsidentitet upprepas över profiler, kataloger, sidor, recensionsplattformar och AI-svar. Denna checklista behandlar lokal SEO som ett data- och publiceringssystem: varje plats har en godkänd post, varje sida förtjänar sin existens och varje förändring har en ägare och bevis.
Checklista: lokal SEO och SEO för flera platser. Tidsram: 2–4 timmar för en plats; 2–5 arbetsdagar för att etablera en baslinje för 10–50 platser, därefter månatlig avvikelsegranskning och kvartalsvis fullständig revision. Ägare: lokal SEO-ansvarig eller marknadsföringsoperationsansvarig, med platschefer ansvariga för faktakontroll och kundupplevelseteam ansvariga för recensionsförfrågningar.
Målet är en tillförlitlig identitet per plats, dokumenterade plattformsvariationer, användbara lokala destinationer och bevis för att människor och söksystem kan hitta rätt filial för rätt tjänst.
Varför denna fas, och varför här
Denna checklista använder validerade marknader, tjänster, målgrupper och begränsningar från upptäcktsfasen; fråge- och promptuppsättningar från nyckelords- och promptforskning ; och godkänd URL-ägarskap från den topiska kartan och informationsarkitekturen . Kör den efter dessa beslut eftersom en platsmatris utan efterfrågan skapar sidor genom multiplikation, medan efterfrågan utan operationell verifiering lovar tjänster som en filial inte kan leverera.
Att köra den för tidigt gör varje kombination av stad och tjänst till en förmodad sida. Att köra den för sent lämnar sökmotorer, kartprodukter, kataloger och AI-system att reconciliera motstridiga namn, stängda platser, dubblettprofiler och tunna sidor. Resultatet är inte bara ett rankningsproblem: kunder kan ringa fel nummer, anlända utanför öppettiderna eller efterfråga en tjänst som den valda filialen inte erbjuder.
Resultatet är en kontrollerad lokal datamängd och en godkänd sidplan. Dessa blir kontrakt för implementering på sidan, strukturerad data, intern länkning, recensionshantering, rapportering och senare uppdateringsarbete i den bredare SEO-processen .
Indata och utdata
| Indata | Minsta bevis som krävs | Utdata-kontrakt |
|---|---|---|
| Platsens huvuddata | Juridiskt och handelsnamn, kundvänd adress eller tjänsteområde, lokal telefon, öppettider, status, öppnings-/stängningsdatum, ägare | En kanonisk post per plats, med ett stabilt plats-ID och dokumenterade varianter |
| Tjänstekatalog | Tjänstedefinitioner, behörighet, personal-/utrustningsbegränsningar, bokningsväg, undantag | Boolesk tjänst-på-plats-matris godkänd av verksamheten |
| Befintlig webbnärvaro | URL:er, kanoniska taggar, statuskoder, indexerbarhet, mallar, interna länkar, strukturerad data | Beslut om behåll, förbättra, slå samman, omdirigera eller ta bort för varje lokal URL |
| Extern närvaro | Gjorda anspråk på och ej gjorda anspråk på profiler, kataloger, aggregatorer, sociala profiler, recensionssajter | Citationsinventering med käll-URL, observerat värde, godkänt värde, allvarlighetsgrad, ägare och status |
| Efterfrågeuppsättning | Platsmodifierade frågor, “nära mig”-behov, tjänstefrågor, AI-promptar, Search Console-bevis | Godkänd siduppsättning för platser och tjänsteplatser kopplade till distinkt intention |
| Rykte-data | Recensionslänkar, utlösare för förfrågningar, plattformspolicybegränsningar, klagomålsväg, recensionshistorik per plats | Neutralt arbetsflöde för recensionsförfrågan, svarsägarskap och månatlig recensionsbaslinje |
| Mätningsåtkomst | Search Console-anslutning, analyshändelser, samtals-/bokningsattribuering, AmICited-arbetsyta | Baslinje-instrumentpanel och repeterbar rapporteringsrytm per plats |
Utdata är versionshanterade tabeller som nedströmsägare kan koppla via stabilt plats-ID, sid-URL och profil-URL utan att manuellt matcha fri-text-filialnamn.
Checklistan
1. Etablera platsen som sanningskälla
Skapa en kanonisk post per verklig plats. Vad: tilldela ett stabilt ID och godkänt namn, adress, telefonnummer, öppettider, status, koordinater, webbplatsdestination och verksamhetsägare. Varför: NAP-konsistens —överensstämmelse av namn, adress och telefon—är omöjlig att granska när det “korrekta” värdet finns i e-posttrådar. Hur: exportera poster från verksamheten, kundsupport, butikssystem och webbplatsen; lös konflikter med personen som ansvarar för den fysiska filialen. Verktyg: kalkylark eller databas med ändringshistorik. Klart när: varje aktiv, öppnande, flyttad, tillfälligt stängd och permanent stängd plats har exakt en godkänd post, en ägare, ett senast verifierat datum och inga olösta obligatoriska fält.
Definiera acceptabla varianter innan du flaggar fel. Vad: registrera plattformstvingade förkortningar, policy för spårningsnummer, lägenhetsformatering och undantag för handelsnamn. Varför: “Street” mot “St” kan vara harmlöst, medan ett gammalt samtalspårningsnummer kan dirigera kunder till fel filial; att behandla båda som lika brus slösar korrigeringstid. Hur: normalisera versaler/gemener, skiljetecken, mellanrum, landskoder och adresstoken, jämför sedan identitet och routing snarare än enbart råa strängar. Verktyg: normaliseringsregler plus en diff på radnivå. Klart när: varje observerat värde är klassificerat som exakt, godkänd variant, materiell avvikelse, dubblett eller okänd, och varje materiell avvikelse har en ägare och deadline.
2. Granska profiler och citat som data
Inventera källorna som kunder faktiskt kan stöta på. Vad: fånga webbplatsen, Google Business Profile , Apple och Bing kartlistor, större aggregatorer, relevanta branschkataloger, sociala profiler och högt synliga recensionssajter. Varför: att korrigera en lågkvalitetskatalog medan den dominerande kartprofilen är fel minskar inte kundrisken. Hur: sök efter företagsnamn, gamla namn, telefonnummer, adresser och plats-ID; spara käll-URL och observerade värden snarare än bara en godkänd/underkänd-markering. Verktyg: sökmotor, plattforms-instrumentpaneler, export från listningsleverantörer och citationstabell. Klart när: varje plats har en kontrollerad post för varje prioriterad källa, plus eventuell upptäckt dubblett eller inaktuell profil, med bevisdatum och åtkomststatus.
Åtgärda högprioriterade avvikelser i riskordning. Vad: prioritera fel status, adress, telefon, öppettider, webbplats och dubbelägarskap före kosmetisk formatering. Varför: ett fel med stängd plats eller felkopplat samtal misslyckas direkt för kunden; inkonsekvent versalisering gör oftast inte det. Hur: skicka in ändringar vid källan, spara bekräftelse-ID:n och kontrollera igen efter plattformens angivna bearbetningstid. Verktyg: källplattform, ärendekö och bevislogg. Klart när: noll prioriterade källor visar fel öppen/stängd-status, fysisk plats, telefonväg, öppettider eller webbplatsdestination; återstående undantag har ärende-ID:n och omkontrollsdatum.
3. Validera profilfullständighet och ägarskap
Verifiera och säkra varje profil. Vad: bekräfta att organisationen äger varje profil, att auktoriserade användare är aktuella och att återställningsvägar inte beror på en före detta anställd. Varför: datanoggrannhet är tillfällig när ingen kan underhålla posten eller när en okänd användare kan ändra den. Hur: granska användare, företagsgrupper, e-postdomäner, tvåfaktorsautentisering, återställningskontakter och byrååtkomst. Verktyg: plattformens åtkomstpaneler och åtkomstregister. Klart när: varje prioriterad profil har en verifierad status där sådan erbjuds, minst två nuvarande organisationskontrollerade administratörer, ingen oförklarad ägare och en testad återställningsväg.
Fyll i fält från operationell sanning. Vad: fyll i kategorier, öppettider, helgöppettider, tjänster, bokningslänkar, tillgänglighetsattribut, foton och beskrivning utan att lägga till icke-understödda påståenden. Varför: ofullständiga profiler kan inte besvara vanliga lokala beslut, men ifylld fiktion skapar ett värre problem än ett tomt fält. Hur: mappa varje fält till sanningskällans kolumn eller en ansvarig lokal verifierare. Verktyg: profil-instrumentpaneler och huvuddata. Klart när: alla tillämpliga högvärdiga fält är ifyllda, varje värde kan spåras till en godkänd källa och profilens landnings-URL löser upp till rätt platssida utan en undvikbar omdirigering.
4. Bestäm vilka platssidor som förtjänar att existera
Kräv ett distinkt jobb för varje sida. Vad: skapa en sida endast när den representerar en verklig bemannad plats, ett legitimt tjänsteområde eller ett materiellt annorlunda lokalt beslut. Varför: sidor som endast differentieras av en stads-token är utbytbara och kan bli ett doorway page -mönster: många tunna ingångar byggda för att fånga frågor snarare än att hjälpa besökare. Hur: poängsätt varje kandidat baserat på verifierad efterfrågan, operationell täckning, unika fakta, lokala bevis, konverteringsväg och underhållsägarskap. Verktyg: frågeuppsättning, tjänstematris, sidinventering och innehållsbrief. Klart när: varje godkänd sida har en namngiven primär intention, minst tre platsspecifika bevisfält, en distinkt konverteringsväg eller filialdestination och en ägare; varje avvisad kandidat har en konsolideringsdestination.
Differentiera sidor med fakta, inte adjektiv. Vad: inkludera platsens adress eller angivna tjänsteområde, öppettider, tjänster, personal eller meriter där relevant, vägbeskrivningar eller åtkomstinformation, lokala policyer, originalfoton, recensionsbevis och filialspecifika FAQ:er. Varför: att ändra “betrodd rörmokare i Stockholm” till “betrodd rörmokare i Göteborg” ändrar inte svaret. Hur: samla strukturerade fakta från lokala ägare, förhindra att tomma moduler renderas och jämför syskonsidor sida vid sida. Verktyg: platsbrief, likhetsgranskning och renderade sidor. Klart när: inga två publicerade platssidor delar en identisk kombination av huvudsvaret, tjänstebevis, vägbeskrivningstext, FAQ-uppsättning och CTA; all gemensam policy är tydligt organisationsövergripande snarare än presenterad som lokalt bevis.
5. Godkänn kombinationer av tjänsteområde och tjänst-på-plats
Bygg matrisen innan du bygger URL:er. Vad: korsreferera platser eller tjänsteområden med tjänster och markera erbjudna, begränsade, endast via remiss, säsongsbetonade eller ej tillgängliga. Varför: ett nyckelordsverktyg kan identifiera efterfrågan men kan inte bekräfta resavstånd, licensiering, lager, personal eller svarstid. Hur: låt verksamheten godkänna varje kombination och bifoga begränsningar samt ikraftträdandedatum. Verktyg: tjänste-plats-matris och efterfrågedata. Klart när: varje publicerad kombination är både efterfrågestödd och operationellt sann, varje begränsning är synlig på destinationen och ingen URL gör anspråk på en otillgänglig tjänst.
Välj en destination per intention. Vad: besluta om platssidan, tjänstesidan eller en genuint specifik tjänst-på-plats-sida bäst besvarar varje fråga. Varför: att publicera alla tre för samma intention får webbplatsens egna URL:er att konkurrera och sprider bevis över närapå-dupletter. Hur: tilldela en primär URL, mappa stödjande interna länkar och konsolidera lågefterfrågade kombinationer till användbara moduler eller filter på en starkare sida. Verktyg: intention-till-URL-karta och Search Console landningssidors bevis. Klart när: varje spårad lokal intention har en primär indexerbar destination, ingen oförklarad konkurrerande URL och varje indexerbar tjänste-plats-sida uppfyller det distinkta sidtestet ovan.
6. Gör lokala sidor tekniskt entydiga
Rikta identitet över synligt innehåll och maskinläsbara fält. Vad: använd samma godkända filialidentitet i titeln, huvudrubriken, kontaktblocket, kanoniska taggen, interna länkar och tillämplig strukturerad data. Varför: motstridiga enhetsnamn eller adresser tvingar crawlers och AI-system att gissa vilken filial sidan representerar. Hur: generera fält från den stabila plats-posten och testa den serverlevererade HTML-koden. Verktyg: källinspektör, strukturerad data-validerare och crawlexport. Klart när: varje indexerbar sida returnerar 200, har en självrefererande kanonisk tagg, exponerar en entydig platsidentitet och dess synliga kontaktinformation matchar den godkända posten.
Koppla samman sidor utan att skapa en stadslänksmur. Vad: tillhandahåll en användbar lokalisator eller regional hierarki och kontextuella länkar till validerade tjänster. Varför: kunder behöver röra sig mellan närliggande alternativ, men hundratals repetitiva nyckelordslänkar döljer sidan och antyder täckning som företaget kanske inte har. Hur: gruppera platser efter geografi som användare förstår, begränsa tjänstelänkar till verifierad tillgänglighet och säkerställ att varje godkänd sida har en inkommande väg. Verktyg: crawlgraf och renderad navigation. Klart när: noll godkända platssidor är föräldralösa, varje länk löser upp, länketiketter identifierar destinationen tydligt och ingen plats länkar till en otillgänglig tjänst.
7. Bygg ett policy-säkert recensionssystem
Fråga varje berättigad kund via samma neutrala väg. Vad: utlös en recensionsförfrågan efter en verklig genomförd interaktion, med samma offentliga recensionsmöjlighet oavsett förväntad känsla. Varför: recensionsstyrning (review gating)—att skicka nöjda kunder till en offentlig plattform medan missnöjda kunder styrs till privat återkoppling—förvränger underlaget och kan bryta mot plattformsregler. Hur: definiera berättigande, tidpunkt, undertryckning, samtycke, formulering och platsspecifik destination; håll privat support tillgänglig utan att göra den till ett villkor för offentlig recension. Verktyg: CRM eller meddelandearbetsflöde, plattformens recensionslänk och förfrågningslogg. Klart när: en dokumenterad regel gäller för alla berättigade kunder, ingen fråga sållar efter tillfredsställelse innan recensionsalternativet presenteras, varje länk landar på rätt plats och arbetsflödet lagrar skickade, undertryckta, misslyckade och avböjda utfall.
Övervaka och svara utan att skripta bort ansvar. Vad: spåra recensionssignaler såsom antal, betyg, aktualitet och plats, dirigera sedan svar och operationella ärenden. Varför: ett mål för “fler femstjärniga recensioner” inbjuder till påtryckningar och incitament; ett mål för representativ återkoppling och lösta problem förbättrar den underliggande upplevelsen. Hur: använd faktabaserade, icke-defensiva svarsriktlinjer, förbjud personal-skrivna recensioner och ej avslöjade incitament, och eskalera säkerhets-, juridiska- eller integritetsärenden. Verktyg: recensionsplattform, svarskö och månatligt platskort. Klart när: varje ny recension tilldelas eller besvaras inom organisationens servicenivå, varje allvarligt ärende har en ärendeägare och granskningen finner noll styrda, fabricerade, anställdas eller felaktigt incitamentstyrda förfrågningar.
8. Baslinjemätning per plats
Separera närvaro, trafik och konvertering. Vad: registrera profilnoggrannhet, sidindexerbarhet, organiska klick och visningar, spårade lokala promptar, samtal, bokningar, vägbeskrivningsförfrågningar och kvalificerade leads där tillgängligt. Varför: en rankningsförändring är inte ett affärsresultat, och en aggregerad totalsumma kan dölja att en filial vinner medan en annan försvinner. Hur: sammanfoga poster via plats-ID och URL, behåll otillgängliga värden som okända snarare än noll, och annotera öppningar, stängningar, flyttar och spårningsändringar. Verktyg: AmICited, Search Console, analys, samtalspårning, bokningsdata och rapporteringstabell. Klart när: varje aktiv plats har en daterad baslinje, källa, period och ägare; mätvärden kan filtreras per plats; och saknad spårning är en explicit åtgärd snarare än tyst behandlad som ingen prestanda.
Verktyg i AmICited
AmICited mäter synlighetsresultat för ägda sidor och AI; det redigerar inte externa företagslistningar. Gör korrigeringar i källplattformarna och använd sedan dessa rapporter för att verifiera om platsegendomen är upptäckbar och presterar.
- Öppna Google Search Pages med Google Search Pages för att jämföra klick, visningar, klickfrekvens och genomsnittlig position per plats-URL, inspektera sedan en sida som saknas eller är oväntat svag.
- Öppna Google Search Directories med Google Search Directories när platssidor delar en katalog. En sektionsnivåminskning kan identifiera ett mall-, navigations- eller lanseringsproblem innan enskilda filialer granskas.
- Öppna Prompt Tracking med Prompt Tracking & Management för att ladda representativa tjänste-plus-plats och “nära mig”-promptar. Spåra endast promptar som matchar faktisk täckning och håll land- och språkinställningar explicita.
- Öppna AI Rank Tracker med AI Rank Tracker för att se om organisationen nämns eller citeras för den godkända lokala promptuppsättningen över supported AI-motorer.
- Öppna Content Freshness med Content Freshness för att upptäcka plats-URL:er som lagts till, uppdaterats eller tagits bort från webbplatskartor. Använd händelsen som en granskningsutlösare; det bevisar inte att kontaktuppgifterna är korrekta.
Beslutsregler
Använd siffror för att göra “dåligt” handlingsbart. Dessa är operativa grindar, inte påståenden om rankningsfaktorers vikt.
| Upptäckt | Dålig tröskel | Krävt beslut |
|---|---|---|
| Aktiv plats utan godkänd huvudpost, stabilt ID, ägare eller verifierat datum | 1 eller fler | Blockera ny sida/profilpublicering tills posten finns |
| Prioriterad profil med fel status, adress, telefonväg, öppettider eller webbplats | 1 eller fler | Kritisk korrigeringsärende; kontrollera igen vid källan |
| Prioriterad profil kontrollerad endast av ett personligt eller före detta anställds konto | 1 eller fler | Lägg till organisationskontrollerade administratörer och återställning |
| Olöst dubblettprofil för samma plats | 1 eller fler | Slå samman, ta bort eller dokumentera plattformsärende och uppföljningsdatum |
| Kandidatsida med färre än 3 platsspecifika bevisfält | Någon | Konsolidera eller samla bevis; publicera inte |
| Indexerbara sidor differentierade endast av ortnamn eller tokenbyten | 2 eller fler | Stoppa utrullning och konsolidera mönstret |
| Publicerat tjänste-plats-påstående inte godkänt i nuvarande matris | 1 eller fler | Ta bort påståendet eller korrigera operationsdata omedelbart |
| Spårad lokal intention tilldelad flera primära indexerbara URL:er | 1 eller fler | Välj en ägar-URL och slå samman, omdirigera eller placera om andra |
| Godkänd platssida som returnerar non-200, blockerad, föräldralös eller kanoniserad till annan sida | 1 eller fler | Tekniskt fel; åtgärda innan prestandamätning |
| Recensionsflöde frågar om tillfredsställelse innan offentlig recensionsväg erbjuds | Någon förekomst | Stoppa arbetsflödet: recensionsstyrning är förbjuden |
| Recensionsförfrågan pekar på fel filial | 1 eller fler | Pausa den platsens utskick tills routing är korrigerad |
| Fabricerad, anställdsskriven eller ej avslöjad incitamentstyrd recensionsaktivitet | Någon förekomst | Stoppa, dokumentera, eskalera och åtgärda enligt plattformspolicy |
| Aktiv plats utan daterad mätningsbaslinje | 1 eller fler | Tilldela spårningsägare och deadline; rapportera som okänd, inte noll |
| Fullständig granskningsålder | Mer än 90 dagar | Gör om granskningen; kör omedelbart efter materiella förändringar av platsdata |
Likhet är en granskningsutlösare, inte en automatisk borttagningsregel. Två platser kan dela organisationsövergripande garantier eller tjänstedefinitioner. De behöver fortfarande distinkta lokala bevis och en annan verklig destination; en låg likhetspoäng kan inte rädda en fiktiv filial.
Leverans
Överlämna en arbetsbok eller databasexport plus en kort beslutslogg. CSV är acceptabelt när en tabell används; använd separata relationella flikar när programmet har flera platser och tjänster.
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
Inkludera korrigeringskön, listan över avvisade sidor, konsolideringsbeslut, olösta plattformsärenden, bevis och nästa granskningsdatum. Den lokala SEO-ansvarige signerar data- och sidbeslut; verksamheten signerar tillgänglighet; kundupplevelse signerar recensionsarbetsflödet.
Vad går fel
- Att använda webbplatsen som huvuddatabas. En gammal sida kan se auktoritativ ut medan verksamheten, kartor och uppringare använder olika fakta.
- Att behandla NAP som rå stränglikhet. Team åtgärdar harmlöst skiljetecken medan de förbiser ett telefonnummer som når en annan filial.
- Att publicera den kartesiska produkten. Femtio platser multiplicerat med tjugo tjänster skapar 1 000 URL:er, inte 1 000 användbara svar.
- Att kalla mallbaserad prosa för “lokal”. Ett ortnamn, en vädersats och en stockbild visar inte lokal personal, åtkomst, bevis eller tillgänglighet av tjänster.
- Att dölja adressen till ett tjänsteområdesföretag utan att definiera täckning. Kunder behöver fortfarande ett ärligt område, begränsningar, svarstidsförväntning och bokningsväg.
- Att låta lokala chefer improvisera profilnamn. Att lägga till nyckelord i företagsnamnet fragmenterar identiteten och kan strida mot plattformspolicy.
- Att medelvärdesberäkna alla platser tillsammans. En nationell vinst kan dölja en stängd filial som fortfarande får samtal eller en ny filial som aldrig blev indexerbar.
- Att optimera recensionspoängen istället för recensionsprocessen. Styrning, påtryckningar och incitament gör det synliga betyget mindre representativt och introducerar policyrisk.
- Att lansera utan underhållsägarskap. Öppettider, tjänster, personal, hyreskontrakt, telefonvägar och recensionslänkar ändras; en korrekt lansering förfaller utan en ändringsväg.
Nästa fas
Denna checklista överlämnar kontrollerad platsdata, godkänt URL-ägarskap, tillgänglighet av tjänster och undantag till implementering och mätning. Sidägare kan nu tillämpa arbete på sidan och med strukturerad data utan att uppfinna lokala fakta; rapporteringsägare kan gruppera resultat efter stabilt plats-ID; kundupplevelseteam kan köra en neutral recensionsprocess per berättigad interaktion.
Nästa återkommande steg är kontinuerlig uppdatering och iteration . Det behöver baslinjen, senast verifierade datum, korrigeringskön, plattformsärendens ID:n, sidbeslut, recensionspolicy-intyg och namngivna ägare från denna checklista. Öppna checklistan omedelbart igen vid en flytt, stängning, öppning, omprofilering, telefonnummerändring, tjänsteändring, fusion eller profilägarskapshändelse.
FAQ
Vanliga frågor
Behöver varje fysisk plats en egen sida?
Bör ett tjänsteområdesföretag publicera en sida för varje stad det täcker?
Hur exakt måste NAP-data vara?
Vad är recensionsstyrning (review gating)?
Hur ofta bör ett program med flera platser granskas?
Slutför baslinjen innan du utökar siduppsättningen. Om organisationen inte kan ange rätt telefonnummer, tjänstetäckning, sidägare och recensionsväg för en plats, är nästa användbara åtgärd datakorrigering—inte ytterligare en lokal landningssida.
Fler tutorials i det här avsnittet
Redo att omsätta det i praktiken?
Gratis kontroll · 7 dagars provperiod · inget kreditkort