301-Weiterleitung: Was sie ist und wie du sie richtig einrichtest

Eine 301-Weiterleitung sagt Browsern und Suchmaschinen: Diese Adresse ist dauerhaft umgezogen. Du brauchst sie, sobald sich eine URL ändert, etwa beim Relaunch, beim Wechsel des Shopsystems, beim Domainwechsel oder wenn du zwei Seiten zusammenlegst. Ohne Weiterleitung landen Besucher auf einer Fehlerseite, und Links auf die alte Adresse helfen der neuen nicht.

Hier erfährst du, was hinter dem Statuscode steckt, wann ein 410 oder ein Canonical besser passt und wie du Weiterleitungen in Apache, nginx, WordPress, Shopify, Shopware und Baukästen einrichtest. Die Beispiele für Apache und nginx sind mit Apache 2.4 und nginx 1.31 getestet. Ich habe solche Weiterleitungen bei mehreren Shop-Umzügen eingerichtet und zeige dir, worauf es in der Praxis ankommt.

Was ist eine 301-Weiterleitung?

Eine 301-Weiterleitung ist eine Antwort des Servers mit dem HTTP-Statuscode 301 „Moved Permanently“. Im Header Location steht die neue Adresse, und der Browser ruft sie sofort selbst auf. Besucher merken meist nur, dass sich die Adresszeile ändert:

GET /alte-seite/ HTTP/1.1
Host: www.beispiel.de

HTTP/1.1 301 Moved Permanently
Location: https://www.beispiel.de/neue-seite/

Die Animation zeigt den Ablauf Schritt für Schritt, von der Anfrage an die alte Adresse bis zur Antwort der neuen Seite:

Google folgt der Weiterleitung und wertet sie als starkes Signal, dass die Zieladresse die kanonische URL werden soll. Mit der Zeit erscheint sie statt der alten in den Suchergebnissen. Links auf die alte Adresse rechnen Suchmaschinen laut MDN der neuen zu.

Laut HTTP-Standard darf eine 301 ohne ausdrückliche Cache-Angaben zwischengespeichert werden. Browser merken sich die Weiterleitung deshalb oft lange. Ein vertipptes Ziel wirkt bei wiederkehrenden Besuchern womöglich nach, obwohl die Regel längst korrigiert ist.

301, 302, 307 und 308 im Vergleich

Die vier Weiterleitungs-Codes unterscheiden sich in zwei Punkten: Ist der Umzug dauerhaft? Und darf der Browser die Anfragemethode ändern, also aus einem abgeschickten Formular (POST) einen normalen Seitenaufruf (GET) machen?

Bei normalen Seitenaufrufen verhalten sich 301 und 308 gleich. Die 308 ist aber jünger und wird laut HTTP-Standard womöglich nicht überall erkannt. Für Seiten, Produkte und Kategorien bleibt die 301 die übliche Wahl.

Meta-Refresh und JavaScript sind keine echte 301

Weiterleitungen per Meta-Refresh oder JavaScript passieren erst im Browser. Der Server liefert die alte Seite mit Status 200 aus, ohne 3xx-Status. Google erkennt solche Weiterleitungen trotzdem: Einen sofortigen Meta-Refresh mit 0 Sekunden wertet Google als dauerhaft, einen verzögerten als vorübergehend.

<meta http-equiv="refresh" content="0; url=https://www.beispiel.de/neue-seite/">

JavaScript-Weiterleitungen sieht Google erst beim Rendern, und das kann scheitern. Google rät deshalb nur dann zu JavaScript, wenn weder Server-Weiterleitung noch Meta-Refresh möglich sind. Wo es geht, ist die serverseitige 301 die bessere Wahl.

Wann eine 301 richtig ist und wann 410 oder Canonical

Eine 301 passt nur, wenn es für die alte Adresse ein gleichwertiges neues Ziel gibt. Diese Übersicht hilft bei der Entscheidung:

Dieser Beitrag ist selbst ein Beispiel: Der frühere Artikel „Was ist eine 301-Weiterleitung?“ steckt jetzt hier drin, seine Adresse leitet per 301 hierher.

