PrestaShop 9.2: Änderungen an strukturierten Daten und mehrsprachigen Routen
Eine Theme-Aktualisierung und eine Core-Aktualisierung können jeweils gültig wirkende strukturierte Daten erzeugen, während die zusammengesetzte Seite dasselbe Produkt zweimal mit widersprüchlichen Werten beschreibt. Nach solchen Integrationsproblemen lohnt es sich in PrestaShop 9.2 zu suchen.
Die Änderungen in 9.2 umfassen Arbeiten an strukturierten Daten im Core, eine nachfolgende Behandlung ungültiger Produkt- und Kategorie-URLs sowie die Konfiguration mehrsprachiger Entitätsrouten. Dies sind konkrete Änderungen am Rendering und Routing. Sie belegen keine Verbesserung des Rankings, und dieser Artikel wiederholt keine allgemeine SEO-Checkliste. Änderung strukturierter Daten im Core, nachfolgende Verbesserung, mehrsprachige Routen.
Führen Sie die folgenden Prüfungen mit dem zum 26. September 2026 verfügbaren 9.2-RC1-Kandidaten durch und dokumentieren Sie die genauen Theme- und SEO-Modulversionen.
Kombinieren Sie diese Rendering-Prüfung bei einem Multistore-Betrieb mit den Multistore-Prüfungen für PrestaShop 9.2 damit eine korrekte URL auch im richtigen Shopkontext bewertet wird.
Verlagern Sie die Prüfgrenze von Template-Fragmenten auf die endgültige Ausgabe
Der Ansatz strukturierter Daten im Core ermöglicht es, Daten im Anwendungscode vorzubereiten und über das Theme auszugeben. Das verändert die Stellen, an denen eine Erweiterung beitragen kann und doppelte Zuständigkeiten entstehen können. Das offizielle Beispiel demoseo ist eine nützliche Quellreferenz für die neue Integrationsrichtung. Offizielles Beispiel für strukturierte Daten.
Listen Sie zunächst alle Komponenten auf, die Produkt- oder Organisationsdaten ausgeben können: Core, Theme, Überschreibungen des Child-Themes und Module. Bestimmen Sie die Zuständigkeit für jedes Feld oder jede Entitätsdarstellung. Nehmen Sie nicht an, dass ein Modul kein Markup mehr ausgibt, nur weil der Core eine neue Fähigkeit erhalten hat.
Prüfen Sie anschließend die gerenderte Seite. Eine reine Quellcodeprüfung kann das Endergebnis nicht belegen, weil mehrere Hooks und Templates beitragen können. Umgekehrt erklärt ein Validatorergebnis allein möglicherweise nicht, welche Komponente einen falschen Wert ausgegeben hat.
Wählen Sie zuerst einen gewöhnlichen Produkttestdatensatz. Erfassen Sie die Seitenantwort und parsen Sie jeden JSON-LD-Block. Vergleichen Sie Kennungen, Namen, URLs und kaufmännische Werte mit der sichtbaren Seite. Verwenden Sie das gerenderte Ergebnis als Abnahmenachweis und den Quellenbestand als Erklärung der Zuständigkeiten.
Erkennen Sie widersprüchliche Beschreibungen, bevor Sie weiteres Markup hinzufügen
Mehrere Blöcke strukturierter Daten sind nicht grundsätzlich falsch. Das Problem sind widersprüchliche oder unverbundene Beschreibungen derselben Entität. Ein Theme und ein Modul können jeweils ein Produkt mit unterschiedlichen Preisen, Verfügbarkeiten oder Kennungen ausgeben.
Bestimmen Sie für jede Produktdarstellung, ob sie dieselbe Entität bezeichnet und ob ihre Werte übereinstimmen. Wenn zwei Komponenten für denselben Sachverhalt zuständig sind, entscheiden Sie, welche maßgeblich sein soll. Entfernen Sie nicht einen ganzen Block, nur weil mehrere script-Elemente vorhanden sind; er kann eine andere berechtigte Entität beschreiben.
Achten Sie auf von Modulen hinzugefügte Werte wie Bewertungen oder Richtlinien. Ihr Vorhandensein sollte durch tatsächliche Shopinhalte und den vorgesehenen Datenvertrag des Moduls belegt sein. Erfinden Sie keine Bewertungen oder Richtlinienangaben, um einen Validierungsbericht vollständiger wirken zu lassen.
Vergleichen Sie bei einem Child-Theme geerbte Templates mit lokalen Überschreibungen. Eine alte Überschreibung kann die bisherige Ausgabe beibehalten, während das übergeordnete Theme den Core-seitigen Weg übernimmt. Die Korrektur sollte den Zuständigkeitskonflikt beheben, statt eine pauschale Textersetzung auf jedes Skript der Seite anzuwenden.
Halten Sie Aussagen über externe Suchergebnisse getrennt. Korrektes Markup ist ein Implementierungsergebnis. Ob eine Suchmaschine eine bestimmte Erweiterung anzeigt, ist eine andere Frage und wird durch diese Versionsänderung nicht garantiert.
Verwenden Sie Testdatensätze, die Transformationsfehler sichtbar machen
Ein einfacher Produktname und eine kurze Beschreibung können Probleme bei der Textkonvertierung verbergen. Ergänzen Sie eine synthetische Beschreibung mit aufeinanderfolgenden Absätzen, Hervorhebungen und Nicht-ASCII-Zeichen. Prüfen Sie den Text der strukturierten Daten und vergleichen Sie ihn mit dem beabsichtigten lesbaren Inhalt.
Der nachfolgende 9.2-PR verweist auf einen neuen HTML-zu-Text-Konvertierungsweg für Beschreibungen und auf die Behandlung unsinniger Produkt- und Kategorie-URLs. Diese Details rechtfertigen gezielte Regressionsfälle, ohne zu unterstellen, dass sich jedes SEO-Verhalten geändert hat. Verbesserung strukturierter Daten #42016.
Prüfen Sie ein Produkt mit Varianten, sofern der Shop sie verwendet. Wählen Sie über die unterstützte Oberfläche eine andere Variante und prüfen Sie, welche strukturierte Darstellung die Seite ausgibt. Die erwartete Darstellung sollte dem Vertrag von Theme und Core entsprechen und keiner aus einem anderen Shop übernommenen Annahme.
Bestätigen Sie bei fehlenden optionalen Daten, dass die Ausgabe stimmig bleibt. Ein fehlendes Bild oder eine fehlende Beschreibung darf weder einen Skript-Syntaxfehler auslösen noch zur Wiederverwendung eines Werts eines anderen Produkts führen. Verwenden Sie Testdatensätze, bei denen optionale Inhalte absichtlich nicht gesetzt sind.
Dies sind vorgeschlagene Integrationstests. Sie behaupten nicht, dass der Kandidat jeden beschriebenen Fehler aufweist.
Für Produktmerkmale und Shopkontaktdaten gibt es eine konkrete RC-Änderung
Die RC1-Version enthält auch eine Änderung, die Produktmerkmale über additionalProperty und konfigurierte Shopkontaktdaten zu den Organisationsdaten hinzufügt. Dies ist eine konkrete Ergänzung der Ausgabe, getrennt vom früheren Wechsel in Richtung Core-seitiges Rendering. Änderung von Produktmerkmalen und Kontaktdaten #42571.
Geben Sie dem Testprodukt zwei erkennbare Merkmalswerte und vergleichen Sie sie mit den ausgegebenen Eigenschaften. Prüfen Sie bei einem Multistore-Theme die Kontaktdaten in jedem Shopkontext und bestätigen Sie, dass die Ausgabe den ausgewählten Shop beschreibt. Wenn ein anderes Modul dieselben Informationen bereits ausgibt, prüfen Sie die Zuständigkeiten, bevor Sie beide Darstellungen beibehalten. Fügen Sie keine erfundenen Kontaktwerte hinzu, nur um ein optionales Feld zu füllen.
Prüfen Sie fehlende Entitäten als eigene Seitenklasse
Rufen Sie in der Staging-Umgebung eine kontrollierte URL für ein nicht vorhandenes Produkt oder eine nicht vorhandene Kategorie auf. Erfassen Sie das HTTP-Ergebnis, die sichtbare Seite und alle strukturierten Daten. Die Seite darf nicht irreführend ein gültiges Produktangebot für eine nicht existierende Entität beschreiben.
Testen Sie dies nicht nur durch Ändern eines Slugs bei einer bestehenden Kennung. Je nach dokumentiertem Routerverhalten kann dies zu einer echten Entität führen oder weiterleiten. Verwenden Sie einen Testdatensatz, dessen Identität tatsächlich nicht existiert, und unterscheiden Sie ihn von einem inaktiven oder nicht verfügbaren Produkt.
Wenn ein individuelles Fehlerseitenmodul oder eine Theme-Überschreibung beteiligt ist, nehmen Sie es in den Zuständigkeitsbestand auf. Eine Core-Korrektur kann nicht die Richtigkeit von Markup belegen, das später durch eine Erweiterung hinzugefügt wird.
Bewahren Sie die Antwort vor browserseitigen Änderungen auf. Wenn ein Skript die Seite nach dem Laden verändert, dokumentieren Sie dies separat, damit das Team Serverausgabe und Clientverhalten unterscheiden kann.
Ein Fall mit fehlender Seite gehört in diese Versionsprüfung, weil die angeführte 9.2-Verbesserung ihn betrifft. Er sollte sich nicht zu einem sachfremden Leitfaden für sämtliche Weiterleitungs- oder Indexierungsrichtlinien des Shops ausweiten.
Mehrsprachige Routenkonfiguration bedeutet mehr als übersetzte Slugs
Die Änderung mehrsprachiger Routen ermöglicht sprachabhängige Routenmuster für Entitäten. Der PR nennt eine sprachspezifische Formulierung des Pfads als motivierendes Beispiel. Das unterscheidet sich von der Übersetzung des umgeschriebenen Namens eines einzelnen Produkts. Änderung der Entitätsrouten #41405.
Erfassen Sie bei einem zweisprachigen Testdatensatz das Routenmuster und eine tatsächlich erzeugte Entitäts-URL in jeder Sprache. Folgen Sie diesen erzeugten Links und prüfen Sie, dass sie zur erwarteten Entität und Sprache führen. Vermeiden Sie das manuelle Erstellen einer URL, die die Anwendung nie erzeugen würde.
Wechseln Sie anschließend über die Shopoberfläche die Sprache und prüfen Sie das Ziel. Prüfen Sie die URL eines Moduls, das auf dieselbe Entität verlinkt. Ein Modul, das ein festes Pfadsegment zusammensetzt, kann das neu konfigurierbare Sprachmuster ignorieren.
Eine separate verifizierte RC-Korrektur erhält die Seitennummerierung in hreflang-URLs von Produktlisten. Zuvor konnten Sprachalternativen auf die erste Seite zeigen, während die kanonische URL eine spätere Seite repräsentierte. Dies ist eine eng begrenzte Korrektur der Seitennummerierung und keine Behauptung, dass jedes Problem der Sprachauszeichnung gelöst ist. Korrektur der hreflang-Seitennummerierung #42725.
Verwenden Sie eine Kategorie mit genügend Produkten für mehrere Seiten und prüfen Sie eine spätere Seite in zwei Sprachen. Folgen Sie den Links zur alternativen Sprache und bestätigen Sie, dass sie die vorgesehene Seitenposition erhalten. Berücksichtigen Sie die erste Seite als separaten Fall und prüfen Sie die gegenseitigen Alternativen. Halten Sie diesen Test von der Übersetzung der Routenmuster getrennt: Der eine betrifft den Zustand der Seitennummerierung, der andere das sprachspezifische Pfadmuster.
Prüfen Sie Standardwerte vor dem Speichern des Routenformulars
Eine nachfolgende Korrektur betrifft Standardroutenwerte, die im Formular SEO und URLs nicht für jede Sprache korrekt erscheinen, wenn eine Konfiguration fehlt oder noch in einer früheren Form vorliegt. Der PR enthält eine konkrete Reproduktion mit neuer Konfiguration. Korrektur sprachabhängiger Standardwerte #42241.
Testen Sie eine neue Kandidateninstallation, bevor Sie die Muster anpassen. Öffnen Sie das Formular und prüfen Sie, dass jede relevante Sprache einen gültigen Standardwert anzeigt. Speichern Sie ohne beabsichtigte Änderungen, öffnen Sie es erneut und bestätigen Sie, dass die Werte gültig bleiben.
Konfigurieren Sie als Nächstes über das unterstützte Formular einen bewussten Sprachunterschied und wiederholen Sie die Prüfungen der erzeugten Links. So unterscheiden Sie das Befüllen der Standardwerte von der Speicherung individueller Muster.
Löschen Sie keine Konfigurationszeilen in einem produktiven Shop, um den Fall aus dem Ursprungsprojekt nachzustellen. Eine neue Testdatenbank schafft die erforderliche Bedingung, ohne veröffentlichte URLs zu gefährden. Wenn eine bestehende Konfiguration untersucht werden muss, verwenden Sie eine kontrollierte Kopie und bewahren Sie ihre ursprünglichen Werte auf.
Vergleichen Sie ein unverändertes Theme mit dem angepassten Theme
Wenn widersprüchliches Markup erscheint, reproduzieren Sie den Testdatensatz mit der unterstützten, unveränderten Theme-Revision in einer separaten Testinstanz. Halten Sie Core- und Modulversionen gleichwertig. Fügen Sie danach die Child-Theme-Überschreibungen und relevanten SEO-Module einzeln hinzu.
Dieser Vergleich kann zeigen, welche Schicht die widersprüchliche Entität oder den veralteten Wert hinzufügt. Er belegt nicht, dass jede Anpassung falsch ist; ein Modul kann absichtlich Daten bereitstellen, die im Basistheme fehlen. Die Frage ist, ob die zusammengesetzte Darstellung stimmig bleibt.
Speichern Sie die geparsten Objekte mit dem Index ihres Ursprungsskripts und, soweit Ihre Prüfung dies feststellen kann, der verantwortlichen Komponente. Vermeiden Sie das Löschen von Ausgaben allein aufgrund der Skriptreihenfolge, weil sich die Reihenfolge ohne Änderung der Zuständigkeit ändern kann.
Testen Sie nach Identifizierung der verantwortlichen Schicht das gewöhnliche Produkt, die fehlende Entität und beide Sprachrouten erneut. Eine Korrektur an einem Template kann mehr als nur die Seite beeinflussen, auf der die Abweichung zuerst aufgefallen ist.
Halten Sie den Vergleich der endgültigen Ausgabe klein genug, damit ein Theme-Betreuer ihn prüfen kann, ohne den gesamten Shop nachzubauen.
Bewahren Sie einen kleinen, gut prüfbaren Ausgabevergleich auf
Speichern Sie für jeden Testdatensatz die ausgewählte URL, Sprache, den Antwortstatus, die geparsten strukturierten Datenobjekte und relevante sichtbare Werte. Der folgende Ausschnitt für die Browserkonsole erfasst nur die JSON-LD-Blöcke auf der gerade geöffneten Seite; er validiert nicht die Eignung für Suchergebnisse:
const results = [...document.querySelectorAll('script[type="application/ld+json"]')]
.map((node, index) => {
try {
return { index, validJson: true, value: JSON.parse(node.textContent) };
} catch (error) {
return { index, validJson: false, error: String(error) };
}
});
console.table(results.map(({ index, validJson }) => ({ index, validJson })));
Verwenden Sie im nächsten Schritt einen spezialisierten Validator und eine manuelle semantische Prüfung. Gültiges JSON ist für ein JSON-LD-Skript notwendig, belegt aber nicht, dass seine Angaben die Seite richtig beschreiben.
Die 9.2-Prüfung sollte mit klaren Zuständigkeiten für ausgegebene Daten und verifiziertem Verhalten der Sprachrouten enden. Beheben Sie Widersprüche und fehlerhafte Standardwerte an ihrer Quelle und bewahren Sie die Testdatensätze auf, damit spätere Theme- oder Modulaktualisierungen anhand derselben Nachweise geprüft werden können.
Zum Kontext der zugrunde liegenden Plattform lesen Sie unseren SEO-Leitfaden für PrestaShop 9 und wenden Sie die obigen versionsspezifischen Prüfungen auf die bewertete Installation an.