Eure WordPress Unterseiten sind auf URLs mit und ohne Trailing Slash erreichbar? Es ist möglich, dass dies im Zusammenhang mit der Nutzung von W3Total Cache steht.
Im Mai 2019 habe ich mit dem Experiment zur WordPress-Pagespeed-Optimierung eine Reihe von Maßnahmen zur Performance-Steigerung von internetzkidz.de vorgenommen. Mittlerweile habe ich schon die zweite Problematik in der damaligen Konfiguration gefunden, die mich mittelfristig auf dem Weg zu einer besseren Site zurückgeworfen hat.
Die erste Erfahrung habe ich im Artikel w3total Cache & Autoptimize Konflikt Canonical Slash dokumentiert.
Problemstellung: Zwei Unterseiten-Versionen durch Trailing Slash Handling
Vor ein paar Tagen habe ich festgestellt, dass meine Unterseiten und Blogbeiträge jeweils unter zwei unterschiedlichen URLs erreichbar waren. Eine Version hatte einen Slash am Ende der URL, die andere nicht. So haben z.B. die URLs
https://internetzkidz.de/glossar und https://internetzkidz.de/glossar/ beide eigene HTML-Dokumente beim Aufruf.
Das erwartete Verhalten wäre ein 301-Redirect von der URL /glossar zu der URL /glossar/. Dadurch würden Nutzer und Crawler immer nur eine Seite angezeigt werden. Die Version der Site ohne Trailing Slash würde praktisch nicht existieren. Dieses Verhalten der automatischen Weiterleitung ist in WordPress eigentlich standardmäßig konfiguriert, wenn der Nutzer nicht in die Permalink-Struktur eingegriffen hat. Die Grundlage dafür bietet die .htaccess-Datei auf dem Server.
Das Ganze hat mir die Schweißperlen auf die Stirn getrieben, da doppelte Inhalte Suchmaschinen den Eindruck von Spam vermitteln können, was zu einer schlechteren Performance in den Suchergebnissen führen würde. Mehr zu der Einschätzung der Folgen aber in einem späteren Abschnitt.
Lösung: Page Cache Method Disk: Basic
Sollte euch das Problem bekannt sein und ihr nutzt das w3total Cache Plugin zum Caching eurer WordPress-Seite, habe ich die entsprechende Lösung gefunden:
- Navigiere zu General-Settings unter dem Menüpunkt Performance im WordPress-Backend.
- Du befindest dich damit in den Einstellungen von w3total Cache.
- In der Sektion Page Cache (die zweite Sektion von oben) findet sich das Dropdown Page Cache Method.
- Wähle in dem Dropdown die Option Disk: Basic aus.
- Speichere die Einstellungen.
- Leere den Page Cache über den Einstellungen, sowie das Plugin es empfiehlt.
Dadurch wird klar, dass das Problem in der Nutzung der Page Cache Method Disk: Enhanced liegt. Bei der Auswahl dieses empfohlenen Modus tritt der Fehler auf. Im Modus Disk: Basic tritt der Fehler nicht auf.
Begründung von w3total Cache der Problematik
Den Tipp mit Cache Mode habe ich aus einem WordPress-Forum erhalten. Allerdings ist seitdem in keinem Plugin-Release eine Anpassung bezüglich es Fehlers vorgenommen worden. Entsprechend wollte ich mal schauen, ob der Plugin-Entwickler auf Support-Anfragen bedient. Ich garantiere, dass ich das Problem sachlich geschildert habe! Ich habe sogar darauf hingewiesen, dass ich kein Paying User bin, aber schon etwas angesäuert wäre, wenn ich für ein Plugin mit diesem Fehler bezahlen würde.
Die Antwort von w3total Cache kam sehr schnell und hat mich folgendes gelehrt:
- Es handelt sich nicht um einen Bug
- Es ist lediglich eine Freiheit in der Plugin-Entwicklung, die nicht eingeschränkt wurde (Trailing Slash oder nicht)
- Durch eine Spezifizierung könnte es dazu kommen, dass andere Plugins nicht funktionieren
- Eine Konfiguration auf Server-Seite wäre kritisch, da Logik zwischen Nicht-Slash und Slash nicht abgebildet werden kann.
Das genau Statement ist hier nachzulesen:
The reason this happens is that page enhanced rules work with and without trailing slash. We don’t know if the user wants the trailing slash or not. Also adding a rewrite rule in the Nginx or Apache config, we can’t do that because we don’t know which URLs should be opposite. For example, the contact form 7 plugin doesn’t work with a trailing slash, but we don’t know if the user installed that plugin. Also, we don’t know what plugins work with what rules and we don’t want to have to add a million possibilities for each plugin there is
w3total Cache Support
Es ist für mich zwar ärgerlich, dass das Problem nicht in einem kommenden Release gelöst wird, aber ein Stück weit verständlich. Ich finde es jedoch etwas kritisch, dass es gegen die WordPress-Default-Konfiguration entwickelt wurde.
Einschätzung der Auswirkungen auf die SEO-Performance
Aus meiner Sicht ist die Auswirkung des Verhaltens nicht gravierend, aber auch nicht zu vernachlässigen. Zum einen habe ich schnell gesehen, dass das Canonical-Tag auf den Versionen ohne Trailing-Slash auch korrekt mit Trailing-Slash belegt war. D.h. dass Google sogar das richtige Signal für die originäre URL erhalten hat, wenn es durch Zufall auf eine Version ohne Slash am Ende gestoßen wäre.
Des Weiteren waren die internen Links so weit alle richtig mit einem Slash gesetzt und auch die Sitemap war korrekt, sodass ein normaler Crawl die Seiten nicht von selbst hätte finden können.
However: Sollten die Seiten ohne Slash in den Umlauf kommen, wäre dies in gewissen Fällen schon etwas ärgerlich. Zum einen würden Sie viele Seiten-basierte Auswertungen in Google Analytics zusätzlich erschweren (/amp/-Ordner machen das schon zu Genüge). Ähnlich sind die Auswirkungen auf die Tracking-Implementierung zu interpretieren. Hätte ich komplexe Firing-Rules für Tags im Tagmanager hinterlegt (z.B. mit Regex o.ä.), könnte ich auch nicht sicher sein, dass alle Tracking-Pixel auf den korrekten Unterseiten auslösen.
Eine Problematik, die die Diagnose des Fehlers deutlich erschwert und verzögert hat, ist die Deaktivierung des Cachings für eingeloggte User. So habe ich die Redirects der Seite anscheinend immer nur dann überprüft während ich gerade im WordPress Backend eingeloggt war. Entsprechend habe ich nie die gecachte Version zu sehen bekommen.
