Du har flyttat en sajt till en ny domän, och den ligger nere. Eller så öppnas den, men utan stilmallar. Eller så släpper adminpanelen inte in dig. Alla som har migrerat WordPress manuellt har varit med om det här ögonblicket: databasen minns fortfarande den gamla webbadressen, och sajten försöker frenetiskt ladda resurser från en adress som inte längre finns.

Fyra SQL-frågor i phpMyAdmin löser problemet på fem minuter. Inga tillägg, ingen WP-CLI, ingen panik. Här följer en steg-för-steg-guide från att hitta den aktuella domänen till den slutliga kontrollen. Med anpassningar för icke-standardiserade tabellprefix, HTTPS och serialiserad data.

💡 Snabb överblick:

• Hitta den aktuella domänen i tabellen wp_options: fälten siteurl och home
• Kör fyra UPDATE-frågor på SQL-fliken i phpMyAdmin
• Återställ administratörslösenordet via wp_users om adminpanelen inte släpper in dig
• Spara permalänkarna i WordPress-inställningarna för att återställa stilmallarna
• För butiker och multisajter, använd Better Search Replace eller WP-CLI: en vanlig REPLACE förstör serialiserade arrayer

Var du ska börja: hitta den aktuella domänen i databasen

Innan du byter ut, se till att du vet vilken domän som för närvarande är inställd för sajten. Det sparar tid om sajten har flyttats tidigare och en tredje, "mellanliggande" webbadress kan finnas kvar i databasen.

Öppna phpMyAdmin, välj sajtens databas och leta upp tabellen wp_options. Den innehåller två rader: siteurl (WordPress-adressen) och home (sajtadressen). Det är dessa värden vi ändrar först.

Om tabellprefixet inte är standard (till exempel mysite_ istället för wp_), leta efter tabellen mysite_options. Du hittar prefixet i filen wp-config.php: variabeln $table_prefix.

Fyra SQL-frågor för ett komplett domänbyte

Kör varje fråga en i taget på fliken "SQL" i phpMyAdmin. Innan du kör dem, se till att säkerhetskopiera databasen: export via phpMyAdmin tar en minut och räddar dig från oåterkalleliga misstag.

Ersätt http://www.oldurl med http://www.newurl i alla frågor nedan. Om sajten körs på HTTPS, använd https:// i båda adresserna.

1. Uppdatera HOME och SITEURL

Detta ändrar de två nyckeladresserna i wp_options. Utan det här steget öppnas sajten helt enkelt inte på den nya domänen; WordPress kommer att fortsätta försöka omdirigera till den gamla.

1
UPDATE wp_options SET option_value = replace(option_value, 'http://www.oldurl', 'http://www.newurl') WHERE option_name = 'home' OR option_name = 'siteurl';

2. Uppdatera inläggens GUID

Fältet guid i wp_posts lagrar den permanenta identifieraren för varje inlägg. Att ersätta det är inte kritiskt för sajtens drift; WordPress använder inte GUID för routning. Men om folk läser din sajt via RSS-läsare spelar GUID-hygienen roll: gamla webbadresser i flödet leder till trasiga länkar.

1
UPDATE wp_posts SET guid = replace(guid, 'http://www.oldurl', 'http://www.newurl');

3. Uppdatera inläggsinnehåll

Den mest omfattande frågan. post_content innehåller texten för alla sidor och inlägg, inklusive inbäddade bilder och interna länkar. När denna har körts kommer alla bilder i innehållet att laddas från den nya domänen.

1
UPDATE wp_posts SET post_content = replace(post_content, 'http://www.oldurl', 'http://www.newurl');

4. Uppdatera metafält

Anpassade fält, tilläggsinställningar, temadata: allt detta lagras i wp_postmeta. Hoppa över den här frågan så får du trasiga länkar på till synes oväntade ställen: logotypen i sidfoten, bakgrunden i anpassaren, webbadressen i ditt SEO-tillägg.

1
UPDATE wp_postmeta SET meta_value = replace(meta_value, 'http://www.oldurl', 'http://www.newurl');

När du har kört alla fyra frågorna öppnar du sajten på den nya domänen. Om allt gjordes korrekt borde det inte vara några problem. Men ibland händer något annat: ett meddelande om "Error establishing a database connection" eller så öppnas sidan utan stilmallar.

