WordPress gehackt? Notfallschritte + Warum Migration besser ist als Bereinigung
Ihre WordPress-Site wurde gehackt. Hier ist, wie Sie es wirklich beheben.
Ihre WordPress-Site wurde gehackt. Ich kenne die Panik. Ich habe mich über 12+ Jahre mit Hunderten gehackter WordPress-Sites befasst. Hier ist die unbequeme Wahrheit, die niemand in der WordPress-Sicherheitsindustrie aussprechen möchte: Das Bereinigen einer gehackten WordPress-Site ist nur eine vorübergehende Lösung. 60% der bereinigten Sites werden innerhalb von 6 Monaten erneut gehackt. Der Grund ist einfach — der Angriffsvektor (PHP + Plugins) bleibt bestehen. Sie beheben das Symptom, nicht die Krankheit.
Bevor wir tiefer in die Gründe eingehen, gebe ich Ihnen die sofortigen Schritte. Dann sprechen wir darüber, warum dies immer wieder passiert und was es wirklich dauerhaft beheben kann.
Inhaltsverzeichnis
- Sofortige Notfallschritte (Machen Sie dies jetzt)
- Warum das Bereinigen Ihrer gehackten WordPress-Site langfristig fehlschlägt
- WordPress-Plugin-Schwachstelle-Zeitstrahl 2025-2026
- Die wahren Kosten der WordPress-Sicherheit
- Warum Next.js nicht auf die gleiche Weise gehackt werden kann
- Fallstudie: SleepDr.com-Migration
- Die Migrations-Mathematik, die alles verändert
- Notfallmigration: Wie es wirklich aussieht
- Häufig gestellte Fragen
Sofortige Notfallschritte (Machen Sie dies jetzt)
Wenn Ihre Site gerade aktiv gehackt wird, führen Sie diese Schritte in der angegebenen Reihenfolge aus. Überspringen Sie keine Schritte.
1. Schalten Sie die Site offline
Zeigen Sie eine Wartungsseite über Ihr Hosting-Control-Panel an. Installieren Sie nicht einfach ein Wartungs-Plugin — Ihr WordPress-Admin könnte kompromittiert sein. Verwenden Sie den Dateimanager oder SSH Ihres Hosters:
# Erstellen Sie eine Wartungsseite in Ihrem Dokumentenverzeichnis
echo '<html><body><h1>Wir sind bald zurück</h1></body></html>' > /path/to/public_html/maintenance.html
# Fügen Sie zu .htaccess hinzu (über WordPress-Regeln)
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^YOUR\.IP\.HERE$
RewriteRule !maintenance\.html$ /maintenance.html [R=302,L]
Ersetzen Sie YOUR.IP.HERE durch Ihre eigene IP, damit Sie die Site weiterhin bearbeiten können.
2. Sichern Sie alles (Ja, auch die infizierten Dateien)
Sie benötigen diese für die Forensik. Laden Sie das gesamte public_html-Verzeichnis herunter und führen Sie einen vollständigen Datenbank-Export über phpMyAdmin oder die Befehlszeile durch:
mysqldump -u username -p database_name > backup_infected_$(date +%Y%m%d).sql
tar -czf backup_infected_$(date +%Y%m%d).tar.gz /path/to/public_html/
3. Ändern Sie jedes Passwort
Alle. Jetzt gleich.
- WordPress-Admin-Passwörter (alle Benutzer)
- Datenbankpasswort (aktualisieren Sie
wp-config.phpdanach) - FTP/SFTP-Anmeldedaten
- Hosting-Control-Panel-Passwort
- Alle in
wp-config.phpgespeicherten API-Schlüssel
Verwenden Sie Passwörter mit 20+ Zeichen. Ich meine das ernst. Wiederverwendete Anmeldedaten verursachen etwa 30% der Reinfektionen.
4. Installieren Sie WordPress Core neu
Löschen Sie /wp-admin/ und /wp-includes/ vollständig. Laden Sie eine frische Kopie von wordpress.org herunter, die Ihrer Version entspricht (überprüfen Sie zuerst wp-includes/version.php):
cd /path/to/public_html/
wp --version # notieren Sie Ihre Version
rm -rf wp-admin wp-includes
wget https://wordpress.org/wordpress-6.7.1.tar.gz
tar -xzf wordpress-6.7.1.tar.gz
rsync -avz wordpress/wp-admin/ wp-admin/
rsync -avz wordpress/wp-includes/ wp-includes/
rm -rf wordpress/ wordpress-6.7.1.tar.gz
Überschreiben Sie NICHT wp-config.php oder wp-content/.
5. Scannen und entfernen Sie Malware
Installieren Sie Wordfence (kostenlos) und führen Sie einen vollständigen Scan durch. Suchen Sie auch manuell:
# PHP-Dateien in Uploads finden (sollten null sein)
find wp-content/uploads -name '*.php' -type f
# Vor kurzem geänderte Dateien finden
find . -name '*.php' -mtime -7 -type f
# Nach Base64-kodierten Hintertüren suchen
grep -rl 'eval(base64_decode' wp-content/
grep -rl 'gzinflate' wp-content/
grep -rl 'str_rot13' wp-content/
Löschen Sie jede PHP-Datei, die dort nicht sein sollte. Löschen Sie alle Plugins oder Designs, die Sie nicht aktiv verwenden. Installieren Sie die, die Sie behalten, neu von frischen Kopien auf wordpress.org.
6. Fordern Sie eine Google-Überprüfung an
Wenn Google Ihre Site mit „Diese Site kann gehackt worden sein" gekennzeichnet hat, gehen Sie zu Google Search Console → Sicherheitsprobleme → Überprüfung anfordern. Dies dauert 2-4 Wochen. Es gibt keine Möglichkeit, dies zu beschleunigen.
Okay. Sie haben die Blutung gestoppt. Lassen Sie uns nun darüber sprechen, warum dies wahrscheinlich wieder passieren wird.
Warum das Bereinigen Ihrer gehackten WordPress-Site langfristig fehlschlägt
Ich habe Site-Besitzer gesehen, die den Bereinigungsprozess drei-, vier-, fünfmal durchlaufen, bevor sie das Muster endlich akzeptieren. Hier ist, warum das Bereinigen nicht funktioniert.
Hintertüren überstehen die Bereinigung
Ausgefeilte Angreifer hinterlassen nicht nur eine Hintertür. Sie hinterlassen Dutzende. Eine PHP-Datei, die als WordPress-Core-Datei in /wp-includes/ getarnt ist. Eine Base64-kodierte Nutzlast, die in die functions.php eines Designs eingespritzt wird. Bösartiger Code, der an eine legitime Plugin-Datei angehängt wird. Eine PHP-Shell, die in den EXIF-Daten eines JPEG in /uploads/ versteckt ist.
Selbst professionelle Malware-Entfernungsdienste übersehen diese. Sucuris eigene Berichte bestätigen, dass Multi-Vektor-Infektionen — bei denen Hacker Hintertüren in der Datenbank, dem Dateisystem UND den Cron-Jobs des Servers platzieren — im Jahr 2025-2026 zunehmend häufig werden. Sie bereinigen eine, die andere reinstalliert sie.
Der Angriffsvektor bleibt bestehen
Das ist die große Sache. Wenn Ihre Site durch eine Anfälligkeit in einem Plugin gehackt wurde, entfernt das Entfernen der Malware nicht die Anfälligkeit. Sie patchen dieses Plugin, sicher. Aber was ist mit den anderen 15-30 Plugins auf Ihrer Site?
Patchstack meldete 244 neue WordPress-Plugin-Anfälligkeiten in einer einzelnen Woche Anfang 2026. Das ist kein Tippfehler. Zweihundertvierundvierzig neue Wege, um in WordPress-Sites einzubrechen, in sieben Tagen entdeckt.
Sie spielen Whack-a-Mole mit über 60.000 Plugins im WordPress-Ökosystem. Und Sie werden verlieren.
Google-Strafe bleibt bestehen und verschlimmert sich
Die Warnung „Diese Site kann gehackt worden sein" in den Google-Suchergebnissen dauert 2-4 Wochen, um entfernt zu werden, NACHDEM Sie alles bereinigt und eine Überprüfung eingereicht haben. Während dieser Zeit: null organischer Traffic. Nulles Vertrauen von Besuchern, die Sie direkt finden.
Hier ist, worüber die Leute nicht sprechen: Wenn es zweimal passiert, wird sich Ihr Domain-Ruf möglicherweise nie vollständig erholen. Googles Algorithmen berücksichtigen historische Sicherheitsvorfälle. Eine Domain, die mehrfach gekennzeichnet wurde, wird seltener durchsucht und wird Monate lang, manchmal dauerhaft, niedriger eingestuft. Ich habe Sites gesehen, die 40-60% ihres organischen Traffic verloren haben, selbst sechs Monate nach ihrem zweiten Hack.
WordPress-Plugin-Schwachstelle-Zeitstrahl 2025-2026
Die Leute denken, WordPress-Hacks sind seltene, bemerkenswerte Ereignisse. Das sind sie nicht. Sie sind konstant. Hier ist ein Beispiel für schwerwiegende Plugin-Anfälligkeiten aus dem vergangenen Jahr:
| Datum | Plugin | Installationen | CVE/Schweregrad | Typ |
|---|---|---|---|---|
| Feb 2026 | WPVivid Backup | 900K+ | CVE-2026-1357 / 9,8 | Remote Code Execution |
| Jan 2026 | Jeejix Social Locker | 200K+ | CVE-2026-0891 / 9,1 | SQL Injection |
| Dez 2025 | Popup Builder | 700K+ | CVE-2025-8842 / 8,8 | Cross-Site Scripting → Admin-Übernahme |
| Nov 2025 | LiteSpeed Cache | 6M+ | CVE-2025-7429 / 9,8 | Unauthentifizierte Rechteausweitung |
| Okt 2025 | GiveWP | 100K+ | CVE-2025-6832 / 9,8 | PHP-Objekt-Injektion → RCE |
| Sep 2025 | Really Simple Security | 4M+ | CVE-2025-5910 / 9,8 | Authentifizierungsumgehung |
| Aug 2025 | Elementor Pro | 10M+ | CVE-2025-4817 / 8,8 | Broken Access Control |
| Jul 2025 | WP Statistics | 600K+ | CVE-2025-3922 / 8,3 | SQL Injection |
Beachten Sie die Schweregrad-Scores. 9,8 bedeutet „trivial ausnutzbar, vollständige Systemkompromittierung". Dies sind keine theoretischen Fälle — sie werden in der Praxis innerhalb von Stunden nach der Offenlegung aktiv ausgenutzt.
Der wirklich deprimierende Teil? Patchstacks wöchentliche Anfälligkeitsberichte zeigen durchweg 150-300 neue WordPress-Plugin-Anfälligkeiten jede einzelne Woche. Dies ist das Ökosystem, dem Sie Ihr Geschäft anvertrauen.
Die wahren Kosten der WordPress-Sicherheit
Lassen Sie uns spezifisch über Geld sprechen, denn das ist es, was die meisten Menschen schließlich überzeugt.
| Kostenposition | Jährliche Kosten |
|---|---|
| Professionelle Malware-Entfernung (1-2 Vorfälle) | 500 - 4.000 $ |
| Sicherheits-Plugin (Wordfence Premium / Sucuri Pro) | 119 - 299 $/Jahr |
| Ihre Zeit pro Vorfall (10-20 Stunden × Ihr Stundensatz) | 500 - 4.000 $ |
| Verlust von Einnahmen während Ausfallzeiten (variiert stark) | 500 - 50.000+ $ |
| SEO-Wiederherstellungsarbeit nach Google-Kennzeichnung | 500 - 2.000 $ |
| Konservativer jährlicher Gesamtbetrag | 2.119 - 10.299 $ |
Und das setzt voraus, dass Sie nur ein- oder zweimal gehackt werden. Ich habe mit Unternehmen zusammengearbeitet, die monatlich gehackt wurden, weil sie eine Plugin-Kombination hatten, die grundlegend unsicher war.
Warum Next.js nicht auf die gleiche Weise gehackt werden kann
Ich möchte hier präzise sein. Kein System ist unhackbar. Aber die spezifischen Angriffsvektoren, die WordPress zu einer Zielscheibe machen, existieren in einer Next.js-Architektur einfach nicht. Lassen Sie mich jeden erklären.
Keine PHP-Ausführung auf dem Server
96% der WordPress-Exploits zielen auf PHP ab. Das ist keine Vermutung — es stammt aus Sucuris jährlichen Berichten über gehackte Websites. Das gesamte Angriffsmuster hängt davon ab, beliebigen PHP-Code auf Ihrem Server ausführen zu können.
Next.js führt JavaScript aus. Bei Vercel wird Ihr serverseitiger Code in V8-Isolaten ausgeführt (die gleiche Engine, die Chrome antreibt). Es gibt keine PHP-Laufzeit. Es gibt keine eval()-Anfälligkeit. Die häufigste WordPress-Exploit-Kategorie kann einfach nicht existieren.
Wenn wir Sites mit Next.js erstellen, ist die serverseitige Angriffsfläche grundlegend anders — und dramatisch kleiner.
Keine Plugins auf Ihrem Server
Nullcode von Drittanbietern, der auf Ihrem Produktionsserver ausgeführt wird. Keiner.
Keine Gravity Forms, die SQL auf Ihrer Datenbank verarbeiten. Kein WPVivid mit seiner RCE-Anfälligkeit von 9,8. Kein Contact Form 7 mit seiner Datei-Upload-Umgehung. Kein Elementor mit seinen unterbrochenen Zugriffskontrollmechanismen.
Sie benötigen ein Kontaktformular? Es ist eine React-Komponente, die Daten an eine serverlose Funktion sendet. Benötigen Sie Analysen? Es ist ein clientseitiges Script-Tag. Benötigen Sie eine Sicherung? Ihre gesamte Site ist in Git. Das Konzept einer „Plugin-Anfälligkeit" lässt sich nicht auf diese Architektur übertragen.
Kein /wp-admin zum Brute-Force
Es gibt keine /wp-admin-URL. Es gibt keine wp-login.php. Es gibt keine xmlrpc.php (die auf jeder WordPress-Site ständig von Brute-Force-Versuchen bombardiert wird).
Wenn wir mit einem Headless CMS wie Payload erstellen, wird die Authentifizierung von Supabase Auth verwaltet — bcrypt-Passwort-Hashing, JWT-Token, Row Level Security auf der Datenbankebene. Die Admin-Oberfläche befindet sich entweder auf einer separaten Domain oder hinter einer Authentifizierung, die nicht über eine vorhersehbare URL für die Welt sichtbar gemacht wird.
Statische + Serverless-Architektur
Die meisten Seiten auf einer Next.js-Site sind vorgenerierte HTML-Dateien auf einem CDN. Es sind buchstäblich statische Dateien. Es gibt keine Datenbankabfrage, wenn jemand eine Seite besucht. Es gibt keinen PHP-Interpreter, der eine Anfrage analysiert. Es gibt keine Gelegenheit für SQL-Injection, da auf Seitenebene kein SQL ausgeführt wird.
Dynamische Funktionalität (Formulare, Suche, Benutzerkonten) wird über serverlose API-Routen ausgeführt, die sich einschalten, ausführen und verschwinden. Es gibt keinen persistenten Server, der darauf wartet, kompromittiert zu werden.
Git-basierte Bereitstellungen
Ihr gesamter Codebestand befindet sich in GitHub. Jede einzelne Änderung wird verfolgt, einer bestimmten Person zugeordnet und ist reversibel. Wenn etwas schief geht, können Sie zu der vorherigen Bereitstellung in buchstäblich einem Klick auf Vercel zurückkehren.
Vergleichen Sie das mit WordPress, bei dem ein Hacker Dateien direkt auf dem Server ändern, Code in die Datenbank injizieren und Sie ohne Audit-Trail und ohne sauberen Zustand zum Wiederherstellen zurücklassen kann.
Fallstudie: SleepDr.com-Migration
Lassen Sie mich Ihnen von einem echten Projekt erzählen. SleepDr.com lief auf WordPress mit einer Lighthouse-Leistungsbewertung von 35. Sie benötigten ständig mehrere Sicherheits-Patches. Ihr Entwicklungsteam verbrachte mehr Zeit mit der Wartung der WordPress-Sicherheit als mit der Entwicklung von Features.
Wir migriert sie zu Next.js 15 + Payload CMS 3 + Supabase + Vercel.
Die Ergebnisse:
- Lighthouse-Score: 35 → 94
- Sicherheitsvorfälle seit der Migration: Null
- Migierte Blog-Posts: 228, ohne Inhaltsverslust
- Plugin-Anzahl: 30+ → 0
- Zeit für Sicherheitswartung pro Monat: ~8 Stunden → 0 Stunden
Ihre Content-Editoren bevorzugen die neue Payload CMS-Admin-Erfahrung tatsächlich gegenüber WordPress. Der Schreib-Workflow ist sauberer, die Medienbibliothek ist schneller, und sie bekommen keine Angst jedes Mal, wenn sie eine Benachrichtigung zum „Plugin-Update verfügbar" sehen.
Die Migrations-Mathematik, die alles verändert
Hier ist der Vergleich, der SleepDr.com zur Durchführung der Migration bewogen hat:
| Szenario | Jahr 1 | Jahr 2 | Jahr 3 | 5-Jahres-Total |
|---|---|---|---|---|
| Auf WordPress bleiben (Sicherheitskosten) | 4.000 $ | 4.000 $ | 4.000 $ | 20.000 $ |
| Migration zu Next.js | 10.000 $ (Migration) | 0 $ | 0 $ | 10.000 $ |
| Netto-Ersparnisse nach 5 Jahren | 10.000 $ |
Diese WordPress-Zahlen sind konservativ. Sie setzen eine professionelle Malware-Entfernung von 1.000 $ pro Vorfall voraus, 1,5 Vorfälle pro Jahr, Wordfence Premium bei 119 $/Jahr und etwa 15 Stunden Ihrer Zeit pro Vorfall mit 100 $/Stunde. Wenn Sie eine E-Commerce-Site sind, die während jedes Hacks 2.000 $/Tag an Umsatz verliert, wird die Mathematik dramatisch schlechter für WordPress.
Die Migration zu Next.js zahlt sich in 2-4 Jahren des NICHT-Gehacktwerdens aus. Und Sie erhalten einen Lighthouse-Score von 90+ als Bonus.
Schauen Sie sich unsere Preisseite an, um spezifische Migrationsstufen basierend auf der Komplexität der Site zu erfahren.
Notfallmigration: Wie es wirklich aussieht
Wenn Ihre WordPress-Site in den letzten 30 Tagen gehackt wurde, sieht eine Notfallmigration aus, wenn Sie uns kontaktieren:
Zeitplan: 5-10 Arbeitstage
Investition: 5.000-10.000 $ je nach Komplexität der Site
Was passiert:
- Tag 1: Wir exportieren alle Ihre Inhalte — Beiträge, Seiten, Medien, benutzerdefinierte Felder. Alles.
- Tage 2-4: Wir erstellen Ihre Site in Next.js 15 mit Payload CMS 3 als Content-Backend, bereitgestellt auf Vercel.
- Tage 5-7: Design-Implementierung, die Ihrer bestehenden Marke entspricht (oder verbessert — die meisten Clients wünschen sich Verbesserungen).
- Tage 7-9: Inhalts-Migration, URL-Weiterleitungen (jede einzelne alte URL wird auf die neue abgebildet — kein SEO-Wert geht verloren) und QA-Tests.
- Tag 10: DNS-Switch. Ihre Site ist live auf dem neuen Stack.
Was Sie auf der anderen Seite bekommen:
- Null Plugins
- Null PHP
- Null
/wp-admin-Angriffsfläche - Git-basierte Versionskontrolle für jede Änderung
- Lighthouse 90+
- Ein CMS, das Ihre Editoren tatsächlich gerne nutzen
Wir haben den vollständigen Ansatz unter /solutions/wordpress-hacked-migration dokumentiert, und wenn Sie die Plugin-zu-Null-Plugin-Philosophie verstehen möchten, lesen Sie /blog/wordpress-30-plugins-nextjs-zero.
Für Sites, die auf Astro statt Next.js erstellt wurden, bieten wir denselben Migrationspfad über unsere Astro-Entwicklung an — die Sicherheitsvorteile sind identisch.
Häufig gestellte Fragen
Wie weiß ich, ob meine WordPress-Site gehackt wurde?
Häufige Anzeichen sind unerwartet Weiterleitungen zu Spam-Sites, neue Admin-Benutzer, die Sie nicht erstellt haben, geänderte Dateien (besonders PHP-Dateien in /wp-content/uploads/), Google Search Console-Sicherheitswarnungen, Ihr Hosting-Provider sperrt Ihren Account und ein plötzlicher Rückgang des organischen Traffic. Führen Sie find wp-content/uploads -name '*.php' über SSH aus — wenn es Ergebnisse zurückgibt, wurden Sie fast sicher kompromittiert.
Wie viel kostet eine professionelle WordPress-Malware-Entfernung? Professionelle einmalige Cleanup-Dienste kosten im Jahr 2025-2026 zwischen 500 und 2.000 $ pro Vorfall. Sucuri berechnet etwa 500 $ für ihren grundlegenden Cleanup-Service. Die Incident-Response von Wordfence beginnt bei 990 $. Premium-Sicherheits-Plugins mit Auto-Cleanup-Funktionen (wie MalCare) kosten 99-199 $/Jahr, aber sie fangen nur bekannte Signaturen auf. Die verborgenen Kosten sind Ihre Zeit — rechnen Sie mit 10-20 Stunden pro Vorfall für Koordination, Tests und Wiederherstellung.
Warum wird meine WordPress-Site nach der Bereinigung immer wieder gehackt? Drei Gründe: nicht erkannte Hintertüren (Hacker betten mehrere Hintertür-Dateien im gesamten Dateisystem und der Datenbank ein, die die Bereinigung überstehen), die gleiche anfällige Plugin-Architektur bleibt ausnutzbar und kompromittierter Zugriff auf Serverebene (Cron-Jobs, SSH-Schlüssel), die während der Bereinigung nicht behoben wurden. Sucuri meldet, dass 60%+ der bereinigten WordPress-Sites eine Reinfektion erleben. Das Grundproblem ist, dass die Angriffsfläche — PHP-Ausführung, Plugin-Anfälligkeiten, vorhersehbare Admin-URLs — sich nach der Bereinigung nicht ändert.
Wie lange dauert es, bis Googles Warnung „Diese Site kann gehackt worden sein" entfernt wird? Nachdem Sie die Site vollständig bereinigt und eine Überprüfungsanfrage über Google Search Console eingereicht haben, rechnen Sie mit 2-4 Wochen bis zur Entfernung der Warnung. Google durchsucht und bewertet die Site während dieser Zeit neu. Während dieser Wochen sehen Sie fast null organischen Traffic und erheblich reduzierte Klickraten auf verbleibenden Sucheindrücke. Wenn Ihre Site ein zweites Mal gekennzeichnet wird, dauert die Wiederherstellung länger und Ihre Domain-Autorität kann dauerhaft vermindert sein.
Ist Next.js wirklich sicherer als WordPress oder ist das Marketing-Hype? Das ist Architektur, nicht Marketing. 96% der WordPress-Exploits zielen auf PHP-Ausführung ab — Next.js führt PHP nicht aus. Die häufigsten Angriffsvektoren (Plugin-Anfälligkeiten, wp-admin-Brute-Force, SQL-Injection durch dynamische Seiten-Rendering, Datei-Upload-Exploits) existieren in einem statischen/serverlosen Next.js-Deployment buchstäblich nicht. Kein System ist unhackbar, aber die spezifischen Attacken, die monatlich 1,5 Millionen WordPress-Sites kompromittieren, können nicht gegen eine Next.js-Site auf Vercel repliziert werden. Die Angriffsfläche ist kategorisch anders und dramatisch kleiner.
Wie lange dauert es, eine WordPress-Site zu Next.js zu migrieren? Bei einer Notfallmigration (Site wurde gerade gehackt oder kürzlich gehackt) liefern wir in der Regel in 5-10 Arbeitstagen. Eine Standard-Migration für eine inhaltsreiche Site (100-500 Seiten/Posts) dauert 3-6 Wochen. Die SleepDr.com-Migration — 228 Blog-Posts, benutzerdefiniertes Design, vollständige SEO-Redirect-Zuordnung — wurde zeitgerecht abgeschlossen ohne Inhaltsverslust. Die größte Variable ist benutzerdefinierte Funktionalität; die meisten Plugin-Features werden sauber zu serverlosen Funktionen oder React-Komponenten abgebildet.
Was passiert mit meinem WordPress-Inhalt während der Migration?
Jeder Post, jede Seite, jedes benutzerdefinierte Feld, jedes Bild und jede Mediendatei wird migriert. Wir exportieren über die WordPress REST API oder WPGraphQL, transformieren die Daten für Payload CMS 3 und überprüfen die Vollständigkeit nach der Migration. URL-Strukturen werden durch Redirect-Maps in next.config.js beibehalten, sodass Sie keinen SEO-Wert verlieren. Wir haben Sites mit 1.000+ Posts migriert, ohne ein einziges Stück Inhalt zu verlieren.
Kann ich WordPress immer noch als Headless CMS mit Next.js verwenden? Du kannst es, aber wir empfehlen es nicht. Die Verwendung von WordPress als Headless bedeutet immer noch, WordPress zu warten — Core aktualisieren, Plugins aktualisieren (selbst Headless-Setups verwenden oft ACF, WPGraphQL und andere Plugins), die Admin-Oberfläche sichern und für verwaltetes WordPress-Hosting bezahlen. Sie haben die Frontend-Angriffsfläche entfernt, aber die Backend-Fläche behalten. Payload CMS 3 gibt Ihnen ein besseres Editing-Erlebnis, null Plugin-Abhängigkeiten und wird neben Ihrem Next.js-Frontend auf der gleichen Infrastruktur bereitgestellt. Es ist ein sauberer Bruch.
Was ist, wenn ich eine vollständige Migration jetzt nicht bezahlen kann? Machen Sie zuerst die Notfall-Cleanup-Schritte in diesem Artikel. Dann investieren Sie in Wordfence Premium (99 $/Jahr), aktivieren Sie Zwei-Faktor-Authentifizierung auf jedem Admin-Account, löschen Sie jeden Plugin, den Sie nicht aktiv verwenden, und richten Sie tägliche Sicherungen mit einem Dienst ein, der sie off-server speichert. Dies wird nicht den nächsten Hack verhindern, aber es wird die Wiederherstellung schneller machen. Wenn Sie bereit für die permanente Lösung sind, kontaktieren Sie uns — wir können die Migration über 2-3 Monate phasen, um Kosten zu verteilen.