Sprachen zuerst auf getrennte Seiten legen
Das Menü zu übersetzen reicht nicht. Wechselt die Sprache per Cookie oder JavaScript, bleibt die URL aber gleich, sind Nutzer vielleicht zufrieden—Suchmaschinen haben trotzdem nichts Solides zum Indexieren.
Den Fehler, den ich zuerst entfernen würde: hreflang nur auf der russischen Seite setzen.
Was vorbereiten und welches Ergebnis erwarten
- Ergebnis: Suchmaschinen wissen, welche Seite zu zeigen ist, und Besucher landen nicht auf russischem Copy mit falscher Währung und Telefonnummer.
- Wählen Sie eine URL-Struktur wie /ru/, /en/, /de/. Erfassen Sie Sprache, Markt, Währung, Kontakt und das unterschiedliche Suchintent jeder Version.
- Halten Sie Quelldaten und Zugriffsrechte vom Output getrennt, damit Sie prüfen können, was die mehrsprachige Site-Version erzeugt hat.
- Prüfen Sie Language Switcher, Quell-HTML und Sitemap jeder Version. Jede Seite sollte auf sich selbst und die anderen Versionen verlinken.
URL-Versionen verknüpfen und Übersetzung prüfen
- Separate URLs anlegen
Bauen Sie /ru/services/repair/ und /en/services/repair/ statt ?lang=en. Mischen Sie keine zwei Sprachen auf einer URL.
Проверьте: Jede Version öffnet sich direkt und hat eigenen title, H1 und html lang.
Если не сработало: Starten Sie mit zwei Sprachen und einer Service-Seite.
- Reziprokes hreflang setzen
Im Head jeder Seite das volle alternate-Set setzen, inklusive der Seite selbst und x-default. Links müssen absolut und reziprok sein.
<link rel="alternate" hreflang="ru" href="https://example.com/ru/services/repair/"> <link rel="alternate" hreflang="en" href="https://example.com/en/services/repair/"> <link rel="alternate" hreflang="x-default" href="https://example.com/ru/services/repair/">Проверьте: Die englische Seite verlinkt zurück zur russischen—nicht nur die russische zur englischen.
Если не сработало: Prüfen Sie das Head-Generierungs-Template auf jedem Locale.
- Canonical auf dieselbe Sprache zeigen
Canonical für /en/services/repair/ muss auf die englische Seite zeigen, nicht die russische. Nur fertige Versionen in die Sitemap.
Проверьте: Es gibt keine Redirect-→-Canonical-Kette zu einer anderen Sprache.
Если не сработало: Duplikat aus dem Index nehmen, bis das Template gefixt ist.
- Bedeutung lokalisieren, nicht nur Wörter
Prüfen Sie title, description, H1, URL, Preise, Währung, Adresse, Telefon, Formular, Bilder und FAQ. Maschinenübersetzung nur als Entwurf nutzen.
Проверьте: Ein Muttersprachler sieht, dass Service und nächster Schritt zu seinem Markt passen.
Если не сработало: Ersten Screen und CTA manuell umschreiben, bevor Sie das Locale erweitern.
Eine Sprach-URL-Map vor der Übersetzung
Zuerst eine Tabelle: `/ru/services/`, `/en/services/`, `/de/services/` und die Zuordnungen. Keine Sprache veröffentlichen, bis sie volle Seite, Formular, Preis/Währung und lokalen nächsten Schritt hat. IP-Redirects vermeiden, die Crawler von der richtigen Version abhalten.
Auf jeder Seite ist Canonical meist self-referencing. Korrektes `lang` auf `<html>` setzen, aber nicht als Ersatz für hreflang. Nach Veröffentlichung HTML mit `curl -s URL | grep -i hreflang` prüfen und Rücklinks testen.
<link rel="alternate" hreflang="ru" href="https://example.com/ru/services/">
<link rel="alternate" hreflang="en" href="https://example.com/en/services/">
<link rel="alternate" hreflang="de" href="https://example.com/de/services/">
<link rel="alternate" hreflang="x-default" href="https://example.com/">Lokalisierung ist kein Worttausch
Währung, Telefon, Adresse, Zeiten, Zahlungsbedingungen, Lieferung, Rechtsdokumente, Kundenbeispiele und CTAs prüfen. `en-GB` nicht in `en-UK` ändern; Sprache zuerst, Region nach dem Bindestrich. In Analytics Leads nach Sprachordnern vergleichen; in Search Console Länder und Geräte.
- Die englische Seite verlinkt zurück zur russischen.
- Nicht alle Sprachen auf Englisch canonicallen.
- Fehlende Übersetzungen nicht in die Sitemap nehmen.
Ich behandle Versionen als getrennte Produkte
Pro Locale einen Übersetzungs-Owner und Review-Datum zuweisen. `locale`, `url`, `canonical`, `hreflang_set`, `currency`, `phone`, `form_recipient` und `last_reviewed` in einer Tabelle speichern. Ein Test-Lead jeder Version muss in die richtige Queue—sonst haben Sie ein Sprach-SEO-Signal ohne Business dahinter.
Rechtliche Begriffe, Preise und Versprechen nicht ohne Editor auto-übersetzen. Ändert sich nur die Menüsprache und der Content bleibt gleich, ist das keine volle Lokalisierung und kein Grund für Dutzende schwache URLs.
Was außer Text lokalisiert werden muss
| Kriterium | Frage | Gutes Zeichen |
|---|---|---|
| Eingabe | Was genau geht in eine mehrsprachige Site-Version? | Wählen Sie eine URL-Struktur wie /ru/, /en/, /de/. Erfassen Sie Sprache, Markt, Währung, Kontakt und das unterschiedliche Suchintent jeder Version. |
| Aktion | Was darf das System von allein tun? | Nur vorab gelistete Aktionen, ohne Zugriff auf das gesamte Konto |
| Prüfung | Woran erkennen Sie, dass das Ergebnis akzeptabel ist? | Prüfen Sie Language Switcher, Quell-HTML und Sitemap jeder Version. Jede Seite sollte auf sich selbst und die anderen Versionen verlinken. |
| Fehlerfall | Wohin geht ein unklarer Fall? | Die kaputte Version aus hreflang und Sitemap nehmen, bis Übersetzung und Canonical bereit sind. |
Was sich nach der Einrichtung ändern sollte
Suchmaschinen wissen, welche Seite zu zeigen ist, und Besucher landen nicht auf russischem Copy mit falscher Währung und Telefonnummer.
Warum hreflang eine schlechte Übersetzung nicht rettet
hreflang nur auf der russischen Seite setzen.
Canonical jeder Sprache auf die russische Version zeigen.
Per IP auto-redirecten und den manuellen Language Switcher verstecken.
Menü übersetzen, aber russische Preise und Bedingungen auf der Service-Seite lassen.
Wann mehrsprachige Arbeit ein eigenes Projekt braucht
Sie brauchen einen Spezialisten, wenn Versionen auf unterschiedlichen Domains leben, regionale Preise haben, eine große Migration erfordern oder rechtlich unterschiedliche Bedingungen tragen.
Was auf jedem Locale prüfen
Braucht man hreflang für zwei Sprachen in einem Markt?
Ja, wenn es separate volle URLs gibt und Suchmaschinen verstehen müssen, wie die Versionen zusammenhängen.
Kann man eine Seite automatisch übersetzen?
Ja, als Entwurf. Begriffe, Preise, rechtliche Formulierungen und natürliche Sprache brauchen trotzdem menschliche Prüfung.
Ordner oder Subdomains?
Für eine kleine Site sind Ordner einfacher zu pflegen. Subdomains oder eigene Domains lohnen, wenn Märkte und Teams unabhängig sind.
Kann eine gemeinsame Kontaktseite bleiben?
Nur wenn der Kontakt wirklich geteilt ist. Für einen lokalen Markt lokales Telefon, Währung und Öffnungszeiten zeigen.
