Migrering av WordPress Multisite: komplett handbok för 2026

Du befinner dig förmodligen i en av två situationer just nu. Antingen har ett multisite-nätverk vuxit ur servern, styrningsmodellen eller URL-strukturen det började med, eller så har någon på affärssidan bestämt att en undersajt ska bli en egen plattform utan att synligheten i sök, de redaktionella arbetsflödena och intäkterna går sönder.

Det är här migrering av WordPress Multisite slutar vara en rutinmässig hostinguppgift och blir ett utvecklingsprojekt. Själva den tekniska flytten är viktig, men de största riskerna ligger oftast någon annanstans: en pluginlicens som inte längre valideras efter utbrytningen, en flerspråkig uppsättning som tappar sina canonical-taggar, ett mediebibliotek som ser bra ut tills redaktörerna upptäcker trasiga filer tre dagar senare, eller en återställningsplan som bara finns som ett vagt löfte.

De renaste migreringarna jag har sett följer alla samma mönster. De behandlar databasflytten som en del av en större, kontrollerad förändring. De låser omfattningen tidigt, testar som utredare och utgår från att något kommer att fallera så länge det inte är verifierat. Det är det tankesättet som hindrar att en multisite-migrering blir en incident sent på kvällen.

Strategi före migreringen och riskbedömning

Fredag kl. 20:40. DNS ska snart växlas, databasimporten är klar och någon frågar om hreflang-taggarna på den franska undersajten bevarades, och vilka licenser för premium-plugins som kommer att överleva flytten. Om den frågan dyker upp på migreringskvällen har planeringen misslyckats.

En migrering av WordPress Multisite börjar med kontroll över omfattningen och planering för fel. Databasen och filerna är viktiga, men högriskprojekt fallerar oftast på frågor om affärskontinuitet: pluginlicenser kopplade till den gamla domänen eller installationstypen, regler för flerspråkig SEO som försvinner efter utbrytningen och återställningsplaner som låter bra tills någon under press måste bestämma om DNS ska vändas tillbaka.

Behandla planen som en runbook för incidenter. Innan någon rör produktion bör den besvara fyra saker:

1. Vad som flyttas, exakt
2. Vad som måste vara tillgängligt hela tiden
3. Vad som utlöser en återställning
4. Vem som har mandat att godkänna lanseringen eller backa den

Definiera migreringens omfattning innan du väljer verktyg

”Flytta multisiten” är inte en användbar omfattning. I praktiken är beställningen ofta rörigare: bryt ut en intäktsgenererande undersajt till en fristående WordPress-installation, lämna kvar två äldre undersajter, behåll de mappade domänerna, se till att redaktörerna kan arbeta på måndagsmorgonen och undvik att tappa placeringar på tre språk.

Skriv ner inventeringen först.

• Varje undersajt: nuvarande URL, mappad domän, affärsansvarig och tolerans för driftstopp
• Aktiveringsmodell: nätverksaktiverade plugins kontra plugins på sajtnivå
• Egen kod: mu-plugins, drop-ins, egna tabeller, cron-jobb, webhooks och åsidosättningar i temat
• Delade beroenden: mediereferenser, API-integrationer, SSO, formulär, sök och analysskript

Om ingen kan säga vilka undersajter som får vara nere, och hur länge, är migreringen inte redo.

Det är också här teamen bestämmer om arbetet ska göras internt eller om de ska ta in en specialist på migreringstjänster för WordPress. Avvägningen är enkel. Interna team känner teknikstacken. Externa aktörer har ofta med sig en renare runbook, bättre disciplin kring återställning och färre antaganden.

Granska felpunkterna som gör ont efter lanseringen

Export och import av databasen är den enkla delen. De kostsamma felen dyker upp senare, när sajten ser ”i stort sett bra” ut.

Pluginlicenser är ett vanligt exempel. Premium-plugins kan validera licensen utifrån primärdomän, nätverkskontext, antal sajter eller miljö. En undersajt som har brutits ut ur en multisite kan starta korrekt och ändå förlora åtkomst till uppdateringar, fältrendering, översättningsfunktioner eller kassaintegrationer eftersom licensen inte längre matchar den nya installationen. Kontrollera leverantörernas villkor före flytten, inte efter.

Flerspråkig SEO förtjänar lika mycket uppmärksamhet. Om nätverket använder WPML, Polylang, egen hreflang-utdata, marknadsspecifika canonical-taggar eller översatta slugs måste du dokumentera hur det fungerar i dag. Det omfattar title-taggar, canonical-taggar, hreflang-taggar, XML-webbplatskartor, omdirigeringsregler och språkbaserade mallar. En sajt kan klara den visuella kvalitetssäkringen och ändå tappa sökvärde eftersom metadatalagret ändrades utan att någon märkte det.

