PrestaShop 9.2 Structured Data and Multilingual Route Changes

A theme update and a core update can each produce valid-looking structured data while the combined page describes the same product twice with conflicting values. That is the kind of integration problem worth looking for in PrestaShop 9.2.

The 9.2 changes include core-side structured-data work, follow-up handling for invalid product and category URLs, and multilingual entity-route configuration. These are concrete rendering and routing changes. They do not establish a ranking improvement, and this article does not repeat a general SEO checklist. Core structured-data change, follow-up refinement, multilingual routes.

Use the checks below on the 9.2 RC1 candidate available as of September 26, 2026, with the exact theme and SEO-module versions recorded.

In a multi-shop deployment, combine this rendering audit with the PrestaShop 9.2 multistore checks so a correct URL is also evaluated in the correct shop context.

Move the audit boundary from template fragments to final output

The core-side structured-data direction allows data to be prepared in application code and rendered through the theme. That changes where an extension can contribute and where duplicate ownership can arise. The official demoseo example is a useful source reference for the new integration direction. Official structured-data example.

Begin by listing every component that can emit product or organization data: the core, theme, child-theme overrides and modules. Identify the owner of each field or entity representation. Do not assume a module stopped emitting markup simply because the core gained a new capability.

Then inspect the rendered page. A source-code review alone cannot prove the final result because multiple hooks and templates can contribute. Conversely, a validator result alone may not explain which component emitted an incorrect value.

Choose one ordinary product fixture first. Capture the page response and parse every JSON-LD block. Compare identifiers, names, URLs and commercial values with the visible page. Use the rendered result as the acceptance artifact and the source inventory as the explanation of ownership.

Detect contradictory descriptions before adding more markup

Multiple structured-data blocks are not inherently wrong. The problem is contradictory or disconnected descriptions of the same entity. A theme and module may each emit a product with different prices, availability or identifiers.

For each product representation, determine whether it refers to the same entity and whether its values agree. If two components own the same fact, decide which should be authoritative. Do not remove an entire block merely because there is more than one script element; it may describe a different legitimate entity.

Pay attention to module-added values such as reviews or policies. Their presence should be supported by actual store content and the module’s intended data contract. Do not invent ratings or policy information to make a validation report look more complete.

For a child theme, compare inherited templates with local overrides. An old override may retain legacy output while the parent adopts the core-side path. The fix should address the ownership conflict rather than applying a broad text replacement to every script on the page.

Keep any external search-result claims separate. Correct markup is an implementation result. Whether a search engine displays a particular enhancement is another question and is not guaranteed by this release change.

Use fixtures that expose transformation mistakes

A plain product name and short description may hide problems in text conversion. Add a synthetic description with adjacent paragraphs, emphasis and non-ASCII characters. Inspect the structured-data text and compare it with the intended readable content.

The follow-up 9.2 PR references a new HTML-to-text conversion path for descriptions and handling of nonsensical product and category URLs. Those details justify targeted regression cases without implying that every SEO behavior changed. Structured-data refinement #42016.

Check a product with combinations if the shop uses them. Select a different combination through the supported interface and inspect which structured representation the page emits. The expected representation should match the theme and core contract, not an assumption copied from another store.

For missing optional data, confirm that the output remains coherent. An absent image or description should not cause a script syntax error or cause another product’s value to be reused. Use fixtures that deliberately leave optional content unset.

These are proposed integration tests. They do not assert that the candidate has each failure described.

Product features and shop contact details have a concrete RC change

The RC1 release also includes a change adding product features through additionalProperty and configured shop contact details to organization data. This is a specific output addition, separate from the earlier move toward core-side rendering. Product-feature and contact-data change #42571.

Give the fixture product two recognizable feature values and compare them with the emitted properties. For a multistore theme, inspect contact details in each shop context and confirm that the output describes the selected shop. If another module already emits the same information, review ownership before retaining both representations. Do not add invented contact values simply to fill an optional field.

Inspect missing entities as a separate page class

