Htaccess einfach und verständlich erklärt – SEO Bedeutung

Eine .htaccess ist eine Konfigurationsdatei für den Apache-Webserver, die verzeichnisbezogene Einstellungen ermöglicht, ohne dass man Zugriff auf die zentrale Serverkonfiguration braucht. Der Name steht für hypertext access, das führende Pünktchen kennzeichnet sie unter Unix als versteckte Datei. Über die .htaccess steuert man vor allem Weiterleitungen, Zugriffsschutz, URL-Umschreibungen und Caching. Besonders im Shared-Hosting ist sie ein flexibles Werkzeug, weil man dort meist keinen Zugriff auf die Hauptkonfiguration des Servers hat.

Die .htaccess liegt normalerweise im Hauptverzeichnis, dem Root-Verzeichnis, der Website. Bei WordPress befindet sie sich auf derselben Ebene wie die wp-config.php. Sie kann zusätzlich in einzelnen Unterverzeichnissen abgelegt werden, um dort speziellere Regeln zu setzen, die für dieses Verzeichnis und seine Unterverzeichnisse gelten. Da der Dateiname mit einem Punkt beginnt, ist die Datei standardmäßig versteckt; im FTP-Programm muss man eventuell das Anzeigen versteckter Dateien aktivieren.

Nein. Die .htaccess ist Apache-spezifisch. Der ebenfalls Apache-kompatible LiteSpeed-Server liest sie ebenfalls, der heute am weitesten verbreitete Nginx-Server dagegen nicht. Bei Nginx werden alle Regeln direkt in den Server-Konfigurationsblöcken hinterlegt. Wer von Apache auf Nginx umzieht, muss seine .htaccess-Regeln also in die Nginx-Konfiguration übersetzen. Bei Apache-Hosting unterstützen fast alle Anbieter die .htaccess, der Funktionsumfang kann aber durch den Provider eingeschränkt sein.

Apache prüft bei jedem einzelnen Seitenaufruf vom angeforderten Dokument aus alle übergeordneten Verzeichnisse darauf, ob eine .htaccess vorhanden ist, und wendet die gefundenen Regeln an. Diese dezentrale Prüfung ist sehr flexibel, kostet aber bei jeder Anfrage etwas Rechenleistung. Wer Zugriff auf die zentrale Serverkonfiguration hat, kann die Regeln dort hinterlegen und die Auswertung von .htaccess-Dateien per AllowOverride None abschalten, was schneller ist. Die .htaccess ist vor allem dann die richtige Wahl, wenn dieser Zugriff fehlt.

Die wichtigsten sind die 301-Weiterleitung für einen dauerhaften Umzug und die 302-Weiterleitung für einen vorübergehenden. Bei einer 301 übertragen Suchmaschinen die Signale der alten auf die neue URL, ohne dass ein nennenswerter Verlust an Linkkraft entsteht; sie ist die richtige Wahl für dauerhafte Umzüge und für die Vereinheitlichung von Adressen, etwa beim Erzwingen von HTTPS oder beim Entfernen des www. Eine 302 lässt die ursprüngliche Adresse im Index und eignet sich nur für vorübergehende Umleitungen.

Ja. Die .htaccess reagiert sehr empfindlich auf Fehler. Schon ein einziger Tippfehler oder eine falsche Syntax kann die gesamte Website mit einem Server Error 500 unzugänglich machen. Deshalb sollte man vor jeder Änderung ein Backup der Datei anlegen, Änderungen schrittweise vornehmen und danach testen. Wenn nach einer Änderung ein 500-Fehler auftritt, stellt man einfach die gesicherte Version wieder her und sucht den Fehler in kleineren Schritten.

Im aktuellen Apache 2.4 werden Zugriffsregeln mit der Require-Anweisung gesetzt, etwa Require all granted, Require all denied oder Require not ip gefolgt von einer Adresse. Die ältere Syntax mit order, allow und deny stammt aus Apache 2.2 und gilt als veraltet, funktioniert auf vielen Servern aber nur noch über ein Kompatibilitätsmodul. Für neue Konfigurationen sollte man daher die moderne Require-Syntax verwenden, die klarer und zukunftssicher ist.

WordPress legt beim Aktivieren der Permalinks automatisch eine .htaccess an. Ihr Rewrite-Block schreibt die kryptischen Standard-Adressen in lesbare, sprechende URLs um. Dieser Bereich ist klar mit den Markierungen BEGIN WordPress und END WordPress gekennzeichnet und wird von WordPress bei Bedarf neu geschrieben. Eigene Regeln sollte man deshalb außerhalb dieser Markierungen eintragen, damit sie beim nächsten Neuschreiben des WordPress-Blocks nicht verloren gehen.

Ja. Mit dem Modul mod_deflate lassen sich Textdateien wie HTML, CSS und JavaScript per Gzip komprimieren, und mit mod_expires steuert man über Expires-Header, wie lange Browser Dateien zwischenspeichern. Beides verkürzt Ladezeiten und entlastet den Server. Voraussetzung ist, dass die entsprechenden Module auf dem Server aktiviert sind. Bereits komprimierte Formate wie Bilder oder moderne Webfonts sollte man nicht zusätzlich per Gzip komprimieren, da das keinen Nutzen bringt.

Über das Modul mod_headers lassen sich sinnvolle Sicherheits-Header setzen, etwa Strict-Transport-Security zum Erzwingen von HTTPS, X-Content-Type-Options mit dem Wert nosniff, eine Referrer-Policy und eine Content-Security-Policy. Der früher verbreitete Header X-XSS-Protection gilt heute als veraltet und wird von modernen Browsern ignoriert; an seine Stelle tritt eine Content-Security-Policy. Diese sollte vor dem Scharfschalten getestet werden, damit sie keine legitimen Ressourcen blockiert.

Nicht zwingend. WordPress erstellt zwar automatisch eine .htaccess für sprechende URLs, viele Aufgaben lassen sich aber ebenso in der zentralen Serverkonfiguration lösen. Wer Zugriff darauf hat, ist mit der Hauptkonfiguration oft besser bedient, weil sie schneller ausgewertet wird. Auf einem Nginx-Server gibt es ohnehin keine .htaccess. Wo man jedoch keinen Zugriff auf die Serverkonfiguration hat, wie bei vielen günstigen Hosting-Paketen, ist die .htaccess ein sehr praktisches und mächtiges Werkzeug.

Für einen Passwortschutz kombiniert man eine .htaccess mit einer .htpasswd-Datei. In der .htaccess legt man mit AuthType Basic, einem AuthName als Bezeichnung des geschützten Bereichs, dem Pfad zur .htpasswd über AuthUserFile und der Anweisung Require valid-user fest, dass nur angemeldete Nutzer Zugriff erhalten. Die .htpasswd enthält die Benutzernamen und die verschlüsselten Passwörter und sollte außerhalb des öffentlich erreichbaren Verzeichnisses liegen. Der Pfad muss exakt stimmen, sonst funktioniert der Schutz nicht.