Schluss mit dem WordPress-Spaghetti

WordPress ist keine schlechte Wahl, aber es wächst gegen Sie

WordPress hat einen Grund, warum es vierzig Prozent des Webs antreibt. Es ist flexibel, die Community ist groß, und für ein überschaubares Budget bekommt man schnell eine funktionsfähige Website. Aber diese Flexibilität hat einen Preis: Alles basiert auf Plugins, Themes und einer Datenbank, die nicht dafür ausgelegt wurden, zusammenzuarbeiten.

Am Anfang fällt das nicht auf. Man installiert ein Kontaktformular-Plugin, ein SEO-Plugin, ein Caching-Plugin, ein Backup-Plugin. Gut. Aber sobald die Website wächst und man mehr Funktionalität hinzufügt, mehr Plugins aktiviert und mehr Themes anpasst, entsteht ein Netz von Abhängigkeiten, das niemand mehr vollständig überblickt. Man selbst auch nicht.

Ich nenne das WordPress-Spaghetti. Nicht als Kritik an dem Tool, sondern als Beschreibung eines Musters, das ich immer wieder bei KMU-Websites sehe, die fünf Jahre alt sind: zwanzig, dreißig, manchmal achtzig Plugins. Themes, die von drei verschiedenen Entwicklern angepasst wurden. Ein Update-Zeitplan, den niemand mehr einhält, weil Updates die Website brechen.

Was in der Praxis bei WordPress im großen Maßstab schiefläuft

Die Probleme, die ich bei WordPress-Websites, die zu groß geworden sind, am häufigsten antreffe:

• ▸Plugin-Konflikte: zwei Plugins, die dieselbe jQuery-Version benötigen und dann kollidieren. Ein WooCommerce-Update, das die Checkout-Seite bricht. Ein Elementor-Update, das benutzerdefiniertes CSS überschreibt.
• ▸Sicherheitslücken: WordPress ist das am häufigsten angegriffene CMS der Welt. Jedes veraltete Plugin ist ein potenzieller Angriffsvektor. Ich begegne regelmäßig Websites, die drei Versionen hinter kritischen Patches zurückliegen.
• ▸Leistungsprobleme: Elementor und Divi laden Megabytes an CSS und JavaScript für jede Seite, auch wenn man den Builder nur für die Startseite verwendet hat. Ein LCP von vier Sekunden ist keine Ausnahme. Es ist die Norm.
• ▸Lizenzkosten, die sich summieren: Premium-Plugins kosten €50–€300 pro Jahr, pro Plugin. Eine Website mit zehn Premium-Plugins zahlt jährlich mehr an Lizenzen als an Hosting.
• ▸Entwicklerknappheit: WordPress-Entwickler gibt es genug, aber ein guter Entwickler, der auch versteht, wie Performance, Security und Custom Post Types zusammenhängen, ist selten und teuer.
• ▸Lock-in durch Page-Builder: Eine in Elementor oder Beaver Builder erstellte Website ist praktisch nicht auf einen anderen Ansatz übertragbar, ohne alles neu aufzubauen.

Das ist keine Theorie. Das sind die Befunde, die ich im Audit antreffe, den ich immer vor dem Start einer Migration durchführe. Die meisten Kunden sind vom Ausmaß überrascht, nicht von seiner Existenz.

Wie ich Ihre Inhalte und URLs migriere

Der technische Kern einer WordPress-Migration ist der Content-Export und das Redirect-Mapping. WordPress hat eine REST API, die ich nutze, um alle Posts, Seiten, Custom Post Types, Medien und Taxonomien strukturiert zu exportieren. Das liefert mir einen JSON-Dump, den ich dann in MDX-Dateien oder ein Headless-CMS transformiere.

Neben dem Content erstelle ich eine vollständige URL-Map. Ich crawle Ihre bestehende Website, vergleiche sie mit Ihren Google-Search-Console-Daten und erstelle eine Redirect-Tabelle, die jede indexierte URL mit der neuen URL-Struktur verknüpft. Diese Tabelle wird Redirect für Redirect als 301 implementiert, bevor die neue Website live geht.

• ▸WP REST API-Export: Alle Posts, Seiten, Custom Post Types und Medien werden über die Standard-WordPress-REST-Endpunkte exportiert. Kein manuelles Kopieren.
• ▸Content-Transformation: Das rohe WordPress-HTML wird in sauberes MDX oder CMS-Input umgewandelt, ohne Shortcodes, ohne Elementor-Markup, ohne versteckte Stile.
• ▸Redirect-Mapping: Jede in Google indexierte URL erhält einen 301-Redirect zur entsprechenden neuen URL. Einschließlich Seite-2-Varianten und Kategorie-URLs.
• ▸Sitemap-Einreichung: Nach dem Launch reiche ich die neue sitemap.xml direkt bei der Google Search Console ein und überwache die Crawl-Statistiken.

