WordPress in statisches HTML umwandeln: alle Methoden im Vergleich (2026)

Das hier ist der Schwesterartikel zu unserem großen Leitfaden WordPress auf eine statische Seite migrieren. Der deckt den kompletten Umzug ab. Dieser zoomt auf den Teil, nach dem tatsächlich gesucht wird: die Umwandlungs-Tools. Welches Export-Tool solltest du nehmen, was liefert es, und was ist am Morgen danach los.

Was "WordPress in statisches HTML umwandeln" wirklich heißt

Eine normale WordPress-Seite existiert erst, wenn jemand sie aufruft. Ein Besucher öffnet eine URL, PHP wacht auf, fragt die MySQL-Datenbank ab, führt dein Theme und jedes aktive Plugin aus und setzt daraus eine HTML-Seite zusammen. Danach wirft es sie weg und macht dasselbe für den nächsten Besucher.

In statisches HTML umwandeln heißt: diese Arbeit einmal vorab erledigen und das Ergebnis als ganz normale .html-Dateien speichern, mit CSS, Bildern und JavaScript daneben. Der Webserver reicht diese Dateien dann einfach durch. Kein PHP, keine Datenbank, keine Plugins zur Laufzeit. Deshalb laden statische Seiten in Millisekunden, und deshalb bleibt kaum noch etwas zum Hacken übrig, die zwei großen Gründe für den Wechsel (mehr dazu in Vorteile und Nachteile statischer Websites).

Der Haken steckt im Wort "einmal". Eine statische Datei ist ein Foto deiner Seite zum Zeitpunkt des Exports.

Die vier Methoden im Überblick

Methode 1: Simply Static oder Staatic (der Plugin-Weg)

Das meinen die meisten, wenn sie "WordPress statisch machen" sagen. Du installierst das Plugin im wp-admin, gibst ein Ziel an, und es läuft deine Seite durch und schreibt jede Seite als Datei raus.

1. Erst sichern. Ein vollständiges Backup von Dateien und Datenbank, bevor du irgendetwas anfasst.
2. Plugin installieren unter Plugins → Installieren, dann die Einstellungen öffnen.
3. Ziel-URL setzen, also die Domain, unter der die statische Seite laufen wird. Diesen Schritt überspringen viele, und genau deshalb liegen in so vielen Exporten noch absolute Links auf die alte WordPress-Domain.
4. Ergänze, was der Crawler nicht findet. Seiten, die nur über ein Formular, ein JavaScript-Menü oder ein PDF erreichbar sind, findet niemand durch Linkverfolgung. Trag sie unter "zusätzliche URLs" von Hand ein.
5. Schließe aus, was nicht mit soll: /wp-admin, Staging-Seiten, Danke-Seiten, die nicht in den Index gehören.
6. Export starten und das ZIP herunterladen.
7. Auf einen statischen Host laden, etwa Cloudflare Pages oder Netlify, und die Domain darauf zeigen lassen.

Die kostenlose Version exportiert jedes Mal die komplette Seite. Bei einer 40-Seiten-Visitenkarte sind das zwei Minuten. Bei 500 Seiten mit großen Bildergalerien kann es sehr lange dauern und in einen Timeout laufen, genau dafür gibt es in den bezahlten Stufen die inkrementellen Builds.

Methode 2: WP2Static (die Entwickler-Pipeline)

WP2Static macht im Kern dasselbe, ist aber für Leute gebaut, die mit einem Build-Prozess umgehen können: Es gibt Add-ons für das Deployment direkt zu S3, Netlify oder in ein Git-Repository und Hooks zur Nachbearbeitung. Wenn du Entwickler bist und "in WordPress veröffentlichen, statisch automatisch ausrollen" willst, kommt das dem am nächsten. Für einen Seitenbetreiber, der einfach schnellere Seiten will, ist es mehr Maschinerie als nötig.

Methode 3: Mit wget oder HTTrack crawlen

