Hvordan klone et WordPress-nettsted lokalt

Når du begynner å gjøre seriøse endringer på et nettsted -i WordPress eller i et hvilket som helst annet system- må du få inn én grunnregel før du starter: ikke eksperimenter i produksjon.

Av flere grunner:

1. Fordi resultatene kan bli katastrofale hvis du ikke helt vet hva du holder på med, eller hvis du ikke har backup.
2. Fordi du, nettopp på grunn av det, kan få et ganske unødvendig stresspåslag mens du gjenoppretter alt.
3. Og fordi det bare tar en halvtime å sette opp en lokal kopi, og du kommer til å takke deg selv for det.

Jeg gjentar:

Først setter du opp en lokal kopi. Så gjør du endringer. Ikke motsatt.

Disse dagene, mens jeg har gjort store endringer på nettstedet mitt, måtte jeg gjøre det selv, så jeg benyttet anledningen til å lage denne guiden.

Nettstedet mitt hadde flere år med innhold, 250 innlegg, bilder samlet opp siden 2013 og var så stort at Duplicator stoppet halvveis to ganger før det fungerte.

Det er også med her. Feilene -og løsningene deres- inkludert.

Hva er poenget med å ha en lokal WordPress-klon?

En lokal kopi lar deg jobbe på din egen datamaskin uten å røre det ekte nettstedet.

Nyttig for å teste plugins, bytte tema, sjekke databasen, forberede en migrering, gjøre en teknisk gjennomgang, installere Polylang, endre CSS eller ødelegge ting uten at Google, brukerne dine eller kunden din merker det.

I mitt tilfelle var målet todelt:

1. Endre designet fullstendig, fra et nettsted for leadgenerering til et digitalt magasin.
2. Forberede nettstedet for AI-assistert oversettelse. En egenutviklet løsning med en viss risiko, siden den innebærer å røre flere ting samtidig.

Uansett er prosessen den samme hvis du vil rekategorisere automatisk, bytte tema, legge til en stor plugin som WooCommerce eller ganske enkelt ha et testmiljø før du rører noe alvorlig.

Verktøyene jeg har brukt

• LocalWP: for å opprette det lokale WordPress-miljøet.
• Duplicator: for å eksportere produksjonsnettstedet.
• cPanel: kontrollpanelet hos webhotellet, for å laste ned bildemappen manuelt.
• WP-CLI: inkludert i LocalWP, for å rette interne WordPress-innstillinger.

Alt gratis.

Steg-for-steg-guide for å klone WordPress lokalt

Nå som du kjenner verktøyene, går vi gjennom prosessen steg for steg. Den er litt lengre enn vanlig.

Uansett, for å gi deg en idé, på omtrent 30 minutter har du alt klart, avhengig av hvilke problemer som dukker opp. For hvis nettstedet ditt er lite og ikke gir noen feil, kan du ha det på under ti minutter.

Få investeringer er mer lønnsomme enn denne.

Steg 1: installer LocalWP

LocalWP lager lokale WordPress-installasjoner uten at du må konfigurere Apache, MySQL og PHP for hånd. Du trenger ikke XAMPP, WAMP eller LAMP.

Du installerer det, oppretter et nytt nettsted, og på to minutter har du en ren WordPress-installasjon som kjører på datamaskinen din.

I mitt tilfelle kalte jeg det yg, så LocalWP tildelte det det lokale domenet https://yg.local med dette miljøet:

Felt	Verdi
Server	nginx
PHP	8.2
Database	MySQL
WordPress	Ren installasjon

Det er nok til å komme i gang.

Steg 2: sjekk at den lokale WordPress-en åpner

Før du importerer noe, åpner du det lokale nettstedet og går inn i panelet:

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

Hvis det laster og du kan logge inn, er miljøet klart. Ikke installer noe ennå. Ikke rør innstillingene. Bare sjekk at det fungerer.

Steg 3: installer Duplicator på det ekte nettstedet

Gå inn i produksjons-WordPress-en (ikke den lokale) og installer Duplicator:

Plugins > Legg til ny > Duplicator

Installer og aktiver den.

Viktig: Duplicator installeres i produksjon. Ideen er å lage en pakke av det ekte nettstedet og deretter importere den i LocalWP.

Steg 4: lag en kopi med Duplicator

Fra produksjonspanelet går du til:

Duplicator > Packages

Lag en ny pakke med et navn som gjør det tydelig hva den er til. Jeg brukte:

yagogonzalez-copia-local-fase0

Den innledende skanningen varslet om at nettstedet var stort. Ikke noe rart på nettsteder med flere år med innhold.

Problemet kom da pakken skulle bygges:

Couldn't close zip archive

Serveren klarte ikke å lukke ZIP-arkivet.

Det betyr ikke at nettstedet har gått i stykker. Det betyr at webhotellet ikke klarte å fullføre operasjonen, sannsynligvis på grunn av størrelse, kjøretid eller minnegrenser.

Første problem å løse.

Steg 5: prøv DupArchive hvis ZIP feiler

