301-Weiterleitungen per .htaccess: Fehler beim Domainumzug

Wenn Sie nach .htaccess Weiterleitung suchen, wollen Sie meistens zuerst nur ein akutes Problem lösen:

• eine alte URL soll auf eine neue zeigen
• HTTP soll auf HTTPS gehen
• eine Domain soll dauerhaft umziehen

Für einzelne Regeln ist .htaccess oft schnell genug. Genau dort entsteht aber auch das Missverständnis. Was für drei Redirects noch überschaubar ist, wird beim Domainumzug schnell unordentlich.

Die wichtigste praktische Antwort lautet deshalb:

• Für einzelne, stabile 301-Weiterleitungen kann .htaccess ausreichen.
• Für Relaunches, Domainumzüge, Rebrands oder große Redirect-Maps wird .htaccess oft zum Risiko, weil Regeln über viele Dateien, Plugins, Agenturen und Server-Zuständigkeiten verteilt sind.

Wenn Ihr Umzug gerade vorbereitet wird, lesen Sie parallel unsere Website-Migrations-Redirect-Checkliste. Diese hilft beim Gesamtprozess. Dieser Artikel hier fokussiert auf den Punkt, an dem viele deutsche Teams anfangen: 301-Weiterleitungen per .htaccess.

Die kurze Antwort: So sieht eine 301-Weiterleitung in .htaccess aus

Für einen einfachen, dauerhaften Umzug einer einzelnen URL sieht das in Apache häufig so aus:

Redirect 301 /alte-seite https://www.beispiel.de/neue-seite

Für eine komplette Domain-Weiterleitung mit HTTPS und gleichem Pfad wird oft mit mod_rewrite gearbeitet:

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

Das beantwortet aber nur die Syntax-Frage. Die eigentliche operative Frage ist:

[!TIP] Reicht eine Datei mit ein paar Regeln noch aus, oder verwalten Sie in Wahrheit bereits eine Redirect-Migration, die Versionierung, Validierung und Rollback braucht?

Wann .htaccess noch gut funktioniert

.htaccess ist nicht das Problem an sich. Sie ist nur oft das falsche Werkzeug für die falsche Größenordnung.

Gut geeignet ist sie meist, wenn:

• Sie nur wenige Redirects brauchen
• der Apache-Server tatsächlich die einzige Regelquelle ist
• keine zweite Redirect-Schicht über CDN, Proxy oder App-Middleware mitredet
• Pfad-Logik einfach bleibt
• eine Person oder ein kleines Team die Verantwortung klar besitzt

Ein typisches Beispiel:

• alte-domain.de/impressum -> neue-domain.de/impressum
• http://alte-domain.de -> https://neue-domain.de

Solche Fälle lassen sich in .htaccess sauber abbilden.

Wo .htaccess beim Domainumzug kippt

Sobald der Umzug nicht mehr aus fünf Regeln besteht, tauchen fast immer dieselben Probleme auf.

1. Mehrere Regelquellen greifen gleichzeitig

In echten Projekten kommen Redirects oft aus mehreren Schichten:

• .htaccess
• CMS-Plugins
• Nginx oder Load Balancer
• Cloudflare / CDN
• App-Middleware

Dann sieht ein scheinbar harmloser Umzug plötzlich so aus:

http://alte-domain.de/produkt-a
  -> https://alte-domain.de/produkt-a
  -> https://www.alte-domain.de/produkt-a
  -> https://www.neue-domain.de/shop/produkt-a

Technisch "funktioniert" das vielleicht noch. Operativ ist es bereits schlecht.

2. Pfad- und Query-Logik wird unklar

Viele Teams testen nur die Startseite und merken zu spät, dass Deep Links oder Kampagnenparameter nicht sauber ankommen.

Beispiel:

alte-domain.de/pricing?utm_source=newsletter&utm_campaign=launch

sollte nicht einfach auf die neue Startseite fallen. Wenn Pfad- oder Query-Erhalt wichtig ist, lesen Sie ergänzend Domain weiterleiten, ohne Pfade oder UTM-Parameter zu verlieren.

