Migrering av WordPress Multisite: komplett håndbok for 2026

Du befinner deg sannsynligvis i én av to situasjoner akkurat nå. Enten har et multisite-nettverk vokst ut av serveren, styringsmodellen eller URL-strukturen det startet med, eller så har noen på forretningssiden bestemt at ett undernettsted skal bli sin egen plattform uten at synligheten i søk, de redaksjonelle arbeidsflytene og inntektene går i stykker.

Det er her migrering av WordPress Multisite slutter å være en rutinemessig hostingoppgave og blir et utviklingsprosjekt. Selve den tekniske flyttingen er viktig, men de største risikoene ligger som regel et annet sted: en utvidelseslisens som ikke lenger valideres etter utskillelsen, et flerspråklig oppsett som mister canonical-taggene sine, et mediebibliotek som ser greit ut helt til redaksjonen oppdager ødelagte filer tre dager senere, eller en tilbakerullingsplan som bare finnes som et vagt løfte.

De ryddigste migreringene jeg har sett, følger alle det samme mønsteret. De behandler databaseflyttingen som én del av en større, kontrollert endring. De låser omfanget tidlig, tester som etterforskere og går ut fra at noe vil svikte så lenge det ikke er verifisert. Det er denne tankegangen som hindrer at en multisite-migrering blir en hendelse sent på kvelden.

Strategi før migreringen og risikovurdering

Fredag kl. 20.40. DNS skal snart byttes, databaseimporten er ferdig, og noen spør om hreflang-taggene på det franske undernettstedet ble bevart, og hvilke lisenser for premium-utvidelser som vil overleve flyttingen. Hvis det spørsmålet dukker opp på migreringskvelden, har planleggingen feilet.

En migrering av WordPress Multisite starter med kontroll på omfanget og planlegging for feil. Databasen og filene er viktige, men høyrisikoprosjekter ryker som regel på spørsmål om forretningskontinuitet: utvidelseslisenser knyttet til det gamle domenet eller installasjonstypen, regler for flerspråklig SEO som forsvinner etter utskillelsen, og tilbakerullingsplaner som høres fine ut helt til noen må bestemme under press om DNS skal reverseres.

Behandle planen som en runbook for hendelser. Før noen rører produksjon, bør den svare på fire ting:

1. Hva som flyttes, helt konkret
2. Hva som må være tilgjengelig hele tiden
3. Hva som utløser tilbakerulling
4. Hvem som har myndighet til å godkjenne lanseringen eller reversere den

Definer omfanget av migreringen før du velger verktøy

«Flytt multisiten» er ikke et brukbart omfang. I praksis er bestillingen ofte mer rotete: skill ut ett inntektsbringende undernettsted som en frittstående WordPress-installasjon, la to eldre undernettsteder bli igjen, behold de tilordnede domenene, sørg for at redaksjonen kan jobbe mandag morgen, og unngå å miste rangeringer på tre språk.

Skriv ned inventaret først.

• Hvert undernettsted: nåværende URL, tilordnet domene, forretningsansvarlig og toleranse for nedetid
• Aktiveringsmodell: nettverksaktiverte utvidelser kontra utvidelser på nettstedsnivå
• Egen kode: mu-plugins, drop-ins, egne tabeller, cron-jobber, webhooks og overstyringer i temaet
• Delte avhengigheter: mediereferanser, API-integrasjoner, SSO, skjemaer, søk og analyseskript

Hvis ingen kan si hvilke undernettsteder som kan være nede, og hvor lenge, er migreringen ikke klar.

Det er også her teamene bestemmer om arbeidet skal gjøres internt, eller om de skal hente inn en spesialist på migreringstjenester for WordPress. Avveiningen er enkel. Interne team kjenner teknologistakken. Eksterne aktører tar ofte med seg en ryddigere runbook, bedre disiplin rundt tilbakerulling og færre antakelser.

Gå gjennom feilpunktene som gjør vondt etter lansering

Eksport og import av databasen er den enkle delen. De kostbare feilene dukker opp senere, når nettstedet ser «stort sett greit» ut.

Utvidelseslisenser er et vanlig eksempel. Premium-utvidelser kan validere lisensen ut fra primærdomene, nettverkskontekst, antall nettsteder eller miljø. Et undernettsted som er skilt ut fra en multisite, kan starte korrekt og likevel miste tilgang til oppdateringer, feltvisning, oversettelsesfunksjoner eller kasseintegrasjoner fordi lisensen ikke lenger samsvarer med den nye installasjonen. Sjekk leverandørenes vilkår før flyttingen, ikke etterpå.

Flerspråklig SEO fortjener like mye oppmerksomhet. Hvis nettverket bruker WPML, Polylang, egen hreflang-utdata, markedsspesifikke canonical-tagger eller oversatte slugs, må du dokumentere hvordan det fungerer i dag. Det omfatter title-tagger, canonical-tagger, hreflang-tagger, XML-nettstedskart, omdirigeringsregler og språkbaserte maler. Et nettsted kan bestå den visuelle kvalitetssikringen og likevel miste søkeverdi fordi metadatalaget endret seg uten at noen la merke til det.