Media är en annan fälla. I en multisite klistrar redaktörer ofta in fil-URL:er mellan undersajter, använder anpassade fält som pekar på gamla uppladdningssökvägar eller förlitar sig på plugins som skriver om mediehanteringen. Trasiga miniatyrbilder är irriterande. Trasiga dokument, kampanjmaterial och lokaliserade PDF:er skapar supportärenden snabbt.

Bygg en risklogg som du faktiskt kan använda

Håll den så kort att migreringsansvarig läser den under övergången.

Sätt objektiva utlösare för återställning

En återställning ska inte bero på självförtroende, humör eller vem som pratar högst i samtalet. Sätt mätbara utlösare före lanseringen.

Exempel:

• Administratörsåtkomsten fungerar inte för de viktigaste sajtägarna
• Kassan, leadformulär eller inloggningsflöden fallerar
• Domänmappningen skickar trafik till fel undersajt
• Kritisk flerspråkig metadata saknas på produktionssidor
• Pluginlicenser inaktiverar nödvändiga funktioner
• Felfrekvensen skjuter i höjden och kan inte åtgärdas inom underhållsfönstret

Skriv ner tröskeln och få den godkänd av migreringsansvarig, produktägare och den person som kontrollerar DNS. Jag rekommenderar också att du skriver ner de exakta kommandona och åtgärderna för återställning, inte bara beslutsregeln. I verkliga incidenter slår tydlighet optimism.

Om återställningen till exempel omfattar att återställa den gamla databasen och tvinga tillbaka DNS, skriv ner ordningsföljden:

# Example rollback checks
wp site list
wp plugin list --network
wp search-replace 'https://new.example.com' 'https://old.example.com' --network --dry-run

Använd testkörningar (dry runs) under planeringen för att bekräfta att teamet har den åtkomst det tror att det har. På migreringskvällen kan saknade WP-CLI-behörigheter eller fel SSH-nyckel äta upp tiden du behövde för återställningen.

Bra multisite-migreringar är kontrollerade förändringar. De team som tar sig rent igenom dem bestämmer omfattningen tidigt, dokumenterar dolda beroenden, testar hur licenser och SEO beter sig före övergången och definierar återställningen som om de räknar med att använda den.

Förbereda miljöerna och DNS

De flesta misslyckade migreringar börjar med en skillnad mellan den gamla miljön och den nya. Inte en dramatisk skillnad. En tyst. Ett PHP-plugin som saknas på målservern, ett problem med filbehörigheter i uploads, en lucka i omskrivningsreglerna eller DNS-ändringar som skjuts upp till sista timmen.

Den nya miljön ska vara tråkig. Det är målet. Om målet beter sig annorlunda än källan på sätt som du inte har räknat med kommer migreringen att blotta skillnaderna i form av avbrutna sessioner, medieproblem eller fel i plugins.

Bygg målet så att det matchar källan

Börja med en ren WordPress-installation på målet och förbered den för multisite innan du importerar något. Om du flyttar till ett nytt nätverk, skapa samma strukturmönster som du redan använder. Byt inte från underkataloger till underdomäner i samma migrering om det inte finns ett tungt vägande skäl och ett separat testspår.

I det här skedet bör du bekräfta:

• PHP-kompatibilitet: Använd de versioner som stöds och som det nuvarande temat och dina plugins kräver.
• Databasåtkomst: Testa CLI-åtkomst, importbehörigheter och hur tabeller skapas.
• Ägarskap i filsystemet: Se till att WordPress kan skriva till rätt kataloger utan provisoriska lösningar för behörigheter.
• Shell-åtkomst: Bekräfta SSH- och WP-CLI-åtkomst före migreringsdagen.
• E-post och externa tjänster: Förbered det som nätverket behöver för formulär, transaktionsflöden eller webhooks.

För team som flyttar infrastruktur som en del av ett leverantörsbyte är det här en praktisk guide om att flytta en WordPress-webbplats till en ny leverantör blir relevant, eftersom leverantörsbytet och multisite-flytten ofta överlappar driftmässigt även när dataflödet är ett annat.

Förbered DNS både för lansering och reträtt

DNS-planering får för lite uppmärksamhet i de flesta migreringsguider. Det borde den få. Du vill att den slutliga övergången ska gå snabbt, men du vill också att reträtten ska gå snabbt om valideringen i produktion misslyckas.

Den viktigaste vanan är att sänka TTL-värdena i god tid före migreringsfönstret. Det ger en renare övergång och en realistisk möjlighet till återställning. Om du väntar för länge med DNS-förberedelserna kan du fortfarande migrera, men återställningsfönstret blir svårare att kontrollera.

Använd den här checklistan före övergången:

• Sänk TTL tidigt: Gör det i god tid före lanseringen, inte under den.
• Dokumentera mappade domäner: Särskilt för multisite-nätverk med domäner för varumärken, språk eller kunder.
• Bekräfta SSL-täckningen: Underdomäner och mappade domäner måste lösas upp korrekt efter övergången.
• Förbered verifieringsvärdar i förväg: Använd icke-publika valideringsmetoder för att testa routningen innan du flyttar produktionstrafiken.

