.htaccess-Weiterleitung einrichten: Einzelne Seiten, Ordner und Domains umleiten

Wann ist eine Weiterleitung per .htaccess die richtige Wahl?

Mit einer .htaccess-Weiterleitung weisen Sie den Apache HTTP Server (Apache) über die Konfigurationsdatei Hypertext Access (.htaccess) an, Aufrufe einer alten Adresse automatisch mit dem Statuscode 301 an ein neues Ziel zu schicken. Besucher und Suchmaschinen behalten dadurch ihre Orientierung ohne Fehlermeldung. Sichern Sie zuerst Ihre bestehende Datei per Kopie und tragen Sie die Regel im Wurzelverzeichnis ein.

Wenn sich der Uniform Resource Locator (URL) einer Unterseite ändert oder Ihre Website umzieht, greift die .htaccess-Datei im Wurzelverzeichnis noch vor einem System wie WordPress. Der Webserver beantwortet die Anfrage im Hypertext Transfer Protocol (HTTP) direkt mit dem Statuscode 301 Moved Permanently und schickt die neue Zieladresse im Location-Header mit. Genau dieser direkte Weg auf dem Server schützt Ihre Search Engine Optimization (SEO): Laut Google Search Central (Stand 20. April 2026) übernehmen Suchmaschinen bei dauerhaften Statuscodes wie 301 oder 308 die neue Adresse als kanonisches Ziel in den Index, sodass der PageRank dabei vollständig erhalten bleibt.

Allerdings funktioniert die .htaccess ausschließlich auf dem Apache HTTP Server (Versionsreihe 2.4) sowie kompatiblen Servern wie LiteSpeed, sofern dort AllowOverride FileInfo freigegeben ist. Im klassischen Shared Hosting ohne eigenen Root-Zugriff führt der direkte Weg über diese Datei, weil der Server jede Änderung sofort übernimmt. Einen Neustart braucht er dafür nicht. Wenn Sie dagegen auf einem eigenen Server vollen Zugriff auf die Hauptkonfiguration (httpd.conf oder VirtualHost) haben, rät die Apache-Dokumentation (Stand 2026) zum Eintrag direkt dort: Während Apache die Hauptkonfiguration nur einmal beim Start einliest, muss er die .htaccess bei jedem Seitenaufruf neu vom Dateisystem laden.

Wie leiten Sie eine einzelne Seite dauerhaft per 301 um?

Eine einzelne Seite leiten Sie in der .htaccess entweder über die Direktive Redirect 301 aus dem Modul mod_alias oder über eine RewriteRule aus dem Modul mod_rewrite dauerhaft um. Während Redirect 301 einen einfachen Pfad mit führendem Schrägstrich vergleicht, prüft RewriteRule ein Suchmuster ohne führenden Schrägstrich und beendet den Durchlauf mit dem Flag [R=301,L].

Eine schlichte Eins-zu-eins-Umleitung richten Sie am übersichtlichsten mit Redirect 301 aus mod_alias ein, weil Sie dafür weder reguläre Ausdrücke noch RewriteEngine On benötigen. Sie schreiben nach Redirect 301 den alten Pfad mit führendem Schrägstrich und dahinter die vollständige neue Zieladresse. Die Zahl 301 ist dabei Pflicht. Ohne Statuscode sendet Apache nur 302. Da Redirect laut Apache-Dokumentation (Stand 2026) immer Präfixe abgleicht, leitet eine Regel für /leistungen automatisch auch /leistungen/webdesign um:

# Einzelne Seite per mod_alias dauerhaft weiterleiten
Redirect 301 /kontakt-alt.html https://example.de/kontakt/

Wenn Sie exakt eine einzelne Adresse ohne Unterpfade abfangen möchten, nutzen Sie RewriteRule, wie es die Apache-Dokumentation zu mod_rewrite beschreibt. Apache entfernt im Verzeichniskontext der .htaccess vor dem Musterabgleich immer den führenden Schrägstrich. Ein Muster mit ^/ greift nie. Sie notieren den Pfad deshalb direkt nach dem Zeichen ^ ohne Schrägstrich, während /?$ am Ende Aufrufe mit und ohne Schrägstrich abfängt. In [R=301,L] erzwingt der Zusatz 301 den permanenten Statuscode (statt 302 bei bloßem [R]), L beendet den Durchlauf sofort, und nach dem Komma darf kein Leerzeichen stehen.