410 statt Weiterleitung

Leite gelöschte Seiten nicht pauschal auf die Startseite. Laut Google können viele alte Adressen, die auf ein einziges unpassendes Ziel wie die Startseite zeigen, als Soft 404 behandelt werden. Gibt es keinen passenden Ersatz, antworte mit 404 oder 410. Google behandelt alle 4xx-Codes außer 429 gleich. Der Code 410 „Gone“ sagt aber klarer, dass du die Seite absichtlich entfernt hast.

Canonical statt Weiterleitung

Ein Canonical-Tag ist ein Hinweis im HTML-Code, keine Weiterleitung. Besucher bleiben auf der aufgerufenen Adresse. Das passt, wenn mehrere URLs bewusst erreichbar bleiben, etwa Filteransichten, Adressen mit Tracking-Parametern oder ein Produkt in mehreren Kategoriepfaden. Google wertet Weiterleitung und Canonical beide als starkes Signal, empfiehlt die Weiterleitung aber, wenn du eine doppelte Seite loswerden willst.

Weiterleitungen planen, bevor du sie einrichtest

Eine Regel ist schnell geschrieben, die eigentliche Arbeit steckt in der Liste davor. Sammle alle alten Adressen aus der XML-Sitemap, der Search Console, deinem Analyse-Tool und deinen Backlink-Daten. Ordne dann jeder alten Adresse genau ein Ziel zu, auch Bildern und PDFs. Was bei einem Relaunch sonst zählt, steht im Beitrag zum SEO-Website-Relaunch.

Beim Umbau von seorado.de von WordPress auf eine statische Seite habe ich im September 2026 alle 91 alten Adressen einzeln geprüft. Dazu kamen 180 alte Bildadressen, die per 301 auf die neuen WebP-Dateien zeigen. Reste des alten Seitenbaukastens antworten bewusst mit 410. Geprüft habe ich vor dem Livegang gegen die neue Version. Mehr dazu in der Referenz zu seorado.de.

301-Weiterleitung mit Apache und .htaccess einrichten

Auf vielen Hosting-Paketen läuft Apache. Weiterleitungen stehen dort in der .htaccess im Hauptverzeichnis. Sichere die Datei vor jeder Änderung, denn ein Tippfehler legt die ganze Seite mit einem Serverfehler 500 lahm.

Setz deine Regeln ganz nach oben, vor den Block von WordPress oder deinem Shopsystem. Im Test blieb eine RewriteRule unterhalb des WordPress-Blocks wirkungslos, weil WordPress die Anfrage vorher an index.php übergeben hatte. Oberhalb funktionierte sie sofort. Den Bereich zwischen # BEGIN WordPress und # END WordPress überschreibt WordPress ohnehin selbst.

Redirect oder RewriteRule?

Redirect aus dem Modul mod_alias ist kurz, passt aber auf den Anfang eines Pfads. Alles dahinter hängt Apache ans Ziel an:

Redirect 301 /shop https://www.beispiel.de/produkte

Diese Zeile leitet /shop auf /produkte, aber auch /shop/tasse auf /produkte/tasse. Parameter wie ?farbe=blau wandern mit. Es zählen nur ganze Pfadabschnitte, /shopping bleibt unberührt. Für Verzeichnisse ist das praktisch, für einzelne Seiten riskant.

Für einzelne Adressen ist RewriteRule aus mod_rewrite genauer. ^ markiert den Anfang, $ das Ende des Pfads. In der .htaccess steht der Pfad ohne führenden Schrägstrich, ein Muster mit ^/ passt dort nie.

RewriteEngine On
RewriteRule ^alte-seite/$ https://www.beispiel.de/neue-seite/ [R=301,L]
RewriteRule ^produkte/tasse-blau\.html$ https://www.beispiel.de/tassen/tasse-blau/ [R=301,L]

