Hur du klonar en WordPress-webbplats lokalt

När du börjar pilla på allvar med en webbplats – i WordPress eller i vilket annat system som helst – måste du få in en grundregel innan du börjar: experimentera inte i produktion.

Av flera skäl:

1. För att resultatet kan bli katastrofalt om du inte riktigt vet vad du rör vid eller inte har någon backup.
2. För att du, på grund av det ovanstående och medan du återställer allt, kan få ett helt onödigt stresspåslag.
3. Och för att det bara tar en halvtimme att sätta upp en lokal kopia, och du kommer att tacka dig själv för det länge.

Jag upprepar:

Först sätter du upp en lokal kopia. Sedan ändrar du. Inte tvärtom.

De här dagarna, när jag håller på att bygga om min webbplats ordentligt, har jag behövt göra det, så jag passade på att skapa den här guiden.

Min webbplats hade flera år av innehåll, 250 inlägg, bilder som samlats sedan 2013 och tillräcklig storlek för att Duplicator fastnade halvvägs två gånger innan det fungerade.

Det finns också med här. Felen – och deras lösningar – ingår.

Vad en lokal WordPress-klon är bra för

En lokal kopia låter dig arbeta på din dator utan att röra den riktiga webbplatsen.

Användbart för att testa plugins, byta tema, granska databasen, förbereda en migrering, göra en teknisk granskning, installera Polylang, ändra CSS eller ha sönder saker utan att Google, dina användare eller din kund märker det.

I mitt fall var målet dubbelt:

1. Att ändra designen helt, från en webbplats för leadgenerering till ett digitalt magasin.
2. Att förbereda webbplatsen för AI-assisterad översättning. En egenutvecklad lösning med viss risknivå, eftersom den innebär att flera saker ändras samtidigt.

I vilket fall som helst är processen densamma om du vill kategorisera om automatiskt, byta tema, lägga till ett stort plugin som WooCommerce eller helt enkelt ha en testmiljö innan du rör något seriöst.

Verktyg jag har använt

• LocalWP: för att skapa den lokala WordPress-miljön.
• Duplicator: för att exportera produktionswebbplatsen.
• cPanel: kontrollpanelen hos webbhotellet för att ladda ner bildmappen manuellt.
• WP-CLI: ingår i LocalWP, för att korrigera interna WordPress-inställningar.

Allt gratis. 

Steg-för-steg-guide för att klona din WordPress-webbplats lokalt

Nu när du känner till verktygen går vi vidare till steg-för-steg-guiden, som är lite längre än vanligt.

För att du ska få en ungefärlig bild: på ungefär 30 minuter har du allt klart, beroende på vilka problem som dyker upp. Om din webbplats är liten och inte ger några fel kan du mycket väl vara klar på mindre än tio minuter.

Få investeringar är mer lönsamma än den här.

Steg 1: installera LocalWP

LocalWP skapar lokala WordPress-installationer utan att du behöver konfigurera Apache, MySQL och PHP för hand. Du behöver varken XAMPP, WAMP eller LAMP.

Du installerar programmet, skapar en ny webbplats och på två minuter har du en ren WordPress som körs på din dator.

I mitt fall kallade jag den yg, så LocalWP gav den den lokala domänen https://yg.local med den här miljön:

Fält	Värde
Server	nginx
PHP	8.2
Databas	MySQL
WordPress	Ren installation

Det räcker för att börja.

Steg 2: kontrollera att den lokala WordPress-installationen öppnas

Innan du importerar något, öppna den lokala webbplatsen och gå in i panelen:

• https://yg.local
• https://yg.local/wp-admin

Om den laddar och du kan logga in är miljön klar. Installera inget än. Rör inga inställningar. Kontrollera bara att den fungerar.

Steg 3: installera Duplicator på den riktiga webbplatsen

Gå in i produktions-WordPressen (inte den lokala) och installera Duplicator:

Tillägg > Lägg till nytt > Duplicator

Installera det och aktivera det.

