Ein englisches /en-Präfix kann gültig sein
Eine mehrsprachige Website kann /en für Englisch verwenden, ebenso wie sie /he für Hebräisch verwenden kann. Ein weiteres gültiges Design stellt Englisch an die Wurzel. Das Problem ist unverwaltete Duplizierung und widersprüchliche Signale: zum Beispiel, wenn beide /services und /en/services dieselbe englische Seite ausliefern, während Links, Canonicals und Sitemaps nicht übereinstimmen.
Dieses Projekt verwendet Englisch an der Wurzel und stellt seinen anderen unterstützten Sprachen, darunter Bengalisch, Hebräisch und Arabisch, ein Präfix voran. Das ist eine Projektkonvention, keine universelle SEO-Regel. Seine redundanten englisch-präfixierten Pfade leiten auf die passenden Wurzelpfade weiter. Eine Website, die bereits konsistent um /en herum organisiert ist, muss nicht migrieren, nur um dieser Konvention zu folgen. Siehe Googles Leitfaden zu mehrsprachigen URL-Strukturen.
Ordnen Sie entsprechende Seiten explizit zu
Jede echte Übersetzung sollte normalerweise auf ihre eigene bevorzugte URL kanonisiert werden. Verknüpfen Sie die entsprechenden Versionen mit wechselseitigen hreflang, einschließlich einer Referenz auf die aktuelle Seite. Verwenden Sie absolute URLs und einen gültigen Sprachcode. x-default kennzeichnet einen Fallback für Sprachen ohne spezifische Entsprechung; es bedeutet nicht, dass jede Seite Englisch ist.
Zum Beispiel kann eine englische Serviceseite auf ihre bengalischen, hebräischen und arabischen Entsprechungen verweisen, und jede Entsprechung gibt denselben Cluster zurück. Ein Link zur Startseite in einer anderen Sprache ist kein Ersatz für eine fehlende Service-Übersetzung.
Eine übersetzte Navigation rund um einen unveränderten englischen Artikel erzeugt keinen übersetzten Artikel. Auf dieser Website erhält eine Artikelübersetzung ihre eigene Canonical-URL und wechselseitige Sprachlinks nur dann, wenn übersetzter Hauptinhalt verfügbar ist. Eine Sprach-URL, die weiterhin die englische Quelle zeigt, verweist auf das englische Canonical und wird aus dem Übersetzungscluster ausgeschlossen. Googles Referenz zu lokalisierten Versionen erläutert wechselseitige Annotationen und nicht übersetzten Hauptinhalt.
Prüfen Sie das HTML und die Leserichtung
Geben Sie ein aussagekräftiges lang Attribut mit dem Server-HTML zurück. Hebräisch und Arabisch benötigen dir="rtl"; verwenden Sie logische Start-/End-Eigenschaften für das Layout. Isolieren Sie von links nach rechts verlaufende Werte wie E-Mail-Adressen, URLs und Produktnamen, wo sie andernfalls verwirrend umsortiert würden. Sprach-Metadaten ersetzen keinen lesbaren, korrekt übersetzten Inhalt.
Eine praktische Release-Prüfung
- Fordern Sie eine repräsentative URL in jeder Sprache ohne Browser-JavaScript an und prüfen Sie Titel, Canonical, Sprache und Überschriften.
- Folgen Sie Links zu alternativen Sprachen in beide Richtungen und bestätigen Sie, dass sie erfolgreich zu gleichwertigem Inhalt aufgelöst werden.
- Behalten Sie nur bevorzugte, veröffentlichte URLs in der Sitemap. Schließen Sie Tracking-Varianten, leere Sammlungen und Entwürfe aus.
- Bestätigen Sie, dass ein Vorschau-Host
noindexin einem HTTP-Header oder HTML-Meta-Tag ausliefert, während die Produktion indexierbar bleibt. Erlauben Sie Crawlern, die Vorschauseite abzurufen, damit sie diese Anweisung lesen können. - Üben Sie den Sprachwechsel an einer Serviceseite, einem Artikel und dem Anfrageformular aus, einschließlich direkter Ladevorgänge und gespeicherter Präferenzen.
Das noindex-Verhalten folgt Googles Leitfaden zur Indexierungssteuerung. Diese Prüfungen unterstützen eine konsistente Auffindbarkeit; sie versprechen keine Rankings. Für Hilfe bei der Umsetzung siehe Webentwicklung und den sekundären technischen SEO-Dienst.