Media er en annen felle. I en multisite limer redaktører ofte inn fil-URL-er på tvers av undernettsteder, bruker egendefinerte felt som viser til gamle opplastingsstier, eller er avhengige av utvidelser som skriver om mediehåndteringen. Ødelagte miniatyrbilder er irriterende. Ødelagte dokumenter, kampanjemateriell og lokaliserte PDF-er skaper supporthenvendelser raskt.

Lag en risikologg du faktisk kan bruke

Hold den så kort at migreringsansvarlig leser den under omleggingen.

Sett objektive utløsere for tilbakerulling

Tilbakerulling bør ikke avhenge av selvtillit, humør eller hvem som snakker høyest i samtalen. Sett målbare utløsere før lansering.

Eksempler:

• Administratortilgangen svikter for de viktigste nettstedseierne
• Kassen, leadskjemaer eller innloggingsflyter svikter
• Domenetilordningen sender trafikk til feil undernettsted
• Kritiske flerspråklige metadata mangler på produksjonssider
• Utvidelseslisenser deaktiverer nødvendige funksjoner
• Feilratene øker kraftig og kan ikke rettes innenfor vedlikeholdsvinduet

Skriv ned terskelen og få den godkjent av migreringsansvarlig, produkteier og personen som kontrollerer DNS. Jeg anbefaler også å skrive ned de nøyaktige kommandoene og handlingene for tilbakerulling, ikke bare beslutningsregelen. I virkelige hendelser slår klarhet optimisme.

Hvis tilbakerullingen for eksempel omfatter å gjenopprette den gamle databasen og tvinge DNS tilbake, skriv ned rekkefølgen:

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

Bruk prøvekjøringer (dry runs) under planleggingen for å bekrefte at teamet har tilgangene det tror det har. På migreringskvelden kan manglende WP-CLI-rettigheter eller feil SSH-nøkkel spise opp tiden du trengte til gjenopprettingen.

Gode multisite-migreringer er kontrollerte endringer. Teamene som kommer ryddig gjennom dem, bestemmer omfanget tidlig, dokumenterer skjulte avhengigheter, tester hvordan lisenser og SEO oppfører seg før omleggingen og definerer tilbakerullingen som om de regner med å bruke den.

Klargjøre miljøene og DNS

De fleste mislykkede migreringer begynner med et avvik mellom det gamle miljøet og det nye. Ikke et dramatisk avvik. Et stille et. En PHP-utvidelse som mangler på målserveren, et problem med filrettigheter i uploads, et hull i omskrivingsreglene eller DNS-endringer som blir liggende til siste time.

Det nye miljøet bør være kjedelig. Det er målet. Hvis målet oppfører seg annerledes enn kilden på måter du ikke har tatt høyde for, vil migreringen avdekke forskjellene som brutte økter, medieproblemer eller feil i utvidelser.

Bygg målet slik at det samsvarer med kilden

Start med en ren WordPress-installasjon på målet, og klargjør den for multisite før du importerer noe. Hvis du flytter til et nytt nettverk, lag det samme strukturmønsteret som du allerede bruker. Ikke bytt fra underkataloger til underdomener i samme migrering med mindre det finnes en tungtveiende grunn og et eget testløp.

På dette stadiet bør du bekrefte:

• PHP-kompatibilitet: Bruk støttede versjoner som det nåværende temaet og utvidelsene krever.
• Databasetilgang: Test CLI-tilgang, importrettigheter og hvordan tabeller opprettes.
• Eierskap i filsystemet: Sørg for at WordPress kan skrive til riktige kataloger uten provisoriske løsninger for rettigheter.
• Shell-tilgang: Bekreft SSH- og WP-CLI-tilgang før migreringsdagen.
• E-post og eksterne tjenester: Klargjør det nettverket trenger for skjemaer, transaksjonsflyter eller webhooks.

For team som flytter infrastruktur som en del av et leverandørbytte, er det her en praktisk veiledning om å flytte et WordPress-nettsted til en ny leverandør blir relevant, fordi leverandørbyttet og multisite-flyttingen ofte overlapper driftsmessig selv når dataflyten er en annen.

Klargjør DNS både for lansering og retrett

DNS-planlegging får for lite oppmerksomhet i de fleste migreringsveiledninger. Det burde den få. Du vil at den endelige omleggingen skal gå raskt, men du vil også at retretten skal gå raskt hvis valideringen i produksjon feiler.

Den viktigste vanen er å senke TTL-verdiene i god tid før migreringsvinduet. Det gir en ryddigere omlegging og en realistisk mulighet for tilbakerulling. Hvis du venter for lenge med DNS-forberedelsene, kan du fortsatt migrere, men gjenopprettingsvinduet blir vanskeligere å kontrollere.

Bruk denne sjekklisten før omleggingen:

• Senk TTL tidlig: Gjør det i god tid før lansering, ikke under.
• Dokumenter tilordnede domener: Spesielt for multisite-nettverk med domener for merkevarer, språk eller kunder.
• Bekreft SSL-dekning: Underdomener og tilordnede domener må løses opp korrekt etter omleggingen.
• Klargjør verifiseringsverter på forhånd: Bruk ikke-offentlige valideringsmetoder for å teste rutingen før du flytter produksjonstrafikken.

