Wie du eine WordPress-Website lokal klonst

Wenn du anfängst, ernsthaft an einer Website zu arbeiten – in WordPress oder in irgendeinem anderen System –, musst du dir vor allem eine Grundregel einprägen: experimentiere nicht in der Produktion.

Aus mehreren Gründen:

1. Weil die Ergebnisse katastrophal sein können, wenn du nicht genau weißt, was du anfasst, oder kein Backup hast.
2. Weil du wegen genau dieser Sache, während du alles wiederherstellst, eine völlig unnötige Stressspitze erleben kannst.
3. Und weil es nur etwa eine halbe Stunde dauert, eine lokale Kopie aufzusetzen, und du dir dafür ewig dankbar sein wirst.

Ich wiederhole:

Erst erstellst du eine lokale Kopie. Dann änderst du Dinge. Nicht umgekehrt.

In diesen Tagen, in denen ich meine Website gründlich umbaue, musste ich genau das machen. Also habe ich die Gelegenheit genutzt und dieses Tutorial erstellt.

Meine Website hatte mehrere Jahre Inhalte, 250 Beiträge, seit 2013 angesammelte Bilder und genug Umfang, dass Duplicator zweimal auf halbem Weg hängen blieb, bevor es funktionierte.

Auch das ist hier drin. Fehler – und ihre Lösungen – inklusive.

Wozu ein lokaler WordPress-Klon gut ist

Mit einer lokalen Kopie kannst du auf deinem Rechner arbeiten, ohne die echte Website anzufassen.

Nützlich, um Plugins zu testen, das Theme zu wechseln, die Datenbank zu prüfen, eine Migration vorzubereiten, ein technisches Audit zu machen, Polylang zu installieren, CSS zu ändern oder Dinge kaputtzumachen, ohne dass Google, deine Nutzer oder dein Kunde es merken.

In meinem Fall hatte das Ziel zwei Seiten:

1. Das Design komplett ändern: weg von einer Leadgenerierungs-Website, hin zu einem digitalen Magazin.
2. Die Website für KI-gestützte Übersetzung vorbereiten. Eine Eigenentwicklung mit einem gewissen Risiko, weil dabei mehrere Dinge gleichzeitig angefasst werden.

Der Prozess ist jedenfalls derselbe, wenn du automatisiert neu kategorisieren, das Theme wechseln, ein großes Plugin wie WooCommerce hinzufügen oder einfach eine Testumgebung haben willst, bevor du etwas Ernstes anfasst.

Tools, die ich verwendet habe

• LocalWP: um die lokale WordPress-Umgebung zu erstellen.
• Duplicator: um die Produktionswebsite zu exportieren.
• cPanel: das Hosting-Kontrollpanel, um den Bilderordner manuell herunterzuladen.
• WP-CLI: in LocalWP enthalten, um interne WordPress-Optionen zu korrigieren.

Alles kostenlos.

Schritt-für-Schritt-Anleitung, um dein WordPress lokal zu klonen

Jetzt, wo du die Tools kennst, gehen wir Schritt für Schritt durch den Prozess. Der ist etwas länger als üblich.

Zur Orientierung: In ungefähr 30 Minuten hast du alles fertig, je nachdem, welche Probleme auftauchen. Wenn deine Website klein ist und keine Fehler macht, kann es auch in weniger als zehn Minuten erledigt sein.

Wenige Investitionen zahlen sich stärker aus als diese.

Schritt 1: LocalWP installieren

LocalWP erstellt lokale WordPress-Installationen, ohne dass du Apache, MySQL und PHP von Hand konfigurieren musst. Du brauchst weder XAMPP noch WAMP noch LAMP.

Du installierst es, erstellst eine neue Website, und nach zwei Minuten läuft ein sauberes WordPress auf deinem Rechner.

In meinem Fall habe ich sie yggenannt, deshalb hat LocalWP ihr die lokale Domain https://yg.local mit dieser Umgebung zugewiesen:

Feld	Wert
Server	nginx
PHP	8.2
Datenbank	MySQL
WordPress	Saubere Installation

Das reicht für den Anfang.

Schritt 2: Prüfen, ob das lokale WordPress öffnet

Bevor du irgendetwas importierst, öffne die lokale Website und gehe ins Backend:

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

Wenn die Seite lädt und du dich anmelden kannst, ist die Umgebung bereit. Installiere noch nichts. Ändere keine Einstellungen. Prüfe nur, ob es funktioniert.

