Link-Equity bei einer Domain-Aufspaltung erhalten: Redirects und Canonicals

Was bei einer Domain-Aufspaltung schiefgehen kann (einfach erklärt)

Eine Domain-Aufspaltung passiert, wenn ein Teil einer Website auf eine neue Domain verschoben wird, während der Rest auf der alten Domain bleibt. Die Aufteilung erfolgt meist nach Produkt (eine Produktlinie bekommt eine eigene Domain) oder Region (ein Landesbereich zieht auf eine lokale Domain um).

Das Risiko ist klar: Das Web kennt bereits deine alten URLs. Sie haben Backlinks, Historie und Vertrauen. Wenn diese alten URLs plötzlich an die falsche Stelle, an mehrere Stellen oder ins Leere führen, kannst du Ranking-Power verlieren — selbst wenn der Inhalt weiterexistiert.

Backlinks verlieren bei einer Aufspaltung meist aus drei Gründen an Wert:

• Redirects fehlen oder führen auf eine generische Seite (z. B. die neue Startseite), wodurch die Bedeutung des Links verwässert wird.
• Canonicals senden gemischte Signale und sagen der Suchmaschine, eine andere URL sei die „richtige“.
• Interne Links zeigen weiterhin auf die alte Domain, sodass du die alten Adressen immer wieder bestätigst und die Entdeckung der neuen URLs verlangsamt.

Erfolg sieht langweilig aus — und das ist gut: Rankings schwanken kurz, pendeln sich ein; organischer Traffic kehrt zurück; und die Seiten der neuen Domain werden schnell indexiert, ohne viele „Duplicate“ oder „Alternate page“-Probleme.

Die Kernregel, um Autorität bei einer Aufspaltung zu erhalten, ist simpel: Jede alte URL sollte ein klares Ziel haben, das zur Absicht passt. War eine alte Seite ein spezifisches Produkt-Feature, sollte sie auf die passende Feature-Seite der neuen Domain führen, nicht auf eine Kategorie-Seite.

Bevor du etwas bewegst, mache einen schnellen Sanity-Check. Stelle sicher, dass jede wichtige alte URL genau eine geplante neue URL hat, dass die Zuordnung in einem Satz erklärbar ist (gleiches Thema, gleiche Funktion) und dass du keine Situationen schaffst, in denen mehrere alte URLs um dieselbe neue URL „kämpfen“. Bestätige außerdem, dass die alte Site nicht weiterhin stark auf Seiten verlinkt, die nun woanders leben, und dass du eine Möglichkeit hast, wichtige Seiten zu entdecken, die nach dem Start aus dem Index fallen.

Lege den Umfang der Aufspaltung fest, bevor du Redirects anfasst

Domain-Aufspaltungen scheitern am häufigsten, weil der Umfang unklar ist. Bevor du den ersten 301 anlegst, schreibe genau auf, was verschoben wird und was bleibt. Denke in echten Seiten, nicht in Ideen wie „das Produkt“ oder „die EU-Site“. Wenn eine Seite heute Backlinks hat, braucht sie morgen ein klares Ziel.

Fange an, indem du URLs auflistest, die verschoben werden, sowie diejenigen, die auf der aktuellen Domain bleiben müssen (Support-Seiten, Docs, Preis-Seiten, Blogbeiträge und andere wertvolle Landingpages). Hier fängst du auch Grauzonen ab, wie ein gemeinsames FAQ, das beide Teile des Geschäfts bedient.

Wähle dann eine Aufteilungsform, die zur Suchweise der Nutzer und deiner Inhaltsstruktur passt:

• Ordner-Aufteilung: gut, wenn der Bereich bereits unter einem Pfad lebt (example.com/product/). Meist am einfachsten.
• Subdomain-Aufteilung: nützlich, wenn ein Bereich andere Technik oder Teams braucht (product.example.com).
• Neue Root-Domain: stärkste Trennung, aber auch größtes Risiko, wenn die Zuordnung schlampig ist.

