Blog NinjaFirewall verursacht 302-Redirects für Autorenseiten

NinjaFirewall verursacht 302-Redirects für Autorenseiten

Ich bin ein großer Fan des Plugins „NinjaFirewall“ und von Web Application Firewalls im Allgemeinen (siehe z.B. auch meinen Beitrag über die Vorteile von WAFs). Vor Kurzem hat mir die NinjaFirewall aber einen fiesen Streich gespielt.

SEO-Analyse deckt Probleme auf

Eine SEO-Agentur hatte für einen Kunden eine Analyse durchgeführt und dabei festgestellt, dass die Autoren-Seiten mittels einer 302-Weiterleitung auf die Startseite umgeleitet werden.

Die Autoren-Seiten sind von WordPress automatisch erzeugte Archiv-Seiten, auf denen alle Beiträge eines Autors aufgelistet werden. Ist die Website kein Blog oder enthält insgesamt nur Beiträge eines Autors, sind diese Autoren-Seiten nicht sinnvoll und werden deswegen gerne deaktiviert. Da es sich um automatisch erzeugte Archive handelt, bedeutet diese Deaktivierung in der Regel eine automatische Weiterleitung aller URLs auf z.B. die Startseite. Da die Autoren-Seiten auch den Benutzernamen des Autors in der URL enthalten (/author/benutzername/), wird manchmal die Deaktivierung der Autorenseiten als Sicherheitsvorteil empfunden (Schnelle Anmerkung: ist Quatsch, aber ich kümmere mich auch gerne darum, dass die Autoren-URLs nicht den Benutzernamen, sondern Vor- und Nachname des Autors enthalten, z.B. über das Plugin Edit Author Slug).

Kurzer Überblick

Bei den Weiterleitungen muss man zwei verschiedene Varianten unterscheiden, die nach Ihrem HTTP-Statuscode differenziert werden.

301-Weiterleitungen sind Weiterleitungen, die den HTTP-Statuscode 301 zurückliefern. Dies bedeutet, dass diese Weiterleitung permanent ist. Eine solche Weiterleitung wird zum Beispiel gesetzt, wenn man die URL einer Seite ändert, die alte URL aber auf die neue URL weiterleiten soll. Oder wenn man eine Seite löscht und auf eine passende andere Seite weiterleitet.

Ein solcher Redirect ist auch für die Suchmaschinen wie Google vorteilhaft und nicht problematisch, da der Statuscode 301 auch der Suchmaschine mitteilt, dass diese Weiterleitung dauerhaft ist. In der Folge wird Google zum Beispiel die alte URL aus dem Index werfen.

Im Gegensatz dazu sind 302-Weiterleitungen Redirects temporärer Art. Solche Redirects werden in der Regel gesetzt, wenn Seiten zeitweise nicht verfügbar sind und in der Zwischenzeit eine Ersatzseite angezeigt werden soll.

Im oben benannten Fall war es nun so, dass alle Autoren-Seiten per 302-Weiterleitung auf die Startseite umgeleitet wurden. Somit blieben die Autorenseiten dauerhaft im Index (da die Umleitung ja nur temporär ist), obwohl die Seiten selbst niemals genutzt werden sollten. Eine 301-Weiterleitung wäre hier die richtige Lösung, denn die Autorenseiten wurden nie und würden nie genutzt.

Spurensuche

Wenn solche Redirects durchgeführt werden, kann es viele verschiedene Stellen geben, an denen diese definiert sind. Mein erster Anlaufpunkt war die .htaccess-Datei der Website. Darin befand sich jedoch keine Definition von 302-Weiterleitungen.

Die nächste Idee: Das Plugin „Yoast SEO“. In den Yoast-Einstellungen gibt es eine Funktion, die Autoren-Archive zu deaktivieren. Wenn dies per 302-Redirect geschehen würde, würde dies dafür sprechen, dass dies aus Sicht der Suchmaschinenoptimierung Sinn macht und der Wunsch der SEO-Agentur ggf. falsch wäre.

In Yoast SEO kann man über eine Einstellung zu Archiv-Seiten das Autoren-Archiv und damit die einzelnen Autorenseiten deaktivieren.

Also habe ich beim Yoast-Team nachgefragt. Die Antwort war jedoch eindeutig: nichts anderes als ein 301-Redirect sollte es sein.

Die Antwort von Jono Alderson war eindeutig: Yoast setzt nur 301-Redirects.

Wo also kam dieser 302-Redirect her? Ein Klassiker der WordPress-Fehlersuche musste her: alle Plugins deaktivieren einzeln und nacheinander wieder aktivieren. Zwischen jeder Plugin-Aktivierung testen, ob die Weiterleitung nun auftritt oder nicht.

In vielen Fällen kann man dazu das HealthCheck-Plugin nutzen, welche eine entsprechende Debugging-Option bietet, wodurch die Plugins nur für mich als eingeloggten Benutzer deaktiviert werden, die Seite selbst aber für alle anderen Besucher ganz normal weiter funktioniert. Dies ist immer dann hilfreich, wenn kein Test-System zur Verfügung steht, oder der Fehler spezifisch im Live-System gesucht werden muss. Leider funktioniert das Plugin nicht in allen Theme-/Plugin-Kombinationen zuverlässig, so dass es sich nicht immer einsetzen lässt.

NinjaFirewall als Ursache

Und siehe da: der Übeltäter war die NinjaFirewall. Auch diese hat Einstellungen zu den Autorenseiten. Hier geht es jedoch eher um die Enumeration der Benutzernamen auf Basis der Autorenseiten (siehe oben). Der Grund ist jedoch egal, denn auch die Firewall richtet an dieser Stelle einfach eine Weiterleitung ein, jedoch mit Statuscode 302. Warum genau 302 und nicht auch 301, konnte ich nicht in Erfahrung bringen.

Ist die Funktion zum Schutz gegen Enumeration der Benutzernamen in NinjaFirewall aktiv, liefert die Firewall 302-Redirects zurück.

Jedoch war die Lösung für mich hier einfach: die entsprechende Option in der Firewall habe ich deaktiviert, in Yoast SEO blieb die Einstellung aktiv, so dass weiterhin alle Autorenseiten umgeleitet wurden, nun jedoch passend per 301-Weiterleitung.

Als Ergänzung: dies bedeutet natürlich auch, dass Websites, die gerne die Autoren-Seiten nutzen möchten (zum Beispiel in einem Blog mit mehreren Autoren), die Firerwall-Option zur Benutzer-Enumeration ebenso nicht deaktivieren sollten.

2 Gedanken zu „NinjaFirewall verursacht 302-Redirects für Autorenseiten“

  1. Hallo Marc,
    danke für diesen wirklich hilfreichen Beitrag.
    Ich hatte das Problem mit dem Plugin ActivityPub. Unter Werkzeuge > Website-Zustand wurde mir da ein (kritischer) Fehler gezeigt. Ich habe auch erst auf YOAST getippt – zumal das als Fehlerquelle angegeben war. Letztendlich musste ich genau wie du alle Plugins deaktivieren und siehe da: es war NinjaFirewall.
    Bei der Recherche bin ich dann auf deinen Beitrag gestoßen.
    Vielleicht noch hilfreich: Die von dir genannte Option befindet sich unter Firewall Policies > WordPress

    Antworten

Schreibe einen Kommentar