En gemensam WordPress-installation kan sänka kostnaden för uppdateringar och förvaltning av flera webbplatser. Fel arkitektur kan samtidigt koppla ihop driftrisker, behörigheter och framtida leverantörsbyten.
Säg att ett företag har sex varumärkes- och marknadssajter som ska publicera samma kampanjbudskap under en och samma vecka. I det hypotetiska exemplet kan WordPress Multisite göra ändringen enkel: ett gemensamt block uppdateras centralt och återanvänds på flera sajter. Men om en av sajterna samtidigt behöver ett eget betalflöde, en annan driftpartner och en tredje ska förberedas för försäljning förändras kalkylen. Den administrativa genvägen riskerar då att bli ett tekniskt beroende som kostar både tid och handlingsfrihet.
Det är den verkliga beslutsfrågan för en ägare eller marknadschef som använder WordPress för flera webbplatser. Antalet sajter säger mindre än hur väl de kan dela kod, releaseplan, integrationer och tekniskt ägarskap. Multisite minskar administrationen när organisationen accepterar en gemensam teknisk livscykel. Separata installationer blir ofta enklare när varje sajt behöver kunna förändras, flyttas eller driftsättas utan hänsyn till de andra.
Så här hade vi angripit valet: börja med de beslut som sajterna förväntas dela under de kommande åren, inte med hur lika startsidorna ser ut just nu. Två sajter kan ha nästan identisk design men helt olika affärslogik. Omvänt kan två visuellt skilda varumärken fungera utmärkt i samma nätverk när de bygger på samma komponenter, samma integrationsmönster och samma förvaltning.
WordPress Multisite lönar sig när sajterna faktiskt kan dela tekniska beslut
Ett Multisite-nätverk består i grunden av en WordPress-installation som hanterar flera undersajter. Teman och pluginfiler delas normalt i samma kodbas, medan varje undersajt har egna tabeller för exempelvis inlägg, sidor och inställningar. Gemensam kod innebär alltså inte automatiskt gemensamt innehåll. Marknadsteamen kan publicera var för sig även om utveckling och uppdateringar sköts centralt.
Den skillnaden förklarar varför Multisite kan ge en tydlig förvaltningsvinst. Ett gemensamt blocktema kan innehålla sidmallar, knappar, formulärkomponenter och kampanjsektioner som används av hela organisationen. En förbättring av en komponent behöver då göras på ett ställe i stället för att kopieras mellan separata WordPress-sajter. Samma resonemang gäller säkerhetsuppdateringar, teknisk kvalitetssäkring och återkommande releasearbete.
Men nyttan uppstår bara om sajterna kan acceptera samma grundbeslut. Om ett varumärke vill ligga kvar på en äldre version av ett centralt plugin medan ett annat behöver den senaste versionen för en ny integration finns ingen naturlig versionsgräns mellan dem. Pluginpaketet ligger fortfarande i den delade installationen. Även om tillägget bara är aktiverat på vissa undersajter kan en koduppdatering därför förändra förutsättningarna för alla sajter som använder det.
Ytlig likhet räcker inte heller som beslutsunderlag. Föreställ er två marknadssajter med samma logotypplacering och samma sidtyper. Den ena skickar enbart kontaktformulär till ett gemensamt CRM, medan den andra har inloggning, lokala produktdata och ett marknadsspecifikt bokningssystem. Designen kan delas, men releasebehovet och felrisken skiljer sig. Om den lokala sajten måste kunna driftsätta en kritisk integrationsändring samma dag som övriga nätverket har releasefrysning blir den gemensamma plattformen en broms.
Ett hållbart Multisite-upplägg behandlar därför lokala skillnader som konfiguration när det är möjligt. Logotyp, färgtema, typografi, tillåtna block och kontaktuppgifter kan styras med dokumenterade variationer ovanpå ett gemensamt tema. Kopierade specialteman ser ofta flexibla ut i början, men skapar snart flera kodgrenar som ska testas och underhållas. Då återkommer dubbelarbetet inne i nätverket, samtidigt som sajterna behåller Multisites gemensamma riskyta.
Tabellen nedan visar hur vi brukar skilja verklig standardisering från beroenden som talar för separata installationer. Den är ett beslutsstöd, inte en automatisk poängmodell.
| Beslutsområde | Talar för Multisite | Talar för separata installationer |
|---|---|---|
| Tema och komponenter | Sajterna kan använda samma bastema, block och tillgängliga variationer. | Varje sajt kräver återkommande kodavvikelser eller en egen teknisk arkitektur. |
| Releaseprocess | Alla sajter kan följa gemensamma test- och releasefönster. | Lokala team måste kunna driftsätta oberoende och med olika prioritet. |
| Pluginpolicy | Behoven ryms inom en kontrollerad och kompatibel uppsättning tillägg. | Ett varumärke behöver egna versioner, specialtillägg eller snabbare uppgraderingar. |
| Integrationer | CRM, formulär, identitet och sökfunktion följer samma integrationsmönster. | Marknaderna har olika datakällor, autentisering eller externa releasekrav. |
| Tekniskt ägarskap | En gemensam funktion ansvarar för budget, prioritering och drift. | Sajterna har olika ägare, leverantörer eller sannolika framtida köpare. |
Det första vi tittar på är alltså inte hur många domäner som ska samlas, utan om organisationen kan formulera en gemensam teknisk policy. Om svaret är ”ja, utom för nästan varje marknad” är standardiseringen sannolikt mer teoretisk än verklig.
Gemensam plattform betyder inte att redaktörerna måste få gemensam kontroll
En vanlig invändning mot WordPress Multisite är att alla redaktörer skulle hamna i samma administrativa miljö och därmed kunna påverka andra varumärken. Så behöver lösningen inte utformas. Nätverksadministratören hanterar den övergripande installationen, medan lokala administratörer och redaktörer kan begränsas till den egna undersajten. Ett konto kan dessutom ha olika roller på olika sajter.
Nätverksadministrationen bör reserveras för ett litet och tydligt utpekat tekniskt ansvar. Där hanteras bland annat installation av teman och pluginer samt inställningar som påverkar hela nätverket. Lokala administratörer bör i stället arbeta med den egna sajtens användare, menyer, innehåll och de funktioner som centralt har gjorts tillgängliga. Marknadsredaktörer kan få en ännu snävare roll med fokus på innehåll och publicering.
Rollfördelningen är inte bara en säkerhetsfråga. Den skyddar också den gemensamma förvaltningsmodellen från tillfälliga lokala lösningar. Om varje marknad kan installera egna tillägg försvinner snabbt möjligheten att förutse konflikter, licensbehov och kommande uppdateringsarbete. Samtidigt får de centrala begränsningarna inte göra normala innehållsändringar beroende av en utvecklare. En kampanjsida, menyjustering eller formulärtext ska kunna hanteras där verksamhetskunskapen finns.
Följande behörighetsmatris är ett illustrativt exempel. De exakta rollerna behöver anpassas efter organisationens ansvar, men matrisen gör en avgörande sak synlig: vem som får besluta, vem som får utföra och vem som bara arbetar med innehållet.
| Uppgift | Central IT | Varumärkesansvarig | Marknadsredaktör | Extern byrå |
|---|---|---|---|---|
| Koduppdatering | Godkänner och driftsätter | Informeras och accepterar verksamhetspåverkan | Ingen åtkomst | Utvecklar via avtalad kodprocess |
| Pluginaktivering | Granskar och tillgängliggör | Begär för den egna sajten | Ingen åtkomst | Rekommenderar vid dokumenterat behov |
| Användarhantering | Hanterar nätverksadministratörer | Godkänner lokala roller | Ingen eller begränsad åtkomst | Endast egna namngivna konton |
| Publicering | Ingen normal redaktionell roll | Äger publiceringsflödet | Skapar och publicerar enligt roll | Publicerar endast om uppdraget kräver det |
| Menyer och formulär | Styr tekniska ramar | Godkänner struktur och mottagare | Redigerar tillåtna delar | Bygger integration efter beställning |
Delade mallar fungerar bäst när lokala avvikelser har namn och regler. Ett varumärke kan exempelvis välja mellan godkända färgteman, egna logotyper och en definierad uppsättning block utan att få en kopia av hela temat. Det gör skillnaderna begripliga för både redaktörer och utvecklare. När nästa centrala designförändring kommer går det att se vilka variationer som ska testas, i stället för att leta efter dolda ändringar i flera temakopior.
Användarlivscykeln förtjänar samma tydlighet. Eftersom användarkonton normalt delas på nätverksnivå behöver introduktion, rollbyte och avslut hanteras centralt nog för att ingen ska behålla bredare åtkomst än uppdraget kräver. För verksamheten betyder det färre oklara behörigheter och mindre tid på att reda ut vem som ändrade vad. För externa byråer skapar det dessutom en tydlig gräns mellan åtkomst till ett varumärke och kontroll över hela plattformen.
Drift och integrationer avgör nätverkets verkliga risknivå
Central drift är ett av de starkaste argumenten för Multisite. Kod kan versionshanteras i Git, testas i en gemensam stagingmiljö och driftsättas enligt en sammanhållen process. Säkerhetsuppdateringar behöver inte planeras separat för varje installation. Den administrativa besparingen är reell när sajterna verkligen kan följa samma takt.
Samma egenskap skapar nätverkets största tekniska risk: ett fel i delad temakod eller ett nätverksaktiverat plugin kan få större räckvidd. En felaktig formulärkomponent kan påverka flera varumärkens kontaktvägar, och en kodändring som bryter sidrenderingen kan störa flera domäner samtidigt. Affärskonsekvensen blir då större än ett isolerat webbplatsfel, eftersom flera kampanjer, kundresor eller marknader kan påverkas under samma incident.
Antalet sajter är därför ett dåligt mått på risk. Ett mindre nätverk med tätt kopplade affärskritiska integrationer kan kräva mer omsorg än ett större nätverk med enkla informationssajter. Det relevanta är hur många gemensamma felpunkter som finns, hur snabbt de kan upptäckas och om en förändring kan aktiveras stegvis. En gemensam kodbas behöver inte betyda att varje ny funktion slås på överallt samtidigt; sajtspecifika konfigurationsval eller funktionsväxlar kan begränsa införandet medan lösningen verifieras.
Domänhanteringen är ett konkret exempel. Undersajter kan använda egna domäner, men DNS, certifikat, CDN och cache måste förstå vilket värdnamn som hör till vilken sajt. CDN är tjänsten som levererar filer nära besökaren; en felaktig konfiguration kan därför ge en besökare gammalt innehåll eller innehåll avsett för fel domän. Cachelagret behöver vara Multisite-anpassat och skilja på sajter, språk, inloggade användare och andra relevanta variationer.
Autentisering kräver en liknande genomgång. Om flera marknadssajter använder samma identitetsleverantör kan en gemensam integration vara rationell. Men om en marknad behöver en unik returadress efter inloggning, en egen användarkatalog eller en separat releaseprocess kan den gemensamma lösningen bli svår att testa. En callback-adress är helt enkelt den adress en extern tjänst skickar användaren tillbaka till. Om den är felaktig kan kunden inte slutföra inloggningen eller betalningen, vilket gör en till synes teknisk detalj direkt affärskritisk.
Identiska leverantörsnamn betyder inte heller identiska integrationer. Två sajter kan båda använda samma CRM men ha olika API-nycklar, fältmodeller, webhookar och ansvariga team. En webhook är ett automatiskt meddelande från en tjänst till en annan; om mottagaren eller datat skiljer sig mellan marknaderna måste varje flöde kunna testas och felsökas separat. Därför bör integrationsinventeringen beskriva API-nycklar, datalagring, webhookadresser, språk, ansvarig ägare, felsökningsväg och behov av separat driftsättning för varje sajt.
Sökfunktionen är ytterligare en möjlig skiljelinje. Ett gemensamt sökindex kan vara effektivt om innehållet ska kunna hittas över flera varumärken. Om marknaderna däremot har olika sortiment, språkregler eller publiceringskrav behövs ofta separata index och tydliga filter. Annars kan avpublicerat eller marknadsspecifikt innehåll dyka upp på fel plats. För kunden ser det ut som en dålig sökupplevelse; bakom problemet finns ofta en otillräckligt isolerad datamodell.
Stagingmiljön måste spegla de beroenden som faktiskt kan gå sönder. Det räcker inte att öppna startsidan och konstatera att temat laddas. Teamet behöver prova formulär, inloggning, sökresultat, språkväxling, cache, schemalagd publicering och de pluginer som bara används på vissa undersajter. En representativ testuppsättning är mer värdefull än att mekaniskt klicka igenom varje sida, eftersom den fångar variationerna i teknik och affärsflöden.
Återställningsplanen bör dessutom skilja mellan tre situationer: återställning av en fil, återställning av en undersajts data och återställning av hela nätverket. Alla backuplösningar som fungerar för en vanlig WordPress-installation hanterar inte en enskild undersajt på ett säkert och smidigt sätt. När sajternas tabeller och användare delar nätverksstruktur kan en ogenomtänkt databasåterställning skriva över nyare innehåll på andra sajter. Därför behöver driftpartnern kunna beskriva både hur backupen tas och hur en avgränsad återställning genomförs.
Separata installationer minskar räckvidden för vissa fel, men de tar inte bort driftansvaret. Flera fristående sajter kan i stället få olika pluginversioner, ojämna säkerhetsrutiner och uppdateringar som glöms bort. Valet står alltså inte mellan risk och ingen risk. Det står mellan en centraliserad risk som kräver stark testning och isolering, och en distribuerad risk som kräver konsekvent förvaltning på flera platser.
Planera avknoppningen innan en sajt behöver säljas eller byta ägare
När nackdelarna med WordPress Multisite diskuteras hamnar fokus ofta på pluginstöd eller drift. Den långsiktigt dyraste frågan kan i stället vara hur en undersajt lämnar nätverket. Ett varumärke kan säljas, en marknad kan få en annan teknisk ägare eller organisationen kan vilja byta leverantör för bara en del av webbportföljen. Om separationen aldrig har planerats blir varje delat beroende en förhandlings- och migrationsfråga.
WordPress inbyggda export kan flytta mycket innehåll, men en fullständig avknoppning omfattar mer än sidor och inlägg. Uppladdade filer behöver kopieras med rätt sökvägar, interna länkar behöver justeras och domänen behöver pekas om utan att gamla adresser går förlorade. Inställningar, formulärkonfiguration, metadata och vissa pluginrelaterade data kan ligga i databastabeller som kräver en särskild migreringsmetod.
Användare är ett särskilt område eftersom kontona normalt finns gemensamt i nätverket medan rollerna kopplas till respektive undersajt. Vid en avknoppning måste organisationen avgöra vilka konton som ska följa med, hur de ska återskapas och vem som tar ansvar för dem efter flytten. Delade administratörskonton bör inte bara kopieras till den nya installationen av bekvämlighet, eftersom åtkomst och ägarskap då riskerar att bli otydliga.
Koden behöver också få en ny ägare. Om undersajten använder ett centralt bastema måste den avknoppade sajten få en fungerande och förvaltningsbar version av temat, tillsammans med dokumentation om byggprocess och beroenden. Pluginlicenser, typsnitt, analysverktyg och externa tjänsteavtal kan vara tecknade för hela nätverket och går inte alltid att behandla som om de tillhör den enskilda sajten. Frågan är därför inte bara om sajten tekniskt kan exporteras, utan om den kan drivas vidare utan löpande tillgång till den tidigare organisationens kod och konton.
En praktisk avknoppningsplan anger vad som händer med databas, media, användare, domän, tema, pluginer, analys, sökindex och externa integrationer. Den beskriver även hur omdirigeringar ska bevaras och hur man kontrollerar att formulär och andra affärsflöden fungerar efter flytten. Planen behöver inte innebära att en separation är nära förestående. Den fungerar som en dokumentation av vilka beroenden organisationen faktiskt har accepterat.
Så här hade vi prioriterat kostnadsfrågan: jämför inte bara dagens antal uppdateringar med kostnaden för flera installationer. Lägg även in värdet av oberoende releasebeslut, leverantörsbyte och framtida ägarförändringar. En billigare central förvaltning kan vara rätt val, men bara när organisationen medvetet accepterar kostnaden för en eventuell separation.
Separata WordPress-sajter är ofta mindre riskfyllda när olika juridiska eller kommersiella ägare ska kunna fatta egna tekniska beslut, när driftkraven skiljer sig tydligt eller när en överlåtelse är sannolik. Det betyder inte att all kod måste utvecklas flera gånger. Ett gemensamt tema eller komponentpaket kan versionshanteras och distribueras till flera fristående installationer. Skillnaden är att varje sajt själv väljer när den tar emot nästa version.
En hybrid är ofta bättre än ett enda beslut för hela webbportföljen
Organisationer hamnar lätt i ett falskt val mellan ett enda stort Multisite-nätverk och helt fristående sajter. I praktiken kan en hybrid ge bättre balans. En grupp marknadssajter som delar tema, CRM och förvaltning kan ligga i samma nätverk, medan en webbshop med eget betalflöde får en separat installation. Ett varumärke som sannolikt ska säljas kan också hållas utanför från början, även om designen liknar övriga sajter.
Grupperingen bör följa tekniskt ägarskap och förändringstakt snarare än organisationsschemat. Två marknader inom samma affärsområde kan behöva separeras om deras integrationer och releasefönster är helt olika. Samtidigt kan flera självständiga varumärken samsas i ett nätverk om de förvaltas av samma team och accepterar samma pluginpolicy. Det är beroendemönstret, inte varumärkesstrukturen, som avgör.
En hybrid kräver fortfarande disciplin. Om ett gemensamt komponentpaket används både i Multisite och på separata installationer behöver versioner, kompatibilitet och dokumentation hanteras tydligt. Vinsten är att organisationen kan återanvända design och kod utan att göra alla sajter beroende av samma databas, driftmiljö eller releaseögonblick.
Fallgropen vi brukar leta efter är en hybrid som har uppstått av en slump: några sajter ligger i nätverket, andra hos olika leverantörer och ingen vet vilka delar som är gemensamma. En medveten hybrid har däremot uttalade skäl för varje placering och en gemensam förvaltningsöversikt. Då går det att se vilka sajter som kan flyttas tillsammans, vilka som ska uppdateras separat och var affärskritiska beroenden finns.
De kriterier som avgör om WordPress Multisite passar
Bedöm inte Multisite utifrån hur många sajter ni har, utan utifrån hur mycket de faktiskt kan dela utan att skapa oönskade beroenden. Följande kriterier hjälper er väga samordningsvinster mot risker för drift, redaktionellt ansvar och framtida ägarförändringar.
Verifiera att sajterna kan dela tekniska beslut
Multisite ger störst nytta när sajterna kan använda samma grundarkitektur, versionsplan, säkerhetsrutiner och en gemensam uppsättning teman eller tillägg. Granska verkliga behov från kommande kampanjer, integrationer och produktplaner i stället för att utgå från dagens visuella likhet. Om varje varumärke eller marknad regelbundet kräver egna tekniska undantag blir nätverket lätt en kö där alla måste vänta på varandras beslut. Ett väl avgränsat konfigurationsval är hanterbart, medan egna kodversioner snabbt urholkar centraliseringens värde.
Signal: Kontrollera att ni kan formulera vilka komponenter som ska vara gemensamma, vem som äger dem och vilka undantag som faktiskt behöver tillåtas.
Separera plattformens styrning från redaktörernas behörigheter
En gemensam installation behöver inte innebära att redaktörer får åtkomst till andra varumärkens innehåll eller inställningar. Roller, publiceringsflöden och nätverksadministration bör utformas så att varje team kan arbeta självständigt inom tydliga gränser. Centrala tekniska beslut ska skyddas utan att vardaglig publicering fastnar hos IT eller en extern byrå. Den balansen minskar både risken för oavsiktliga ändringar och kostnaden för onödiga supportärenden.
Signal: En bra lösning visar konkret vem som får administrera nätverket, respektive sajt, användare, tillägg och publicering.
Kartlägg gemensamma felpunkter i drift och integrationer
Delad kodbas, databas, driftsmiljö och centrala integrationer kan göra underhållet enklare, men kan också ge ett enskilt fel större räckvidd. Bedöm därför isolering, övervakning, testmiljöer, återställning och hur externa integrationer hanteras per sajt. Be om konkreta beskrivningar av hur en pluginuppdatering provas, hur en funktion aktiveras stegvis och hur en enskild undersajt återställs. Centralisering utan en plan för felbegränsning flyttar bara administrationen till incidenthanteringen.
Signal: Varna om leverantören bara beskriver centraliseringens effektivitet men inte hur fel begränsas, upptäcks och återställs.
Kräv en realistisk plan för avknoppning
En sajt kan senare behöva säljas, flyttas till en annan leverantör eller få en separat teknisk ägare. Planera därför från början hur innehåll, media, användare, domäner, konfiguration och sajtspecifika integrationer kan exporteras utan onödiga beroenden till resten av nätverket. Planen bör även visa vem som äger tema, licenser och externa konton efter separationen. När processen går att beskriva innan den behövs blir både plattformsvalet och en framtida affär mindre riskfyllda.
Signal: Kontrollera att det finns en dokumenterad och testbar process för att flytta ut en enskild sajt utan att påverka övriga sajter.
Säkerställ att förvaltningsmodellen klarar lokala behov
Multisite kräver tydliga beslut om vem som prioriterar uppdateringar, godkänner tillägg och hanterar konflikter mellan centrala krav och lokala önskemål. Om ansvar, budget och beslutsvägar är oklara riskerar den gemensamma plattformen att samla teknisk skuld och organisatoriska låsningar. Lokala undantag behöver ha en ägare, en motivering och en tidpunkt för omprövning. Annars kan ett tillfälligt kampanjbehov bli ett permanent specialfall som alla framtida releaser måste ta hänsyn till.
Signal: En bra förvaltningsmodell anger vem som beslutar, vem som utför och hur lokala undantag bedöms över tid.
Börja här: inför WordPress Multisite i rätt ordning
-
Kartlägg sajterna och fatta ett tydligt Multisite-beslut
Samla domäner, språk, redaktörer, integrationer, teman och pluginberoenden i Google Sheets. Komplettera uppgifterna med WordPress Webbplatshälsa och WP-CLI, som ger ett kontrollerat sätt att inventera installationer, versioner och konfiguration via kommandorad. Lägg till teknisk ägare, driftpartner, releasefrekvens och sannolik framtida avknoppning för varje sajt. Resultatet ska vara ett dokumenterat beslut där sajter som kan dela teknisk plattform och förvaltning grupperas, medan installationer med tydligt avvikande ägarskap, säkerhetsbehov eller releaseplan hålls separata.
-
Fastställ styrning för nätverk, varumärken och behörigheter
Rita upp nätverket i Miro eller Lucidchart och markera vilka teman, pluginer, användarroller, domäner och integrationer som ska hanteras centralt respektive lokalt. Dokumentera ansvar och publiceringsflöden i Confluence eller Notion, inklusive hur ett lokalt team begär ett nytt plugin och vem som bedömer följderna för resten av nätverket. Beskriv även hur externa byråer får åtkomst och hur den tas bort när uppdraget slutar. Målet är att nätverksadministratörer och marknadsteam ska veta vad de får ändra utan att behöva tolka plattformens gränser vid varje release.
-
Bygg en stagingmiljö med gemensam designgrund
Sätt upp WordPress Multisite i en stagingmiljö och versionshantera ett gemensamt bastema eller blocktema i GitHub eller GitLab. Använd globala stilar, återanvändbara blockmönster och varumärkesspecifika variationer för logotyp, färg och tillåtna komponenter. Stagingmiljön ska innehålla de tekniska variationer som finns i den planerade portföljen, inte bara en ren demonstrationssajt. Prova därför både en enkel marknadssajt och de undersajter som har språkfunktioner, formulär, sök eller andra avvikande beroenden innan arkitekturen låses.
-
Migrera en representativ pilotsajt före resten
Välj en sajt som innehåller de vanligaste innehållstyperna och integrationerna, men undvik att börja med den enklaste sajten om den inte representerar resten. Migrera innehåll med WordPress inbyggda export och import där det passar, och använd WP-CLI för kontrollerade ändringar av URL:er och databasvärden. Kontrollera formulär, omdirigeringar, språk, redaktörsroller, metadata, schemalagd publicering och indexeringsinställningar. Dokumentera varje manuellt steg och sätt stoppkriterier för fel som måste lösas innan fler sajter flyttas; piloten ska förbättra metoden, inte bara bevisa att en enskild startsida går att öppna.
-
Inför central drift, övervakning och återställning
Hantera kod och uppdateringar via Git och WP-CLI så att förändringar går att granska, testa och återupprepa. Övervaka varje domän separat med UptimeRobot och följ respektive webbplats i Google Search Console, eftersom en fungerande nätverksinstallation inte garanterar att varje marknadssajt är nåbar eller korrekt indexerad. Välj en backupplattform som uttryckligen stöder WordPress Multisite och genomför dokumenterade återställningstester för både en undersajt och hela nätverket. Komplettera med tydliga vägar för återställning av kod, databas och media, så att teamet kan agera metodiskt när ett fel berör en sajt eller flera.
När piloten är godkänd kan återstående sajter flyttas i planerade etapper med samma arbetsordning och tydliga stoppkriterier. Målet är inte bara färre installationer, utan en WordPress Multisite-plattform som gör lanseringar, varumärkesstyrning och löpande förvaltning enklare utan att skapa onödiga framtida låsningar; en erfaren partner angriper därför uppdraget som ett beslut om styrning, drift och ägarskap, inte enbart som en teknisk installation.
