\u00d6ffnen Sie das Stammverzeichnis einer beliebigen, lang betriebenen WordPress-Website per SFTP, und Sie finden Dateien, die dort nicht hingeh\u00f6ren. Alte Entwickler-Backups mit Namen wie functions24-02-2026.php. Vergessene Testdateien wie info.php. Komprimierte Archive fr\u00fcherer Installationen. Von Plugins exportierte Tabellen. SQL-Dumps, die von einer Migration im letzten Jahr \u00fcbrig sind. Die Website l\u00e4uft weiter, also entfernt sie niemand, und sie stapeln sich.<\/p>
Das meiste davon ist harmloser Ballast. Manches sind ernste Sicherheits- und SEO-Risiken. Das Problem: Nur sehr wenige Website-Betreiber schauen \u00fcberhaupt hin, also ist die Grenze zwischen beidem unsichtbar. Dieser Artikel beschreibt die h\u00e4ufigsten Kategorien, warum manche davon z\u00e4hlen und wie Sie das Stammverzeichnis regelm\u00e4\u00dfig pr\u00fcfen.<\/p>
Ein k\u00fcrzlicher Audit auf der Website einer Agentur in Sydney, mit der wir zusammengearbeitet haben, f\u00f6rderte 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 \u00e4hnlich datierter Geschwisterdateien. Jede war ein Entwickler-Backup, vor einer \u00c4nderung angelegt, als lokale R\u00fcckfalloption gedacht und nie gel\u00f6scht.<\/p>
WordPress l\u00e4dt diese Dateien nicht, sie beeinflussen das Verhalten der Website also nicht. Aber sie sind \u00fcber ihre URL \u00f6ffentlich zug\u00e4nglich. Wer den Dateinamen err\u00e4t, kann den Quellcode fr\u00fcherer Versionen lesen, der Zugangsdaten, fest verdrahtete Pfade oder verwundbare Funktionssignaturen enthalten kann. Sie erschweren zudem jeden k\u00fcnftigen Audit, weil sie den Code mit Dateien zum\u00fcllen, die echt aussehen, es aber nicht sind.<\/p>
Der richtige Ort f\u00fcr Code-Backups ist die Versionsverwaltung, nicht der Live-Server. Verschieben Sie sie nach git und l\u00f6schen Sie die datierten Kopien.<\/p>
Eine SQL-Datei mit dem Datenbank-Export im Stammverzeichnis ist eines der gef\u00e4hrlichsten Artefakte auf einer WordPress-Website. L\u00e4dt ein Angreifer sie herunter, hat er Ihre Benutzertabelle, Ihre gehashten Passw\u00f6rter, Ihre geheimen Schl\u00fcssel \u00fcber wp_options und jeden Inhalt. Dasselbe gilt f\u00fcr komprimierte Backup-Archive der gesamten Website.<\/p>
Backup-Dateien sollten niemals im Stammverzeichnis liegen. Sie geh\u00f6ren ausgelagert, an einen Speicherort, den das \u00f6ffentliche Web nicht erreichen kann. Finden Sie irgendein Backup-Archiv im Stammverzeichnis, entfernen Sie es sofort und pr\u00fcfen Sie die Zugriffsprotokolle Ihres Hostings auf fr\u00fchere Downloads.<\/p>
Der klassische Fehler. Ein Entwickler will eine Konfigurations\u00e4nderung vornehmen. Er kopiert wp-config.php nach wp-config.bak als Sicherheitsnetz. Er nimmt die \u00c4nderung vor. Er l\u00e4sst das Backup zur\u00fcck. Die Endung .bak wird von PHP nicht ausgef\u00fchrt, also wird die Datei als reiner Text ausgeliefert. Jeder Angreifer, der den naheliegenden Dateinamen probiert, hat Ihre vollst\u00e4ndige Konfiguration, einschlie\u00dflich Datenbank-Zugangsdaten und Salts.<\/p>
Lassen Sie niemals eine Kopie von wp-config in irgendeiner Form auf dem Live-Server. Nutzen Sie die Versionsverwaltung. Wenn Sie kopieren m\u00fcssen, kopieren Sie an einen Pfad au\u00dferhalb des Stammverzeichnisses und entfernen Sie ihn, sobald die Arbeit erledigt ist.<\/p>
Viele Entwickler legen eine kleine info.php-Datei mit phpinfo an, um die PHP-Version auf einem neuen Server zu pr\u00fcfen, und vergessen dann, sie zu l\u00f6schen. Die Datei bleibt zug\u00e4nglich, und phpinfo gibt eine enorme Menge an Serverdetails preis, die Angreifer zur Angriffsplanung nutzen k\u00f6nnen. PHP-Version, geladene Erweiterungen, Serverpfade, Umgebungsvariablen, manchmal mehr.<\/p>
Jede Testdatei, so harmlos sie aussieht, sollte entfernt werden, sobald sie ihren Zweck erf\u00fcllt hat. info.php, test.php, hello.html \u2013 alles, was Sie auf der \u00f6ffentlichen Website nicht brauchen, geh\u00f6rt nicht dorthin.<\/p>
Das ist der gef\u00e4hrliche Fall. Existiert auf der Festplatte ein Ordner mit demselben Namen wie eine WordPress-Seite, l\u00f6st 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.<\/p>
Der erw\u00e4hnte Fall der Agentur in Sydney war genau dieses Muster. Der Angreifer legte f\u00fcnf 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\u00fcnglichen Seiten, und ein fl\u00fcchtiger Besuch der Startseite sah normal aus.<\/p>
Pr\u00fcfen Sie das Stammverzeichnis gezielt auf Ordner, die zu WordPress-Seiten-Slugs passen. Alles, was Sie nicht erkl\u00e4ren k\u00f6nnen, ist verd\u00e4chtig.<\/p>
Manche Texteditoren erzeugen beim Bearbeiten tempor\u00e4re Swap-Dateien: Endungen .swp, ~, .orig und \u00c4hnliches. Bearbeitet ein Entwickler eine Datei direkt auf dem Server, k\u00f6nnen diese zur\u00fcckbleiben. Sie enthalten oft denselben Inhalt wie die Originaldatei, werden aber von PHP nicht ausgef\u00fchrt, also als reiner Text ausgeliefert, wenn man sie \u00fcber die URL aufruft.<\/p>
Schlimmer noch: Ein im Stammverzeichnis zur\u00fcckgelassenes .git-Verzeichnis kann das gesamte Repository offenlegen, samt vergangener Commits, Branches und historischer Geheimnisse. Das war \u00fcber die Jahre Ursache mehrerer aufsehenerregender Datenlecks. Der .git-Ordner sollte niemals auf einem Live-Server liegen \u2013 oder falls doch, muss er auf Serverebene blockiert werden.<\/p>
Der Audit ist unkompliziert. Verbinden Sie sich per SFTP oder \u00fcber den Dateimanager Ihres Hosters. Durchsuchen Sie das Stammverzeichnis. Alles au\u00dferhalb 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.<\/p>
Suchen Sie im Ordner des aktiven Themes nach datierten Backups, Testdateien und Editor-\u00dcberresten. Suchen Sie im Plugin-Ordner nach inaktiven Plugins und erw\u00e4gen Sie, sie ganz zu entfernen. Suchen Sie in uploads nach PHP-Dateien. Dort sollten fast keine sein.<\/p>
Monatlich ist f\u00fcr eine Unternehmenswebsite angemessen. Viertelj\u00e4hrlich ist das Minimum. Nach jeder Entwicklungsarbeit, die direkte Datei\u00e4nderungen auf dem Live-Server umfasste. Nach jedem Vorfall, egal wie klein.<\/p>