Hoppa inte över en ren installation

Många team vill kopiera hela den gamla installationen först och ”städa upp senare”. Det drar oftast med sig gamla antaganden in i den nya miljön. En färsk installation på målet ger dig en känd utgångspunkt och gör det lättare att isolera fel.

Om flytten innebär att en fristående sajt görs om till en undersajt, eller att ett nätverk först skapas på målet, måste förberedelsen av miljön också ta hänsyn till de multisite-konstanter och den sajtstruktur som importerade data förväntar sig. Det är här migreringsprojekt antingen förblir kontrollerade eller börjar samla på sig engångslösningar.

Fullständig säkerhetskopia och databasmigrering

I det här skedet kan ett enda felaktigt kommando slå ut alla sajter i nätverket. I en multisite hänger användare, roller, sajttabeller, nätverksinställningar och mycket av pluginsens data ihop. En slarvig import fallerar inte snyggt. Den skapar partiella skador som redaktörerna upptäcker flera dagar senare.

Det finns två framkomliga vägar. Använd ett migreringsplugin byggt för multisite, eller genomför flytten med WP-CLI och ta ansvar för varje steg själv. Jag använder båda. Rätt val beror på nätverkets storlek, ändringsfönstret och hur mycket driftsdisciplin teamet klarar av att hålla klockan 02.00 på natten.

Välj migreringsmetod utifrån risk, inte preferens

Ett plugin är ofta säkrare när projektet har ett kort underhållsfönster, ett mindre erfaret överlämningsteam eller ett nätverk med många undersajter och mappade domäner. All-in-One WP Migration är fortfarande ett vanligt val eftersom det paketerar nätverket på ett sätt som minskar fel på tabellnivå och hanterar WordPress-medveten sökning och ersättning under importen. Det skyddet är viktigt i multisite eftersom serialiserade värden finns i inställningar, widgets, data från sidbyggare och plugininställningar i hela nätverket.

WP-CLI passar bättre när du behöver repeterbarhet via skript, selektiva ersättningar, miljöspecifik kontroll eller en migreringslogg som du kan lämna över till en annan utvecklare under en återställning. Det är också det bättre alternativet när verksamhetens behov går utöver själva dataöverföringen. Pluginlicenser kan sluta fungera efter ett domän- eller serverbyte. Flerspråkiga plugins lagrar ofta SEO-metadata i egna tabeller eller serialiserade inställningsuppsättningar. Om de värdena inte migreras rent kan både placeringar och licensaktiveringar rasa samtidigt.

Om målet byggs från grunden, börja med ett rent nätverk som matchar den struktur som importerade data förväntar sig. Det är ännu viktigare om du gör om en fristående installation till ett nätverk eller byter mellan underdomän- och underkatalogläge. Använd en dokumenterad process för installation och konfiguration av WordPress Multisite före importen, så att databasen hamnar i ett nätverk med rätt konstanter och tabellantaganden.

WP-CLI-arbetsflöde för team som behöver kontroll

Börja med en fullständig export. Inte en partiell dump. Inte ”bara tabellerna för den aktiva sajten”. Hela nätverket.

wp db export network-backup.sql --all-tables

Innan du ändrar URL:er, gör en testkörning och granska utdata:

wp search-replace 'old-domain.com' 'new-domain.com' --network --precise --recurse-objects --all-tables --dry-run

Om omfattningen ser rätt ut, kör den faktiska ersättningen:

wp search-replace 'old-domain.com' 'new-domain.com' --network --precise --recurse-objects --all-tables

De här flaggorna gör verkligt jobb. --network förhindrar avvikelser från sajt till sajt. --precise byter hastighet mot noggrannhet, vilket oftast är rätt byte under en migrering. --recurse-objects skyddar serialiserade strukturer. --all-tables fångar upp plugintabeller och egna tabeller som team glömmer tills något affärskritiskt fallerar.

Serialiserade data är minfältet. Om verktyget inte förstår WordPress-serialisering, håll det borta från databasen.

Viktiga WP-CLI-kommandon för search-replace i multisite

Säkerhetskopiera nätverket som om du räknar med att återställa det

En användbar uppsättning säkerhetskopior är mer än en SQL-export som ligger i en delad mapp. För nätverk där mycket står på spel vill jag ha fyra saker innan någon rör produktion:

• Fullständig databasdump: Ta med nätverkstabeller, användartabeller, plugintabeller och allt som är anpassat.
• Ögonblicksbild av wp-content: Teman, plugins, mu-plugins, uppladdningar, språkfiler och kod för egna integrationer.
• Kopior av konfigurationen: wp-config.php, inställningar för objektcache, vhost-regler på servern och eventuell cron- eller worker-konfiguration kopplad till nätverket.
• Anteckningar för återställning: Exakt plats för återställningen, vem som verifierade den, vilken version som sparades och hur lång tid återställningen förväntas ta.