Was tun Sie dagegen mit einer alten Seite, die beim Relaunch ersatzlos wegfällt? Wenn eine abgelaufene Aktion kein inhaltliches Gegenstück mehr hat, leiten Sie die Adresse nicht auf eine beliebige andere Seite um. Gelöschte Seiten ohne Ersatz erhalten 410. Der Statuscode 410 Gone teilt den Suchmaschinen nach dem HTTP-Standard RFC 9110 der IETF (Abschnitt 15.5.11, Juni 2022) verbindlich mit, dass die Ressource dauerhaft entfernt wurde. Dafür tragen Sie entweder Redirect 410 oder das Flag [G,L] ein:

RewriteEngine On
RewriteRule ^kontakt-alt/?$ https://example.de/kontakt/ [R=301,L]
Redirect 410 /alte-aktion-2022/

Damit beim Einrichten Ihrer ersten Weiterleitung nichts schiefgeht, gehen Sie in dieser festen Reihenfolge vor:

1. Bestehende .htaccess im Wurzelverzeichnis sichern

   Laden Sie vor jeder Änderung die aktuelle .htaccess-Datei aus dem Hauptverzeichnis Ihres Webspaces (etwa /var/www/html/) per SFTP auf Ihren Rechner herunter. Bei einem Tippfehler spielen Sie diese Sicherungskopie sofort wieder ein.

2. Passendes Modul und Regeltyp auswählen

   Wählen Sie Redirect 301 (mit führendem /) für einzelne statische Pfade. Nutzen Sie RewriteEngine On mit RewriteRule (ohne führenden /), sobald Sie Muster, Ordner oder Bedingungen mit RewriteCond benötigen.

3. Weiterleitungsregel vor dem CMS-Block eintragen

   Fügen Sie Ihre neuen Zeilen in einem reinen Texteditor im oberen Bereich der .htaccess ein – bei WordPress zwingend oberhalb von # BEGIN WordPress. Laden Sie die Datei anschließend wieder auf den Server hoch.

4. HTTP-Statuscode 301 ohne Browser-Cache prüfen

   Kontrollieren Sie die alte Adresse nach dem Hochladen im Terminal mit curl -sI https://example.de/alte-seite oder im Netzwerk-Tab bei deaktiviertem Cache. Der Server muss im ersten Schritt mit 301 antworten.

Wie leiten Sie einen ganzen Ordner oder eine alte Domain um?

Einen umbenannten Ordner oder eine komplette Domain leiten Sie mit mod_rewrite um, indem Sie den angefragten Pfad über den Suchausdruck (.*) auffangen und über die Variable $1 an die Zieladresse anhängen. So landet jeder Aufruf einer Unterseite in einem einzigen Schritt beim passenden Gegenstück, ohne dass Besucher auf der Startseite stranden.

Wenn Sie Ihr Verzeichnis /blog/ in /ratgeber/ umbenennen, speichert der Klammerausdruck (.*) alles hinter /blog/ und setzt es am Ziel über $1 wieder ein. Alle Dateinamen bleiben dabei erhalten. Einen kompletten Domainwechsel von example.de auf example.com setzen Sie nach demselben Prinzip um, sobald die Seitenstruktur identisch bleibt. Dazu prüfen Sie vorab mit RewriteCond %{HTTP_HOST}, ob der Aufruf über die alte Domain (mit oder ohne www, Flag [NC]) hereinkommt:

RewriteEngine On
# Ordner /blog/ samt Unterseiten auf /ratgeber/ weiterleiten
RewriteRule ^blog/(.*)$ https://example.de/ratgeber/$1 [R=301,L]

# Alte Domain (mit und ohne www) 1:1 auf neue Domain umleiten
RewriteCond %{HTTP_HOST} ^(www\.)?example\.de$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

Laufen alte Adressen ins Leere, verlieren Sie Platzierungen, die über Jahre entstanden sind. Jede alte Adresse braucht eine Weiterleitung auf ihr inhaltliches Gegenstück, ohne Umweg über eine Zwischenstation.

— Sascha Fix

