Flytta WordPress till nytt webbhotell utan att sajten går sönder

Att flytta en WordPress-sajt borde vara okomplicerat, men i praktiken är det precis här saker börjar gå snett. Filerna och databasen är en sak. Det WordPress-specifika är en annan.

Det generella är enkelt, men det WordPress-specifika är fällan

Den grundläggande principen för att flytta en webbplats brukar sammanfattas med fyra steg: ta backup, kopiera filer, flytta databasen och byt DNS. Om du letar efter det generella upplägget utan WordPress-specifika detaljer finns svaret i vår guide om hur du flyttar en webbplats generellt. WordPress lägger dock ett extra lager av komplexitet ovanpå det. Till skillnad från en statisk HTML-sajt innehåller din WordPress-databas dynamiska referenser till din domän och dina serversökvägar, inbakade på dussintals ställen i ett format som inte tolererar naiv textersättning. Det formatet heter serialisering (engelska: serialization), och det är den vanligaste orsaken till att WordPress-flytt går fel trots att man trodde att allt var gjort rätt.

Väljer du dessutom ett webbhotell optimerat för WordPress från start brukar processen gå smidigare, men oavsett destination gäller samma tekniska regler.

Varför en enkel sök-och-ersätt förstör din WordPress-databas

Serialisering är orsaken till att genvägen via phpMyAdmin konsekvent slår tillbaka, och det är värt att förstå mekanismen innan du väljer verktyg.

Hur PHP-serialisering fungerar

När PHP lagrar komplexa datastrukturer (arrayer, objekt) i databasen omvandlar det dem till en komprimerad textsträng med ett specifikt format. Det avgörande är längdprefixet: varje sträng föregås av ett prefix som talar om exakt hur många tecken strängen innehåller. Ta det här exemplet, där en URL lagras som en del av en serialiserad array:

s:23:"https://gamladomain.se";

Här betyder s:23 att det följer en sträng (s) med exakt 23 tecken. Räkna efter: https://gamladomain.se är just 23 tecken. Nu byter du domän till en kortare adress och kör en rå SQL-ersättning:

-- Det som råSQL gör (FEL):
s:23:"https://nydomain.se";

Längdprefixet säger fortfarande 23, men den nya strängen https://nydomain.se är bara 20 tecken. När PHP sedan försöker läsa tillbaka värdet ur databasen förväntar det sig 23 tecken, hittar inte avgränsaren på rätt plats och kan inte tolka strukturen. Resultatet är korrupt data.

Ett korrekt verktyg hanterar exakt detta: det avserialiserar strängen, ersätter URL:en, räknar den nya längden och reserialiserar med uppdaterat prefix:

-- Vad rätt verktyg producerar (RÄTT):
s:20:"https://nydomain.se";

En siffra fel och PHP kan inte tolka strukturen alls.

Var i din databas sitter serialiserad data

Serialiserad data dyker upp på tre platser i en standardinstallation:

• wp_options: temainställningar, widgetkonfigurationer, plugin-preferenser, cron-scheman och temaval lagras här i serialiserat format.
• wp_postmeta: alla custom fields, SEO-plugin-data (Yoast, Rank Math), sidbyggarstrukturer och ACF-fält bor i denna tabell. Det är ofta den tätaste källan till serialiserad data.
• wp_usermeta: användarinställningar och roller kan också lagras serialiserat.

Sidbyggare som Elementor, Divi och Beaver Builder är värst drabbade. De lagrar hela sidlayouter, bakgrundsbilder, knapptexter och animationsinställningar i serialiserade strukturer i wp_postmeta. En sajt byggd med Elementor kan ha tusentals rader serialiserad data med URL-referenser. Konsekvenserna av korrupt serialisering syns inte alltid tydligt: vita skärmar, widget-layouts som faller sönder, menyer som försvinner, eller templates som ser normala ut men saknar all dynamisk data.

Varför phpMyAdmin:s sök-och-ersätt är fel verktyg

phpMyAdmin har visserligen en sök-och-ersätt-funktion, och det ger intrycket av att det borde fungera. Gör det inte. Verktyget hanterar ingen serialisering alls; det är en ren textersättning precis som att använda SQL:s REPLACE()-funktion direkt. För vanlig brödtext i post_content (dina blogginlägg) kan en enkel textersättning ibland klara sig om inga serialiserade strukturer är inblandade. Men wp_options och wp_postmeta, där merparten av dina URL-referenser faktiskt sitter, innehåller nästan alltid serialiserad data. Att köra phpMyAdmin-ersättning på dem är att garanterat skada databasen.