Ikke hopp over en ren installasjon

Mange team vil kopiere hele den gamle installasjonen først og «rydde opp senere». Det drar som regel gamle antakelser med inn i det nye miljøet. En fersk installasjon på målet gir deg et kjent utgangspunkt og gjør det lettere å isolere feil.

Hvis flyttingen innebærer å gjøre et frittstående nettsted om til et undernettsted, eller å opprette et nettverk på målet først, må klargjøringen av miljøet også ta hensyn til multisite-konstantene og nettstedsstrukturen som de importerte dataene forventer. Det er her migreringsprosjekter enten forblir kontrollerte eller begynner å samle opp enkeltstående hurtigfikser.

Fullstendig sikkerhetskopi og databasemigrering

På dette stadiet kan én feil kommando ta ned alle nettstedene i nettverket. I en multisite henger brukere, roller, nettstedstabeller, nettverksinnstillinger og mye av dataene til utvidelsene sammen. En slurvete import feiler ikke pent. Den skaper delvise skader som redaksjonen oppdager flere dager senere.

Det finnes to farbare veier. Bruk en migreringsutvidelse laget for multisite, eller gjennomfør flyttingen med WP-CLI og ta ansvar for hvert steg selv. Jeg bruker begge. Riktig valg avhenger av nettverkets størrelse, endringsvinduet og hvor mye driftsdisiplin teamet klarer å holde klokken 02.00 om natten.

Velg migreringsmetode ut fra risiko, ikke preferanse

En utvidelse er ofte tryggere når prosjektet har et kort vedlikeholdsvindu, et mindre erfarent overtakelsesteam eller et nettverk med mange undernettsteder og tilordnede domener. All-in-One WP Migration er fortsatt et vanlig valg fordi den pakker nettverket på en måte som reduserer feil på tabellnivå, og håndterer WordPress-bevisst søk og erstatt under importen. Den beskyttelsen er viktig i multisite fordi serialiserte verdier ligger i innstillinger, widgets, data fra sidebyggere og utvidelsesinnstillinger i hele nettverket.

WP-CLI passer bedre når du trenger repeterbarhet gjennom skript, selektive erstatninger, miljøspesifikk kontroll eller en migreringslogg du kan gi til en annen utvikler under en tilbakerulling. Det er også det beste alternativet når virksomhetens behov går utover selve dataoverføringen. Utvidelseslisenser kan slutte å fungere etter et domene- eller serverbytte. Flerspråklige utvidelser lagrer ofte SEO-metadata i egne tabeller eller serialiserte innstillingssett. Hvis disse verdiene ikke migreres ryddig, kan rangeringer og lisensaktiveringer falle samtidig.

Hvis målet bygges fra bunnen av, start med et rent nettverk som samsvarer med strukturen de importerte dataene forventer. Dette er enda viktigere hvis du gjør en frittstående installasjon om til et nettverk eller bytter mellom underdomene- og underkatalogmodus. Bruk en dokumentert prosess for installasjon og oppsett av WordPress Multisite før importen, slik at databasen havner i et nettverk med riktige konstanter og tabellantakelser.

WP-CLI-arbeidsflyt for team som trenger kontroll

Start med en full eksport. Ikke en delvis dump. Ikke «bare tabellene for det aktive nettstedet». Hele nettverket.

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

Før du endrer URL-er, kjør en prøvekjøring og gå gjennom utdataene:

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

Hvis omfanget ser riktig ut, kjør den faktiske erstatningen:

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

Disse flaggene gjør reell jobb. --network hindrer avvik fra nettsted til nettsted. --precise bytter fart mot nøyaktighet, som vanligvis er riktig bytte under en migrering. --recurse-objects beskytter serialiserte strukturer. --all-tables fanger opp utvidelsestabeller og egne tabeller som team glemmer helt til noe forretningskritisk svikter.

Serialiserte data er landminen. Hvis verktøyet ikke forstår WordPress-serialisering, hold det unna databasen.

Viktige WP-CLI-kommandoer for search-replace i multisite

Ta sikkerhetskopi av nettverket som om du regner med å rulle det tilbake

Et brukbart sett med sikkerhetskopier er mer enn en SQL-eksport som ligger i en delt mappe. For nettverk der mye står på spill, vil jeg ha fire ting før noen rører produksjon:

• Full databasedump: Ta med nettverkstabeller, brukertabeller, utvidelsestabeller og alt som er egendefinert.
• Øyeblikksbilde av wp-content: Temaer, utvidelser, mu-plugins, opplastinger, språkfiler og kode for egne integrasjoner.
• Kopier av konfigurasjonen: wp-config.php, innstillinger for objektbuffer, vhost-regler på serveren og eventuell cron- eller worker-konfigurasjon knyttet til nettverket.
• Notater for gjenoppretting: Nøyaktig sted for gjenopprettingen, hvem som verifiserte den, hvilken versjon som ble tatt vare på, og hvor lang tid gjenopprettingen forventes å ta.

