Gehackt: Warum ich WordPress durch statisches HTML ersetzt habe

Eine schädliche PHP-Datei, drei ausgefallene Websites und ein über Wochen gesperrtes Hosting-Paket: So hatte ich mir den Neustart meiner Projekte definitiv nicht vorgestellt. Am Ende war genau dieser Vorfall aber der Auslöser dafür, meine eigene Website, Fix & Flott und das Filmportfolio von Daniel Hacker nicht einfach wiederherzustellen, sondern technisch komplett neu aufzubauen.

Dieser Beitrag ist deshalb zweierlei: ein persönlicher Erfahrungsbericht über einen Sicherheitsvorfall und das aus meiner Sicht katastrophale Fehlermanagement meines Hosters IONOS – und gleichzeitig die technische Begründung dafür, warum ich bei diesen Projekten von WordPress auf statisches HTML, CSS und JavaScript gewechselt bin.

Gehackt – und anschließend komplett ausgesperrt

Nach meiner Analyse befand sich mindestens eine schädliche PHP-Datei in meinem Webspace. IONOS sperrte daraufhin das gesamte Hosting-Paket. Betroffen waren nicht irgendein Testsystem und irgendeine vergessene Unterseite, sondern drei aktive Websites, deren Sichtbarkeit ich über Jahre aufgebaut hatte.

Den ursprünglichen Angriffsweg kann ich rückblickend nicht mehr forensisch zweifelsfrei benennen. Sicher ist aber: Mehrere WordPress-Updates konnten zuvor nicht mehr sauber abgeschlossen werden. Plugins und Installationen blieben dadurch in einem problematischen Zustand zurück. Dass aktuelle Versionen von WordPress, Themes und Plugins ein zentraler Bestandteil der Absicherung sind, betont auch die offizielle WordPress-Dokumentation zur Sicherheit.

Von der Falschauskunft zur Support-Odyssee

Mein erster Anruf beim Support klang zunächst beruhigend: Es handele sich um ein Serverproblem bei IONOS, der Zugriff werde wahrscheinlich innerhalb weniger Stunden wieder funktionieren und ich bekäme eine Rückmeldung. Warum sollte ich dem technischen Support nicht glauben?

Die Rückmeldung kam nicht. Der Server blieb gesperrt. Erst auf meine erneute Nachfrage erhielt ich die Information, dass IONOS zuvor bereits Warnungen beziehungsweise Logdateien verschickt habe und das Paket wegen einer Sicherheitsbedrohung gesperrt worden sei. Die Anweisung lautete sinngemäß: Logdateien prüfen und infizierte Dateien entfernen.

Das eigentliche Problem war damit allerdings nicht gelöst. Statt einer klaren technischen Eskalation bekam ich aus unterschiedlichen Richtungen unterschiedliche Vorschläge:

• Ich solle die Zwei-Faktor-Authentifizierung für den IONOS-Zugang aktivieren.
• Ich könne zusätzliche Sicherheits-Plugins in WordPress installieren.
• Ich müsse zunächst alle kompromittierten Dateien selbst bereinigen.
• Später hieß es, das Hosting werde erst nach vollständiger Bereinigung wieder freigeschaltet.

Zwei-Faktor-Authentifizierung ist sinnvoll. Ein Sicherheits-Plugin kann ebenfalls sinnvoll sein. Beides entfernt aber keine bereits vorhandene Schadsoftware aus einem gesperrten und teilweise beschädigten Webspace. Was ich in dieser Situation gebraucht hätte, war eine eindeutige Diagnose, ein nachvollziehbarer Bereinigungsweg und eine feste Ansprechperson. Stattdessen vergingen Wochen.

„Unlimited“ – bis das Dateilimit erreicht ist

Mein alter Unlimited-Vertrag war nicht primär durch den Speicherplatz, sondern durch die Anzahl der Dateien begrenzt – auf rund 220.000 Dateien. Dieses Limit war nach Auskunft von IONOS erreicht. Das erklärte zumindest, warum automatische Updates irgendwann abbrachen und warum selbst Backups nicht mehr zuverlässig erzeugt wurden.

Merkwürdig wurde es, als ich sämtliche erreichbaren Websites, Datenbanken und Dateien gelöscht hatte und im System trotzdem noch ungefähr 170.000 Dateien gezählt wurden. Auf diese Dateien konnte ich weder über das IONOS-Backend noch über FTP oder SFTP zugreifen. Auch der telefonische Support konnte mir zunächst nicht erklären, woher sie kamen oder wie ich sie löschen sollte.