Det är också nu du ska exportera allt som kanske inte överlever en vanlig flytt av filer och databas på ett rent sätt. Licensnycklar för premium-plugins är ett vanligt exempel. Vissa leverantörer knyter aktiveringar till domäner, IP-adresser eller maskinfingeravtryck. Inaktivera där det är lämpligt, dokumentera nuvarande aktiveringar och bekräfta villkoren för ny utfärdning före övergången. Om nätverket använder plugins för flerspråkig SEO, verifiera var hreflang-data, översatta slugs, omdirigeringsregler och SEO-metadata lagras. Förlust av de data visar sig inte alltid som ett PHP-fel. Det visar sig som förlorad trafik en vecka senare.

Återkommande databasmisstag i multisite-projekt

Samma fel dyker upp om och om igen:

• Att köra rå SQL-ersättning mot serialiserat innehåll
• Att exportera bara synliga sajttabeller och missa nätverks- eller plugintabeller
• Att importera till ett mål med fel multisite-läge eller fel antaganden om tabellprefix
• Att glömma stegen för att återaktivera pluginlicenser tills kritiska funktioner slutar fungera
• Att uppdatera primärdomäner utan att kontrollera fält för flerspråkig SEO, canonical-taggar eller hreflang-referenser

Lösningen är inte komplicerad, men den kräver disciplin. Exportera hela nätverket. Logga varje kommando. Testa ersättningar med --dry-run. Spara en orörd kopia av databasen från före migreringen. I migreringar för större verksamheter är kommandohistorik, SQL-artefakter och licensförteckningar en del av affärskontinuiteten, inte extra pappersarbete.

Migrera filer och konfigurera nätverket

Övergångar på fredagskvällar fallerar här oftare än någon annanstans. Databasen importeras utan problem, startsidan renderas, alla slappnar av, och sedan upptäcker redaktörerna saknade media, licensierade plugins faller tillbaka till begränsat läge eller en mappad regional sajt börjar leverera fel filer. I en multisite-migrering är det filsystemet och nätverkskonfigurationen som avgör om lanseringen är stabil eller bara ser stabil ut de första tio minuterna.

Katalogen med högst risk är oftast wp-content/uploads. Den är stor, rörig och full av affärskritiska filer som ingen lägger märke till förrän en landningssida för en kampanj, en översatt PDF eller en produktbild försvinner.

Flytta filerna: integritet först, hastighet sedan

För stora nätverk är rsync standardvalet eftersom det bevarar strukturen, kan återupptas rent och ger dig en överföringsmetod som du kan köra mer än en gång före övergången. Det spelar roll. En enda stor kopia på en gång är långsammare att validera och svårare att lita på.

Ett standardmönster ser ut så här:

rsync -avz --progress /path/to/source/wp-content/ /path/to/destination/wp-content/

För stora företagsnätverk delar jag upp överföringen i faser. Först kopieras teman, plugins och mu-plugins. Uppladdningarna kopieras separat. Sedan körs en sista synkronisering nära övergången för att fånga upp bara de ändrade filerna:

rsync -avz --delete /path/to/source/wp-content/uploads/ /path/to/destination/wp-content/uploads/

Flaggan --delete är användbar, men bara när du är säker på att målet går att kasta eller redan är verifierat. Använd den slarvigt och du kan radera filer som lagts in manuellt på målet.

Undvik långa FTP-sessioner för det här arbetet. De är långsamma, de döljer partiella fel och de lämnar röriga granskningsspår när någon frågar vilka filer som kom fram. För stora uppladdningskataloger är stegvis kopiering med rsync ett praktiskt sätt att bevara filintegriteten och samtidigt hålla överföringen repeterbar.

Behörigheter förtjänar en egen kontroll. Om ägarskap eller filrättigheter ändras under flytten kan bildgenerering, skrivningar till cachen och pluginuppdateringar fallera efter lanseringen. Validera dem uttryckligen:

find /path/to/destination/wp-content -type d -exec chmod 755 {} ;
find /path/to/destination/wp-content -type f -exec chmod 644 {} ;
chown -R www-data:www-data /path/to/destination/wp-content

Konfigurera multisite korrekt i wp-config.php

Målet måste matcha den nätverksmodell som du migrerar. Ett litet stavfel i wp-config.php kan visa sig som inloggningsloopar, trasiga cookies eller undersajter som löses upp till huvudsajten.

Om multisite ska aktiveras på målet, lägg till:

define('WP_ALLOW_MULTISITE', true);

Den konstanten hör hemma direkt före raden /* That's all, stop editing! Happy publishing. */. När du har slutfört nätverkskonfigurationen genererar WordPress resten av multisite-konstanterna och omskrivningsreglerna utifrån underdomän- eller underkatalogläge. Behåll de genererade värdena exakt som de är. Att redigera dem för hand utan skäl är hur fungerande nätverk blir inkonsekventa.

Om du behöver en referens för installationssidan medan du validerar arkitekturvalen är den här guiden om att installera WordPress Multisite användbar innan du låser konfigurationen på målet.

