Eine Webseite, die in unterschiedlichen Ländern und Sprachen über Suchmaschinen auffindbar sein muss, kommt nicht an internationalen SEO-Aspekten vorbei. Nachfolgend gehe ich auf folgende SEO-Aspekte mit internationalen Bezug näher ein:

• Domain-Strategie
• URLs
• Hreflang
• Geo-Targeting
• Nutzer-Lokalisierung
• CDN
• Bilder
• Übersetzte Templates
• Suchmaschinen
• Internationales SEO abseits SEO-Technik

Domain-Strategie

Internationales SEO beginnt schon bei der Wahl einer richtigen Domain-Strategie unter Berücksichtigung von SEO-Aspekten. Hier stellen sich die Fragen, ob man eine ccTLD oder gTLD wählen sollte, wie man mit Sonderzeichen (z.B. chinesisch oder russisch) umgeht und ob Subfolder oder Subverzeichnisse besser sind.

ccTLD oder gTLD?

ccTLD steht für “Country Code Top Level Domain” und ist eine länderspezifische Domain wie .de für Deutschland. Die Vorteile einer ccTLD sind:

• Nutzer kennen die ccTLD ihres Landes
• Nutzer vertrauen ihrer länderspezifischen Domain
• Dies wiederum kann sich positiv auf die Klickrate innerhalb der SERPs auswirken
• Eindeutige geografische Ausrichtung
• Serverstandort irrelevant aus SEO-Sicht
• Webseiten lassen sich ohne große Probleme unterteilen

Nachteile einer ccTLD sind hingegen:

• Es ist mehr Infrastruktur erforderlich
• Manchmal gibt es strikte Anforderungen für ccTLD-Domains

Hinweis: Es gibt einige ccTLDs, die Google nicht immer dem jeweiligen Land zuordnet. Dazu gehören bspw. “.me” oder “.tv”. Grund dafür ist, dass viele Nutzer diese als nicht länderspezifische Domains ansehen. Auf Twitter hab John Müller von Google auch bekannt, dass Google eine ccTLD nicht als gTLD behandelt, nur weil sie auch außerhalb ihres Landes verfügbar ist.

gTLD steht für “Generic Top Level Domain” und ist eine Domain, die keinem Land zugeordnet ist. Zu den gTLDs gehören bspw. .com, .org, .edu, .gov und viele Weitere. Es gibt aber auch generische, regionale Top-Level-Domains wie .eu oder .asia. Diese sind zwar einer geografischen Region zugeordnet, werden von Google aber als gTLD behandelt. Es gibt zudem noch länderspezifische Top-Level-Domains (ccTLDs), die Google aber als gTLD sieht, da sie von Nutzer und Webmaster als generisch angesehen werden. Dazu gehören: .ad, .as, .bz, .cc, .cd, .co, .dj, .fm, .io, .la, .me, .ms, .nu, .sc, .sr, .su, .tv, .tk und .ws.

Die Vorteile einer gTLD sind:

• Alle Backlinks kommen allen Sprachen zugute
• Man muss nicht für jedes Land einzeln Backlinks aufbauen

Großer Nachteil ist hier, dass eine negative SEO-Performance sich auf alle Länder/Sprachen auswirken und somit auch Webseiten-Bereiche in Mitleidenschaft ziehen kann, die grundsätzlich gut performen und gute Ergebnisse liefern. Beispielsweise kann das der Fall sein, wenn ein SEO-Team für den französischen Bereich zuständig ist und hier gute Links aufbaut, während das italienische SEO-Team schadhafte Backlinks generiert.

Bei gTLD kann man nochmal in “gTLDs mit Sprachverzeichnissen” und “gTLDs mit Sprachsubdomains” unterscheiden.

Bei gTLDs mit Sprachverzeichnissen gibt es folgende Vor- und Nachteile:

• Vorteile: Leichte und schnelle Einrichtung, geografische Ausrichtung in der Search Console möglich, geringer Wartungsaufwand
• Nachteile: Nutzer können die geografische Ausrichtung nicht anhand der Domainendung erkennen, ein einziger Serverstandort, Unterteilung von Websites schwieriger

Bei gTLDs mit Sprachsubdomains gibt es folgende Vor- und Nachteile:

