Transkript:
Du hast für jedes Land eine eigene Domain und überlegst nun, ob es Sinn hat, diese auf einer generischen Domain zusammenzufassen. Dann solltest du dieses Video nicht verpassen. Dranbleiben! Hi und herzlich willkommen! Mein Name ist Andor Palau und ich helfe als SEO Beratern, Publishern, Shops, Marktplätzen und B2B Unternehmen dabei, dass sie durch eine Verbesserung ihrer technischen Infrastruktur, durch eine bessere strategische Ausrichtung und auch durch die Optimierung von internen Prozessen mehr Reichweite in der organischen Suche erzielen. In dieser Videoreihe gehe ich immer kurz auf eine Frage ein, die mir klassischerweise im Rahmen meiner Beratungstätigkeit gestellt wird. Und die Frage, um die es sich heute dreht, ist. Was würde ich machen? Bzw. Worauf würde ich achten, wenn ich mehrere Domains auf eine generische Top Level Domain zusammenziehen müsste? Und das ist eine super spannende Frage, weil in ihr ehrlicherweise auch so ein bisschen die Furcht mitschwingt, dass bei einem solchen Domainwechsel etwas falsch gemacht werden könnte, was sich dann negativ auf die Reichweite, den Traffic respektive natürlich den Umsatz auswirkt. Und jeder SEO weiß, dass diese Angst auch völlig berechtigt ist. Denn jedes Jahr erleben wir unzählige Migrationen, die einfach katastrophal aus SEO Sicht verlaufen. Daher denke ich, hat es kurz einmal Sinn festzuhalten, worum es jetzt genau geht. Die Annahme ist, dass es sich nur um eine Verschiebung der Inhalte beispielsweise von einer De-Domain auf eine Dot-Com-Domain geht, oder etwas größer gedacht von mehreren unterschiedlichen länderspezifischen Domains auf eine globale generische Domain.
Dieses Szenario bezeichnen wir klassischerweise dann als eine reine Domainmigration, weil es eben keine Änderung am CM System gibt und auch keine Änderungen am Content gibt. Was ich aber in jedem Fall ändert, ist eben die URL Struktur. Würde ich darüber hinaus aber noch beispielsweise im gleichen Zuge das System ändern, mit dem der Content verwaltet wird, oder den Content selbst, dann haben wir eben nicht nur die Domain Migration, sondern eben auch eine System oder eine Content Migration. Und das können dann im schlechtesten Fall quasi drei Migrationen auf einmal sein. Und das ist natürlich deutlich anspruchsvoller und auch risikoreicher. Da wir im heutigen Video aber nur von einer reinen Domain Migration ausgehen, habe ich darauf gemünzt ein paar Punkte zusammengefasst, die man dabei beachten sollte. Der erste Punkt ist, dass wenn ein solcher Wechsel vorgenommen wird, eines der wichtigsten, wenn nicht sogar das wichtigste Thema natürlich ein sauberes Weiterleitungsmanagement ist. Damit alle Signale weitergeleitet werden können, müssen einfach die relevantesten URLs eins zu eins mit einer permanenten Weiterleitung auf die neue Domain übertragen werden. Stichwort 301 Statuscode. Wenn eben keine Änderung an den URLs vorgenommen werden und sich im Grunde nur die Domain ändert, dann lässt sich das in der Regel auch sehr gut mit einer Wild Card Regelung lösen. Selbst wenn man die URLs dann beispielsweise in ein Sprachverzeichnis bündelt. Also das ist eigentlich ganz gut handlebar.
Und auch wenn es Aussagen gibt, dass Google nach circa einem Jahr Weiterleitungen in der Regel eigentlich nicht mehr bräuchte, weil angeblich alle Signale weitergegeben sind, empfehle ich ganz klar die alte Domain oder die alten Domains und die Weiterleitung aktiv zu lassen. Da es vor allem natürlich bei alten Domains eine lange Historie gibt und auch ein umfangreiches und starkes Linkprofil geben kann. Und man möchte ja unter keinen Umständen dieses preisgeben und dafür sorgen, dass Links nicht defekt werden usw. Also wer mich fragt, ich würde die alten Domains natürlich immer behalten, aber eben auch die Weiterleitung auf diesen Domains aktiv lassen. Und bitte klärt vor der Migration ab, was mit euren Bildern und mit euren Bildern URLs ist und ob ihr hier eventuell auch Weiterleitungen vornehmen müsst. Vielleicht habt ihr Glück und es ändert sich nichts, weil ihr ein CDN habt ja, aber in dem Falle, dass sich was ändert, denkt bitte auch an eure Bilder. Der zweite Punkt ist, dass wenn ihr ein internationales Setup habt, ich die URLs in jedem Fall immer in einem Sprachverzeichnis bündeln würde, also je Sprache, ein Verzeichnis beispielsweise: Die Inhalte werden dann eben in einen Slash-De-Slash oder in ein Slash-De-Bindestrich-De-Slash Verzeichnis gebündelt, je nachdem, ob wir jetzt beispielsweise nur auf Sprache oder auf Sprachlandkombination optimieren wollt. Das hat in jedem Fall den Vorteil, dass ihr eine sehr saubere Domainstruktur habt und dass ihr beispielsweise die De-Signale dann eben in einem Verzeichnis bündeln könnt.
Das hat aber auch den Vorteil, dass ihr für jedes dieser Verzeichnisse in der GSC eine Präfix Property anlegen könnt, um so länderspezifische Daten zu bekommen. Ihr müsst allerdings an einer Stelle hier aufpassen, nämlich ob eure URL Struktur am Ende ein Trailing-Slash hat oder nicht. Hat beispielsweise die Startseite der länderspezifischen Version kein Trailing-Slash, dann würden diese Daten in der GSC nicht in die länderspezifische Präfix Property einlaufen, sondern nur in die Präfix Property der www-Domain, weil da am Ende wirklich ein Unterschied macht. Das heißt, wenn ihr darauf achten könnt, achtet bitte darauf, dass eure URL Struktur am Ende ein Trailing-Slash hat, damit auch die länderspezifische Startseite in die länderspezifische Präfix Property bei der GSC mit aufgenommen wird. Der dritte Punkt, auf den ich zumindest einmal kurz eingehen möchte, ist das Hreflang Setup. Sollte es ein solches vorher nicht gegeben haben, weil ihr beispielsweise eben auf länderspezifischen Top Level Domains wart, wo das Geotargeting ja zumindest darüber eigentlich schon gesteuert wurde, ist das nun natürlich auf der generischen Domain wichtiger. Und hier müsst ihr dann eben gucken, ob ihr das Targeting verbessern müsst, indem ihr eben eine klare Länder oder Sprachland Kombination einzieht. Sollte es vorher eines gegeben haben, dann gilt natürlich, dass das auf die neue Domain, auf die neue URL Struktur angepasst werden muss und zwar für alle involvierten Varianten. Weil es ein reziprokes System ist, muss einfach darauf geachtet werden, dass es dann überall geachtet wird. Selbst auf Domains, die ihr nicht mit migriert habt.
Habt ihr nur eine Sprache und wechselt von einer De auf eine Dot-Com ist der Punkt nicht ganz so wichtig, aber habt ihr ein bestehendes Hreflang Setup und ihr transferiert beispielsweise unterschiedliche Länder von diversen CctLDs zu unterschiedlichen Zeitpunkten auf eine generische Dot- Com, dann müsst ihr eigentlich immer wieder das Hreflang Setup auf allen Instanzen anpassen, wann immer ihr eine Umstellung vorgenommen habt. Und das kann Google durchaus auch etwas beschäftigen und durcheinander bringen, weil einfach ein mehrfaches Recrawling nötig wäre am Ende. John Mueller von Google hat ja nicht einmal umsonst gesagt, dass das Hreflang Setup eines der kompliziertesten Konstrukte ist, die Google zu verstehen hat. Und sofern euer System nicht in der Lage ist, die Hreflangs über das HTML auszusteuern, weil beispielsweise die unterschiedlichen Verzeichnisse gar nicht wissen, dass sie miteinander verknüpft werden, dann gäbe es natürlich noch die Möglichkeit, das Ganze über Sitemaps zu steuern. Aber das ist ehrlicherweise ein so großes Thema, das hebe ich mir mal für ein eigenes Video auf.
Der vierte Punkt ist im Grunde nur relevant, wenn die generische Domain, auf die ihr umzieht, schon einmal aktiv betrieben wurde. Sollte das aber der Fall gewesen sein, gilt natürlich auch hier einmal abzuklären, ob und welche Inhalte auf dieser Domain vorher existierten und wie die Performance auf der Domain war und ob es irgendwelche Rückschlüsse dahingehend gibt, dass es hier eine negative Entwicklung beispielsweise auch durch Google Updates gab oder vielleicht sogar mal eine manuelle Maßnahme usw. Das muss abgeklärt werden, bevor der Domainumzug vollzogen wird. Bei diesem Punkt geht es vor allem um die innerpolitischen Entscheidungsprozesse und Kompetenzen, auf die man gegebenenfalls achten muss bei so einem Umzug. Bei vielen sage ich mal KMUs B2Blern mag das nicht viel Reibungspunkte geben, weil die Entscheidungskompetenzen sehr, sehr klar sind und sehr, sehr fokussiert sind. Aber wenn man so ein Thema mal in einem Enterprise Unternehmen denkt, dann ist schnell mal eine Firmenzentrale irgendwo in einem anderen Land und jedes Land hat sein eigenes Verzeichnis, was es verwaltet. Und dann kann so eine Migration schon eine gewisse, auch unternehmenspolitische Komponente haben. Und das sollte man am Anfang nicht unterschätzen. Also auch da bitte rechtzeitig und genug Zeit einplanen, falls der Entscheidungsprozess ein größerer und langwieriger ist. Der fünfte Punkt, an den ich dann denken würde, wäre natürlich, das Disawov-File mitzunehmen, sollte denn eins existieren. Bei älteren Domains sollte man natürlich auch noch mal in die HTTP Property gucken, ob da eventuell auch noch irgendwie was rumlungert, aber in jedem Fall bitte daran denken, dass wenn man das Disawov-File mitnimmt, es nur in einer Präfix Property funktioniert und nicht in einer Domain Property. Und vor allen Dingen, wenn ihr ein System habt oder eine Situation habt, wo ihr aus unterschiedlichen Ländern Domains etwas zusammenzieht, dann kann es auch sein, dass ihr unterschiedliche Disawov-File je Land habt.
Und das müsst ihr dann ehrlicherweise bei einer generischen Domain zusammenziehen, konsolidieren und dann in die www-Property legen, weil ihr das ansonsten nicht für die gesamte Domain ausspähen können. Der sechste Punkt wäre dann sicherzustellen, dass die Sitemaps richtig angepasst sind. Hier muss also sichergestellt werden, dass ich nicht nur die Domainendung ändert, sondern für den Fall, dass ihr die URLs auch in ein Sprachverzeichnis organisiert habt, dass natürlich auch das Sprachverzeichnis dann mit in die URL Struktur in den Sitemaps aufgenommen wird, weil ihr ansonsten natürlich einfach lauter 404 URLs oder Weiterleitungen in der Sitemap erzeugen würdet. Also achtet darauf, dass da wirklich die richtigen URLs drin sind. Und sofern ihr eure URLs in Sprachverzeichnissen organisiert habt, legt auch gleich noch mal je Sprachverzeichnis eine eigene Sitemap ab. Die könnt ihr dann auch in der jeweiligen Property Präfix Property in der GSK hinterlegen für das jeweilige Sprachverzeichnis. Und so könnt ihr noch mal mehr Daten sammeln. Der siebte Punkt wäre dann, gegebenenfalls die robots.txt anzupassen, sofern es keine Systemänderung gab und auch keine länderspezifischen Regeln enthalten waren, muss an der Datei eigentlich vermutlich keine großartige Änderung vorgenommen werden. Aber bitte nicht vergessen, diese mit umzuziehen und zumindest auch die Verweise auf die Site Maps zu aktualisieren, damit einfach auch hier keine falschen Daten an Google übermittelt werden.
Der nächste Punkt ist dann einer, den ich schon beiläufig ein paar Mal erwähnt habe, aber der ist so wichtig, dass er hier seinen eigenen Abschnitt kriegt. Und das sind natürlich die GSC-Properties. Natürlich solltet ihr für die neue Domain die relevantesten Properties vorab einrichten. Das wäre zumindest mal die Domain Property, dann die Präfix-Property für die entsprechende Subdomain. Meist ist das eben eine www-Subdomain und dann die Präfix-Properties. Für die jeweiligen Länderverzeichnisse solltet ihr natürlich das Ganze über Subdomains gelöst haben, dann dafür eben einzelne Präfix Properties. Und falls ihr Sprachlandkombinationen gewählt habt, dann eben dafür die einzelnen Properties. Aber auf jeden Fall nicht vergessen, die GSC-Properties anzulegen. Der nächste Punkt, den ich ansprechen möchte, ist der Sprachwechsler. Sofern ein solcher eingesetzt wird, muss natürlich darauf geachtet werden, dass hier dann auch die neuen und richtigen URLs hinterlegt sind. Je nachdem, wie dieser Wechsler konstruiert ist, also beispielsweise mit richtigen Ahrefs oder vielleicht auch komplett ohne Links, kann sich das am Ende natürlich auf das Crawling der Domain auswirken. So, das war’s von mir. Das war mal ein paar Punkte, an die man denken sollte, wenn man eine reine Domainmigration vornimmt. Und weil wir ja über eine generische Top Level Domain reden und hier alles zusammengezogen haben, habe ich noch einen Bonus mit im Gepäck.
Beim Bonuspunkt geht es dann noch um die Startseite der generischen Domain und um die Frage, wie diese zukünftig genau genutzt werden soll. Und hier müssen wir zwei Fälle unterscheiden. Der erste Fall ist ihr habt nur eine Sprachversion auf der numerischen Domain und der andere Fall ist, ihr habt mehrere Sprachversionen auf der generischen Domain. Solltet ihr nur eine Sprache auf der generischen Domain haben und diese ist in einem Sprachverzeichnis organisiert, dann müsst ihr natürlich nur noch die Frage klären, welche URL jetzt die Startseite ist. Die eine Möglichkeit wäre, ihr nehmt die Startseite der generischen Domain, weil ihr eben nur eine Sprachversion habt. In diesem Falle solltet ihr dann die Startseite des Sprachverzeichnisses beispielsweise mit einer 301 Weiterleitung eben auf die Startseite der Domain wieder zurückleiten, weil ihr ansonsten ja irgendwie Gefahr läuft, da Duplicate Content zu generieren. Wollt ihr es aber genau andersrum machen und die Startseite der neuen Domain ist im Prinzip das Sprachverzeichnis, dann müsst ihr natürlich sicherstellen, dass die Startseite auf die auf das Verzeichnis weitergeleitet wird. Streng genommen handelt es sich dann hier um einen Georedirect. Ja, wo man dann eigentlich mit einer 302 Weiterleitung mit einer temporären Weiterleitung arbeiten müsste. Aber wenn ihr nur eine Sprache habt, braucht ihr euch eigentlich keine Sorgen darum zu machen, dass Google das irgendwie falsch cachen könnte und deswegen was Falsches ausspielt. Insofern seid ihr da wahrscheinlich dann auch mit einer 301 Weiterleitung eigentlich okay. Wenn ihr jedoch mehrere Sprachen auf einer Domain habt, dann stellt sich natürlich die Frage nach dem eben angesprochenen Georedirect und ob es die überhaupt geben soll.
Und auch hier stellt sich dann die Frage, welche Sprache eigentlich die Home bekommen soll. Manchmal sieht man aber auch hier einen globalen Verteiler, also eine Seite, die keiner Sprachversion zugewiesen ist. Oftmals wird aber eben einer der Hauptsprachen ausgewählt und deren Startseite ist dann auch die Startseite der generischen Domain. In diesem Fall muss hier dann wieder auf das Duplikat der Startseite der jeweiligen Sprachversion aufgepasst werden. Es gibt aber auch Fälle, wo die globale Startseite immer eine temporäre Weiterleitung hat in das jeweilige Sprachverzeichnis, aus dem die Anfrage eben kam. Und ganz wichtig in dem Fall bei mehreren Sprachen Google muss alle Versionen crawlen können. Ihr dürft keine harten Georedirect einführen, die den User oder gegebenenfalls sogar den Googlebot zwingen, nur eine Sprachversion zu verarbeiten. Das führt dann zu signifikanten Abstürzen in den jeweiligen Ländern oder den jeweiligen anderen Ländern, weil der Googlebot einfach nicht dorthin kommt. Aber auch das mache ich vielleicht mal noch in einem eigenen Video. So, das war’s für heute für die Folge. Ich hoffe es hat euch gefallen. Wenn ja, dann hinterlasst mir gerne einen Daumen hoch hier. Wenn ihr Fragen oder Anregungen zu dem Thema habt, dann gerne unten rein in die Kommentare. Und ansonsten freue ich mich, euch auch bei einer neuen Folge begrüßen zu können. Macht’s gut.