In meiner Arbeit als SEO-Manager sind Umleitungen per Redirect-Befehl in einer .htaccess-Datei unverzichtbar. Aus der Praxis hat sich dabei ein größerer Wissensschatz gebildet, der über typische Herausforderungen hinaus Lösungen für häufige Problemstellungen bietet. Natürlich alles auf eigene Gefahr!
In diesem Beitrag möchte ich daher über Lösungen für untypische Probleme sprechen und wie man diese per .htaccess auf einem Apache-Server umsetzen kann. Als Grundlage für meine Lösungen diente immer ein Ubuntu-System. Die Fallbeispiele lassen sich vermutlich auch auf andere Distributionen in Verbindung mit dem Apache-Server übertragen. Ich freue mich diesbezüglich über Hinweise und Vorschläge für Korrekturen. Die dargestellten Lösungen bieten vermutlich auch einen Hinweis, wie man per NGINX gleiche Herausforderungen lösen könnte.
Einführung mit einem Klassiker: Umleitung per Redirect auf https-Version einer Website
Der Klassiker muss aufgelistet werden. Es ist noch immer die häufigste Frage in Foren und auf Google zum Thema Redirect und Redirects. Das Beispiel hilft auch als Einführung in das Verständnis der Thematik. Also: Wie leitet man eine komplette Domain und Unterseiten auf die verschlüsselte Versionen mit https um? Folgender Fünfzeiler reicht bereits in den meisten Fällen:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>
Erläuterungen: Am Anfang und Ende stehen die Einschränkungen für das Ausführen dieser Umleitung drin. Das ist ein Standard, den ich sehr empfehle. Das heißt, die zwischen „IfModule“ angegebenen Befehle werden nur dann umgesetzt, wenn der Apache-Server auch wirklich Umleitungen unterstützt. Dies ist immer dann der Fall, wenn das Modul „mod_rewrite“ aktiv ist. Wenn das Modul nicht aktiv ist, wird die Umleitung auch nicht ausgeführt.
Der Befehl „RewriteEngine On“ sollte immer nach der Einschränkung kommen. Damit wird die Umleitung überhaupt ermöglicht und „scharf geschaltet“.
Eine sog. Condition stellt in einer htaccess Datei immer eine Ausnahme dar. In diesem Fall benötigen wir eine Ausnahme. Wenn nämlich bereits die https Version einer Website ausgespielt wird, dann darf nicht noch einmal umgeleitet werden. Die Logik dahinter ist einfach: Dies würde sonst zu einer unendlichen Umleitungsschleife führen. Die Angabe „nicht“ ist hier mit „!=“ angegeben.
Die RewriteRule gibt die Umleitungsregel an. Das Hochzeichen „^“ bildet dabei eine Anweisung, dass die Regel für alle Links gelten soll. (Hier ist auch die Reihenfolge wichtig. Würde die Condition unter der Rule stehen, würde es nicht funktionieren und in einer Dauerschleife enden.) Wir stellen vor den Host und der angeforderten URL ein https:// vor. Außerdem leiten wir alle URLS per Redirect 301 um. Das ist wichtig, weil die 301-Umleitung bedeutet, dass die Links immer umgeleitet werden. Das gibt auch dem Google-Bot den Hinweis: Der neue Link bleibt, du kannst den alten Link ignorieren. Das vorangestellte L in der eckigen Klammer stellt einen sog. RewriteRule Flag dar. Diese Auszeichnung dient als Hinweis, dass diese Regel als „Last“ ausgeführt werden. Das heißt, der Server stoppt nach der Ausführung dieser Regel und führt keine weiteren Umleitungsregeln aus. In diesem Kontext ist das wichtig.
Umleitung per .htaccess auf https und www-Version einer Website
Um das Verständnis unseres Einstiegsbeispiels zu vertiefen, erweitern wir die Aufgabe um ein ebenfalls in hoher Zahl auftretendes Beispiel. Wie muss die .htaccess gestaltet werden, wenn die Website immer auf die www-Version und auf die Verschlüsselung per https verweisen soll? Die Antwort sieht so aus:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.domainname.de%{REQUEST_URI} [L,NE,R=301]
</IfModule>Was ist passiert? Nun, wir haben eine weitere Bedingung hinzugefügt. Damit beide Bedingungen geprüft werden, haben wir die Flag [OR] genutzt. Diese beudetet, dass entweder die Bedingung https ist an oder die Bedingung www. steht bereits im Host-Namen nicht erfüllt sein dürfen. Das Flag [NC] bedeutet, dass nicht auf Groß- oder Kleinschreibung bei der Suche nach www im Host-Namen geachtet werden soll.
In dem Beispiel wird dann die Regel so ausgespielt, dass der Domainname vorangestellt wird mit www. und https.
Das Flag [NE] hindert in diesem Fall eine Änderung von Sonderzeichen zu Äquivalenten in Hexa-Code. Das ist wichtig, wenn beispielsweise an den URI weitere Zeichen angehängt sind und verarbeitet werden müssen. Man könnte auch darauf verzichten, ich rate aber häufig davon ab, um eine gewisse Konsistenz in der Umleitung zu haben und immer die alten Links wirklich bei der Umleitung zu berücksichtigen.
In der Praxis kann man das Ergebnis dieser Einträge sehr gut auch auf meinem Blog sehen. Hier ist etwa der Link ohne https und www zu einem Beitrag:
http://akifsahin.de/2022/08/17/seo-selbstreferentielle-canonical-tags-bleiben-wichtig/
Der Klick auf den Link führt zur www-Version mit https-Verschlüsselung.
Eine kleine Anmerkung am Rande. Auf vielen Seiten finden sich auch ähnliche Lösungen mit Angaben wie *. +. oder (*.) oder ^(*.)$. Im Grunde haben alle diese Zeichen teilweise identische oder überschneidende Effekte. Ich habe die einfachere Lösung aus meiner Sicht genommen. Wichtig ist, dass man bei einer Lösung bleibt, wenn man sie gefunden hat.
Nicht immer eine Einstellung in .htaccess notwendig
Außerdem ist wichtig, dass bei einigen Hostern und Server-Anbietern auch bestimmte Einstellungen dieser Art nicht per .htaccess vorgenommen werden, sondern über Einstellungen im Backend für die Domain. Das kann sowohl die Verschlüsselung und Umleitung per .htaccess betreffen als auch die Umleitung auf die www-Version. Beispielsweise ist beim Anbieter Hetzner teilweise das Umleiten auf die verschlüsselte Version nur über die Server-Einstellungen möglich. Einträge in der .htaccess werden dabei ignoriert. Bei all-inkl.com kann man hingegen im KAS bei der Einrichtung des SSL-Schutzes einstellen, dass eine Seite immer die verschlüsselte Seite aufrufen soll. Auch eine ständige Umleitung auf die www-Version ist möglich. Ich rate daher dazu, sich die Dokumentation oder die Hilfe des eigenen Providers genau anzuschauen. Das vermeidet unnötige Kopfschmerzen.
Klassiker: Die Umleitung per Redirect 301
Eine alte URL ist nicht mehr gültig und sie möchten auf die neue URL weiterleiten? Die Lösung heißt: Redirect 301. Diese ist auch wichtig für die Suchmaschinenoptimierung, weil die Rückmeldung 301 erklärt, dass der ursprüngliche Link endgültig veraltet ist. Ein Beispiel:
Redirect 301 /seo-fett/ https://www.neue-domain.de/2021/11/15/seo-fett/Der Befehl kann für sich alleine stehen. Sollte aber immer zwischen den oben aufgeführten <ifModule> Befehlen stehen. Er sollte immer in der Reihenfolge ganz am Ende stehen, wenn man mich fragt. Die 301 ist bereits erklärt worden. Doch der Aufbau ist jetzt wichtig. Die alte URL wird ohne https, www und domain-Namen angegeben. Es ist wie ein Pfad oder auch als einzelne URL völlig okay. dann folgt ein weiteres Leerzeichen und hier wird der neue Link angegeben.
Ein äquivalentes Beispiel mit html-Endung der Links könnte so aussehen:
Redirect 301 /seite1.html https://www.domainname.de/seite2.html
Ziemlich einfach, oder? Doch was ist, wenn eine komplette Domain auf eine neue Domain umleiten soll? Das ist eine häufige Frage bei Relaunch oder einem Umzug auf eine neue Domain. Die Lösung könnte so aussehen und sollte wieder ganz nach oben gestellt werden:
RewriteEngine On
RewriteCond %{REQUEST_URI} (.*)
RewriteRule ^(.*)$ https://www.neue-domain.de/$1 [L,R=301]Da sind wir auch mal bei einem Beispiel mit (.*) und ^(.*)$. In diesem Fall ergibt es tatsächlich Sinn, diese Angaben zu nutzen. Sie stammen aus dem Bereich der sog. Regular Expressions und würden in diesem Fallbeispiel alle Formen von URLs betreffen, die auf die alte Domain führen. Hier ist wichtig, dass die Einschränkung der angeforderten URL auch vorhanden ist. Die Regel leitet dann alle Anfragen auf die neue Domain mit https und www. um. Die Endung $1 fügt den ursprünglichen Link an die neue Domain an.
Umlaute und Sonderzeichen in URLs ändern und per Redirect umleiten
Es gibt CMS-Systeme, wie Contao, die erlauben tatsächlich ein breites Spektrum an Sonderzeichen. Unter anderem ist es möglich bei Contao nicht nur Groß- und Kleinschreibung in URLs zu nutzen, sondern auch Umlaute wie Ä, Ö und Ü. Das ist aus meiner Sicht keine gute Idee. Wenn man das schon immer so gemacht hat, kann man diesen Part meiner Anleitung überspringen. Aber Umlaute in Domainnamen werden bis heute von Google und Co. anders gelesen, als der menschliche Nutzer diese eintippt. Außerdem sind Umlaute in URLs gerade für bestimmte Nutzer aus anderen Regionen nicht nutzbar.
Aus SEO-Perspektive stellt sich aber ein anderer Grund häufiger in den Vordergrund. Es kann sein, dass Google unter bestimmten Voraussetzungen URLs indiziert, die fälschlicherweise mit Umlauten angegeben wurden. Ein häufig auftretendes Problem im Zusammenhang mit doppelten Links zu gleichen Seiten. Beispielsweise führten bei einem früheren Projekte die URL-Endungen „baden-wuerttemberg“ und „baden-württemberg“ auf die gleiche Seite. Google hatte beide Seiten mit seinem Crawler indexiert und wir hatten den Duplicate-Content-Salat. In solchen Fällen hilft es, schnell einen Redirect per 301 auf die Hauptseite einzurichten. Ein Canonical-Tag braucht in solchen Fällen etwas länger.
Wir müssen hier auch einen Fundus aus verschiedenen Codes für die Umlaute berücksichtigen. Mein Beispiel für diesen speziellen Fall sieht so aus:
RewriteRule ^(.*)(ä|Ä|ä|Ä)(.*) /$1ae$3 [L,R=301]
RewriteRule ^(.*)(ö|Ö|ö|Ö)(.*) /$1oe$3 [L,R=301]
RewriteRule ^(.*)(ü|ý|ü|Ü)(.*) /$1ue$3 [L,R=301]Das ist eines der schönsten Code-Stücke, an denen ich während meiner Arbeit je gebastelt habe. Die Regeln sind für die verschiedenen Schreibweisen und Codierungen der Umlaute Ä, Ö und Ü ausgelegt. Es werden dabei Sonderschreibweisen und Kleinschreibung beachtet. Die Angabe erfolgt in geschweiften Klammern und jede Schreibweise wird mit einem senkrechten Strich (Pipe) getrennt aufgeführt. Die Umschreibung erfolgt mit den Angaben zwischen den $-Zeichen. Aus Ä und ä wird ae und so weiter. Der neue Link wird mit 301 gekennzeichnet. Und dieser Code wurde dann immer wichtiger für andere Herausforderungen.
Sonderzeichen ß umleiten auf ss per Redirect
RewriteRule ^(.*)(ß|ß)(.*) /$1ss$3 [L,R=301]Leerzeichen per Redirect umleiten und ersetzen
Eine echt interessante Herausforderung wurde es, Leerzeichen per htaccess umzuleiten. Es gibt tatsächlich Möglichkeiten, Links mit Leerzeichen zu erstellen. Das ist nicht nur unschön, sondern ein Verbrechen an Linkgestaltung. Ich hatte damit sehr viel SEO-Ärger. Also habe ich nach einer Alternative gesucht. Meine Lösung sieht so aus:
RewriteRule ^(.*)(\s)(.*) /$1-$3 [L,R=301]Ich habe mit diesem Code echt gerungen, denn Anleitungen zu diesem Thema gibt es kaum. Ein Leerzeichen wird von Google und Co. immer codiert gelesen. Für ein Leerzeichen würde in diesem Fall bei einer URL %20 eingesetzt werden. Doch dies kann man in einer .htaccess Datei so nicht schreiben, weil das %-Zeichen immer reserviert ist. Entsprechend muss getrickst werden und es gibt in diesem Fall die Sonderauszeichnung \s. Unsere Regel ändert das Leerzeichen zu einem Bindestrich (was ich übrigens charmanter finde als einen Unterstrich).
Geschweifte Klammern per htaccess umleiten
Auch hier hat es etwas länger gedauert, aber am Ende war es ziemlich einfach und der Code kann im Grunde für verschiedenste Zeichen genutzt werden.
RewriteRule ^(.*)(\()(.*) /$1$3 [L,R=301]
RewriteRule ^(.*)(\))(.*) /$1$3 [L,R=301]In diesem Fall wird die „(“ und „)“ komplett entfernt aus der URL. Entsprechend steht zwischen $1 und $3 kein Zeichen. Damit wird dieses Sonderzeichen aus der URL entfernt.
Vorläufig so viel zum Thema Redirect und .htaccess
Das sind jetzt einige Beispiele gewesen, die ich hier notieren wollte, weil dazu nur selten und sehr schwierig etwas zu finden ist. Ich werde diesen Beitrag in Zukunft um weitere Beispiele und Lösungen ergänzen. Ich freue mich, wie zuvor erwähnt, über Anmerkungen und Anregungen – gerne auch als Kommentar.
Redirect per .htaccess: Lösungen für (un)typische Probleme