Dette er også tidspunktet for å eksportere alt som kanskje ikke overlever en vanlig flytting av filer og database på en ryddig måte. Lisensnøkler for premium-utvidelser er et vanlig eksempel. Noen leverandører knytter aktiveringer til domener, IP-adresser eller maskinfingeravtrykk. Deaktiver der det er hensiktsmessig, dokumenter dagens aktiveringer og bekreft vilkårene for ny utstedelse før omleggingen. Hvis nettverket bruker utvidelser for flerspråklig SEO, verifiser hvor hreflang-data, oversatte slugs, omdirigeringsregler og SEO-metadata lagres. Tap av disse dataene viser seg ikke alltid som en PHP-feil. Det viser seg som tapt trafikk en uke senere.

Gjentakende databasefeil i multisite-prosjekter

De samme feilene dukker opp igjen og igjen:

• Kjøre rå SQL-erstatning mot serialisert innhold
• Eksportere bare synlige nettstedstabeller og gå glipp av nettverks- eller utvidelsestabeller
• Importere til et mål med feil multisite-modus eller feil antakelser om tabellprefiks
• Glemme trinnene for å reaktivere utvidelseslisenser til kritiske funksjoner slutter å virke
• Oppdatere primærdomener uten å sjekke felt for flerspråklig SEO, canonical-tagger eller hreflang-referanser

Løsningen er ikke komplisert, men den krever disiplin. Eksporter hele nettverket. Loggfør hver kommando. Test erstatninger med --dry-run. Ta vare på en urørt kopi av databasen fra før migreringen. I migreringer for større virksomheter er kommandohistorikk, SQL-artefakter og lisensoversikter en del av forretningskontinuiteten, ikke ekstra papirarbeid.

Migrere filer og konfigurere nettverket

Omlegginger fredag kveld feiler her oftere enn noe annet sted. Databasen importeres uten problemer, forsiden vises, alle slapper av, og så oppdager redaksjonen manglende media, lisensierte utvidelser faller tilbake til begrenset modus, eller et tilordnet regionalt nettsted begynner å levere feil filer. I en multisite-migrering er det filsystemet og nettverkskonfigurasjonen som avgjør om lanseringen er stabil eller bare ser stabil ut de første ti minuttene.

Katalogen med høyest risiko er som regel wp-content/uploads. Den er stor, rotete og full av forretningskritiske filer som ingen legger merke til før en landingsside for en kampanje, en oversatt PDF eller et produktbilde forsvinner.

Flytt filene: integritet først, fart etterpå

For store nettverk er rsync standardvalget fordi det bevarer strukturen, kan gjenopptas ryddig og gir deg en overføringsmetode du kan kjøre mer enn én gang før omleggingen. Det betyr noe. Én stor kopi i én omgang er tregere å validere og vanskeligere å stole på.

Et standardmønster ser slik ut:

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

For store virksomhetsnettverk deler jeg overføringen i faser. Først kopieres temaer, utvidelser og mu-plugins. Opplastingene kopieres separat. Deretter kjøres en siste synkronisering tett opp mot omleggingen for å fange opp bare de endrede filene:

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

Flagget --delete er nyttig, men bare når du er sikker på at målet kan forkastes eller allerede er verifisert. Brukt uforsiktig kan det slette filer som ble lagt inn manuelt på målet.

Unngå lange FTP-økter til dette arbeidet. De er trege, de skjuler delvise feil, og de etterlater rotete revisjonsspor når noen spør hvilke filer som kom over. For store opplastingskataloger er trinnvis kopiering med rsync en praktisk måte å bevare filintegriteten på og holde overføringen repeterbar.

Rettigheter fortjener en egen sjekk. Hvis eierskap eller filmoduser endrer seg under flyttingen, kan bildegenerering, skriving til buffer og oppdateringer av utvidelser feile etter lansering. Valider dem eksplisitt:

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

Konfigurer multisite riktig i wp-config.php

Målet må samsvare med nettverksmodellen du migrerer. En liten skrivefeil i wp-config.php kan vise seg som innloggingsløkker, ødelagte informasjonskapsler eller undernettsteder som løses opp til hovednettstedet.

Hvis multisite skal aktiveres på målet, legg til:

define('WP_ALLOW_MULTISITE', true);

Denne konstanten hører hjemme rett før linjen /* That's all, stop editing! Happy publishing. */. Når du har fullført nettverksoppsettet, genererer WordPress resten av multisite-konstantene og omskrivingsreglene basert på underdomene- eller underkatalogmodus. Behold disse genererte verdiene nøyaktig som de er. Å redigere dem for hånd uten grunn er måten fungerende nettverk blir inkonsekvente på.

Hvis du trenger en referanse for installasjonssiden mens du validerer arkitekturvalgene, er denne veiledningen om å installere WordPress Multisite nyttig før du låser konfigurasjonen på målet.

