Du flyttet et nettsted til et nytt domene, og det er nede. Eller det åpnes, men uten stilark. Eller adminpanelet slipper deg ikke inn. Alle som har migrert WordPress manuelt har opplevd dette øyeblikket: databasen husker fortsatt den gamle URL-en, og nettstedet prøver febrilsk å laste ressurser fra en adresse som ikke lenger finnes.

Fire SQL-spørringer i phpMyAdmin løser problemet på fem minutter. Ingen utvidelser, ingen WP-CLI, ingen panikk. Nedenfor finner du en trinnvis guide fra å finne gjeldende domene til den endelige sjekken. Med justeringer for ikke-standard tabellprefikser, HTTPS og serialiserte data.

💡 Rask oversikt:

• Finn gjeldende domene i wp_options-tabellen: feltene siteurl og home
• Kjør fire UPDATE-spørringer i SQL-fanen i phpMyAdmin
• Tilbakestill administratorpassordet via wp_users hvis adminpanelet ikke slipper deg inn
• Lagre permalenker i WordPress-innstillinger for å gjenopprette stilark
• For nettbutikker og multisites, bruk Better Search Replace eller WP-CLI: en vanlig REPLACE ødelegger serialiserte arrays

Hvor du skal begynne: finn gjeldende domene i databasen

Før du erstatter, må du forsikre deg om hvilket domene som for øyeblikket er satt for nettstedet. Dette sparer tid hvis nettstedet har blitt flyttet før og en tredje, «mellomliggende» URL kan ligge igjen i databasen.

Åpne phpMyAdmin, velg nettstedets database og finn wp_options-tabellen. Den inneholder to rader: siteurl (WordPress-adressen) og home (nettstedsadressen). Dette er verdiene vi endrer først.

Hvis tabellprefikset er ikke-standard (for eksempel mysite_ i stedet for wp_), se etter mysite_options-tabellen. Du finner prefikset i filen wp-config.php: variabelen $table_prefix.

Fire SQL-spørringer for en komplett domeneerstatning

Kjør hver spørring én etter én i «SQL»-fanen i phpMyAdmin. Før du kjører dem, sørg for å ta sikkerhetskopi av databasen: eksport via phpMyAdmin tar ett minutt og redder deg fra irreversible feil.

Erstatt http://www.oldurl med http://www.newurl i alle spørringene nedenfor. Hvis nettstedet kjører på HTTPS, bruk https:// i begge adressene.

1. Oppdatering av HOME og SITEURL

Dette endrer de to nøkkeladressene i wp_options. Uten dette trinnet vil nettstedet rett og slett ikke åpnes på det nye domenet; WordPress vil fortsette å prøve å omdirigere til det gamle.

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. Oppdatering av innleggs-GUID-er

Feltet guid i wp_posts lagrer den permanente identifikatoren for hvert innlegg. Å erstatte den er ikke kritisk for nettstedets drift; WordPress bruker ikke GUID for ruting. Men hvis folk leser nettstedet ditt gjennom RSS-lesere, er rene GUID-er viktig: gamle URL-er i feeden vil føre til ødelagte lenker.

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

3. Oppdatering av innleggsinnhold

Den mest omfattende spørringen. post_content inneholder teksten til alle sider og innlegg, inkludert innebygde bilder og interne lenker. Etter å ha kjørt denne, vil alle bilder i innholdet lastes fra det nye domenet.

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

4. Oppdatering av metafelter

Egendefinerte felter, utvidelsesinnstillinger, temadata: alt dette lagres i wp_postmeta. Hopp over denne spørringen, og du får ødelagte lenker på tilsynelatende uventede steder: logoen i bunnteksten, bakgrunnen i tilpasseren, URL-en i SEO-utvidelsen din.

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

Etter å ha kjørt alle fire spørringene, åpner du nettstedet på det nye domenet. Hvis alt ble gjort riktig, skal det ikke være noen problemer. Men noen ganger skjer noe annet: en melding om «Feil ved tilkobling til databasen» eller siden åpnes uten stilark.

Det første du trenger i denne situasjonen er tilgang til adminpanelet.

