Hvordan oppdatere url-er i WordPress-databasen når du flytter domene

Å flytte et WordPress-nettsted fra et utviklingsmiljø til et produksjonsdomene, bytte merkenavn eller ta i bruk et SSL-sertifikat (overgang fra HTTP til HTTPS) er rutineoppgaver for enhver administrator og utvikler. Ved første øyekast virker det banalt: eksporter databasen til en .sql-fil, åpne den i en kodeeditor, kjør “Søk og erstatt” og importer filen igjen. Eller kjør en rask SQL-spørring i phpMyAdmin.

Gjør du dette på en WordPress-database i produksjon, går nettstedet i stykker med en gang. Widgeter i bunntekst og sidepaneler forsvinner, farge- og typografiinnstillingene i temaet tilbakestilles, avanserte felter (ACF) returnerer tomme verdier, og konfigurasjonen av nettbutikk-utvidelser nullstilles.

Årsaken er måten WordPress og utvidelsene lagrer komplekse datastrukturer på i relasjonsdatabasene MySQL og MariaDB. WordPress-dokumentasjonen advarer direkte: et vanlig søk og erstatt i hele databasen kan ødelegge serialiseringen, fordi noen temaer og widgeter lagrer adressen sammen med lengden (Migrating WordPress, developer.wordpress.org). Å forstå PHP-serialisering og å beherske de riktige verktøyene, først og fremst kommandolinjegrensesnittet WP-CLI, er grunnlaget for trygg drift av WordPress-nettsteder.

#Hva er serialiserte data i WordPress-databasen

Relasjonsdatabaser er laget for skalare data: tall, korte tekststrenger og datoer. WordPress må likevel ofte lagre en sammensatt, flerdimensjonal datastruktur i én enkelt tabellrad, for eksempel en array med listen over aktive widgeter, rekkefølgen deres, tilknyttede ikoner og konfigurasjonsparametre.

I stedet for å lage dusinvis av ekstra normaliserte tabeller for hver utvidelse valgte WordPress-utviklerne å bruke en innebygd PHP-funksjon: serialize().

// Eksempel på en konfigurasjonsarray for temaet i PHP
$theme_settings = array(
    'site_name'    => 'Min WordPress-butikk',
    'logo_url'     => 'https://gammelt-domene.no/logo.png',
    'contact_mail' => '[email protected]'
);

// Resultatet av serialize($theme_settings)
// Lagres direkte i kolonnen option_value i tabellen wp_options:
a:3:{s:9:"site_name";s:20:"Min WordPress-butikk";s:8:"logo_url";s:34:"https://gammelt-domene.no/logo.png";s:12:"contact_mail";s:22:"[email protected]";}

#Hvordan lese en serialisert streng

Se nærmere på delen som representerer url-en til logoen:

s:34:"https://gammelt-domene.no/logo.png";

Hvert element i det serialiserte PHP-formatet har en fast struktur:

• s angir datatypen: string (tekststreng).
• 34 er den oppgitte lengden på strengen (nøyaktig antall byte).
• "https://gammelt-domene.no/logo.png" er selve verdien i anførselstegn.

Nøkkelen i hele puslespillet er tallet 34. Når PHP leser dataene fra databasen, kaller den funksjonen unserialize(). PHP-parseren leter ikke etter det avsluttende anførselstegnet på måfå, den teller nøyaktig 34 byte fra det angitte stedet.

#Hvorfor SQL REPLACE ødelegger serialiserte data

Tenk deg at vi flytter nettstedet til et nytt og lengre domene: https://nytt-og-mye-lengre-firmadomene.no. Den nye adressen til logoen blir https://nytt-og-mye-lengre-firmadomene.no/logo.png, som har 50 tegn.

Hvis vi kjører en tradisjonell SQL-spørring:

-- KRITISK FEIL: Denne spørringen ødelegger serialiseringen!
UPDATE wp_options
SET option_value = REPLACE(option_value, 'https://gammelt-domene.no', 'https://nytt-og-mye-lengre-firmadomene.no');

ender databasen opp med denne strengen:

s:34:"https://nytt-og-mye-lengre-firmadomene.no/logo.png";

Hva skjer når en bruker åpner nettstedet?