Att bara byta siteurl och home i wp_options räcker inte på långa vägar. WordPress officiella migrationsguide är tydlig med att ett fullständigt verktyg för URL-ersättning krävs.

Rätt verktyg för URL-bytet, tre alternativ rangordnade

Det finns tre etablerade vägar, alla med korrekt serialiseringshantering. Vilket du väljer beror på om du har SSH-tillgång och hur bekväm du är med kommandorad.

WP-CLI search-replace är det tekniskt renaste alternativet. Kommandot avserialiserar automatiskt, ersätter och reserialiserar med korrekta längdprefix. Kör alltid --dry-run som ett försteg för att se vad som skulle ändras utan att faktiskt skriva till databasen. Flaggan --recurse-objects är aktiv som standard och ser till att nästlade objekt också hanteras. De flesta svenska webbhotell med cPanel eller DirectAdmin erbjuder SSH-tillgång; verifiera med din hostpanel om du är osäker. Dokumentationen finns på developer.wordpress.org/cli/commands/search-replace/.

Better Search Replace (installeras som ett vanligt plugin) hanterar serialisering i bakgrunden utan att du behöver tänka på det. Kör alltid "Dry Run" i gränssnittet innan du verkställer. Gratisversionen klarar de flesta vanliga sajter. Premiumversionen lägger till stöd för multisite och mer avancerade ersättningar, men det saknas sällan vid en vanlig flytt.

WP Migrate (tidigare WP Migrate DB) kombinerar export, URL-ersättning och import i ett flöde, vilket minskar antalet manuella steg. Gratisversionen har begränsningar vad gäller push/pull-funktionalitet, men export med inbyggd URL-ersättning fungerar bra för de flesta flytt-scenarion.

Ett fjärde alternativ som nämns i sammanhang är interconnect/it Search Replace DB, ett fristående PHP-skript. Det hanterar serialisering korrekt, men kräver att du lägger upp skriptet på servern och sedan omedelbart tar bort det efteråt. Säkerhetsrisken om du glömmer är inte försumbar; föredra ovanstående alternativ om du inte har starka skäl.

Välj din migreringsmetod med eskaleringskedjan som guide

Rätt metod beror på sajtens storlek, din tekniska komfortnivå och om du har SSH-tillgång. Börja på den enklaste nivån och eskalera om begränsningarna biter.

Nivå 1: Migrerings-plugin (de flesta klarar sig här)

Plugin-lösningar som All-in-One WP Migration, Duplicator och Migrate Guru sköter filer, databas och URL-ersättning i ett paket. Du behöver varken SSH-tillgång eller att röra en databasfil manuellt. För sajter under gratispluginet storlek-gräns (kontrollera aktuell gräns i respektive plugins dokumentation, den ändras) är det enklaste och snabbaste alternativet. Misslyckas importen tyst utan felmeddelande är det nästan alltid ett storleksproblem.

Nivå 2: Manuell flytt med rätt search-replace-verktyg

Är sajten för stor för ett plugin, eller vill du ha mer kontroll, är manuell flytt rätt väg. Flödet ser ut så här: exportera databasen via phpMyAdmin eller wp db export (om WP-CLI finns), kopiera alla filer via FTP eller SFTP (inkl. dolda filer som .htaccess), skapa en ny databas på nya hosten och importera, uppdatera wp-config.php med nya credentials, och kör därefter URL-ersättning med WP-CLI, Better Search Replace eller WP Migrate.

Nivå 3: Hostens migreringstjänst

Många svenska webbhotell erbjuder migrering, ibland gratis och ibland till en engångskostnad. Det är bekvämt, men ställ konkreta frågor innan du tackar ja. Fråga specifikt om de hanterar serialiserad data och URL-ersättning, eller om det handlar om en ren filkopia. En ren filkopia utan URL-fix lämnar dig med exakt samma problem att lösa efteråt.

När databasen är för stor för phpMyAdmin

