Öffnen Sie das Stammverzeichnis einer beliebigen, lang betriebenen WordPress-Website per SFTP, und Sie finden Dateien, die dort nicht hingehören. Alte Entwickler-Backups mit Namen wie functions24-02-2026.php. Vergessene Testdateien wie info.php. Komprimierte Archive früherer Installationen. Von Plugins exportierte Tabellen. SQL-Dumps, die von einer Migration im letzten Jahr übrig sind. Die Website läuft weiter, also entfernt sie niemand, und sie stapeln sich.
Das meiste davon ist harmloser Ballast. Manches sind ernste Sicherheits- und SEO-Risiken. Das Problem: Nur sehr wenige Website-Betreiber schauen überhaupt hin, also ist die Grenze zwischen beidem unsichtbar. Dieser Artikel beschreibt die häufigsten Kategorien, warum manche davon zählen und wie Sie das Stammverzeichnis regelmäßig prüfen.
Datierte Sicherungskopien von Theme-Dateien
Ein kürzlicher Audit auf der Website einer Agentur in Sydney, mit der wir zusammengearbeitet haben, förderte Dutzende davon zutage. Der Ordner des aktiven Themes enthielt functions24-02-2026.php, header31-01-2026.php, footer19-01-2026.php, 404-04-08-2025.php und eine lange Liste ähnlich datierter Geschwisterdateien. Jede war ein Entwickler-Backup, vor einer Änderung angelegt, als lokale Rückfalloption gedacht und nie gelöscht.
WordPress lädt diese Dateien nicht, sie beeinflussen das Verhalten der Website also nicht. Aber sie sind über ihre URL öffentlich zugänglich. Wer den Dateinamen errät, kann den Quellcode früherer Versionen lesen, der Zugangsdaten, fest verdrahtete Pfade oder verwundbare Funktionssignaturen enthalten kann. Sie erschweren zudem jeden künftigen Audit, weil sie den Code mit Dateien zumüllen, die echt aussehen, es aber nicht sind.
Der richtige Ort für Code-Backups ist die Versionsverwaltung, nicht der Live-Server. Verschieben Sie sie nach git und löschen Sie die datierten Kopien.
SQL-Dumps und Backup-Archive
Eine SQL-Datei mit dem Datenbank-Export im Stammverzeichnis ist eines der gefährlichsten Artefakte auf einer WordPress-Website. Lädt ein Angreifer sie herunter, hat er Ihre Benutzertabelle, Ihre gehashten Passwörter, Ihre geheimen Schlüssel über wp_options und jeden Inhalt. Dasselbe gilt für komprimierte Backup-Archive der gesamten Website.
Backup-Dateien sollten niemals im Stammverzeichnis liegen. Sie gehören ausgelagert, an einen Speicherort, den das öffentliche Web nicht erreichen kann. Finden Sie irgendein Backup-Archiv im Stammverzeichnis, entfernen Sie es sofort und prüfen Sie die Zugriffsprotokolle Ihres Hostings auf frühere Downloads.
Konfigurations-Backups wie wp-config.bak
Der klassische Fehler. Ein Entwickler will eine Konfigurationsänderung vornehmen. Er kopiert wp-config.php nach wp-config.bak als Sicherheitsnetz. Er nimmt die Änderung vor. Er lässt das Backup zurück. Die Endung .bak wird von PHP nicht ausgeführt, also wird die Datei als reiner Text ausgeliefert. Jeder Angreifer, der den naheliegenden Dateinamen probiert, hat Ihre vollständige Konfiguration, einschließlich Datenbank-Zugangsdaten und Salts.
Lassen Sie niemals eine Kopie von wp-config in irgendeiner Form auf dem Live-Server. Nutzen Sie die Versionsverwaltung. Wenn Sie kopieren müssen, kopieren Sie an einen Pfad außerhalb des Stammverzeichnisses und entfernen Sie ihn, sobald die Arbeit erledigt ist.
Testdateien und info.php
Viele Entwickler legen eine kleine info.php-Datei mit phpinfo an, um die PHP-Version auf einem neuen Server zu prüfen, und vergessen dann, sie zu löschen. Die Datei bleibt zugänglich, und phpinfo gibt eine enorme Menge an Serverdetails preis, die Angreifer zur Angriffsplanung nutzen können. PHP-Version, geladene Erweiterungen, Serverpfade, Umgebungsvariablen, manchmal mehr.
Jede Testdatei, so harmlos sie aussieht, sollte entfernt werden, sobald sie ihren Zweck erfüllt hat. info.php, test.php, hello.html – alles, was Sie auf der öffentlichen Website nicht brauchen, gehört nicht dorthin.
Seiten und Ordner, die WordPress-URLs überschatten
Das ist der gefährliche Fall. Existiert auf der Festplatte ein Ordner mit demselben Namen wie eine WordPress-Seite, löst der Webserver zuerst den Ordner auf. Das URL-Routing von WordPress bekommt nie die Chance, die Anfrage zu bearbeiten. Der Besucher sieht den Inhalt des Ordners, nicht die WordPress-Seite.
Der erwähnte Fall der Agentur in Sydney war genau dieses Muster. Der Angreifer legte fünf Ordner im Stammverzeichnis an, benannt nach echten WordPress-Seiten. Dateien in diesen Ordnern fingen jede Anfrage an diese URLs ab und lieferten getarnten SEO-Spam aus. Der Betreiber hatte keine Ahnung, denn das WordPress-Backend zeigte weiterhin die ursprünglichen Seiten, und ein flüchtiger Besuch der Startseite sah normal aus.
Prüfen Sie das Stammverzeichnis gezielt auf Ordner, die zu WordPress-Seiten-Slugs passen. Alles, was Sie nicht erklären können, ist verdächtig.
Editor-Swap-Dateien und Versionsverwaltungs-Verzeichnisse
Manche Texteditoren erzeugen beim Bearbeiten temporäre Swap-Dateien: Endungen .swp, ~, .orig und Ähnliches. Bearbeitet ein Entwickler eine Datei direkt auf dem Server, können diese zurückbleiben. Sie enthalten oft denselben Inhalt wie die Originaldatei, werden aber von PHP nicht ausgeführt, also als reiner Text ausgeliefert, wenn man sie über die URL aufruft.
Schlimmer noch: Ein im Stammverzeichnis zurückgelassenes .git-Verzeichnis kann das gesamte Repository offenlegen, samt vergangener Commits, Branches und historischer Geheimnisse. Das war über die Jahre Ursache mehrerer aufsehenerregender Datenlecks. Der .git-Ordner sollte niemals auf einem Live-Server liegen – oder falls doch, muss er auf Serverebene blockiert werden.
Wie man prüft
Der Audit ist unkompliziert. Verbinden Sie sich per SFTP oder über den Dateimanager Ihres Hosters. Durchsuchen Sie das Stammverzeichnis. Alles außerhalb der WordPress-Standard-Kern-Dateien im Stamm sowie den Ordnern wp-admin, wp-includes und wp-content sollte untersucht werden. Alles in wp-content, das nicht themes, plugins, uploads, mu-plugins oder ein bekannter Cache-Ordner ist, verdient einen genaueren Blick.
Suchen Sie im Ordner des aktiven Themes nach datierten Backups, Testdateien und Editor-Überresten. Suchen Sie im Plugin-Ordner nach inaktiven Plugins und erwägen Sie, sie ganz zu entfernen. Suchen Sie in uploads nach PHP-Dateien. Dort sollten fast keine sein.
Wie oft
Monatlich ist für eine Unternehmenswebsite angemessen. Vierteljährlich ist das Minimum. Nach jeder Entwicklungsarbeit, die direkte Dateiänderungen auf dem Live-Server umfasste. Nach jedem Vorfall, egal wie klein.
Brauchen Sie Unterstützung?
Wenn Sie das Stammverzeichnis Ihrer WordPress-Website prüfen und den Ballast beseitigen lassen möchten, kann Defyn das übernehmen. Es ist eine stille Aufgabe, die oft Probleme zutage fördert, die sonst niemand bemerkt hat.