1. WordPress henter raden fra databasen og sender den til funksjonen unserialize().
2. Funksjonen leser overskriften s:34 og forventer nøyaktig 34 tegn.
3. PHP kutter de første 34 tegnene av den nye adressen og treffer tilfeldige bokstaver inne i strengen i stedet for det påkrevde avsluttende anførselstegnet og semikolonet.
4. PHP-parseren gir feilen PHP Notice: unserialize(): Error at offset... og returnerer verdien false.
5. Temaet eller utvidelsen får false i stedet for den forventede arrayen med innstillinger.
6. WordPress tror dermed at dataene ikke finnes, og gjenoppretter temaets standardinnstillinger eller fjerner widgetene.

#Hvor lagrer WordPress url-er i databasen

Url-ene i en WordPress-installasjon ligger ikke på ett sted. De er spredt over mange systemtabeller og tabeller som eksterne moduler oppretter:

graph TD
    A["WordPress-databasen"] --> B["wp_options"]
    A --> C["wp_posts"]
    A --> D["wp_postmeta"]
    A --> E["wp_comments / wp_commentmeta"]
    A --> F["wp_usermeta"]
    A --> G["Tabeller fra utvidelser (WooCommerce, skjemaer, SEO)"]

    B --> B1["siteurl og home (hovedadresser)"]
    B --> B2["sidebars_widgets (serialisert)"]
    B --> B3["theme_mods (serialisert)"]

    C --> C1["post_content (lenker, bilder)"]
    C --> C2["post_excerpt"]
    C --> C3["guid (IKKE endre i publiserte innlegg!)"]

    D --> D1["_elementor_data (JSON / escapet)"]
    D --> D2["_wp_attached_file (mediestier)"]
    D --> D3["ACF-felter (serialisert)"]

#1. Tabellen wp_options

Dette er den viktigste konfigurasjonstabellen. Den inneholder to kritiske poster som avgjør om nettstedet fungerer:

• siteurl: viser hvor WordPress-filene fysisk ligger (kjernestien).
• home: viser hovedadressen til nettstedet som brukerne skriver inn i nettleseren.

I tillegg lagrer tabellen i serialisert form:

• sidebars_widgets: plasseringen av widgeter i sidepaneler og bunntekster.
• theme_mods_[temanavn]: farger, topptekstoppsett, typografi og logo fra tematilpasseren (Customizer).
• Innstillinger for SEO-utvidelser (Rank Math, Yoast), sikkerhetsutvidelser og hurtigbufferutvidelser.

#2. Tabellen wp_posts

Lagrer innholdet i innlegg, sider, WooCommerce-produkter og elementer i mediebiblioteket.

• Kolonnen post_content: inneholder absolutte lenker til andre undersider, innebygde img-tagger, lenker til PDF-filer og Gutenberg-blokkommentarer.
• Kolonnen guid (Globally Unique Identifier): den unike identifikatoren til innlegget. Viktig regel: WordPress-dokumentasjonen sier: “Endre aldri, under noen omstendigheter, innholdet i GUID-kolonnen” (Migrating WordPress, developer.wordpress.org, egen oversettelse). Kolonnen guid skal ikke endres, fordi RSS-lesere bruker den til å oppdage nye artikler. Endrer du guid, behandler RSS-leserne alle eldre innlegg som nye og sender varsler til abonnentene på nytt.

#3. Tabellen wp_postmeta

Inneholder tilleggsattributter for innlegg og sider. Her havner serialiserte arrays fra egendefinerte felter i utvidelsen Advanced Custom Fields (ACF), vedleggsmetadata (_wp_attachment_metadata) og konfigurasjonen til sidebyggere som Elementor og Divi.

#4. Tabellene wp_usermeta og wp_comments

Inneholder url-ene til hjemmesidene til kommentarforfatterne og metadata for brukerprofiler.

#Bytte domene i WordPress med WP-CLI search-replace

Kommandolinjegrensesnittet for WordPress (WP-CLI) er det raskeste, mest pålitelige og fullt automatiserte verktøyet for å migrere url-er. Det kjører direkte på serveren over SSH og arbeider med PHP-objektstrukturene i minnet.

#Steg 1: Ta sikkerhetskopi

Før du gjør noe som helst med en produksjonsdatabase, lager du en dump av databasen til en SQL-fil:

# Databasedump med DROP TABLE-setninger
wp db export backup-for-migrering-$(date +%Y%m%d_%H%M%S).sql --add-drop-table

Blir databasen skadet, gjenoppretter du opprinnelig tilstand på sekunder:

wp db import backup-for-migrering-*.sql