• Vorteile: Leichte und schnelle Einrichtung, geografische Ausrichtung in der Search Console möglich, verschiedene Serverstandorte möglich, Webseiten lassen sich ohne Probleme unterteilen
• Nachteile: Nutzer können die geografische Ausrichtung nicht anhand der Domainendung erkennen

ccTLDs sprechen also hauptsächlich aus Usability-Gründen für sich, während gTLD aus SEO-Sicht die bessere Wahl sein könnten. Um es an einem Beispiel zu beschreiben: Ist ein Unternehmen im DACH-Raum tätig und besitzt hauptsächlich Backlinks aus Deutschland, so kommen diese Backlinks bei einer gTLD (z.B. .com) auch Österreich (.com/at/) und der Schweiz (.com/ch/) zugute. Falls man aber domain.de, domain.at und domain.ch als Domain-Strategie gewählt hat, so muss man für jede einzelne Domain separat Backlinks aufbauen. Die reine SEO-Empfehlung wäre hier eine gTLD zu wählen. In der Praxis empfehle ich aber folgende Entscheidungen hinsichtlich Domain-Strategie zu treffen:

• Webseiten mit Warenkörben (also E-Commerce-Seiten bei denen man direkt einkaufen kann) empfehle ich ccTLDs zu wählen. Hier spricht der Vertrauensaspekt der Nutzer eine zentrale Rolle. .com-Shops haben erfahrungsgemäß innerhalb der SERP eine geringere CTR als ccTLDs.
• Corporate Webseiten (Unternehmenswebseiten ohne Warenkörbe) empfehle ich gTLDs einzusetzen. Das betrifft meistens B2B-Webseiten, die es ohnehin schwieriger haben an Backlinks zu kommen als B2C-Webseiten (z.B. E-Commerce-Seiten). Hier profitieren dann alle Länder-/Sprachversionen von allen Backlinks.

Subdomain, Subfolder oder Language-Parameter?

Nachdem man sich für eine ccTLD oder gTLD entschieden hat, wird es etwas komplexer: Soll man Länder- bzw. Sprachversionen der Webseite über Subdomains, Subfolder oder Language-Parameter abbilden? Schauen wir uns zunächst die verschiedenen Möglichkeiten an:

