En bekant situation: du sätter upp en utvecklingssajt, bygger klart temat, kopplar innehåll via WP Migrate DB Pro och upptäcker efter push att stylingen är trasig, bilder saknas och wp-admin inte fungerar. Orsaken är nästan alltid densamma: produktion ligger i roten medan dev ligger i en underkatalog (eller tvärtom), och en enkel sök-ersätt av URL:er i databasen löser inte denna skillnad.

Problemet är djupare än det verkar: i en rotinstallation använder WordPress samma domän för alla länkar (både till sidor och till mediafiler). I en underkataloginstallation kommer innehållslänkar från webbplatsadressen, medan resurslänkar (css, js, bilder) kommer från WordPress-adressen. En standard sök-ersätt över databasen ersätter allt enhetligt och förstör hälften av sökvägarna.

I den här guiden hittar du två beprövade migreringsvägar (dit och tillbaka) med specifika sök-ersätt-inställningar, förberedelse av wp-config.php och rätt filöverföringssekvens. Efter läsning kommer du antingen att föra dev och produktion till ett enhetligt upplägg eller medvetet genomföra en migrering mellan olika installationstyper utan trasig frontend.

💡 Snabb översikt:

• Fastställ din installationstyp: matchar "WordPress-adress" och "Webbplatsadress" under Inställningar → Allmänt
• För migrering från underkatalog till rot: hårdkoda WP_SITEURL i wp-config, utför en /subdir → /-ersättning i databasen, flytta filer en nivå upp, uppdatera rotens index.php
• För migrering från rot till underkatalog: ersätt endast sökvägar till /wp-content i databasen, uppdatera WordPress-adressen i inställningarna, skapa underkatalogen, kopiera index.php och .htaccess tillbaka till roten
• Efter varje migrering, gå till Inställningar → Permalänkar och klicka på "Spara": detta återbygger URL-strukturen och rensar cachen

Hur du avgör var WordPress är installerat

Om du installerade WordPress manuellt minns du förmodligen om det var i domänroten eller en underkatalog som /wp eller /blog. Men om sajten togs över från en tidigare utvecklare, driftsattes av webbhotellet med ett klick, eller om flera år har gått, bleknar detaljerna.

Det snabbaste sättet: gå till WordPress admin, öppna Inställningar → Allmänt och titta på fälten "WordPress-adress (URL)" och "Webbplatsadress (URL)". Om värdena matchar har du en rotinstallation:

Om fälten skiljer sig åt är WordPress installerat i en underkatalog (i exemplet nedan är detta /subdir):

Ett ytterligare tecken på en underkataloginstallation: när du loggar in i admin innehåller URL:en en underkatalog, till exempel example.com/wp/wp-admin/ istället för example.com/wp-admin/.

Varför du inte bara kan överföra direkt

Roten till problemet ligger i det dubbla URL-system som WordPress använder vid underkataloginstallationer. Låt oss bryta ner det med konkreta exempel.

Anta att du har en rotinstallation på example.com. Absolut alla länkar i databasen, både till ett inlägg /2025/about-page och till en bild /wp-content/uploads/photo.jpg, börjar med //example.com. En standard sök-ersätt //example.local → //example.com fungerar perfekt.

Ta nu en installation i underkatalogen /wp. Länken till samma inlägg ser ut som //example.com/about-page (via webbplatsadressen), medan länken till samma bild är //example.com/wp/wp-content/uploads/photo.jpg (via WordPress-adressen med underkatalogen). En enkel ersättning //example.local → //example.com kommer att förstöra mediafiler: systemet letar efter dem utan /wp i sökvägen och får en 404.

Tabellen nedan visar vilka URL-grupper som behöver uppdateras i varje migreringsriktning:

Förutom databasen måste du fysiskt flytta filer och uppdatera index.php i roten, annars hittar inte WordPress wp-blog-header.php. Nu går vi igenom båda vägarna steg för steg.

Metod 1: flytta WordPress från underkatalog till rot

Det här är den enklare riktningen: du tar bort underkatalogen från sökvägarna, och alla URL:er blir "platta", som i en standardinstallation.