3. Wildcards lösen nicht jede fachliche Zuordnung

/blog/* -> /magazin/* klingt elegant, bis Inhalte zusammengelegt wurden, Produkte weggefallen sind oder Kategorien eine neue Logik haben.

Dann reicht eine grobe Rewrite-Regel nicht mehr. Sie brauchen:

• explizite Zielzuordnungen
• Prioritäten
• Validierung
• eine prüfbare Redirect-Map

4. Änderungen sind schwer reviewbar

Ein Merge in einer Konfigurationsdatei ist keine gute Migrationsdokumentation.

Sobald mehrere Personen am Umzug arbeiten, wollen Sie eigentlich wissen:

• wer welche Regeln geändert hat
• welche Regeln neu sind
• welche Regeln entfernt wurden
• ob der Import fehlerhafte Ziele erzeugt
• wie ein Rollback aussieht

Diese Fragen beantwortet .htaccess allein kaum.

Die häufigsten Fehler bei 301-Weiterleitungen im Domainumzug

Fehler 1: Erst Host, dann HTTPS, dann neuer Pfad

Viele Teams bauen Host-Normalisierung und Migrationsziel in getrennten Schritten. Das erzeugt Ketten.

Schlecht:

http://alte-domain.de/docs/api
  -> https://alte-domain.de/docs/api
  -> https://www.alte-domain.de/docs/api
  -> https://www.neue-domain.de/docs/api

Besser:

http://alte-domain.de/docs/api
  -> https://www.neue-domain.de/docs/api

Wenn Sie solche Hop-Pfade prüfen wollen, nutzen Sie einen Redirect Checker, bevor der Traffic umschaltet.

Fehler 2: Homepage funktioniert, Tiefenpfade nicht

Der Klassiker im Relaunch:

• / funktioniert
• /kategorie/produkt
• /blog/alter-artikel
• /docs/api/v1

landen aber auf 404, auf der falschen Seite oder auf einer generischen Übersichtsseite.

Ein Domainumzug ist erst dann sauber, wenn auch die URLs funktionieren, die echte Nutzer und Google bereits kennen.

Fehler 3: Query-Parameter gehen verloren

Gerade in deutschen B2B- und Ecommerce-Setups werden Kampagnen oft über:

• Newsletter
• Partnerseiten
• Sales-Mails
• Paid Search
• LinkedIn-Kampagnen

gemessen. Wenn utm_-Parameter oder andere Query-Strings verschwinden, wird die Migration nicht nur ein SEO-, sondern auch ein Reporting-Problem.

Fehler 4: Die Redirect-Map bleibt außerhalb der Technik

Oft existiert die "wahre" Migrationsliste in:

• Excel
• Google Sheets
• PM-Notizen
• SEO-Audit-Dokumenten

und nicht dort, wo die Regeln tatsächlich live gehen.

Dann entsteht ein gefährlicher Bruch: Das Fachteam plant URLs, das Technikteam schreibt Regeln, aber niemand sieht früh genug, wo Einträge fehlen oder kollidieren.

Fehler 5: .htaccess wird zum stillen Dauerzustand

Ein Provisorium bleibt länger als gedacht. Erst sind es 20 Regeln, dann 80, dann 400.

Irgendwann weiß niemand mehr sicher:

• welche Regeln noch gebraucht werden
• welche Reihenfolge wichtig ist
• welche Wildcard andere Regeln überschreibt
• ob alte Agentur-Arbeit noch aktiv ist

Das ist meistens der Punkt, an dem Teams nicht noch eine weitere Zeile in .htaccess brauchen, sondern eine andere Arbeitsweise.

Wann Sie von .htaccess zu einem verwalteten Redirect-Workflow wechseln sollten

Ein Wechsel lohnt sich meist, wenn mindestens eines davon zutrifft:

• Sie migrieren hunderte oder tausende URLs
• mehrere Teams oder Dienstleister pflegen Regeln
• Redirects sollen per CSV importierbar sein
• Sie brauchen vor dem Go-live Konfliktprüfung
• Sie möchten Rollback und Versionsstände
• Sie wollen Regeln pflegen, ohne am Origin-Server zu deployen
• Ihre Website liegt teilweise auf Systemen, die Root-Zugriff oder Server-Config erschweren

Genau an dieser Stelle wird UrlEdge interessant:

• Bulk URL Management für große Redirect-Maps
• Redirect Management für Regeln, Prioritäten und Rollout
• Permanent 301 Redirects für dauerhafte Umzüge

Das ersetzt nicht die Migrationsplanung. Es ersetzt aber viel von dem operativen Risiko, das bei wachsenden .htaccess-Setups entsteht.

Ein pragmischer Migrationsansatz für deutsche Teams

Wenn Sie gerade zwischen "wir lösen das schnell in .htaccess" und "wir brauchen etwas Strukturierteres" stehen, gehen Sie so vor:

1. Erst die Redirect-Map fertig machen

Vor jeder technischen Umsetzung brauchen Sie eine belastbare Liste:

old_url,new_url,status,priority,owner,notes
https://alte-domain.de/preise,https://www.neue-domain.de/preise,301,hoch,marketing,Top-Landingpage
https://alte-domain.de/docs/api,https://www.neue-domain.de/docs/api,301,hoch,engineering,Dokumentation

2. Kleine, stabile Spezialfälle separat halten

Einzelne technische Regeln wie eine ganz einfache Host-Normalisierung können weiterhin servernah bleiben, wenn sie sauber kontrolliert werden.

3. Die eigentliche Migrationslogik zentralisieren

Große URL-Mappings, Wildcards, Pfad-Erhalt und Massenänderungen sollten an einer Stelle gepflegt werden, die:

• lesbar ist
• validierbar ist
• von mehreren Rollen verstanden wird

4. Vor dem Switch echte Hop-Tests durchführen

Prüfen Sie nicht nur den Zielhost, sondern konkrete Business-URLs:

• Top-Seiten aus der Search Console
• wichtige Kategorie- und Produktseiten
• Kampagnen-Links
• Doku- und Support-Links

5. Rollback mitdenken

Wenn eine wichtige Regelgruppe falsch ausgerollt wird, sollten Sie nicht erst im Incident überlegen, wie Sie zurückkommen.

Die eigentliche Entscheidung

Die Frage ist nicht, ob .htaccess gut oder schlecht ist.

Die Frage ist:

Ist Ihr Domainumzug noch klein genug für handgepflegte Server-Regeln, oder ist er längst ein Routing-Projekt mit SEO-, Kampagnen- und Team-Abhängigkeiten?

Wenn es Letzteres ist, sollten Sie nicht nur nach einem Snippet suchen. Dann brauchen Sie einen Workflow, der Redirects als produktionskritische Infrastruktur behandelt.

FAQ

Reicht .htaccess für einen kleinen Domainumzug?

Ja, wenn der Umfang klein ist, die Regeln einfach bleiben und Apache wirklich die einzige aktive Redirect-Schicht ist.

Ist .htaccess schlecht für SEO?

Nein. Schlechte Redirect-Architektur ist schlecht für SEO. .htaccess wird nur dann problematisch, wenn Ketten, Konflikte, falsche Ziele oder ungetestete Wildcards entstehen.

Ab wann sollte ich nicht mehr alles per Hand in .htaccess pflegen?

Sobald Sie mit größeren Redirect-Maps, mehreren Stakeholdern, CSV-Listen, Rollback-Anforderungen oder komplexen Migrationspfaden arbeiten, ist eine zentralere Lösung meist sicherer.

Was ist wichtiger: die korrekte Syntax oder die Redirect-Map?

Beides zählt, aber die Redirect-Map entscheidet häufiger über den Migrationserfolg. Die perfekte Syntax nützt wenig, wenn die fachliche Zielzuordnung unvollständig oder falsch ist.