Die erste Regel greift bei /alte-seite/, nicht aber bei /alte-seite/unterseite/, /alte-seite-2/ oder /alte-seite ohne Schrägstrich. Soll die Variante ohne Schrägstrich mitlaufen, schreib ^alte-seite/?$. Punkte maskierst du mit einem Backslash, denn ein nackter Punkt steht für ein beliebiges Zeichen. R=301 setzt den Statuscode, L verhindert, dass danach weitere Regeln greifen.

Weiterleitung mit Query-String

Ältere Shopsysteme nutzen oft Adressen wie index.php?id=123. Den Teil nach dem Fragezeichen sieht RewriteRule nicht, ein Muster wie ^index\.php\?id=123$ passt also nie. Du brauchst eine RewriteCond auf %{QUERY_STRING}:

RewriteEngine On
RewriteCond %{QUERY_STRING} (^|&)id=123(&|$)
RewriteRule ^index\.php$ https://www.beispiel.de/tasse-blau/? [R=301,L]

Die Bedingung findet id=123 an jeder Stelle der Parameter, aber nicht id=1234. Das Fragezeichen am Ende des Ziels entfernt den alten Query-String. Ohne es landet der Besucher auf /tasse-blau/?id=123. Seit Apache 2.4.0 geht das auch mit dem Flag QSD.

Domainwechsel

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?alte-domain\.de$ [NC]
RewriteRule ^(.*)$ https://www.neue-domain.de/$1 [R=301,L]

Die Regel nimmt Pfad und Parameter mit: Aus alte-domain.de/kategorie/produkt/ wird www.neue-domain.de/kategorie/produkt/. NC ignoriert Groß- und Kleinschreibung. Ändern sich beim Umzug auch die Pfade, gehören die einzelnen Regeln über diese Sammelregel, sonst entsteht eine Kette.

HTTP zu HTTPS, mit oder ohne www

Für die reine Umstellung auf HTTPS reicht diese Regel:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Willst du zusätzlich genau eine Variante mit oder ohne www, kombiniere beides in einer Regel. Dann springt auch http://www.beispiel.de in einem Schritt ans Ziel. Ohne www:

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://beispiel.de%{REQUEST_URI} [R=301,L]

Mit www:

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.beispiel.de%{REQUEST_URI} [R=301,L]

Stell einzelne Weiterleitungen vor diese Regel und gib ihr Ziel vollständig mit https:// und Domain an. Dann geht auch http://beispiel.de/alte-seite/ direkt zur neuen Seite. Übernimmt ein Proxy oder CDN das HTTPS, meldet %{HTTPS} immer „off“, und die Regel dreht sich endlos im Kreis. Apache empfiehlt dann, den Header X-Forwarded-Proto zu prüfen, sofern du den Proxy selbst kontrollierst. Mit Zugriff auf die Server-Konfiguration ist laut Apache ein Redirect im VirtualHost für Port 80 der sauberste Weg.

Gelöschte Seiten beantwortest du mit dem Flag G. Es liefert 410 Gone:

RewriteEngine On
RewriteRule ^alte-seite/$ - [G]

301-Weiterleitung mit nginx einrichten

nginx kennt keine .htaccess. Weiterleitungen stehen in der Server-Konfiguration, je nach System unter /etc/nginx/conf.d/ oder /etc/nginx/sites-available/. Prüf nach jeder Änderung die Syntax mit nginx -t und lade die Konfiguration dann neu, etwa mit nginx -s reload.

Einzelne Adressen mit location =

location = /alte-seite/ {
    return 301 https://www.beispiel.de/neue-seite/;
}

Das Gleichheitszeichen verlangt einen exakten Treffer. Ein location ohne = passt auf jeden Pfad, der mit der Zeichenkette beginnt, und zwar Zeichen für Zeichen statt nach Pfadabschnitten. Im Test hat location /alt auch /alternativen/, /altes-produkt.html und /alte-seite weitergeleitet. Das ist ein häufiger Fehler.

location prüft nur den Pfad, Parameter spielen für den Treffer keine Rolle. return hängt den alten Query-String aber nicht an. Willst du Parameter wie utm_source behalten, ergänze $is_args$args:

location = /alte-seite/ {
    return 301 https://www.beispiel.de/neue-seite/$is_args$args;
}

