301-Weiterleitung in .htaccess: fertige Regeln

Eine 301-Weiterleitung ist eine Serverantwort, die Browser und Suchmaschinen-Crawler mitteilt: Die Seite ist dauerhaft umgezogen, hier ist ihre neue Adresse. Von anderen Wegen, einen Besucher weiterzuschicken, unterscheidet sie sich dadurch, dass sie nicht nur die Adresse, sondern auch das gesammelte Linkgewicht in den Index überträgt. Unten stehen fertige Regeln für .htaccess, ihre nginx-Entsprechungen und die Fehler, die einen Umzug Traffic kosten.

Wie es funktioniert

Der Server beantwortet die Anfrage mit Code 301 und dem Header Location, der die neue Adresse enthält. Der Browser folgt sofort, für den Besucher meist unbemerkt, und merkt sich den Sprung. Die Suchmaschine macht dasselbe: Sie ersetzt die alte URL im Index durch die neue und gibt das Linkgewicht weiter.

Browser oder CrawlerGET /old-page/AnfrageServer301 Moved PermanentlyLocation: /new-page/Regel aus .htaccessWeiterleitungNeue Adresse200 OK, Seite geöffnetWas für die Suche zählt301 sagt „die Adresse hat sich dauerhaft geändert“: die Suchmaschine verschiebt die Seite samt Linkgewicht im Index.302 bedeutet vorübergehend — die alte Adresse bleibt im Index, Gewicht wird nicht übertragen.
Die Kette der Anfrage: der Server antwortet mit 301 und nennt die neue Adresse

Der Unterschied zwischen den Codes ist wichtig und kostet Geld:

Code Bedeutung Wann einsetzen
301 Dauerhaft umgezogen Domainwechsel, neue Seitenadresse, Spiegel zusammenführen, Umstieg auf HTTPS
302 Vorübergehend Aktion über zwei Wochen, Wartung, A/B-Test
307 Vorübergehend, Anfragemethode bleibt Dasselbe, aber für POST-Anfragen
308 Dauerhaft, Methode bleibt Seltener Fall: API-Umzug, bei dem POST zählt
410 Endgültig gelöscht Die Seite existiert nicht mehr und hat keinen Ersatz

301 und 302 zu verwechseln ist der teuerste Fehler dieser Liste: Bei 302 behält die Suchmaschine die alte Adresse im Index und überträgt kein Gewicht.

Regeln für .htaccess

Alle Beispiele setzen Apache mit aktivem mod_rewrite voraus. Der Regelblock gehört an den Anfang der .htaccess im Stammverzeichnis — vor die Regeln des CMS, sonst fängt WordPress die Anfrage zuerst ab.

RewriteEngine On
RewriteBase /

Eine Seite auf eine andere

# die einfache Variante
Redirect 301 /old-page/ https://site.com/new-page/

# dasselbe über mod_rewrite, wenn die übrigen Regeln ebenfalls darauf laufen
RewriteRule ^old-page/?$ https://site.com/new-page/ [R=301,L]

Spiegel zusammenführen: von www auf ohne www

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

Der umgekehrte Fall, wenn die Domain mit www der Hauptspiegel ist:

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

Umstieg auf HTTPS

RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Hinter Cloudflare oder einem anderen Proxy greift die Bedingung %{HTTPS} nicht — die Anfrage erreicht den Server bereits über HTTP. Dort prüft man den Header:

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

HTTPS und ohne www in einer Regel

Der entscheidende Kniff dieses Abschnitts: keine zwei Regeln hintereinander, sonst entsteht eine Kette aus zwei Sprüngen.

RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www.(.+)$ [NC]
RewriteRule ^(.*)$ https://site.com/$1 [R=301,L]

Schrägstrich am Ende der Adresse

# Schrägstrich hinzufügen
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !.[a-zA-Z0-9]{1,5}$
RewriteCond %{REQUEST_URI} !/$
RewriteRule ^(.*)$ /$1/ [R=301,L]

# Schrägstrich entfernen
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1 [R=301,L]

Die Bedingungen mit !-f und !-d sind keine Formsache: Ohne sie schreibt die Regel auch Bildadressen und vorhandene Verzeichnisse um.

Umzug auf eine neue Domain

# mit Beibehaltung der Seitenadressen — so gehört es gemacht
RewriteCond %{HTTP_HOST} ^(www.)?old-site.com$ [NC]
RewriteRule ^(.*)$ https://new-site.com/$1 [R=301,L]

# alles auf die Startseite — nur wenn die neue Struktur völlig anders ist
RewriteRule ^(.*)$ https://new-site.com/ [R=301,L]