phpMyAdmin har en importgräns som styrs av PHP-inställningar (upload_max_filesize, post_max_size, max_execution_time). Gränsen varierar per host; kolla i phpMyAdmins startsida eller via din hostpanels PHP-konfiguration. Är databasen för stor finns tre alternativ: importera via SSH med mysql -u anvandarnamn -p databasnamn < dump.sql, använd BigDump (ett PHP-skript för uppdelad import) eller dela upp dumpfilen manuellt.

wp-config.php och hårdkodade sökvägar som folk glömmer

Databasen är inte det enda stället där din gamla hosts uppgifter lever kvar. wp-config.php och ett antal konfigurationsfiler innehåller referenser som måste uppdateras manuellt.

wp-config.php på nya hosten

Den enklaste lösningen är att öppna den befintliga wp-config.php och uppdatera de fyra databasuppgifterna till vad den nya hosten angett, ofta i välkomstmejlet eller i cPanel/DirectAdmin:

• DB_NAME: databasens namn på nya hosten
• DB_USER: databasanvändaren
• DB_PASSWORD: lösenordet
• DB_HOST: varierar per host. Vanligast är localhost, men det kan vara en IP-adress eller en socket-sökväg. Fabricera inte ett värde här; hämta det från hostens dokumentation.

En vanlig källa till förvirring är konstanter direkt i wp-config.php:

define('WP_SITEURL', 'https://gamladomain.se');
define('WP_HOME', 'https://gamladomain.se');

Dessa konstanter överstyr wp_options. Det innebär att även om du kört ett perfekt URL-byte i databasen så pekar WordPress fortfarande på den gamla domänen om dessa rader finns kvar. Sök igenom wp-config.php och eventuellt functions.php efter hårdkodade URL:er. Mer om wp-config.php och alla tillgängliga konstanter finns i WordPress officiella wp-config-dokumentation.

Övriga saker att kontrollera efter en flytt:

• .htaccess: WordPress rewrite-regler måste finnas på nya hosten. Filen är dold (börjar med punkt) och kan förbises vid FTP-kopiering. Regenerera vid behov via Inställningar och Permalänkar.
• Filrättigheter: mappen wp-content/uploads/ och cachekatalogerna måste vara skrivbara av webbservern. Katalogerna bör ha 755, filer 644. Symptom på felaktiga rättigheter är att bilder inte kan laddas upp.
• Säkerhetsnycklar: du behöver inte ändra dem vid en flytt, men gamla inloggningssessioner ogiltigförklaras. Befintliga användare måste logga in igen.

Testa på nya hosten INNAN du byter DNS

Att byta DNS innan du vet att sajten fungerar på nya hosten är onödigt riskabelt. Peka istället om din lokala dator mot nya serverns IP-adress via hosts-filen, utan att beröra DNS alls.

Du hittar nya serverns IP i hostpanelen eller välkomstmejlet. Redigera sedan hosts-filen:

• Windows: C:\Windows\System32\drivers\etc\hosts (kräver administratörsbehörighet)
• Mac/Linux: /etc/hosts

Lägg till en rad: 123.456.789.10 dindomän.se. Din webbläsare besöker nu nya servern när du skriver in din domän, medan resten av världen fortfarande ser gamla hosten.

Kontrollera åtminstone dessa punkter innan du är nöjd:

1. Startsidan laddar korrekt med alla bilder
2. En undersida (blogginlägg, produktsida) fungerar utan 404
3. WP-admin-inloggning fungerar och dashboarden ser normal ut
4. HTTPS fungerar och certifikatet är giltigt
5. Ladda upp en testbild i Mediebiblioteket
6. Fyll i och skicka ett kontaktformulär om sådant finns

Kontrollera dessutom mixed content: om sajten kör HTTPS men har hårdkodade http://-URL:er till bilder eller skript flaggar webbläsaren det som osäkert innehåll. DevTools-konsolen (F12) visar mixade-innehåll-varningar. Åtgärden är ett separat search-replace-körning för http://dindomän.se till https://dindomän.se, eller ett plugin som Really Simple SSL som hanterar det automatiskt.

Flusha alltid permalänkarna (Inställningar och Permalänkar och Spara) direkt efter import. WordPress lagrar sina rewrite-regler cachade; utan flush-steget får du 404 på nästan alla undersidor trots att allt annat är rätt. Har du plugin-licenser bundna till en domän eller IP-adress (som många premium-plugins har), avaktivera dem på gamla hosten och återaktivera på nya.