HTTP zu HTTPS und www mit nginx

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

server {
    listen 443 ssl;
    server_name beispiel.de;
    ssl_certificate     /pfad/zum/zertifikat.pem;
    ssl_certificate_key /pfad/zum/schluessel.pem;
    return 301 https://www.beispiel.de$request_uri;
}

$request_uri enthält Pfad und Parameter der ursprünglichen Anfrage. Die Website selbst läuft in einem weiteren server-Block für www.beispiel.de.

Viele Weiterleitungen mit map

Bei Hunderten Adressen nimmst du statt vieler location-Blöcke eine map. Sie steht im http-Block, also außerhalb von server:

map $uri $neues_ziel {
    default "";
    /alte-seite/            /neue-seite/;
    /kategorie/tassen-alt/  /tassen/;
}

server {
    # ...
    if ($neues_ziel) {
        return 301 https://www.beispiel.de$neues_ziel;
    }
}

$uri ist der Pfad ohne Parameter, Groß- und Kleinschreibung spielt keine Rolle. Für alte Adressen mit Parametern nimmst du $request_uri und setzt den Schlüssel in Anführungszeichen, etwa "/index.php?id=123". Lange Listen lagerst du mit include in eine eigene Datei aus. Meldet nginx -t bei langen Schlüsseln, dass map_hash_bucket_size zu klein ist, erhöhst du den Wert im http-Block.

Trag die if-Abfrage auch in den server-Block für Port 80 ein, vor das allgemeine return. Dann springt http://beispiel.de/alte-seite/ in einem Schritt ans Ziel. Für die neue seorado.de nutze ich genau diese Kombination: exakte location-Regeln für einzelne Adressen und eine map für die alten Bildadressen.

WordPress: 301-Weiterleitung mit Plugin

In WordPress geht es am einfachsten mit dem kostenlosen Plugin Redirection. Du findest es unter Werkzeuge > Redirection, trägst die alte Adresse als Quelle und die neue als Ziel ein und wählst 301. Das Plugin kann auch 302, 307, 308 und 410, versteht reguläre Ausdrücke und protokolliert 404-Fehler. So siehst du nach einem Relaunch, welche alten Adressen noch aufgerufen werden. Weiterleitungen importierst du per CSV und exportierst sie auch als .htaccess- oder nginx-Regeln.

WordPress leitet einen geänderten Slug bei Beiträgen selbst per 301 um, bei Seiten und anderen hierarchischen Inhalten nicht. Plugin-Weiterleitungen greifen erst, wenn WordPress geladen ist, bei Tausenden Regeln ist die Server-Ebene schneller. Nutze nur ein Werkzeug für Weiterleitungen, auch wenn dein SEO-Plugin eines mitbringt. Sonst suchst du Fehler an zwei Stellen.

Shopify: URL-Weiterleitungen einrichten

Shopify verwaltet Weiterleitungen im Adminbereich unter Inhalt > Menüs > URL-Weiterleitungen anzeigen. Klick auf „URL-Weiterleitung erstellen“, trag unter „Weiterleiten von“ die alte und unter „Weiterleiten zu“ die neue Adresse ein und klick auf „Weiterleitung speichern“. Viele Adressen lädst du über „Importieren“ als CSV-Datei hoch, eine Beispieldatei gibt es dort. Laut Shopify-Hilfe gilt:

• Weiterleiten kannst du nur von Adressen, die nicht mehr existieren und eine 404-Seite zeigen.
• Adressen, die mit /apps, /application, /cart, /carts, /orders, /services oder /shop beginnen, lassen sich nicht umleiten, ebenso die festen Shopify-Pfade /products, /collections und /collections/all selbst.
• Adressen mit Query-String funktionieren möglicherweise nicht wie erwartet.
• Möglich sind bis zu 100.000 Weiterleitungen, mit Shopify Plus bis zu 20 Millionen.

Änderst du bei einem Produkt oder einer Seite das URL-Handle im Suchmaschineneintrag, ist „URL-Weiterleitung erstellen“ vorausgewählt. Lass die Option aktiv, wenn die alte Adresse indexiert oder verlinkt ist.