Hvordan få tilgang til adminpanelet hvis passordet er tapt eller nettstedet ikke slipper deg inn

Klienten la ikke igjen noe passord. Eller du låste deg selv ute ved å endre domenet, og /wp-admin kaster deg inn i en endeløs omdirigering. Her er to måter å få administratorrettigheter direkte gjennom databasen.

Tilbakestille administratorpassordet via phpMyAdmin

Åpne wp_users-tabellen (ditt prefiks kan være annerledes: mysite_users osv.). Finn brukeren med administratorrettigheter og klikk «Rediger»:

I raden user_pass velger du MD5-funksjonen fra nedtrekksmenyen og skriver inn det nye passordet i det tilstøtende feltet. Klikk «Kjør»:

Merk: Moderne WordPress bruker phpass (bcrypt-hasher), ikke MD5. Men når du oppgir et WordPress-passord, sjekker det hashen sekvensielt: Hvis bcrypt-sjekken mislykkes, prøver det MD5-fallbacken og rehasher passordet umiddelbart til gjeldende format. Derfor fungerer MD5 via phpMyAdmin som en midlertidig nøkkel.

Opprette en administrator via PHP

En alternativ metode er å legge til en ny administratorbruker programmatisk. Koden settes inn i det aktive temaets functions.php eller via en MU-plugin.

Legg til følgende i barnetemaets 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' );

Funksjonen wp_insert_user() oppretter en bruker med de angitte parameterne, og init-hooken kjøres ved hver WordPress-forespørsel. Bare åpne en hvilken som helst side på nettstedet én gang, så opprettes brukeren.

Etter at du har logget inn i administrasjonspanelet, må du huske å slette både funksjonen fra functions.php og den midlertidige brukeren du opprettet. Å etterlate tempadmin med et passord i klartekst er et sikkerhetshull.

Reparere ødelagte bilder og stiler etter domenebytte

Du har tilgang til administrasjonspanelet, men bilder lastes ikke og layouten er ødelagt. I ni av ti tilfeller hjelper én enkel operasjon.

Gå til «Innstillinger» → «Permalenker»:

Ikke endre noe, bare klikk «Lagre endringer»:

WordPress bygger om URL-strukturen, oppdaterer hurtigbufferen for omskrivingsregler og tømmer den interne videresendingsbufferen. Etter dette er bildene vanligvis tilbake på plass.

Hvis det ikke hjalp, betyr det at det gamle domenet ligger innebygd i serialiserte tabeller. En vanlig REPLACE i SQL ødelegger dem: strenglengden i en serialisert tabell er hardkodet som et tall, og å erstatte «gammelt-langt-domene.no» med «nytt-kort.io» endrer den lengden, noe som gjør tabellen uleselig. Installer den gratis plugin-en Better Search Replace; den håndterer serialisering korrekt og viser deg hvor mange treff som ble funnet i hver tabell før erstatning.

For nettsteder med WP-CLI er det enda enklere med én kommando:

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

Flagget --dry-run viser først hva som vil bli erstattet uten å gjøre endringer. Når du er trygg, kjører du den uten flagget. WP-CLI search-replace håndterer også serialiserte data og gjør det raskere enn webgrensesnittet.

Videoen nedenfor demonstrerer hele prosessen fra innlogging i phpMyAdmin til kontroll av nettstedet etter erstatning:

⁉️🤔 Ofte stilte spørsmål

Er det obligatorisk å bruke phpMyAdmin for domeneerstatning?

Nei. Hvis nettstedet ikke er flyttet ennå, utfører Duplicator eller All-in-One WP Migration erstatningen automatisk under distribusjon. Hvis nettstedet allerede ligger på det nye webhotellet uten admin-tilgang, sitter du igjen med SQL-spørringer via phpMyAdmin, Adminer eller WP-CLI. For de fleste webmastere er phpMyAdmin den mest direkte og kontrollerte metoden: du ser hver operasjon i stedet for å stole på en plugins svarte boks.

Hva bør jeg gjøre hvis tabellprefikset ikke er wp_?

