Start / Magazin / Relaunch & Technik

301-Weiterleitungs-Generator für .htaccess, Nginx, IIS und PHP

301-Weiterleitungs-Generator für .htaccess, Nginx, IIS und PHP

Alles auf einen Blick

  • Für dauerhaft geänderte Adressen nimmst du 301 oder 308. Google behandelt beide gleich und wertet sie als starkes Signal für die neue URL.
  • Serverseitige Weiterleitungen über .htaccess, Nginx oder IIS sind die erste Wahl. PHP ist eine Notlösung. Meta-Refresh und JavaScript senden keinen 3xx-Statuscode.
  • Die Nginx-Regeln nutzen location = und treffen genau eine Adresse. Nach dem Einfügen prüfst du mit nginx -t und lädst neu.
  • Das URL Rewrite Module von IIS kennt kein 308. Dort nimmst du 301.
  • Für Hunderte Adressen beim Shop-Relaunch nutzt du den Shop-Umzugs-Planer.
Inhaltsverzeichnis8 Abschnitte
  1. So benutzt du den Generator
  2. Welche Variante wann?
  3. Welcher Statuscode wann?
  4. Wohin der erzeugte Code gehört
  5. Viele URLs beim Shop-Relaunch
  6. Häufige Fehler
  7. Häufige Fragen
  8. Quellen

Ändert sich eine Adresse in deinem Shop, braucht die alte URL eine Weiterleitung. Sonst landen Besucher und Google auf einer 404-Seite. Dieser Generator schreibt dir den Code dafür: für .htaccess (Apache), Nginx, IIS (web.config) und PHP sowie als Meta-Refresh oder JavaScript. Du erzeugst eine einzelne Weiterleitung oder eine ganze Liste und wählst zwischen den Statuscodes 301, 302, 303, 307 und 308.

Unter dem Tool erfährst du, welche Variante und welcher Statuscode passen, wohin der Code gehört und welche Fehler Weiterleitungen wirkungslos machen.

So benutzt du den Generator

  1. Modus wählen. „Einzelne Weiterleitung“ erzeugt eine Regel. Mit „Bulk-Weiterleitung“ baust du eine Liste: „Weitere Weiterleitung hinzufügen“ legt eine neue Zeile an, „Löschen“ entfernt sie.
  2. Quelle und Ziel eintragen. Die Quelle gibst du als Pfad an, etwa /alte-seite.html, oder als volle URL mit http:// oder https://. Die volle URL lohnt sich, wenn mehrere Domains auf denselben Server zeigen, denn dann prüft die Regel auch den Hostnamen. Das Ziel ist immer eine vollständige URL.
  3. Variante und Statuscode wählen. Unter „Weiterleitungstyp“ stellst du deinen Server ein, unter „HTTP Statuscode“ den Code. Bei Meta-Refresh kommt die Verzögerung in Sekunden dazu, 0 heißt sofort. Bei Meta-Refresh und JavaScript ist der Statuscode gesperrt, denn diese Varianten senden keinen.
  4. Erzeugen und kopieren. Klick auf „Weiterleitung generieren“, prüf den Code und übernimm ihn mit „In Zwischenablage kopieren“.

Welche Variante wann?

Bei einer serverseitigen Weiterleitung antwortet der Server direkt mit einem 3xx-Statuscode und der neuen Adresse im Location-Header. Die alte Seite wird gar nicht erst ausgeliefert. Google empfiehlt, wann immer möglich eine dauerhafte serverseitige Weiterleitung zu nutzen.

VarianteWo sie wirktStatuscodesWann sinnvoll
.htaccess (Apache)Webserver301, 302, 303, 307, 308Shops auf Apache, auch im Shared Hosting
NginxWebserver301, 302, 303, 307, 308eigener Server oder VPS mit Nginx
IIS (web.config)Webserver301, 302, 303, 307Windows-Server mit URL Rewrite Module
PHPSkript auf dem Server301, 302, 303, 307, 308Notlösung ohne Zugriff auf die Serverkonfiguration
Meta-RefreshBrowserkeiner, der Server antwortet mit 200nur wenn keine serverseitige Weiterleitung möglich ist
JavaScriptBrowser, nach dem Rendernkeiner, der Server antwortet mit 200letzte Wahl, wenn auch Meta-Refresh nicht geht