Duplicator tilbyr et alternativ når ZIP feiler: DupArchive.

For å gjøre det må du bytte arkivmotor fra ZIP til DupArchive. Pakken genereres da som .daf i stedet for .zip.

Det endres fra:

Duplicator > Innstillinger > Sikkerhetskopier > Arkiv

Der finner du Archive Engine og endrer ZipArchive til DupArchive.

Lagre deretter endringene.

Alt klart?

Nei. Ny feil:

Den totale størrelsen på filene og databasen overstiger grensen på 500 MB

Kopien veide omtrent 1,33 GB. Det hjalp heller ikke å bare endre alt i seg selv.

Løsningen: ikke legge alt inn i pakken.

Steg 6: lag pakken uten uploads-mappen

Mappen som får størrelsen til å eksplodere i enhver WordPress med noen år bak seg, er wp-content/uploads/. 

Der ligger bilder, PDF-er, miniatyrbilder, WebP-filer og alt som er lastet opp siden første dag.

For å redusere nedlastingspakken aktiverte jeg filfiltrene i Duplicator og ekskluderte:

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

Med dette inkluderer pakken det viktige for å gjenoppbygge nettstedet: database, WordPress, tema, plugins, konfigurasjon, innlegg, sider, taksonomier, ACF, Yoast og interne innstillinger.

Bildene laster vi ned separat. Jeg forklarer hvordan i steg 8.

Steg 7: last ned Duplicator-filene

Når pakken er generert, lager Duplicator to filer:

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

Last ned begge.  

Det er disse som gjør det mulig å gjenoppbygge nettstedet lokalt. Installasjonsprogrammet tar seg av å pakke ut pakken, importere databasen, erstatte URL-er og justere stier.

Steg 8: last ned mappen uploads

Siden uploads ikke lå inne i pakken, må den lastes ned manuelt fra webhotellet.

Den vanlige stien i WordPress:

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

Hvis du har en vanlig hosting, kan du laste den ned fra filbehandleralternativene i cPanel. Det var det jeg gjorde.

Hvis du ikke kan gjøre det på denne måten, må du gjøre det på gamlemåten, ved å laste den ned via FTP eller SFTP direkte til datamaskinen med FileZilla eller lignende.

Tips: ikke komprimer mappen på serveren. Det vil igjen belaste webhotellet og kan feile på samme måte som Duplicator. Direkte nedlasting er tregere, men sikrere.

Steg 9: klargjør LocalWP for å importere kopien

Med de to Duplicator-filene lastet ned, går du tilbake til LocalWP:

1. For det lokale nettstedet: klikk på Stop site.
2. Åpne nettstedsmappen: klikk på Site folder.
3. Gå inn i app > public.
4. Slett innholdet i public (den rene WordPress-en som LocalWP opprettet).
5. Kopier de to Duplicator-filene dit.

Viktig: du må slette innholdet i public, ikke mappen public.

Mappen må finnes, og inni den skal bare de to nedlastede filene ligge:

• installer.php
• copia-local.daf

Start deretter nettstedet: klikk på Start site.

Steg 10: kjør Duplicator-installasjonsprogrammet lokalt

Åpne installasjonsprogrammet i nettleseren:

https://yg.local/installer.php

Installereren oppdager pakken og starter prosessen.

For å koble til den lokale databasen bruker du dataene fra LocalWP:

Felt	Verdi
Database Host	localhost
Database Name	local
User	root
Password	root

Siden dette var en tom lokal installasjon (den programmet setter opp som standard i starten), godtar du at Duplicator sletter den forrige databasen. 

Ingenting farlig skjer: den slettet bare den rene WordPress-installasjonen fra LocalWP, ikke det ekte nettstedet.

Deretter erstatter Duplicator URL-ene:

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

Når den er ferdig, kan du logge inn i den lokale WordPress-en.

Viktig: etter at databasen er importert, er brukernavnet og passordet de samme som på det ekte nettstedet, ikke de som opprinnelig ble opprettet i LocalWP.

Steg 11: rydd opp installasjonsfilene

Duplicator sletter vanligvis installeringsfilene når den er ferdig:

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

I produksjon er dette viktig av sikkerhetsgrunner. Lokalt er det mindre kritisk, men det er lurt å la det stå ryddig.

Sjekk at de ikke finnes etter installasjonen før du fortsetter.

Steg 12: kopier uploads til lokal WordPress

Med nettstedet stoppet (Stop site) i LocalWP, går du inn i app > public > wp-content og kopierer dit mappen uploads som du lastet ned.

Riktig struktur:

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

├── themes/

└── uploads/

    ├── 2013/

    ├── 2014/

    ...

    └── 2026/

Dette skal ikke skje:

wp-content/uploads/uploads/2026/

Den doble uploads/uploads er en klassisk feil når man komprimerer til zip før nedlasting, og den ødelegger alle bildestiene.

Steg 13: rett problemet med ødelagte bilder