#Steg 2: Kjør en testkjøring (—dry-run)

Flagget --dry-run viser hvor mange rader som vil bli endret og i hvilke tabeller, uten å gjøre noen endringer i databasen:

wp search-replace 'https://gammelt-domene.no' 'https://nytt-domene.no' --all-tables --dry-run

Resultatet er en tabell med kolonnene Table, Column, Replacements og Type, pluss en oppsummeringslinje med det totale antallet erstatninger. Kolonnen Type viser om kolonnen ble behandlet i SQL eller i PHP. Er antallet erstatninger null, skyldes det oftest at den gamle adressen skiller seg fra den som er lagret i databasen, enten i protokoll, www-prefiks eller avsluttende skråstrek.

#Steg 3: Utfør selve erstatningen i produksjon

Til den endelige erstatningen anbefaler vi dette settet med flagg:

wp search-replace 'https://gammelt-domene.no' 'https://nytt-domene.no' \
  --all-tables \
  --precise \
  --recurse-objects \
  --skip-columns=guid \
  --report-changed-only

Forklaring av parameterne:

• --all-tables: søker gjennom alle tabellene i databasen, også egne tabeller fra nettbutikk-, skjema- og loggutvidelser.
• --precise: tvinger bruk av PHP i stedet for SQL for alle kolonner. WP-CLI-dokumentasjonen beskriver dette som tregere, men sikrere ved komplekse serialiserte data.
• --recurse-objects: går rekursivt inn i serialiserte objekter. Det er slått på som standard og slås av med --no-recurse-objects, så å skrive det eksplisitt dokumenterer bare intensjonen.
• --skip-columns=guid: hopper over kolonnen guid i tabellen wp_posts og beskytter RSS-leserne mot dupliserte innlegg.
• --report-changed-only: viser i oppsummeringen bare tabellene der det faktisk ble gjort endringer, og skjuler hundrevis av tomme rader.

#Bytte domene i et WordPress Multisite-nettverk

I Multisite-installasjoner (et nettverk av flere nettsteder) har systemtabellene egne prefikser (f.eks. wp_2_posts, wp_3_options), og informasjonen om domenene til de enkelte undernettstedene ligger i tabellene wp_blogs og wp_site.

I et slikt miljø bruker du flagget --network, som omfatter alle tabellene som er registrert i $wpdb for hele nettverket, eller --all-tables-with-prefix, som tar med tabeller med prefikset som ikke er registrert i $wpdb:

wp search-replace 'https://gammelt-nettverk.no' 'https://nytt-nettverk.no' --network --all-tables-with-prefix

WordPress-dokumentasjonen innrømmer at dette steget ved domenebytte i et Multisite-nettverk “ennå ikke enkelt kan automatiseres” (Migrating WordPress, developer.wordpress.org, egen oversettelse). Etter erstatningen sjekker du manuelt:

• tabellene wp_site og wp_blogs, der domenet og stien til nettverket og hvert undernettsted er lagret,
• alternativene home, siteurl og fileupload_url i alternativtabellen til hvert nettsted (wp_options, wp_2_options og så videre),
• ved overgang fra underdomener til underkataloger eller omvendt: filen .htaccess og konstanten SUBDOMAIN_INSTALL i wp-config.php.

#Eksportere databasen med nye adresser til en SQL-fil

Forbereder du en databasemigrering for en kunde i et lokalt miljø og vil lage en ferdig SQL-fil med byttede domener uten å røre den lokale arbeidsdatabasen:

wp search-replace 'https://localhost/prosjekt' 'https://kundens-domene.no' \
  --all-tables \
  --export=database-klar-for-import.sql

#Bytte fra www til domenet uten www

Når bare prefikset endres, fra www.dittdomene.no til domenet uten www, bytter du hele adressen med protokoll, slik at du ikke treffer andres strenger med samme navn. Kjør en testkjøring først, og deretter erstatningen:

wp search-replace 'https://www.dittdomene.no' 'https://dittdomene.no' --all-tables --precise --skip-columns=guid --dry-run
wp search-replace 'https://www.dittdomene.no' 'https://dittdomene.no' --all-tables --precise --skip-columns=guid

#Bytte url-er med utvidelsen Better Search Replace

Administrerer du et nettsted på delt hosting uten SSH-tilgang, eller foretrekker du å jobbe fra WordPress-kontrollpanelet, er utvidelsen Better Search Replace den tryggeste løsningen. Den utvikles av WP Engine (tidligere Delicious Brains).