PHP nur als Notlösung

PHP sendet einen echten Statuscode, greift aber erst, wenn die Anfrage bei der PHP-Datei ankommt. Eine Regel in der Serverkonfiguration greift früher und unabhängig vom Shopsystem. Das Skript aus dem Bulk-Modus wirkt nur, wenn alle alten URLs über dieselbe Datei laufen, etwa über die index.php des Shops. Nutze PHP deshalb nur, wenn du weder .htaccess noch Serverkonfiguration bearbeiten kannst.

Meta-Refresh und JavaScript

Beide Varianten laufen erst im Browser. Der Server liefert die alte Seite mit Status 200 aus, dann leitet der Browser weiter. Einen 3xx-Code kann nur der Server senden. Google erkennt beide trotzdem als Weiterleitung: Einen Meta-Refresh mit 0 Sekunden wertet Google als dauerhaft, einen mit Verzögerung als vorübergehend. Eine JavaScript-Weiterleitung zählt als dauerhaft, Google sieht sie aber nur, wenn das Rendern der Seite klappt. Deshalb rät Google, JavaScript nur zu nutzen, wenn weder eine serverseitige Weiterleitung noch ein Meta-Refresh möglich ist.

Welcher Statuscode wann?

Der Statuscode sagt Browsern und Suchmaschinen, ob die Änderung bleibt. Bei einer dauerhaften Weiterleitung nutzt Google das Ziel als Signal für die kanonische Adresse, in den Suchergebnissen erscheint die neue URL. Bei einer vorübergehenden folgt der Googlebot zwar, die alte URL bleibt aber in den Ergebnissen.

CodeBedeutungEinsatz im Shop
301Moved Permanently, dauerhaftStandard für geänderte URLs, Relaunch, Domainwechsel und Umstieg auf HTTPS
308Permanent Redirect, dauerhaft, die Anfragemethode bleibt gleichwie 301, wenn Formulare oder Schnittstellen per POST an die alte Adresse senden
302Found, vorübergehendkurzfristige Umleitung, etwa auf eine Aktionsseite
307Temporary Redirect, vorübergehend, die Anfragemethode bleibt gleichwie 302, wenn POST-Anfragen erhalten bleiben müssen
303See Other, vorübergehendnach dem Absenden eines Formulars auf eine Ergebnisseite, für SEO kaum relevant

Google behandelt 301 und 308 gleich, ebenso 302, 303 und 307. Der Unterschied liegt in der Anfragemethode: Bei 301 und 302 dürfen Browser aus einem POST einen GET machen, bei 307 und 308 nicht. Für normale Shop-Seiten ist 301 die sichere Wahl. 308 gibt es erst seit 2014 und wird laut RFC 9110 womöglich nicht überall erkannt.

Wichtig

Das URL Rewrite Module von IIS unterstützt kein 308. Es kennt nur 301, 302, 303 und 307. Wählst du im Generator IIS, ist 308 deshalb gesperrt, und der Code nutzt redirectType="Permanent", also 301.

Wohin der erzeugte Code gehört

Leg vor jeder Änderung eine Sicherung der Datei an. Ein Tippfehler in einer Serverdatei kann den ganzen Shop lahmlegen.

.htaccess (Apache)

Die .htaccess liegt im Verzeichnis, aus dem der Webserver deinen Shop ausliefert. Setz den Block oben in die Datei, vor die Regeln des Shopsystems. Für einen Pfad erzeugt der Generator eine Zeile mit RedirectMatch, die genau diese eine Adresse trifft:

# Redirect von /alte-seite.html zu https://www.dein-shop.de/neue-seite mit Statuscode 301
RedirectMatch 301 ^/alte-seite\.html$ https://www.dein-shop.de/neue-seite

