Die .htaccess-Datei: Was du als SEO wissen musst

Aktualisiert im Oktober 2026. Dieser Beitrag erschien ursprünglich 2012 und wurde für den heutigen Stand komplett neu geschrieben: mit Apache-2.4-Syntax, aktuellen Praxisbeispielen für Weiterleitungen und X-Robots-Tag sowie einem Hinweis zu NGINX.

Wer Weiterleitungen einrichtet, eine Domain umzieht oder HTTPS erzwingt, landet früher oder später bei der .htaccess. Die kleine Datei kann viel, und ein einziger Tippfehler legt die ganze Website mit einem Serverfehler lahm. Hier steht, was die Datei eigentlich ist, welche Regeln für SEO wirklich zählen und wo die typischen Fallen liegen.

Was die .htaccess ist und wo sie gilt

Die .htaccess ist eine Konfigurationsdatei des Apache-Webservers, die du in ein Verzeichnis legst. Ihre Anweisungen gelten für dieses Verzeichnis und alle Unterverzeichnisse. Der Clou: Apache liest sie bei jeder Anfrage neu. Änderungen wirken also sofort, ohne Neustart des Servers und ohne Zugriff auf die zentrale Konfiguration. Genau deshalb ist sie bei Shared Hosting so verbreitet.

Wichtig zu wissen:

• Nicht jeder Server liest sie. Viele Websites laufen heute auf NGINX. NGINX kennt keine .htaccess; Regeln in dieser Datei werden dort einfach ignoriert. Microsoft IIS arbeitet mit einer web.config. LiteSpeed dagegen versteht die meisten Apache-Regeln aus der .htaccess. Frag im Zweifel deinen Hoster, welcher Server läuft.
• Der Server muss sie erlauben. Ob und welche Anweisungen in einer .htaccess wirken, legt die Hauptkonfiguration mit AllowOverride fest. Seit Apache 2.4 steht das standardmäßig auf None; bei Hostern ist es aber fast immer freigeschaltet.
• Nicht erlaubte oder fehlerhafte Anweisungen führen zu einem 500-Fehler. Den genauen Grund findest du im Error-Log, etwa „Invalid command“ oder „not allowed here“.
• Sie kostet etwas Leistung. Weil Apache bei jeder Anfrage in allen übergeordneten Verzeichnissen nach .htaccess-Dateien sucht, empfiehlt die Apache-Dokumentation, Regeln lieber in die Serverkonfiguration zu schreiben, wenn du Zugriff darauf hast.

mod_rewrite in fünf Minuten

Wenn SEOs „in der htaccess“ sagen, meinen sie meistens mod_rewrite, das Apache-Modul zum Umschreiben und Weiterleiten von URLs. Die Grundbausteine:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

• RewriteEngine On schaltet das Modul ein.
• RewriteCond ist eine Bedingung. Mehrere Bedingungen gelten als UND, mit [OR] als ODER.
• RewriteRule Muster Ziel [Flags] prüft den URL-Pfad gegen einen regulären Ausdruck und schreibt ihn um.
• In der .htaccess sieht das Muster den Pfad ohne führenden Schrägstrich und relativ zum Verzeichnis der Datei. ^blog/ passt, ^/blog/ nicht.
• Teile in runden Klammern kannst du im Ziel mit $1, $2 usw. wiederverwenden. Treffer aus einer RewriteCond heißen %1, %2.

Die wichtigsten Flags:

Flag	Wirkung
L	letzte Regel in diesem Durchlauf
R=301	externe Weiterleitung mit Statuscode 301
NC	Groß-/Kleinschreibung ignorieren
QSA	vorhandenen Query-String an das Ziel anhängen
QSD	Query-String verwerfen (Apache 2.4)
F	Zugriff verweigern (403)
G	Seite dauerhaft entfernt (410)

Rewrite oder Weiterleitung?

Das ist der Punkt, an dem die meisten Missverständnisse entstehen:

• Interner Rewrite: RewriteRule ^produkte/(.*)$ shop.php?item=$1 [L] liefert den Inhalt von shop.php aus, die Adresse im Browser bleibt aber /produkte/…. Der Server antwortet mit 200. So erzeugen CMS ihre „sprechenden“ URLs.
• Weiterleitung: Mit dem Flag R schickt der Server einen 3xx-Statuscode und die neue Adresse. Browser und Crawler rufen dann die neue URL ab.

