Website Traffic- und Speicher-Problem 2026

Im Juni 2026 meldete der Hosting-Anbieter (Pressidium) der GfWM-Website dem Vorstand 2026–2028 eine anhaltende und deutliche Überschreitung der im Tarif enthaltenen Besuchszahlen sowie eine Speichernutzung über dem Kontingent, verbunden mit dem Nahelegen, in einen erheblich teureren Tarif zu wechseln.

Ausgangslage

Der Tarif der Website ("Personal") umfasst 30.000 Besuche pro Monat und 10 GB Speicher. Eine vom Support bereitgestellte Zwölfmonatsübersicht (Juli 2025 bis Juni 2026) zeigte, wie weit die gemessenen Werte darüber lagen:

• Die Besuchszahlen lagen im Schnitt bei rund 370.000 pro Monat, also mehr als dem Zehnfachen des Tarifs. Dabei schwankten sie zwischen 64.000 (Juli 2025) bis 1,6 Millionen (August 2025).
• Der Speicherverbrauch lag durchgehend über dem Limit, zuletzt bei rund 14,5 GB (über das Jahr langsam steigend).
• Die Bandbreite (im Tarif unbegrenzt) blieb dagegen unauffällig bei 20 bis 48 GB pro Monat und wuchs nicht annähernd im Verhältnis zu den Besuchszahlen.

Analyse

Die Auswertung der Hosting-Statistiken ergab, dass der überwiegende Teil des Traffics nicht von echten Besucher*innen stammt, sondern von Bots. Dafür sprachen die schiere Menge an Zugriffen (teils Millionen im Monat) sowie die folgenden Beobachtungen:

• Das Verhältnis von Zugriffen zu übertragener Datenmenge lag in den Spitzenmonaten bei einem Bruchteil dessen, was ein echter Seitenaufruf erzeugt.
• Die geografische Verteilung zeigte die meisten Zugriffe aus Ländern und Netzen, in denen große Rechenzentren stehen, nicht aus dem DACH-Raum, in dem unsere Zielgruppe überwiegend sitzt.

Das Bot-Problem war ebenfalls die Ursache für die Übernutzung des Speichers. Das Statistik-Plugin "WP Statistics" hatte über Jahre jeden einzelnen Seitenaufruf in der Datenbank protokolliert. Die Statistik-Tabellen waren dadurch auf 2,3 GB angewachsen und machten den mit Abstand größten Teil der Datenbank aus. Die eigentlichen Inhalte der Website (Seiten und Medien) belegen dagegen einen erwartbaren Teil des Speichers (2,5 GB).

Auf das Kontingent zählen jedoch nicht nur die sichtbaren Website-Dateien und die Datenbank, sondern auch die Staging-Umgebung, Logdateien sowie die täglichen Backups, die 15 Tage lang vorgehalten werden. Die aufgeblähte Datenbank lag damit in jeder dieser Sicherungen erneut und ging entsprechend mehrfach in den ausgewiesenen Speicherverbrauch ein. Dieser lag deshalb deutlich über dem, was auf der Website selbst tatsächlich belegt war.

Maßnahmen

Bereinigung der Datenbank

Die aufgeblähten Statistik-Tabellen wurden geleert. Die Datenbank schrumpfte dadurch von 2,6 GB auf rund 300 MB. Für die Zukunft wurde eine Aufbewahrungsfrist von 180 Tagen eingerichtet. Ältere Daten werden seitdem automatisch zu Tages-Summenwerten zusammengefasst, sodass Langzeit-Trends erhalten bleiben. Die Bereinigung der Datenbank wurde am 15.07.2026 durchgeführt.

Löschung der Staging-Umgebung

Neben der Produktiv-Website existierte eine Staging-Umgebung, ein vollständiger Klon der Website aus dem Jahr 2024, der mit Dateien und Datenbank rund 4,5 GB des Speicherkontingents belegte, aber keine eigenen Inhalte enthielt. Da sich eine Staging-Kopie bei Bedarf jederzeit frisch aus der Produktiv-Website erzeugen lässt, wurde sie nach Rücksprache mit dem Support am 20.07.2026 gelöscht.

Cloudflare

Als wirksamste Maßnahme gegen den Bot-Traffic wurde der Dienst Cloudflare (im kostenlosen Tarif) vor die Website geschaltet. Cloudflare übernimmt seitdem die DNS-Verwaltung der Hauptdomain und arbeitet als vorgelagerter Filter (sämtliche Aufrufe der Website laufen zuerst über das Cloudflare-Netz). Automatisierte Zugriffe werden dort erkannt und abgewiesen, bevor sie unseren Hoster überhaupt erreichen.

Die Umstellung der Nameserver auf Cloudflare wurde am 24.07.2026 durchgeführt und verlief ohne Unterbrechung. Als Nebenwirkung kam es anschließend zu Abmeldungen im WordPress-Backend nach fast jedem Klick; Ursache war ein zusätzlich installiertes Login-Schutz-Plugin ("Limit Login Attempts Reloaded"), das mit der Server-Architektur des Hosters hinter Cloudflare nicht kompatibel ist. Es wurde entfernt; der Hoster stellt ohnehin ein eigenes Login-Schutz-Plugin bereit.

Ergänzend wurde eine Regel eingerichtet, die automatisierte Zugriffe auf die WordPress-Anmeldeseite (/wp-login.php) bereits bei Cloudflare abfängt, da diese nach der Umstellung der größte verbliebene Anteil unerwünschten Traffics waren.

Ergebnis

Nach der Backup-Rotation liegt der Speicherverbrauch bei rund 5 GB (rund 9 GB weniger als zuvor) und damit deutlich unter dem Limit von 10 GB.

Der Traffic ist nach der Cloudflare-Umstellung auf ein realistisches Maß zurückgegangen. Die eigenständige Zählung der Website ergibt für die ersten vollen Tage nach der Umstellung rund 500 Besuche pro Tag, hochgerechnet eine Größenordnung von 10.000 bis 15.000 pro Monat. Gegenüber dem Zwölfmonatsschnitt von rund 370.000 Besuchen pro Monat entspricht das einem Rückgang von etwa 96 %.