Kommentar-Spam per htaccess blockieren

Q: Können echte Kommentare durch die htaccess-Regel blockiert werden?

Nein, solange Besucher über einen normalen Browser kommentieren. Browser senden immer einen User-Agent und den Referer. Die Regel greift nur bei direkten POST-Requests ohne diese Informationen.

Q: Funktioniert das auch ohne WordPress?

Das Prinzip funktioniert mit jedem CMS. Man muss lediglich wp-comments-post.php durch den Pfad der eigenen Kommentar-Verarbeitung ersetzen.

Hinweis 2026: Der htaccess-Trick funktioniert auch 14 Jahre nach dem Original noch. Was sich geändert hat: xmlrpc.php kannst du in modernen WordPress-Setups komplett deaktivieren (Disable XML-RPC-Plugin oder ein eigener Header-Block). Statt eines klassischen Captchas nehmen viele heute Cloudflare Turnstile oder Antispam Bee in der aktuellen Version. Kombination aus htaccess-Layer plus modernem Plugin ist 2026 weiter die robusteste Variante.

Warum Kommentar-Spam auf Server-Ebene blockieren?

WordPress-Plugins wie Antispam Bee oder Akismet filtern Spam erst, nachdem der Kommentar die Datenbank erreicht hat. Das funktioniert, kostet aber bei jeder Anfrage Rechenleistung - PHP wird ausgeführt, die Datenbank abgefragt, das Plugin prüft den Inhalt.

Mit einer htaccess-Regel fängst du Spam-Bots eine Ebene früher ab: direkt auf dem Apache-Webserver. Die Anfrage wird sofort abgelehnt, bevor WordPress überhaupt geladen wird. Das spart Serverressourcen und macht dein Blog schneller, weil weniger unsinnige Requests verarbeitet werden müssen.

Diese Methode ersetzt kein Spam-Plugin - sie ergänzt es. Die htaccess-Regel fängt automatisierte Bots ab, während ein Plugin die wenigen Spam-Kommentare filtert, die von echten Browsern kommen.

Der komplette htaccess-Code

Kopiere den folgenden Code in die .htaccess im WordPress-Stammverzeichnis. Ersetze deine-domain.de durch deine eigene Domain:

# Kommentar-Spam-Bots blockieren
<IfModule mod_rewrite.c>
  RewriteEngine On

  # Bedingung 1: Nur POST-Requests prüfen
  RewriteCond %{REQUEST_METHOD} POST

  # Bedingung 2: Nur Zugriffe auf wp-comments-post.php
  RewriteCond %{REQUEST_URI} ^/wp-comments-post\.php$

  # Bedingung 3: Referer muss die eigene Domain sein
  RewriteCond %{HTTP_REFERER} !^https?://(www\.)?deine-domain\.de [NC,OR]

  # Bedingung 4: Kein User-Agent vorhanden (typisch für Bots)
  RewriteCond %{HTTP_USER_AGENT} ^$

  # Aktion: Anfrage mit 403 Forbidden ablehnen
  RewriteRule .* - [F,L]
</IfModule>

Was macht jede Zeile?

Der Code besteht aus vier Bedingungen (RewriteCond) und einer Aktion (RewriteRule). Nur wenn alle Bedingungen zutreffen, wird die Anfrage blockiert:

Zeile	Funktion
`RewriteCond %{REQUEST_METHOD} POST`	Prüft nur POST-Anfragen. Normale Seitenaufrufe (GET) sind nicht betroffen.
`RewriteCond %{REQUEST_URI} ^/wp-comments-post\.php$`	Greift nur bei Zugriffen auf die Kommentar-Datei von WordPress.
`RewriteCond %{HTTP_REFERER} !^https?://...`	Der Referer muss von der eigenen Domain stammen. Direkte Aufrufe ohne Referer oder von fremden Seiten werden abgefangen.
`RewriteCond %{HTTP_USER_AGENT} ^$`	Fängt Bots ab, die sich nicht als Browser ausgeben (leerer User-Agent).
`RewriteRule .* - [F,L]`	Gibt einen 403-Fehler (Forbidden) zurück und beendet die Verarbeitung.

Die Bedingungen 3 und 4 sind mit [OR] verknüpft. Das bedeutet: Die Anfrage wird blockiert, wenn der Referer nicht stimmt oder kein User-Agent gesendet wird. Beides sind typische Merkmale von automatisierten Spam-Bots.

Anpassungen für deine Seite

Domain anpassen

Ersetze deine-domain\.de durch deine echte Domain. Der Backslash vor dem Punkt ist wichtig, weil der Punkt in regulären Ausdrücken sonst als Platzhalter für jedes Zeichen gilt. Beispiele:

mein-blog\.de - einfache .de-Domain
mein-blog\.com - .com-Domain
(www\.)?mein-blog\.de - mit und ohne www (bereits im Code enthalten)

HTTPS und HTTP

