De flesta råd om hur man installerar WordPress Multisite börjar på fel ställe. De inleds wp-config.php, berättar var du ska klistra in en konstant och behandlar nätverket som en teknisk uppgradering.
Det är tvärtom.
Multisite är ett arkitektoniskt val. Det kan förenkla styrning, publicering och plattformsunderhåll. Det kan dock också binda samman webbplatser som inte har något med varandra att göra till en enda driftsmodell, en enda distributionsväg och ett enda felområde. Installationen tar bara några minuter. Att leva med beslutet tar däremot flera år.
Table of Contents
Det är viktigt eftersom WordPress i sig används i enorm skala. WordPress ligger till grund för 43,5 % av alla webbplatser världen över, och i mars 2025 fanns det cirka 1,19 miljarder webbplatser online, vilket är anledningen till att Multisite fortfarande är relevant för företag som driver flerspråkiga, flerdomän- eller flerplatsbaserade webbplatsnätverk på det dominerande CMS:et (Pantheons sammanställning av WordPress-statistik). Funktionen är fullt utvecklad. Den större frågan är om din organisation är det.
När man ska använda WordPress Multisite och när man ska undvika det
Team väljer ofta Multisite när de egentligen behöver bättre styrning, inte en gemensam arkitektur. Det är två olika problem.
Använd Multisite när du behöver driva många webbplatser inom en och samma kontrollerad plattform. Det passar vanligtvis franchisekedjor, universitet, byråer, publicistnätverk och företagsgrupper med återkommande webbplatsmönster, gemensamma krav på inloggning, gemensamma designsystem och centraliserad övervakning av plugins. WordPress Multisite är utvecklat för just den typen av skala. Ett nätverk kan vara värd för flera webbplatser från en enda installation, och vissa organisationer driver ”hundratals eller till och med tusentals” webbplatser i ett enda nätverk (Fellowship om WordPress Multisite).
Undvik det när webbplatserna bara ser likadana ut i en presentationsbild. Om affärsenheterna behöver separata lanseringsscheman, olika plugin-uppsättningar, självständiga beslut om webbhotell, strikt juridisk åtskillnad eller friheten att avvika från ett gemensamt temasystem, blir Multisite ett hinder.
Tecken på bra passform
- Centraliserad styrning är viktigt: Ett plattformsteam måste hantera teman, tillägg och användarpolicyer på flera webbplatser.
- Bebyggelsemönstren upprepas: Nya byggnader är varianter av en godkänd ritning, inte skräddarsydda konstruktioner.
- Gemensam drift är en fördel: Säkerhet, underhåll och redaktionella riktlinjer bör hanteras centralt.
- En expansion förväntas: Företag som planerar regionala lanseringar eller skapar skalbara mikrosajter har ofta nytta av en repeterbar nätverksmodell.
Signaler på dålig passform
- Varje webbplats fungerar som en egen produkt: Separata utvecklingsplaner och anpassade integrationer kräver oftast separata installationer.
- Plugin-autonomi är avgörande: Multisite begränsar friheten redan från början.
- Organisationen är politiskt decentraliserad: Teknisk centralisering klarar sällan av kaoset i styrningen.
- Dataseparering är ett absolut krav: Separata installationer är ofta enklare både ur drifts- och avtalsmässig synvinkel.
Praktisk regel: Om ditt team prioriterar delad kontroll framför delad bekvämlighet kan Multisite vara ett lämpligt val. Om de vill ha delad bekvämlighet men förväntar sig lokala undantag överallt, är det oftast inte det rätta valet.
För företagsteam som behöver hjälp från erfarna experter för att väga för- och nackdelarna innan de sätter igång med utvecklingen är WordPress-lösningar för företag ofta mer användbara än ännu en checklista för installation.
De kritiska beslutsunderdomänerna kontra underkatalogerna
Det första bestående valet i en Multisite-installation är inte koden. Det är URL-strukturen.
De flesta handledningar hoppar över detta, trots att valet kan leda till långvariga migrationsproblem om man väljer fel. WordPress egna utbildningsmaterial lämnar en lucka här. Man visar teamen hur man aktiverar nätverket, men inte hur man bedömer om valet mellan en permanent underdomän eller en underkatalog passar deras verksamhetsmodell (lektion om installation av WordPress.org Multisite).
Vad förändras med varje struktur
| Struktur | Bättre när | Det brukar vara svårare när |
|---|---|---|
| Underdomäner | Webbplatserna behöver tydligare avgränsning, olika publiceringsfrekvenser eller så småningom egna domäner | DNS, SSL-planering och konfiguration av miljön |
| Underkataloger | Webbplatserna ska representera ett gemensamt varumärke och ge intryck av att vara delar av en sammanhängande helhet | Framtida uppdelningar, domänförändringar och vissa migrationsmönster |
Undermappar gör att allt hålls samlat under ett gemensamt varumärke. Det ger ofta en överskådligare struktur för ett centralt marknadsföringsteam. Det minskar också behovet av tidig DNS-samordning och brukar göra den första lanseringen enklare.
Underdomäner skapar tydligare gränser. De är ofta det säkraste valet för företagsnätverk där varje region, avdelning eller affärsområde numera behöver en egen identitet, även om allt styrs centralt bakom kulisserna.
SEO och konsekvenser för varumärket
Det här valet är aldrig enbart av teknisk karaktär.
Underkataloger är oftast ett bra val när den överordnade domänen är varumärket och varje webbplats finns till för att stärka just det varumärket. Landsavdelningar, innehållshubbar för affärsenheter eller kampanjområden kan fungera bra i den här modellen om styrningen är strikt och användarupplevelsen är enhetlig. Team som planerar webbplatsstrukturen på den här nivån bör också granska hur navigering och URL-utformning påverkar synligheten i den här guiden om URL:ers SEO-potential i webbplatsnavigering.
Underdomäner är ett bättre val när varje webbplats ska uppfattas som relativt självständig. Ett franchisenätverk, ett partnerprogram eller en regionalt självständig verksamhet drar ofta nytta av denna åtskillnad. Det ger dig tydligare strukturer för domänmappning i framtiden och färre besvärliga kompromisser när webbplatserna utvecklas.
Välj underkataloger när nätverket består av ett varumärke med många avdelningar. Välj underdomäner när det handlar om en plattform med många identiteter.
Konsekvenser för verksamheten som teamen underskattar
Underdomäner medför mer arbete med infrastrukturen. Du måste noga överväga hur jokertecken fungerar, SSL-täckningen och hur nya webbplatser ska hanteras innan redaktörerna ens börjar använda kontrollpanelen.
Underkataloger verkar enklare i början, men de kan bli kostsamma om en webbplats senare behöver flyttas till en egen domän eller tas bort från nätverket. Det är den dolda kostnaden som de flesta snabbstartsguider bortser från.
Ett bra test är följande: fråga dig om någon webbplats under de närmaste åren kan komma att behöva ett eget varumärke, en egen domän eller en delvis självständig styrning. Om svaret är ja är underdomäner oftast det säkraste valet att börja med. Om svaret är nej och företaget vill ha en helt enhetlig webbplats, håller underkataloger ofta bättre över tid.
Förbereda din webbhotell- och DNS-miljö
En multisite-implementering misslyckas långt innan WordPress misslyckas. Den misslyckas på grund av problem med DNS, certifikatplanering, felaktiga antaganden om cachelagring och dåliga val av webbhotell.
Om det här nätverket är avsett för produktion, bör du betrakta hostinglagret som en del av applikationsdesignen. Se inte på det som en teknisk detalj som du tar itu med senare.
Vad produktionsberedskap egentligen innebär
För ett seriöst nätverk måste miljön stödja repeterbar konfiguration, kontrollerade driftsättningar och förutsägbart routningsbeteende. Det innebär att ditt infrastrukturteam och ditt WordPress-team bör enas om hur domäner, certifikat, omdirigeringar, cache-lager och testmiljöer ska fungera innan nätverket tas i drift.
Bristfällig planering leder ofta till att många projekt spårar ur. Utvecklare kan installera WordPress Multisite på rätt sätt, men om DNS-poster, certifikatens täckning och hur omvänd proxy fungerar aldrig har planerats, blir den första lanseringen av en live-domän en ändlös kedja av supportärenden.
Checklista inför installationen
- Välj en webbhotellleverantör som har praktisk erfarenhet av WordPress: Generisk delad hosting är en olämplig grund för ett nätverk som ska stödja flera varumärken eller marknader.
- Planera för jokertecken redan i ett tidigt skede: Om du använder underdomäner måste infrastrukturen stödja hur nya webbplatser ska omdirigeras.
- Fastställ ansvaret för SSL: Bestäm om certifikaten ska hanteras av värden, plattformsteamet eller ett externt driftsteam.
- Kontrollera att omskrivningarna är kompatibla: Reglerna för Apache eller Nginx måste stämma överens med hur WordPress dirigerar nätverkssidor.
- Skillnad mellan testmiljö och produktionsförväntningar: Ett testnätverk bör efterlikna domän- och cachebeteendet tillräckligt noggrant för att upptäcka problem vid lanseringen innan de når användarna.
Scenografi är inte valfritt
En staging-miljö för flera webbplatser är inte bara till för att testa kod. Det är där du validerar hela processen, från skapandet av webbplatsen till domäntilldelningen och den säkra lanseringen. Utan det blir din första riktiga lansering ett testfall.
Team som ännu inte har fastställt detta bör åtminstone följa en tydlig process för staging-miljön, så att antaganden om DNS, SSL-konfiguration och driftsättningsordning testas under kontrollerade förhållanden.
Om ditt webbhotellsteam säger ”vi kan ordna domänkopplingen efter installationen”, så pausa projektet. Det är just när man gör infrastrukturjusteringar efter installationen som välplanerade Multisite-projekt börjar bli röriga.
Vad man bör bestämma sig för innan man börjar använda WordPress
| Område | Beslut om nedstängning |
|---|---|
| Domäner | Vilka webbplatser kommer att använda nätverks-URL:er först, och vilka kommer att lanseras på mappade domäner? |
| Intyg | Hur SSL-certifikat utfärdas, förnyas och valideras i nätverket |
| Cachelagring | Om cache-reglerna är gemensamma eller isolerade per webbplats |
| Miljöer | Hur staging, förproduktion och produktion hanterar mappade domäner |
| Stödmodell | Vem ansvarar för ändringar i DNS, lanseringsfönster och beslut om återställning? |
En stabil Multisite-installation är mindre beroende av define() linjen än vad man ofta tror. Det svåra är att göra miljön tillräckligt förutsägbar så att varje ny webbplatslansering följer samma driftsmönster.
Aktivera och konfigurera WordPress-nätverket
Själva installationen är enkel. Det är ordningsföljden som är viktig.
En WordPress Multisite-installation sker i två steg. Först aktiverar du funktionen genom att lägga till define('WP_ALLOW_MULTISITE', true); till wp-config.php. Använd sedan Verktyg → Nätverksinställningar för att välja nätverksstruktur och generera den slutliga koden som krävs för både wp-config.php och .htaccess (installationsguide för MultilingualPress).
Börja med en säkerhetskopia och en ren administratörssession. Inaktivera plugins innan du aktiverar nätverket. Det minskar störningar under installationen och undviker felsökning av plugin-beteenden som inte har något med Multisite i sig att göra.
Fas ett: aktivera funktionen
Redigera wp-config.php och lägg till:
define('WP_ALLOW_MULTISITE', true);
Placera det ovanför raden som lyder /* That's all, stop editing! */.
Den raden skapar inte nätverket i sig. Den visar skärmen för nätverksinställningar i WordPress-admin så att applikationen kan generera resten av konfigurationen baserat på den struktur du valt.
Steg två: skapa nätverkskonfigurationen
I adminområdet går du till Verktyg → Nätverksinställningar.
Välj underdomäner eller underkataloger, ange nätverkets titel och administratörsuppgifter och låt WordPress generera de nödvändiga kodsnuttarna. Du får ett block för wp-config.php och ett annat för .htaccess.
De genererade reglerna är inte bara till för syns skull. De talar om för WordPress hur man ska känna igen nätverksförfrågningar, vidarebefordra dem korrekt och hantera den omskrivna URL-strukturen som nätverket är beroende av.
Här är arbetsflödet som fungerar pålitligt:
- Gör först en säkerhetskopia: filer och databas.
- Inaktivera plugins: Särskilt sådana som har med omdirigeringar, säkerhet eller sidcachelagring att göra.
- Lägg till Multisite-konstanten: Spara
wp-config.php. - Kör nätverkskonfigurationen: Välj den URL-modell du redan har bestämt dig för.
- Klistra in den genererade koden noggrant: Placera varje block i rätt fil.
- Logga in igen: WordPress uppdaterar behörigheterna och visar det nya nätverksgränssnittet.
En videoguide kan vara till hjälp om du vill jämföra din sekvens med ett visuellt installationsflöde:
Vanliga misstag under installationen
- Att lämna plugins aktiva: Detta skapar ofta falska larm vid den första inloggningen efter konverteringen.
- Att klistra in koden på fel ställe:
wp-config.phpoch.htaccessutför olika uppgifter. Blanda inte ihop dem. - Att ignorera befintliga omskrivningsregler: Om webbplatsen redan hade anpassat serverbeteende, slå ihop dem noggrant istället för att blint skriva över dem.
- Att betrakta uppdateringen vid inloggningen som ett fel: Omaktivering efter installationen är förväntat.
Vad den genererade koden gör
De tillagda wp-config.php värdena att webbplatsen nu är ett nätverk och definierar hur nätverket ska fungera. .htaccess reglerna hanterar URL-omskrivning så att förfrågningar når rätt webbplats inom nätverket.
Du behöver inte memorera varje direktiv, men du måste respektera ordningen och filgränserna. De flesta misslyckade installationerna beror på att någon kopierade rätt kodsnutt till fel plats eller genererade strukturen innan beslutet om infrastrukturen hade fattats.
Att bemästra nätverksadministratörens kontrollpanel
Redan första dagen efter installationen visar det sig om nätverket kommer att förbli välorganiserat.
En superadministratör loggar in, öppnar Mina webbplatser och ser en ny kontrollpanel. Det är vid den punkten som Multisite slutar vara en installationsövning och börjar bli en driftsmodell.
Prioriteringar dag ett
Det första uppdraget är inte att bygga fler webbplatser. Det är att definiera vad webbplatsadministratörerna får göra.
Skapa den initiala webbplatsstrukturen. Lägg till en eller två representativa webbplatser, inte tjugo. Installera endast de teman och plugins som nätverket är förberett för att stödja. Bestäm vilka plugins som ska aktiveras på nätverksnivå och vilka som ska vara tillgängliga för aktivering på den lokala webbplatsen. Om du hoppar över det här styrningssteget kommer redaktörer och klientadministratörer att börja behandla nätverket som en vanlig WordPress-installation med en enda webbplats, och du kommer att tillbringa nästa månad med att reda ut undantag som hade kunnat undvikas.
En strukturerad sekvens för den första dagen ser ut så här:
- Skapa grundläggande webbplatser: Huvudvarumärket, en regional webbplats, en testwebbplats.
- Begränsa plugin-katalogen: Installera endast det som nätverket har kommit överens om att stödja.
- Ställ in användarroller med eftertanke: Separera superadministratörsbehörigheter från webbplatsadministratörsbehörigheter omedelbart.
- Granska registreringsinställningarna: Lämna inte öppna vägar för skapande av webbplatser eller användare om det inte är avsiktligt.
Dashboarden förändrar hur ansvaret fungerar
I en standardinstallation kan varje webbplatsadministratör känna sig suverän. I Multisite är den suveräniteten delvis.
Nätverksadministratören ansvarar för installation av plugins, tillgänglighet av teman och övergripande användarpolicy. Webbplatsadministratörer hanterar innehåll, menyer, widgets och lokal konfiguration inom ramen för de behörigheter de har tilldelats. Denna uppdelning är sund när den är dokumenterad. Den blir kaotisk när den tas för given.
Ett stabilt Multisite-nätverk har färre friheter än en lös samling av enskilda webbplatser. Det är en funktion, inte en brist.
Ett praktiskt styrningsmönster
En användbar modell är att behandla nätverket som en plattformsprodukt:
| Roll | Äger |
|---|---|
| Superadministratör | Kärnuppdateringar, teman, plugin-förteckning, nätverksinställningar |
| Webbplatsadministratör | Innehåll, media, menyer, aktivering av lokala tillägg om detta är tillåtet |
| Plattformsansvarig | Standarder, godkännanden inför lansering, policy för produktlansering |
| Redaktionella ledare | Taxonomier, arbetsflöden, innehållskvalitet |
Denna struktur hjälper byråer och företagsteam att undvika det vanligaste misstaget när det gäller kontrollpaneler. De installerar Multisite för att uppnå centralisering, men beviljar sedan behörigheter som återigen leder till fragmentering.
En annan vana som är värd att behålla redan från början är att följa namngivningsregler. Webbplats-slugs, ansvar för administratörs-e-postadresser, miljöetiketter och domänplaner bör alla följa ett fast mönster. Om så inte är fallet blir det svårt att granska och ge support även för ett tekniskt välfungerande nätverk.
Domänmappning av SSL och publicering av webbplatser
I det här skedet är de flesta installationsguiderna inte längre till någon nytta.
Det är enkelt att aktivera nätverket. Det som verkligen spelar roll är att lansera riktiga webbplatser på riktiga domäner utan felaktiga omdirigeringar, certifikatproblem, cacheförvirring eller skador på SEO. För byråer och företagsteam är den största utmaningen inte bara att aktivera Multisite. Det handlar om att på ett säkert sätt driftsätta det på olika marknader och domäner, inklusive DNS, SSL, cacheisolering och migreringsplanering (Pagely om drift av WordPress Multisite).
Domänmappning är en lanseringsprocess, inte en kryssruta
När nätverket väl är på plats måste varje live-webbplats fortfarande hantera sina egna domäninställningar. I praktiken innebär det att domänen måste peka på rätt miljö, att den mappade webbplatsen måste tilldelas korrekt inom nätverket och att SSL måste vara giltigt innan lanseringen.
Det låter enkelt tills flera team blir inblandade. Marknadsavdelningen ansvarar för varumärkesdomänen. IT-avdelningen ansvarar för DNS. Värdleverantören tillhandahåller certifikat. WordPress-teamet uppdaterar webbplatsinställningarna. Om dessa steg inte genomförs i rätt ordning kan lanseringsdagen snabbt bli en mardröm.
En återkommande startordning
Skapa webbplatsen i Network Admin
. Bygg först upp webbplatsen med en tillfällig nätverks-URL. Kontrollera tema, plugins och innehållsstruktur innan du kopplar in den riktiga domänen.Förbered den anpassade domänen
. Domänen ska vara redo att peka på den miljö där nätverket är hostat. Planera inte in några tidsfönster för innehållsfrysning förrän ägarförhållandena är klarlagda.Tilldela den mappade domänen till webbplatsen
. I nätverket kopplar du den avsedda domänen till rätt webbplats. Kontrollera noga att du inte mappar fel domän till en underwebbplats med liknande namn.Konfigurera SSL före den offentliga lanseringen
. En kopplad domän utan giltigt HTTPS-certifikat är inte redo för lansering. Certifikatets status bör kontrolleras innan omdirigeringarna aktiveras.Testa utanför den förväntade funktionsvägen
. Kontrollera frontend, administratörsinloggning, medie-URL:er, kanoniska länkar, formuläråtgärder och eventuella hårdkodade referenser som fortfarande pekar på den tillfälliga nätverks-URL:en.
Fel vid domänmappning beror sällan på WordPress i sig. De beror på att teamen ändrar DNS-, SSL- och applikationsinställningarna i fel ordning.
Flytta en befintlig fristående webbplats till nätverket
Det här är den del som ofta underskattas. En fristående webbplats har redan en historik. Den har indexerbara URL:er, omdirigeringsmönster, förutsättningar för plugins, hårdkodade resurser och ett driftsätt som är utformat för att fungera som en fristående enhet.
Innan migreringen bör du avgöra om webbplatsen flyttas in i nätverket av styrningsskäl eller enbart av praktiska skäl. Om det enbart handlar om praktiska skäl bör du behålla den separat. Att flytta en etablerad webbplats till Multisite medför beroenden vad gäller URL:er, domäner och drift som bör motiveras.
En praktisk checklista för migrering:
- Granskning av innehåll och media: Kontrollera att strukturen och referenserna bevaras vid import.
- Granskning av tillägg: Vissa tillägg fungerar annorlunda i Multisite eller kräver hantering på nätverksnivå.
- Omdirigeringsplan: Bevara gamla stigar där det är viktigt.
- Granskning av ”Sök och ersätt”: Upptäck problem med miljö-URL:er, mediereferenser och serialiserade data.
- Definition av återställning: Se till att du vet vad ”avbryta och återställa” innebär innan du kopplar om den aktiva trafiken.
SSL och cacheisolering kräver uttryckligt ägarskap
Det blir svårare att hantera SSL-certifikat när nätverket innehåller många domäner med olika lanseringstidpunkter. Någon måste ansvara för utfärdandet av certifikat, översikten över förnyelser och valideringen. Om ingen utses till ansvarig blir projektledaren oavsiktligt certifikatkoordinator.
Cacheisolering är också viktigt. En webbplats cachelogik bör inte orsaka oväntat beteende hos en annan webbplats med andra cookies, lokaliseringsregler eller inloggningsmönster. Om värden eller cachelagringslagret hanterar nätverket på ett alltför generellt sätt kan felsökning på en marknad påverka en annan.
Checklistan inför lanseringen som sparar tid
| Kontrollera | Vad man ska kontrollera |
|---|---|
| Domänupplösning | Den kartlagda domänen når den avsedda miljön |
| HTTPS | Certifikatet är giltigt och inga problem med blandat innehåll uppstår |
| Administratörsbehörighet | Redaktörer kan logga in via rätt domänväg |
| Omdirigeringar | Äldre URL:er och önskade kanoniska länkar fungerar som förväntat |
| Tillgångar | Media, skript och formulär laddas från rätt domän |
De smidigaste lanseringarna av Multisite sker när domänmappningen hanteras som en kontrollerad lanseringsprocess, inte som en inställning som man bara slår på i sista stund.
Prestanda, säkerhet och skalbarhet i ditt nätverk
Det svåra med Multisite börjar efter installationen.
Ett nätverk förändrar driftsmodellen för WordPress. Prestandaproblem är inte längre lokala. Säkerhetsbeslut är inte längre webbplatsspecifika. Varje undantag som du beviljar för ett varumärke, en region eller en kund innebär extra arbete för det team som ansvarar för resten av nätverket.
Driftsstörningar begränsas sällan till ett enda område
Ett plugin som inte fungerar som det ska, ett resurskrävande sökmönster eller en massimport kan försämra administratörsgränssnittets prestanda på flera webbplatser. På en ren informationswebbplats är det bara ett irritationsmoment. Men i ett nätverk med aktiva redaktörer, kampanjtrafik och schemalagd publicering blir det en driftsstörning.
Planera för delad infrastruktur redan från början. Det innebär vanligtvis permanent objektcaching, noggrant utformade regler för sidcache, kontrollerat cron-beteende och övervakning av sökfrågor i testmiljön innan något aktiveras i nätverket. Det innebär också att man måste vara realistisk när det gäller kostnaderna för plugins. Ett plugin som fungerar bra på en enskild webbplats kan bli för kostsamt när det används på dussintals webbplatser och hanterar tusentals förfrågningar.
En skalbar arkitektur som fungerar i produktionsmiljön omfattar vanligtvis följande:
- Centralt godkännande av tillägg: Behandla varje tillägg som ett plattformsberoende med konsekvenser för support, uppdateringar och återställning.
- Webbplatsanpassade cache-regler: Tar hänsyn till cookies, inloggningsstatus, språkvarianter och domänspecifikt beteende.
- Styrning av bakgrundsprocesser: Köa eller begränsa import, synkroniseringsuppgifter och sökindexering så att en arbetsbelastning inte tar all resurskapacitet från de övriga.
- Ett avgränsat tema och en enhetlig standard: Färre stödda mönster gör att testning, lanseringar och hantering av incidenter går snabbare.
- Databasunderhåll: Alternativ som laddas automatiskt, övergivna tabeller och alltför stora loggfiler blir med tiden en belastning för hela nätverket.
Säkerhet börjar med utformningen av behörigheter
Säkerheten i multisite-miljöer äventyras oftast av bristfällig styrning innan den äventyras av en avancerad attack. Superadministratörsbehörighet är den uppenbara risken, men en slapp rollutformning skapar lika många problem. Redaktörer får behörigheter som de inte borde ha. Webbplatsadministratörer installerar tillfälliga lösningar som strider mot riktlinjerna. Byråer överlämnar ett nätverk utan en tydlig behörighetsmodell, och sex månader senare kan ingen förklara vem som får göra vad.
Fastställ gränserna redan från början. Begränsa superadministratörsbehörigheten till den lilla grupp som ansvarar för plattformsändringar. Bestäm vilka teman och plugins som överhuvudtaget ska vara tillgängliga. Granska reglerna för filuppladdning, registreringsbeteende, API-exponering och all anpassad kod som överskrider webbplatsgränserna. Loggning är också viktigt. Om nätverket inte kan svara på vem som ändrade en inställning, aktiverade ett plugin eller skapade en webbplats, saktar incidenthanteringen snabbt ner.
Säkerhetsverktygen måste också anpassas till arkitekturen. Flödesbegränsning, skanning efter skadlig kod, WAF-regler och revisionsloggning bör konfigureras med hänsyn till domänmappning och ägarskap över flera webbplatser, och inte läggas till i efterhand som om det vore en enkel installation.
Säkerhetskopior är endast användbara om återställningen överensstämmer med nätverksmodellen
Många team hävdar att de har reservlösningar, när det i själva verket bara handlar om att kryssa i en ruta hos leverantören utan att ha någon testad återställningsprocess.
En miljö med flera webbplatser kräver en mer ingående diskussion. Går det att återställa en webbplats utan att det påverkar de andra? Går det att återställa media, tabeller och inställningar för mappade domäner för en enskild webbplats efter en misslyckad driftsättning? Hur lång tid tar en fullständig nätverksåterställning, och vem godkänner den när flera affärsenheter delar samma teknikstack?
Team som ansvarar för att hantera WordPress-webbplatser i flera olika miljöer brukar upptäcka att återställningsprocessen är viktigare än hur säkerhetskopiorna ser ut. Skriv ner återställningsprocedurerna. Testa dem. Se till att ha olika lösningar för ett innehållsfel på en enskild webbplats jämfört med ett fel som drabbar hela nätverket.
Skalbarhet handlar lika mycket om återhållsamhet som om infrastruktur
Hälsosamma nätverk växer inte genom att man säger ja till varje undantag. De växer genom att man håller variationerna under kontroll.
Använd en lanseringsprocess där gemensamma komponenter testas innan de tas i drift. Gå igenom inaktiva webbplatser och arkivera de som inte längre fyller någon affärsfunktion. Håll koll på vilka anpassningar som medför långsiktiga supportkostnader. Om en webbplats kräver ovanliga tillägg, särskilda värdtjänstlösningar eller redaktionella arbetsflöden, bör du överväga om den överhuvudtaget hör hemma i nätverket.
De mest effektiva Multisite-miljöerna har några gemensamma drag:
- Strikt ändringskontroll för inställningar på nätverksnivå
- Ett litet urval av pålitliga tillägg
- Dokumenterat ägarskap för domäner, SSL, cachelagring och DNS
- Tydliga rutiner för introduktion och avslutning av anställning vid anläggningarna
- Regelbundna granskningar av inaktiva tillgångar, föråldrad kod och utvidgning av behörigheter
Multisite kan fungera som en plattform för stora företag eller organisationer. Det kan dock också innebära att riskerna koncentreras till en enda kodbas, ett enda databaslager och en enda styrningsmodell. Team som lyckas med detta behandlar nätverket som en produkt med standarder, ansvariga och operativ disciplin.
Oavsett om du funderar på om Multisite är rätt arkitektur för dig eller om du behöver hjälp med att omvandla ett befintligt nätverk till en stabil driftsplattform, erbjuder IMADO stöd för WordPress-lösningar som kräver avancerad teknisk expertis inom Multisite, flerspråkig implementering, styrning, migreringsplanering och löpande underhåll.