Die zweite Variante werten Suchmaschinen oft als „soft 404“ und übertragen kein Gewicht. Bilden Sie Adresse auf Adresse ab, wo immer es geht, und schicken Sie nur das auf die Startseite, wofür es keinen Ersatz gibt.

Bereich auf Bereich und Adressen mit Parametern

# /blog/artikel/ → /news/artikel/
RewriteRule ^blog/(.*)$ /news/$1 [R=301,L]

# ?id=12 → /catalog/sofa/
RewriteCond %{QUERY_STRING} (^|&)id=12(&|$)
RewriteRule ^index.php$ /catalog/sofa/? [R=301,L]

Das Fragezeichen am Ende des Ziels verwirft die ursprüngliche Parameterzeile — ohne es hängt sie sich an die neue Adresse.

Dasselbe unter nginx

nginx kennt keine .htaccess: Die Regeln stehen in der Serverkonfiguration und greifen nach nginx -t und einem Reload.

server {
    listen 80;
    server_name www.site.com site.com;
    return 301 https://site.com$request_uri;
}

# eine Seite auf eine andere
location = /old-page/ {
    return 301 https://site.com/new-page/;
}

# Bereich auf Bereich
rewrite ^/blog/(.*)$ /news/$1 permanent;

return 301 ist schneller als rewrite und liest sich eindeutig, deshalb nimmt man für einfache Fälle genau das.

Häufige Fehler

SO LÄUFT ES OFT: VIER SPRÜNGE STATT EINEMhttp://www.site.comhttp://site.comhttps://site.comhttps://site.com/page/Jeder Sprung ist eine eigene Anfrage: längere Ladezeit, Gewichtsverlust, verbrauchtes Crawl-BudgetRICHTIG: EINE REGEL, EIN SPRUNGhttp://www.site.comein 301https://site.com/page/Eine Zeile genügt: curl -sIL https://site.com/page/ — in der Antwort darf genau ein 301 stehen
Eine Kette mehrerer Sprünge und wie es stattdessen aussehen sollte
  • Weiterleitungskette. www → ohne www → https → Schrägstrich: vier Anfragen statt einer. Fassen Sie die Bedingungen in einer Regel zusammen.
  • Schleife. Eine Regel schickt die Seite auf sich selbst, der Browser zeigt ERR_TOO_MANY_REDIRECTS. Meist liegt es an einer HTTPS-Weiterleitung hinter einem Proxy über %{HTTPS}.
  • 302 statt 301. Der Umzug ist erledigt, das Gewicht bleibt auf der alten Adresse.
  • Alles auf die Startseite. Hunderte Seiten pauschal auf die Wurzel zu leiten liest die Suchmaschine als verkappten 404.
  • Regeln hinter dem CMS-Block. In der .htaccess greift WordPress zuerst zu und Ihre Regel läuft nie: Setzen Sie den eigenen Block darüber.
  • Weiterleitung statt Canonical. Werden beide Seiten von Menschen gebraucht und doppelt sich nur der Inhalt, gehört dorthin rel="canonical" und keine 301.
  • Vergessene interne Links. Nach dem Umzug müssen Links im Inneren direkt auf die neue Adresse zeigen, sonst läuft jeder Klick über die Weiterleitung.

Wie man prüft

Am schnellsten geht es im Terminal. -I fragt nur die Header ab, -L folgt der Kette bis zum Ende:

curl -sIL https://site.com/old-page/ | grep -E "HTTP/|Location"

Die richtige Antwort sieht so aus: ein HTTP/1.1 301, ein Location und danach HTTP/2 200. Zwei oder mehr 301 hintereinander sind eine Kette und gehören zusammengelegt. In der Search Console steht dasselbe im Bericht „Seitenindexierung“, im Browser im Tab Network bei aktivem „Preserve log“.

Prüfen Sie nach einem großen Umzug eine Stichprobe von zwei bis drei Dutzend Adressen: Startseite, Kategorien, Produktseiten, Adressen mit Parametern und die Adressen aus den oberen Suchergebnissen.

Das Wichtigste in Kürze

301 für den dauerhaften Umzug, 302 für den vorübergehenden, 410 für das, was es nicht mehr gibt. Geschrieben wird eine Regel, die direkt auf die Zieladresse führt, ohne Zwischenschritte. Und prüfen gehört immer dazu — curl -sIL beantwortet die Frage in einer Sekunde.

Steht ein großer Umzug an — neue Domain, Zusammenlegung von Websites, Wechsel auf HTTPS mit neuer Adressstruktur — schreiben Sie uns: Wir erstellen die Zuordnungskarte und ziehen so um, dass der Traffic bleibt.