Bevor du dich festlegst, bestätige, dass die neue Domain zum Crawlen und Ranken bereit ist. Sie sollte HTTPS nutzen, auf Mobilgeräten schnell genug sein und nicht durch robots-Regeln oder versehentliche noindex-Tags blockiert werden. Richte außerdem Analytics und Search-Tools ein, damit du Vorher-Nachher vergleichen kannst.

Wähle ein kurzes Freeze-Fenster für Inhalts- und URL-Änderungen. Während des Freeze vermeide Umbenennungen, Navigation-Edits und CMS-Migrationen. Eine stabile Ausgangslage macht Probleme leichter erkennbar.

Beispiel: Wenn du einen "/fr/"-Bereich auf eine neue Domain verschiebst, entscheide, ob jede französische Seite mitwandert (inklusive französischer Hilfsartikel) oder nur der Shop. Diese Entscheidung ändert deine Redirect-Map und deine Regeln für interne Verlinkung.

Erstelle das URL-Mapping, das die Bedeutung bewahrt

Dein URL-Mapping ist das Dokument, das darüber entscheidet, ob du Autorität bei der Aufspaltung behältst oder stillschweigend verschenkst. Behandle es wie einen Vertrag: Jede wichtige alte URL muss ein klares Ziel haben.

Fange mit einer Tabelle an, die alle indexierbaren URLs der alten Domain listet, und füge eine Spalte „neue URL“ hinzu. Strebe Eins-zu-eins-Zuordnungen an, wann immer möglich. Wenn das Seitenthema gleich bleibt, sollte das Ziel die engste Entsprechung sein, nicht eine Kategorie oder die Startseite.

Priorisiere zuerst, was am wichtigsten ist: URLs mit bereits vorhandener Autorität und Nachfrage. Ziehe diese an den Anfang der Tabelle, anhand von Daten, die du schon hast (Top-Landing-Pages aus Analytics, Seiten mit Klicks in der Search Console und Listen mit starken Backlinks). Das sind die Seiten, bei denen ein Mapping-Fehler am schnellsten schadet.

Deine Mapping-Tabelle muss nicht schick sein, aber komplett. Die meisten Teams tracken alte URL, neue URL, Seitentyp und Owner, ob die Seite behalten/zusammengeführt/retired wird (mit Grund) und ein einfaches QA-Kästchen zur Testbestätigung.

Behandle Sonderfälle im Vorfeld. Ist ein Produkt eingestellt, leite auf den nächsten Ersatz (oder eine permanente „eingestellt“-Seite), nicht auf eine generische Seite. Werden zwei alte Seiten zu einer neuen, wähle das beste Ziel und plane, wie du die fehlenden Details auf der neuen Seite bewahrst.

Schließe URL-Regeln ab, bevor jemand mit dem Bauen beginnt. Entscheide, wie du mit Trailing Slashes, Groß-/Kleinschreibung und Query-Strings umgehst, und wende einen Standard überall an. Zum Beispiel: zwinge Kleinbuchstaben, einheitliche Trailing-Slash-Regel und entferne Tracking-Parameter, damit sie keine Duplikate erzeugen.

Redirect-Leitplanken, die Backlink-Wert schützen

Bei einer Aufspaltung ziehst du nicht nur Seiten um — du ziehst Vertrauen um, das andere Sites dir bereits gegeben haben. Wenn du diesen Wert erhalten willst, sollten deine Redirects langweilig, direkt und konsistent sein.

Die erste Regel ist simpel: Verwende 301-Redirects für permanente Umzüge. Ein 301 signalisiert Suchmaschinen, dass der Umzug endgültig ist und hilft, Ranking-Signale zu übertragen. Ein 302 ist für temporäre Umzüge und verlangsamt oft die Wertübertragung.

Gute Redirects respektieren außerdem die Nutzerintention. War eine alte URL eine Preis-Seite, sollte sie auf die engste Preis-Seite der neuen Domain führen, nicht auf die Startseite. Alles auf eine Seite zu schicken wirkt oft wie ein Soft-404 und verschwendet die Relevanz des ursprünglichen Backlinks.