RedirectMatch arbeitet mit regulären Ausdrücken. ^ und $ binden die Regel an Anfang und Ende des Pfads, den Punkt in .html maskiert der Generator mit einem Backslash. Parameter wie ?utm_source= hängt Apache an das Ziel an. Die kürzere Form Redirect 301 /kategorie … vergleicht dagegen nur den Anfang des Pfads in ganzen Abschnitten. Sie greift auch bei /kategorie/produkt und hängt den Rest an das Ziel an. Deshalb nutzt der Generator sie nicht. Gibst du die Quelle als volle URL ein, entsteht eine Regel aus RewriteCond auf den Hostnamen und RewriteRule, bei 301 mit [R=301,L].

Nginx

Nginx liest keine .htaccess. Die Regeln gehören in den server-Block deiner Domain, je nach System unter /etc/nginx/sites-available/ oder /etc/nginx/conf.d/. Der Generator erzeugt exakte Regeln:

# Redirect von /alte-seite.html zu https://www.dein-shop.de/neue-seite
location = /alte-seite.html {
    return 301 https://www.dein-shop.de/neue-seite;
}

location = passt nur auf genau diese Adresse, Nginx beendet die Suche dann sofort. Ohne = wäre es ein Präfix, der auch /alte-seite.html-2 erfassen kann. Parameter spielen beim Abgleich keine Rolle. Hast du die Quelle als volle URL eingegeben, steht die Regel in einem eigenen server-Block. Hat die Domain schon einen, übernimmst du nur die location-Blöcke. Dann testest du und lädst neu:

sudo nginx -t
sudo nginx -s reload

nginx -t prüft die Syntax und versucht, alle Dateien zu öffnen, auf die die Konfiguration verweist. Lade erst neu, wenn der Test fehlerfrei durchläuft. Mit systemd geht auch sudo systemctl reload nginx.

IIS (web.config)

Für IIS brauchst du das URL Rewrite Module, eine Erweiterung von Microsoft. Die Regeln kommen in die web.config der Website, innerhalb von <system.webServer>:

<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Redirect_1" stopProcessing="true">
          <match url="^alte-seite\.html$" />
          <action type="Redirect" url="https://www.dein-shop.de/neue-seite" redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

Das Muster steht ohne führenden Schrägstrich, denn IIS vergleicht den Pfad relativ zur web.config und ohne Parameter. Die Parameter hängt IIS standardmäßig an das Ziel an. Die Einzelregel des Generators heißt immer „Redirect Rule“. Fügst du mehrere ein, gib jeder einen eigenen Namen.

PHP

Der Code gehört ganz an den Anfang der Datei, die unter der alten Adresse aufgerufen wird. Vor <?php darf nichts stehen, kein HTML und keine Leerzeile, auch nicht in eingebundenen Dateien. PHP kann Header nur senden, solange noch keine Ausgabe erfolgt ist.

<?php
    header("Location: https://www.dein-shop.de/neue-seite", true, 301);
    exit;
?>

Der dritte Parameter setzt den Statuscode. Fehlt er, sendet PHP bei einem Location-Header eine 302. exit verhindert, dass danach weiterer Code läuft.

Meta-Refresh und JavaScript

Beide Snippets kommen in den Quelltext der alten Seite, der Meta-Tag in den <head>. Die alte Seite muss dafür weiter ausgeliefert werden.

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

Viele URLs beim Shop-Relaunch

Für eine Handvoll Adressen reicht der Bulk-Modus. Beim Wechsel des Shopsystems geht es schnell um Hunderte oder Tausende Produkt-, Kategorie- und Bild-URLs. Dann ist nicht der Code das Problem, sondern die Zuordnung. Ich habe Shops von PrestaShop zu Shopify und von Gambio zu Shopware umgezogen, jeweils mit Weiterleitungen aller alten Adressen.

Genau dafür gibt es den Shop-Umzugs-Planer. Du fügst die Listen mit alten und neuen URLs ein. Der Planer ordnet sie über Pfad, Wörter und Artikelnummern zu und legt unsichere Treffer zur Prüfung vor. Er exportiert Regeln für Nginx, Apache und den Shopify-Import, auch für alte Adressen mit Parametern, dazu ein Prüfskript für den Livegang. Den ganzen Umzug planst du mit dem Beitrag SEO beim Website-Relaunch.