Security: das stille Risiko einer veralteten WordPress-Website

WordPress-Sicherheit ist eine aktive Tätigkeit, keine einmalige Einstellung. Jeden Tag werden neue Schwachstellen in Plugins und Themes entdeckt. Wenn man ein Plugin nicht aktualisiert, weil man Angst hat, dass die Website bricht, öffnet man die Tür für automatisierte Angriffe, die WordPress-Installationen massenhaft auf bekannte Schwachstellen scannen.

Ich hatte Kunden, die entdeckten, dass ihre WordPress-Website seit Monaten Teil eines Spam-Netzwerks war. Die Website funktionierte einwandfrei, aber der Server verschickte täglich tausende Spam-Mails. In einem anderen Fall war ein Redirect injiziert worden, der mobile Besucher auf eine Phishing-Seite umleitete. Beide Vorfälle waren die Folge eines nicht gepatchten Plugins.

Next.js hat dieses Problem strukturell nicht. Es gibt keine Datenbank, die direkt über SQL-Injection abgefragt werden kann. Es gibt keine Plugin-Architektur mit Hintertüren. Die Angriffsfläche ist minimal: statische Dateien, ein API-Endpunkt wenn nötig und eine verwaltete Hosting-Umgebung. Nach der Migration müssen Sie nicht mehr täglich prüfen, ob ein Plugin-Update wartet, das Ihre Website brechen könnte.

Was ich anders mache als eine WordPress-Agentur

Die meisten WordPress-Agenturen lösen ein WordPress-Problem mit einer WordPress-Lösung: ein besseres Caching-Plugin, ein anderes Theme, mehr Serverarbeitsspeicher. Das funktioniert kurzfristig, löst aber das strukturelle Problem nicht. Plugins sind nicht das Problem. Das System der Abhängigkeiten ist das Problem.

Ich verwende WordPress nicht als Ausgabe. Ich verwende WordPress als Ausgangspunkt: Ich lese Ihre Daten über die REST API, exportiere Ihre Inhalte und baue eine neue Umgebung in Next.js auf, die keine der WordPress-Annahmen trägt. Keine Datenbank, die für SQL-Injection anfällig ist. Keine Plugin-Updates, die die Website brechen können. Keine monatlichen Lizenzen für Formular-Plugins.

Was ich mitnehme: Ihre Inhalte, Ihre URLs, Ihre SEO-Position und Ihre Designabsicht. Was ich zurücklasse: die technischen Schulden, das Plugin-Chaos und die Sicherheitsrisiken. Das Ergebnis ist eine Website, die Sie vollständig verstehen, die ich warten kann und die nicht von der Roadmap eines Drittanbieter-Plugin-Entwicklers abhängt.

Verwaltung und CMS nach der Migration

Ein häufig geäußertes Anliegen: 'Aber ich möchte meine Inhalte selbst aktualisieren können.' Das können Sie. Und besser als in WordPress. Je nach Menge der Inhalte und Häufigkeit der Aktualisierungen wähle ich:

• ▸ein eigenes CMS: ein Git-basiertes CMS, das direkt in das Repository schreibt. Keine separate Datenbank, kein separater Server. Sie bearbeiten Inhalte in einer übersichtlichen Benutzeroberfläche, ich sehe die Änderung als Git-Commit.
• ▸ein eigenes CMS: ein Headless-CMS mit einer vollständig konfigurierbaren Redaktionsoberfläche. Geeignet, wenn mehrere Redakteure vorhanden sind oder die Inhaltsstruktur komplex ist.
• ▸MDX-Dateien: für einfache Websites mit seltenen Inhaltsaktualisierungen funktioniert auch eine direkte MDX-Struktur. Sie bearbeiten Markdown-Dateien, ich deploye automatisch über eine CI/CD-Pipeline.
• ▸Kein CMS: für Broschüren-Websites, bei denen sich Inhalte selten ändern, ist ein CMS nicht nötig. Ich liefere die Seiten als statische Dateien und Sie wenden sich an mich, wenn etwas geändert werden soll.

In allen Fällen haben Sie vollen Zugriff auf Ihre eigenen Daten. Es gibt keine WordPress-Verwaltung, für die Sie ein separates Passwort verwalten müssen, keine Datenbank, die separat gesichert werden muss, und kein Plugin, das Ihre Inhalte in einem proprietären Format speichert, das schwer zu exportieren ist.

Weiter lesen