WordPress als HTML exportieren – so geht's.

Kurz beantwortet

Ja, eine öffentlich erreichbare WordPress-Seite lässt sich bei passenden Inhalten als statisches HTML veröffentlichen. Dabei müssen nicht nur HTML-Dateien, sondern auch Bilder, Styles, Skripte, interne Links und weitere Ressourcen geprüft werden. Dynamische Funktionen brauchen gesonderte Lösungen.

Was ein vollständiger HTML-Export umfasst

WordPress speichert keine fertigen Seiten. Jede Adresse wird beim Aufruf aus Theme, Plugins und Datenbank zusammengesetzt. Ein HTML-Export macht diesen Schritt einmal für alle Seiten und legt das Ergebnis als Dateien ab. Damit die exportierte Website genauso funktioniert wie das Original, gehören drei Dinge dazu:

Alle Seiten finden. Startseite, Unterseiten, Beiträge, Kategorie- und Schlagwortarchive, Autorenseiten, Paginierung. Ein Crawler, der nur Links folgt, übersieht Seiten, die nirgends verlinkt sind. Zuverlässiger ist die Kombination aus Sitemaps (WordPress-Core, Yoast, Rank Math), der öffentlichen REST-API und einem Crawl der internen Links.
Alle Ressourcen mitnehmen. Stylesheets samt den darin verlinkten Schriften und Hintergrundbildern, JavaScript, Bilder in allen responsiven Größen, PDFs und andere verlinkte Dateien. Viele Themes und Page-Builder laden Dateien erst per JavaScript nach – die findet nur, wer die Seite wirklich im Browser rendert.
Adressen und Signale erhalten. Jede Seite muss unter derselben URL erreichbar bleiben, mit gleichem abschließendem Schrägstrich. Canonicals, hreflang, Open-Graph-Angaben, Sitemap, robots.txt und Weiterleitungen gehören dazu, sonst verliert die Website bei Google an Boden.

Drei Methoden im Vergleich

Kriterium	Export-Plugin / Generator	Eigene Skripte / Build	Betreute Konvertierung
Einstieg	Plugin installieren, Export starten	Technisches Know-how nötig	Anfrage und Bestandsaufnahme
Kontrolle	Begrenzt auf Plugin-Optionen	Volle Kontrolle	Abgestimmt im Angebot
Dynamisches	Meist manuell nachrüsten	Frei integrierbar	Wird geplant und gelöst
SEO-Migration	Selbst prüfen	Selbst umsetzen	Teil der Leistung
Passt für	Einfache Seiten, Tüftler	Entwicklerteams	Wenig Zeit, wichtige Website

Warum „Seite speichern unter“ nicht für ganze Websites genügt

Der Browser speichert genau eine Seite – mit Verweisen, die oft weiterhin auf den Server zeigen. Die Navigation führt danach ins Leere oder zurück zu WordPress, Ressourcen wie nachgeladene Bilder oder Schriften fehlen, und die übrigen Seiten des Seitensatzes musst du einzeln speichern und neu verknüpfen. Für eine einzelne Landingpage mag das gehen, für eine Website nicht.

Schritt für Schritt: von WordPress zur HTML-Website

Bestandsaufnahme. Welche Seiten gibt es, welche Funktionen werden genutzt? Notiere Formulare, Suche, Kommentare, Logins, Shop, eingebettete Karten und Videos sowie Tracking und Cookie-Banner.
Backup anlegen. Dateien und Datenbank vollständig sichern. Das Backup ist deine Rückfallebene und die Grundlage für spätere Änderungen.
Export durchführen. Mit Plugin, eigenem Skript oder Converter. Wichtig ist, dass der Export die öffentliche Website so sieht wie ein Besucher – ohne eingeloggte Admin-Leiste und ohne Vorschau-Parameter.
Lokal prüfen. Die exportierten Dateien über einen einfachen Webserver öffnen, nicht per Doppelklick. Navigation, Bilder, Schriften, Menüs und mobile Ansicht durchklicken, Konsole und Netzwerk-Tab auf Fehler prüfen.
Dynamisches ersetzen. Formulare an einen Formulardienst anbinden, Suche durch einen clientseitigen Index oder externen Dienst ersetzen, Kommentare abschalten oder auslagern.
Hosting und SEO vorbereiten. Statisches Hosting einrichten, Weiterleitungen übernehmen, 404-Seite mit echtem 404-Status, Sitemap und robots.txt prüfen.
Domain umstellen. DNS auf das neue Hosting zeigen lassen, SSL-Zertifikat prüfen, dann stichprobenartig alte URLs aufrufen.
Beobachten. In der Google Search Console in den folgenden Wochen auf Crawling-Fehler und auffällige Änderungen achten.

Typische Probleme nach dem Export – und wie du sie erkennst

Links zeigen weiter auf die alte Installation

