En kjent situasjon: du setter opp et utviklingsnettsted, bygger ut temaet, kobler innhold via WP Migrate DB Pro, og etter publisering oppdager du ødelagte stiler, manglende bilder og et wp-admin som ikke fungerer. Årsaken er nesten alltid den samme: produksjon ligger i roten mens dev ligger i en underkatalog (eller omvendt), og en enkel søk-og-erstatt av URL-er i databasen fikser ikke denne forskjellen.

Problemet er dypere enn det ser ut til: i en rotinstallasjon bruker WordPress samme domene for alle lenker (både til sider og til mediefiler). I en underkataloginstallasjon kommer innholdslenker fra nettstedadressen, mens ressurslenker (css, js, bilder) kommer fra WordPress-adressen. En standard søk-og-erstatt i databasen erstatter alt likt og ødelegger halvparten av stiene.

I denne veiledningen finner du to utprøvde migreringsruter (frem og tilbake) med spesifikke søk-og-erstatt-innstillinger, forberedelse av wp-config.php og riktig sekvens for filoverføring. Etter å ha lest vil du enten bringe dev og produksjon til et enhetlig oppsett eller bevisst gjennomføre en migrering mellom ulike installasjonstyper uten en ødelagt frontend.

💡 Hurtigoversikt:

• Finn din installasjonstype: sjekk om «WordPress-adresse» og «Nettstedsadresse» er like under Innstillinger → Generelt
• For migrering fra underkatalog til rot: hardkod WP_SITEURL i wp-config, utfør en /subdir → /-erstatning i databasen, flytt filer ett nivå opp, oppdater rotens index.php
• For migrering fra rot til underkatalog: erstatt kun stier til /wp-content i databasen, oppdater WordPress-adressen i innstillingene, opprett underkatalogen, kopier index.php og .htaccess tilbake til roten
• Etter enhver migrering, gå til Innstillinger → Permalenker og klikk «Lagre»: dette gjenoppbygger URL-strukturen og tømmer cachen

Slik finner du ut hvor WordPress er installert

Hvis du installerte WordPress manuelt, husker du sannsynligvis om det var i domenets rot eller i en underkatalog som /wp eller /blog. Men hvis nettstedet ble overtatt fra en tidligere utvikler, satt opp av hosting-leverandøren med ett klikk, eller det har gått flere år, blekner detaljene.

Den raskeste måten: gå til WordPress-administrasjonen, åpne Innstillinger → Generelt og se på feltene «WordPress-adresse (URL)» og «Nettstedsadresse (URL)». Hvis verdiene er like, har du en rotinstallasjon:

Hvis feltene er forskjellige, er WordPress installert i en underkatalog (i eksempelet nedenfor er dette /subdir):

Et ekstra tegn på en underkataloginstallasjon: når du logger inn i administrasjonen, inneholder URL-en en underkatalog, for eksempel example.com/wp/wp-admin/ i stedet for example.com/wp-admin/.

Hvorfor du ikke bare kan overføre direkte

Roten til problemet ligger i det doble URL-systemet som WordPress bruker ved underkataloginstallasjoner. La oss bryte det ned med konkrete eksempler.

Anta at du har en rotinstallasjon på example.com. Absolutt alle lenker i databasen, både til et innlegg /2025/about-page og til et bilde /wp-content/uploads/photo.jpg, starter med //example.com. En standard søk-og-erstatt //example.local → //example.com fungerer perfekt.

Ta nå en installasjon i underkatalogen /wp. Lenken til det samme innlegget ser ut som //example.com/about-page (via nettstedadressen), mens lenken til det samme bildet er //example.com/wp/wp-content/uploads/photo.jpg (via WordPress-adressen med underkatalogen). En enkel erstatning //example.local → //example.com vil ødelegge mediefiler: systemet vil lete etter dem uten /wp i stien og få en 404.

Tabellen nedenfor viser hvilke URL-grupper som må oppdateres i hver migreringsretning:

I tillegg til databasen må du fysisk flytte filer og oppdatere index.php i roten, ellers vil ikke WordPress finne wp-blog-header.php. Deretter går vi gjennom begge rutene steg for steg.

Metode 1: flytte WordPress fra underkatalog til rot

Dette er den enkleste retningen: du fjerner underkatalogen fra banene, og alle adresser blir «flate», som i en standardinstallasjon.

Steg 0: diagnostisere hva som vil gå galt

