Lokal SEO for store bedrifter: WordPress multisite-strategier i 2026

Å styre den organiske synligheten for ett enkelt fysisk utsalgssted er en forholdsvis enkel oppgave. Når en bedrift vokser til 50, 100 eller 500 avdelinger, filialer eller klinikker i Norge og resten av Norden, oppstår derimot en krevende utfordring med teknisk styring: hvordan beholde sentral kontroll over merkevaren uten å gi slipp på den hyperlokale relevansen som søk etter “i nærheten” krever.

Mange merkevarer med flere lokasjoner bruker WordPress Multisite som infrastruktur for å forene domenets nasjonale autoritet med det særegne ved hver fysiske lokasjon. Denne guiden beskriver arkitekturen og viser for hvert punkt hva dokumentasjonen fra Google og WordPress faktisk sier, for mye av det som sirkulerer om lokal SEO i stor skala, er folklore.

Se våre avanserte SEO- og GEO-tjenester, utviklet for multiregionale bedriftsarkitekturer.

#1. Hvorfor bruke WordPress Multisite for mange avdelinger

En vanlig feil blant store kjeder er å velge ett av to problematiske ytterpunkter: å samle alle butikkene på én statisk listeside, eller å lage titalls helt separate WordPress-installasjoner. Det første alternativet har ikke nok dybde til å rangere på spesifikke geografiske søkeord; det andre skaper et mareritt for sikkerhet og vedlikehold, med hundrevis av databaser og isolerte kontrollpaneler.

WordPress Multisite løser dette dilemmaet med en samlet plattform som driver et nettverk av undernettsteder fra én kodebase:

• Sentral styring av temaer og utvidelser: Sikkerhetsoppdateringer, bedriftens temaer og analyseverktøy installeres én gang på nettverksnivå av Superadmin.
• Isolerte datatabeller: Hvert undernettsted har sitt eget sett med tabeller (wp_X_posts, wp_X_options), slik at lokale innstillinger og innlegg holdes strengt adskilt.
• Detaljert rettighetshierarki: Lokale ledere får begrenset redigeringstilgang til å oppdatere spesielle åpningstider eller publisere lokale kunngjøringer, uten risiko for å ødelegge portalens arkitektur.

WordPress-dokumentasjonen om Multisite oppsummerer datamodellen i én setning: innholdet på hvert nettsted har “sine egne tabeller i databasen, bare brukertabellen er felles for instansene” (egen oversettelse). Samme side minner om at URL-omskriving må være aktivert for å bruke Multisite.

#2. Undermapper eller subdomener for lokale sider

Adressestrukturen bestemmer hvor hver avdeling bor og hva den koster å vedlikeholde. Tabellen nedenfor følger sammenligningen Google publiserer i Administrere flerregionale og flerspråklige nettsteder, brukt på bysider:

Google gir ingen av disse modellene en rangeringsfordel. For en butikkjede i ett land vinner undermapper som regel på driften: ett sertifikat, én hosting, ett cacheoppsett. Subdomener gir mening når det finnes tekniske grunner til å betjene regioner fra ulike servere.

På WordPress-siden forklarer siden Opprett et nettverk at valget mellom subdomener og undermapper tas når nettverket installeres, og at det er mulig å konfigurere nettverket om til det andre alternativet senere, selv om endringen krever arbeid. Samme side presiserer at wildcard-DNS bare trengs for nettsteder som opprettes ved behov basert på domene, selv om installasjonsskjermen antyder noe annet.

#3. Slik legger du til LocalBusiness-schema for hver avdeling

Strukturert kode forteller søkemotorene eksplisitt hva hvert utsalgssted heter, hvor det ligger og når det har åpent. Ifølge dokumentasjonen for LocalBusiness-strukturerte data kan de som søker etter bedrifter i Google Søk eller Maps, få se et kunnskapspanel med disse detaljene.

Hvert undernettsted i Multisite-nettverket bør dynamisk generere fullstendig og spesialisert JSON-LD-markering. Eksemplet bruker et fiktivt merke:

<!-- Eksempel på LocalBusiness JSON-LD generert for en avdeling (fiktivt merke) -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Store",
  "name": "Merke Eksempel Bergen",
  "url": "https://example.com/bergen/",
  "telephone": "+47 55 00 00 00",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Eksempelgata 100",
    "addressLocality": "Bergen",
    "postalCode": "5000",
    "addressCountry": "NO"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 60.39299,
    "longitude": 5.32415
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:00:00",
      "closes": "18:00:00"
    }
  ]
}
</script>

Googles regler som dette eksemplet følger:

• Påkrevd: bare name og address, med så mange adresseegenskaper som mulig.
• Koordinater: i geo skal breddegrad og lengdegrad ha en presisjon på “minst 5 desimaler” (egen oversettelse).
• Åpningstider: opens og closes i formatet hh:mm:ss; openingHoursSpecification godtar ett objekt eller en liste.
• Telefon: hovednummeret for kunder, med lands- og retningsnummer.
• URL: den fullstendige adressen til den konkrete lokasjonen, og den må være en lenke som fungerer. I et Multisite-nettverk er det avdelingens side, ikke merkevarens forside.
• Undertype: Google ber om den mest spesifikke undertypen av LocalBusiness som finnes (i eksemplet Store).
• Avdelinger: et utsalgssted med apotek eller verksted kan beskrive hver seksjon med department.

Et punkt mange guider overser: aggregateRating og review anbefales, med Googles egne ord, bare for nettsteder som samler inn anmeldelser av andre lokale bedrifter. En kjede som merker opp anmeldelsene av sine egne butikker, faller ikke inn under dette.

Med egendefinerte felt (for eksempel Advanced Custom Fields) eller REST API-et fylles disse dataene inn i databasen til hver avdeling og settes automatisk inn i HTML-en, uten manuell programmering fra det lokale teamet.

#4. Synkroniser NAP-data med Google Business Profile

Avvik i NAP-dataene (Name, Address, Phone) mellom nettstedet, de strukturerte dataene og Google Business Profile skaper tvil om hvilken informasjon som stemmer. Hvis adressen på nettstedet oppgir et annet postnummer enn det som er registrert i profilen, får både brukeren og søkemotoren to versjoner av samme butikk.

For å sikre løpende synkronisering fungerer WordPress som hovedregister for dataene:

1. Sentral database: Adresse, åpningstider og kontaktopplysninger for alle butikkene holdes i et kanonisk format i WordPress.
2. API-koblinger: Planlagte jobber (WP-Cron eller crontab på serveren) sender endringene til API-ene for Google Business Profile, for dem som har tilgang til dem.
3. Spredning av unntak: Når en leder endrer stengetiden på grunn av en lokal helligdag, går endringen ut fra ett sted til nettstedet, de strukturerte dataene og profilen.

#5. Hva retningslinjene for Google Business Profile krever av en butikkjede

Retningslinjene for å representere bedriften din på Google definerer hva hver post i WordPress må inneholde før den sendes til profilen:

• Én profil per lokasjon: Google ber deg ikke opprette mer enn én side per lokasjon, “på én konto eller på flere kontoer” (egen oversettelse).
• Navn: skal gjenspeile virksomhetens faktiske navn, uten unødvendig informasjon. I en kjede “må alle lokasjonene ha samme navn”, med mindre den faktiske fremtoningen varierer fra butikk til butikk (egen oversettelse). Et felt offentlig_navn per avdeling, med merkenavnet låst på nettverksnivå, hindrer at en leder legger til søkeord.
• Adresse: må være den faktiske fysiske lokasjonen; postbokser og virtuelle kontorer kvalifiserer ikke.
• Telefon: under bedriftens direkte kontroll; Google foretrekker et lokalt nummer fremfor et sentralt kundesenternummer når det er mulig.
• Nettsted: skal representere den enkelte lokasjonen. I et Multisite-nettverk peker dette naturlig til avdelingens URL.
• Avdelinger: avdelinger med kundebetjening som fungerer som egne enheter, kan ha egen profil, med et annet navn enn hovedvirksomheten.
• Virksomheter med serviceområde: én profil for hovedkontoret med definert serviceområde, og adressen skjult for kundene.

For verifisering gjelder siden om massebekreftelse for dem som har “10 eller flere lokasjoner av samme virksomhet” (egen oversettelse). Forespørselen sendes med et regneark over alle profilene du administrerer, den er ikke tilgjengelig for virksomheter med serviceområde, og den kan kreve videobekreftelse med en autorisert representant på stedet. En eksport generert fra tabellene i Multisite-nettverket er den mest direkte måten å lage dette regnearket på uten kopieringsfeil.

#6. Slik lager du lokale sider uten duplisert innhold

Å lage 100 bysider bare ved å bytte ut stedsnavnet i en statisk tekst (“De beste IT-tjenestene i Trondheim”, “De beste IT-tjenestene i Stavanger”) gir sider med lav verdi.

Googles retningslinjer for spam beskriver dette mønsteret uten omsvøp. Blant eksemplene på misbruk av doorway-sider står “å ha flere domenenavn eller sider rettet mot bestemte regioner eller byer som sender brukerne videre til én side” (egen oversettelse). Samme side definerer misbruk av innhold i stor skala som å generere mange sider med hovedformål å manipulere rangeringen og ikke å hjelpe brukerne. Et Multisite-nettverk med 500 nesten identiske undernettsteder passer inn i begge definisjonene.

Hvert lokale undernettsted bør berikes med ekte substans:

• Teamet på stedet: Presentasjon med bilde, navn og fagområde for de ansatte ved avdelingen.
• Prosjekter og kundecaser fra regionen: Korte omtaler av oppdrag for lokale virksomheter og organisasjoner, når slike finnes og kan publiseres.
• Adkomst og transport: Konkret informasjon om T-banestasjoner, bussholdeplasser eller parkeringsplasser i nærheten.
• Lokale initiativer: Omtale av deltakelse på lokale messer, foredrag eller idrettssamarbeid i kommunen.

Den praktiske testen er om brukeren ville miste informasjon som ikke finnes på den nasjonale siden, hvis avdelingssiden forsvant. Hvis ikke, bør siden ikke lages.

#7. Opprett nye avdelinger med WP-CLI

Å opprette hundrevis av avdelinger manuelt i kontrollpanelet tar hundrevis av timer og mangedobler antallet konfigurasjonsfeil. Den sentrale administrasjonen bør bruke kommandolinjen via WP-CLI.

#Aktiver Multisite med undermapper i wp-config.php

Første steg er define( 'WP_ALLOW_MULTISITE', true );. Når nettverket er opprettet, viser installasjonsskjermen de endelige linjene, tilpasset installasjonen din; for et nettverk med undermapper ser de slik ut:

/* Konfigurasjon av Multisite-nettverk med undermapper */
define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
define('DOMAIN_CURRENT_SITE', 'merke.no');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

#Klon nye avdelinger med Bash og WP-CLI

Skriptet tar utgangspunkt i et malnettsted (ID 2, på merke.no/mal/). Etter at tabellene fra malen er kopiert, peker valgene siteurl og home fortsatt til malen, så steg 3 retter dem med en search-replace begrenset til det nye nettstedet:

#!/usr/bin/env bash
# Skript for automatisk klargjøring av nye avdelinger i WordPress

BY_SLUG="bergen"
BY_NAVN="Bergen"
EPOST_LEDER="[email protected]"

# 1. Opprett nytt undernettsted i Multisite-nettverket
NY_BLOG_ID=$(wp site create --slug="$BY_SLUG" --title="Merke $BY_NAVN" --email="$EPOST_LEDER" --porcelain)

# 2. Klon innstillinger og blokker fra standardmalen (site_id 2)
wp db export /tmp/mal.sql --tables=$(wp db tables "wp_2_*" --format=csv)
sed -i "s/wp_2_/wp_${NY_BLOG_ID}_/g" /tmp/mal.sql
wp db import /tmp/mal.sql
rm /tmp/mal.sql

# 3. Rett URL-ene som er arvet fra malen, og lokasjonens metadata
wp search-replace "merke.no/mal/" "merke.no/$BY_SLUG/" --url="merke.no/$BY_SLUG/"
wp option update blogname "Merke $BY_NAVN" --url="merke.no/$BY_SLUG/"
wp post update 1 --post_title="Avdeling $BY_NAVN" --url="merke.no/$BY_SLUG/"

echo "Undernettsted i drift på merke.no/$BY_SLUG/ med ID $NY_BLOG_ID"

Test skriptet i et staging-miljø før du bruker det i produksjon: kopiering av tabeller går ikke gjennom WordPress-hookene, og utvidelser som lagrer data i egne tabeller, må håndteres separat.

#8. Hvem styrer hva i administrasjonen av et Multisite-nettverk

Maktfordelingen som beskrives i dokumentasjonen om nettverksadministrasjon, er det som gjør modellen trygg for hundrevis av lokale ledere:

• Superadmin: bare Superadmin installerer temaer og utvidelser. Med dokumentasjonens ord: “nettstedsadministratorer kan ikke installere nye temaer eller utvidelser” (egen oversettelse).
• Utvidelser: Superadmin kan aktivere en utvidelse for hele nettverket (Aktiver for nettverket), for eksempel utvidelsen som genererer LocalBusiness JSON-LD, slik at ingen avdeling står uten den.
• Temaer: et tema må være aktivert for nettverket eller tillatt under fanen Temaer for det aktuelle nettstedet. Bedriftens tema er tilgjengelig for alle; alternative temaer vises ikke for avdelingene.
• Utvidelsesmenyen: om nettstedsadministratorer får tilgang til utvidelsesskjermen, er et valg under Nettverksinnstillinger. I en butikkjede gir det mening å la det være slått av.
• Filer: det første nettstedet lagrer opplastinger i /wp-content/uploads/ og de neste i /wp-content/uploads/sites/, noe som gjør det mulig å ta sikkerhetskopier og rydde opp per avdeling.

Fordi brukertabellen er felles, kan en regionsjef ha rollen Redaktør på ti undernettsteder med én konto, og en butikksjef bare på sitt eget.

#9. Egne domener for franchisetakere med domenekartlegging