Vermeiden Sie bei Domain- und Protokollwechseln mehrstufige Ketten, in denen der Server erst von http:// auf https:// und danach in einer zweiten Regel von www. auf die Version ohne www. weiterleitet. Jeder Zwischenschritt kostet unnötig Ladezeit, weshalb die Google Search Central zur Website-Verschiebung (Stand 9. September 2026) ausdrücklich die direkte Weiterleitung zum Endziel oder höchstens 3 bis 4 Weiterleitungssprünge (Hops) empfiehlt. Zwar folgt der Googlebot laut derselben Richtlinie technisch bis zu 10 Hops in einer Kette, doch über das Flag [OR] bündeln Sie deshalb RewriteCond %{HTTPS} !=on und den www-Hostnamen direkt zu einem einzigen 301-Sprung.

Wenn der Browser nach der SSL-Umstellung trotz richtiger Adresse vor unsicheren Elementen warnt, zeige ich im Leitfaden, wie Sie unverschlüsselte HTTP-Ressourcen nach der SSL-Umstellung bereinigen. Beachten Sie beim Wechsel auf eine andere Domain außerdem die Google Search Console (GSC): Das Adressänderungstool benötigen Sie laut Google Search Central ausschließlich bei einem Wechsel der Domain oder Subdomain. Bei Pfadwechseln genügt die .htaccess. Die folgende Übersicht fasst die vier wichtigsten Muster zusammen:

In welcher Reihenfolge müssen die Weiterleitungsregeln stehen?

Der Apache-Webserver arbeitet Weiterleitungsregeln in der .htaccess streng von oben nach unten ab, weshalb spezifische Einzelregeln immer vor allgemeinen Ordner- oder Domainregeln stehen müssen. Auf einer Website mit WordPress platzieren Sie sämtliche eigenen Weiterleitungen zwingend oberhalb der Markierung # BEGIN WordPress, weil die interne Standardregel sonst jede Anfrage zuerst abfängt.

Für mod_alias und mod_rewrite gilt laut Apache-Dokumentation (Stand 2026) bei jedem Aufruf derselbe Ablauf: Der erste Treffer gewinnt immer, und spezifische Pfade gehören deshalb nach oben. Wenn Sie also das Verzeichnis /leistungen/ insgesamt auf /angebot/ umleiten, gleichzeitig aber die spezielle Unterseite /leistungen/seo-beratung/ auf /seo/ schicken wollen, muss die Einzelregel oberhalb der Ordnerregel stehen. Drehen Sie die Reihenfolge um, greift bereits die Ordnerregel für /leistungen/ und schickt den Besucher nach /angebot/seo-beratung/, noch bevor Apache die Einzelregel überhaupt erreicht.

In einer WordPress-Installation entscheidet die Position über jeden Treffer: Der Block zwischen # BEGIN WordPress und # END WordPress übergibt laut WordPress Advanced Administration Handbook (Abschnitt zu Apache HTTPD und .htaccess, Stand 14. Oktober 2026) jede virtuelle Adresse über RewriteRule . /index.php [L] an PHP. Wegen des [L]-Flags beendet Apache den Durchlauf an dieser Stelle sofort, sodass unterhalb davon keine Weiterleitung mehr greift. Außerdem überschreibt WordPress beim Speichern der Permalinks alles zwischen seinen Markern. Reine Ladezeit-Regeln können dagegen problemlos unter # END WordPress stehen – wie Caching-Header in der .htaccess das wiederholte Laden beschleunigen, erkläre ich separat:

# ZONE 1: HTTPS und Domain ohne www in einem Sprung erzwingen
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.de$ [NC]
RewriteRule ^(.*)$ https://example.de/$1 [R=301,L]

# ZONE 2: Spezifische Einzelseiten vor allgemeinen Ordnerregeln
RewriteRule ^leistungen/seo-beratung/?$ https://example.de/seo/ [R=301,L]

# ZONE 3: Allgemeine Ordner-Umleitungen
RewriteRule ^leistungen/(.*)$ https://example.de/angebot/$1 [R=301,L]

# ZONE 4: WordPress-Standardblock (nicht innerhalb der Marker ändern)
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Wie prüfen Sie, ob die Weiterleitung wirklich mit 301 antwortet?