Vill du testa mer grundligt utan att röra produktionsmiljön är en staging-miljö ett alternativ att överväga, särskilt för komplexa sajter med betallösningar.

Byt DNS sist, och förstå vad som händer under propagering

DNS är det sista steget, inte det första. Verifiera att sajten fungerar på nya hosten via hosts-filen, och byt sedan DNS med god marginal mot eventuella problem.

Sänk TTL-värdet (Time to Live, ungefär hur länge DNS-svar cachas hos mellanhänder) till 300-600 sekunder ett dygn i förväg om möjligt. Det gör att ändringen sprids snabbare och eventuell rollback går fortare. Propagering tar i praktiken ofta bara minuter till några timmar, men officiellt kan det ta upp till 48 timmar. Håll gamla hosten aktiv och sajten tillgänglig under minst 48-72 timmar som försäkring mot rollback. För en fullständig genomgång av vilka poster som ska ändras, se vår DNS-checklista för byte av webbhotell.

Har du e-post kopplad till domänen måste MX-posterna hanteras separat och samordnas med flytten. Byter du dem i fel ordning riskerar du att tappa inkommande mejl under övergången. Mer om det i guiden om att flytta din e-post utan mejlförlust.

Symptom, orsak och åtgärd: felsöka en dålig WordPress-flytt

De flesta problem som uppstår efter en WordPress-flytt är reparerbara på plats. Tabellen nedan sammanfattar de vanligaste symptomen och vad de pekar på.

Vit skärm och databasfel är de mest alarmanta men oftast också de enklaste att diagnostisera. Aktivera WP_DEBUG temporärt i wp-config.php för att se felmeddelanden i klartext istället för en blank sida. Stäng av debug igen när problemet är löst.

Visar det sig att sökmotorsynligheten försvann beror det nästan alltid på inställningen under Inställningar och Läsning, inte på att Google avindexerade sajten. Wordpress har ett kryssruteläge avsett för testmiljöer som blockerar crawlning, och det är lätt att glömma att avmarkera det.

Checklista för en säker WordPress-flytt

Gå igenom punkterna i ordning. De flesta misstag vid WordPress-flytt beror på steg som hoppas över under tidspress. Är sajten på plats och fungerar är nästa steg att se till att den också är snabb, vilket vi går igenom i guiden om hur du optimerar WordPress laddtid.

Förberedelse

• Ta backup av samtliga filer OCH databasen separat (inte bara ett migrations-plugin-paket)
• Notera vilken PHP-version gamla hosten kör och verifiera att nya hosten matchar eller är kompatibel
• Sänk TTL för domänens DNS-poster till 300-600 sekunder
• Kontrollera om du har SSH-tillgång på nya hosten (avgör val av URL-ersättningsverktyg)
• Gå igenom plugin-licensvillkor och notera vilka som kräver avaktivering på gamla hosten

Under flytt

• Exportera databasen (phpMyAdmin eller wp db export)
• Kopiera alla filer via FTP/SFTP, inklusive dolda filer som .htaccess
• Skapa ny databas och databasanvändare på nya hosten
• Importera databas-dumpen
• Uppdatera wp-config.php med nya DB_NAME, DB_USER, DB_PASSWORD och DB_HOST
• Kontrollera att inga WP_SITEURL/WP_HOME-konstanter i wp-config.php pekar på gamla domänen
• Kör URL-ersättning med WP-CLI (--dry-run först), Better Search Replace eller WP Migrate
• Peka om lokala hosts-filen mot nya serverns IP och verifiera sajten
• Flusha permalänkar (Inställningar och Permalänkar och Spara)
• Kontrollera filrättigheter på wp-content/uploads/ och cache-kataloger

Efter DNS-byte

• Rensa plugin-cacher, CDN-cacher och webbläsarcachen
• Verifiera HTTPS och kontrollera att inga mixed content-varningar dyker upp
• Bekräfta att sökmotorindexering inte är blockerad (Inställningar och Läsning)
• Avaktivera plugin-licenser på gamla hosten och återaktivera på nya
• Håll gamla webbhotellskontot aktivt i minst 48-72 timmar som rollback-möjlighet
• Bekräfta att e-post (MX-poster) fungerar korrekt om e-post bor på samma host