To innstillinger fortjener ekstra granskning under migreringen: domenestrukturen og antakelsene om stier. Hvis kildenettverket brukte underkataloger og målet bygges opp på nytt med underdomener, kan det hende at utvidelsesinnstillinger, omdirigeringslogikk og stier for flerspråklig SEO ikke lenger samsvarer med det som er lagret. Forsiden kan fortsatt lastes mens hreflang-referanser, canonical-tagger og språkspesifikke medie-URL-er brytes.

Updrafts veiledning om å gjøre WordPress om til multisite er også en nyttig påminnelse om at WP_ALLOW_MULTISITE bare er inngangspunktet. I prosjekter der et enkeltnettsted blir et undernettsted, er utvidelsenes tilstand og riktig mål for gjenopprettingen viktig. Gjenoppretting i feil nettstedskontekst kan overskrive feil tabeller eller etterlate undernettstedet konfigurert som en frittstående installasjon.

Velg struktur ut fra driften, ikke preferanse

Både underdomener og underkataloger er gyldige. Riktig valg avhenger av hvordan virksomheten drives.

• Underdomener passer bedre når hvert nettsted behandles som en egen merkevare, et eget land eller en egen juridisk enhet med egen DNS, SSL og egne markedsføringsflyter.
• Underkataloger passer bedre når nettverket fungerer som én publiseringsplattform med delt autoritet og tett beslektet innhold.
• Tilordnede domener øker driftsrisikoen fordi hver tilordnede eiendom gir flere hensyn knyttet til SSL, DNS, omdirigeringer, buffer og tilbakerulling.

Det er også her konflikter rundt utvidelseslisenser kommer til overflaten. Noen premium-utvidelser lisensieres per domene, per miljø eller per aktivt nettsted. Et nettverk som fungerte på kildeserveren, kan etter migreringen plutselig vise deaktiverte funksjoner på tilordnede domener. Sjekk lisensoversiktene før lansering, særlig for utvidelser for SEO, skjemaer, oversettelse og sidebyggere. Slike feil gir ikke alltid en synlig feilmelding. De viser seg som manglende schema-utdata, blokkerte oppdateringer eller administratorvarsler som bare nettverksadministratorer ser.

Her er en nyttig gjennomgang før du ferdigstiller disse innstillingene:

Ikke gå glipp av koden som ligger utenfor temaet

Feil i multisite skyldes ofte kode som aldri lå i det aktive temaet i utgangspunktet.

Sjekk alt det følgende:

• Must-use-utvidelser
• Drop-ins
• Egne cron-skript
• Miljøspesifikke include-filer
• Avhengigheter til omskrivingsregler på serveren

Verifiser også drop-ins for objektbuffer, sunrise-konfigurasjonen hvis domenetilordningen er avhengig av den, og eventuelle symbolske lenker som opprettes ved utrulling. Disse delene støtter ofte autentisering, omdirigeringer, sidebuffer, bildehåndtering og flerspråklig ruting. Hvis én av dem mangler, kan nettverket se funksjonelt ut mens viktige forretningsflyter svikter under belastning eller på sekundære domener.

Behandle flyttingen av filsystemet som en produksjonsutrulling. Kartlegg innholdet, synkroniser i etapper og verifiser først de delene som påvirker inntekter, SEO og tilbakerulling.

Testing etter migreringen og domenetilordning

Migreringen er ikke ferdig når forsiden lastes. Det er åpningstrekket i testingen, ikke avslutningen. Et multisite-nettverk kan se friskt ut ved første øyekast og samtidig skjule ødelagte brukerroller, ugyldige mediestier, feilformede omdirigeringer eller ett tilordnet domene som sender trafikken til feil nettsted.

Den raskeste måten å fange dette på er å behandle valideringen etter migreringen som etterforskningsarbeid. Du beviser ikke at nettstedet lastes. Du prøver å bevise at ingenting kritisk mangler.

Start med systemene som oftest svikter

Delicious Brains rapporterer at feil håndtering av stier til mediefiler er en vanlig fallgruve ved multisite-migreringer og forekommer i omtrent 35 % av manuelle migreringsforsøk, mens automatiserte migreringer med forhåndssjekker kan oppnå 92 % suksess, og manuelle migreringer uten forhåndssjekker feiler i 28 % av tilfellene, ifølge artikkelen om å dele opp en WordPress Multisite og migrere et undernettsted.

Disse tallene stemmer med det team ser i produksjon. Media ryker først fordi det avhenger av stistruktur, rettigheter og korrekte URL-er på én gang.

Begynn med:

• Mediebiblioteker: Åpne gamle innlegg, ikke bare nye. Sjekk fremhevede bilder, gallerier, bilder i teksten og nedlastbare filer.
• Administratortilgang: Verifiser Network Admin, administrasjon av undernettsteder og rollespesifikke innlogginger.
• Kritiske skjemaer og transaksjoner: Test innsending av skjemaer, søk, handlekurver, låst innhold og handlinger som utløses av e-post.
• Utdata fra utvidelser: Gå gjennom alt som skriver egne URL-er, bygger inn skript eller lagrer data i egne tabeller.

Forsiden er den minst nyttige testsiden i en multisite-migrering. Innholdet lenger inn avslører den virkelige skaden.

Gjennomfør en strukturert verifiseringsrunde