Nutze diese Leitplanken:

• Redirecte jede indexierbare alte URL zur bestpassenden neuen URL.
• Halte es bei einem Schritt: alte URL direkt zur finalen URL (keine Ketten).
• Teste auf Schleifen (A zu B, dann zurück zu A) bevor du live gehst.
• Mische keine Signale: vermeide, eine URL zu redirecten, die gleichzeitig ein Canonical auf eine andere Seite zurückgibt.
• Belasse Redirects langfristig, gemessen in Monaten und Jahren, nicht Wochen.

Beispiel: Wenn dein EU-Produkt auf eine neue Domain wandert, sollte ein alter Blog-Review-Link zu /eu/product-x auf die neue /product-x (EU)-Seite weiterleiten, nicht auf eine generische /eu-Landingpage.

Canonical-Regeln für geteilte Sites

Canonicals sind deine Signale „das ist die Hauptseite“. Bei einer Aufspaltung helfen sie Suchmaschinen, sehr ähnliche Seiten über zwei Domains hinweg nicht als Duplikate zu behandeln. Falsch eingesetzt können sie aber auch verhindern, dass die neue Domain rankt.

Verwende rel=canonical, wenn zwei URLs im Wesentlichen denselben Inhalt haben (gleiches Produkt, gleicher Text, gleiche Absicht) und du eine bevorzugte Version indexiert haben möchtest. Nutze es nicht als Ersatz für einen Redirect. Wenn eine Seite wirklich verschoben wurde, ist ein 301 oft das klarere Signal.

Eine häufige Falle ist das Vermischen von cross-domain-Canonicals mit Redirects, sodass sie sich gegenseitig aufheben. Wenn alte-domain Seite A per 301 zu neue-domain Seite B weiterleitet, darf Seite B nicht per Canonical auf Seite A verweisen. Das erzeugt widersprüchliche Anweisungen.

Auf der neuen Domain solltest du selbstreferenzierende Canonicals auf den Seiten setzen, die indexiert werden sollen. Das reduziert das Duplikat-Risiko durch Parameter, Sortierungen, Tracking-Tags oder alternative Pfade. Es macht Audits außerdem einfacher, weil jede wichtige Seite auf sich selbst als bevorzugte Version zeigt.

Halte URL-Versionen konsistent, damit Canonicals die Signale nicht aufsplitten:

• Nur HTTPS
• Ein Host (www oder non-www)
• Einheitlicher Trailing-Slash-Stil
• Indiziere nicht sowohl saubere URLs als auch Parameter-Versionen

Beispiel: Du ziehst /product/x auf eine neue Domain. Die alte URL 301t zur neuen URL. Die neue Seite hat ein self-canonical auf ihre bevorzugte HTTPS-Version. Interne Links und Sitemaps zeigen nur auf diese bevorzugte URL, nicht auf Alternativen.

Leitplanken für interne Verlinkung nach der Aufspaltung

Externe Backlinks bekommen die meiste Aufmerksamkeit, aber interne Links bestimmen, wo Crawler Zeit verbringen und welche Seiten als „wichtig“ erscheinen. Behandle interne Verlinkung wie eine kontrollierte Übergabe, nicht wie ein langsames Ausfransen.

Beginne mit den größten internen Signalen: Navigation, Footer, Header-Utility-Links und siteweite Promos. Diese Links erscheinen auf jeder Seite, sodass ein falsches Ziel Nutzer (und Bots) lange nach der Umstellung zur alten Domain zurückschicken kann.

Eine praktische Regel: Verschobene Seiten sollten auf die neue Domain-Version verschobener Inhalte verlinken und auf der alten Domain verbleibende Inhalte intern auf der alten Domain. Vermeide „halbverschobene“ Pfade, die zwei konkurrierende Routen zum Gleichen erzeugen.

Konzentriere dich in der ersten Runde auf:

