Geprüft im Juni 2026, gilt für PrestaShop 1.7, 8 und den Hummingbird-basierten Standard in 9.x; alle geben einen Core-hreflang-Block aus, den Sie prüfen sollten, statt ihn einfach vorauszusetzen.
Den teuren Teil haben Sie bereits erledigt: Ihr Shop spricht Deutsch mit deutschen Käufern, Französisch mit französischen, Polnisch mit polnischen. Der günstige Teil. Google mitzuteilen, welche Version zu wem gehört. Ist genau der Teil, den die meisten PrestaShop-Händler falsch umsetzen, und er macht die Übersetzungsarbeit leise wieder zunichte. Ohne korrekte hreflang-Signale muss Google raten, und das geht oft schief: Es zeigt einem deutschen Suchenden Ihre englische Seite, oder es wertet Ihre fünf Sprachversionen als fünf beinahe identische Seiten, die um dasselbe Keyword konkurrieren, rankt eine davon und begräbt den Rest. Hreflang ist das kleine technische Verbindungsstück, das aus „wir haben den Shop übersetzt“ ein „der richtige Käufer landet in der richtigen Sprache“ macht. In diesem Leitfaden geht es darum, genau dieses Verbindungsstück in PrestaShop sauber umzusetzen, was die Plattform bereits ausgibt, wo sie an Grenzen stößt und wie Sie es prüfen, statt darauf zu vertrauen, dass es „einfach funktioniert“.
Dies ist der hreflang-spezifische Teil eines größeren Themenclusters. Wenn Sie noch früher im Prozess stehen, also entscheiden, welche Sprachen Sie anbieten, wie URLs aufgebaut sein sollen oder ob Sie einen oder mehrere Shops nutzen, beginnen Sie mit dem Setup mehrsprachiger Shops und kommen Sie hierher zurück, sobald die Sprachen angelegt sind.
Was hreflang Google tatsächlich mitteilt (und was nicht)