Steg for steg i WordPress-kontrollpanelet:
1. Gå til: Utvidelser > Legg til utvidelse > søk etter "Better Search Replace".
2. Installer og aktiver utvidelsen.
3. Gå til: Verktøy > Better Search Replace.
4. I feltet "Search for" skriver du inn den gamle url-en (f.eks. https://gammelt-domene.no).
5. I feltet "Replace with" skriver du inn den nye url-en (f.eks. https://nytt-domene.no).
6. Merk alle tabellene i listen (Ctrl+A på Windows eller Cmd+A på macOS).
7. Kontroller at valget "Run as dry run?" er AVKRYSSET.
8. Klikk "Run Search/Replace" og gå gjennom rapporten.
9. Fjern avkryssingen for "Run as dry run?" og kjør på nytt for å lagre endringene.

#Feil i Better Search Replace og hvordan du løser dem

• Feilen 504 Gateway Timeout eller overskredet kjøretid for skriptet (max_execution_time): Ved store databaser kan webserveren avbryte HTTP-forespørselen. I fanen Settings i utvidelsen reduserer du parameteren Max Page Size. Standardverdien er 20000 rader per porsjon, noe som fremgår av kildekoden til utvidelsen (class-bsr-admin.php); en mindre porsjon gir flere og kortere forespørsler.

#Hvordan endre siteurl og home i WordPress

To alternativer i tabellen wp_options avgjør om du i det hele tatt kommer inn på nettstedet under den nye adressen. WordPress-dokumentasjonen (Changing The Site URL) skiller dem slik: home er “Nettstedsadresse (URL)”, altså adressen besøkende skriver inn i nettleseren, og siteurl er “WordPress-adresse (URL)”, altså stedet der kjernefilene ligger. Begge feltene under Innstillinger > Generelt skal inneholde https:// og skal ikke slutte med skråstrek.

Dokumentasjonen beskriver flere måter å endre disse verdiene på. Hver passer til en egen situasjon:

#Endre siteurl og home med WP-CLI

Dokumentasjonen gir to kommandoer, etterfulgt av en adressebytte i innholdet der kolonnen guid hoppes over:

wp option update home 'https://nytt-domene.no'
wp option update siteurl 'https://nytt-domene.no'
wp search-replace 'https://gammelt-domene.no' 'https://nytt-domene.no' --skip-columns=guid

#Endre adressen via functions.php

Har du bare FTP-tilgang, anbefaler dokumentasjonen å legge til to linjer i filen functions.php i det aktive temaet, rett etter den innledende <?php:

update_option( 'siteurl', 'https://nytt-domene.no' );
update_option( 'home', 'https://nytt-domene.no' );

Last opp filen, åpne innloggingssiden eller kontrollpanelet noen ganger, og fjern deretter linjene. Dokumentasjonen sier det rett ut: “Ikke la denne koden ligge i functions.php-filen” (Migrating WordPress, developer.wordpress.org, egen oversettelse). Koden ville kjørt ved hver forespørsel og overskrevet alternativer du senere vil endre fra kontrollpanelet.

#Konstanten RELOCATE etter flytting av katalog

Konstanten define( 'RELOCATE', true ); lagt inn i wp-config.php før kommentaren That's all, stop editing! gjør at WordPress tar i bruk den gjeldende adressen etter innlogging via wp-login.php på den nye serveren. Ifølge dokumentasjonen retter den bare adressene i administrasjonspanelet, ikke resten av konfigurasjonen, og det er usikkert å la den bli liggende: “Fjern alltid RELOCATE-linjen fra wp-config.php når du er ferdig” (Migrating WordPress, developer.wordpress.org, egen oversettelse).

#Transienter i den flyttede databasen

Dokumentasjonen trekker fram transienter, altså midlertidige verdier som lagres i wp_options. De kan inneholde gamle adresser, og fordi WordPress lager dem på nytt selv, kan de trygt slettes i den flyttede kopien av databasen. Med WP-CLI gjør du det med wp transient delete --all, og dokumentasjonen gir også en spørring for phpMyAdmin, som du kjører etter at du har tatt sikkerhetskopi:

DELETE FROM `wp_options` WHERE `option_name` LIKE '%\_transient\_%';

#Hvordan endre url-er når WordPress-kontrollpanelet ikke virker

I nødsituasjoner, når du ikke har SSH-tilgang og kontrollpanelet ikke virker på grunn av en omdirigeringsløkke eller ødelagte filer, har skriptet Search-Replace-DB (kjent som SRDB) fra byrået Interconnect/it vært et utprøvd verktøy i over ti år.

Slik bruker du SRDB-skriptet:
1. Last ned det offisielle zip-arkivet fra interconnectit.com.
2. Pakk ut filene og gi mappen et unikt navn som er vanskelig å gjette (f.eks. srdb-sec-8f7a9d/).
3. Last opp mappen til serveren via FTP / SFTP til rotkatalogen for WordPress-installasjonen (der wp-config.php ligger).
4. Åpne adressen i nettleseren: https://ditt-domene.no/srdb-sec-8f7a9d/.
5. Skriptet leser automatisk innloggingsdataene for databasen fra wp-config.php.
6. Fyll ut feltene "replace" (gammel verdi) og "with" (ny verdi).
7. Klikk "dry run", og etter kontroll "live run".
8. KRITISK: Når du er ferdig, klikker du den røde knappen "delete me", slik at skriptet sletter seg selv fra serveren.

[!CAUTION] Å la skriptet Search-Replace-DB ligge igjen på en aktiv server er et kritisk sikkerhetshull. Alle som gjetter stien til skriptet, får full lese- og skrivetilgang til databasen uten å oppgi passord. Kontroller alltid at mappen er slettet når arbeidet er ferdig!

#Bytte url-er i Elementor, Divi og Gutenberg

Moderne sidebyggere og blokkredigereren Gutenberg legger til ekstra lag med datakoding som du må huske på når du oppdaterer url-er.

graph LR
    subgraph WP_CLI_Execution["Steg 1: Database"]
        A["wp search-replace"] --> B["Tabellene wp_posts, wp_postmeta, wp_options"]
    end

    subgraph Builder_Sync["Steg 2: Sidebyggere"]
        B --> C["Elementor: Tools > Replace URL"]
        B --> D["Elementor: generer CSS-filer på nytt"]
    end

    subgraph Edge_Purge["Steg 3: Hurtigbuffer og CDN"]
        C & D --> F["wp cache flush (Redis/Memcached)"]
        F --> G["Tøm CDN (Cloudflare)"]
    end

#1. Url-er i Elementors JSON-data

Elementor lagrer sideoppsettet i metafeltet _elementor_data i JSON-format, der skråstrekene i url-er ofte er escapet (escaped slashes):

{\"url\":\"https:\/\/gammelt-domene.no\/wp-content\/uploads\/2026\/08\/banner.jpg\"}

Et vanlig søk etter https://gammelt-domene.no treffer kanskje ikke strengen med skråstreker https:\/\/gammelt-domene.no. I tillegg kompilerer Elementor stilreglene til statiske CSS-filer i katalogen wp-content/uploads/elementor/css/.

Riktig fremgangsmåte etter migrering av et Elementor-nettsted:

1. Kjør vanlig wp search-replace i databasen.
2. Logg inn i WordPress-kontrollpanelet og gå til Elementor > Tools > Replace URL (etikettene i Elementors engelske grensesnitt).
3. Skriv inn gammel og ny url og klikk Replace URL.
4. I fanen General klikker du Regenerate Files & Data.

#2. Url-er i Gutenberg-blokker

Gutenberg-blokker lagrer medieattributter direkte i HTML-kommentarer i post_content:

<!-- wp:image {"id":412,"sizeSlug":"full","linkDestination":"custom"} -->
<figure class="wp-block-image size-full"><a href="https://gammelt-domene.no/tilbud/"><img src="https://gammelt-domene.no/wp-content/uploads/2026/08/grafikk.png" alt="Tilbud"/></a></figure>
<!-- /wp:image -->

Både wp search-replace og Better Search Replace håndterer dette uten problemer, så lenge kolonnen post_content i tabellen wp_posts er med i søket.

#3. Hardkodede url-er i temafiler

Noen temaer og utvidelser har url-er hardkodet i PHP-, CSS- eller JavaScript-filer, og dem når ingen databaseerstatning. Søk etter dem i filsystemet:

grep -rn "gammelt-domene.no" wp-content/themes/ditt-tema/

#Bytte domene i en WooCommerce-butikk

Når du bytter domene i en nettbutikk basert på WooCommerce, må du være spesielt oppmerksom på modulene som kommuniserer med eksterne betalingsløsninger, fraktleverandører og ERP-systemer:

1. Betalingsløsninger (Stripe, PayPal og andre):
   • De fleste betalingsløsninger registrerer adresser for tilbakemeldinger (webhooks / IPN) i utviklerpanelene sine. Bytter du domene fra gammelt.no til nytt.no, vil varsler om betalte bestillinger fortsatt gå til den gamle adressen og gi transaksjonsfeil.
   • Etter wp search-replace logger du inn i panelet til hver betalingsleverandør og oppdaterer webhook-adressen.
2. Nøkler og webhooks i WooCommerce REST API:
   • Under WooCommerce > Settings > Advanced > Webhooks sjekker du at måladressene (Delivery URL) er oppdatert. Synkroniserer webhookene lagerstatus med et ERP-system, oppdaterer du endepunktadressene i integrasjonsprogramvaren.
3. Økter og kunders handlekurver:
   • Tabellen wp_woocommerce_sessions lagrer midlertidige handlekurvdata. Etter domenebyttet er det lurt å tømme utløpte økter under WooCommerce > Status > Tools > Clear customer sessions for å unngå feil i økttokener etter at domenets informasjonskapsler er endret.

#Search-replace på en stor database og MySQL-klynge

Ved svært store databaser tar én gjennomkjøring av wp search-replace over alle tabeller lang tid, og hele tiden skrives det til tabeller som det kjørende nettstedet bruker. WP-CLI-dokumentasjonen nevner to begrensninger det er verdt å kjenne til: tabeller uten primærnøkkel hoppes over, og alternativene --regex og --log gjør arbeidet merkbart tregere.

#1. Hvordan dele opp search-replace i mindre deler

Kommandoen wp search-replace har ingen alternativer som --batch-size eller --limit; listen over alternativer i WP-CLI-dokumentasjonen inneholder dem ikke, og instruksjoner som bruker dem, vil ikke fungere. Arbeidet deles opp på en annen måte: ved å oppgi tabellnavn som argumenter (jokertegn er tillatt) eller ved å utelate tabeller med --skip-tables:

# Først innhold, så metadata, i separate kjøringer
wp search-replace 'https://gammelt.no' 'https://nytt.no' wp_posts --precise --skip-columns=guid
wp search-replace 'https://gammelt.no' 'https://nytt.no' wp_postmeta --precise

# Alt unntatt en stor loggtabell fra en utvidelse
wp search-replace 'https://gammelt.no' 'https://nytt.no' --all-tables --skip-tables='wp_*_log' --precise --skip-columns=guid

Alternativet --include-columns begrenser erstatningen til bestemte kolonner, og med --export styrer --export_insert_size antall rader per INSERT-setning (standard 50).

#2. Search-replace ved replikering (Amazon Aurora, MySQL Galera)

Kjører databasen i en master-slave-arkitektur eller en Galera-klynge, gir masseendring av millioner av poster en kraftig datastrøm i den binære loggen (binlog). Det kan føre til betydelig replikeringsforsinkelse (replication lag) på lesenodene.

Anbefalt strategi for miljøer med høy tilgjengelighet:

• Utfør operasjonen i et vedlikeholdsvindu med minst trafikk.
• Koble replikanodene midlertidig fra mens masseskrivingen pågår.
• Bruk flagget --export til å lage en ferdig behandlet SQL-fil på en egen arbeidsmaskin, og importer den i vedlikeholdsvinduet.

#3. Vedlikeholdsmodus under migreringen

WP-CLI kan slå på vedlikeholdsmodusen i WordPress, slik at besøkende ikke ser et nettsted som er halvveis flyttet til den nye adressen:

wp maintenance-mode activate
wp search-replace 'https://gammelt.no' 'https://nytt.no' --all-tables --precise --skip-columns=guid
wp maintenance-mode deactivate

#Overgang fra HTTP til HTTPS og oppsett av webservere

Er målet med migreringen ikke å bytte domenenavn, men å ta i bruk et SSL-sertifikat og gå fra ukryptert til kryptert protokoll:

wp search-replace 'http://dittdomene.no' 'https://dittdomene.no' \
  --all-tables \
  --precise \
  --skip-columns=guid

Slik fjerner du problemet med såkalt Mixed Content (blandet innhold), der nettleseren blokkerer skript, skrifter eller bilder som serveres over den gamle protokollen http://. Erstatningen er avgrenset til ditt eget domene, slik at lenker til eksterne nettsteder ikke endres.

#301-omdirigeringer på Nginx- og Apache-nivå

Etter domenebyttet i databasen er det, sett fra SEO, avgjørende å omdirigere all trafikk fra den gamle adressen til den nye med HTTP-statuskode 301 (Moved Permanently).

Nginx-oppsett (/etc/nginx/sites-available/gammelt-domene.conf):

server {
    listen 80;
    listen 443 ssl http2;
    server_name gammelt-domene.no www.gammelt-domene.no;

    ssl_certificate /etc/letsencrypt/live/gammelt-domene.no/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/gammelt-domene.no/privkey.pem;

    return 301 https://nytt-domene.no$request_uri;
}

Apache-oppsett (.htaccess på den gamle serveren):

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTP_HOST} ^(?:www\.)?gammelt-domene\.no$ [NC]
    RewriteRule ^(.*)$ https://nytt-domene.no/$1 [L,R=301]
</IfModule>

Du kan kontrollere at omdirigeringen og den nye adressen svarer riktig med curl, som skriver ut bare HTTP-statuskoden:

curl -s -o /dev/null -w "%{http_code}" https://gammelt-domene.no/
curl -s -o /dev/null -w "%{http_code}" https://nytt-domene.no/

#Konstanter i wp-config.php kontra verdiene i databasen

En vanlig nødløsning er å tvinge url-ene i filen wp-config.php:

define('WP_HOME', 'https://nytt-domene.no');
define('WP_SITEURL', 'https://nytt-domene.no');

Det er nyttig å vite hvordan disse konstantene virker i praksis:

• Konstanter definert i wp-config.php overstyrer verdiene siteurl og home som WordPress leser, men endrer ikke postene i databasen. Dokumentasjonen kaller dette rett ut hardkoding av verdiene, og påpeker at det ikke nødvendigvis er den beste løsningen.
• Adressefeltene under Innstillinger > Generelt kan da ikke redigeres.
• Lenker i innleggsinnhold, vedlegg og widgeter peker fortsatt på den gamle adressen.
• Se på konstantene i wp-config.php som en midlertidig løsning; på sikt skal databasen alltid oppdateres med wp search-replace.

#Sjekkliste for domenebytte i WordPress

Før du begynner, lønner det seg å følge en strukturert plan:

#Bash-skript for å synkronisere WordPress-databasen mellom miljøer

I moderne arbeidsflyter basert på Docker-containere eller utviklingsmiljøer (DDEV, Lando, LocalWP) tar manuell inntasting av kommandoer tid og gir rom for menneskelige feil. Standarden i utviklingsteam er et universelt Bash-skript som automatiserer nedlasting av produksjonsdatabasen, import til det lokale miljøet, domenebytte og anonymisering av sensitive kundedata.

#!/usr/bin/env bash
# Skript for automatisk databasesynkronisering: sync-db.sh
set -eo pipefail

PROD_HOST="din-produksjonsserver.no"
PROD_USER="deploy"
PROD_PATH="/var/www/html"
PROD_URL="https://dittfirma.no"
LOCAL_URL="https://prosjekt.local"
BACKUP_DIR="./backups"

mkdir -p "${BACKUP_DIR}"
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
DUMP_FILE="${BACKUP_DIR}/dump_prod_${TIMESTAMP}.sql"

echo "==> 1/4 Henter produksjonsdatabasen over SSH..."
ssh "${PROD_USER}@${PROD_HOST}" "cd ${PROD_PATH} && wp db export - --add-drop-table" > "${DUMP_FILE}"

echo "==> 2/4 Importerer databasen til det lokale miljøet..."
wp db import "${DUMP_FILE}"

echo "==> 3/4 Trygg domenebytte med støtte for serialisering..."
wp search-replace "${PROD_URL}" "${LOCAL_URL}" \
  --all-tables \
  --precise \
  --recurse-objects \
  --skip-columns=guid \
  --report-changed-only

echo "==> 4/4 Tømmer hurtigbuffer og nullstiller permalenker..."
wp cache flush
wp rewrite flush --hard

echo "==> Ferdig! Det lokale miljøet er synkronisert på ${LOCAL_URL}."

#Kontrollere serialiseringen etter at arbeidet er ferdig

Vil du være helt sikker på at ingen felt i databasen ble skadet under migreringen, kan du kjøre et kort PHP-skript i WP-CLI som kontrollerer integriteten til alle serialiserte poster i tabellen wp_options:

wp eval '
global $wpdb;
$options = $wpdb->get_results("SELECT option_name, option_value FROM {$wpdb->options} WHERE option_value LIKE \"a:%\" OR option_value LIKE \"O:%\"");
$broken = 0;
foreach ($options as $opt) {
    if (is_serialized($opt->option_value) && @unserialize($opt->option_value) === false) {
        echo "Ødelagt alternativ: " . $opt->option_name . PHP_EOL;
        $broken++;
    }
}
if ($broken === 0) {
    echo "Alle serialiserte alternativer i wp_options er gyldige." . PHP_EOL;
} else {
    echo "Fant " . $broken . " ødelagte poster!" . PHP_EOL;
}
'

#Feil etter domenebytte i WordPress og hvordan du retter dem

#1. Omdirigeringsløkke etter domenebytte (ERR_TOO_MANY_REDIRECTS)

Havner nettstedet i en uendelig omdirigeringsløkke etter domenebyttet:

• Sjekk at adressene siteurl og home i tabellen wp_options har nøyaktig samme protokoll (https://) og prefiks (www eller uten www) som er satt opp på webserveren eller i Cloudflare.
• Sjekk SSL-oppsettet i Cloudflare (SSL/TLS-modusen bør være Full (Strict), ikke Flexible).
• Tilbakestill .htaccess til WordPress-standarden med kommandoen:

  wp rewrite flush --hard

#2. CSS-stiler og ikoner forsvinner etter migrering

• Lastes nettstedet som rå tekst uten stiler, er de vanligste årsakene stilark og skript som fortsatt peker på den gamle adressen, blandet innhold (Mixed Content) ved overgang til HTTPS, eller at ressurser blokkeres av CORS-reglene.
• Åpne utviklerkonsollen i nettleseren (F12 > fanen Console) for å finne filene som lastes fra den gamle http://-adressen.

#3. Ødelagte widgeter eller ACF-felter

• Ble reglene for serialisering ignorert og en rå SQL REPLACE kjørt, er den eneste trygge utveien å gjenopprette databasen fra den tidligere dumpen (wp db import backup.sql) og gjenta operasjonen med wp search-replace --precise.

#4. Feilen Allowed memory size exhausted i WP-CLI

Ved search-replace på tabeller med svært store tekstmengder (f.eks. store loggtabeller eller innleggsrevisjoner) kan PHP-prosessen i terminalen bruke opp minnegrensen:

• For midlertidig å øke minnegrensen for én enkelt WP-CLI-kommando kjører du den med en PHP-innstilling:

  php -d memory_limit=1024M /usr/local/bin/wp search-replace 'https://gammelt.no' 'https://nytt.no' --all-tables

• Det lønner seg også å slette unødvendige innleggsrevisjoner og utløpte transienter før migreringen:

  wp transient delete --all && wp post delete $(wp post list --post_type='revision' --format=ids) --force

#5. Avvikende tegnsett og sortering (collation)

Når du flytter en databasedump til en eldre eller annen databaseserver, kan det vise seg at målserveren ikke kjenner sorteringsregelen (collation) som er brukt i dumpen, for eksempel utf8mb4_unicode_520_ci:

• Får du feilen #1273 - Unknown collation: 'utf8mb4_unicode_520_ci' når du importerer .sql-filen, bytter du ut strengen i SQL-filen før importen:

  sed -i 's/utf8mb4_unicode_520_ci/utf8mb4_unicode_ci/g' backup.sql

• Begge lagrer utf8mb4, så æ, ø og å bevares; bare regelen for sortering og sammenligning av tekst endres.

#Oppsummering

Riktig oppdatering av url-er i en WordPress-database krever forståelse av hvordan PHP og relasjonsdatabaser fungerer. Rå SQL-spørringer eller redigering av filer i tekstredigeringsprogrammer er den korteste veien til et ustabilt nettsted og tapte innstillinger.

Verktøyet WP-CLI med flaggene --all-tables --precise --skip-columns=guid, kjørt etter en sikkerhetskopi og en --dry-run, holder de serialiserte dataene og kolonnen guid intakte.

Planlegger du en større modernisering av nettstedet, en overgang til headless-arkitektur eller en migrering til nyere plattformer? Se tjenestene våre for migrering fra WordPress til Astro og Next.js, revisjon av Core Web Vitals og WordPress-utvikling.