Två inställningar förtjänar extra granskning under migreringen: domänstrukturen och antagandena om sökvägar. Om källnätverket använde underkataloger och målet byggs om med underdomäner kan det hända att plugininställningar, omdirigeringslogik och sökvägar för flerspråkig SEO inte längre stämmer med det som är lagrat. Startsidan kan fortfarande laddas medan hreflang-referenser, canonical-taggar och språkspecifika medie-URL:er går sönder.

Updrafts guide om att göra om WordPress till multisite är också en nyttig påminnelse om att WP_ALLOW_MULTISITE bara är ingångspunkten. I projekt där en enskild sajt blir en undersajt är pluginsens tillstånd och rätt mål för återställningen viktiga. En återställning i fel sajtkontext kan skriva över fel tabeller eller lämna undersajten konfigurerad som en fristående installation.

Välj struktur utifrån driften, inte preferens

Både underdomäner och underkataloger är giltiga. Rätt val beror på hur verksamheten drivs.

• Underdomäner passar bättre när varje sajt behandlas som ett eget varumärke, ett eget land eller en egen juridisk enhet med egen DNS, SSL och egna marknadsföringsflöden.
• Underkataloger passar bättre när nätverket fungerar som en publiceringsplattform med delad auktoritet och nära besläktat innehåll.
• Mappade domäner ökar driftrisken eftersom varje mappad egendom lägger till hänsyn kring SSL, DNS, omdirigeringar, cache och återställning.

Det är också här konflikter kring pluginlicenser kommer upp till ytan. Vissa premium-plugins licensieras per domän, per miljö eller per aktiv sajt. Ett nätverk som fungerade på källservern kan efter migreringen plötsligt visa inaktiverade funktioner på mappade domäner. Kontrollera licenspanelerna före lanseringen, särskilt för plugins för SEO, formulär, översättning och sidbyggare. Sådana fel ger inte alltid ett synligt felmeddelande. De visar sig som saknad schema-utdata, blockerade uppdateringar eller administratörsaviseringar som bara nätverksadministratörer ser.

Här är en användbar genomgång innan du slutför de här inställningarna:

Missa inte koden som ligger utanför temat

Fel i multisite kommer ofta från kod som aldrig låg i det aktiva temat från början.

Kontrollera allt följande:

• Must-use-plugins
• Drop-ins
• Egna cron-skript
• Miljöspecifika include-filer
• Beroenden av omskrivningsregler på servern

Verifiera också drop-ins för objektcache, sunrise-konfigurationen om domänmappningen är beroende av den, och eventuella symboliska länkar som skapas vid driftsättning. De delarna stödjer ofta autentisering, omdirigeringar, sidcache, bildhantering och flerspråkig routning. Om en av dem saknas kan nätverket se funktionellt ut medan viktiga affärsflöden fallerar under belastning eller på sekundära domäner.

Behandla flytten av filsystemet som en produktionsdriftsättning. Inventera innehållet, synkronisera i etapper och verifiera först de delar som påverkar intäkter, SEO och återställning.

Testning efter migreringen och domänmappning

Migreringen är inte klar när startsidan laddas. Det är testningens öppningsdrag, inte dess avslutning. Ett multisite-nätverk kan se friskt ut vid första anblick och samtidigt dölja trasiga användarroller, ogiltiga mediesökvägar, felformade omdirigeringar eller en mappad domän som skickar trafiken till fel sajt.

Det snabbaste sättet att fånga det här är att behandla valideringen efter migreringen som utredningsarbete. Du bevisar inte att sajten laddas. Du försöker bevisa att inget kritiskt saknas.

Börja med de system som oftast fallerar

Delicious Brains rapporterar att felaktig hantering av sökvägar till mediefiler är en vanlig fallgrop vid multisite-migreringar och förekommer i ungefär 35 % av manuella migreringsförsök, medan automatiserade migreringar med förkontroller kan nå 92 % framgång och manuella migreringar utan förkontroller misslyckas i 28 % av fallen, enligt artikeln om att dela upp en WordPress Multisite och migrera en undersajt.

De siffrorna stämmer med vad team ser i produktion. Media går sönder först eftersom det är beroende av sökvägsstruktur, behörigheter och korrekta URL:er på en gång.

Börja med:

• Mediebibliotek: Öppna gamla inlägg, inte bara nya. Kontrollera utvalda bilder, gallerier, bilder i texten och nedladdningsbara filer.
• Administratörsåtkomst: Verifiera Network Admin, administration av undersajter och rollspecifika inloggningar.
• Kritiska formulär och transaktioner: Testa formulärinskick, sök, varukorgar, låst innehåll och åtgärder som utlöses av e-post.
• Utdata från plugins: Granska allt som skriver egna URL:er, bäddar in skript eller lagrar data i egna tabeller.

Startsidan är den minst användbara testsidan i en multisite-migrering. Innehållet längre in avslöjar den verkliga skadan.