• Navigation, Footer, Breadcrumbs und Kategorie-Pfade
• Kontextuelle Links im Body (Blogposts, Hilfeartikel, Vergleichsseiten)
• Entfernen alter Domain-Links, die Nutzer in der verschobenen Sektion im Kreis führen statt überzusetzen
• Separate XML-Sitemaps veröffentlichen (je eine pro Domain)

Beispiel: Wenn du eine "/eu/"-Region auf eine neue Domain verschiebst, stelle sicher, dass Breadcrumb und Header jeder EU-Seite die neue Domain auswählen, während US-Seiten intern auf US-Inhalte verlinken. Lass nicht zu, dass ein globaler Footer weiter auf alte EU-Seiten verweist „weil es einfacher ist“.

On-Page- und technische Konsistenz-Checks

Eine Aufspaltung kann in Bezug auf Redirects perfekt aussehen, aber trotzdem Wert verlieren, wenn die neuen Seiten nicht wie echte Ersatzseiten wirken. Suchmaschinen vergleichen Absicht, Seitenlayoutsignale und technische Hinweise über beide Domains.

Gestalte die verschobenen Seiten konsistent in ihrer Präsentation. Nutze ein einheitliches Template für Titel, H1s und Meta-Descriptions, damit die neue Domain nicht plötzlich wie eine andere Seite für dieselbe Suchanfrage wirkt. Formuliere natürlich, aber behalte die Rolle der Seite (Produktseite bleibt Produktseite, Standortseite bleibt Standortseite).

Bedeutung zählt mehr als das Wort-für-Wort-Matching. Wenn die alte Seite „Preis- und Plandetails“ beantwortete und die neue Seite nur eine schlanke Signup-Seite wird, bitte Google dann, die Zielintention als anders zu werten.

Führe einen strengen technischen Check auf der neuen Domain durch:

• Structured Data: bestätige, dass alle URL-Felder (wie "url", "@id", "logo") auf die korrekte Domain und die bevorzugte Seitenversion zeigen.
• Canonical-Tags: prüfe, dass jede verschobene Seite self-canonical zur neuen URL hat (sofern nicht absichtlich anders).
• Hreflang: falls genutzt, stelle sicher, dass Sprach-/Region-Alternativen auf die richtige Domain für den jeweiligen Markt verweisen.
• Indexierungs-Kontrollen: bestätige, dass robots-meta und X-Robots-Tag nicht versehentlich auf noindex stehen.
• Medien und Scripte: stelle sicher, dass wichtige Assets laden und nicht blockiert sind.

Beispiel: Wenn du /uk/support auf eine neue UK-Domain verschiebst, sollte die neue Seite dieselbe Support-Absicht behalten, nicht in ein Sales-Pitch umschwenken. Behalte FAQ und Kontaktoptionen, aktualisiere Structured-Data-URLs und lass Hreflang auf die UK-Domain für en-GB zeigen, während andere Regionen auf ihre richtigen Homes verweisen.

Ein realistisches Aufspaltungsbeispiel (Produkt oder Region)

Beispiel 1: Eine Produktlinie auf eine neue Marken-Domain verschieben

Ein SaaS-Unternehmen hat eine Hauptseite (example.com). Mit der Zeit wird ihr „Analytics“-Produkt zu einer eigenständigen Marke, daher ziehen sie es auf eine neue Domain (analyticsbrand.com). Ziel ist es, Autorität aus Reviews, Partnerseiten und alten Blogerwähnungen zu bewahren, die bereits auf example.com verlinken.

Die einfache Regel lautet: Ist eine Seite hauptsächlich über das Analytics-Produkt, bekommt sie eine Eins-zu-Eins-Weiterleitung zur engsten passenden Seite auf der neuen Domain. Ist die Seite allgemeiner (Unternehmensnachrichten, Recruiting, nicht-Analytics-Dokumentation), bleibt sie auf example.com.

Typische Mapping-Entscheidungen:

• Produktseiten: example.com/analytics/features -> analyticsbrand.com/features
• Preise: example.com/analytics/pricing -> analyticsbrand.com/pricing (nicht zur Startseite leiten)
• Blogposts: Beiträge über allgemeine SEO-/Produktstrategie bleiben auf example.com; reine Analytics-Tutorials leiten zur neuen Domain
• Support-Dokumente: nur die Docs weiterleiten, die klar zum Analytics-Produkt gehören; gemeinsame Plattform-Dokumente bleiben auf der Ursprungsdomain
• Vergleichsseiten: weiterleiten, wenn der Vergleich das Analytics-Produkt behandelt; sonst interne Links anpassen und die Seite dort belassen, wo sie besser passt

Gemeinsame Ressourcen brauchen besondere Vorsicht. Bei Bildern und PDFs entscheide eine „Owner“-Domain. Bleiben Dateien auf example.com, sorge dafür, dass die neue Site sie konsistent referenziert und keine Ketten entstehen (alte URL -> Zwischenlink -> final). Für gemeinsame Seiten wie rechtliche Hinweise oder Sicherheitsinformationen wähle eine kanonische Version und verlinke von der anderen Site darauf, anstatt zwei konkurrierende Kopien zu veröffentlichen.

Beispiel 2: Eine Länderseite auf eine regionale Domain verschieben

Wenn du example.com/de/ auf example.de verschiebst, behandle jede Locale-URL als eigenes Mapping-Projekt. Halte Sprache und Absicht übereinstimmend: Deutsche Produktseite zu deutscher Produktseite, nicht zu einem englischen Fallback.

Häufige Fehler, die existierende Backlinks verschwenden

Die meisten Backlink-Werte gehen bei einer Aufspaltung aus einem einfachen Grund verloren: Der Move wirkt für Suchmaschinen unklar. Ziel ist es, eine konsistente Botschaft zu senden: was verschoben wurde, wo es jetzt lebt und welche Version ranken soll.

Ein häufiger Fehler ist, beide Domains live zu starten, ohne eine vollständige URL-Map. Teams beginnen „so nach und nach“ zu redirecten und wichtige Seiten werden übersehen. Meist sind das genau die Seiten mit den besten Backlinks, wie alte Produktdokus, Vergleichsseiten oder regionale Landingpages.

Ein weiterer Klassiker ist das Redirecten aller Seiten zur neuen Startseite. Das wirkt zwar sicher, zerstört aber Relevanz. Verlinkte technische Blogs, die auf eine bestimmte Feature-Seite verwiesen, geben durch eine Weiterleitung zur Startseite kein sinnvolles Signal mehr über den ursprünglichen Inhalt.

Achte auf diese Muster:

• Keine Eins-zu-eins-URL-Zuordnung vor dem Launch
• „Catch-all“-Redirects zur Startseite statt passender Zielseiten
• 301-Redirects auf Seite B, während das Canonical auf Seite B auf Seite A zeigt
• Interne Links zeigen weiterhin auf die alte Domain
• URL-Struktur ändern und Inhalte gleichzeitig umschreiben

Widersprüchliche Signale sind besonders kostspielig. Wenn z. B. /product/widget auf der alten Domain per 301 zu newdomain.com/widget weiterleitet, die neue Seite aber per Canonical auf die alte URL zeigt (oder auf einen anderen Pfad), bittest du Google effektiv, deinen Redirect zu ignorieren.

Monitoring-Checkliste für die ersten 30–90 Tage

Eine Aufspaltung ist nicht „fertig“, sobald Redirects live sind. Die nächsten 30–90 Tage sind die Phase, in der Suchmaschinen deine Änderungen testen — und kleine Fehler können still Autorität abziehen.

Sichere dir eine Basislinie aus der Woche vor dem Launch: Top-Organische-Landingpages, eine kleine Menge Prioritäts-Keywords und die am meisten verlinkten URLs. Vergleiche später alles damit.

Wöchentliche Prüfungen (auf beiden Domains)

Führe in den ersten vier Wochen dieselbe Routine jede Woche durch, danach alle zwei Wochen bis Tag 90:

• Index-Coverage und Crawl-Fehler: achte auf Anstiege bei „Not found (404)“, Redirect-Fehler oder plötzliche Rückgänge indexierter Seiten.
• Am meisten verlinkte Seiten: bestätige, dass jede von ihnen nach einem sauberen Redirect auf die beabsichtigte neue Seite zeigt (nicht auf die Startseite).
• Rankings: tracke eine kleine Menge Queries, die zum verschobenen Produkt/der Region gehören, plus einige Brand-Queries.
• Organische Landingpages und Traffic: vergleiche, welche Seiten jetzt Besuche bekommen vs. vorher.
• Redirect-Ketten und 404s: finde „A zu B zu C“-Redirects, Schleifen und alte URLs, die 404 zurückgeben.

Schaue dann auf die Geschichte, die die Daten erzählen. Wenn z. B. deine alte "/pricing" stark verlinkt war und jetzt zu einer generischen "/plans"-Seite leitet, Rankings fallen und Verweildauer sinkt, ist das ein Zeichen, dass das Ziel die Absicht nicht trifft. Das Ziel anzupassen stellt oft die Performance schneller wieder her als Abwarten.

Rote Flaggen, die am selben Tag behoben werden sollten

Behandle diese als dringend:

• Eine stark verlinkte Seite leitet zur Startseite oder zu einer irrelevanten Kategorie
• Viele 404s auf URLs, die früher Links oder Traffic hatten
• Ein plötzlicher Anstieg indexierter alter-Domain-URLs, die eigentlich weiterleiten sollten
• Wichtige URLs mit Ketten länger als ein Hop

Nächste Schritte: stabilisieren, dann Autorität aufbauen

Nach einer Aufspaltung ist die erste Aufgabe Stabilität. Halte Dinge lange genug ruhig, damit Google und Nutzer die neue Struktur lernen. Dann beginne mit Wachstum.

Ein einfacher Zeitplan:

• Pre-Launch (1–2 Wochen vorher): Freeze großer Inhaltsänderungen, bestätige deine Redirect-Map final und stelle sicher, dass die neue Domain saubere indexierbare Seiten hat (keine versehentlichen noindex, keine blockierten Ordner). Mach eine letzte Runde, dass Schlüssel-Seiten auf der neuen Domain die richtigen internen Links haben.
• Launch-Woche: Schalte Redirects live, update interne Links und überwache die Basics täglich (Crawl-Fehler, Redirect-Schleifen, plötzliche Traffic-Abfälle, Seiten, die im falschen Index landen). Erwarte etwas Ranking-Wackeln.
• Wochen 2–4: Behebe Muster, keine Einzelfälle. Erweitere Redirect-Abdeckung, ersetze Startseiten-Redirects durch spezifische Ziele und halte Inhalte größtenteils stabil, während sich Signale setzen.
• Monate 2–3: Sobald die Indexierung stabil aussieht, beginne wieder mit Verbesserungen (Inhalt, UX, Geschwindigkeit). Dann kannst du sicher neue interne Link-Pfade testen und neue Seiten auf der neuen Domain hinzufügen.

Behalte „Catch-all“-Redirects nur als temporäre Sicherheitsnetze, und ersetze sie anschließend durch Seiten-zu-Seite-Redirects, sobald du weißt, welche Seiten Bots und Nutzer tatsächlich treffen. Wenn ein Partner Monate später noch immer auf eine alte URL verlinkt, keine Panik — lass die Redirects langfristig bestehen, damit späte Links weiterhin Wert an die neue Site weiterreichen.

Selbst mit sauberen Redirects und Canonicals braucht eine neue Domain oft frische Signale. Wenn du planst, nach dem Move hochwertige Backlinks hinzuzufügen, mache das erst, wenn die Aufspaltung stabil ist, damit diese Links die richtigen Seiten stärken. Für Teams, die direkte Platzierungen auf autoritativen Sites wollen, ist SEOBoosty (seoboosty.com) eine Option: Du wählst Domains aus einem kuratierten Bestand und richtest Backlinks auf die spezifischen neuen Seiten, die du ranken möchtest.