Et nettsted for en franchisekjede med flere lokasjoner trenger en felles WordPress-infrastruktur med lokasjonssider bygd på en gjenbrukbar mal. Riktig arkitektur – enten det er en underkatalogstruktur i én WordPress-installasjon eller et Multisite-nettverk – lar hovedkontoret opprettholde merkevarestandarder og gir de enkelte lokasjonene nok fleksibilitet til å rangere i lokale søk. Å ta denne beslutningen riktig fra første dag sparer deg for måneder med opprydding senere.
De fleste franchisenettsteder feiler ikke på grunn av dårlig design, men på grunn av et arkitekturvalg som ble tatt for tidlig, uten å forstå avveiningene for SEO og drift. Denne guiden viser hva du må bestemme, i hvilken rekkefølge og hvorfor.
Det viktigste
- URL-strukturer med underkataloger er det praktiske standardvalget for de fleste franchisenettsteder – de forenkler analyse, internlenking, innholdsstyring og gjennomsøking under ett domene. Google oppgir at det kan rangere underdomener og underkataloger likt; valget er først og fremst arkitektonisk, ikke et rangeringsvalg.
- Én WordPress-installasjon håndterer de fleste franchisenettverk effektivt. Multisite gir mening når lokasjonene trenger reell driftsmessig atskillelse – egne administratorer, egne tillatelser eller flere franchisemerker som deler én WordPress-motor i stedet for å vedlikeholde separate kodebaser.
- Lokasjonssider trenger innhold som faktisk er forskjellig – ikke bare byttede bynavn. I IMADOs implementeringer bygger vi hver lokasjonsside rundt minst fem lokasjonsspesifikke elementer, slik at sidene skiller seg tydelig fra hverandre.
- Strukturerte data av typen LocalBusiness gir Google eksplisitt, maskinlesbar informasjon om hver fysiske lokasjon og kan støtte aktuelle lokale søkefunksjoner. På franchisenettsteder er de gjennomgående for dårlig implementert.
- Ytelseskravene på franchisenettsteder øker med trafikkmengde og kompleksiteten i spørringene, ikke med antall lokasjoner. CDN og objektcache blir viktig når du har lokasjonssider med mye trafikk, krevende geospørringer eller dynamiske integrasjoner per lokasjon – ikke bare fordi du har passert et visst antall sider.
URL-struktur for franchisenettsteder: underkatalog, underdomene eller separate domener?
For de fleste franchisenettsteder er underkataloger riktig valg. Stistrukturen domain.com/locations/chicago/ holder alt innhold under ett domene, noe som forenkler gjennomsøking, internlenking, analyse og innholdsstyring. Valget handler ikke først og fremst om rangering – Google oppgir at det kan rangere underkatalog- og underdomenestrukturer likt.
Dataene fra casestudier peker mot underkataloger. Da IWantMyName gikk fra en underkatalog til underdomener, falt den organiske trafikken med 47 % ifølge en casestudie dokumentert av CognitiveSEO. Pink Cake Box gikk motsatt vei – fra underdomener til underkataloger – og fikk 40 % mer organisk trafikk. Dette er nyttige datapunkter, selv om Googles egen veiledning er at det kan rangere begge strukturene likt. Ta beslutningen ut fra hva som er enklest å drifte.
Underdomener har ett legitimt bruksområde: franchisekjeder der de enkelte lokasjonene opererer som juridisk eller merkevaremessig separate enheter, hver med sin egen Google-bedriftsprofil, andre tjenester og innhold som skiller seg betydelig fra hovedkontorets. Selv da gir et godt strukturert underkatalogoppsett vanligvis bedre resultater rent SEO-messig.
Separate domener per lokasjon er nesten aldri verdt den ekstra driften, med mindre du driver en reell portefølje av flere merkevarer og ikke en franchisekjede med en samlet merkevareidentitet.
| Faktor | Underkatalog | Underdomene | Separat domene |
|---|---|---|---|
| Samling av SEO-verdi | Best | Oppsplittet | Helt oppsplittet |
| Styring fra hovedkontoret | Enklest | Middels | Mest kompleks |
| Innholdsredaktører per lokasjon | Mulig (rollebasert) | Enklere | Enklest |
| Kompleksitet i oppsettet | Lav | Middels | Høy |
| Anbefalt for franchisekjeder | Ja | Bare i spesialtilfeller | Bare for merkevareporteføljer |
WordPress Multisite eller én installasjon: hvilken arkitektur passer franchisekjeden din?
Riktig arkitektur avhenger av behovet for driftsmessig atskillelse, ikke av antall lokasjoner. Et sentralt styrt nettverk med 100 lokasjoner kan fungere godt på én installasjon med en egen innholdstype for lokasjoner (CPT). Åtte franchisetakere som trenger egne administratorer, uavhengige utvidelsesoppsett eller egen merkevarestyring på en felles motor – det er et tilfelle for Multisite.
Multisite gir reell ekstra drift. Hver utvidelse må være kompatibel med Multisite, og endringer i hele nettverket krever superadministrator-tilgang. Temaoppdateringer slår inn på alle undernettsteder samtidig, noe som er kraftfullt når det fungerer og forstyrrende når det ikke gjør det. I et nettverk der hovedkontoret styrer alt innhold, gir den ekstra driften deg ingenting.
For at utvikling med WordPress Multisite skal gi mening, bør minst ett av disse punktene stemme: franchisetakerne må styre eget innhold selvstendig, enkeltlokasjoner trenger egne utvidelsesoppsett, eller selskapsstrukturen krever at data holdes atskilt mellom lokasjonsenhetene. Multisite passer også naturlig for franchisegrupper som driver flere separate merkevarer fra én WordPress-motor – det er betydelig billigere enn å vedlikeholde en egen kodebase for hver merkevare.
Som et grovt utgangspunkt vurderer vi vanligvis Multisite fra rundt 20 lokasjoner – men det tallet er underordnet spørsmålet om hvordan nettverket driftes.
| Scenario | Anbefalt arkitektur |
|---|---|
| Sentralt styrt innhold, uansett antall lokasjoner | Én installasjon + lokasjons-CPT |
| Redaktører per lokasjon, uavhengige oppsett | WordPress Multisite |
| Flere franchisemerker, felles WordPress-motor | WordPress Multisite |
Dette må hver lokasjonsside inneholde
I franchiseprosjektene våre bygger vi hver lokasjonsside rundt fem lokasjonsspesifikke innholdselementer. Googles retningslinjer for inngangssider advarer mot «mange like sider, der hver er litt endret for en annen by» – målet er sider som er reelt nyttige for en besøkende på akkurat det stedet, ikke maler med byttet bynavn.
De fem signalene som gjør en lokasjonsside reelt unik: en lokasjonsspesifikk overskrift som viser til nærområdet (ikke bare et innsatt bynavn), fullstendige NAP-data (navn, adresse, telefonnummer), et innebygd Google-kart, en unik tjenestebeskrivelse med lokal kontekst – kjente steder i nærheten, dekningsområde, referanser til lokale kunder – og anmeldelser hentet spesifikt fra lokasjonens Google-bedriftsprofil.
Små formateringsforskjeller som «Suite» og «Ste.» betyr sjelden noe – Google er flink til å normalisere adresser. Fokuser heller på at de faktiske bedriftsopplysningene er riktige på nettstedet og i GBP: bedriftsnavn, besøksadresse, telefonnummer, nettstedets URL og åpningstider. Det er dette Google bruker for å vurdere relevans og bygge den lokale entiteten.
Å bygge inn Google Maps uten å svekke Core Web Vitals krever utsatt lasting av iframe-en. Last den først når brukeren ruller kartet inn i visningen, ikke ved første sideinnlasting. Et franchisenettsted med 30 lokasjonssider der hver laster et fullt Google-kart med en gang, vil stryke på LCP over hele linja.
Å hente inn lokasjonsspesifikke anmeldelser dynamisk krever en tilkobling til Google Business Profile-API-et eller en tjeneste som samler anmeldelser. Anmeldelsene på hver lokasjonsside bør komme fra GBP-oppføringen til akkurat den lokasjonen, ikke fra en generell feed fra hovedkontoret.
Merkevarestyring: slik styrer hovedkontoret malen uten å låse franchisetakerne
Den ryddigste styringsmodellen låser global topptekst, bunntekst, typografi og fargepalett på temanivå i WordPress, og gir franchisetakerne et ACF-basert redigeringsgrensesnitt med forhåndsdefinerte feltgrupper. Franchisetakerne redigerer innhold, ikke struktur. De har ikke tilgang til hele blokkbiblioteket i Gutenberg-redigeringsverktøyet, og de kan ikke røre temaet.
Dette er en teknisk beslutning, ikke en retningslinje. Du løser ikke merkevareglidning med en stilguide i PDF. Du løser den ved å bygge en publiseringsløsning der feil valg ikke er tilgjengelig.
Roller og rettigheter i WordPress gir finmasket kontroll. En redaktørrolle for franchisetakere kan settes opp med tilgang bare til bestemte innholdstyper (sin egen lokasjonsside), bare til bestemte ACF-feltgrupper og ingen tilgang til tematilpasning, innstillinger for utvidelser eller andre lokasjoners innhold. Med WordPress-filteret map_meta_cap kan du utvide dette til så detaljert nivå du vil, hvis standardrollene ikke er nok.
Synkronisering av merkevareelementer på tvers av lokasjoner skjer på temanivå. Fargetokener, typografidefinisjoner og logofiler ligger i temaets konfigurasjon, ikke i innstillingene for hver lokasjonsside. Når hovedkontoret endrer den primære merkevarefargen, endres den overalt samtidig. Franchisetakerne får ikke noe felt for å overstyre den.
Når en franchisetaker likevel bryter merkevarestandardene – laster opp et bilde som ikke passer merkevaren, eller overskriver en overskrift med reklamespråk som strider mot hovedkontorets budskap – er gjenopprettingsrutinen avgjørende. Revisjonssystemet i WordPress dekker innleggsinnhold; for ACF-felt innførte ACF 6.8.1 et datalager som knytter feltverdier til WordPress-revisjoner, slik at redaktører kan se og gjenopprette tidligere feltverdier i det innebygde Revisjoner-skjermbildet. For detaljert logging av hvem som gjorde hva, legg til en egen utvidelse for aktivitetslogg. Finn bruddet, gå tilbake til siste godkjente versjon og forklar franchisetakeren hva som er riktig innhold.
I prosjekter der designlaget trenger full oppmerksomhet ved siden av den tekniske arkitekturen, dekker arbeidet vårt med UI/UX-design for WordPress både definisjonen av designsystemet og implementeringen fra Figma til WordPress for franchisekunder.
For franchisegrupper som ikke vil bygge denne infrastrukturen fra bunnen av, tilbyr IMADO Location Engine en produksjonsklar WordPress-arkitektur for nettsteder med flere lokasjoner. Den samler lokasjonsdata som åpningstider, priser, arrangementer, kampanjer og bookinginformasjon sentralt og gir hvert utsalgssted kontrollert tilgang til sitt eget innhold. Nye lokasjoner lanseres fra en utprøvd mal der lokale sider, strukturerte data, navigasjon, tillatelser og integrasjoner allerede er bygd inn i plattformen – slik at et nettverk kan vokse uten å bygge den samme funksjonaliteten på nytt for hvert nye utsalgssted.
Implementering av lokal SEO: schema, GBP og internlenking
Hver lokasjonsside trenger LocalBusiness-schema med riktig adresse, åpningstider, telefonnummer og geografiske koordinater. Strukturerte data av typen LocalBusiness gir Google eksplisitt, maskinlesbar informasjon om hver fysiske lokasjon og kan støtte aktuelle lokale søkefunksjoner. På franchisenettsteder er de gjennomgående for dårlig implementert.
Schemaet bør implementeres som JSON-LD og settes inn i <head> på hver lokasjonsside. WordPress legger ikke til LocalBusiness-schema som standard – RankMath og Yoast SEO støtter det gjennom sine moduler for lokal SEO, eller du kan implementere det med en egen utvidelse som leser feltdataene på lokasjonssiden. @type bør settes til den mest spesifikke undertypen som passer: LocalBusiness, FoodEstablishment, AutoRepair, LegalService osv. Mer spesifikke typer gir bedre gjenkjenning av entiteten.
Hver lokasjonsside bør ha en selvrefererende canonical-tag som peker til sin egen URL – vanlig praksis for å unngå problemer med duplisert innhold hvis siden en gang blir tilgjengelig via flere stier. I tillegg setter du feltet Nettsted i hver lokasjons Google-bedriftsprofil til URL-en for den tilhørende lokasjonssiden. Det er slik Google knytter GBP-oppføringen til nettstedet ditt, ikke gjennom canonical-taggen. Googles dokumentasjon om strukturerte data for LocalBusiness beskriver de påkrevde og anbefalte egenskapene. Googles dokumenterte lokale rangeringsfaktorer er fortsatt relevans, avstand og fremtredenhet – LocalBusiness-schema gir ikke et direkte rangeringsløft, men gir Google strukturert informasjon og kan gjøre siden aktuell for flere lokale søkefunksjoner.
Internlenking fra rotdomenet til lokasjonssidene sender autoritet nedover i hierarkiet. Oversiktssiden for lokasjoner (domain.com/locations/) bør lenke til hver enkelt lokasjonsside. Kategorisider (domain.com/locations/new-york/) bør lenke til undersider på bynivå hvis nettverket er stort nok til å forsvare den dybden. Hovednavigasjonen på rotdomenet bør ha en lenke «Finn en lokasjon» som peker til oversiktssiden. Dette er grunnleggende, men mangler på mange franchisenettsteder.
Kannibalisering av søkeord mellom lokasjonssider er en reell risiko. Hvis du sikter mot «rørleggertjenester Chicago» på Chicago-siden og et blogginnlegg sikter mot samme frase, konkurrerer de. Løsningen er en tydelig fordeling: lokasjonssidene eier lokale transaksjonelle søkeord, og blogginnholdet sikter mot informasjonssøkeord. Ikke skriv et blogginnlegg med tittelen «De beste rørleggertjenestene i Chicago» hvis du har en lokasjonsside for Chicago.
Ytelse i stor skala: CDN og caching for mer enn 50 lokasjonssider
WordPress håndterer tusenvis av lokasjonsinnlegg uten ytelsesproblemer når spørringene er riktig bygd og indeksert. Ytelsesutfordringen på franchisenettsteder er ikke antall lokasjoner – det er kompleksiteten i spørringene og trafikkmengden.
CDN-caching og en objektcache for WordPress (Redis eller Memcached) blir viktig når du har: mye trafikk til enkelte lokasjonssider, krevende geo- eller radiusspørringer i et lokasjonssøk, kall til tredjeparts-API-er per lokasjon (anmeldelsesfeeder, lager, tilgjengelighet) eller dynamisk innhold som varierer med brukerens posisjon. Googles undersøkelse av mobilhastighet fant at 53 % av mobilbrukerne forlater nettsteder som bruker mer enn 3 sekunder på å laste – lokasjonssider med uoptimaliserte kart og anmeldelseswidgeter er ofte de tregeste sidene på et franchisenettsted. Legg til disse cachelagene når belastningen tilsier det.
Helsidecaching av lokasjonssider kompliseres av dynamisk innhold. Sider som viser anmeldelser i sanntid, gjeldende åpningstider eller lagerstatus i sanntid, kan ikke caches fullt ut på edge uten å bli utdaterte. Riktig tilnærming er å cache det statiske skallet på hver lokasjonsside i CDN-et og laste det dynamiske innholdet (anmeldelser, åpningstider) med JavaScript etter første gjengivelse. Slik holdes Largest Contentful Paint rask, samtidig som innholdet er oppdatert der det betyr noe.
Vår tjeneste for hastighetsoptimalisering av WordPress tar seg nettopp av dette laget: CDN-konfigurasjon, Redis-objektcache, spørringsoptimalisering for WordPress-nettsteder med mange lokasjoner og måling av Core Web Vitals per lokasjon i stedet for bare forsiden.
Mål for Core Web Vitals på lokasjonssider: LCP under 2,5 sekunder, CLS under 0,1, INP under 200 millisekunder. Innebygde kart er den vanligste årsaken til LCP- og CLS-problemer på lokasjonssider. Last dem utsatt. Lever lokasjonsbilder i WebP-format med eksplisitte dimensjoner for å unngå at oppsettet forskyver seg.
Overvåk ytelsen per lokasjon, ikke bare forsiden. En franchisekjede med 40 lokasjonssider der tre av dem stadig stryker på Core Web Vitals, har et problem du ikke finner ved å sjekke forsiden. Bruk Core Web Vitals-rapporten i Google Search Console filtrert på URL-mønster, eller sett opp planlagte Lighthouse-kjøringer mot et utvalg lokasjonssider.
Analysesporing per lokasjon i GA4
Google Analytics 4 støtter segmentering på lokasjonsnivå via egendefinerte dimensjoner. Implementeringen krever at hver lokasjonsside merkes med en location_id-parameter i GA4-konfigurasjonen, og deretter at du bygger utforskingsrapporter som bryter ned trafikk, engasjementsrate og konverteringshendelser per lokasjon.
Opprett en egendefinert dimensjon kalt location_id i GA4 med omfanget «hendelse». Send parameteren via gtag-konfigurasjonen eller via Google Tag Manager med en variabel som leser lokasjons-ID-en fra sidens URL eller fra et push til datalaget. Når dimensjonen har fått verdier, kan du segmentere enhver standardrapport i GA4 etter lokasjon.
Målsporing per lokasjon bør minst dekke: innsendte skjemaer (kontakt- eller tilbudsforespørsler), klikk på telefonnummeret og klikk på «Veibeskrivelse» i det innebygde Google-kartet. Hver av disse bør spores som en konverteringshendelse i GA4, med location_id-dimensjonen knyttet til. Slik får hovedkontoret et tydelig bilde av hvilke lokasjoner som konverterer, og hvilke som trenger oppfølging.
I Search Console setter du opp én GSC-eiendom for rotdomenet og bruker sidefilteret i resultatrapporten til å segmentere etter lokasjonenes URL-mønster (/locations/). Du trenger ikke separate GSC-eiendommer per lokasjon med mindre du bruker separate domener. Eiendommen for rotdomenet fanger automatisk opp data for alle underkataloger.
Vanlige spørsmål
Bør en franchisekjede bruke WordPress Multisite eller separate installasjoner for hver lokasjon?
Valget avhenger av behovet for driftsmessig atskillelse, ikke av antall lokasjoner. Én installasjon holder for de fleste franchisenettverk, også store. Multisite gir mening når lokasjonene trenger egne administratorer eller uavhengige utvidelsesoppsett, eller når du driver flere separate franchisemerker fra én WordPress-motor. Som et grovt utgangspunkt vurderer vi vanligvis Multisite fra rundt 20 lokasjoner – men antall lokasjoner alene bør ikke avgjøre valget.
Hva er den beste URL-strukturen for et franchisenettsted?
Underkataloger er standardanbefalingen for franchisenettsteder. Strukturen domene.no/locations/bynavn/ samler domeneautoriteten under én rot, er enklere for sentrale team å styre og unngår den oppsplittingen av SEO-verdi som underdomener gir.
Hvordan holder franchisenettsteder merkevaren konsekvent på alle lokasjoner?
Merkevarekonsistens håndheves i publiseringsløsningen, ikke gjennom retningslinjedokumenter. Lås globale designelementer (topptekst, bunntekst, fonter, farger) i WordPress-temaet, og gi franchisetakerne tilgang bare til forhåndsdefinerte ACF-feltgrupper for innholdet på sin lokasjonsside. Da er endringer som bryter med retningslinjene ikke bare frarådet, men rett og slett ikke mulige.
Hvilken schema-markering bør et franchisenettsted bruke for hver lokasjon?
Bruk LocalBusiness-schema (eller den mest spesifikke undertypen som passer) implementert som JSON-LD i <head> på hver lokasjonsside. Ta med adresse, telefonnummer, åpningstider, geografiske koordinater og URL-en til selve lokasjonssiden (f.eks. example.com/locations/chicago/). Egenskapen url i LocalBusiness-schema bør peke til nettsiden, ikke til URL-en for Google Maps eller GBP-oppføringen.
Hvordan unngår du at lokasjonssider blir flagget som duplisert innhold?
Hver lokasjonsside trenger minst fem unike innholdssignaler: en lokasjonsspesifikk overskrift, en beskrivelse av de lokale tjenestene, NAP-data, et innebygd Google-kart for adressen og anmeldelser fra lokasjonens GBP-oppføring. Tynne sider som bare bytter ut bynavnet i en felles mal, risikerer Googles straff for inngangssider (doorway pages).
Oppsummering
Nettsteddesign for franchisekjeder med flere lokasjoner er først og fremst en arkitekturbeslutning, ikke en designbeslutning. Få URL-strukturen riktig først (underkataloger), velg deretter mellom én installasjon og Multisite ut fra antall lokasjoner og hvem som styrer innholdet, og bygg så lokasjonssider som er reelt unike i stedet for å bytte ut bynavnet. Merkevarestyring, lokal SEO og ytelse i stor skala følger av disse grunnleggende valgene.
IMADOs tjenester for WordPress-utvikling dekker hele denne stakken: arkitekturavklaring, Multisite-oppsett, ACF-baserte redaksjonelle grensesnitt, implementering av LocalBusiness-schema, CDN-konfigurasjon og GA4-sporing per lokasjon. Vi bygger franchiseplattformer for nettverk med alt fra 5 til over 100 lokasjoner.
Snakk med WordPress-utviklerne våre for franchisekjeder for å avklare omfanget av prosjektet ditt.