1. Das Land wird über eine ccTLD abgebildet, die Sprache über Subdomain (z.B. fr.domain.ch)
2. Das Land wird über eine ccTLD abgebildet, die Sprache über Subfolder (z.B. domain.ch/fr/)
3. Das Land wird über eine ccTLD abgebildet, die Sprache über Language-Parameter (z.b. domain.ch?language=fr)
4. Bei einer gTLD wird das Land über einen Subfolder abgebildet, die Sprache über Subdomain (z.B. fr.domain.com/ch/)
5. Bei einer gTLD wird das Land über eine Subdomain abgebildet, das Land über Subfolder (z.B. ch.domain.com/fr/)
6. Bei einer gTLD werden Land und Sprache über einen Subfolder abgebildet (z.B. domain.com/ch-fr/ oder domain.com/ch/fr/)
7. Bei einer gTLD wird das Land über Subdomain oder Subfolder abgebildet, die Sprache über Language-Parameter (z.B. ch.domain.com?language=fr oder domain.com/ch?language=fr

Grundsätzlich ist es wichtig, dass es für jede Sprache unterschiedliche URLs gibt. Sollte es nur eine URL geben und sich der Inhalt je nach Nutzer-Aufenthaltsort ändern würde, dann könnte Google den Inhalt nicht indexieren.

Aus SEO-Sicht wird die Wahl meistens auf einen Subfolder fallen. Warum? Interne und externe Links können hierbei ihre Wirkung am besten entfalten. Innerhalb der SEO-Szene herrscht die Vermutung, dass Subdomains seitens Google als eine eigene Domain behandelt werden. Demnach müssten für eine Subdomain eigene Backlinks aufgebaut werden. Zum Thema Language-Parameter: Für Sprachen können diese eingesetzt werden (sehen aber nicht so schön aus wie Subfolder). Passend dazu hat Google auch einen Tweet veröffentlicht: “Language is per-URL (parameters are fine). Geotargeting for countries is per site section (domain, subdomain, subdirectory).” (Zum Tweet). Grundsätzlich sollte man aber auf Language-Parameter verzichten, da diese mehrere Nachteile mit sich bringen: URL-basierte Unterteilung schwierig, Nutzer können die geografische Ausrichtung nicht anhand der URL erkennen, geografische Ausrichtung in der Search Console nicht möglich.

Können Sonderzeichen in Domainnamen verwendet werden?

Grundsätzlich können Sonderzeichen von Suchmaschinen verarbeitet und innerhalb der SERP korrekt dargestellt werden.

Für Domainnamen gilt die gleiche Empfehlung wie für Sonderzeichen in URLs: Möglichst darauf verzichten. Man kann zwar Domains mit deutschen Umlauten oder chinesischen Zeichen registrieren, jedoch gibt es hier bei der Darstellung unschöne Probleme. Bei diesen sogenannten IDN-Domains (Internationalized Domain Names) findet die Kodierung nach dem ASCII-Zeichensatz statt und ist an dem Präfix “xn--” zu erkennen. Nutzer die per Copy&Paste die Domain weiterleiten, erhalten dann nicht saubere Domainnamen. Aus diesem Grund sollte man auf Sonderzeichen verzichten und alles in lateinischen Buchstaben darstellen. Im deutschen werden die Umlaute ä, ö, ü zu ae, oe und ue. Kyrillische Buchstaben und chinesische Zeichen können mit dem lateinischen Alphabet dargestellt werden. Suchmaschinen erkennen diese Umwandlung und können auf die Wörter in korrekter Schreibweise schließen.

Empfehlung: Sonderzeichen im Domainnamen vermeiden und stattdessen mit dem lateinischen Alphabet darstellen. Die Sonderzeichen-Domain sollte aber dennoch registriert werden und kann per Redirect auf den “sauberen” Domainnamen weiterleiten (Beispiel: http://www.亚马逊.cn).

Bez. Groß- und Kleinschreibung muss man sich bei Domains grundsätzlich keine Sorgen machen. Beim Domainnamen und Protokollen beachtet Google nicht die Groß- und Kleinschreibung.

URLs

Bei den URLs geht es um unterschiedliche URLs je Sprache und wie man mit Groß- und Kleinschreibung sowie Sonderzeichen umgehen sollte.

Unterschiedliche URLs für verschiedene Sprachen

Es gibt unterschiedliche Arten wir man verschiedene Sprachversionen bereit stellen kann:

• Cookies: Ist nicht zu empfehlen.
• Browsereinstellungen: Ist nicht zu empfehlen.
• URLs: Das ist die von Google empfohlene Methode. Die einzelnen URLs sollten dann untereinander mit dem Hreflang verlinkt werden.

In einem Webmaster-Hangout ist es aus internationaler SEO-Sicht nicht zwingend erforderlich, eine URL zu übersetzen. Google benötige je Sprache jedoch eine eindeutige URL. Einen SEO-Bonus für die Übersetzung würde es nicht geben, da Keywords in URLs kein starkes Ranking-Signal sind. Man muss jedoch bedenken, dass sich eine Übersetzung (die sowieso die meisten machen) indirekt positiv auf SEO auswirken kann. Eine URL in der jeweiligen Sprache des Nutzers hat positive Auswirkungen auf die User Experience, was wiederum SEO gut kommen kann.

Groß- und Kleinschreibung in URLs

Google kann mit Groß- und Kleinschreibung in URLs umgehen, jedoch sind die URLs https://www.domain.com/hallo/ und https://www.domain.com/HALLO/ für Google 2 unterschiedliche Domains. Grund: Die meisten Server unterscheiden diese URLs und versuchen sie auch so aufzulösen. Sprich: Die beiden beispielhaften URLs können unterschiedliche Inhalte ausspielen.

Aus SEO-Sicht muss man dabei das Thema Duplicate Content beachten: Ist die URL über Groß- und Kleinschreibung aufrufbar, so entsteht Duplicate Content, sofern der gleiche Inhalt vorzufinden ist. Hier sollte man mit Redirects oder Canonicals arbeiten.

URLs sollten grundsätzlich in Kleinbuchstaben sein, da sie auch so von Nutzern abgetippt werden. Zudem ist es einfach sie zu diktieren: “Alles klein!”.

Sonderzeichen in URLs

Für URLs gilt die gleiche Empfehlung wie für Sonderzeichen in Domains: Möglichst darauf verzichten. Sonderzeichen können verarbeitet und in den Suchergebnissen korrekt dargestellt werden. Dennoch gibt es manchmal Probleme und Sonderzeichen werden als UTF8-Kodierung ausgegeben. Somit wirken sie für Nutzer nicht schön. Aus www.domain.com/österreich/ wird dann www.domain.com/%C3%B6sterreich/.

Wenn es um den Einsatz von Akzenten in URLs geht (z.B. kommt dies im Französischen häufig vor), so hat Google mit der Verarbeitung grundsätzlich kein Problem. Auch hier sollte man jedoch testen, wie Google und andere Suchmaschinen damit umgehen.

Bindestrich vs. Unterstrich

Ob man in URLs Binde- oder Unterstriche verwendet ist für die Suchmaschine grundsätzlich egal. Da im Domainnamen Bindestriche vorkommen können, ist es üblich auch in der URL Bindestriche zu verwenden, um konsistent zu bleiben. Wenn es aber um die Kennzeichnen von Land und Sprache in der Verzeichnis-URL geht, so sollte man laut Aussage von John Müller Bindestriche verwenden. In der Google-Dokumentation werden zudem auch die Beispiele mittels Bindestrichen gezeigt.

Hreflang

Das Hreflang ist ein Attribut, welches man als HTML-Element im Head-Bereich, in der XML-Sitemap oder im HTTP-Header platzieren kann. Beim Setzen des Hreflangs signalisiert man Google, dass die Webseiteninhalte in verschiedenen Sprachen und für verschiedene Länder existieren. Somit beugt man Duplicate Content vor und man stellt sicher, dass die jeweiligen Inhalte richtig im jeweiligen Land innerhalb der SERPs ausgegeben werden. Beispiel: Sucht ein Nutzer in Österreich auf google.at nach Inhalten, so stellt man dabei sicher, dass domain.at bzw. domain.com/at/ ausgegeben wird und nicht domain.de bzw. domain.com/de/.

Zudem kann der Einsatz des Hreflangs bei ccTLDs einen Autoritätsboost geben. Wie wir oben gelernt haben, ist der Vorteil einer gTLD (z.B. .com), dass sich die Backlinks auf alle Sprachen- bzw. Länderverzeichnisse auswirken, da es eine Domain ist. Bei ccTLDs kommen verschiedene Domains vor, daher müsste für jedes Land einzeln Backlink-Aufbau betrieben werden. Mit dem Hreflang signalisiert man Google die Zusammengehörigkeit. Beispiel: example.de will auch in Slowenien Fuß fassen und registriert sich example.si. Mit dem Hreflang sagt man Google: “Hey, example.si gehört zu der schon bekannten und von dir beliebten Domain example.de.”

Die Vorteile des Hreflangs sind also:

• Signalisierung der inhaltlichen Verwandschaft
• Bessere Verteilung der Backlink-Power (wird vermutet)
• Vermeidung von Duplicate Content
• Korrekte Ausspielung der Sprach- bzw. Länderversion innerhalb der Google-Sprachversion (z.B. deutsche Inhalte für Deutschland auf google.de ausspielen, deutsche Inhalte für Österreich in google.at ausspielen)

Wie baut man das Hreflang-Attribut ein?
Man kann das Attribut über 3 Wege einbauen:

• XML-Sitemap
• HTTP-Header
• Head-Bereich

Einbindung über XML-Sitemap

Standardmäßig schaut eine URL in der Sitemap folgendermaßen aus:

<url>
<loc>https://www.demirjasarevic.com/</loc>
</url>


Mit einer Hreflang-Answeisung schaut es wie folgt aus:

<url>
<loc>https://www.demirjasarevic.com/</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://www.demirjasarevic.com/en/" />
<xhtml:link rel="alternate" hreflang="de" href="https://www.demirjasarevic.com/" />
</url>


Die erste Hreflang-Anweisung verweist auf die englische Version, die Zweite ist die Selbstreferenzierung, um die Beziehung zueinander zu gewährleisten. So müsste jede URL ausgezeichnet werden. Um beim obigen Beispiel zu bleiben, braucht die EN-Version ebenfalls eine Selbstreferenzierung:

<url>
<loc>https://www.demirjasarevic.com/en/</loc>
<xhtml:link rel="alternate" hreflang="en" href="https://www.demirjasarevic.com/en/" />
<xhtml:link rel="alternate" hreflang="de" href="https://www.demirjasarevic.com/" />
</url>


Bei einer großen Webseite mit vielen Sprachen und Ländern kann das schon viel Code in der XML-Sitemap verursachen. Auf der anderen Seite spart man sich diesen Code jedoch im HTML-Quellcode. Dies führt zu einem besseren Pagespeed. Zudem ist die Bearbeitung einfach, da Anpassungen nur in einer Datei stattfinden müssen und nicht auf zahlreichen Unterseiten. Deshalb empfiehlt sich die Sitemap-Methode insbesondere bei großen Webseiten mit vielen Unterseiten.

Einbindung über HTTP-Header

Die zweite Möglichkeit ist die Einbindung über den HTTP-Header. Vor allem für Nicht-HTML-Elemente ist diese Methode zu empfehlen (z.B. PDFs). In der .htaccess würde der Eintrag folgendermaßen aussehen:

Link: <https://www.demirjasarevic.com/pdf/pdf-deutsch.pdf/>; rel="alternate"; hreflang="de", <https://www.demirjasarevic.com/pdf/pdf-englisch.pdf/>; rel="alternate"; hreflang="en", <https://www.demirjasarevic.com/pdf/pdf-spanisch.pdf/>; rel="alternate"; hreflang="es"
Ob ein Hreflang für ein Nicht-HTML-Dokument eingesetzt wird, kann man über die Chrome Developer Tools prüfen.

Einbindung über Head-Bereich

Der Klassiker:

<link rel="alternate" href="http://www.demirjasarevic.com/" hreflang="de-DE" />

Auch hier muss jede Sprachversion enthalten sein. Sprich alle URLs müssen sich untereinander verlinken.

Was ist bei der Implementierung allgemein zu beachten?

• Seiten, die auf “noindex” sind bekommen kein Hreflang
• Seiten, die per Canonical nicht auf sich selbst, sondern auf eine andere Domain zeigen, bekommen kein Hreflang
• Die URL sollte Absolut und mit der bevorzugten Version (also z.B. mit WWW und HTTPS) angegeben werden
• Die URLs müssen untereinander bidirektional verlinkt werden
• Falls es Nutzer gibt, die nicht durch eine Sprache abgedeckt werden können, kann der Wert “x-default” als Standardsprache angegeben werden
• Die jeweilige Sprache muss im Format “ISO 639-1” (https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes) angegeben werden (der erste Teil der Kennzeichnung; Pflichtangabe)
• Die optionale Länderkennung muss im Format “ISO 3166-1 Alpha 2” (https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2) angegeben werden (der zweite Teil der Kennzeichnung; Optionale Angabe). Hierbei ist zu achten, dass diese nur angegeben werden soll, wenn einen guten Grund dafür gibt. Beispiel: Je Land sind unterschiedliche Informationen notwendig. Ansonsten sei es besser, nur mittels Sprache zu referenzieren, um die Komplexität bei internationalen Webseiten laut Google zu minimieren.

Besonders komplex wird es im Zusammenhang mit hreflangs, wenn neben der Desktop-Version noch weitere Versionen der Website existieren (Mobile, AMP). Hier muss sichergestellt werden, dass die hreflangs unter den gleichartigen Versionen gesetzt werden müssen:

• Desktop zu Desktop
• Mobile zu Mobile
• AMP zu AMP

Zusätzlich müssen aber auch unter den verschiedenen Versionen weiterhin die richtigen Auszeichnungen existieren (Canonicals, Alternate, etc.).

Geo-Targeting

Beim Geo-Targeting geht es darum, dass die Inhalte in der jeweiligen Sprache und im jeweiligen Land ranken. Für Suchmaschinen ist die Ermittlung des Ziellandes wichtig, um den Nutzer zufrieden zu stellen. Inhalte, die für Deutschland gedacht sind sollen auf google.de gefunden werden. Inhalte, die für Österreich gedacht sind, sollen auf google.at gefunden werden und so weiter. Hier gibt es unterschiedliche Möglichkeiten bzw. Ansatzpunkte wie man Suchmaschinen die richtige lokale Zugehörigkeit signalisieren kann.

• Hreflang
• ccTLD
• Sprache des Inhalts
• Eintrag in der Google Search Console
• Lokale Backlinks
• Land aus dem der Traffic stammt
• Server-Standort
• Standort-Meta-Tags

Hreflang
Was Hreflangs sind und wie man diese einbinden kann, haben wir vorhin gesehen. Für Suchmaschinen wie Google sind Hreflangs ein starkes Signal, welche Inhalte in welchem Land Nutzern präsentiert werden sollen. Wichtig ist, dass die Hreflang-Auszeichnung richtig und konsistent ist, da Suchmaschinen diese sonst ignorieren.

ccTLD
Länderspezifische Top-Level-Domains sind ebenfalls ein starkes Signal an Suchmaschinen, wenn es um Geo-Targeting geht. So ist eine .at-Domain für Google ein eindeutiges Indiz, dass die Inhalte für Österreich gedacht sind. Da die Inhalte aber auf Deutsch sind, geht Google zudem davon aus, dass diese auch für Nutzer in DE und CH relevant sein können und versucht die Domain auch für Suchergebnisse in google.de und google.ch zu berücksichtigen.

Sprache des Inhalts
Suchmaschinen schauen sich Inhalte und Navigation an, um die Sprache und daraus resultierend das Zielland zu bestimmen. Hinweis: Sprachinformationen im Code wie das lang-Attribut oder in der URL verwendet Google für die Bestimmung des Ziellandes nicht. Örtliche Adressen und Telefonnummern auf der Webseite oder die Verwendung einer Währung werden jedoch herangezogen.

Eintrag in der Google Search Console
Wenn man über eine generische TLD verfügt, so sollte man die geografische Ausrichtung innerhalb der Search Console angeben, damit sich Google danach richten kann. In einem Webmaster-Hangout erklärte John Müller, dass der Eintrag in der GSC gleichwertig sei, wie der Einsatz einer ccTLD (wenn es um Geo-Targeting geht). Falls die generische TLD aber für mehrere Länder gelten soll, so ist es besser die Einstellung in der Search Console nicht anzupassen.

Lokale Backlinks
Übermäßig viele Backlinks aus einem Land können ebenfalls ein Indiz für die geografische Ausrichtung sein.

Land aus dem der Traffic stammt
Auch der Traffic könnte dazu dienen, das Zielland zu bestimmen. Übermäßig viel Zugriffe aus z.B. Frankreich könnten Suchmaschinen helfen, das Zielland zu bestimmen. Man geht jedoch nicht davon aus, dass Suchmaschinen Traffic-Daten aus z.B. Google Analytics, etc. heranziehen.

Server-Standort
Dieser Hinweis ist nicht eindeutig, da manchmal auch CDNs verwendet werden oder die Webseite wird in einem anderen Land gehostet, da dort die Infrastruktur besser ist. Hierauf sollte man sich also nicht verlassen.

Standort-Meta-Tags
Standort-Meta-Tags wie geo.position, distribution oder auch geografische HTML-Attribute werden seitens Google ignoriert.

Um zu testen, ob das Geo-Targeting erfolgreich war, können 2 Parameter an die Google-Such-URL drangehängt werden:

• hl = hier kommt der Sprachcode rein.
• gk = hier kommt der Ländercode rein.

Mit “https://www.google.com/search?q=suchanfrage&hl=de&gl=at” prüft man, welche Ergebnisse zu “suchanfrage” auf Deutsch in Österreich ausgespielt werden.

Nutzer-Lokalisierung

Wenn ein Nutzer eine Domain aufruft für der es verschiedene Sprachen- und Länderversionen gibt, so hat man verschiedenen Möglichkeiten den Nutzer zu lokalisieren:

• Der Nutzer landet auf der vom ihm eingetippten Domain (z.B. Österreicher gibt domain.de an, es existiert aber domain.at) und er erhält einen Banner, wo ihm mitgeteilt wird, dass es auch die Domain in Österreich gibt. Der Nutzer kann dann wählen, ob der auf domain.de bleibt oder doch zu domain.at navigiert.
• Der Nutzer wird automatisch anhand von IP- und/oder Browsersprache weitergeleitet

Aus SEO-Sicht ist die erste Methode zu empfehlen. Der Grund ist, dass Google oft mit einer US-IP surft. Zwar sagt Google, dass sie das Web aus unterschiedlichen Standorten und Orten auf der Welt zu crawlen, jedoch nicht versuchen, verschiedene Crawler-Quellen für einzelne Webseiten einzusetzen, um mögliche Webseiten-Variationen zu finden. Zudem sendet der Crawler Anfragen ohne Accept-Language im Anforderungsheader. Würde man hier Methode 2 von oben wählen, dann würde man den Googlebot immer auf eine domain.us weiterleiten. Dadurch wird es der Bot schwer haben die Inhalte von domain.de und domain.at zu indexieren. Bei Methode 1 kann man die Auswahl des Nutzers in einem Cookie speichern. Beim nächsten Aufruf werden die Informationen aus dem Cookie gezogen und der Nutzer wird automatisch auf die für ihn passende Domain geleitet. Da Google keine Cookies ausliest, ist diese Methode aus SEO-Sicht in Ordnung. Beim Einsatz des Banners muss man nur darauf achten, nicht gegen die Google Pop-Up-Policy zu verstoßen. Seiten, die einen Pop-Up zeigen, um auf anderen Sprach- und Länderversionen zu verweisen, könnten von Google abgestraft werden (Quelle). Grundsätzlich sollte der Nutzer aber mittels Hyperlinks immer die Möglichkeit haben, zwischen verschiedenen Sprachversionen zu wechseln.

CDN

Dieser Abschnitt wird das Thema CDN nicht von A bis Z beleuchten, sondern nur auf die SEO-relevanten Aspekte eingehen. Dem Thema CDN werde ich einen eigenen Artikel widmen.

Wieso ist ein CDN aus SEO-Sicht wichtig?
Im SEO ist Pagespeed längst ein Ranking-Faktor. CDNs tragen dazu bei, den Pagespeed zu verbessern, indem Nutzern URLs aus geografischer Nähe ausgespielt werden. Einfach ausgedrückt werden dabei Kopien einer Domain auf verschiedenen Servern weltweit abgelegt. Beim Zugriff auf die Webseite wird ermittelt, wo sich der Nutzer befindet und ihn die Webseite vom nächstgelegenden Server zugespielt.

Was muss beim Einsatz eines CDNs aus SEO-Sicht beachtet werden?

• Eine Umstellung auf ein CDN sollte unbedingt mit SEO-Begleitung stattfinden.
• Durch den Einsatz eines CDNs können sich IP, Domain und URLs ändern, je nach CDN-Einstellung.
• Bei IP-Adressen sollten Anycast-IPs verwendet werden.
• Bei der Domain ist wichtig, dass die CDN-Seite auf der eigenen Domain liegt, z.B. auf einer Subdomain (cdn.demirjasarevic.com). Mit Canonicals von cdn.demirjasarevic.com zu demirjasarevic.com vermeidet man zudem Duplicate Content Probleme.
• Bei URLs gilt: Namensänderungen an URLs und Verzeichnissen sowie Änderungen an Verzeichnisstrukturen sollten im Zuge der CDN-Umstellung vermieden werden, damit Bots nicht zu viele Änderungen auf einmal verarbeiten müssen.

Bilder

Auch Bilder spielen bei der internationalen SEO-Strategie eine wichtige Rolle. Dabei gibt es grundsätzlich 2 verschiedene Möglichkeiten:

• Ein Bild für alle Sprachen/Länder
• Pro Sprache/Land ein Bild bereitstellen

Gehen wir davon aus, dass wir eine Unterseite in 5 Sprachen haben. Auf jeder dieser Unterseiten wird das gleiche Bild (z.B. bild.jpg) eingebunden. Man könnte nun die gleiche Datei/URL auf allen 5 Sprachen einbinden. Auf der deutschen, englischen, französischen, italienischen und spanischen Unterseite würde mal also bild.jpg integrieren. Vorteil ist hier, dass nur ein Bild gecrawlt werden muss und man so sein Crawling-Budget effizient gestaltet. Zudem müssen in der Bilder-Sitemap nicht 5 Einträge erfolgen, sondern nur Einer. Für Google ist es jedoch auch kein Problem, wenn man das Bild “übersetzt” (siehe hier). Hier wird also bild.jpg im Englischen zu image.jpg und so weiter. Vorteil ist hier, dass man den Dateinamen für die jeweilige Sprache optimieren kann. Nachteile wären das vorher genannte Thema Crawling-Budget und dass eine Bilder-Sitemap dadurch mit vielen Einträgen angereichert werden muss. Zudem hätte man mehrfach Duplicate Images.

Es kann jedoch Sinn machen, eigene Bilder für die unterschiedlichen Sprachversionen zur Verfügung zu stellen wenn, diese lokalisiert werden müssen. Vor allem wenn es deutliche kulturelle Unterschiede gibt. So kann ein Bild für den deutschen Markt zwar passend sein, für China aber unpassend. In diesem Fall würde es Sinn machen je Sprache und Land unterschiedliche Bilder bereit zu stellen.

Übersetzte Templates

Wie geht man mit mehrsprachigen Websites um, wo das Template übersetzt worden ist, aber nicht der Inhalt? Gehen wir vom folgenden Beispiel aus. Für die Sprachen Deutsch, Englisch und Spanisch existieren folgende URLs:

• domain.com/de/max-mustermann/
• domain.com/en/max-mustermann/
• domain.com/es/max-mustermann/

Gehen wir davon aus, dies wären Seiten, wo die Person “Max Mustermann” vorgestellt wird. Wenn auf diesen Seiten nur das Template (also Header, Navigation, Footer, etc.) in der jeweiligen Sprache übersetzt ist, aber nicht der Hauptinhalt selbst, dann entsteht Duplicate Content. In so einem Fall hat man laut dem Leitfaden “Unifying content under multilingual templates” folgende Möglichkeiten:

• Per Canonical auf die bevorzugte Version zeigen lassen
• 301-Redirects auf die bevorzugte Version einrichten

Suchmaschinen

• Yandex bevorzugt eher lokale Domains wie .ru oder .com.ru
• Ob man eine ccTLD oder gTLD für den russischen Markt wählt, hängt davon ab, welche Suchmaschine die Zielgruppe verwendet
• Google und Yandex teilen sich den Suchmaschinenmarkt in Russland
• Ein Blick in die Google Analytics Daten kann helfen

• Baidu hat keine Präferenz für ccTLD oder gTLD (Beispiel baidu.com oder soku.com)

Bei der Domainendung ist zu beachten, dass diese so gewählt werden soll, dass sie für den Zielmarkt nicht ungewöhnlich ist. Innerhalb der Suchergebnisse kann eine unpassende ccTLD bei Nutzern schnell unglaubwürdig wirken. Das führt zu schlechteren Klickraten, die zu Ranking-Rückgängen führen können.

Internationales SEO abseits SEO-Technik

Neben all den genannten SEO-Technik-Aspekten gibt es grundsätzliche Entscheidungen, die man in der Internationalsierungsstrategie treffen muss. Eine zentrale Frage lautet, ob man die Webseite auf ein Land oder auf eine Sprache optimieren soll? Das Keyword lautet hier “Lokalisierung”, weshalb es unbedingt notwendig ist auf ein Land hin zu optimieren. Jeder Markt muss hier separat behandelt werden. Eine gut optimierte Seite auf Deutsch muss nicht unbedingt in Deutschland, Österreich und Schweiz funktionieren. Neben einzelnen, feinen Unterschieden in der Sprache hat jeder Markt seine eigene Währung, Gewohnheiten, Wettbewerber und Verhaltensweisen. Umso wichtiger ist es, dass man hier mit Muttersprachlern arbeitet, die die Nutzer verstehen. Hier müssen Keywords, Texte und Themen auf den lokalen Markt angepasst werden.

Was automatische Übersetzungen angeht, muss man etwas vorsichtig sein. Automatische Übersetzungen verstoßen bei Google gegen die Webmaster-Richtlinien. Google wies aber auch darauf hin, dass die eingesetzten Technik die Qualität automatischer Übersetzungen deutlich verbessert hat. Um hier einen Spagat zu schaffen, empfiehlt Google folgendes:

• Mit einer oder wenigen Sprachen mit der automatischen Übersetzung beginnen
• Übersetzungen hinsichtlich Qualität überprüfen
• Wenn man “hinter den Inhalten stehen kann”, dann sollte man sie indexieren lassen
• Andere – schwache Übersetzungen – kann man per “noindex” aus dem Index entfernt lassen
• Alternativ kann man schwache Übersetzungen hinter einem JS-Widget auf der gleichen Seite anbieten, um keine separaten Seiten zu erstellen