Beim Umzug von RYMHART ging es 2024 von PrestaShop unter rymhart-troyer.de zu Shopify unter rymhart.de. Dabei habe ich jede alte Adresse weitergeleitet. Mehr dazu in der Referenz zu RYMHART.

Shopware 6: Weiterleitungen einrichten

Bei Shopware 6 gibt es zwei Fälle. Ändert sich eine URL innerhalb von Shopware, etwa durch einen neuen Produktnamen, kennt das System die alte SEO-URL. In den Einstellungen unter SEO steht im Abschnitt „Verhalten der Weiterleitung“ die Option „Statt Canonical URLs direkt per HTTP 301 auf die aktuellste URL leiten“. Ist sie aktiv, antwortet die alte Adresse mit einer echten 301. Sonst liefert Shopware sie weiter aus und verweist nur per Canonical auf die neue.

Der zweite Fall ist ein Umzug aus einem anderen System. Alte Adressen aus Gambio oder WooCommerce kennt Shopware 6 nicht, einen Bereich für frei definierte Weiterleitungen beschreibt die Dokumentation nicht. Üblich sind zwei Wege: eine Erweiterung aus dem Shopware Store, die 301-Weiterleitungen verwaltet und oft einen CSV-Import mitbringt, oder Regeln auf dem Webserver. Bei Apache gehören sie in die .htaccess im Ordner public vor die Shopware-Regeln.

Bei der Opal-Schmiede habe ich den Shop von Gambio zu Shopware umgezogen und alle alten Adressen weitergeleitet. Details stehen in der Referenz zur Opal-Schmiede.

Baukästen und Hoster: Wix, Jimdo und IONOS

Baukästen bieten eine einfache Oberfläche, aber wenig Spielraum. Reguläre Ausdrücke und Parameter sind meist nicht möglich, die Menüs ändern sich häufig. Stand September 2026 laut offizieller Hilfe:

Prüf nach dem Einrichten bei jedem Baukasten mit curl, ob wirklich eine 301 zurückkommt und der Pfad erhalten bleibt.

Weiterleitungen testen

Verlass dich beim Testen nicht allein auf den Browser, denn er speichert 301-Weiterleitungen zwischen. Zuverlässiger ist curl auf der Kommandozeile, vorinstalliert unter macOS, aktuellen Windows-Versionen und den meisten Linux-Systemen. In der Windows PowerShell tippst du curl.exe, weil curl dort ein Alias für einen anderen Befehl ist.

curl -I https://www.beispiel.de/alte-seite/

Mit -I fragt curl nur die Header ab: erst den Statuscode, bei einer Weiterleitung darunter Location mit dem Ziel. Mit -sIL folgt curl allen Weiterleitungen und zeigt jeden Sprung, so erkennst du Ketten sofort. Unter macOS und Linux filterst du die wichtigen Zeilen mit grep:

curl -sIL http://beispiel.de/alte-seite/ | grep -iE "^(HTTP|location)"

HTTP/1.1 301 Moved Permanently
Location: https://www.beispiel.de/neue-seite/
HTTP/2 200

Ideal ist genau eine Weiterleitung und danach Status 200. Für eine Liste alter Adressen reicht eine Schleife über eine Datei mit einer URL pro Zeile:

while read -r url; do
  curl -s -o /dev/null -w "%{http_code} %{url_effective} -> %{redirect_url}\n" "$url"
done < alte-urls.txt

curl -I schickt eine HEAD-Anfrage, auf die manche Systeme anders antworten als auf einen normalen Aufruf. Die Schleife nutzt deshalb GET.

Im Browser prüfen

Öffne die Entwicklerwerkzeuge deines Browsers, unter Windows meist mit F12, und wechsle zum Tab Netzwerk. Dort siehst du jede Anfrage mit Statuscode. Aktiviere das Beibehalten des Protokolls, damit die Weiterleitung beim Seitenwechsel nicht aus der Liste verschwindet, und deaktiviere den Cache.

In der Search Console prüfen

