Derzeit "ruckelt" der Blog: Ursache waren Bots

Kurze Info: Derzeit (6:40 ff.) stelle ich fest, dass der Blog hier etwas ruckelt und lange Antwortzeiten produziert. Ich habe den Besitzer mal per Mail kontaktiert, ob er was findet. Da ich derzeit unterwegs bin, kann ich eh nicht viel machen. Ergänzung: Ursache gefunden und beseitigt. Ich habe eine Erklärung nachgetragen.

Was war los?

Als ich heute (23.7.2026) gegen 6:40 Uhr im Administrationsbereich des IT-Blogs aktiv war, reagierten Seitenabrufe sporadisch für bis zu einer Minute nicht mehr. Es gab beim Erstellen von Beiträgen den Effekt, dass der Editor meldete, dass die Verbindung zum Blog verloren gegangen sei. Tests zeigten, dass die Blog-Seiten nicht abrufbar waren und bis zu einer Minute brauchten.

Gegenprüfungen mit meinen anderen Blogs auf borncity.eu ergaben, dass diese "pfeilschnell" antworteten. Schlechte Internetverbindung in der Ferienwohnung konnte ich also ausschließen. Mein grobes Bauchgefühl deutetet in Richtung "Probleme mit Plugins", hatte ich doch erst zum Wochenende den Blog auf WordPress 7.0.2 aktualisiert, um das im Beitrag Kritische WordPress-Schwachstelle wp2shell erlaubt CMS-Übernahme angesprochene Sicherheitsproblem abzufangen.

Da ich aber nicht mehr Besitzer und Betreiber des Blogs bin, kann ich nicht mehr auf den Sever zugreifen. Ich habe also, ähnlich wie am Wochenende beim Beitrag Kritische WordPress-Schwachstelle wp2shell erlaubt CMS-Übernahme meinem Ansprechpartner beim neuen Besitzer eine kurze Mail geschickt. Das 2p2shell-Thema konnte ich durch Aktualisierung der Blogs lösen – der Hauptblog auf borncity.com wurde inzwischen ebenfalls auf WordPress 7.0.2 aktualisiert.

Was war die Ursache für die "Ruckler"?

Der Ansprechpartner des neuen Besitzers hat sich im Laufe des Vormittags gemeldet und schrieb "danke für den Hinweis — Ursache gefunden und schon behoben". Laut meines Ansprechpartners wurden die "Ruckler" durch eine  eine bekannte WordPress-Falle plus aggressive Crawler verursacht.

Der Hintergrund: Bei verschachtelten Kommentaren erzeugt der IT-Blog hier pro Artikel rund 12 "Antworten"-Links der Form ?replytocom=N. Bei ~21.600 Artikeln sind das hunderttausende eindeutiger URLs. Laut Analyse folgt ein ganzer Schwarm Bots (Amazonbot, SentiBot, Bytespider, TikTokSpider, MJ12bot u.a.) jedem einzelnen Kommentar.

Da jede URL eines Kommentars einzigartig ist, greift der CDN-Cache nicht — jeder Aufruf geht voll auf den Server und löst eine "teure" DB-Abfrage über alle 21.600 Beiträge aus. Der Prozesspool des Blogs lief so wellenweise voll (heute laut Betreiber 40x am Limit), was die Antwortzeiten von bis über eine Minute verursachte.

Ich hatte den englischsprachigen Blog auch getestet, dort aber keine Probleme gefunden. Dazu schrieb mir mein Kontakt: "Zum Kontrast: heute 21.323 solcher Aufrufe auf /blog/ gegen nur 57 auf /win/ — deshalb war ausschließlich der deutsche Blog betroffen. Und es war kein 6:40-Ereignis, das läuft chronisch rund um die Uhr, Sie haben nur eine besonders spürbare Welle erwischt." Es waren also alles unproduktive Bot-Abfragen, die den Blog bzw. den Server in die Knie zwangen (was mich insgeheim ärgert).

Das ?replytocom-Problem

Der Parameter ?replytocom wird von WordPress in verschachtelten Kommentar-Threads verwendet. Wenn ein Nutzer auf "Antworten" klickt, wird diese URL generiert, damit die Seite neu geladen und das Antwortformular korrekt unter dem jeweiligen Kommentar platziert wird. Für Betreiber einer Website ist dieser Parameter jedoch oft problematisch:

• Duplicate Content: Suchmaschinen wie Google können diese URLs als eigenständige Seiten werten. Dies führt zu doppelten Inhalten und verschwendet sogenanntes Crawl-Budget.
• Indexierung: Oft werden diese Antwort-Links fälschlicherweise von Suchmaschinen indexiert.

Es sollte also möglichst vermieden werden, dass solche Konstruktionen auftreten.

Die Gegenmaßnahmen

Vom neuen Betreiber wurden Gegenmaßnahmen ergriffen, um die Last zu senken. Was jetzt live ist:

• Die ?replytocom-URLs werden direkt am Webserver auf die saubere Artikel-URL umgeleitet, bevor WordPress startet. SEO-neutral, für Leser ändert sich nichts.
• Die wertlosen Crawler ohne Suchmaschinen-Nutzen (SentiBot, Bytespider, TaranisAI, MJ12bot etc.) werden geblockt. Googlebot, Bingbot, Applebot bleiben unangetastet.
•  robots.txt entsprechend ergänzt und den Blog FPM-Pool zur Sicherheit von 35 auf 45 erhöht.

Effekt war laut meinem Ansprechpartner sofort messbar. Die Aufrufe werden jetzt umgeleitet statt durchgerechnet, der Pool ist wieder entspannt (9 statt 35 Prozesse), der IT-Blog antwortet wieder in ~0,3s.