Der Code berücksichtigt beide Protokolle (https?://). Das Fragezeichen nach dem s macht das s optional, sodass sowohl http als auch https als gültiger Referer akzeptiert werden.

403 statt 301-Redirect

Im Originalcode aus 2012 wurde der Bot per 301-Redirect an seine eigene IP-Adresse weitergeleitet (http://%{REMOTE_ADDR}). Das ist clever, aber nicht mehr zeitgemäß. Ein direkter 403 Forbidden ist sauberer: Der Bot bekommt eine klare Absage, es wird kein Redirect ausgelöst und dein Server muss keine zusätzliche Anfrage verarbeiten.

Erweiterte Version mit zusätzlichem Schutz

Wenn du den Schutz weiter verschärfen willst, kannst du bekannte Spam-Quellen zusätzlich blockieren:

# Erweiterte Spam-Abwehr
<IfModule mod_rewrite.c>
  RewriteEngine On

  # Basis: Kommentar-Spam blockieren
  RewriteCond %{REQUEST_METHOD} POST
  RewriteCond %{REQUEST_URI} ^/wp-comments-post\.php$
  RewriteCond %{HTTP_REFERER} !^https?://(www\.)?deine-domain\.de [NC,OR]
  RewriteCond %{HTTP_USER_AGENT} ^$
  RewriteRule .* - [F,L]

  # Zusatz: Bekannte Spam-Bots per User-Agent blockieren
  RewriteCond %{HTTP_USER_AGENT} (semalt|sogou|baidu|360spider) [NC]
  RewriteRule .* - [F,L]

  # Zusatz: Trackback/Pingback-Spam unterbinden
  RewriteCond %{REQUEST_METHOD} POST
  RewriteCond %{REQUEST_URI} ^/xmlrpc\.php$
  RewriteRule .* - [F,L]
</IfModule>

Die zusätzliche Regel für xmlrpc.php blockiert auch Trackback- und Pingback-Spam, der über die XML-RPC-Schnittstelle von WordPress eingeschleust wird. Diese Schnittstelle wird außerdem häufig für Brute-Force-Angriffe auf den Login missbraucht.

Was sich 2026 ergänzen lässt

Der Original-Trick aus 2012 fängt unkomplizierte Bots ab. Drei Ergänzungen, die ich heute zusätzlich einsetzen würde:

xmlrpc.php komplett deaktivieren. Wenn du Jetpack oder die WordPress-Mobile-App nicht nutzt, brauchst du XML-RPC nicht. Plugin "Disable XML-RPC" einsetzen oder den Endpunkt per htaccess hart auf 403 setzen: <Files xmlrpc.php>Require all denied</Files>. Das ist klarer als die RewriteCond-Variante oben.
Cloudflare Turnstile vor wp-comments-post.php hängen. Turnstile ist Googles reCAPTCHA-Alternative ohne nervige Bilderrätsel. Für WordPress gibt es Plugins wie "Simple Cloudflare Turnstile", die das Widget direkt ins Kommentarformular bauen. Bots ohne Browser-Engine scheitern am Token-Check, echte Besucher sehen praktisch nichts.
Antispam Bee in aktueller Version. Seit Version 2.11 ohne externe Datenabfragen DSGVO-kompatibel. Filtert Inhalt nach Sprache, Honeypot-Feldern und Reputation der IP. Gute Ergänzung zur Server-Ebene, die nur die einfachen Bots erwischt.
Akismet bleibt valide, wenn du den kommerziellen Aspekt nicht stört. Akismet sieht jeden Kommentar weltweit und hat dadurch die größte Trainingsbasis. Für reine Hobbyblogs ist Antispam Bee oft die schlankere Wahl.

Wer einen Layer mehr will: ein htaccess-Block für bekannte Bot-Netzwerke (vor allem die ASN-Bereiche russischer/asiatischer Hosting-Provider) reduziert die Gesamt-Last sichtbar. Dafür gibt es Listen wie abuseipdb.com, die du periodisch ziehen und in .htaccess als Deny from-Block einbauen kannst.

Funktioniert es?

Nach dem Einfügen der Regeln kannst du testen, ob alles korrekt funktioniert. Schreibe einen Testkommentar auf deinem Blog - der muss wie gewohnt durchkommen, weil du von deiner eigenen Domain kommst und einen Browser mit User-Agent benutzt.

Im Apache-Errorlog (/var/log/apache2/error.log oder über das Hosting-Panel einsehbar) siehst du blockierte Anfragen als 403-Einträge. Nach ein paar Tagen kannst du dort nachschauen, wie viele Spam-Versuche abgefangen wurden.

Häufige Fragen

Können echte Kommentare blockiert werden?

Nein, solange deine Besucher über einen normalen Browser kommentieren. Browser senden immer einen User-Agent und den Referer der Seite, auf der das Kommentarformular steht. Die Regel greift nur bei direkten POST-Requests ohne diese Informationen.

Funktioniert das auch ohne WordPress?

Das Prinzip funktioniert mit jedem CMS, das Kommentare über eine bestimmte Datei verarbeitet. Du musst lediglich wp-comments-post.php durch den Pfad deiner Kommentar-Verarbeitung ersetzen.

Muss ich trotzdem ein Spam-Plugin nutzen?

Empfehlenswert ist es. Die htaccess-Methode blockiert nur einfache Bots. Ausgefeilte Spam-Software simuliert echte Browser mit User-Agent und korrektem Referer. Für diese Fälle brauchst du ein Plugin wie Antispam Bee, das den Inhalt analysiert.