Genomför en strukturerad verifieringsrunda

En bra verifieringsrunda efter migreringen går från kontroller på nätverksnivå till kontroller på undersajtsnivå. Hoppa inte runt.

Kontroller på nätverksnivå

• Sajtregister: Bekräfta att varje förväntad undersajt finns och routas korrekt.
• Delade användare: Testa en användare som tillhör flera sajter och verifiera användarens behörigheter på var och en.
• Nätverksplugins: Bekräfta att nätverksaktiverade plugins fortfarande fungerar som avsett.
• Tillgängliga teman: Se till att aktiverade teman syns där de ska.

Kontroller på undersajtsnivå

• Rendering i frontend: Granska startsidan, viktiga landningssidor, inläggsarkiv och formulär.
• Redaktörsupplevelse: Öppna blockredigeraren, mediauppladdaren, återanvändbara mönster och anpassade fält.
• URL-beteende: Kontrollera permalänkar, paginering och omdirigeringar.
• Lokaliserat innehåll: Granska språkspecifikt innehåll och navigering om nätverket är flerspråkigt.

En enkel testlogg hjälper teamen att hålla sig ärliga:

Mappa domäner först när nätverket har klarat valideringen

Domänmappning bör vara ett av de sista stegen, inte en tidig gissning. När det importerade nätverket är stabilt på målet pekar du varje mappad egendom medvetet och validerar svaret sajt för sajt.

För SEO-känsliga nätverk hänger domänmappningen också ihop med sökstrukturen. Om en flerspråkig undersajt eller en regional domän beter sig annorlunda efter flytten måste du granska canonical-taggar, alternate-taggar och genomsökningsvägar. Det är särskilt relevant för team som ansvarar för SEO för WordPress Multisite, där teknisk routning och söksignaler hänger tätt ihop.

Spara om och kontrollera igen, men lita inte bara på det

Ja, att spara om permalänkarna hjälper ofta efter en import. Nej, det är ingen fullständig lösning. Det återställer inte saknade uppladdningar, löser inte problem med pluginlicenser och rättar inte rolltilldelningar som har blivit fel.

En mogen testrunda är klar först när verkliga användare kan göra sitt jobb i det nya nätverket. Fram till dess är migreringen fortfarande provisorisk.

Återställningsplaner och optimering av lanseringen

Klockan 02.07 på natten är DNS-övergången aktiv, inloggningen fungerar fortfarande och startsidan ser bra ut. Tio minuter senare börjar betald trafik hamna på fel regional sajt, ett premium-plugin hamnar i provläge på två undersajter och canonical-taggarna pekar tillbaka till den gamla domänen. Det är den delen av en migrering av WordPress Multisite som vanliga checklistor underskattar. Överföringen kan lyckas och lanseringen ändå misslyckas.

Återställning måste vara en driftsrutin, inte ett vagt löfte om att ”återställa säkerhetskopian”. I byråarbete är skillnaden enkel. En verklig återställningsplan anger den exakta återställningspunkten, kommandoordningen, vem som kan godkänna att man backar, vem som ändrar DNS och vilka förhållanden som utlöser beslutet. Utan det lägger teamen 30 till 60 minuter på att diskutera medan användare och sökrobotar fortsätter att träffa en trasig stack.

Skriv planen så att jourhavande utvecklare kan köra den halvsovande. Håll den kort och konkret:

1. Releaseidentifierare kopplad till den slutliga databasdumpen och ögonblicksbilden av filerna
2. Återställningskommandon för databasen och uppladdningarna
3. Ansvarig för att vända tillbaka DNS och åtkomstväg till registrar eller CDN
4. Anteckningar om återställning av pluginlicenser för allt som är knutet till domän, IP-adress eller miljö
5. Affärsmässig utlösare för återställning, till exempel fel i kassan, utelåsta administratörer eller routningsfel mellan domäner
6. Validering efter återställningen för de få funktioner som betyder mest först

Om måldatabasen till exempel redan är inläst och du måste backa snabbt bör runbooken innehålla de exakta kommandona, inte en hänvisning till ”säkerhetskopian i S3”:

wp db import /backups/prod-prelaunch.sql
rsync -av /backups/uploads/ wp-content/uploads/
wp cache flush

Om objektcache eller Redis används, lägg till det kommandot också. Om ditt edge-lager hanterar omdirigeringar, notera om återställningen omfattar att inaktivera page rules eller origin-åsidosättningar. Jag har sett tekniskt korrekta databasåterställningar misslyckas eftersom Cloudflare, Route 53 eller en lastbalanserare fortsatte att leverera den nya originservern.

DNS är oftast den långsammaste delen av en återgång, och därför börjar optimeringen av lanseringen före lanseringskvällen. Korta TTL-värden hjälper, men de garanterar inte omedelbar korrigering. Vissa resolvrar ignorerar dem. Vissa klienter sitter bakom aggressiv cachning. Planera för en period med blandad trafik där en del av publiken ser den gamla stacken och en del den nya.