I mitt tilfelle kom det største problemet her (fordi det var uventet): nettstedet lastet, men bildene ble ikke vist. Og det skyldtes ikke stien med dobbel upload.

Problemet lå i URL-en som WordPress genererte for bildene:

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

Alt som er markert med fet skrift, var overflødig. Riktig URL måtte være:

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

WordPress hadde lagret i innstillingen upload_path en absolutt Windows-sti:

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

For å rette det åpner du Site shell i LocalWP og kjører disse tre kommandoene én etter én:

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, dukket bildene opp etter en oppdatering.

Problemet var at det også dukket opp flere Warnings (advarsler).

Steg 14: rett synlige warnings

Som jeg sa, dukket denne warningen opp på det lokale nettstedet:

Constant WP_POST_REVISIONS already defined

Her brukte jeg ChatGPT, for jeg hadde ingen anelse om hvordan jeg skulle løse det.

Problemet kom fra functions.php i temaet, som definerte WP_POST_REVISIONS uten å sjekke om den allerede var definert et annet sted.

Rettelsen:

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

Hvis verdien er en annen hos deg, beholder du bare din egen:

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

Jeg endret det fra WordPress-temaets filbehandler (Utseende > Temafilredigering), lagret filen, og ferdig.

Steg 15: rydd opp i produksjon

Når den lokale kopien fungerer, går du tilbake til det ekte nettstedet og fjerner sporene etter Duplicator:

1. Duplicator > Packages:  slett pakkene som ble opprettet.
2. Plugins > Installerte plugins: avinstaller Duplicator.

Dette påvirker ikke den lokale kopien. Det hindrer bare at tunge pakker og unødvendige installerere blir liggende igjen i produksjon.

Det er ikke obligatorisk, men det anbefales.

Steg 16: test den lokale klonen

Sjekk flere URL-er før du fortsetter.  

I mitt tilfelle sjekket jeg:

• Forsiden.
• Et innlegg.
• En kategori.
• En underkategori.
• En tagg.

Jeg gjorde det slik fordi hver av dem bruker en forskjellig mal:

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

Fire ting å sjekke:

1. Nettstedet laster.
2. Bildene vises.
3. Designet er likt som i produksjon.
4. Interne lenker peker til yg.local, ikke til yagogonzalez.com.

Dette siste punktet er avgjørende. Hvis du klikker på en artikkel og den sender deg til produksjon, har du fortsatt URL-er som er feil erstattet.

Steg 17: opprett et gjenopprettingspunkt før du fortsetter

Dette steget er igjen valgfritt, men anbefales.

Før du begynner å gjøre endringene du trenger lokalt, eller røre noe seriøst, opprett et gjenopprettingspunkt.

I LocalWP kan du klone nettstedet:

Clone site

I mitt tilfelle lagde jeg en kopi kalt yg-pre-polylang.

Logikken:

• yg = lokalt arbeidsnettsted.
• yg-pre-polylang = ren kopi før jeg rører noe.

Hvis noe ryker, slipper jeg å gjenta hele migreringen fra produksjon fra bunnen av; da tar jeg denne rene kopien og jobber videre på den. Men ikke før jeg har klonet den igjen, selvfølgelig.

Vanlige problemer i denne prosessen

Lokale migreringer går nesten aldri perfekt på første forsøk. Her samler jeg de som dukket opp i dette tilfellet.

Duplicator-ZIP-en feilet

Feil: Couldn't close zip archive

Årsak: servergrenser (størrelse, kjøretid, minne).

Løsning: prøv DupArchive eller ekskluder tunge mapper fra pakken.

DupArchive hadde størrelsesgrense

Feil: pakken oversteg 500 MB.

Løsning: ekskluder wp-content/uploads/ og last ned den mappen separat.

Bildene lastet ikke

Årsak: WordPress brukte en absolutt Windows-sti som om den var en offentlig URL.

Løsning:

wp option delete upload_path

wp option delete upload_url_path

PHP-warning på grunn av konstant som allerede var definert

Årsak: WP_POST_REVISIONS definert to ganger i functions.php.

Løsning: pakk definisjonen inn med if ( ! defined(…) ).

Konklusjon

Hvis nettstedet ditt veier lite, gjør Duplicator alt alene. Men hvis det har år med innhold og oppsamlede bilder, er det vanlige å dele prosessen i to:

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

Og deretter sjekke stier, bilder, warnings og interne lenker før du rører noe alvorlig.

Den lokale kopien er verdiløs hvis den ikke faktisk fungerer.

Og hvis du skal røre noe ømtålig – flerspråklighet, redesign, store plugins, SEO-migreringer – er det unødvendig risikabelt å gjøre det direkte i produksjon.

Du har verktøyene. De er gratis. Og prosessen, selv om den ikke er automatisk, gjøres på en halvtime.

Husk:

Først lokalt. Så tester. Deretter produksjon. I den rekkefølgen.

Som Bale og golfen, bare brukt på WordPress.

Forresten, her er fortsettelsen på denne artikkelen: hvordan optimalisere hastigheten til WPLocal.