Før du griper inn, hjelper det å se omfanget av problemet med egne øyne. Skjermbildet nedenfor viser migreringsinnstillinger fra wp-in-a-subdirectory.local (WordPress i /subdir) til wp-standard-install.local (rotinstallasjon). WP Migrate DB Pro-innstillingene er standard, pluss en erstatning av nettstedstittel for demonstrasjon:

Resultatet er forutsigbart nedslående: sidene åpnes, men uten stilsett og med ødelagte bilder:

I HTML-koden kan du se ressurslenker med en død /subdir-bane som ikke lenger finnes på målserveren. Forsøk på å gå til wp-admin fører til en omdirigering til wp-standard-install.local/subdir/wp-login.php, men en slik fil finnes ikke. La oss nå fikse dette.

Steg 1: forberedelse

Først, beskytt admintilgang under migreringen. Legg til konstanter i wp-config.php som overstyrer innstillinger fra databasen, slik at WordPress fortsetter å slippe deg inn i admin via den gamle banen med underkatalogen, selv etter at vi har ryddet databasen:

1
define( 'WP_SITEURL', 'http://wp-in-a-subdirectory.local/subdir' );
2
define( 'WP_HOME', 'http://wp-in-a-subdirectory.local' );

Sett deretter nettstedet i vedlikeholdsmodus: rediger index.php i den offentlige roten, kommenter ut linjen require( dirname( __FILE__ )... og sett inn en html-plassholder med en kort nedetidsmelding etter den avsluttende ?>-taggen. Besøkende vil se dette:

I mellomtiden fortsetter du å få tilgang til admin på http://wp-in-a-subdirectory.local/subdir/wp-admin/ fordi WP_SITEURL-konstanten fungerer.

Steg 2: søk og erstatt i databasen

Rydd nå i databasen. Kjør et søk-og-erstatt med disse parene (vist i WP Migrate DB Pro-grensesnittet, men samme prinsipp fungerer med WP-CLI search-replace eller SQL-spørringer via phpMyAdmin):

• //wp-in-a-subdirectory.local/subdir → //wp-in-a-subdirectory.local
• /app/public/subdir → /app/public (filbane på serveren)

Rett etter migrering vil utseendet ikke endre seg (vedlikeholdssiden er fortsatt oppe, admin fungerer via den hardkodede konstanten). Men hvis du ser på innhold i innlegg, laster ikke bilder ennå, og interne lenker har «mistet» underkatalogen, noe som er akkurat det vi ønsket på dette stadiet:

Trinn 3: fysisk filoverføring

Fjern (eller kommenter ut) linjene med WP_SITEURL og WP_HOME fra wp-config.php. Admin vil nå slutte å fungere, så flytt umiddelbart filer fra underkatalogen ett nivå opp.

Via SSH eller kommandolinje på serveren gjøres dette med tre kommandoer:

1
rm index.php && mv subdir/* . && rm -rf subdir

Via FTP eller vertskontrollpanelets filbehandler drar du alt innhold fra underkatalogen til den offentlige roten og erstatter index.php:

Ferdig. Nettstedet åpnes på rot-URL-en; bilder og stilsett er på plass:

Siste finpuss: gå til admin (nå på http://wp-in-a-subdirectory.local/wp-admin uten underkatalogen), åpne Innstillinger → Permalenker og klikk «Lagre endringer», selv om du ikke endret noe. WordPress vil bygge opp URL-strukturen på nytt og tømme hurtigbufferen.

Metode 2: flytte WordPress fra rot til underkatalog

Mange utviklere anser installasjon av WordPress i en underkatalog som god praksis: kjernefiler roter ikke til roten, administrasjon via Git/Composer forenkles, og selve domenet kan brukes til andre applikasjoner. Men å migrere et eksisterende nettsted til en underkatalog er objektivt sett mer komplekst enn det motsatte, fordi noen lenker nå MÅ beholde underkatalogen mens andre ikke skal det.

Steg 0: diagnostikk

Samme utgangspunkt: vi prøver en standard migrering fra rotinstallasjonen wp-standard-install.local til underkataloginstallasjonen wp-in-a-subdirectory.local (WordPress i /subdir):

Resultatet er helt som forventet: sider åpnes, men stiler og bilder er ødelagt fordi /subdir ikke ble lagt til i banene deres:

I motsetning til det første scenarioet fungerer lenker til innlegg og sider korrekt (de skal ikke inneholde underkatalogen). Det som bryter sammen, er spesifikt ressurser (css, js, media), hvis baner nå må inkludere /subdir.

Steg 1: forberedelse

På dette stadiet setter vi IKKE konstantene WP_SITEURL og WP_HOME, fordi vår søk-og-erstatt ikke vil røre disse verdiene, og vi vil oppdatere WordPress-adressen manuelt litt senere.

Sett opp vedlikeholdssiden på samme måte: kommenter ut require(...) i index.php og legg til en html-plassholder. Besøkende ser vedlikeholdsmeldingen mens du fortsetter å få tilgang til admin på http://wp-standard-install.local/wp-admin/.

Steg 2: selektiv søk-og-erstatt i databasen

Den viktigste forskjellen fra den første metoden: vi erstatter KUN fil- og ressursbaner, og rører IKKE side-URL-er. For å gjøre dette, målrett erstatningen ved hjelp av /wp-content-mønsteret:

• //wp-standard-install.local/wp-content → //wp-standard-install.local/subdir/wp-content
• /app/public → /app/public/subdir (bane på serveren)

Etter migrering, sjekk innholdsinnlegg: lenker til andre sider på nettstedet inneholder IKKE underkatalogen (korrekt), mens innebygde bilder inneholder den (også korrekt):

Steg 3: oppdatere WordPress-adresse og flytte filer

Gå nå til Innstillinger → Generelt og legg til underkatalogen på slutten av «WordPress-adresse (URL)», for eksempel http://wp-standard-install.local/subdir. Umiddelbart etter lagring vil admin-delen bryte sammen fordi WordPress vil prøve å finne filer på den nye banen, men de er ikke der ennå:

Opprett underkatalogen subdir i den offentlige roten og flytt ALLE WordPress-filer inn i den. Kopier deretter index.php og .htaccess TILBAKE til roten slik at vedlikeholdssiden fortsetter å vises mens vi fullfører:

Gjenopprett index.php INNE i underkatalogen til fabrikktilstand: fjern html-plassholderen og fjern kommenteringen av require-linjen:

1
<?php
2
define( 'WP_USE_THEMES', true );
3
require( dirname( __FILE__ ) . '/wp-blog-header.php' );

Nå er admin-delen tilgjengelig igjen på http://wp-standard-install.local/subdir/wp-admin/:

Sjekk innholdet: bilder er på plass, stilark lastes inn:

Siste finpuss: rotens index.php

Det eneste som gjenstår er å oppdatere index.php i den offentlige roten. Fjern vedlikeholdssiden og angi riktig sti til wp-blog-header.php som tar hensyn til underkatalogen:

1
<?php
2
define( 'WP_USE_THEMES', true );
3
require( dirname( __FILE__ ) . '/subdir/wp-blog-header.php' );

Nettstedet åpnes på rot-URL-en med alle ressurser lastet fra underkatalogen:

Gå igjen til Innstillinger → Permalenker og lagre uten endringer, slik at WordPress oppdaterer URL-strukturen.

Alternative verktøy og den offisielle metoden

Fremgangsmåten beskrevet over med WP Migrate DB Pro er praktisk, men ikke det eneste alternativet. Her er andre verktøy du kan jobbe med:

• *WP-CLI search-replace.* Kommandoen wp search-replace '//oldsite.local/subdir' '//newsite.com' med flagget --dry-run vil først vise hvor mange forekomster som blir erstattet. For selektiv erstatning (rot → underkatalog), snevr inn mønsteret: wp search-replace '//newsite.com/wp-content' '//newsite.com/subdir/wp-content'.

• Offisiell WordPress-metode. Dokumentasjonen på developer.wordpress.org beskriver prosedyren «Giving WordPress Its Own Directory», med detaljerte konfigurasjoner for Apache (.htaccess), nginx (server block) og IIS (web.config). Metoden krever ingen utvidelser og fungerer på alle hostingtjenester.

• Manuell SQL. Hvis omfanget av endringer er lite, kan du kjøre UPDATE wp_posts SET post_content = REPLACE(post_content, '/subdir/', '/') direkte i phpMyAdmin, men alltid med en forutgående sikkerhetskopi, ettersom slik erstatning vil ødelegge serialiserte data i wp_options og wp_postmeta.

Uansett hvilket verktøy du velger, er regelen den samme: ved migrering ROT → UNDERKATALOG, erstatt bare /wp-content og filstier; ved migrering UNDERKATALOG → ROT, erstatt alt som refererer til underkatalogen.

⁉️🤔 Ofte stilte spørsmål

Er WP Migrate DB Pro påkrevd for denne typen migrering?

Nei. WP Migrate DB Pro tilbyr bare et praktisk grensesnitt for søk-og-erstatt med forståelse for PHP-serialiserte data. Teknisk sett kan du utføre de samme erstatningene via WP-CLI (kommandoen wp search-replace håndterer også serialiserte strenger korrekt) eller bruke den offisielle WordPress-metoden med manuell filoverføring og redigering av index.php. Utvidelsen sparer tid på store og mellomstore prosjekter med mange forekomster.

Hva bør jeg gjøre hvis noen bilder fortsatt ikke lastes inn etter migrering?

Den vanligste årsaken: hardkodede URL-er med absolutte stier fra den gamle serveren ligger igjen i databasen og traff ikke erstatningsmønsteret. Sjekk innholdsdata via phpMyAdmin: SELECT ID, post_content FROM wp_posts WHERE post_content LIKE '%/subdir/%' (eller det gamle domenet). Den andre kandidaten er nettleser- og CDN-cache: tøm begge og sjekk i inkognitomodus.

Må jeg oppdatere.htaccess etter overføringen?

Hvis du bruker pene permalenker, ja, men WordPress gjør dette automatisk når du klikker «Lagre» på siden Innstillinger → Permalenker. Hvis serveren mangler skrivetillatelser, vil WordPress vise det ferdige.htaccess-innholdet slik at du kan kopiere det manuelt. Ved migrering til en underkatalog, sørg for at rotens.htaccess (ikke den inne i underkatalogen) ikke inneholder regler som kommer i konflikt med den nye strukturen.

Er det mulig å utføre migreringen uten nedetid?

Teknisk sett ja, hvis du bruker metoden med.htaccess-viderekoblinger (Metode I fra den offisielle WordPress-dokumentasjonen, «Without changing URLs»). Med denne tilnærmingen flyttes filene til underkatalogen mens rotens.htaccess sømløst dirigerer alle forespørsler til den nye plasseringen. Besøkende merker ikke flyttingen. Ulempen: du forblir på samme domene, og nettstedets URL endres formelt sett ikke (underkatalogen er ikke synlig i adressefeltet).

Hvorfor støtter ikke WP Migrate DB Pro migrering mellom ulike installasjonstyper ut av boksen?

Utviklerne i Delicious Brains diskuterte dette på GitHub i nesten tre år. Roten til problemet: utvidelsen bruker ETT søk-og-erstatt-par på HELE databasen, men migrering mellom rot og underkatalog krever ULIKE erstatninger for ulike URL-grupper (sider kontra ressurser). Å automatisk avgjøre hvilken URL som tilhører hvilken gruppe ville kreve parsing av innholdsstrukturen, noe som går utover enkel søk-og-erstatt. Derfor er den nåværende anbefalingen: bring nettsteder til et enhetlig installasjonsskjema FØR migrering.

Bunnlinjen: rotmappe eller undermappe?

Valget mellom rotmappe og undermappe for WordPress-installasjonen koker i bunn og grunn ned til én avveining. Installasjon i rotmappen er enklere: færre bevegelige deler, direkte kompatibilitet mellom dev og produksjon, ingen overraskelser med doble URL-er. Installasjon i undermappe er arkitektonisk renere: kjernefilene er isolert, bare index.php ligger i roten, det er enklere å oppdatere WordPress via Git/Composer, og det er tryggere å drifte flere applikasjoner på ett domene.

Har du ett produksjonsnettsted og ett dev-nettsted, bør du bringe begge over på en enhetlig ordning (velg én av dem) og glemme problemet. Jobber du i et team der noen prosjekter historisk ligger i rotmappen mens andre ligger i undermapper, kjenner du nå de nøyaktige søk-og-erstatt-mønstrene for hver retning.

Hovedregelen det er verdt å bokmerke: når du migrerer ROTMAPPE → UNDERMAPPE, berører du bare /wp-content og filstier; når du migrerer UNDERMAPPE → ROTMAPPE, erstatter du alt som inneholder undermappen. Og klikk alltid, alltid på «Lagre» under Permalenker etter flyttingen.