Det första du behöver i den här situationen är tillgång till adminpanelen.

Så får du tillgång till adminpanelen om lösenordet är borttappat eller sajten inte släpper in dig

Kunden lämnade inget lösenord. Eller så låste du ut dig själv genom att byta domän, och /wp-admin kastar dig in i en oändlig omdirigering. Här är två sätt att få administratörsrättigheter direkt via databasen.

Återställa administratörslösenordet via phpMyAdmin

Öppna tabellen wp_users (ditt prefix kan skilja sig: mysite_users osv.). Hitta användaren med administratörsrättigheter och klicka på "Redigera":

I raden user_pass, välj funktionen MD5 från rullgardinsmenyn och ange det nya lösenordet i det intilliggande fältet. Klicka på "Kör":

Obs: modern WordPress använder phpass (bcrypt-hashar), inte MD5. Men när du anger ett WordPress-lösenord kontrolleras hashen i sekvens: om bcrypt-kontrollen misslyckas provas MD5-fallbacken och lösenordet hashas omedelbart om till det aktuella formatet. Det är därför MD5 via phpMyAdmin fungerar som en tillfällig nyckel.

Skapa en administratör via PHP

En alternativ metod är att lägga till en ny administratörsanvändare programmatiskt. Koden infogas i det aktiva temats functions.php eller via ett MU-plugin.

Lägg till följande i ditt barntemas functions.php:

1
function sdstudio_add_admin_user() {
2
    $userdata = array(
3
        'user_login' => 'tempadmin',
4
        'user_pass'  => 'TempPass123!',
5
        'user_email' => '[email protected]',
6
        'role'       => 'administrator',
7
    );
8
    wp_insert_user( $userdata );
9
}
10
add_action( 'init', 'sdstudio_add_admin_user' );

Funktionen wp_insert_user() skapar en användare med de angivna parametrarna, och init-hooken körs vid varje WordPress-anrop. Öppna bara valfri sida på webbplatsen en gång, så skapas användaren.

När du har loggat in i adminpanelen, se till att ta bort både funktionen från functions.php och den tillfälliga användaren du skapade. Att lämna kvar tempadmin med ett lösenord i klartext är en säkerhetsrisk.

Åtgärda trasiga bilder och stilar efter domänbyte

Du har tillgång till adminpanelen, men bilder laddas inte och layouten är trasig. I nio fall av tio hjälper en enkel åtgärd.

Gå till "Inställningar" → "Permalänkar":

Ändra ingenting; klicka bara på "Spara ändringar":

WordPress bygger om URL-strukturen, uppdaterar cachen för omskrivningsregler och rensar den interna omdirigeringscachen. Efter detta brukar bilderna hamna på plats igen.

Om det inte hjälpte betyder det att den gamla domänen är inbäddad i serialiserade arrayer. En vanlig REPLACE i SQL förstör dem: stränglängden i en serialiserad array är hårdkodad som ett nummer, och att ersätta "old-long-domain.ru" med "new-short.io" ändrar den längden, vilket gör arrayen oläsbar. Installera det kostnadsfria pluginet Better Search Replace; det hanterar serialisering korrekt och visar hur många träffar som hittades i varje tabell innan det ersätter.

För webbplatser med WP-CLI är det ännu enklare med ett kommando:

1
wp search-replace 'http://olddomain.ru' 'https://newdomain.io' --all-tables --dry-run

Flaggan --dry-run visar först vad som kommer att ersättas utan att göra några ändringar. När du är säker kör du det utan flaggan. WP-CLI search-replace hanterar också serialiserad data och gör det snabbare än webbgränssnittet.

Videon nedan demonstrerar hela processen från inloggning i phpMyAdmin till kontroll av webbplatsen efter ersättningen:

⁉️🤔 Vanliga frågor

Är det obligatoriskt att använda phpMyAdmin för domänbyte?

Nej. Om sajten inte har flyttats ännu gör Duplicator eller All-in-One WP Migration ersättningen automatiskt vid driftsättning. Om sajten redan ligger på det nya webbhotellet utan adminåtkomst återstår SQL-frågor via phpMyAdmin, Adminer eller WP-CLI. För de flesta webbansvariga är phpMyAdmin den mest direkta och kontrollerade metoden: du ser varje operation istället för att lita på ett plugins svarta låda.