En god verifiseringsrunde etter migreringen går fra sjekker på nettverksnivå til sjekker på undernettstedsnivå. Ikke hopp rundt.

Sjekker på nettverksnivå

• Nettstedsregister: Bekreft at hvert forventede undernettsted finnes og rutes riktig.
• Delte brukere: Test en bruker som tilhører flere nettsteder, og verifiser rettighetene vedkommende har på hvert av dem.
• Nettverksutvidelser: Bekreft at nettverksaktiverte utvidelser fortsatt fungerer som tiltenkt.
• Tilgjengelige temaer: Sørg for at aktiverte temaer er synlige der de skal være.

Sjekker på undernettstedsnivå

• Visning i frontend: Gå gjennom forsiden, viktige landingssider, innleggsarkiver og skjemaer.
• Redaktøropplevelse: Åpne blokkredigeringen, medieopplasteren, gjenbrukbare mønstre og egendefinerte felt.
• URL-oppførsel: Sjekk permalenker, paginering og omdirigeringer.
• Lokalisert innhold: Gå gjennom språkspesifikt innhold og navigasjon hvis nettverket er flerspråklig.

En enkel testlogg hjelper teamene med å holde seg ærlige:

Tilordne domener først når nettverket har bestått valideringen

Domenetilordning bør være et av de siste trinnene, ikke en tidlig gjetning. Når det importerte nettverket er stabilt på målet, peker du hver tilordnede eiendom bevisst og validerer responsen nettsted for nettsted.

For SEO-følsomme nettverk henger domenetilordningen også sammen med søkestrukturen. Hvis et flerspråklig undernettsted eller et regionalt domene oppfører seg annerledes etter flyttingen, må du gå gjennom canonical-tagger, alternate-tagger og gjennomsøkingsstier. Dette er særlig relevant for team som har ansvar for SEO for WordPress Multisite, der teknisk ruting og søkesignaler henger tett sammen.

Lagre på nytt og sjekk igjen, men ikke stol bare på det

Ja, å lagre permalenkene på nytt hjelper ofte etter en import. Nei, det er ikke en fullstendig løsning. Det gjenoppretter ikke manglende opplastinger, løser ikke problemer med utvidelseslisenser og retter ikke rolletilordninger som har gått galt.

En moden testrunde er først ferdig når virkelige brukere kan gjøre jobben sin i det nye nettverket. Inntil da er migreringen fortsatt foreløpig.

Planer for tilbakerulling og optimalisering av lanseringen

Klokken 02.07 om natten er DNS-omleggingen aktiv, innloggingen fungerer fortsatt, og forsiden ser fin ut. Ti minutter senere begynner betalt trafikk å havne på feil regionalt nettsted, en premium-utvidelse faller over i prøvemodus på to undernettsteder, og canonical-taggene peker tilbake til det gamle domenet. Det er denne delen av en migrering av WordPress Multisite som vanlige sjekklister undervurderer. Overføringen kan lykkes og lanseringen likevel mislykkes.

Tilbakerulling må være en driftsprosedyre, ikke et vagt løfte om å «gjenopprette sikkerhetskopien». I byråarbeid er forskjellen enkel. En reell plan for tilbakerulling navngir det nøyaktige gjenopprettingspunktet, kommandorekkefølgen, hvem som kan godkjenne reverseringen, hvem som endrer DNS, og hvilke forhold som utløser beslutningen. Uten det bruker teamene 30 til 60 minutter på å diskutere mens brukere og søkeroboter fortsetter å treffe en ødelagt stakk.

Skriv planen slik at vakthavende utvikler kan kjøre den i halvsøvne. Hold den kort og konkret:

1. Utgivelsesidentifikator knyttet til den endelige databasedumpen og øyeblikksbildet av filene
2. Gjenopprettingskommandoer for databasen og opplastingene
3. Ansvarlig for å reversere DNS og tilgangsvei til registrar eller CDN
4. Notater om gjenoppretting av utvidelseslisenser for alt som er knyttet til domene, IP-adresse eller miljø
5. Forretningsmessig utløser for tilbakerulling, for eksempel feil i kassen, administratorer som er låst ute eller rutingfeil på tvers av domener
6. Validering etter tilbakerullingen for de få funksjonene som betyr mest først

Hvis måldatabasen for eksempel allerede er lastet inn og du må reversere raskt, bør runbooken inneholde de nøyaktige kommandoene, ikke en henvisning til «sikkerhetskopien i S3»:

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

Hvis objektbuffer eller Redis er i bruk, legg til den kommandoen også. Hvis edge-laget ditt håndterer omdirigeringer, noter om tilbakerullingen omfatter å deaktivere page rules eller origin-overstyringer. Jeg har sett teknisk korrekte databasegjenopprettinger mislykkes fordi Cloudflare, Route 53 eller en lastbalanserer fortsatte å levere den nye originen.

DNS er som regel den tregeste delen av en reversering, og derfor starter optimaliseringen av lanseringen før lanseringskvelden. Korte TTL-verdier hjelper, men de garanterer ikke umiddelbar korrigering. Noen resolvere ignorerer dem. Noen klienter sitter bak aggressiv bufring. Planlegg for en periode med blandet trafikk der en del av publikummet ser den gamle stakken og en del den nye.