Steht im Ziel eine vollständige URL mit anderem Host, leitet Apache auch ohne R weiter, und zwar mit 302. Gib für dauerhafte Umzüge deshalb immer ausdrücklich R=301 an.

Praxisbeispiele für SEOs

HTTPS und eine Hostvariante erzwingen

Eine Website sollte unter genau einer Adresse erreichbar sein. Diese Regel leitet HTTP und die Variante ohne www in einem Schritt auf https://www. um:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]

Läuft die Website hinter einem Load Balancer oder CDN, das die TLS-Verbindung beendet, meldet %{HTTPS} womöglich immer off. Dann entsteht eine Weiterleitungsschleife. In dem Fall prüfst du stattdessen den Header, den der Proxy mitschickt (häufig X-Forwarded-Proto), oder erledigst die Umleitung direkt im CDN.

Einzelne Seiten weiterleiten

Für einfache 1:1-Weiterleitungen reicht mod_alias, das ist übersichtlicher als mod_rewrite:

Redirect 301 /alter-artikel.html https://www.example.com/neuer-artikel/
RedirectMatch 301 ^/news/(.*)$ https://www.example.com/blog/$1

Mische für dieselben URLs aber nicht Redirect und RewriteRule. Die Module arbeiten unabhängig voneinander, und die Reihenfolge ist nicht immer die, die man erwartet. Bei vielen Regeln bleibst du am besten bei einem der beiden.

Alte URLs mit Parametern umziehen

RewriteRule sieht nur den Pfad, nicht den Query-String hinter dem Fragezeichen. Parameter prüfst du deshalb in einer Bedingung und greifst mit %1 auf den Treffer zu:

RewriteCond %{QUERY_STRING} (?:^|&)id=([0-9]+)(?:&|$)
RewriteRule ^artikel\.php$ /artikel/%1/ [R=301,L,QSD]

Aus /artikel.php?id=42&ref=newsletter wird /artikel/42/. Das Flag QSD verhindert, dass Apache den alten Query-String an das Ziel anhängt. Ohne es würde ?id=42&ref=newsletter mitwandern, im schlimmsten Fall in einer Endlosschleife. Vor Apache 2.4 hat man dafür ein ? ans Ende des Ziels gesetzt.

X-Robots-Tag für PDFs und andere Dateien

PDFs haben keinen <head> für ein Meta-Tag. Mit mod_headers setzt du noindex als HTTP-Header:

<FilesMatch "\.pdf$">
  Header set X-Robots-Tag "noindex"
</FilesMatch>

Was noindex genau bewirkt, steht in noindex, follow. Sperre solche Dateien nicht zusätzlich per robots.txt, sonst sieht Google den Header nie, siehe noindex, Disallow oder beides?.

Eigene robots.txt pro Host

Teilen sich mehrere Domains oder Subdomains ein Verzeichnis, liefert diese Regel jedem Host seine eigene Datei aus:

RewriteRule ^robots\.txt$ /robots/%{HTTP_HOST}.txt [L]

Im Ordner /robots/ liegen dann www.example.com.txt, shop.example.com.txt usw. Was in die robots.txt gehört, steht in robots.txt: Was du als SEO heute wissen musst.

Dateien und Bereiche schützen

Konfigurations- oder Logdateien haben im Web nichts verloren:

<FilesMatch "\.(ini|conf|log|sql)$">
  Require all denied
</FilesMatch>

Require all denied ist die Apache-2.4-Syntax. Die alte Form Order deny,allow / Deny from all funktioniert nur noch mit einem Kompatibilitätsmodul.

Ein Staging-System schützt du am besten mit einem Passwort (HTTP 401). Das hält Crawler zuverlässiger fern als jede robots.txt:

AuthType Basic
AuthName "Staging"
AuthUserFile /pfad/ausserhalb/des/webroots/.htpasswd
Require valid-user

Unerwünschte Bots aussperren

Aggressive Crawler, die deinen Server belasten, kannst du über den User-Agent abweisen:

RewriteCond %{HTTP_USER_AGENT} (BeispielBot|NochEinBot) [NC]
RewriteRule ^ - [F]

Zwei Einschränkungen: Den User-Agent kann jeder fälschen, wirklich böswillige Bots erwischst du so kaum. Und sperre auf diesem Weg nie versehentlich Googlebot oder Bingbot aus. Für seriöse Crawler, auch KI-Crawler, ist die robots.txt der richtige Ort.