Ikke alle lokasjoner ligger under hoveddomenet. En franchisetaker med eget merke kan kreve sitt eget domene. Ifølge siden om domenekartlegging har denne funksjonen vært innebygd i Multisite siden WordPress 4.5: i nettverkspanelet, under Nettsteder, redigerer du undernettstedet og skriver inn den fullstendige URL-en i feltet Nettstedsadresse (URL).

De praktiske kravene, alle fra samme side:

• DNS: de ekstra domenene må peke til nettverkets hoveddomene før kartleggingen.
• SSL: sertifikat på hoveddomenet og SNI for de øvrige; hvert domene bør ha SSL slik at innloggingen i kontrollpanelet blir kryptert.
• Informasjonskapsler: hvis innloggingen feiler på et kartlagt undernettsted, sier dokumentasjonen at du skal legge til define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] ); i wp-config.php, etter nettverkskoden.

Avveiningen er den samme som i tabellen i seksjon 2: hvert selvstendig domene må bygge opp sin tilstedeværelse fra bunnen, så kartlegging tjener merkevareidentitet, ikke SEO.

#10. Hreflang når nettverket dekker flere land

Et nettverk med avdelinger i Norge, Sverige og Danmark har ofte den samme tjenestesiden på norsk bokmål, svensk og dansk. Det er her hreflang kommer inn, slik Google beskriver det i Lokaliserte versjoner av siden din:

• Tre metoder: link-tagger i HTML, HTTP-headere eller XML-nettstedskartet. I et Multisite-nettverk er nettstedskartet som hvert undernettsted genererer, den enkleste metoden å vedlikeholde.
• Gjensidighet: “hver språkversjon må liste seg selv og alle de andre versjonene” (egen oversettelse). Hvis det svenske undernettstedet peker til det norske og det norske ikke peker tilbake, feiler annoteringen.
• x-default: den reserverte verdien som brukes når ingen språk eller region passer til nettleserens innstillinger, for eksempel en side der man velger land.
• Koder: bare språkkoder etter ISO 639-1 og regionkoder etter ISO 3166-1 Alpha 2 godtas, som nb-NO, sv-SE eller da-DK. Google er tydelig: du kan ikke oppgi landskoden alene.
• Språkgjenkjenning: Google bruker verken hreflang eller HTML-attributtet lang til å avgjøre hvilket språk en side er på; den synlige teksten må faktisk være på det språket.

Bysider innenfor samme land og samme språk skal ikke ha hreflang seg imellom: Oslo og Bergen er ikke språkversjoner av hverandre.

#11. Hvorfor ikke tilpasse innholdet etter IP eller nettleserspråk

En vanlig fristelse i store nettverk er å sende den besøkende automatisk videre til nærmeste avdeling. Den samme Google-siden om flerregionale nettsteder fraråder denne tilnærmingen av to grunner:

• Søkeroboten sender HTTP-forespørsler uten headeren Accept-Language, så innhold som endres etter nettleserspråket, blir kanskje aldri funnet.
• “Ikke bruk IP-analyse for å tilpasse innholdet ditt” (egen oversettelse), fordi lokalisering basert på IP er vanskelig og som regel lite pålitelig.

Google anbefaler ulike URL-er for hver versjon og ignorerer metatagger for lokasjon som geo.position. I praksis: en synlig butikkvelger med gjennomsøkbare lenker til hvert undernettsted, i stedet for en stille omdirigering. Blant signalene Google bruker for å forstå hvem et nettsted er rettet mot, er lokale adresser og telefonnumre på siden, enda en grunn til å vise NAP-dataene i HTML-en til hver avdeling.

#12. Gjør Multisite raskere med edge-caching og Redis

En WordPress-installasjon med hundrevis av undernettsteder i produksjon krever særlig omtanke i arkitekturen:

• Edge-caching via CDN: Fordel den statiske sidecachen på tilstedeværelsespunktene (PoP) til et CDN som Cloudflare eller Fastly, nærmest brukerne i hver region.
• Objektcache med Redis: Installer Redis Object Cache for å lagre resultatene fra valg og metadata fra nettverkets hundrevis av tabeller i RAM.
• Databaseindeksering: Hold tabellene wp_blogs og wp_site optimalisert, slik at webserverens ruting av forespørsler går friksjonsfritt.

Serverens plassering er også et av målgruppesignalene Google lister opp, men Google sier selv at det ikke er et avgjørende signal. CDN-et gir hastighet; den geografiske målrettingen kommer fra dataene på siden og fra hreflang.

#13. Modenhetsmodell for lokal SEO i bedrifter

Når du bygger bedriftens nettverk på WordPress Multisite, kombinerer merkevaren styringen til en bedriftsportal med lokale sider som svarer dem som leter etter hver enkelt butikk, så lenge hver side har eget innhold og data som stemmer med Google-profilen.