Den verkligheten förändrar hur du lanserar. Frys innehållet före övergången. Lägg beställningar eller redaktionella ändringar i kö om verksamheten tål det. Om den inte gör det behöver du en avstämningsplan för kommentarer, formulär, handelsdata och användarregistreringar som skapas i överlappningsfönstret.

Flerspråkig SEO behöver en egen tröskel för återställning. I praktiken är det här ett av de enklaste ställena att missa en affärsrisk, eftersom sidan visas normalt. De dolda felen finns i canonical-taggar, hreflang-par, regionala omdirigeringar, översatta slugs, XML-webbplatskartor och marknadsväljare. Vår erfarenhet är att migrerade multisite-egendomar ofta tappar några av de signalerna vid utbrytning eller ny domänmappning, särskilt när SEO-plugins lagrar inställningar på en annan nivå än teamet förväntade sig.

Kontrollera de här punkterna direkt efter övergången:

• Canonical-taggar på de viktigaste mallarna och landningssidorna
• Hreflang-par för varje språk- eller marknadsvariant
• Lokaliserade URL-strukturer som /de/ eller landsspecifika underdomäner
• Webbplatskartor genererade av det aktiva SEO-pluginet på målet
• Omdirigeringsbeteende från äldre regionala URL:er
• Indexeringskontroller, så att noindex-regler från staging inte följde med in i lanseringen

Pluginlicenser förtjänar lika mycket uppmärksamhet. Team i större verksamheter överraskas här eftersom pluginet fungerade i det gamla nätverket och sedan fallerar på den utbrutna sajten eller den nya domänen. Felet är sällan dramatiskt. Ofta är det en saknad fältgrupp, inaktiverad formulärleverans, en blockerad uppdateringskanal eller en banner som blir till trasig utdata när cachen löper ut. Om en pluginleverantör knyter licensen till det ursprungliga nätverket, ta med de manuella aktiveringsstegen i lanseringens runbook och bestäm om det läget är en utlösare för återställning eller en känd uppgift efter lanseringen.

Optimeringen av lanseringen kommer efter stabilitetskontrollerna, inte före. Töm cachelagren. Värm upp de sidor som betyder något. Granska PHP-loggar, webbserverloggar, omdirigeringskedjor, cron-händelser och transaktionsmejl. Testa sedan de kommersiella flödena under verkliga förhållanden: inloggade sessioner, språkbyte, formulärinskick, sök, kassa och eventuella callbacks från tredje part.

Använd WP-CLI för den städning som ska kunna upprepas:

wp cache flush
wp rewrite flush --hard
wp cron event run --due-now
wp search-replace 'https://staging.example.com' 'https://example.com' --network --skip-columns=guid

Det sista kommandot är kraftfullt och farligt. I multisite bör du köra det först när du har bekräftat måldomänerna, de mappade värdarna och omfattningen av serialiserade data. En felaktig ersättning i hela nätverket är hur du skapar ett nytt avbrott medan du försöker åtgärda det första.

En stark lansering är tråkig på bästa möjliga sätt. Användarna fortsätter att arbeta. Söksignalerna förblir intakta. Licensierade plugins fortsätter att valideras. Och om något av det går sönder så illa att det hotar intäkter eller drift sker återställningen snabbt, eftersom teamet redan har valt utlösaren, den ansvariga och de exakta kommandona.

Avancerade scenarier och viktiga frågor och svar

Fredag kl. 17:30: databasimporten är klar, uppladdningarna är på plats och undersajten laddas. Sedan försvinner översättningar från hreflang-taggarna, ett formulärplugin hamnar i provläge och SEO-teamet upptäcker att canonical-taggarna nu pekar på den gamla nätverksdomänen. Det är den delen som vanliga guider för multisite-migrering oftast missar.

De kostsamma felen vid migrering av WordPress Multisite uppstår efter att filerna och tabellerna har flyttats. Pluginlicenser kan sluta fungera när en undersajt lämnar ett nätverk. Flerspråkiga plugins kan fortsätta att visa sidor medan de tappar kopplingarna mellan språken eller metadata. En återställningsplan som såg bra ut på papperet kan falla isär om återaktivering av licenser, DNS-timing eller callbacks från tredje part aldrig testades.

Pluginlicenser är en driftrisk, inte en städuppgift

Diskussioner i supportforumet om multisite-migrering på WordPress.org pekar gång på gång ut trasiga plugins som ett vanligt problem efter migrering, ofta kopplat till licenser, saknade multisite-plugin eller nätverksspecifika inställningar. Behandla det som ett arbetsflöde före lanseringen, inte som en överraskning efteråt.

Ett premium-plugin kan bete sig korrekt i ett nätverk och fallera i samma ögonblick som en sajt blir fristående. Jag ser det oftast med domänbundna licenser, plugins som lagrar tillståndet i wp_sitemeta i stället för i inställningar per sajt och leverantörer som säljer multisite-stöd som en separat rättighet.