WordPress schreibt viele Adressen absolut ins HTML, inklusive Domain. Stellt der Export sie nicht um, lädt die neue Seite Bilder oder Skripte weiter vom alten Server – bis der abgeschaltet wird. Im Netzwerk-Tab des Browsers siehst du sofort, ob noch Anfragen an die alte Adresse gehen.

Bilder fehlen in bestimmten Größen

Über srcset wählt der Browser je nach Bildschirm eine passende Bildgröße. Wurden nur die Standardgrößen exportiert, fehlen auf dem Smartphone oder auf hochauflösenden Displays Bilder. Teste deshalb mehrere Bildschirmbreiten.

Nachgeladene Dateien fehlen

Page-Builder wie Elementor oder Themes wie Blocksy laden Teile ihres Codes erst bei Bedarf nach, etwa beim Öffnen des Mobilmenüs, beim Scrollen oder beim Hover. Ein Export, der die Seite nur herunterlädt statt sie zu rendern, übersieht diese Dateien. Das Menü öffnet dann nicht oder Slider bleiben stehen.

Dynamische Dateinamen

Adressen wie load-styles.php?… oder Dateien mit Abfrageparametern lassen sich nicht direkt als Datei speichern. Sie brauchen einen festen Dateinamen, und alle Verweise darauf müssen angepasst werden.

Verweise auf WordPress-Schnittstellen

Im <head> stehen oft Links auf wp-json, xmlrpc.php oder oEmbed-Endpunkte. Auf einer statischen Website gibt es diese Schnittstellen nicht mehr – die Verweise sollten entfernt werden, sonst produzieren sie Fehler in der Search Console.

Fehlerseiten liefern Status 200

Wird für jede unbekannte Adresse die Startseite oder eine Fehlerseite mit Status 200 ausgeliefert, wertet Google das als „Soft 404“. Die Fehlerseite muss mit echtem 404-Status ausgeliefert werden.

WP2HTML berücksichtigt diese Punkte bei der Umwandlung automatisch: Seiten werden über Sitemaps, REST-API und Crawl gefunden, in Chromium auf Desktop und Mobil gerendert, Adressen bleiben 1:1, und ein Bericht listet, was gefehlt hat. Mehr dazu unter So funktioniert's.

10-Punkte-Checkliste für den Export

01Vollständige URLs – Alle Seiten, Archive und Unterseiten sind erfasst – nicht nur die verlinkten.
02Medien – Bilder, PDFs und Videos liegen lokal vor, inklusive responsiver Varianten.
03CSS & JS – Stylesheets und Skripte laden ohne Verweis auf die alte Installation.
04SEO-Metadaten – Title und Description pro Seite sind erhalten.
05Canonicals – Zeigen auf die endgültige Domain.
06Redirects – Alte und geänderte Adressen sind geplant und eingerichtet.
07Formulare – Haben einen funktionierenden Empfänger außerhalb von WordPress.
08Responsive – Desktop und Mobil sind sichtbar geprüft.
09Externe Dienste – Karten, Videos, Analytics und Consent funktionieren weiter.
10Suchzugriff – robots.txt, Sitemap und noindex-Angaben stimmen.

Was passiert mit WordPress danach?

Lösche die WordPress-Installation nicht sofort. Behalte ein vollständiges Backup von Dateien und Datenbank, teste die statische Version gründlich und stelle erst dann die Domain um. Viele betreiben WordPress danach geschützt oder lokal weiter, um Inhalte zu pflegen und neu zu exportieren.

HTML-Vorschau mit WP2HTML testen

Fragen zum HTML-Export

Ist HTML-Export kostenlos?

Es gibt kostenlose Werkzeuge – der Aufwand liegt meist in Prüfung, Nacharbeit und Hosting. Ein Export erzeugt Dateien. Fehlende Ressourcen, Formulare, Weiterleitungen und der neue Änderungsprozess kosten Zeit oder Dienstleistung, auch wenn das Werkzeug selbst nichts kostet.

Werden Bilder übernommen?

Bilder, die öffentlich ausgeliefert werden, lassen sich in der Regel mit exportieren. Kritisch sind responsive Bildvarianten (srcset), per JavaScript nachgeladene Bilder und Medien von externen Domains. Diese Punkte gehören auf jede Export-Checkliste.

Was passiert mit meinem Google-Ranking?

Eine Umstellung kann gut funktionieren, wenn URLs, Inhalte und technische Signale sorgfältig erhalten bleiben. Dazu gehören interne Links, strukturierte Daten und korrekte Weiterleitungen. Rankings können trotzdem schwanken; eine Garantie auf unveränderte Positionen wäre unseriös.

Kritische SEO-Punkte im Überblick

Kann ich danach Texte und Bilder bearbeiten?

Ja, aber der Weg ändert sich. Du kannst Dateien anpassen, einen erneuten Export durchführen oder einen Publishing-Prozess mit CMS/Build-System verwenden. Wer täglich Inhalte ändert, sollte diesen Workflow vor der Umstellung genau planen.

Wege zur Aktualisierung