Best Practice für URLs mehrsprachiger Websites

Question

Was wird als beste Strategie für URLs übersetzter Websites angesehen? Was ich häufig sehe, ist:

http://example.com/english-slug.html 
http://example.com/de/english-slug.html 
http://example.com/fr/english-slug.html 

Dies hat den (kleinen) Vorteil, dass ein Benutzer manuell in eine andere Sprache wechseln kann, indem er die URL ändert. Der Nachteil scheint zu sein, dass die URL aus einem Slug in der falschen Sprache für jede Seite besteht, die nicht in der Standardsprache ist. Das würde zu einer SEO-Strafe führen, denke ich.

Die Alternative wäre, die Schnecken als auch zu übersetzen und gegebenenfalls die Sprachkennung auslassen auch:

http://example.com/english-slug.html 
http://example.com/deutscher-slug.html 
http://example.com/slug-francois.html 

Einige Sprachen selbst nicht wirklich verleihen ‚sluggified‘, wie Russisch, Chinesisch und Arabisch werden . Sie werden mit Transliterationen enden, die wenig Sinn ergeben.

Answer 1

ich glaube, Sie Sprachtags und übersetzt Schnecken verwenden sollten:

http://example.com/en/hello-world 
http://example.com/de/hallo-welt 

Warum Sprach-Tags? Um Kollisionen zu vermeiden.
Manchmal möchten Sie vielleicht den gleichen Slug für verschiedene Sprachen haben (zum Beispiel "team" sowohl auf Englisch als auch auf Deutsch).

Warum übersetzte Pfade? Für bessere Benutzerfreundlichkeit.
Nicht alle Benutzer verstehen die "Standard" -Sprache, und je nach Skript können sie den Slug nicht einmal eingeben/erinnern/diktieren. (Es macht überhaupt keinen Sinn, menschenlesbare Nacktschnecken zu verwenden, die nur ein Teil Ihrer Benutzer verstehen kann.)

Ja, es wäre ein (geringfügiger) Vorteil, dass ein Benutzer manuell wechseln kann in eine andere Sprache durch Ändern der URL ". Aber es ist unwahrscheinlich, dass Benutzer oder Suchmaschinen erwarten, dass dies funktioniert (siehe my related answer on Webmasters). Sie würden also wenig (URL-Hacking für fortgeschrittene Benutzer) gewinnen und viel verlieren (schlechte Benutzerfreundlichkeit für Benutzer, die die Nicht-Standardsprache verwenden).

Das heißt, es immer noch möglich wäre, diese URL zu ermöglichen Hacking-Funktion in den meisten Fällen: Wenn Benutzer die Sprache Tag ändern de (in /de/hallo-welt) zu en (/en/hallo-welt), können Sie überprüfen, ob es vorhanden ist (wenn ja, zeigen es), und wenn nicht, überprüfen Sie, ob es einen Slug "hallo-Welt" in irgendeiner Sprache gibt, finden Sie seine englische Übersetzung und leiten Sie es um (von /en/hallo-welt zu /en/hello-world).

Answer 2

Die beste Lösung, wenn Sie es sich leisten können, ist, das Dokument mit dem richtigen Namen zu senden, dh mit dem richtigen Wort für jede Sprache.

Natürlich sollte jedes Dokument mit den entsprechenden Spracheinstellungen in den Kopfzeilen gesendet werden.

Um diese zu speichern, können Sie Ordner verwenden und den Webserver entsprechend den Spracheinstellungen das richtige Dokument auswählen lassen. oder Sie können serverseitige Technologie wie PHP, Perl usw. verwenden, um das Dokument zu senden und die URL anzupassen.

In jedem Fall muss eine Standardsprache gesendet werden, wenn Sie nicht die gewünschte Sprache haben.

Wenn Sie ein Dokument mit dem richtigen Namen nicht senden können oder wollen, ist die Verwendung von Subdomains die beste Option. Diese Option ist nicht so gebräuchlich wie das Hinzufügen der Sprache nach der Domäne, und das bedeutet, dass Personen möglicherweise nicht daran gewöhnt sind, obwohl es z. B. einige Vorteile hat;

• Jede Sprache verhält sich (fast) wie eine ganz neue URL/Site.
• Die Leute haben das Gefühl, eine dedizierte Site zu besuchen, nicht eine Untersektion, in der die zweite Sprache verbannt ist und jederzeit fehlschlagen kann (einige Inhalte werden möglicherweise nicht übersetzt).
• Einige Leute sind nicht vertraut mit ihrer Zwei-Buchstaben-Darstellung der Sprache, aber jeder weiß, wie seine Sprache heißt und geschrieben wird.
• Es generiert sauberere URLs.
• Es wird angenommen, dass Subdomains das Aussehen auf SERPs erhöht (ich habe keine Kenntnis davon und es könnte sich geändert haben).
• Es ist einfacher, verschiedene Layouts zu haben, wenn Sie möchten.
• Es ist einfacher, verschiedene Server nach Sprache einzustellen.

Natürlich Subdomains haben einige Nachteile, wie:

• ein bisschen mehr Arbeit richtig aus der Perspektive des Servers einzustellen.
• Weniger Zusammenarbeit von dem Teil in Richtung hochrangig.
• Manche Leute erwarten es nicht, aber erwarten einen Unterordner.

Als nächstes wäre die Unterordner-Option, wie Sie auf die Frage zeigen. Dies ist der empfohlene Weg, wenn Ihre Hauptperspektive SEO ist, da die gesamte Relevanz der Domain auf derselben Domain bleibt und jede Sprache zu einem gemeinsamen Ranking beiträgt.

Meine Perspektive bei der Auswahl einer Lösung, ist nie SEO, unter keinen Umständen. Welches Ranking ich auch immer erhalte, hängt mit dem Inhalt selbst und dem besten Nutzen zusammen, den ich der Technologie geben kann. Aber ich verstehe, dass meine Sichtweise nicht die üblichste ist.

Eine Sache, die Sie auch beachten sollten, ist, dass Sie eine Erklärung geben oder dem Benutzer helfen sollten, damit er Maßnahmen ergreifen kann, um in die bevorzugte Sprache zu wechseln. Es kann Symbole, eine QuickInfo oder eine andere Methode sein, die für Ihr Design und Ihre Ausführlichkeit geeignet ist.

Eine Sache zu vermeiden, und Sie haben nicht danach gefragt, aber ist verwandt; verwendet automatische Spracherkennung. Viele Male ist der Benutzer in einem anderen Land oder verwendet eine Version eines Browsers, der eine andere Sprache hat, als die, die er verstehen kann, und die automatische Erkennung macht nur ein großes Durcheinander. Bieten Sie die Standardversion und eine klare Möglichkeit, sie zu ändern.