Denne virkeligheten endrer hvordan du lanserer. Frys innholdet før omleggingen. Sett bestillinger eller redaksjonelle endringer i kø hvis virksomheten tåler det. Hvis den ikke gjør det, trenger du en avstemmingsplan for kommentarer, skjemaer, handelsdata og brukerregistreringer som opprettes i overlappingsvinduet.

Flerspråklig SEO trenger sin egen terskel for tilbakerulling. I praksis er dette et av de enkleste stedene å overse forretningsrisiko, fordi siden vises normalt. De skjulte feilene ligger i canonical-tagger, hreflang-par, regionale omdirigeringer, oversatte slugs, XML-nettstedskart og markedsvelgere. Vår erfaring er at migrerte multisite-eiendommer ofte mister noen av disse signalene under utskillelse eller ny domenetilordning, særlig når SEO-utvidelser lagrer innstillinger på et annet nivå enn teamet forventet.

Sjekk disse punktene rett etter omleggingen:

• Canonical-tagger på de viktigste malene og landingssidene
• Hreflang-par for hver språk- eller markedsvariant
• Lokaliserte URL-strukturer som /de/ eller landsspesifikke underdomener
• Nettstedskart generert av den aktive SEO-utvidelsen på målet
• Omdirigeringsoppførsel fra eldre regionale URL-er
• Indekseringskontroller, slik at noindex-regler fra staging ikke fulgte med inn i lanseringen

Utvidelseslisenser fortjener like mye oppmerksomhet. Team i større virksomheter blir tatt på senga her fordi utvidelsen fungerte i det gamle nettverket og så svikter på det utskilte nettstedet eller det nye domenet. Feilen er sjelden dramatisk. Ofte er det en manglende feltgruppe, deaktivert levering av skjemaer, en blokkert oppdateringskanal eller et banner som blir til ødelagt utdata når bufferen utløper. Hvis en utvidelsesleverandør knytter lisensen til det opprinnelige nettverket, ta med de manuelle aktiveringstrinnene i lanseringens runbook og bestem om den situasjonen er en utløser for tilbakerulling eller en kjent oppgave etter lanseringen.

Optimaliseringen av lanseringen kommer etter stabilitetssjekkene, ikke før. Tøm bufferlagene. Varm opp sidene som betyr noe. Gå gjennom PHP-logger, webserverlogger, omdirigeringskjeder, cron-hendelser og transaksjonsbasert e-post. Test deretter de kommersielle flytene under reelle forhold: innloggede økter, språkbytte, innsending av skjemaer, søk, kasse og eventuelle callbacks fra tredjeparter.

Bruk WP-CLI til oppryddingen som skal kunne gjentas:

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

Den siste kommandoen er kraftig og farlig. I multisite bør du kjøre den først etter at du har bekreftet måldomenene, de tilordnede vertene og omfanget av serialiserte data. En feilaktig erstatning i hele nettverket er måten å skape et nytt avbrudd på mens du prøver å rette det første.

En sterk lansering er kjedelig på best mulig måte. Brukerne fortsetter å jobbe. Søkesignalene forblir intakte. Lisensierte utvidelser fortsetter å validere. Og hvis noe av dette ryker så hardt at det truer inntekter eller drift, skjer tilbakerullingen raskt fordi teamet allerede har valgt utløseren, den ansvarlige og de nøyaktige kommandoene.

Avanserte scenarioer og viktige spørsmål og svar

Fredag kl. 17.30: databaseimporten er ferdig, opplastingene er på plass, og undernettstedet lastes. Så forsvinner oversettelser fra hreflang-taggene, en skjemautvidelse faller over i prøvemodus, og SEO-teamet oppdager at canonical-taggene nå peker til det gamle nettverksdomenet. Det er denne delen standardveiledninger for multisite-migrering som regel går glipp av.

De kostbare feilene ved migrering av WordPress Multisite oppstår etter at filene og tabellene er flyttet. Utvidelseslisenser kan slutte å fungere når et undernettsted forlater et nettverk. Flerspråklige utvidelser kan fortsette å vise sider mens de mister koblingene mellom språkene eller metadataene. En plan for tilbakerulling som så fin ut på papiret, kan falle fra hverandre hvis reaktivering av lisenser, DNS-timing eller callbacks fra tredjeparter aldri ble testet.

Utvidelseslisenser er en driftsrisiko, ikke en oppryddingsoppgave

Diskusjoner i supportforumet om multisite-migrering på WordPress.org peker gjentatte ganger på ødelagte utvidelser som et vanlig problem etter migrering, ofte knyttet til lisenser, manglende multisite-tillegg eller nettverksspesifikke innstillinger. Behandle det som en arbeidsstrøm før lansering, ikke som en overraskelse etterpå.

En premium-utvidelse kan oppføre seg korrekt i et nettverk og svikte i det øyeblikket et nettsted blir frittstående. Jeg ser dette oftest med domenebundne lisenser, utvidelser som lagrer tilstanden i wp_sitemeta i stedet for i innstillinger per nettsted, og leverandører som selger multisite-støtte som en egen rettighet.