Ob Ihre Weiterleitung den Statuscode 301 und die richtige Zieladresse liefert, prüfen Sie am zuverlässigsten per Kommandozeile mit dem Befehl curl -sI oder im Netzwerk-Tab der Browser-Entwicklerwerkzeuge bei deaktiviertem Cache. Ein normaler Seitenaufruf im Browser täuscht beim Testen leicht, weil Browser permanente 301-Weiterleitungen lokal zwischenspeichern und geänderte Regeln dann ignorieren.

Warum reicht ein Blick in die Adresszeile des Browsers nicht aus? Der Browser merkt sich falsche Ziele, denn eine 301-Antwort ist nach dem HTTP-Standard RFC 9110 (Abschnitt 15.4.2, Juni 2022) standardmäßig zwischenspeicherbar. Wenn Sie beim ersten Versuch eine fehlerhafte Zieladresse eingetragen und im Browser geöffnet haben, speichert er diese Umleitung lokal ab. Selbst wenn Sie die .htaccess auf dem Server Sekunden später korrigieren, leitet Ihr Browser Sie deshalb weiter aus seinem eigenen Cache um.

Sie prüfen Ihre Regel deshalb im Terminal mit curl direkt am Server: Der Schalter -I (--head) ruft laut offiziellem Handbuch (Version 8.23.0, Stand Oktober 2026) nur die HTTP-Header ab, während -s die Fortschrittsanzeige ausblendet. Da curl ohne -L keiner Weiterleitung folgt, sehen Sie exakt den ersten Antwort-Schritt Ihres Servers mit dem Statuscode 301 und der Zeile Location:. Rufen Sie danach auch diese Zieladresse einmal mit curl -sI ab. Erst bei 200 steht die Weiterleitung:

curl -sI https://example.de/kontakt-alt
# Erwartete Antwort: HTTP/1.1 301 Moved Permanently + Location: https://example.de/kontakt/

Warum landet Ihre Weiterleitung auf einem 404 oder in einer Schleife?

Landet Ihre Weiterleitung auf einer 404-Fehlerseite, verhindert entweder ein führender Schrägstrich im Suchmuster einer RewriteRule den Treffer oder die Regel steht erst unterhalb des WordPress-Blocks. Eine Endlosschleife entsteht dagegen, wenn die neue Zieladresse erneut auf das eigene Suchmuster passt oder die Domain-Umleitung im Hosting-Panel den Regeln in der .htaccess widerspricht.

Wenn Sie beim Testen mit curl -sI trotz eingetragener Regel weiterhin den Statuscode 404 erhalten, hat Apache Ihre Zeile beim Durchlauf übersprungen. Dahinter stecken drei typische Ursachen: Entweder steht ein führender / im RewriteRule-Muster, die Zeile liegt erst unterhalb von # BEGIN WordPress, oder ein fehlendes [L]-Flag erlaubt nachfolgenden Regeln, die Ziel-URL weiter zu verändern.

Wenn der Browser dagegen ERR_TOO_MANY_REDIRECTS meldet, trifft entweder ein zu breites Ordnermuster wie /shop/(.*) auch auf das neue Ziel /shop/neu/$1 zu, oder die Domain-Umleitung im Hosting-Panel widerspricht Ihrer .htaccess. Beide Ebenen schicken sich dann im Kreis. Wie Sie typische Weiterleitungsschleifen nach Server- und Domainumzügen systematisch beheben, zeige ich in einer eigenen Fehleranleitung.

Ein dritter Fehler legt nach dem Hochladen die gesamte Website mit einem 500 Internal Server Error lahm. Das passiert vor allem, wenn Sie ältere .htaccess-Vorlagen aus Foren kopieren, in denen neben den Weiterleitungen noch PHP-Anweisungen wie php_value oder php_flag stehen. Diese Direktiven funktionieren in der .htaccess laut offiziellem PHP-Handbuch (Kapitel zum Ändern von Konfigurationseinstellungen, PHP 8.5, Stand 2026) ausschließlich mit dem alten Apache-Modul mod_php. Unter PHP-FPM bricht der Server dagegen sofort ab. Falls Ihr Webspace bereits blockiert, lesen Sie nach, wie Syntaxfehler in der .htaccess einen internen Serverfehler auslösen und wie Sie sie reparieren.

Wie lange müssen Weiterleitungen bestehen bleiben?