Request a controlled nonexistent product or category URL in staging. Capture the HTTP result, the visible page and any structured data. The page should not misleadingly describe a successful product offer for an entity that does not exist.

Do not test this only by changing a slug on an existing identifier. Depending on the router’s documented behavior, that may resolve or redirect to a real entity. Use a fixture whose identity genuinely does not exist and distinguish it from an inactive or unavailable product.

If a custom error-page module or theme override participates, include it in the ownership inventory. A core fix cannot establish the correctness of markup added later by an extension.

Preserve the response before applying browser-side modifications. If a script changes the page after load, record that separately so the team can distinguish server output from client behavior.

A missing-page case belongs in this release audit because the cited 9.2 refinement touches it. It should not expand into an unrelated guide to every redirect or indexing policy in the store.

Multilingual route configuration is more than translated slugs

The multilingual-route change allows route patterns for entities to vary by language. The PR gives language-specific path wording as the motivating example. That is distinct from translating an individual product’s rewritten name. Entity-route change #41405.

In a two-language fixture, record the route pattern and an actual generated entity URL in each language. Follow those generated links and verify that they resolve to the expected entity and language. Avoid manually constructing a URL that the application would never generate.

Then switch languages through the storefront and inspect the destination. Check the URL produced by a module that links to the same entity. A module that concatenates a fixed path segment may ignore the newly configurable language pattern.

A separate verified RC fix preserves pagination in product-listing hreflang URLs. Previously, language alternatives could point to the first page while the canonical represented a later page. This is a narrow pagination correction, not a claim that every language-annotation issue is solved. Hreflang pagination fix #42725.

Use a category with enough products for several pages and inspect a later page in two languages. Follow the alternative-language links and confirm that they retain the intended page position. Include the first page as a separate case and inspect reciprocal alternatives. Keep this test distinct from route-pattern translation: one concerns pagination state, while the other concerns the language-specific path pattern.

Verify defaults before saving the route form

A follow-up fix addresses default route values not appearing correctly for every language in the SEO and URLs form when configuration is absent or still represented in an earlier form. The PR provides a specific fresh-configuration reproduction. Per-language default fix #42241.

Test a fresh candidate installation before customizing the patterns. Open the form and verify that each relevant language shows a valid default. Save without intentional changes, reopen and confirm that the values remain valid.

Next, configure a deliberate language difference through the supported form and repeat the generated-link checks. This distinguishes default population from custom pattern persistence.

Do not clear configuration rows on a live store to recreate the upstream case. A fresh test database provides the required condition without risking published URLs. If an existing configuration needs investigation, use a controlled copy and preserve its original values.

Compare a fresh theme with the customized theme

When contradictory markup appears, reproduce the fixture on the supported unmodified theme revision in a separate test instance. Keep the core and module versions equivalent. Then introduce the child-theme overrides and relevant SEO modules one at a time.

This comparison can identify which layer adds the conflicting entity or stale value. It does not establish that every customization is wrong; a module may intentionally provide data the base theme lacks. The question is whether the combined representation remains coherent.

Save parsed objects with their originating script index and, where your inspection can establish it, the responsible component. Avoid deleting output based solely on script order, because order can change without changing ownership.

Once the responsible layer is identified, retest the ordinary product, the missing entity and both language routes. A correction to one template can affect more than the page where the discrepancy was first noticed.

Keep the final output comparison small enough for a theme maintainer to review without reconstructing the entire store.

Keep a small, reviewable output comparison

For each fixture, save the selected URL, language, response status, parsed structured-data objects and relevant visible values. The following browser-console snippet only inventories JSON-LD blocks on the page currently open; it does not validate search eligibility:

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 })));

Use a dedicated validator and manual semantic review for the next stage. Valid JSON is necessary for a JSON-LD script but does not establish that its facts describe the page correctly.

The 9.2 audit should end with clear ownership of emitted data and verified language-route behavior. Fix contradictions and failed defaults at their source, then retain the fixtures so a later theme or module update can be checked against the same evidence.

For the underlying platform context, see our PrestaShop 9 SEO guide and apply the version-specific checks above to the installation you are evaluating.