Nach dem Umzug zeigt dir die Search Console, wie Google deine Weiterleitungen sieht. Prüf alte Adressen mit der URL-Prüfung. Im Bericht zur Seitenindexierung stehen sie unter „Seite mit Weiterleitung“, das ist gewollt. Kritisch ist „Weiterleitungsfehler“: Dahinter stecken zu lange Ketten, Schleifen, zu lange URLs oder leere Ziele. Beim Domainwechsel meldest du den Umzug zusätzlich mit dem Tool zur Adressänderung. Wie du neue Adressen einreichst, erklärt die Anleitung URL in der Google Search Console eintragen.

Typische Fehler und wie du sie vermeidest

• Fehlender Statuscode, Präfix statt exakter Treffer. Ohne Code wird es oft eine 302. Redirect bei Apache und location ohne = bei nginx erfassen mehr Adressen, als du denkst.
• Ketten. A leitet auf B, B auf C. Google folgt bis zu zehn Sprüngen, empfiehlt aber, direkt auf das Endziel zu leiten. Ändert sich ein Ziel, passe auch die alten Regeln an.
• Schleifen. Ein Klassiker ist Redirect 301 /shop /shop/neu. Weil /shop/neu wieder mit /shop beginnt, entsteht /shop/neu/neu, bis der Browser abbricht.
• Alles auf die Startseite. Das kann Google als Soft 404 werten. Such für jede Adresse das beste Ziel oder antworte mit 410.
• Interne Links und Sitemap vergessen. Menüs, Textlinks, Canonicals und die XML-Sitemap sollten direkt auf die neuen Adressen zeigen.
• Weiterleitungen zu früh gelöscht. Google empfiehlt in der Regel mindestens ein Jahr. Beim Domainwechsel muss dafür auch die alte Domain registriert und erreichbar bleiben.

Du planst einen Shop-Umzug und willst keine Adresse verlieren? Unterstützung findest du unter SEO für Online-Shops. Beim kostenlosen Shop-Check bekommst du innerhalb von 48 Stunden drei konkrete Punkte zu deinem Shop.

Häufige Fragen

Wie lange muss eine 301-Weiterleitung bestehen bleiben?

Google empfiehlt, Weiterleitungen so lange wie möglich zu behalten, in der Regel mindestens ein Jahr. Besser ist dauerhaft, denn Backlinks und Lesezeichen verweisen oft noch Jahre später auf alte Adressen.

Kostet eine 301-Weiterleitung Rankings?

Laut Google ist eine serverseitige 301 der beste Weg, Suchmaschinen und Besucher zur richtigen Seite zu führen. Bei größeren Umbauten sind laut Google trotzdem Schwankungen möglich, solange neu gecrawlt und indexiert wird. Bei mittelgroßen Websites dauert es einige Wochen oder länger, bis die neuen Adressen die alten ersetzen.

Solltest du 301 oder 308 verwenden?

Für Seiten, Produkte und Kategorien nimm 301. Google behandelt 308 genauso. Die 308 brauchst du, wenn auch POST-Anfragen unverändert am Ziel ankommen müssen, etwa bei Formularen oder Schnittstellen.

Kannst du eine 301-Weiterleitung rückgängig machen?

Technisch ja, du löschst die Regel. Browser haben die 301 aber womöglich gespeichert und leiten wiederkehrende Besucher weiter um, bis ihr Cache abläuft. Ist ein Umzug nur vorübergehend, nimm von Anfang an 302 oder 307.

Darfst du gelöschte Produkte auf die Startseite umleiten?

Besser nicht, Google kann das als Soft 404 werten. Leite ein ausgelaufenes Produkt auf den Nachfolger oder eine wirklich passende Kategorie. Gibt es beides nicht, antworte mit 410.

Funktioniert eine 301 auch für Bilder und PDF-Dateien?

Ja, eine Weiterleitung funktioniert für jede Adresse. Beim Umbau von seorado.de zeigen zum Beispiel 180 alte Bildadressen per 301 auf die neuen WebP-Dateien. So bleiben verlinkte Bilder erreichbar.