Du brauchst streng genommen gar kein Plugin. Jede öffentlich erreichbare Seite lässt sich von einem Crawler spiegeln. Der Klassiker als Einzeiler:

wget --mirror --convert-links --adjust-extension \
     --page-requisites --no-parent https://beispiel.de/

--convert-links schreibt interne Links so um, dass sie lokal funktionieren, --adjust-extension hängt bei Bedarf .html an, und --page-requisites zieht CSS, Bilder und Schriften mit. HTTrack macht dasselbe mit Oberfläche.

Für ein Archiv einer Seite, die du gleich abschaltest, ist das hervorragend, und es ist der Weg, um rechtssicher festzuhalten, was eine Seite an einem bestimmten Tag gesagt hat. Als Fundament für eine Seite, die du weiter betreibst, taugt es wenig: Das Ergebnis ist ein Gewirr aus generierten Dateinamen, die URLs bekommen oft eine .html-Endung, die deine Rankings nicht kennen, und es gibt keine Struktur zum Bearbeiten.

Methode 4: Eine Managed Migration

Der andere Weg ist, gar nicht zu exportieren, sondern die Seite als saubere statische Seiten neu aufzubauen, mit gleichem Aussehen, gleichen Inhalten und gleichen URLs, und WordPress danach ganz hinter sich zu lassen. Das ist der Unterschied zwischen Schnappschuss und Umzug, und das Einzige, was die Export-Tools nicht können. Ausführlich steht das im großen Migrations-Leitfaden, und an einer echten Seite kannst du es in der CSR-Tools-Fallstudie nachlesen: über 200 Seiten weg von WordPress und rund 7× schneller.

Export, und dann? Die acht Dinge, die das ZIP nicht löst

Das ist der Abschnitt, vor dem jede "WordPress statisch machen"-Anleitung endet. Du hast jetzt einen Ordner voller HTML-Dateien. Und diese Punkte sind ab jetzt dein Problem.

1. Kontaktformulare. Contact Form 7, Gravity Forms, WPForms schicken alle an PHP. Das nimmt niemand mehr entgegen. Ersetze sie durch einen Formular-Dienst (Formspree, Basin) oder einen gehosteten Handler, und teste eine echte Absendung, bevor du die Domain umstellst.
2. Die Seitensuche. Die WordPress-Suche ist eine Datenbankabfrage. Du brauchst stattdessen einen statischen Index (Pagefind, Lunr, Algolia) oder einen Link auf die Google-Sitesuche.
3. Kommentare. Umziehen auf Giscus, Disqus, oder weglassen. Bestehende Kommentare stecken als Nur-Lese-Text im exportierten HTML, was meistens in Ordnung ist.
4. Die Sitemap. Yoast und Rank Math erzeugen sitemap_index.xml per PHP. Mit dem Export ist sie weg. Du musst eine echte statische sitemap.xml ausliefern und in der Search Console neu einreichen.
5. Absolute URLs. Fest eingetragene https://alteseite.de/...-Links in Beitragsinhalten, Theme-Templates und Inline-CSS überleben den Export und laufen danach entweder ins 404 oder schicken stillschweigend weiter Besucher auf die alte Installation. Durchsuche die exportierten Dateien nach der alten Domain.
6. Login und Mitgliederbereiche. Alles hinter wp-login.php ist weg. Wenn du Inhalte schützt, kann statisches HTML allein das nicht.
7. Geplante und dynamische Inhalte. Geplante Beiträge erscheinen nie. "Neueste Beiträge"-Widgets, Beliebtheitszähler und dynamische Jahreszahlen frieren am Exportdatum ein.
8. Weiterleitungen. Die Regeln deines Redirect-Plugins lagen in der Datenbank. Sie müssen beim Host oder im CDN neu angelegt werden, und zwar zusammen mit jeder URL, die die Umwandlung selbst verändert hat.