Viktigt: Duplicator installeras i produktion. Idén är att skapa ett paket av den riktiga webbplatsen och sedan importera det i LocalWP.

Steg 4: skapa en kopia med Duplicator

Gå från produktionspanelen till:

Duplicator > Packages

Skapa ett nytt paket med ett namn som visar vad det är till för. Jag använde:

yagogonzalez-copia-local-fase0

Den första genomsökningen varnade för att webbplatsen var stor. Inget konstigt på webbplatser med många års innehåll.

Problemet kom när paketet skulle byggas:

Couldn't close zip archive

Servern kunde inte stänga ZIP-filen. 

Det betyder inte att webbplatsen gick sönder. Det betyder att webbhotellet inte kunde slutföra åtgärden, troligen på grund av storlek, körningstid eller minnesgränser.

Första problemet att lösa.

Steg 5: prova DupArchive om ZIP misslyckas

Duplicator erbjuder ett alternativ när ZIP misslyckas: DupArchive.

För det behöver du byta arkivmotor från ZIP till DupArchive. Paketet genereras då som .daf i stället för .zip.

Så här ändrar du det:

Duplicator > Inställningar > Säkerhetskopior > Arkiv

Där letar du efter Archive Engine och ändrar ZipArchive till DupArchive.

Spara sedan ändringarna.

Klart?

Nja, nej. Nytt fel:

Den totala storleken på filerna och databasen överskrider gränsen på 500 MB

Kopian vägde ungefär 1,33 GB. Det hjälpte alltså inte heller att bara byta allt rakt av.

Lösningen: att inte lägga allt i paketet.

Steg 6: skapa paketet utan uploads-mappen

Mappen som drar upp vikten i vilken WordPress som helst med några år på nacken är wp-content/uploads/. 

Där finns bilder, PDF:er, miniatyrer, WebP och allt som har laddats upp sedan första dagen.

För att minska nedladdningspaketet aktiverade jag filtren för filer i Duplicator och exkluderade:

• wp-content/uploads/
• wp-content/cache/
• wp-content/upgrade/
• wp-content/backups-dup-lite/
• wp-content/plugins/duplicator/backups/

Med detta innehåller paketet det viktigaste för att bygga upp webbplatsen igen: databas, WordPress, tema, plugins, konfiguration, inlägg, sidor, taxonomier, ACF, Yoast och interna inställningar. 

Bilderna laddar vi ner separat. Jag förklarar hur i steg 8.

Steg 7: ladda ner Duplicator-filerna

När paketet har skapats genererar Duplicator två filer:

• installer.php
• .zip- eller .daf-fil

Ladda ner båda.  

Det är de som gör det möjligt att återskapa webbplatsen lokalt. Installationsprogrammet sköter extrahering av paketet, import av databasen, ersättning av URL:er och justering av sökvägar.

Steg 8: ladda ner mappen uploads

Eftersom uploads inte låg i paketet måste den laddas ner manuellt från webbhotellet.

Den vanliga sökvägen i en WordPress:

/public_html/tudominio.com/wp-content/uploads/

Om du har ett normalt webbhotell kan du ladda ner den från alternativen i cPanels filhanterare. Det var det jag gjorde.

Om det inte går den vägen får du göra det på det gamla sättet, genom att ladda ner den via FTP eller SFTP direkt till datorn med FileZilla eller liknande.

Tips: komprimera inte mappen på servern. Det skulle åter belasta webbhotellet och kan misslyckas precis som Duplicator. Direkt nedladdning är långsammare, men säkrare.

Steg 9: förbered LocalWP för att importera kopian

Med de två Duplicator-filerna nedladdade går du tillbaka till LocalWP:

1. För den lokala webbplatsen: klicka på Stop site.
2. Öppna webbplatsens mapp: klicka på Site folder.
3. Gå in i app > public.
4. Ta bort innehållet i public (den rena WordPress som LocalWP skapade).
5. Kopiera dit de två Duplicator-filerna.

Viktigt: du ska ta bort innehållet i public, inte mappen public.