Damit hatte ich jahrelang für ein Paket bezahlt, dessen angegebenes Dateikontingent zu einem erheblichen Teil durch Dateien belegt war, die ich nicht verwalten konnte. Erst nach einer weiteren Eskalation und der Einstufung mit hoher Priorität verschwanden diese Dateien innerhalb weniger Stunden. Eine nachvollziehbare technische Erklärung oder den angekündigten Rückruf erhielt ich trotzdem nicht.

Der eigentliche Schaden: Ausfall, defekte Backups und verlorene Sichtbarkeit

Während die Zuständigkeit hin- und hergeschoben wurde, waren meine Websites nicht erreichbar. Das betraf nicht nur Komfort oder ein paar Anfragen. Suchmaschinen trafen über längere Zeit auf ausgefallene beziehungsweise nicht funktionsfähige Seiten. Die über Jahre aufgebaute organische Sichtbarkeit und bestehende Rankings litten entsprechend.

Hinzu kam, dass mein übliches Zwei-Wochen-Backup durch die lange Verzögerung keine einfache Rettung mehr bot. Neuere Sicherungen waren teilweise unvollständig, Updates waren abgebrochen und mehrere WordPress-Installationen befanden sich in einem nicht mehr verlässlich rekonstruierbaren Zustand.

Irgendwann war klar: Das Kind war im Brunnen. Ein weiteres Herumdoktern an den beschädigten Installationen hätte mehr Zeit gekostet als ein kontrollierter Neuaufbau.

Warum ich nicht wieder zu WordPress zurückgegangen bin

WordPress ist nicht grundsätzlich schlecht oder unsicher. Es ist ein leistungsfähiges CMS und war für mich über viele Jahre die richtige Wahl. Eine dynamische WordPress-Installation bringt aber zwangsläufig mehr bewegliche Teile mit: PHP, Datenbank, Login, Core, Theme, Plugins und regelmäßige Updates.

Für die drei betroffenen Websites brauchte ich viele dieser dynamischen Funktionen schlicht nicht mehr. Gleichzeitig haben sich meine Arbeitsabläufe verändert. Inhalte, Quellcode und wiederkehrende Anpassungen kann ich heute lokal und agentengestützt vorbereiten. Damit fiel einer der größten früheren Vorteile eines CMS – Inhalte ohne direkten Zugriff auf den Code einzupflegen – deutlich weniger ins Gewicht.

Weniger Angriffsfläche

Eine statische Website benötigt für die Seitenausgabe weder PHP noch eine Datenbank noch ein öffentliches CMS-Login. Dadurch entfallen bei diesen Projekten mehrere typische Angriffsflächen. Statisch bedeutet allerdings nicht „unhackbar“: Hosting-Zugang, SFTP, DNS, Formulare, externe Skripte und die lokale Entwicklungsumgebung müssen weiterhin sauber abgesichert werden.

Mehr Performance und Kontrolle

Der Server liefert fertiges HTML, CSS, JavaScript und optimierte Medien aus. Es müssen keine Datenbankabfragen und keine PHP-Templates ausgeführt werden. Gleichzeitig kann ich exakt bestimmen, welche Ressourcen eine Seite lädt. Bei den neuen Versionen erreichen die PageSpeed-Tests dadurch bis hin zu 100 Punkten – mobil wie auf dem Desktop, abhängig von Seite und Messlauf.

SEO direkt im Quellcode

Seitentitel, Meta-Descriptions, Canonicals, Open-Graph-Daten, strukturierte Daten, interne Links, Bildattribute und semantisches HTML liegen nicht mehr verteilt in Theme-Optionen und Plugins. Sie sind ein nachvollziehbarer Bestandteil jeder einzelnen Seite. Google Analytics und die Google Search Console lassen sich weiterhin integrieren; dafür ist kein CMS erforderlich.

Einfachere Wiederherstellung

Die vollständige Website kann lokal gespeichert, versioniert, geprüft und als klar definierter Stand veröffentlicht werden. Der nächste sinnvolle Schritt ist ein durchgängiger Workflow aus Versionsverwaltung, automatisierten Prüfungen und reproduzierbarem Deployment. Genau daran arbeite ich gerade.

Drei Websites, drei vollständige Rebuilds