Vad ska jag göra om tabellprefixet inte är wp_?

Kontrollera konstanten $table_prefix i wp-config.php. Vanligtvis är den wp_, men webbhotell eller säkerhetsplugins som Solid Security (tidigare iThemes Security) ändrar den ibland till något slumpmässigt. I alla frågor ovan byter du ut wp_ mot ditt prefix (till exempel xyz123_options istället för wp_options).

Varför öppnas sajten utan stilmallar efter ersättningen?

Den gamla domänen finns kvar i temainställningar, cache eller CDN. Återställ permalänkar (instruktioner ovan) och rensa cacheminnet i ditt cachingplugin. Om du använder Cloudflare eller ett annat CDN, ogiltigförklara cachen på leverantörens sida. Om det inte hjälpte, kör Better Search Replace: den gamla URL:en är troligen inbäddad i en serialiserad theme_mods_*-array.

Sajten ligger på HTTPS, men efter flytten fungerar inte certifikatet. Vad ska jag göra?

Se till att du använde https:// (inte http://) i alla frågor. Kontrollera att båda adresserna i WordPress-inställningarna efter inloggning i adminpanelen börjar med https://. Själva SSL-certifikatet konfigureras på webbhotellets sida, via kontrollpanelen eller gratis Let's Encrypt. Det är en separat procedur som inte har med databasen att göra.

Kan jag ersätta domänen utan tillgång till phpMyAdmin?

Ja. WP-CLI: wp search-replace 'http://olddomain' 'http://newdomain' --all-tables. Enbart FTP: lägg till raderna define('WP_HOME','http://newdomain'); och define('WP_SITEURL','http://newdomain'); i wp-config.php. Detta åsidosätter adresserna tillfälligt och ger dig adminåtkomst. Efter inloggning tar du bort raderna och sparar inställningarna via gränssnittet.

Behöver jag ändra GUID i wp_posts, eller kan jag hoppa över det?

Det behövs inte för sajtens funktion. WordPress använder inte GUID för routning, bara för att identifiera inlägg i RSS-flöden. Om folk aktivt läser din sajt via RSS är ersättningen meningsfull. Om inte kan du hoppa över den tredje av de fyra frågorna utan konsekvenser.

Efter domänbytet via SQL försvann vissa plugininställningar. Varför?

Plugins som WooCommerce, Advanced Custom Fields och sliders lagrar URL:er i serialiserade arrayer i wp_postmeta. En vanlig REPLACE tar inte hänsyn till stränglängdsräknaren i serialiseringen och förstör strukturen. Lösningen är Better Search Replace eller wp search-replace (de deserialiserar arrayen, ersätter strängen och serialiserar tillbaka den). Om du redan har förstört den, återställ databasen från backup och upprepa ersättningen med rätt verktyg.

Vad du ska göra i komplexa fall: butiker, multisajter och stora databaser

Domänbyte via SQL är en femminutersprocedur om du har direkt tillgång till phpMyAdmin och ett standardtabellprefix. Men det finns situationer där manuell ersättning via REPLACE är genuint riskabelt.

Webbutiker på WooCommerce med hundratusentals ordrar. Multisajtnätverk med dussintals separata tabeller för varje undersajt. Sajter där URL:er är hårdkodade i serialiserade arrayer (temainställningar, sidbyggare, sliders). I sådana fall kan en enda SQL-REPLACE skada datastrukturen, och att återställa databasen från backup tar längre tid än att göra en korrekt ersättning från början.

Better Search Replace eller WP-CLI search-replace kan hantera serialisering; använd dem. Och om databasstorleken överstiger en gigabyte och kostnaden för ett fel är hög, kostar en timmes arbete av en utvecklare mindre än att återställa en butik vars driftstopp kostar pengar.

Vi behandlade ämnet sajtflytt med bevarad SEO och utan trafikförlust i en separat guide. Och om du stöter på ett specifikt fel efter ersättningen, skriv i kommentarerna så hjälper vi till med diagnostik.