Eine hreflang-Annotation ist eine einzelne Zeile im Head der Seite:
<link rel="alternate" hreflang="de" href="https://yourstore.com/de/produkt">
Sie sagt genau eines aus: „Es gibt eine deutschsprachige Entsprechung dieser Seite, und sie befindet sich hier.“ Wiederholen Sie das für jede Sprache, und Sie geben Google eine Karte dafür, welche URLs Übersetzungen voneinander sind. Google nutzt diese Karte für zwei Aufgaben. Erstens für die Sprachzuordnung, ein französisch-kanadischer Suchender erhält Ihre fr-Seite, nicht Ihre en-Seite, selbst wenn die englische Version rein technisch besser rankt. Zweitens, und das wird von Händlern oft unterschätzt, für die Kannibalisierungskontrolle: hreflang sagt Google, dass diese Seiten Alternativen sind, keine Wettbewerber, sodass sie sich ihre Ranking-Signale nicht gegenseitig aufteilen. Genau deshalb sind ein SEO-Problem und ein Übersetzungsproblem hier im Grunde dasselbe Problem.
Die Grenze sollte man ehrlich benennen, denn dort entstehen falsche Erwartungen. Hreflang ist ein Hinweis, keine Anweisung. Google hat das wiederholt klar gesagt. Es erzwingt kein Ranking, ersetzt keine guten Übersetzungen und rettet keine Seiten, die Google als minderwertig einstuft. Es hilft Ihren Kunden auch nicht direkt; niemand sieht im Browser ein hreflang-Tag. Es ist ausschließlich ein Signal für den Crawler. Der praktische Nutzen ist also eng gefasst, aber real: Korrektes hreflang verhindert, dass bereits verdiente Rankings durch eine Duplicate-Content-Fehlinterpretation verloren gehen, und es verhindert Absprünge wegen der falschen Sprache, die Werbe- und SEO-Budget gleichermaßen verbrennen.
Was PrestaShop bereits erledigt, und wo die Lücken liegen
Hier liegt der Fehler in der alten Empfehlung „PrestaShop hat kein hreflang, installieren Sie ein Modul“: Moderne PrestaShop-Versionen geben hreflang-Tags bereits aus. Die Standard-Themes (das Classic-Theme in 1.7/8 und der Hummingbird-basierte Standard in 9.x) enthalten einen hreflang-Block im Head der Seite, der Ihre aktiven Sprachen durchläuft und für jede eine rel="alternate"-Zeile ausgibt, aufgebaut über Link::getLanguageLink(). Eine unveränderte mehrsprachige Installation in einem einzelnen Shop hat deshalb in der Regel funktionierendes hreflang direkt ab Werk. Bevor Sie etwas kaufen, öffnen Sie den Quelltext einer Produktseite und suchen Sie nach „hreflang“, vielleicht ist es bereits vorhanden.
Was der Core nicht zuverlässig richtig macht, ist alles an den Rändern. Und genau an diesen Rändern leben internationale Shops in der Praxis:
- x-default fehlt häufig. Die Core-Schleife gibt ein Tag pro Sprache aus, lässt aber oft den Eintrag
hreflang="x-default"weg, der Google sagt, was angezeigt werden soll, wenn keine Ihrer Sprachen zur suchenden Person passt (etwa ein niederländischer Käufer in einem EN/DE/FR-Shop). Ohne diesen Eintrag entscheidet Google für Sie. - Gleiche Sprache, mehrere Märkte ist nicht automatisch gelöst. Eine PrestaShop-Sprache hat Felder für Locale und Sprachcode, ein regionaler Wert ist also nicht unmöglich, aber der Core baut nicht automatisch die komplexen marktspezifischen Cluster, die Sie brauchen, wenn Sie sowohl Österreich als auch Deutschland auf Deutsch oder das Vereinigte Königreich und die USA auf Englisch bedienen.
de-ATvonde-DEüber diese Alternativen hinweg zu unterscheiden, müssen Sie einrichten und prüfen; das erkennt die Standard-hreflang-Schleife nicht von selbst. Prüfen Sie die tatsächlich ausgegebenen hreflang-Werte aus Locale/Code der jeweiligen Sprache, statt anzunehmen, dass sie den gewünschten Markt ansprechen. - Multistore teilt die Menge auf. Wenn Sie separate Shops pro Land betreiben (siehe PrestaShop Multistore), kennt jeder Shop nur seine eigenen Sprachen.
store-de.comundstore-fr.comdazu zu bringen, sich gegenseitig in einem hreflang-Cluster zu referenzieren, ist genau der Fall, den der Core nicht für Sie zusammensetzt. - Individuelle und Child-Themes lassen es fallen. Themes, die
head.tplüberschreiben oder den Hook entfernen, können den hreflang-Block stillschweigend entfernen. Erstaunlich viele Fälle von „fehlendem hreflang“ sind schlicht Themes, die das Partial nicht mehr ausgeben.
Die eigentliche Frage in PrestaShop lautet deshalb selten „habe ich hreflang?“. Sie lautet: „Ist die Menge vollständig, wechselseitig und auf kanonische URLs gerichtet?“, und das ist eine Prüfaufgabe, kein Kaufgrund.
Zuerst die richtige URL-Struktur schaffen
Hreflang zeigt auf URLs, also kann es nur so sauber sein wie die mehrsprachige URL-Struktur darunter. PrestaShop gibt Ihnen hier eine Wahl, die Sie unter Shop-Einstellungen → Traffic & SEO → SEO & URLs festlegen (und für die Option mit Domains pro Sprache zusätzlich in Shop-URL festlegen bzw. den Multistore-URL-Einstellungen). Es gibt drei realistische Varianten und jeweils klare hreflang-Folgen:
| Struktur | Beispiel | Auswirkung auf hreflang | Am besten, wenn … |
|---|---|---|---|
| Unterordner (ISO im Pfad) | store.com/de/, store.com/fr/ | Am saubersten. Eine Domain, ein SSL-Zertifikat, die Sprachlinks des Cores lösen natürlich auf. | Die meisten Shops. Der vernünftige Standard für einen einzelnen mehrsprachigen Shop. |
| Subdomain | de.store.com, fr.store.com | Funktioniert, aber jede Alternative muss den vollständigen Subdomain-Host verwenden, leicht falsch zu konfigurieren. | Sie brauchen infrastrukturelle Trennung, aber keine separaten rechtlichen Einheiten. |
| Länderdomain (ccTLD) | store.de, store.fr | Stärkstes Geo-Signal, schwierigstes hreflang, Alternativen zeigen über verschiedene Domains, meist über Multistore. | Ernsthafte länderspezifische Aktivitäten mit lokalen Vertrauens- und Zahlungsanforderungen. |
Eine PrestaShop-spezifische Falle steckt in der Sprachkonfiguration (International → Lokalisierung → Sprachen), in der zwei getrennte Felder wichtig sind. Das URL-Pfadpräfix wird aus dem zweibuchstabigen ISO-Code gebildet; eine Sprache mit nachlässig gesetztem ISO-Code erzeugt also einen nachlässigen Pfad. Der hreflang-Wert kommt dagegen aus der Locale / dem Sprachcode der Sprache. Ein Problem mit dem falschen Sprach-Tag und ein Problem mit dem falschen URL-Präfix werden daher an unterschiedlichen Stellen behoben. Prüfen Sie den ISO-Code, wenn Ihre Pfade falsch aussehen, und prüfen Sie Locale/Sprachcode, wenn die ausgegebenen hreflang-Werte falsch aussehen, und korrigieren Sie die Sprache, nicht das Tag von Hand. Währungen, Steuern und das breitere Setup für den EU-Verkauf, das danebensteht, behandeln wir in Verkaufen in Europa mit PrestaShop; dieser Beitrag bleibt bewusst auf der hreflang-Spur.
Die vier Fehler, die hreflang stillschweigend entwerten
Hreflang scheitert leise. Es gibt keinen Fehler in Ihrem Shop, keine kaputte Seite, Google ignoriert die Annotation einfach und beginnt wieder zu raten. Diese vier Punkte erklären fast jeden realen Fehlerfall:
- Fehlende Rückverweise (nicht wechselseitige Sets). Wenn Ihre EN-Seite die DE-Seite als deutsche Alternative aufführt, muss die DE-Seite zurück auf die EN-Seite verweisen. Hreflang ist ein Handschlag; ein einseitiges Winken wird verworfen. Das ist der häufigste Fehler überhaupt, und er trifft besonders Multistore-Setups, bei denen jeder Shop naturgemäß nur die halbe Verbindung kennt.
- Falsche Sprachcodes. Der Wert muss ein echter ISO 639-1-Sprachcode sein, optional ergänzt um ein ISO 3166-1-Land.
en-GBist gültig;en-UKist es nicht (das Land ist GB).cssteht für Tschechisch, nichtcz. PrestaShop lässt Sie problemlos einen falschen ISO-Code in die Sprachkonfiguration schreiben, und der wandert direkt ins Tag. - Verweise auf nicht kanonische URLs. Wenn Ihre kanonische URL
https://store.com/de/ist, Ihr hreflang aber aufhttp://store.com/dezeigt (kein SSL, abweichender abschließender Slash oder ein?-Parameter), sieht Google eine andere URL und verwirft die Annotation. In PrestaShop entsteht das am häufigsten durch gemischte http/https-Konfiguration oder dadurch, dass die kanonische URL der benutzerfreundlichen URL nicht zu dem passt, was die hreflang-Schleife erzeugt. - Unvollständige Abdeckung. Hreflang auf Produkten, aber nicht auf Kategorien, CMS-Seiten oder der Startseite, verwirrt Google über ganze Bereiche der Website. Es muss für jeden Seitentyp und jede Sprache vorhanden sein, sonst wird die Inkonsistenz selbst zum Signal, dass etwas nicht stimmt.
Wenn das Core-hreflang nicht reicht: der Modulweg
Wenn Sie Ihr Setup geprüft und echte Lücken gefunden haben, kein x-default, ein individuelles Theme, das die Tags entfernt hat, länderspezifisches Targeting, das der Core nicht abbilden kann, oder ein Multistore-Cluster, das domainübergreifende Wechselseitigkeit braucht. Dann ist der Punkt erreicht, an dem ein SEO-Modul seinen Platz verdient. Die Aufgabe ist eng umrissen: auf jedem Seitentyp ein vollständiges, wechselseitiges und kanonisches hreflang-Set ausgeben, inklusive x-default, ohne dass Sie Templates von Hand bearbeiten müssen.
Unsere SEO Revolution suite verarbeitet hreflang als Teil ihrer internationalen SEO-Ebene: Sie erzeugt das Alternativ-Set für Produkte, Kategorien, CMS-Seiten und die Startseite aus Ihren aktiven PrestaShop-Sprachen, ergänzt den x-default-Eintrag, den der Core häufig auslässt, und richtet jedes Tag auf die kanonische URL, damit sich die oben genannten http/https- und Parameter-Abweichungen nicht einschleichen. Was bringt Ihnen das konkret? Sie müssen die Head-Tags nicht mehr von Hand in einem Shop auditieren, der ständig neue Seiten bekommt, und ein Theme-Upgrade kann Ihr hreflang nicht stillschweigend entfernen, weil die Tags aus dem Modul kommen und nicht aus einem Template, das Sie möglicherweise überschreiben. Die Konfiguration erfolgt im Backoffice, keine Operation an head.tpl, keine Entwicklerrechnung für ein einzeiliges Tag, das auf Tausenden von URLs korrekt sein muss. Auch hier gilt die ehrliche Grenze: Ein Modul, das perfektes hreflang ausgibt, rankt Ihren Shop nicht von selbst; es entfernt den technischen Grund, aus dem Google Ihre bereits übersetzten Seiten falsch einstufen oder falsch ausliefern würde.
Prüfen Sie es, setzen Sie es nicht voraus
Hreflang ist besonders unerbittlich, weil eine halb falsche Implementierung schlechter sein kann als gar keine: Ein defektes wechselseitiges Set kann dazu führen, dass Google dem gesamten Cluster misstraut. Prüfung ist also kein optionaler Feinschliff. Sie ist die eigentliche Arbeit. Drei Checks, in dieser Reihenfolge:
[SCREENSHOT: Browser-„Quelltext anzeigen“ einer Produktseite mit hervorgehobenen <link rel="alternate" hreflang="...">-Zeilen im <head>, mit einer Zeile pro Sprache plus x-default]- Sehen Sie zuerst in den Quelltext. Öffnen Sie eine Produktseite, suchen Sie im HTML nach „hreflang“ und zählen Sie. Sie sollten eine
rel="alternate"-Zeile pro aktiver Sprache plus einex-default-Zeile sehen. Wenn Sie null sehen, hat Ihr Theme den Block entfernt. Wenn Sie die Sprachen sehen, aber kein x-default, ist das Ihre erste Lücke. - Prüfen Sie die Wechselseitigkeit von Hand an einem Cluster. Nehmen Sie ein Produkt, öffnen Sie den Quelltext jeder Sprachversion und bestätigen Sie, dass jede Version dieselbe vollständige Menge aufführt, inklusive sich selbst. Wenn die DE-Seite nicht zurück auf EN zeigt, haben Sie einen Rückverweis-Fehler gefunden, bevor Google ihn findet.
- Vertrauen Sie danach der Sicht des Crawlers. Google Search Console hat den alten Bericht zur internationalen Ausrichtung nicht mehr. Nutzen Sie daher einen Crawler mit hreflang-Audit (Screaming Frog, Sitebulb oder den Site Audit von Ahrefs/Semrush), um fehlende Rückverweise, ungültige Codes und nicht kanonische Ziele für die gesamte Website auf einmal zu markieren. Nur so finden Sie das Problem der unvollständigen Abdeckung, weil es über Tausende URLs verteilt ist.
Häufig gestellte Fragen
Gibt PrestaShop hreflang selbst aus, oder brauche ich ein Modul?
Moderne PrestaShop-Versionen geben hreflang bereits aus. Die Standard-Themes (Classic in 1.7/8, der Hummingbird-basierte Standard in 9.x) enthalten einen hreflang-Block im Head der Seite, der Ihre aktiven Sprachen durchläuft und für jede eine rel="alternate"-Zeile ausgibt, aufgebaut über Link::getLanguageLink(). Eine unveränderte mehrsprachige Einzelshop-Installation hat daher meist funktionierendes hreflang ab Werk, öffnen Sie den Quelltext und suchen Sie nach „hreflang“, bevor Sie etwas kaufen. Ein Modul wird relevant, wenn Sie echte Lücken finden: ein fehlendes x-default, ein individuelles Theme, das den Block entfernt hat, länderspezifisches Targeting oder ein Multistore-Cluster, das domainübergreifende Wechselseitigkeit braucht.
Wie sieht ein vollständiges hreflang-Set tatsächlich aus?
Jede Sprachversion einer Seite sollte dieselbe vollständige Menge aufführen, inklusive sich selbst, plus ein x-default. Für ein EN/DE/FR-Produkt sollte jede dieser drei Seiten einen identischen Block in ihrem <head> tragen:
<link rel="alternate" hreflang="en" href="https://store.com/en/product" />
<link rel="alternate" hreflang="de" href="https://store.com/de/produkt" />
<link rel="alternate" hreflang="fr" href="https://store.com/fr/produit" />
<link rel="alternate" hreflang="x-default" href="https://store.com/en/product" />
Das x-default sagt Google, was ausgeliefert werden soll, wenn keine Ihrer Sprachen zur suchenden Person passt (etwa ein niederländischer Käufer in einem EN/DE/FR-Shop). Richten Sie jedes Tag auf die kanonische URL, gleiches Protokoll, gleicher abschließender Slash, kein verirrter ?-Parameter, sonst verwirft Google die Annotation.
Wodurch scheitert hreflang am häufigsten, ohne dass man es merkt?
Durch fehlende Rückverweise. Hreflang ist ein Handschlag: Wenn Ihre EN-Seite die DE-Seite als deutsche Alternative aufführt, muss die DE-Seite zurück auf die EN-Seite verweisen. Ein einseitiges Winken wird verworfen. Dieser Fehler trifft Multistore-Setups besonders hart, weil jeder Shop naturgemäß nur die halbe Verbindung kennt, store-de.com und store-fr.com dazu zu bringen, sich gegenseitig zu referenzieren, ist genau der Fall, den der Core nicht für Sie zusammensetzt.
Meine hreflang-Werte sind falsch, korrigiere ich das Tag oder die Sprache?
Die Sprache, niemals das Tag von Hand. Das URL-Pfadpräfix kommt aus dem zweibuchstabigen ISO-Code der Sprache, während der hreflang-Wert aus der Locale / dem Sprachcode der Sprache kommt (International → Lokalisierung → Sprachen). Ein Problem mit dem falschen Pfad und ein Problem mit dem falschen Tag werden also in unterschiedlichen Feldern behoben. Verwenden Sie einen echten ISO-639-1-Code, optional mit einem ISO-3166-1-Land: en-GB ist gültig, en-UK ist es nicht; cs steht für Tschechisch, nicht cz.
Wie prüfe ich hreflang über Tausende URLs hinweg?
Sehen Sie zuerst bei einer Seite in den Quelltext, um zu bestätigen, dass die Tags existieren und x-default enthalten. Prüfen Sie danach die Wechselseitigkeit von Hand an einem Produkt-Cluster. Anschließend vertrauen Sie einem Crawler. Google Search Console hat den alten Bericht zur internationalen Ausrichtung nicht mehr. Nutzen Sie daher Screaming Frog, Sitebulb oder den Site Audit von Ahrefs/Semrush, um fehlende Rückverweise, ungültige Codes und nicht kanonische Ziele siteweit zu markieren. Das ist der einzige praktische Weg, unvollständige Abdeckung zu finden, weil sie über den gesamten Katalog verteilt ist.
Weiterführende Lektüre
- Mehrsprachiges Shop-Setup, bringen Sie den übersetzten Shop und die URLs pro Sprache in Ordnung, bevor Sie sich um hreflang kümmern.
- PrestaShop Multistore. Dort wird domainübergreifende hreflang-Wechselseitigkeit zum schwierigen Teil.
- Währungsauswahl und Sprachflaggen, der sichtbare Umschalter für Menschen, den hreflang ergänzt, aber nicht ersetzen kann.
Das Prinzip darunter ist dasselbe, das sich durch den Rest dieses Themenclusters zieht: Ein Shop, der grenzüberschreitend verkauft, besteht aus vielen kleinen, exakten Signalen, der richtigen Währung, der richtigen Sprachflagge, der richtigen Steuerzeile und dem richtigen hreflang, jedes für sich günstig, jedes in der Lage, Wert zu verlieren, wenn es leicht falsch ist. Sorgen Sie dafür, dass Sprache und Währung in der Nutzererfahrung stimmen, damit Besucher bleiben (Währungsauswahl und Sprachflaggen), kalkulieren und berechnen Sie korrekt pro Markt (Mehrwährung und internationaler Verkauf), und lassen Sie hreflang sicherstellen, dass die Suchmaschine jeden Käufer zu der Version schickt, die Sie für ihn gebaut haben. In PrestaShop bedeutet das: Wissen, dass der Core bereits den Großteil der Arbeit erledigt, und Ihre Mühe auf x-default, Wechselseitigkeit und die Übereinstimmung mit der kanonischen URL verwenden, die darüber entscheiden, ob es tatsächlich zählt.
Kommentare
Kommentar schreiben
Teilen Sie eine Frage, ein Installationsdetail oder Feedback, das anderen Lesern helfen kann.