Ich habe die beschädigten Reste und lokal vorhandenen Materialien nicht einfach eins zu eins kopiert. Der Ausfall war bereits passiert, also habe ich die Gelegenheit genutzt und alle drei Projekte technisch und inhaltlich modernisiert.

• New Advertising / seo-website-grafiker.de: persönliche Website, digitale Visitenkarte, Arbeitsproben, Blog und die inhaltliche Weiterentwicklung in Richtung AI und Software Engineering.
• Fix & Flott: vollständig überarbeitete Werkstatt-Website mit lokaler SEO-Struktur, individuellen Leistungsseiten und eigenem HU-Rechner.
• Daniel Hacker: performantes Filmportfolio mit sauberer Video-Semantik, neu strukturierter Präsentation und technischer Suchmaschinenoptimierung.

Zu allen drei Rebuilds folgen eigene Beiträge mit Screenshots, PageSpeed-Ergebnissen und einem genaueren Blick auf die jeweilige technische Umsetzung.

Mein neuer Workflow: lokal, kontrolliert und agentengestützt

Texte und Konzeption entstehen weiterhin bei mir. Grafiken und Bildaufbereitung ebenfalls. Bei Programmierung, technischen Prüfungen und wiederkehrenden Aufgaben arbeite ich inzwischen mit einer kleinen Agentenfront – vor allem mit Codex und Claude Code, ergänzend mit Antigravity.

Das ersetzt nicht die fachliche Entscheidung. Es verändert aber die Geschwindigkeit, mit der sich eine statische Website pflegen und erweitern lässt. Was früher zwingend ein CMS-Backend erforderte, kann heute über einen kontrollierten lokalen Workflow, klare Vorlagen und automatisierte Prüfungen gelöst werden.

Ein vertrautes Problem – sogar für erfahrene Entwickler

Während des Wiederaufbaus bin ich auf ein Video des Informatikers und Tech-YouTubers Niklas Steenfatt gestoßen. Seine Schilderung hatte für mich deutliche Parallelen zu meiner Situation. Das war kein Trost im eigentlichen Sinne, aber zumindest die Bestätigung, dass ein solcher Vorfall nicht nur Menschen trifft, die noch nie einen Server administriert haben.

Video von Niklas Steenfatt ansehen: „Oh Mann …“ →

Mein Fazit zu IONOS

Ich bezahle seit vielen Jahren für diesen Vertrag. In einer Situation, in der schnelle und eindeutige Hilfe entscheidend gewesen wäre, erhielt ich widersprüchliche Aussagen, lange keine Antwort und schließlich sogar Hinweise auf eine mögliche mehrmonatige Sperre. Eine Entschuldigung, eine transparente technische Erklärung oder einen Vorschlag zur Kompensation des entstandenen Aufwands habe ich bis heute nicht erhalten.

Ob ich dauerhaft bei IONOS bleibe, ist deshalb offen. Andere Anbieter – unter anderem Hostinger – schaue ich mir an. Eine Entscheidung oder Empfehlung ist das ausdrücklich noch nicht.

Der Vorfall hat mich Rankings, sehr viel Zeit und einige Nerven gekostet. Eine klare Aufarbeitung seitens IONOS gab es nicht. Mein sehr persönliches Schlusswort lautet deshalb: Danke für nichts, IONOS.

Wie es weitergeht

Die drei Websites sind wieder online beziehungsweise befinden sich im letzten Ausbau. Fix & Flott und Daniel Hacker liefern bereits hervorragende technische Werte. Meine eigene Website wächst gerade weiter – insbesondere beim Blog, bei den Arbeitsproben und bei den Themen AI, Automatisierung und Software Engineering.

In den nächsten Beiträgen zeige ich die drei Rebuilds einzeln. Bis dahin gilt: Regelmäßige, tatsächlich wiederherstellbare Backups sind wichtiger als das gute Gefühl, dass schon nichts passieren wird. Und ein Hosting-Tarif ist nur so gut wie der Support, wenn es wirklich darauf ankommt.

Redaktioneller Hinweis: Dieser Beitrag schildert meine persönliche Erfahrung und meine Erinnerung an den damaligen Kommunikationsverlauf. Wo ich technische Ursachen nicht abschließend forensisch belegen konnte, habe ich dies entsprechend kenntlich gemacht. Sollte IONOS konkrete sachliche Fehler benennen oder eine technische Einordnung liefern, ergänze beziehungsweise korrigiere ich den Beitrag transparent.