Ändert die Umwandlung deine URLs?

Sie kann es, und genau da geht SEO verloren. Achte auf diese Fälle:

Googles eigene Hinweise zu Umzügen mit URL-Änderungen sind hier die Referenz: 301-Weiterleitungen übertragen fast die gesamte Autorität einer Seite auf die neue Adresse, also lass sie mindestens ein Jahr aktiv. Wenn du gleichzeitig den Host wechselst, lies vorher WordPress auf einen neuen Host umziehen, und mach nicht beide Umzüge in derselben Nacht.

Eine statische HTML-Seite nach der Umwandlung pflegen

Jetzt der ehrliche Teil. Ein Plugin-Export bringt dir sofort Tempo und Sicherheit, aber das Bearbeiten wird schwerer, nicht leichter. Du hast ab jetzt zwei Systeme: WordPress, das du weiter installierst, aktualisierst und absicherst, weil es dein Redaktionssystem ist, und die statische Ausgabe, die die Welt sieht. Jeder Tippfehler heißt: ändern, neu exportieren, neu ausrollen.

Da gibt es drei Auswege:

• Das HTML direkt bearbeiten. Okay, wenn du technisch bist und die Seite sich selten ändert. Nicht okay, wenn jemand anderes die Öffnungszeiten aktualisieren muss.
• Mit einem Static-Site-Generator neu bauen, etwa Astro, Hugo oder Eleventy, mit einem Git-basierten CMS obendrauf. Sauber und schnell, aber das ist ein Entwicklungsprojekt, kein Nachmittag.
• Eine Managed-Plattform nutzen, die die statische Seite bearbeitbar hält. Genau das macht der KI-Editor von ShiftPress: Deine Seite liegt als statische Seiten vor, und du änderst sie, indem du beschreibst, was du willst ("tausch das Hero-Bild", "aktualisiere die Preise auf allen Leistungsseiten"). Du siehst eine Vorschau jeder betroffenen Seite, gibst sie frei, und sie geht live, mit Rückgängig per Klick. Ohne WordPress darunter.

Und deshalb empfehlen wir auch nicht, stattdessen ein KI-Plugin auf WordPress zu schrauben, was wir in Claude mit WordPress verbinden und WordPress und KI ausführlich begründen.

Welche Methode solltest du nehmen?

• Eine Seite archivieren, die du abschaltest? wget. Zwei Minuten, fertig.
• Eine kleine Seite, die sich wirklich nie ändert (eine Veranstaltungsseite, ein Onepager)? Die kostenlose Simply-Static-Version.
• Du bist Entwickler und willst eine Publishing-Pipeline? WP2Static, oder Simply Static Pro mit inkrementellen Builds.
• Eine laufende Unternehmensseite, an der weiter gearbeitet wird? Nicht exportieren. Umziehen. Ein Export verschiebt das Wartungsproblem nur, er löst es nicht, und du zahlst weiter für PHP-Hosting und flickst weiter WordPress-Sicherheitslücken auf der Redaktions-Installation.

Häufige Fragen

Fazit

WordPress in statisches HTML umzuwandeln ist wirklich einfach. Simply Static erledigt das heute Nachmittag, und deine Seiten sind heute Abend schneller. Nicht einfach ist alles nach dem ZIP: die Formulare, die Sitemap, die Weiterleitungen, und die Tatsache, dass du jetzt WordPress und eine statische Seite pflegst statt einer Sache.

Die eigentliche Frage ist also nicht, welches Export-Tool. Sondern ob du einen Schnappschuss willst oder einen Umzug. Ist die Seite fertig, exportier sie und freu dich über das Tempo. Ist es eine laufende Unternehmensseite, ist eine Migration, die sie zugleich bearbeitbar hält, die Variante, die deine Arbeit wirklich reduziert. Genau darum geht es im großen Leitfaden und in weg von WordPress, ohne Rankings zu verlieren.