Kontrollera de här punkterna innan du godkänner övergången:

• Har pluginet stöd för både multisite- och fristående installationer?
• Är den nuvarande licensen giltig för måldomänen?
• Ligger aktiveringsdata i nätverksinställningar, sajtinställningar, egna tabeller eller ett externt API?
• Kan pluginet återaktiveras via CLI eller bara via wp-admin?
• Om licensen fallerar, förlorar sajten funktioner, förlorar den uppdateringar eller slutar den visa kritiskt innehåll?

Om leverantören inte kan svara tydligt på de frågorna, planera för manuell åtgärd och bestäm om ett fel i pluginet ska stoppa lanseringen.

Du kan snabbt kontrollera inställningarnas omfattning med WP-CLI:

wp option get active_plugins
wp site option get active_sitewide_plugins
wp db query "SELECT meta_key FROM wp_sitemeta ORDER BY meta_key;"

På utbrutna undersajter bör du också jämföra pluginspecifika tabeller. Vissa plugins lagrar licenser, språkkopplingar eller köstatus utanför de vanliga inställningarna.

Flerspråkig SEO går sönder i det tysta

En flerspråkig undersajt kan se bra ut för redaktörerna och ändå tappa sökvärde efter migreringen. De vanliga felen är felaktiga canonical-taggar, saknade hreflang-taggar, trasiga översatta URL-slugs och språkväljare som pekar på gamla värdar. Därför hör flerspråkig validering hemma i lanseringschecklistan, inte bara i den allmänna kvalitetssäkringen.

För WPML, Polylang eller egna flerspråkiga uppsättningar bör du verifiera allt följande på den migrerade sajten:

• Canonical-taggar pekar på rätt domän i produktion
• Hreflang-taggar refererar till rätt språkvarianter
• Översatta sidor är fortfarande kopplade till varandra
• XML-webbplatskartor innehåller alla språk och rätt värdnamn
• Omdirigeringsregler bevarar gamla språksökvägar och frågeparametrar där det behövs

Lita inte på en kontroll av startsidan. Testa djupa URL:er, paginerade arkiv och de sidor som genererar intäkter.

Tre viktiga frågor och svar

Kan man migrera en enskild sajt till ett befintligt multisite-nätverk?
Ja, men skapa målundersajten först och återställ i rätt blog ID-kontext. Om du importerar data mot fel sajt-ID kan uppladdningssökvägar, användarroller och plugininställningar kopplas till fel tabeller. Kontrollera målet före importen med:

wp site list
wp db tables | grep _2_

Ersätt _2_ med det faktiska blog ID som du räknar med att använda.

Kan man bryta ut en undersajt till en egen fristående WordPress-installation?
Ja. Själva överföringen är oftast enkel. Risken ligger i allt runt omkring: omskrivning av mediesökvägar, schemalagda jobb, licensierade plugins och SEO-signaler som tidigare hanterades på nätverksnivå. I verkliga projekt är det vid utbrytningen som affärskontinuiteten sätts på prov.

Hur är det med användare och behörigheter?
Användare är globala i multisite. Roller är det inte. Bekräfta behörigheterna på målsajten efter migreringen, särskilt för redaktörer, butiksansvariga och alla konton som är integrerade med SSO. Om det ursprungliga nätverket delade användare mellan egendomar, verifiera om de användarna över huvud taget ska finnas på den utbrutna sajten.

Frågan som ingen ställer tillräckligt tidigt

Vilken är den snabbaste säkra återställningen om den migrerade sajten är i produktion och intäktsflödena börjar fallera?
Använd en återställning som återställer den senaste databasen som man vet fungerade, skickar tillbaka trafiken till den gamla miljön och inkluderar eventuella leverantörssteg som behövs för att validera licenser på nytt eller aktivera flerspråkiga tjänster igen. Om din återställning är beroende av att folk listar ut saker under ett avbrott är det ingen återställningsplan.

Ha en skriftlig ordningsföljd med namngivna ansvariga, antaganden om DNS-TTL och exakta återställningskommandon. Till exempel:

wp db import prelaunch-backup.sql
wp search-replace 'https://new.example.com' 'https://old.example.com' --skip-columns=guid
wp cache flush

Kör det bara i den miljö som du tänker återställa. I multisite kan en slarvig search-replace göra avbrottet större.

Den svåra delen av en multisite-migrering är att bevara verksamhetens funktion under press. Dataöverföringen är bara ett lager. Licenser, flerspråkig SEO och disciplin kring återställning är det som hindrar att flytten blir en incident som drabbar intäkterna.

Om ditt team behöver erfarna händer för en multisite-flytt med hög risk är IMADO den sortens utvecklingspartner som är värd att ta in tidigt. De tar hand om de delar som brukar underskattas, bland annat flerspråkig arkitektur, komplexitet i multisite, prestanda och lanseringsdisciplin, utan att göra projektet till en generisk ”webbplatsflytt”.