Steg 0: diagnostisera vad som kommer att gå fel

Innan du ingriper är det bra att se problemets omfattning med egna ögon. Skärmdumpen nedan visar migreringsinställningar från wp-in-a-subdirectory.local (WordPress i /subdir) till wp-standard-install.local (rotinstallation). Inställningarna i WP Migrate DB Pro är standard, plus ett ersättning av webbplatsens titel för demonstration:

Resultatet är förutsägbart uselt: sidor öppnas men utan stilmallar och med trasiga bilder:

I HTML-koden kan du se resurslänkar med en död /subdir-sökväg som inte längre finns på målservern. Ett försök att nå wp-admin orsakar en omdirigering till wp-standard-install.local/subdir/wp-login.php, men den filen finns inte. Nu ska vi åtgärda detta.

Steg 1: förberedelse

Skydda först admin-åtkomsten under migreringen. Lägg till konstanter i wp-config.php som åsidosätter inställningar från databasen, så att WordPress fortsätter att släppa in dig i admin via den gamla sökvägen med underkatalogen, även efter att vi har rensat databasen:

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

Sätt sedan webbplatsen i underhållsläge: redigera index.php i den publika roten, kommentera bort raden require( dirname( __FILE__ )... och infoga efter den avslutande ?>-taggen en html-platshållare med ett kort meddelande om driftstopp. Besökare kommer att se detta:

Under tiden fortsätter du att nå admin på http://wp-in-a-subdirectory.local/subdir/wp-admin/ eftersom konstanten WP_SITEURL fungerar.

Steg 2: sök och ersätt i databasen

Rensa nu databasen. Kör en sök-ersätt med dessa par (visas i WP Migrate DB Pro-gränssnittet, men samma princip fungerar med WP-CLI search-replace eller SQL-frågor via phpMyAdmin):

• //wp-in-a-subdirectory.local/subdir → //wp-in-a-subdirectory.local
• /app/public/subdir → /app/public (sökväg på servern)

Direkt efter migreringen ändras inte utseendet (underhållssidan ligger fortfarande uppe, admin fungerar via den hårdkodade konstanten). Men om du tittar på innehållet i inläggen så laddas inte bilderna än, och interna länkar har "tappat" underkatalogen, vilket är precis vad vi ville i det här skedet:

Steg 3: fysisk filöverföring

Ta bort (eller kommentera ut) raderna med WP_SITEURL och WP_HOME i wp-config.php. Admin kommer nu att sluta fungera, så flytta omedelbart filerna från underkatalogen en nivå upp.

Via SSH eller kommandorad på servern görs detta med tre kommandon:

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

Via FTP eller webbhotellets filhanterare drar du allt innehåll från underkatalogen till webbroten och ersätter index.php:

Klart. Webbplatsen öppnas på rot-URL:en; bilder och stilmallar är på plats:

Sista finjusteringen: gå till admin (nu på http://wp-in-a-subdirectory.local/wp-admin utan underkatalogen), öppna Inställningar → Permalänkar och klicka på "Spara ändringar", även om du inte ändrat något. WordPress bygger om URL-strukturen och rensar cachen.

Metod 2: flytta WordPress från roten till en underkatalog

Många utvecklare anser att installera WordPress i en underkatalog är god praxis: core-filerna skräpar inte ner roten, hantering via Git/Composer förenklas och själva domänen kan användas för andra applikationer. Men att migrera en befintlig sajt till en underkatalog är objektivt sett mer komplext än det omvända, eftersom vissa länkar nu MÅSTE behålla underkatalogen medan andra inte får göra det.

Steg 0: diagnostik

Samma utgångsläge: vi provar en standardmigrering från rotinstallationen wp-standard-install.local till underkataloginstallationen wp-in-a-subdirectory.local (WordPress i /subdir):

Resultatet är helt förväntat: sidor öppnas men stilmallar och bilder går sönder eftersom /subdir inte lades till i deras sökvägar:

Till skillnad från det första scenariot fungerar länkar till inlägg och sidor korrekt (de ska inte innehålla underkatalogen). Det som går sönder är specifikt resurser (css, js, media), vars sökvägar nu måste inkludera /subdir.

Steg 1: förberedelse

I det här skedet sätter vi INTE konstanterna WP_SITEURL och WP_HOME, eftersom vår sök-ersätt inte kommer att röra dessa värden, och vi uppdaterar WordPress-adressen manuellt lite senare.

Sätt upp underhållssidan på samma sätt: kommentera ut require(...) i index.php och lägg till en html-platshållare. Besökare ser underhållsmeddelandet medan du fortsätter att komma åt admin på http://wp-standard-install.local/wp-admin/.

Steg 2: selektiv sök-ersätt i databasen

Den viktigaste skillnaden mot den första metoden: vi ersätter ENDAST fil- och resurssökvägar, och rör INTE sid-URL:er. För att göra detta, rikta ersättningen med hjälp av mönstret /wp-content:

• //wp-standard-install.local/wp-content → //wp-standard-install.local/subdir/wp-content
• /app/public → /app/public/subdir (sökväg på servern)

Efter migreringen, kontrollera inläggsinnehållet: länkar till andra sidor på sajten innehåller INTE underkatalogen (korrekt), medan inbäddade bilder innehåller den (också korrekt):

Steg 3: uppdatera WordPress-adress och flytta filer

Gå nu till Inställningar → Allmänt och lägg till underkatalogen i slutet av "WordPress-adress (URL)", till exempel http://wp-standard-install.local/subdir. Omedelbart efter att du har sparat kommer admin att sluta fungera eftersom WordPress försöker hitta filer på den nya sökvägen, men de finns inte där än:

Skapa underkatalogen subdir i den publika roten och flytta ALLA WordPress-filer till den. Kopiera sedan index.php och .htaccess TILLBAKA till roten så att underhållssidan fortsätter att visas medan vi avslutar:

Återställ index.php INUTI underkatalogen till dess fabriksskick: ta bort html-platshållaren och avkommentera require-raden:

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

Nu är admin tillgänglig igen på http://wp-standard-install.local/subdir/wp-admin/:

Kontrollera innehållet: bilder finns på plats, stilar laddas:

Sista finjusteringen: rotens index.php

Det enda som återstår är att uppdatera index.php i den publika roten. Ta bort underhållssidan och ange rätt sökväg till wp-blog-header.php med hänsyn till underkatalogen:

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

Webbplatsen öppnas på rot-URL:en med alla resurser laddade från underkatalogen:

Gå återigen till Inställningar → Permalänkar och spara utan ändringar så att WordPress uppdaterar URL-strukturen.

Alternativa verktyg och den officiella metoden

Tillvägagångssättet som beskrivs ovan med WP Migrate DB Pro är smidigt men inte det enda alternativet. Här är andra verktyg du kan arbeta med:

• *WP-CLI search-replace.* Kommandot wp search-replace '//oldsite.local/subdir' '//newsite.com' med flaggan --dry-run visar först hur många förekomster som kommer att ersättas. För selektiv ersättning (rot → underkatalog), smalna av mönstret: wp search-replace '//newsite.com/wp-content' '//newsite.com/subdir/wp-content'.

• Officiell WordPress-metod. Dokumentationen på developer.wordpress.org beskriver proceduren "Giving WordPress Its Own Directory", med detaljerade konfigurationer för Apache (.htaccess), nginx (serverblock) och IIS (web.config). Metoden kräver inga tillägg och fungerar på alla webbhotell.

• Manuell SQL. Om mängden redigeringar är liten kan du köra UPDATE wp_posts SET post_content = REPLACE(post_content, '/subdir/', '/') direkt i phpMyAdmin, men alltid med en föregående säkerhetskopia, eftersom en sådan ersättning förstör serialiserad data i wp_options och wp_postmeta.

Oavsett vilket verktyg du väljer är regeln densamma: vid migrering ROT → UNDERKATALOG, ersätt endast /wp-content och filsökvägar; vid migrering UNDERKATALOG → ROT, ersätt allt som refererar till underkatalogen.

⁉️🤔 Vanliga frågor

Krävs WP Migrate DB Pro för den här typen av migrering?

Nej. WP Migrate DB Pro erbjuder helt enkelt ett bekvämt gränssnitt för search-replace med förståelse för PHP-serialiserad data. Tekniskt sett kan du utföra samma ersättningar via WP-CLI (kommandot wp search-replace hanterar också serialiserade strängar korrekt) eller använda den officiella WordPress-metoden med manuell filöverföring och redigering av index.php. Tillägget sparar tid på stora och medelstora projekt med många förekomster.

Vad ska jag göra om vissa bilder fortfarande inte laddas efter migreringen?

Den vanligaste orsaken: hårdkodade URL:er med absoluta sökvägar från den gamla servern finns kvar i databasen och matchade inte ersättningsmönstret. Kontrollera innehållet i inlägg via phpMyAdmin: SELECT ID, post_content FROM wp_posts WHERE post_content LIKE '%/subdir/%' (eller den gamla domänen). Den andra kandidaten är webbläsarens och CDN:ens cache: rensa båda och kontrollera i inkognitoläge.

Behöver jag uppdatera.htaccess efter överföringen?

Om du använder snygga permalänkar, ja, men WordPress gör detta automatiskt när du klickar på "Spara" på sidan Inställningar → Permalänkar. Om servern saknar skrivrättigheter visar WordPress det färdiga.htaccess-innehållet så att du kan kopiera det manuellt. Vid migrering till en underkatalog, se till att rotens.htaccess (inte den inuti underkatalogen) inte innehåller regler som står i konflikt med den nya strukturen.

Är det möjligt att utföra migreringen med noll driftstopp?

Tekniskt sett ja, om du använder metoden med.htaccess-omdirigeringar (Metod I från den officiella WordPress-dokumentationen, "Without changing URLs"). Med detta tillvägagångssätt flyttas filer till underkatalogen medan rotens.htaccess sömlöst dirigerar alla förfrågningar till den nya platsen. Besökare märker inte flytten. Nackdelen: du stannar kvar på samma domän, och webbplatsens URL ändras formellt sett inte (underkatalogen syns inte i adressfältet).

Varför stöder inte WP Migrate DB Pro migrering mellan olika installationstyper direkt ur lådan?

Utvecklarna på Delicious Brains diskuterade detta på GitHub i nästan tre år. Roten till problemet: tillägget tillämpar ETT search-replace-par på HELA databasen, men migrering mellan rot och underkatalog kräver OLIKA ersättningar för olika URL-grupper (sidor vs resurser). Att automatiskt avgöra vilken URL som tillhör vilken grupp skulle kräva tolkning av innehållsstrukturen, vilket går bortom enkel search-replace. Därför är den nuvarande rekommendationen: för webbplatser till ett enhetligt installationsschema FÖRE migrering.

Slutsats: rot eller underkatalog?

Valet mellan rot och underkatalog för WordPress-installationen handlar i grunden om en enda avvägning. Rotinstallation är enklare: färre rörliga delar, direkt kompatibilitet mellan dev och produktion, inga överraskningar med dubbla URL:er. Underkataloginstallation är arkitektoniskt renare: kärnfilerna är isolerade, bara index.php ligger i roten, uppdatering av WordPress via Git/Composer är enklare och det är säkrare att driva flera applikationer på en domän.

Om du har en produktionssajt och en dev-sajt, för båda till ett enhetligt upplägg (vilket som) och glöm problemet. Om du jobbar i ett team där vissa projekt historiskt ligger i roten medan andra ligger i underkataloger vet du nu exakt vilka sök-och-ersätt-mönster som gäller för respektive riktning.

Huvudregeln värd att bokmärka: vid migrering ROT → UNDERKATALOG, rör bara /wp-content och filsökvägar; vid migrering UNDERKATALOG → ROT, ersätt allt som innehåller underkatalogen. Och klicka alltid, alltid på "Spara" under Permalänkar efter flytten.