PrestaShop hreflang: Sprachzuordnungen und Validierung
Prüfen Sie PrestaShop-hreflang, gegenseitige Sprachzuordnungen, regionale URLs und optionales x-default. Prüfen Sie Modul- und Sitemap-Ausgabe zusammen.
Prüfen Sie die von Ihrem Shop veröffentlichten Sprach-URLs, bevor Sie hreflang ändern. Nutzen Sie korrekte Seitenzuordnungen, eine klare Zuständigkeit für die Ausgabe und wiederholbare Prüfungen für jeden beteiligten Sprachverbund.
Was wir tun würden
Wir würden die Ursache einer falschen oder fehlenden Sprachalternative ermitteln, bevor wir ein Modul auswählen. Das Vorgehen hängt von Ihrem bestehenden Theme, SEO-Modulen, Anbindungen zum Import von Übersetzungen oder zur Änderung von URLs, Katalogzuordnungen, Märkten und dem zuständigen Team ab. Dokumentieren Sie, welche Seiten einander entsprechen sollen und welche Komponente diese Beziehung derzeit veröffentlicht.
Nehmen Sie die Änderung auf einer Staging-Kopie dieser Konfiguration vor. Halten Sie Staging privat und aus der Suche heraus, erproben Sie die Zuordnungs- und Ausgabeprüfungen und sichern Sie die bisherigen Einstellungen und Templates. Vereinbaren Sie ein Umstellungsfenster und Schritte zur Rücknahme und prüfen Sie nach der Bereitstellung die öffentlichen Seiten. Staging-Prüfungen belegen die Struktur; die endgültigen Produktionshosts und die Indexierbarkeit müssen weiterhin an Live-Seiten geprüft werden. Veröffentlichen Sie niemals Staging-URLs in Live-Sprachalternativen oder Sitemaps.
Wenn mehrsprachiges Routing, Canonicals und Zuordnungen von Sprachalternativen kollidieren, bietet der PrestaShop SEO Audit & Action Plan eine Prüfung und priorisierte Korrekturen für Ihren Entwickler; die Umsetzung wird separat vereinbart.
Die Aufgabe von hreflang verstehen
Hreflang kennzeichnet entsprechende Sprach- oder Regionalversionen einer Seite. Es hilft Suchmaschinen, eine passende Version auszuwählen; es übersetzt keine Inhalte, erzwingt keine Rankings und fasst übersetzte Seiten nicht zu einer kanonischen Seite zusammen.
Vollständig übersetzter Hauptinhalt ist nicht allein aufgrund der Übersetzung doppelter Inhalt. Kopierter Text in der Ausgangssprache und gleichsprachige regionale Duplikate benötigen eine eigene Inhalts-/Canonical-Prüfung. Nutzen Sie separate Sprach-URLs und ermöglichen Sie eine ausdrückliche Sprachauswahl. Siehe Googles Hinweise zu mehrsprachigen Websites.
Hreflang wird empfohlen, wenn Sie diese Beziehung ausdrücken möchten, ist aber nicht für jeden mehrsprachigen Shop verpflichtend. Google kann Sprachversionen auch ohne hreflang entdecken. Schlechte Inhalte, fehlende Übersetzungen, blockierte URLs und unklare Routen sind getrennte Probleme.
Zuerst die native PrestaShop-Ausgabe prüfen
Modernes PrestaShop erstellt für aktive Sprachen im aktuellen Shop eine Zuordnung alternativer Sprach-URLs. In PrestaShop 9 verwendet sie language_code als Schlüssel und nutzt Link::getLanguageLink(). Das Theme muss sie tatsächlich im Head ausgeben. Ein überschriebenes Head-Teil-Template kann sie entfernen oder duplizieren.
Classic und Hummingbird bieten moderne Theme-Integrationen, prüfen Sie aber die installierten Versionen. Classic blieb in 9.0 der Standard; Hummingbird wurde es in 9.1. Der default-bootstrap-Header von PrestaShop 1.6 bietet nicht denselben modernen Alternativblock. Nehmen Sie über diese Generationen hinweg keine identische Ausgabe an.
Der ISO-Code der Sprache wirkt am URL-Routing mit, während language_code den Schlüssel der nativen Alternativzuordnung liefert. Das Gebietsschema ist ein separates Feld. Korrigieren Sie falsche Werte in ihrer tatsächlichen Konfiguration und prüfen Sie die gerenderte Ausgabe; die Änderung eines Werts garantiert nicht die Richtigkeit des anderen.
Shop-URLs gehören zu Shops, nicht zu einzelnen Sprachen. Unterordner können natives mehrsprachiges Routing verwenden. Separate Sprachdomains oder Subdomains benötigen passendes Multishop- oder eigenes Routing. Native Sprachlinks eines einzelnen Shops finden nicht automatisch entsprechende Produkte auf unabhängigen Shopdomains.
Prüfen Sie in Versionen mit diesen Menübezeichnungen International → Lokalisierung → Sprachen für Sprachfelder und Shop-Einstellungen → Traffic & SEO → SEO & URLs für URL-Einstellungen. Shop-URL festlegen betrifft die Shopadresse. Dokumentieren Sie vor der Bearbeitung den aktuellen Shopkontext und die Werte; die Änderung eines etablierten Sprachpfads benötigt auch einen Plan für Weiterleitungen und interne Links.
Gegenseitig verknüpfte Seitenverbünde aufbauen
Nutzen Sie gültige Sprachcodes, optional mit einer unterstützten Region: en-GB statt en-UK; cs für Tschechisch statt cz. Verweisen Sie mit vollständiger URL auf die tatsächlich entsprechende Seite. Jede beteiligte Version sollte sich selbst nennen und Rückverweise zu ihren Partnern liefern. Google kann gegenseitig verknüpfte Teilmengen verarbeiten; eine andernorts fehlende Angabe macht nicht jedes funktionierende Paar ungültig. Siehe Googles Regeln für alternative Versionen.
Für einen englischen/deutschen/französischen Produktverbund gehört dieselbe beteiligte Gruppe in den Head jeder Seite:
<link rel="alternate" hreflang="en" href="https://store.example/en/product">
<link rel="alternate" hreflang="de" href="https://store.example/de/produkt">
<link rel="alternate" hreflang="fr" href="https://store.example/fr/produit">x-default ist ein optionales Ausweichziel, beispielsweise eine Sprachauswahl oder gewählte allgemeine Version. Sein Fehlen macht die Sprachgruppe nicht ungültig. Wenn Sie es verwenden, halten Sie das Ziel passend und zugänglich. Siehe Googles Erklärung zu x-default.
<link rel="alternate" hreflang="x-default" href="https://store.example/en/product">Behalten Sie für jede tatsächlich übersetzte Version das übliche Canonical in dieser Sprache bei. Beheben Sie unerwartete Weiterleitungen, noindex, Fehler oder widersprüchliche Canonicals, bevor Sie sich auf den Verbund verlassen. Hreflang macht ein ungeeignetes Ziel nicht indexierbar.
Ordnen Sie bei regionalen Shops entsprechende Entitäten ausdrücklich zu. Gleiche numerische IDs in verschiedenen Shops sind nur sicher, wenn sie denselben Artikel oder Inhalt repräsentieren. Entscheiden Sie, welches Ziel für jeden Sprach-/Regionalcode zuständig ist, wenn mehrere Shops ihn anbieten. Ordnen Sie ein unübersetztes Produkt niemals nur zum Füllen eines Platzes einer Startseite zu.
HTML-Head-Tags und XML-Sitemap-Angaben können diese Beziehungen ausdrücken. Nutzen Sie beides, halten Sie die Zuordnungen konsistent. Ein Sitemap-Eintrag sollte die aktuelle URL und die relevanten Alternativverweise mit den erforderlichen XML-Namespaces enthalten; prüfen Sie alle beteiligten Einträge, statt nur einen einseitigen Link zu einer anderen Version hinzuzufügen.
Einen regionalen Zuordnungsfehler durchgehen
Ihr britischer und Ihr US-Shop verkaufen dieselbe Lampe auf Englisch, doch Katalogimporte haben unterschiedliche Produktdatensätze angelegt. Eine Zuordnung anhand übereinstimmender numerischer IDs verknüpft die britische Lampe mit einem US-Lampenschirm. Die Codes en-GB und en-US können gültig sein, während die Beziehung falsch ist.
Bestätigen Sie die Entsprechung anhand einer stabilen Katalogreferenz und des tatsächlichen Produktinhalts, korrigieren Sie die Zuordnung und prüfen Sie anschließend beide Ziele und ihre Rückverweise. Ist die US-Lampe nicht veröffentlicht, entfernen Sie ihren Alternate-Eintrag aus den beteiligten Seiten und aktivierten Sitemap-Annotationen, bis sie bereit ist. Nehmen Sie diesen Fall in Prüfungen nach Katalogimporten auf: Ein Crawler kann fehlerhafte Beziehungen melden, ohne zu erkennen, dass zwei gültige Seiten unterschiedliche Artikel verkaufen.
Eine Implementierung wählen und die Einrichtung in der Modulhilfe belassen
| Ihr Befund | Erster Ansatz | Nachweise vor der Umstellung |
|---|---|---|
| Die native Ausgabe deckt die Sprach-URLs Ihres Shops ab. | Behalten Sie sie bei und pflegen Sie die Sprachkonfiguration. | Repräsentative entsprechende Seiten besitzen nutzbare, wechselseitige Verweisgruppen. |
| Ein individuelles Theme hat den Alternate-Block entfernt. | Stellen Sie die Ausgabe der nativen Zuordnung wieder her, sofern diese Ihre Anforderungen erfüllt. | Der korrigierte Head enthält die vorgesehene Verweisgruppe ohne doppelte Ausgabe. |
| Sie benötigen shopübergreifende Zuordnungen, Ausschlüsse oder seitenspezifische Ausnahmen. | Bewerten Sie eine zusätzliche Umsetzung anhand dieser Anforderungen. | Die installierte Version unterstützt Ihre Entitäten und Ziele einschließlich Rückverweisen. |
| Verschiedene Generatoren veröffentlichen widersprüchliche Verweisgruppen. | Legen Sie die Zuständigkeit für die Ausgabe fest und deaktivieren Sie konkurrierende Ausgaben über deren unterstützte Einstellungen. | Zwischengespeicherte öffentliche Antworten und aktivierte Sitemap-Annotationen stimmen überein. |
Legen Sie für die Alternate-Verweisgruppe jeder Seite eine zuständige Komponente fest und prüfen Sie deren Einbindung in die tatsächliche Theme-Ausgabe.
Für automatische Multishop-Verbindungen, manuelle Local/Shared-Gruppen, Quell-/Zielzeilen, Ausschlüsse, Entwurfsvorschauen, Zuständigkeit und Lizenzanforderungen folgen Sie der Hilfeseite zu Hreflang Tags Manager.
Für hreflang-Einstellungen, URL-Muster, Vorschauen, Weiterleitungen aus dem URL-Verlauf und erzeugte Sprach-Sitemaps folgen Sie der Hilfeseite zu SEO Revolution.
Hreflang Tags Manager deckt unterstützte Entitätsseiten ab und lässt seine erzeugten Gruppen bei Suche, gefilterten Ergebnissen und Listenseiten nach Seite eins weg. Bei erfolgreichen Antworten behalten Konto-, Checkout- und Modulseiten mögliche Alternativen ihrer eigenen Controller und des Themes. Manuelle Zuständigkeiten haben Vorrang vor automatischen Verbindungen. Eigene URL-Ziele und dynamische Zuordnungen benötigen weiterhin Rückverweisprüfungen. Canonical-Behandlung bleibt ein separates Thema.
Wenn SEO Revolution die hreflang-Ausgabe übernimmt, bleibt der eigenständige Manager stumm. Die Suite benötigt mindestens zwei zulässige Alternativen einschließlich der aktuellen Seite; ihre x-default-Ausgabe hängt davon ab, dass die gewählte Standard-URL zulässig bleibt. Ihr Code bevorzugt language_code und kann auf das Gebietsschema zurückgreifen. Header- und Sitemap-Funktionen haben eigene Einstellungen und Zulässigkeitsprüfungen. Wiederholen Sie die Ausgabeprüfungen nach Theme-Änderungen, da auch vom Modul erzeugte Tags von der Theme-Einbindung abhängen.
Die tatsächlichen Seiten nach Änderungen validieren
- Wählen Sie ein echtes Produkt mit vollständigen Übersetzungen. Rufen Sie die HTML-Antwort ab oder verwenden Sie den Seitenquelltext und prüfen Sie den Head auf Alternativlinks. Prüfen Sie, welche Komponente sie liefert.
- Öffnen Sie jedes Ziel. Bestätigen Sie endgültige URL, sichtbare Sprache, Antwortstatus, Robots-Anweisung und Canonical. Prüfen Sie den tatsächlichen Sprach-/Regionalcode gegen die vorgesehene Zielgruppe.
- Vergleichen Sie die Gruppen. Prüfen Sie Selbstreferenzen und Rückverweise der beteiligten Seiten. Behandeln Sie x-default als optional und validieren Sie sein Ziel, falls vorhanden.
- Wiederholen Sie dies für Startseite, Kategorien, CMS, Marken und Lieferanten, soweit sie teilnehmen. Absichtlich nicht unterstützte Seitentypen eines Moduls benötigen keine erfundenen Zuordnungen.
- Prüfen Sie erzeugtes XML, wenn Sitemap-Angaben aktiviert sind. Vergleichen Sie dessen URLs mit Head-Tags und Zielen der Sprachauswahl.
- Nutzen Sie einen Crawler für den vorgesehenen URL-Bestand, um ungültige Codes, Weiterleitungen, einseitige Paare, doppelte Ausgaben und ungeeignete Ziele zu finden. Dokumentieren Sie Ausnahmen, statt jede Seite als teilnahmepflichtig anzusehen.
- Wiederholen Sie nach Änderungen an Domains, Spracheinstellungen, Slugs, Head-Templates des Themes, SEO-Zuständigkeit oder Sitemap-Erzeugung.
Fehlende oder unbrauchbare Angaben können ignoriert werden oder keine Beziehung herstellen. Prüfen Sie, welche Zuordnungen betroffen sind, und korrigieren Sie die unbrauchbaren Angaben.
Bleibt ein altes Ziel nach einer Korrektur bestehen, vergleichen Sie eine aktualisierte Antwort mit zwischengespeichertem HTML und bestimmen Sie die Cache-Ebene, bevor Sie weitere Zuordnungen bearbeiten. Das Leeren Ihres Browser-Caches leert kein Server- oder CDN-HTML. Fehlen Tags, vergleichen Sie denselben Seitentyp im installierten Theme und dessen Head-Override, bevor Sie fehlende Sprachdaten vermuten.
Zur Vorbereitung der Inhalte und Währungen hinter diesen URLs siehe Leitfaden zu Übersetzungen und internationalem Verkauf.
Umstellung und Übergabe planen
- Sichern Sie HTML vor und nach der Änderung sowie die Zuordnungseinstellungen für die vereinbarten Testseiten einschließlich eines absichtlichen Ausschlusses. Halten Sie die bisherige Ausgabekonfiguration zur Wiederherstellung bereit.
- Stellen Sie die freigegebenen Einstellungen und Template-Änderungen gemeinsam bereit, aktualisieren Sie betroffene Caches und generieren Sie aktivierte Sitemaps neu. Wiederholen Sie vor der Abnahme die obige Validierung an öffentlichen URLs.
- Übergeben Sie der für die Shoppflege zuständigen Person Angaben zur ausgebenden Komponente, Zuordnungsregeln, Ausschlüsse, Test-URLs und Anweisungen zur Rücknahme. Wiederholen Sie die relevanten Prüfungen, wenn diese Person eine Sprache ändert oder Katalogdaten importiert.
Fragen an Ihren Entwickler oder Ihre Agentur
- Wie werden entsprechende Datensätze shopübergreifend zugeordnet, und was geschieht, wenn eine Übersetzung nicht mehr veröffentlicht ist oder ein Import einen Datensatz ersetzt?
- Welches Theme-Override oder Modul steuert den Head, und welche Einstellungen steuern Sitemap-Annotationen?
- Wer prüft neue Sprach- und Domainänderungen, und welche Befunde lösen eine Rücknahme aus?
Häufige Fragen von Shopbetreibern
Brauche ich separate Domains, um hreflang zu korrigieren?
Nein. Eine funktionierende Unterordnerstruktur kann Sprachalternativen ausdrücken. Wählen Sie Domains passend zu Ihrem Markt und Ihrer Shoparchitektur; das Verschieben etablierter URLs verursacht Migrationsarbeit, die eine Tag-Korrektur möglicherweise nicht erfordert.
Kann hreflang die Sprachauswahl ersetzen oder Besucher weiterleiten?
Nein. Behalten Sie eine gut bedienbare Auswahl mit Links zur entsprechenden Seite bei. Automatische Sprach- oder Standortweiterleitungen benötigen eine separate Prüfung: Sie können Besucher und Crawler daran hindern, die angeforderte URL zu erreichen.
Wie schnell zeigt Google die korrigierte Version an?
Es gibt keinen festen Zeitplan. Bewahren Sie das korrigierte HTML und die Crawling-Ergebnisse als technische Nachweise auf; Suchergebnisse hängen von erneutem Crawling und Googles Auswahl ab. Ein unverändertes Ranking allein zeigt nicht, ob eine Annotation gültig ist.