Schritt 3: Duplicator auf der echten Website installieren

Logge dich in das WordPress der Produktionswebsite ein (nicht in die lokale Installation) und installiere Duplicator:

Plugins > Neues Plugin hinzufügen > Duplicator

Installiere und aktiviere es.

Wichtig: Duplicator wird in der Produktion installiert. Die Idee ist, ein Paket der echten Website zu erzeugen und es danach in LocalWP zu importieren.

Schritt 4: Eine Kopie mit Duplicator erstellen

Gehe im Produktions-Backend zu:

Duplicator > Packages

Erstelle ein neues Paket mit einem Namen, der klar macht, wofür es gedacht ist. Ich habe verwendet:

yagogonzalez-copia-local-fase0

Der erste Scan warnte, dass die Website groß sei. Nichts Ungewöhnliches bei Websites mit jahrelangen Inhalten.

Das Problem kam beim Erstellen des Pakets:

Couldn't close zip archive

Der Server konnte das ZIP-Archiv nicht schließen.

Das bedeutet nicht, dass die Website kaputtgegangen ist. Es bedeutet, dass das Hosting den Vorgang nicht abschließen konnte, vermutlich wegen Größe, Ausführungszeit oder Speicherlimits.

Das erste Problem, das gelöst werden musste.

Schritt 5: DupArchive testen, wenn ZIP fehlschlägt

Duplicator bietet eine Alternative, wenn ZIP fehlschlägt: DupArchive.

Dafür musst du die Archiv-Engine von ZIP auf DupArchive umstellen. Das Paket wird dann als .daf statt als .zip erzeugt.

Geändert wird das hier:

Duplicator > Einstellungen > Backups > Archiv

Dort suchst du nach Archive Engine und änderst ZipArchive auf DupArchive.

Speichere danach die Änderungen.

Alles bereit?

Nun ja: nein. Neuer Fehler:

Die Gesamtgröße der Dateien und der Datenbank überschreitet das Limit von 500 MB

Die Kopie wog ungefähr 1,33 GB. Einfach alles umzustellen half also auch nicht per se.

Die Lösung: nicht alles in das Paket packen.

Schritt 6: Das Paket ohne den Ordner uploads erstellen

Der Ordner, der bei jedem WordPress mit ein paar Jahren auf dem Buckel das Gewicht explodieren lässt, ist wp-content/uploads/. 

Dort liegen Bilder, PDFs, Thumbnails, WebP-Dateien und alles, was seit dem ersten Tag hochgeladen wurde.

Um das Downloadpaket zu verkleinern, habe ich in Duplicator die Dateifilter aktiviert und Folgendes ausgeschlossen:

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

Damit enthält das Paket das Wichtige, um die Website wieder aufzubauen: Datenbank, WordPress, Theme, Plugins, Konfiguration, Beiträge, Seiten, Taxonomien, ACF, Yoast und interne Einstellungen.

Die Bilder laden wir separat herunter. Wie, erkläre ich dir gleich in Schritt 8.

Schritt 7: Die Duplicator-Dateien herunterladen

Sobald das Paket erzeugt ist, erstellt Duplicator zwei Dateien:

• installer.php
• .zip- oder .daf-Datei

Lade beide herunter.  

Mit ihnen lässt sich die Website lokal wiederaufbauen. Der Installer extrahiert das Paket, importiert die Datenbank, ersetzt URLs und passt Pfade an.

Schritt 8: Den Ordner herunterladen uploads

Da uploads nicht im Paket enthalten war, musst du ihn manuell vom Hosting herunterladen.

Der übliche Pfad in WordPress:

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

Wenn du ein normales Hosting hast, kannst du ihn über die Optionen des Dateimanagers in cPanelherunterladen. Genau das habe ich gemacht.

Wenn das über diesen Weg nicht geht, musst du es klassisch machen und ihn per FTP oder SFTP direkt auf den Rechner mit FileZilla oder einem ähnlichen Tool herunterladen.

Tipp: Komprimiere den Ordner nicht auf dem Server. Das würde dem Hosting wieder Last aufbürden und könnte genauso scheitern wie Duplicator. Der direkte Download ist langsamer, aber sicherer.

Schritt 9: LocalWP für den Import der Kopie vorbereiten

Wenn die beiden Duplicator-Dateien heruntergeladen sind, gehst du zurück zu LocalWP:

1. Für die lokale Website: klicke auf Stop site.
2. Öffne den Ordner der Website: klicke auf Site folder.
3. Gehe in app > public.
4. Lösche den Inhalt von public (das saubere WordPress, das LocalWP erstellt hat).
5. Kopiere dort die beiden Duplicator-Dateien hinein.

Wichtig: Du musst den Inhalt von publiclöschen, nicht den Ordner public.

Der Ordner muss existieren, und darin dürfen nur die beiden heruntergeladenen Dateien liegen:

• installer.php
• copia-local.daf

Starte danach die Website: klicke auf Start site.

Schritt 10: Den Duplicator-Installer lokal ausführen

Öffne den Installer im Browser:

https://yg.local/installer.php

Der Installer erkennt das Paket und startet den Prozess.

Für die Verbindung mit der lokalen Datenbank verwendest du die Daten von LocalWP:

Feld	Wert
Database Host	localhost
Database Name	local
User	root
Password	root

Da es eine leere lokale Installation war (die, die das Programm am Anfang standardmäßig für dich erstellt), bestätigst du, dass du akzeptierst, dass Duplicator die vorherige Datenbank löscht. 

Das ist kein Problem: Es wurde nur das saubere WordPress von LocalWP gelöscht, nicht die echte Website.

Danach ersetzt Duplicator die URLs:

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

Wenn der Vorgang fertig ist, kannst du dich bereits im lokalen WordPress anmelden.

Wichtig: Nach dem Import der Datenbank sind Benutzername und Passwort die der echten Website, nicht die, die am Anfang in LocalWP erstellt wurden.

Schritt 11: Installationsdateien bereinigen

Duplicator entfernt die Installer-Dateien normalerweise nach Abschluss:

• installer.php
• .daf-Datei
• Ordner dup-installer
• Installationslogs

In der Produktion ist das aus Sicherheitsgründen wichtig. Lokal ist es weniger kritisch, aber es ist sinnvoll, sauber aufzuräumen.

Prüfe, dass sie nach der Installation nicht mehr existieren, bevor du weitermachst.

Schritt 12: uploads in das lokale WordPress kopieren

Bei gestoppter Website (Stop site) in LocalWP gehst du in app > public > wp-content und kopierst dort den Ordner uploads hinein, den du heruntergeladen hast.

Die richtige Struktur:

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

├── themes/

└── uploads/

    ├── 2013/

    ├── 2014/

    ...

    └── 2026/

Was nicht passieren darf:

wp-content/uploads/uploads/2026/

Dieses doppelte uploads/uploads ist ein klassischer Fehler, wenn man vor dem Download als ZIP komprimiert, und es zerstört alle Bildpfade.

Schritt 13: Das Problem mit den kaputten Bildern korrigieren

In meinem Fall kam hier das dickste Problem (weil unerwartet): Die Website lud, aber die Bilder wurden nicht angezeigt. Und es lag nicht am Pfad mit doppeltem upload.

Das Problem lag in der URL, die WordPress für die Bilder erzeugte:

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

Alles, was fett markiert ist, war überflüssig. Die richtige URL musste lauten:

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

WordPress hatte in der Option upload_path einen absoluten Windows-Pfad gespeichert:

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

Um das zu korrigieren, öffnest du Site shell in LocalWP und führst diese drei Befehle nacheinander aus:

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

Als das erledigt war, erschienen die Bilder nach dem Neuladen wieder.

Das Problem: Es erschienen auch mehrere Warnings (Warnhinweise).

Schritt 14: Sichtbare Warnings korrigieren

Wie gesagt, auf der lokalen Website erschien diese Warning:

Constant WP_POST_REVISIONS already defined

Hier habe ich ChatGPT gefragt, weil ich keine Ahnung hatte, wie ich es lösen sollte.

Das Problem kam aus der functions.php des Themes, die WP_POST_REVISIONS definierte, ohne zu prüfen, ob es an anderer Stelle bereits definiert war.

Die Korrektur:

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

Wenn der Wert in deinem Fall ein anderer ist, behalte einfach deinen bei:

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

Ich habe es im Dateimanager des WordPress-Themes geändert (Design > Theme-Datei-Editor), die Datei gespeichert und fertig.

Schritt 15: Produktion bereinigen

Wenn die lokale Kopie funktioniert, gehst du zurück zur echten Website und entfernst die Spuren von Duplicator:

1. Duplicator > Packages:  lösche die erstellten Pakete.
2. Plugins > Installierte Plugins: deinstalliere Duplicator.

Das wirkt sich nicht auf die lokale Kopie aus. Es verhindert nur, dass schwere Pakete und unnötige Installer in der Produktion liegen bleiben.

Es ist nicht zwingend, aber empfehlenswert.

Schritt 16: Den lokalen Klon testen

Prüfe mehrere URLs bevor du weitermachst.  

In meinem Fall habe ich geprüft:

• Die Startseite.
• Einen Beitrag.
• Eine Kategorie.
• Eine Unterkategorie.
• Ein Schlagwort.

Ich habe das so gemacht, weil jede davon eine andere Vorlage verwendet:

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

Vier Dinge solltest du prüfen:

1. Die Website lädt.
2. Die Bilder werden angezeigt.
3. Das Design ist dasselbe wie in der Produktion.
4. Die internen Links zeigen auf yg.local, nicht auf yagogonzalez.com.

Dieser letzte Punkt ist entscheidend. Wenn du auf einen Artikel klickst und in der Produktion landest, hast du noch URLs, die falsch ersetzt wurden.

Schritt 17: Vor dem Weitermachen einen Wiederherstellungspunkt erstellen

Dieser Schritt ist wieder optional, aber empfehlenswert.

Bevor du lokal mit den nötigen Änderungen beginnst oder irgendetwas Ernstes anfasst, erstelle einen Wiederherstellungspunkt.

In LocalWP kannst du die Website klonen:

Clone site

In meinem Fall habe ich eine Kopie namens yg-pre-polylang.

Die Logik:

• yg = lokale Arbeitswebsite.
• yg-pre-polylang = saubere Kopie, bevor irgendetwas angefasst wird.

Wenn etwas kracht, musst du nicht die ganze Migration aus Produktion wieder von vorn machen, sondern ich nehme diese saubere Kopie und arbeite darauf weiter. Natürlich nicht, ohne sie vorher noch einmal geklont zu haben, klar.

Typische Probleme in diesem Prozess

Lokale Migrationen laufen fast nie beim ersten Mal perfekt. Ich fasse dir hier die Probleme zusammen, die in diesem Fall aufgetaucht sind.

Das ZIP von Duplicator ist fehlgeschlagen

Fehler: Couldn't close zip archive

Ursache: Serverlimits (Größe, Ausführungszeit, Speicher).

Lösung: DupArchive testen oder schwere Ordner aus dem Paket ausschließen.

DupArchive hatte ein Größenlimit

Fehler: Das Paket war größer als 500 MB.

Lösung: Ausschließen von wp-content/uploads/ und diesen Ordner separat herunterladen.

Die Bilder luden nicht

Ursache: WordPress verwendete einen absoluten Windows-Pfad, als wäre er eine öffentliche URL.

Lösung:

wp option delete upload_path

wp option delete upload_url_path

PHP-Warning wegen bereits definierter Konstante

Ursache: WP_POST_REVISIONS zweimal definiert in functions.php.

Lösung: die Definition mit folgendem Konstrukt umschließen: if ( ! defined(…) ).

Fazit

Wenn deine Website wenig wiegt, erledigt Duplicator alles allein. Wenn sie aber jahrelange Inhalte und angesammelte Bilder hat, ist es üblich, den Prozess in zwei Teile aufzuteilen:

• Duplicator = Datenbank + WordPress + Theme + Plugins
• FTP/SFTP = Ordner uploads

Und danach Pfade, Bilder, Warnings und interne Links prüfen, bevor du etwas Ernstes anfasst.

Die lokale Kopie ist nichts wert, wenn sie nicht wirklich funktioniert.

Und wenn du etwas Heikles anfassen willst – Mehrsprachigkeit, Redesign, große Plugins, SEO-Migrationen –, es direkt in der Produktion zu tun, bedeutet unnötige Risiken.

Du hast die Tools. Sie sind kostenlos. Und der Prozess ist, auch wenn er nicht automatisch ist, in einer halben Stunde erledigt.

Denk daran:

Erst lokal. Dann testen. Danach Produktion. In genau dieser Reihenfolge.

Wie Bale und Golf, nur auf WordPress angewendet.

Übrigens: Hier lasse ich dir die Fortsetzung dieses Artikels: wie man die Geschwindigkeit von WPLocal optimiert.