Sjekk konstantverdien $table_prefix i wp-config.php. Den er vanligvis wp_, men webhoteller eller sikkerhetsplugins som Solid Security (tidligere iThemes Security) endrer den noen ganger til noe tilfeldig. I alle spørringene over, erstatt wp_ med ditt prefiks (for eksempel xyz123_options i stedet for wp_options).

Hvorfor åpnes nettstedet uten stilark etter erstatning?

Det gamle domenet ligger igjen i temainnstillinger, cache eller CDN. Tilbakestill permalenker (instruksjoner over) og tøm cachen i ditt caching-plugin. Hvis du bruker Cloudflare eller en annen CDN, invalider cachen på leverandørens side. Hvis det ikke hjalp, kjør Better Search Replace: den gamle URL-en er sannsynligvis innebygd i en serialisert theme_mods_*-array.

Nettstedet ligger på HTTPS, men etter flyttingen virker ikke sertifikatet. Hva bør jeg gjøre?

Forsikre deg om at du brukte https:// (ikke http://) i alle spørringer. Sjekk at begge adressene i WordPress-innstillingene etter innlogging i adminpanelet starter med https://. SSL-sertifikatet i seg selv konfigureres på webhotellsiden, via kontrollpanelet eller gratis Let's Encrypt. Dette er en separat prosedyre som ikke har noe med databasen å gjøre.

Kan jeg erstatte domenet uten tilgang til phpMyAdmin?

Ja. WP-CLI: wp search-replace 'http://olddomain' 'http://newdomain' --all-tables. Kun FTP: legg til linjene define('WP_HOME','http://newdomain'); og define('WP_SITEURL','http://newdomain'); i wp-config.php. Dette overstyrer adressene midlertidig og gir deg admin-tilgang. Etter innlogging, fjern linjene og lagre innstillingene via grensesnittet.

Må jeg endre GUID i wp_posts, eller kan jeg hoppe over det?

Det er ikke nødvendig for nettstedets drift. WordPress bruker ikke GUID for ruting, kun for å identifisere innlegg i RSS-strømmer. Hvis folk aktivt leser nettstedet ditt via RSS, gir erstatning mening. Hvis ikke, kan du hoppe over den tredje av de fire spørringene uten konsekvenser.

Etter å ha erstattet domenet via SQL, forsvant noen plugin-innstillinger. Hvorfor?

Plugins som WooCommerce, Advanced Custom Fields og slider-bildegallerier lagrer URL-er i serialiserte arrays i wp_postmeta. En vanlig REPLACE tar ikke hensyn til strenglengdetelleren i serialiseringen og ødelegger strukturen. Løsningen er Better Search Replace eller wp search-replace (de deserialiserer arrayen, erstatter strengen og serialiserer den tilbake). Hvis du allerede har ødelagt det, gjenopprett databasen fra backup og gjenta erstatningen med riktig verktøy.

Hva du gjør i komplekse tilfeller: butikker, multisites og store databaser

Domeneerstatning via SQL er en fem-minutters prosedyre hvis du har direkte tilgang til phpMyAdmin og et standard tabellprefiks. Men det finnes situasjoner der manuell erstatning via REPLACE er genuint risikabelt.

Nettbutikker på WooCommerce med hundretusenvis av ordrer. Multisite-nettverk med dusinvis av separate tabeller for hvert undernettsted. Nettsteder der URL-er er hardkodet i serialiserte arrays (temainnstillinger, sidebyggere, slider-bildegallerier). I slike tilfeller kan en enkelt SQL REPLACE skade datastrukturen, og gjenoppretting av databasen fra backup vil ta mer tid enn å gjøre en nøyaktig erstatning første gang.

Better Search Replace eller WP-CLI search-replace kan håndtere serialisering; bruk dem. Og hvis databasestørrelsen overstiger en gigabyte og kostnaden ved en feil er høy, vil en times arbeid fra en utviklerspesialist koste mindre enn å gjenopprette en butikk der nedetid koster penger.

Vi dekket temaet nettstedsmigrering med bevaring av SEO og uten å miste trafikk i en egen guide. Og hvis du støter på en spesifikk feil etter erstatning, skriv i kommentarene så hjelper vi med diagnostikk.