Caching und Kompression

Für die Ladezeit lohnen sich Browser-Caching und Textkompression, sofern dein Hoster das nicht ohnehin erledigt:

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType text/javascript "access plus 1 month"
</IfModule>

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript application/json image/svg+xml
</IfModule>

Lange Cache-Zeiten funktionieren nur, wenn sich bei Änderungen der Dateiname ändert (etwa style.3f2a.css). Viele Caching-Plugins und Build-Tools erledigen das automatisch. Das <IfModule> sorgt dafür, dass die Website nicht ausfällt, wenn ein Modul fehlt.

Eigene Fehlerseite

ErrorDocument 404 /404.html

Gib hier einen lokalen Pfad an. Mit einer vollständigen URL (https://…) leitet Apache auf die Fehlerseite weiter, und der Statuscode 404 geht verloren. Das Ergebnis wären „Soft 404“-Fehler. Wie eine gute 404-Seite aussieht, steht in 404-Fehlerseite: alles zum Statuscode. Wer eine Fehlerseite als Skript nutzt, um alte URLs dynamisch weiterzuleiten, muss im Skript selbst den richtigen Statuscode senden: 301 bei Treffer, sonst 404.

Stolperfallen

1. WordPress-Block überschrieben. WordPress pflegt den Bereich zwischen # BEGIN WordPress und # END WordPress selbst. Eigene Regeln gehören darüber, sonst überschreibt WordPress sie beim nächsten Speichern der Permalinks, oder die Catch-all-Regel von WordPress greift vorher.
2. MultiViews. Ist die Apache-Option MultiViews aktiv, ergänzt der Server fehlende Dateiendungen selbstständig. Aus /lib/… wird dann womöglich /lib.css/…, bevor deine Rewrite-Regel überhaupt greift. Wenn Weiterleitungen rätselhafte 404 erzeugen, hilft oft Options -MultiViews.
3. Ketten und Schleifen. Jede Regel einzeln ist korrekt, zusammen leiten sie über drei Stationen weiter oder im Kreis. Teste nach jeder Änderung mit curl -I oder einem Crawler.
4. Punkt nicht maskiert. In regulären Ausdrücken steht . für ein beliebiges Zeichen. ^index.php$ passt auch auf indexXphp. Richtig ist ^index\.php$.
5. 302 statt 301. Siehe oben: Ohne R=301 wird aus einer Domain-Weiterleitung schnell eine temporäre.
6. Keine Fehlersuche in der .htaccess. Das frühere RewriteLog gibt es seit Apache 2.4 nicht mehr. Ausführliches Logging aktivierst du mit LogLevel alert rewrite:trace3, und das nur in der Serverkonfiguration. Komplexe Regelwerke testest du deshalb am besten auf einer lokalen oder Staging-Installation, bei der du volle Rechte hast.

Und bei NGINX?

Auf NGINX stehen die Regeln in der Serverkonfiguration, meist in einem server-Block. Änderungen werden erst nach einem Reload aktiv. Das Gegenstück zur HTTPS- und www-Weiterleitung sieht so aus:

# HTTP (beide Hostvarianten) auf https://www.
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

# HTTPS ohne www auf https://www.
server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate ... (Zertifikat wie im Haupt-Block)
    return 301 https://www.example.com$request_uri;
}

# im server-Block von www.example.com: einzelne Weiterleitung
location = /alter-artikel.html {
    return 301 https://www.example.com/neuer-artikel/;
}

Bei Managed Hosting hast du darauf oft keinen direkten Zugriff. Dann richtest du Weiterleitungen über das Hosting-Panel, ein CMS-Plugin oder das CDN ein. Das Prinzip bleibt gleich: 301 für dauerhafte Umzüge, eine einzige Hostvariante, keine Ketten.

Fazit: mächtig, aber mit Sorgfalt

Die .htaccess ist für SEOs vor allem ein Werkzeug für Weiterleitungen, Hostvarianten und HTTP-Header. Halte sie kurz, kommentiere jede Regel, teste nach jeder Änderung und sichere vorher die funktionierende Version. Und prüfe zuerst, ob dein Server die Datei überhaupt liest, bevor du dich wunderst, dass nichts passiert.