UrlEdge
Zurück zum Blog
17. Mai 2026 UrlEdge Editorial4 min read

www, Apex und Wildcard-Weiterleitung ohne SEO-Bruch

Host-Normalisierung wirkt klein, bis Root-Domain, www, Subdomains, Pfade und Query-Strings unterschiedliche Regeln bekommen. Eine klare Policy hält die kanonische URL stabil.

Host-Normalisierungskarte, in der Apex, www und Wildcard-Subdomains auf einen kanonischen Host zeigen

Host-Normalisierung klingt nach einer kleinen DNS-Aufgabe. In echten Migrationen wird daraus schnell eine URL-Policy.

Die Geschäftsführung nutzt die Apex-Domain. Das alte System nutzt www. Ein Produkt läuft auf einer Subdomain. Die Agentur hat Wildcard-Weiterleitungen in der Migrationsliste. Eine Kampagne hängt noch UTM-Parameter an alte URLs. Wenn diese Entscheidungen erst beim Launch zusammenkommen, entsteht oft eine Redirect-Kette.

Die Frage ist nicht, ob www oder Apex grundsätzlich besser ist. Die Frage ist: Welcher Host ist kanonisch, und wie folgen alle anderen Varianten dorthin?

Wenn der Host-Wechsel Teil einer größeren Migration ist, beginnen Sie mit der Website-Migrations-Redirect-Checkliste. Dieser Artikel ist enger: Er behandelt die Host-Schicht.

Der Host gehört zur Redirect-Policy

example.de, www.example.de und *.example.de sind operativ nicht identisch.

  • Apex wirkt in Marketingmaterialien oft kürzer.
  • www passt gut zu älteren Hosting-Setups.
  • Subdomains können eigenständige Produkte, Shops oder Docs sein.
  • Wildcards helfen, viele Hostnamen mit einer Regel zu behandeln.

Wichtig ist, die Varianten nicht zufällig laufen zu lassen.

Host normalization map for apex, www, and wildcard subdomains

Den kanonischen Host vor dem Launch entscheiden

Klären Sie früh:

FrageWarum sie zählt
Soll die Website auf Apex oder www leben?Bestimmt die sichtbare kanonische URL
Welche Subdomains sind Aliase?Nicht jede Subdomain darf mitmigrieren
Sollen Pfade erhalten bleiben?Deep Links, Rankings und Bookmarks hängen daran
Sollen Query-Strings bleiben?UTM und Partnerparameter können sonst verschwinden
Gibt es temporäre Ausnahmen?Kampagnen und Launches brauchen manchmal andere Regeln

Wenn diese Antworten unklar sind, entsteht meist eine Kette aus HTTPS, www, Domainwechsel und App-Regel.

DNS löst die Policy nicht

DNS zeigt, wohin Traffic geschickt wird. Der Browser braucht trotzdem eine HTTP-Entscheidung, wenn die sichtbare URL wechseln soll.

Sauber:

http://www.alte-marke.de/preise?utm_source=newsletter
  -> https://neue-marke.de/preise?utm_source=newsletter

Problematisch:

http://www.alte-marke.de/preise
  -> https://www.alte-marke.de/preise
  -> https://alte-marke.de/preise
  -> https://neue-marke.de/preise

Ein Hop ist leichter zu testen, zu erklären und später zu ändern.

Wildcard-Weiterleitung funktioniert bei stabiler Struktur

Wildcard-Regeln sind nützlich, wenn alte und neue Struktur ähnlich bleiben:

alt.example.de/* -> neu.example.de/$1

Das passt, wenn:

  • viele alte URLs erhalten bleiben sollen
  • Pfade strukturell gleich sind
  • nicht für jede Seite eine Regel geschrieben werden soll
  • alte Subdomains nur Aliase sind

Wenn sich die Informationsarchitektur stark ändert, sind explizite Regeln für die wichtigsten URLs sicherer.

Pfad und Query erhalten

Host-Normalisierung darf nicht nur den Host austauschen. Die Anfrage enthält mehr Kontext.

http://docs.alte-marke.de/api?ref=partner&utm_source=email

sollte, wenn die Struktur passt, so enden:

https://neue-marke.de/api?ref=partner&utm_source=email

Das betrifft:

  • SEO-Landingpages
  • Dokumentation
  • bezahlte Kampagnen
  • Affiliate-Links
  • gespeicherte Nutzerlinks

Wenn Pfad oder Query verschwinden, sieht der Redirect technisch korrekt aus und verliert trotzdem Wert.

Mehrere hilfreiche Schichten erzeugen Ketten

Häufige Ursache:

  • HTTP zu HTTPS in einer Schicht
  • www zu Apex in einer anderen
  • Domainwechsel in .htaccess
  • App fügt eine weitere Canonical-Regel hinzu

Das Ergebnis ist http -> https -> www -> final.

Wenn Ihre aktuelle Umgebung so aussieht, prüfen Sie als Nächstes Redirect-Ketten und Loops.

Launch-Matrix testen

Vor Veröffentlichung sollten echte Varianten geprüft werden:

TestBeispiel
Apex Roothttps://example.de/
www Roothttps://www.example.de/
Deep Pathhttps://example.de/preise
Deep Path mit Queryhttps://example.de/preise?utm_source=email
Alter Host mit Pfadhttps://alt.example.de/blog/post-1
Wildcard Subdomainhttps://docs.example.de/guide

Launch QA matrix for canonical host, path preservation, query preservation, and redirect hops

Prüfen Sie:

  • finaler Host ist korrekt
  • Pfad bleibt erhalten
  • Query bleibt erhalten
  • Statuscode passt zur Absicht
  • kein zusätzlicher Hop liegt dazwischen

Wo UrlEdge passt

UrlEdge hilft, wenn Host-Normalisierung als verwaltete Routing-Policy statt als Server-Snippet laufen soll.

Der Vorteil ist eine verantwortliche Stelle für Apex, www, Subdomains, Pfade, Query-Strings und Statuscodes.

FAQ

Sollte ich immer Apex statt www verwenden?

Nein. Beides kann funktionieren. Entscheidend ist, einen kanonischen Host zu wählen und alle Varianten sauber dorthin zu führen.

Kann ich Wildcard-Subdomains mit einer Regel behandeln?

Ja, wenn die Struktur gleich bleibt. Bei stark geänderter Struktur brauchen wichtige URLs explizite Zuordnungen.

Reicht DNS für Host-Normalisierung?

Nein. DNS ist keine sichtbare HTTP-Weiterleitung. Die URL-Änderung passiert in der Routing-Schicht.

Sollten Kampagnenparameter erhalten bleiben?

Meist ja. Attribution lässt sich nachträglich schwer wiederherstellen.

Referenzen

Legen Sie den kanonischen Host einmal sauber fest

Leiten Sie Root, www und Wildcard-Subdomains mit automatischem HTTPS, Pfad-Erhalt und klarer Zielregel weiter.

Free Redirect Service testen

Verwandte Artikel

Alle anzeigen