Permanente 301-Weiterleitungen sollten nach einer Adressänderung oder einem Website-Relaunch laut Google Search Central mindestens ein Jahr lang aktiv bleiben, damit Suchmaschinen alle Signale auf die neuen Adressen übertragen. Solange externe Websites, Lesezeichen oder Verzeichnisse noch auf Ihre alten Pfade verweisen, lassen Sie die Regeln am besten dauerhaft in der Konfiguration.

Google crawlt tiefe Unterseiten deutlich seltener als Ihre Startseite. Deshalb gibt die Google Search Central in ihrer Dokumentation zur Website-Verschiebung (Stand 9. September 2026) als feste Richtlinie vor, Weiterleitungen generell mindestens für ein Jahr beizubehalten. Parallel dazu muss auch das Canonical-Tag im HTML-Kopf ab dem ersten Tag auf die neuen Zieladressen zeigen.

Wenn Sie dabei nicht nur Pfade ändern, sondern den Server wechseln, lassen Sie den alten Hosting-Vertrag nach dem Umzug noch zwei bis vier Wochen als Sicherheitsnetz weiterlaufen. Kündigen Sie das Althosting also nicht sofort, damit Besucher mit zwischengespeicherten DNS-Einträgen nicht ins Leere laufen. Wie Sie anschließend Indexierungsfehler und 404-Meldungen nach URL-Änderungen in der Search Console überwachen, zeige ich im passenden Handbuch.

Wann lohnt sich ein Weiterleitungsplan vom Fachmann?

Wenige einzelne Seiten oder einen reinen Domainwechsel mit identischer Pfadstruktur richten Sie mit den Vorlagen aus diesem Ratgeber in wenigen Minuten selbst ein. Ändern sich beim Relaunch jedoch Dutzende Unterseiten, Kategorien oder Shop-Adressen gleichzeitig, schützt ein systematischer Weiterleitungsplan vor Ketten, offenen 404-Fehlern und dem Verlust gewachsener Platzierungen in den Suchergebnissen.

Bei einem größeren Relaunch liegt der eigentliche Aufwand nicht im Tippen der Syntax, sondern im sorgfältigen Redirect-Mapping vorab. Wie dieser Schritt in das Gesamtprojekt greift, zeigt meine vollständige SEO-Checkliste für den Relaunch-Ablauf von der Vorbereitung bis zum Go-Live. Noch einfacher ist der Weg, den ich bei jedem eigenen Projekt zuerst prüfe – die bestehenden Adressen beim Systemwechsel gar nicht erst zu ändern.

Bei der Migration meiner eigenen Website im dritten Quartal 2026 habe ich deshalb alle 128 indexierten Seiten der alten Sitemap ohne Weiterleitung unter exakt demselben Pfad belassen, während ich nur zehn bestehende Weiterleitungen aus der alten .htaccess übernommen habe. Dadurch hatte Google nach dem Systemwechsel im Herbst 2026 praktisch alle Seiten in den ersten zwei Tagen neu abgerufen, und nach fünf Tagen waren die Werte in der Search Console eher besser als schlechter.

Anhand dieser vier Kriterien entscheiden Sie, ob Sie die Weiterleitungen selbst in der .htaccess pflegen oder die Planung abgeben:

Wenn Ihre Website mit neuer URL-Struktur online gehen soll – auch wenn eine andere Agentur den Relaunch baut –, übernehme ich diese Planung und Kontrolle in meiner SEO-Relaunch-Begleitung zum Festpreis (Stand Oktober 2026). Bis etwa 50 Unterseiten kostet die komplette Begleitung inklusive Bestandsaufnahme, Weiterleitungsplan, Prüfung am Tag des Livegangs und acht Wochen Monitoring 890 € netto; bis etwa 250 Unterseiten oder mit Online-Shop liegt das Paket bei 1.490 € netto. Falls Ihr Relaunch bereits live ist und die Platzierungen einbrechen, prüfe ich die Weiterleitungen in der Nachprüfung Ihres Relaunchs für 490 € netto. Alle Festpreise gelten zzgl. 19 % USt.

Wenn beim Serverwechsel dagegen alle Adressen gleich bleiben, entfällt der neue Weiterleitungsplan. Dann übernehme ich stattdessen den kompletten Website-Umzug zum neuen Hoster.