WordPress lokal installieren — der Spielplatz auf dem eigenen Rechner.
Ein neues Plugin ausprobieren, ein Theme umbauen, ein Update testen: Auf der Live-Seite ist das riskant, auf einer Staging-Kopie kostet es Serverplatz. Für vieles ist die dritte Variante die beste — WordPress läuft direkt auf deinem Rechner, kostenlos, schnell und ohne dass jemand mitbekommt, wenn etwas kaputtgeht.
Eine lokale Installation ist WordPress auf dem eigenen Rechner, erreichbar nur für dich. Am einfachsten geht das mit LocalWP oder DevKinsta: installieren, Seite anlegen, fertig. Für Entwickler bieten sich Docker oder wp-env an. Eine lokale Umgebung ersetzt kein Staging — für den letzten Test vor dem Livegang braucht es die echte Serverumgebung.
Wofür lokal, wofür Staging.
| Lokal | Staging beim Hoster | |
|---|---|---|
| Kosten | Keine | Je nach Tarif |
| Geschwindigkeit | Sehr schnell | Wie der Server |
| Erreichbar für andere | Nein | Ja, mit Passwort |
| Gleiche Serverumgebung | Nein | Ja |
| Gut für | Entwickeln, Ausprobieren, Lernen, Theme-Umbau | Abnahme, letzter Test vor Livegang, Kundenfreigabe |
| E-Mails, Zahlungen | Nur simuliert | Realistisch testbar |
Die Praxis sieht meist so aus: entwickeln lokal, abnehmen auf Staging, veröffentlichen live. Bei kleinen Änderungen reicht der direkte Weg über Staging (Staging einrichten).
Die Werkzeuge im Vergleich.
- LocalWP — kostenlos, für Mac und Windows, neue Seite in zwei Klicks, PHP-Version umschaltbar, Ein-Klick-Freigabe für Kunden. Für die meisten der beste Einstieg.
- DevKinsta — ähnlich komfortabel, kostenlos, mit Anbindung an den Hoster Kinsta.
- XAMPP oder MAMP — der klassische Weg mit Apache, MySQL und PHP. Flexibel, aber du richtest WordPress selbst ein.
- Docker — sauber getrennte Umgebungen, gut wenn mehrere Projekte mit verschiedenen Versionen laufen. Mehr Einarbeitung.
- wp-env — das offizielle Werkzeug aus dem WordPress-Umfeld, praktisch beim Entwickeln von Blöcken und Plugins (Plugin-Entwicklung).
In zehn Minuten eingerichtet.
- LocalWP herunterladen und installieren.
- Neue Seite anlegen, Namen vergeben, PHP-Version und Datenbank auf der Voreinstellung lassen.
- Benutzername und Passwort für das Backend festlegen — auch lokal bitte kein „admin/admin“, denn diese Zugänge landen erstaunlich oft später auf dem Server.
- Seite starten, Backend öffnen, loslegen.
- Für Tests mit E-Mail-Versand das eingebaute Postfach nutzen: Lokale Umgebungen fangen Mails ab, statt sie wirklich zu verschicken.
Kopie der Live-Seite einspielen.
Richtig nützlich wird es, wenn lokal dieselbe Seite läuft wie live. Dafür gibt es drei Wege. Erstens ein Migrations-Plugin wie All-in-One WP Migration oder Duplicator: Paket auf der Live-Seite erzeugen, lokal einspielen, fertig. Zweitens der manuelle Weg mit Dateien und Datenbank-Export — dabei müssen die Adressen sauber ersetzt werden, am besten mit WP-CLI, weil serialisierte Daten sonst beschädigt werden (WordPress-Umzug). Drittens bieten manche Werkzeuge einen direkten Abgleich mit dem Hoster an.
# Datenbank der Live-Seite einspielen
wp db import live-export.sql
# Adressen anpassen — erst als Trockenlauf ansehen
wp search-replace 'https://deine-domain.de' 'http://deine-seite.local' --all-tables --dry-run
wp search-replace 'https://deine-domain.de' 'http://deine-seite.local' --all-tables
# Suchmaschinen fernhalten und Caches leeren
wp option update blog_public 0
wp cache flushLokale Kopien enthalten oft echte Kundendaten. Sie gehören deshalb auf einen verschlüsselten Rechner, nicht in eine Cloud-Freigabe, und werden gelöscht, wenn das Projekt fertig ist.
So arbeitet es sich angenehm.
- Debug einschalten: Lokal dürfen Fehler sichtbar sein. In der wp-config.php WP_DEBUG auf true — auf der Live-Seite bleibt es aus (Fehler beheben).
- Query Monitor installieren: zeigt Abfragen, Ladezeit und welches Plugin bremst.
- Änderungen versionieren: Wer am Theme oder an Plugins arbeitet, legt den Ordner in eine Versionsverwaltung. Dann ist jeder Schritt nachvollziehbar.
- Zahlungen im Testmodus: Shops lassen sich mit Testschlüsseln der Zahlungsanbieter durchspielen (Zahlungen).
Änderungen zurück auf die echte Seite.
Hier gilt dieselbe Regel wie beim Staging: Dateien lassen sich gefahrlos übertragen — Theme, Child-Theme, eigene Plugins. Inhalte und Datenbank nur dann komplett, wenn auf der Live-Seite seither nichts passiert ist. Bei einem Shop oder einer Seite mit Kommentaren und Bestellungen wäre das fatal. Dann werden Änderungen entweder nachgebaut oder gezielt einzelne Tabellen übertragen. Vorher immer ein Backup der Live-Seite.
Grenzen.
Lokal läuft nicht alles wie auf dem Server: Serverkonfiguration, PHP-Erweiterungen, Speicherlimits, Caching, Firewall und Mailversand unterscheiden sich. Ein Update, das lokal problemlos durchläuft, kann live an einer Servereinstellung scheitern. Deshalb gilt für kritische Änderungen — große Updates, Shop-Umbauten, Relaunch — weiterhin: letzter Test auf einer Staging-Kopie in der echten Umgebung, dann live.
Wenn du nicht weiterkommst.
Wenn du eine Umgebung brauchst, in der du gefahrlos ausprobieren kannst, richte ich dir lokal und auf Staging eine Kopie ein und zeige dir den Weg dazwischen. Ich richte das ein, prüfe die Einbindung und erkläre dir, worauf es ankommt: WordPress-Hilfe. Damit es dauerhaft sauber bleibt: WordPress-Wartung.
Wer hilft.
Ich bin Manuel Killert, WordPress-Entwickler aus Quakenbrück. Seit 2020 baue und betreue ich WordPress-Websites — für Handwerksbetriebe, Industrie, Gastronomie, Start-ups und Vereine —, entwickle eigene Plugins und unterrichte WordPress als Dozent an der KW Design Akademie. Das heißt: Ich kenne die typischen Fehler nicht nur aus Foren, sondern aus eigenen Projekten, und ich kann sie so erklären, dass du sie beim nächsten Mal selbst erkennst. Du erreichst mich direkt, ohne Ticketsystem.
Echte Projekte — live ansehen.
WordPress-Websites, die ich gebaut habe oder laufend betreue.
Markenfest
Stärkerer Online-Shop — Webdesign, Content und individuelle Shop-Funktionen.
Website ansehen ↗
KT Bodenteam
Professioneller Auftritt für einen Bodenleger — Vorher-Nachher-Slider und regionale SEO.
Website ansehen ↗
Potassco Solutions
Klare Website für ein KI-Unternehmen, die komplexe Technologie verständlich macht.
Website ansehen ↗FAQ — Lokale WordPress-Testumgebung.
Wie installiere ich WordPress lokal?
Am einfachsten mit LocalWP oder DevKinsta: Programm installieren, neue Seite anlegen, Zugangsdaten vergeben, starten. Wer mehr Kontrolle will, nutzt XAMPP, Docker oder wp-env.
Was ist der Unterschied zwischen lokal und Staging?
Lokal läuft auf dem eigenen Rechner, ist schnell und kostenlos, aber nicht für andere erreichbar und nicht die echte Serverumgebung. Staging liegt beim Hoster, ist teilbar und eignet sich für den letzten Test vor dem Livegang.
Kann ich meine Live-Seite lokal kopieren?
Ja, mit einem Migrations-Plugin wie All-in-One WP Migration oder Duplicator oder manuell über Dateien und Datenbank. Die Adressen müssen dabei sauber ersetzt werden, am besten mit WP-CLI.
Kann ich lokal E-Mails testen?
Lokale Umgebungen fangen ausgehende Mails ab und zeigen sie in einem eigenen Postfach an, statt sie wirklich zu versenden. So lassen sich Formulare und Bestellmails gefahrlos prüfen.
Kann ich lokale Änderungen einfach live übertragen?
Dateien wie Theme und eigene Plugins ja. Die Datenbank nur, wenn auf der Live-Seite seither nichts passiert ist. Bei Shops und Seiten mit laufenden Inhalten werden Änderungen stattdessen gezielt nachgezogen.
Reicht eine lokale Umgebung als Test vor einem Update?
Für einen ersten Eindruck ja. Serverkonfiguration, Speicherlimits, Caching und Mailversand unterscheiden sich aber. Der letzte Test vor dem Livegang gehört auf eine Staging-Kopie.
Das bin ich – rechts im BildErzähl mir, was nicht funktioniert.
Domain und eine kurze Beschreibung reichen — du bekommst eine ehrliche Einschätzung, was los ist und was die Behebung kostet.
Antwort meist innerhalb von 24 Stunden · hallo@manuelkillert.de