Mappen måste finnas kvar och inuti ska bara de två nedladdade filerna ligga:

• installer.php
• copia-local.daf

Starta sedan webbplatsen: klicka på Start site.

Steg 10: kör Duplicators installer lokalt

Öppna installern i webbläsaren:

https://yg.local/installer.php

Installern upptäcker paketet och startar processen.

För att ansluta till den lokala databasen använder du uppgifterna från LocalWP:

Fält	Värde
Database Host	localhost
Database Name	local
User	root
Password	root

Eftersom det var en tom lokal installation (den som programmet sätter upp åt dig som standard i början), godkänn att Duplicator får radera den tidigare databasen. 

Det gör inget: den raderade bara den rena WordPressen från LocalWP, inte den riktiga webbplatsen.

Därefter gör Duplicator URL-ersättningen:

• Old URL: https://yagogonzalez.com
• New URL: https://yg.local

När det är klart kan du logga in i den lokala WordPressen.

Viktigt: efter att databasen importerats är användarnamn och lösenord de från den riktiga webbplatsen, inte de som skapades i början i LocalWP.

Steg 11: rensa installationsfilerna

Duplicator tar normalt bort installerfilerna när den är klar:

• installer.php
• .daf-fil
• mappen dup-installer
• installationsloggar

I produktion är det viktigt av säkerhetsskäl. Lokalt är det mindre kritiskt, men det är bra att lämna det rent.

Kontrollera att de inte finns kvar efter installationen innan du fortsätter.

Steg 12: kopiera uploads till den lokala WordPressen

Med webbplatsen stoppad (Stop site) i LocalWP, gå in i app > public > wp-content och kopiera dit mappen uploads som du laddade ner.

Rätt struktur:

<em>wp-content/</em>
├── plugins/

├── themes/

└── uploads/

    ├── 2013/

    ├── 2014/

    ...

    └── 2026/

Det som inte ska hända:

wp-content/uploads/uploads/2026/

Den där dubbla uploads/uploads är ett klassiskt fel när man zippar innan nedladdning och det bryter alla sökvägar till bilderna.

Steg 13: fixa problemet med trasiga bilder

I mitt fall kom det största problemet här (för att det var oväntat): webbplatsen laddade, men bilderna syntes inte. Och det berodde inte på sökvägen med dubbla upload.

Problemet låg i URL:en som WordPress genererade för bilderna:

https://yg.local/C:/Users/pcadmin/Local Sites/yg/app/public/wp-content/uploads/2026/06/imagen.webp

Allt som är markerat i fetstil var överflödigt. Den korrekta URL:en behövde vara:

https://yg.local/wp-content/uploads/2026/06/imagen.webp

WordPress hade sparat i alternativet upload_path en absolut Windows-sökväg:

C:/Users/pcadmin/Local Sites/yg/app/public/wp-content/uploads

För att rätta det, öppna Site shell i LocalWP och kör de här tre kommandona ett efter ett:

wp --url=https://yg.local option delete upload_path

wp --url=https://yg.local option delete upload_url_path 

wp --url=https://yg.local cache flush

När det var gjort och sidan laddades om syntes bilderna igen.

Problemet var att det också dök upp flera Warnings (varningar).

Steg 14: fixa synliga warnings

Som jag sa dök den här varningen upp på den lokala webbplatsen:

Constant WP_POST_REVISIONS already defined

Här tog jag hjälp av ChatGPT, för jag hade ingen aning om hur jag skulle lösa det.

Problemet kom från functions.php i temat, som definierade WP_POST_REVISIONS utan att kontrollera om den redan var definierad någon annanstans.

Rättelsen:

<em>if ( ! defined( 'WP_POST_REVISIONS' ) ) {</em>
<em>    define( 'WP_POST_REVISIONS', false );</em>
<em>}</em>

Om värdet i ditt fall är ett annat, behåll bara ditt:

<em>if ( ! defined( 'WP_POST_REVISIONS' ) ) {</em>
<em>    define( 'WP_POST_REVISIONS', <strong>5</strong> );</em>
<em>}</em>