Häufige Fehler

  • Ketten. A leitet auf B, B auf C. Der Googlebot folgt bis zu zehn Sprüngen, Google rät aber, direkt auf das endgültige Ziel zu leiten.
  • Schleifen. Das Ziel leitet zurück auf die Quelle, der Browser bricht mit einer Fehlermeldung ab.
  • Alles auf die Startseite. Viele alte URLs auf eine unpassende Seite zu leiten, kann Google als Soft 404 werten. Leite auf die passende Kategorie oder den Nachfolger des Produkts.
  • 302 für dauerhafte Änderungen. Dann nutzt Google das Ziel nicht als Signal für die kanonische Adresse, und die alte URL bleibt in den Suchergebnissen.
  • Präfix statt exakt. location ohne = und Redirect in der .htaccess erfassen mehr als eine Adresse.
  • Parameter übersehen. Die Regeln des Generators vergleichen nur den Pfad. Alte Adressen wie /product_info.php?info=p388 brauchen eine Bedingung auf den Parameterteil, bei Apache etwa RewriteCond %{QUERY_STRING}.
  • Interne Links vergessen. Menü, Produkttexte und Sitemap sollten direkt auf die neuen URLs zeigen.

Tipp

Teste jede Weiterleitung im Terminal mit curl -I https://www.dein-shop.de/alte-seite.html. Die Antwort zeigt den Statuscode und in der Zeile Location das Ziel. Dem Browser traust du dabei besser nicht: 301 und 308 darf er zwischenspeichern, eine geänderte Regel siehst du dort womöglich erst später.

Weiterleitungen sind ein Teil der Shop-Technik. Wie Kategorien, Produktseiten und Technik zusammenspielen, liest du unter SEO für Online-Shops. Wo es in deinem Shop hakt, zeigt dir der kostenlose Shop-Check innerhalb von 48 Stunden.

Häufige Fragen

Was ist der Unterschied zwischen 301 und 308?

Beide melden eine dauerhafte Verschiebung, Google behandelt sie gleich. Bei 308 muss der Browser die Anfragemethode beibehalten, ein POST bleibt ein POST. Bei 301 darf er daraus einen GET machen. Für normale Shop-Seiten reicht 301. Im URL Rewrite Module von IIS ist es die einzige dauerhafte Option.

Wie lange muss eine Weiterleitung bestehen bleiben?

Google empfiehlt bei einem Umzug, Weiterleitungen so lange wie möglich zu behalten, in der Regel mindestens ein Jahr. Adressen mit Backlinks von anderen Websites leitest du am besten dauerhaft weiter, denn diese Links bleiben bestehen.

Lässt sich mit dem Generator eine ganze Domain umziehen?

Der Generator erzeugt Regeln für einzelne Adressen. Bleiben beim Domainwechsel alle Pfade gleich, reicht in der .htaccess der alten Domain eine Regel mit Muster:

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

Ändern sich die Pfade, brauchst du eine Zuordnung pro URL. Mehr dazu steht in der Anleitung 301-Weiterleitungen einrichten.

Funktioniert der Generator auch für Shopify?

Nur bedingt. Bei Shopify hast du keinen Zugriff auf .htaccess oder Serverkonfiguration. Weiterleitungen legst du dort im Admin an oder importierst sie als CSV-Datei. Diese Datei erzeugt dir der Shop-Umzugs-Planer.

Quellen

Geschrieben von

SEO, GEO und KI-Automatisierung für Online-Shops. Ich teste, worüber ich schreibe, zuerst auf eigenen Seiten und in Kundenprojekten wie RYMHART und Opal-Schmiede.

Das für deinen Shop umsetzen?

Drei Fragen, sofort eine Einschätzung, danach drei konkrete Punkte von mir persönlich. Kostenlos.

Projekt anfragen

Weitere Artikel
aus dem Magazin.

Alle Artikel
Relaunch & Technik11 Min.

URLs aus Google entfernen: Search Console, 410 und noindex

Eine Seite soll aus der Google-Suche verschwinden? Dafür hast du mehrere Werkzeuge. Das Entfernen-Tool der Search Console blendet eine URL schnell aus, aber nur für etwa sechs Monate. Dauerhaft verschwindet sie …