Sjekk disse punktene før du godkjenner omleggingen:

• Støtter utvidelsen både multisite- og frittstående installasjoner?
• Er den nåværende lisensen gyldig for måldomenet?
• Ligger aktiveringsdataene i nettverksinnstillinger, nettstedsinnstillinger, egne tabeller eller et eksternt API?
• Kan utvidelsen reaktiveres via CLI eller bare via wp-admin?
• Hvis lisensen svikter, mister nettstedet funksjoner, mister det oppdateringer, eller slutter det å vise kritisk innhold?

Hvis leverandøren ikke kan svare tydelig på disse spørsmålene, planlegg for manuell utbedring og bestem om en feil i utvidelsen skal stoppe lanseringen.

Du kan raskt sjekke omfanget av innstillingene 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å utskilte undernettsteder bør du også sammenligne utvidelsesspesifikke tabeller. Noen utvidelser lagrer lisenser, språkkoblinger eller køstatus utenfor de vanlige innstillingene.

Flerspråklig SEO ryker i det stille

Et flerspråklig undernettsted kan se fint ut for redaktørene og likevel miste søkeverdi etter migreringen. De vanlige feilene er feil canonical-tagger, manglende hreflang-tagger, ødelagte oversatte URL-slugs og språkvelgere som peker til gamle verter. Derfor hører flerspråklig validering hjemme i lanseringssjekklisten, ikke bare i den generelle kvalitetssikringen.

For WPML, Polylang eller egne flerspråklige oppsett bør du verifisere alt det følgende på det migrerte nettstedet:

• Canonical-tagger peker til riktig domene i produksjon
• Hreflang-tagger viser til riktige språkvarianter
• Oversatte sider er fortsatt koblet til hverandre
• XML-nettstedskart inneholder alle språk og riktige vertsnavn
• Omdirigeringsregler bevarer gamle språkstier og spørringsparametere der det trengs

Ikke stol på en sjekk av forsiden. Test dype URL-er, paginerte arkiver og sidene som skaper inntekter.

Tre viktige spørsmål og svar

Kan man migrere et enkeltnettsted inn i et eksisterende multisite-nettverk?
Ja, men opprett målundernettstedet først og gjenopprett i riktig blog ID-kontekst. Hvis du importerer data mot feil nettsteds-ID, kan opplastingsstier, brukerroller og utvidelsesinnstillinger knyttes til feil tabeller. Sjekk målet før importen med:

wp site list
wp db tables | grep _2_

Erstatt _2_ med den faktiske blog ID-en du regner med å bruke.

Kan man skille ut et undernettsted til sin egen frittstående WordPress-installasjon?
Ja. Selve overføringen er vanligvis enkel. Risikoen ligger i alt rundt den: omskriving av mediestier, planlagte jobber, lisensierte utvidelser og SEO-signaler som tidligere ble håndtert på nettverksnivå. I virkelige prosjekter er det i utskillelsen at forretningskontinuiteten blir satt på prøve.

Hva med brukere og rettigheter?
Brukere er globale i multisite. Roller er det ikke. Bekreft rettighetene på målnettstedet etter migreringen, særlig for redaktører, butikkansvarlige og alle kontoer som er integrert med SSO. Hvis det opprinnelige nettverket delte brukere på tvers av eiendommer, verifiser om disse brukerne i det hele tatt skal finnes på det utskilte nettstedet.

Spørsmålet ingen stiller tidlig nok

Hva er den raskeste trygge tilbakerullingen hvis det migrerte nettstedet er i produksjon og inntektsflytene begynner å svikte?
Bruk en tilbakerulling som gjenoppretter den siste databasen man vet fungerte, sender trafikken tilbake til det gamle miljøet og inkluderer eventuelle leverandørtrinn som trengs for å validere lisenser på nytt eller aktivere flerspråklige tjenester igjen. Hvis tilbakerullingen din er avhengig av at folk finner ut av ting under et avbrudd, er det ikke en plan for tilbakerulling.

Ha en skriftlig rekkefølge med navngitte ansvarlige, antakelser om DNS-TTL og nøyaktige gjenopprettingskommandoer. For eksempel:

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

Kjør dette bare i miljøet du har tenkt å gjenopprette. I multisite kan en uforsiktig search-replace gjøre avbruddet større.

Den vanskelige delen av en multisite-migrering er å bevare forretningsdriften under press. Dataoverføringen er bare ett lag. Lisenser, flerspråklig SEO og disiplin rundt tilbakerulling er det som hindrer at flyttingen blir en hendelse som rammer inntektene.

Hvis teamet ditt trenger erfarne folk til en multisite-flytting med høy risiko, er IMADO den typen utviklingspartner det lønner seg å hente inn tidlig. IMADO håndterer delene som vanligvis undervurderes, blant annet flerspråklig arkitektur, kompleksitet i multisite, ytelse og lanseringsdisiplin, uten å gjøre prosjektet til en generisk «nettstedsflytting».