Jag ändrade det från WordPress-temats filhanterare (Utseende > Temafilredigerare), sparade filen och klart.

Steg 15: rensa produktion

När den lokala kopian fungerar, gå tillbaka till den riktiga webbplatsen och ta bort spåren av Duplicator:

1. Duplicator > Packages:  ta bort paketen som skapats.
2. Plugins > Installerade plugins: avinstallera Duplicator.

Det påverkar inte den lokala kopian. Det förhindrar bara att tunga paket och onödiga installationsfiler ligger kvar i produktion.

Det är inte obligatoriskt, men rekommenderas.

Steg 16: testa den lokala klonen

Kontrollera flera URL:er innan du fortsätter.  

I mitt fall gick jag igenom:

• Startsidan.
• Ett inlägg.
• En kategori.
• En underkategori.
• En tagg.

Jag gjorde det så eftersom var och en använder en annan mall:

• https://yg.local
• https://yg.local/ruta-de-escape
• https://yg.local/tecnologia
• https://yg.local/ocio/series
• https://yg.local/negocio

Fyra saker att kontrollera:

1. Webbplatsen laddar.
2. Bilderna visas.
3. Designen är densamma som i produktion.
4. De interna länkarna pekar på yg.local, inte på yagogonzalez.com.

Den sista punkten är avgörande. Om du klickar på ett inlägg och hamnar i produktion har du fortfarande URL:er som ersatts fel.

Steg 17: skapa en återställningspunkt innan du fortsätter

Det här steget är återigen valfritt, men rekommenderas.

Innan du börjar göra de ändringar du behöver lokalt eller rör något seriöst, skapa en återställningspunkt.

I LocalWP kan du klona webbplatsen:

Clone site

I mitt fall skapade jag en kopia som hette yg-pre-polylang.

Logiken:

• yg = lokal arbetswebbplats.
• yg-pre-polylang = ren kopia innan något rörs.

Om något brakar behöver du inte göra om hela migreringen från produktion från början, utan jag tar den här rena kopian och arbetar vidare på den. Inte utan att först ha klonat den igen, förstås.

Vanliga problem i den här processen

Lokala migreringar blir nästan aldrig perfekta på första försöket. Här samlar jag de som dök upp i det här fallet.

ZIP-filen från Duplicator misslyckades

Fel: Couldn't close zip archive

Orsak: serverbegränsningar (storlek, körningstid, minne).

Lösning: prova DupArchive eller exkludera tunga mappar från paketet.

DupArchive hade storleksgräns

Fel: paketet överskred 500 MB.

Lösning: exkludera wp-content/uploads/ och ladda ner den mappen separat.

Bilderna laddades inte

Orsak: WordPress använde en absolut Windows-sökväg som om den vore en offentlig URL.

Lösning:

wp option delete upload_path

wp option delete upload_url_path

PHP-warning för redan definierad konstant

Orsak: WP_POST_REVISIONS definierad två gånger i functions.php.

Lösning: slå in definitionen med if ( ! defined(…) ).

Slutsats

Om din webbplats väger lite gör Duplicator allt själv. Men om den har år av innehåll och samlade bilder är det normala att dela processen i två:

• Duplicator = databas + WordPress + tema + plugins
• FTP/SFTP = uploads-mappen

Och sedan kontrollera sökvägar, bilder, warnings och interna länkar innan du rör något seriöst.

Den lokala kopian är värdelös om den inte faktiskt fungerar.

Och om du ska röra något känsligt – flerspråkighet, redesign, stora plugins, SEO-migreringar – är det onödigt riskabelt att göra det direkt i produktion. 

Du har verktygen. De är gratis. Och även om processen inte är automatisk görs den på en halvtimme.

Kom ihåg:

Först lokalt. Sedan tester. Därefter produktion. I den ordningen.

Som Bale och golf, fast tillämpat på WordPress.

Förresten, här lämnar jag fortsättningen på den här artikeln: hur du optimerar hastigheten i WPLocal.