SEO Technical Pack

The SEO Technical Pack is the PrestaShop SEO module bundle aimed at the technical signals Google uses to crawl, understand and consolidate your store. It groups four of our modules: Advanced SEO Sitemap Builder for XML/HTML sitemaps, Automatic SEO Schema Rich Snippets for Schema.org structured data, Product Canonical Manager for canonical and noindex control, and Hreflang Tags Manager for multilingual targeting.

It differs from the full Smart SEO Revolution Suite because it sticks to infrastructure, not every SEO workflow. Pick this pack when your priority is crawl discovery, structured data, duplicate-content control and correct language targeting, and you would rather not buy each technical module on its own.

An XML sitemap is a machine-readable file written for search engines. It lists URLs together with metadata (last-modified date, hreflang alternates, image references) and is submitted to Google Search Console or Bing Webmaster Tools. Its job is discovery: helping crawlers find and prioritise pages they might otherwise miss.

An HTML sitemap is an ordinary page on your shop, made for human visitors. It lists links to categories, products, CMS pages and manufacturers in a readable structure. Its job is navigation and internal linking. It gives visitors a backup index and gives crawlers another set of links into deeper pages.

You generally want both: the XML sitemap is the one search engines actually consume, while the HTML sitemap is optional but handy on large catalogues. Our Advanced SEO Sitemap Builder generates XML sitemaps with hreflang alternates and image entries, automatically splits large catalogues at the 50,000-URL search-engine limit into a sitemap index, and can publish an HTML sitemap page as well.

The sitemap builder is not just a URL dump. Its module description and pipeline are built around verified XML sitemaps: URLs can be crawled and checked for HTTP status, canonical and noindex before being written. The stored URL rows include entity type, language, shop, status, canonical and image/hreflang metadata, so the final sitemap can be based on URLs that passed verification rather than every possible catalogue URL.

For XML output, the writer includes the standard sitemap namespace and adds image and XHTML namespaces when image or hreflang output is enabled. Each URL can receive <loc>, <lastmod>, <changefreq>, <priority>, image entries and alternate-language links. Large output is split by the configured maximum URL count and file size, and a sitemap index points crawlers at the generated files.

The HTML sitemap is different by design. It uses verified URLs for the current shop and language, groups them by type such as home, product, category, CMS, manufacturer, supplier, core, hook or custom, and renders them as a normal page. In the inspected front controller the HTML sitemap page is marked noindex, so treat it mainly as a user navigation and internal-linking page, not as another landing page you expect to rank.

For merchants, the practical setup is: enable the entity types you actually want indexed, keep image and hreflang output on for multilingual/image-heavy catalogues, submit the XML sitemap index in Search Console, and link the HTML sitemap only where it helps visitors.

Short version: Yoast is a WordPress plugin and has no PrestaShop equivalent, so there's nothing to integrate with there. If you mean another PrestaShop SEO module, our modules can run alongside it. The thing to manage is overlap.

The risk with any two SEO tools is duplicate output: two canonical tags, two sets of Open Graph tags, two JSON-LD blocks. Search engines dislike that. So decide, per feature, which tool is the source of truth and turn the duplicate off in the other.

Our own modules are built to cooperate, not collide. The Smart SEO Revolution Suite actively de-duplicates against the theme: when it renders its own hreflang or Open Graph tags, it strips the theme's matching tags from the page head, and it can optionally clean foreign JSON-LD too. Blog Revolution goes further and hands blog structured data over to SEO Revolution when that module is set to emit it, so you never get two blog schemas.

Common mistake: enabling the same feature in two modules and assuming "more is better." Pick one owner per feature and you'll have clean, single output.

A missing markup warning means the tool did not find the schema type or required field on that URL. In Schema Revolution, first check that the schema type is enabled for that page type, then compare the module preview with the final page source after cache is cleared, and finally test the live URL in Google's Rich Results Test or Schema.org's validator.

The module builds JSON-LD based on the detected page type. Depending on configuration it can output Organization and WebSite on the homepage, BreadcrumbList on non-home pages, Product schema on product pages, CollectionPage for categories, and Article for CMS pages. Product schema can include name, URL, description, SKU, GTIN, MPN, brand from the configured catalogue source, images, condition, offers, availability, shipping details, return policy, ratings, reviews, weight and category data when the shop has that data available.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Example product",
  "url": "https://example.com/product.html",
  "description": "Short product description",
  "sku": "REF-123",
  "gtin13": "1234567890128",
  "offers": {
    "@type": "Offer",
    "price": "29.99",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}

If Google reports missing fields, compare three things: the module preview, the final HTML source after PrestaShop and external caches are cleared, and the live URL fetched by the test tool. A field can be absent because the schema type is disabled, the page detector does not identify the page as expected, the product lacks source data such as brand or GTIN, cached HTML is still being served, or another theme/module changes the final output.

Be careful with the cleanup options. They are intended to remove older microdata and duplicate JSON-LD, but the current JSON-LD cleanup preserves only scripts marked with <!-- mprschema -->, while the module's header output is unmarked. With clean_existing_jsonld enabled, including its default state, the cleanup can remove the module's own schema from the final HTML. If tools show missing schema, disable/fix JSON-LD cleanup or add the expected marker before assuming another module is at fault.

In the module configuration, open Schema Revolution > Configuration > Schema Types. Enable the missing type there: Product Schema, Organization Schema, WebSite Schema, Breadcrumb Schema, Category Schema or CMS Article Schema, depending on the URL being tested.

If the schema exists in preview but disappears from the final HTML, disable Remove Existing JSON-LD in the same Schema Types tab while testing. That option removes unmarked application/ld+json scripts from the page before output, so it is the first setting to check when validators report that all JSON-LD is missing.

Hreflang tags fix one specific problem well: they tell Google which language or country version of a page to show each visitor, so your translated pages stop competing with each other as near-duplicate content. For a multilingual PrestaShop store they are not optional, but they are one part of the job, not the whole of it.

What hreflang will not do is rescue thin or machine-quality translations, fill in pages that only exist in one language, or fix inconsistent URL structures across your shops. Those need real content and clean URLs underneath the tags. Our Smart SEO Revolution Suite generates hreflang automatically for every active language, adds a proper x-default, stays multi-shop aware, and also includes the same references inside your XML sitemap. Get those signals right and Google can match the correct version to each searcher; the translation quality is still your call.

In the SEO Suite, hreflang output is part of the header hook. When HREFLANG_ENABLED is on, the module calls its Hreflang manager and renders <link rel='alternate' hreflang='...'> tags for the alternate URLs it can build. If more than one alternate exists, it also adds an x-default URL. If the current robots decision contains noindex, the suite returns no hreflang output for that page, which keeps noindexed pages from sending mixed signals.

<!-- MPR SEO Revolution - Hreflang Tags -->
<link rel="alternate" hreflang="en-US" href="https://example.com/en/product.html" data-mpr-seo="1" />
<link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/produit.html" data-mpr-seo="1" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/product.html" data-mpr-seo="1" />

<url>
  <loc>https://example.com/en/product.html</loc>
  <xhtml:link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/produit.html" />
</url>

The sitemap side is separate but aligned. The sitemap writer can emit xhtml:link rel='alternate' entries when it finds matching URLs for the same entity in other languages. The sitemap configuration has an INCLUDE_HREFLANG switch, so header hreflang and XML sitemap hreflang can both be controlled deliberately.

There are still real limits. Hreflang works only when there is a real alternate URL to point to. If a product exists in English but the French product is missing, disabled, noindexed or has poor translated content, the tag cannot create a good French landing page for you. Likewise, hreflang does not replace canonical tags; each language page should normally canonicalize to itself and then list its alternates.

A good multilingual SEO checklist is: keep each language URL crawlable, use self-referencing canonicals, publish complete translations for important products and categories, keep language switcher URLs consistent, include alternates in the XML sitemap, and avoid noindex on pages that are meant to participate in the hreflang cluster.

Yes. The Smart SEO Revolution Suite is our all-in-one SEO module for PrestaShop: it pulls our main SEO line into one back-office dashboard, under a single licence and one update channel, so you are not juggling several modules that each want their own settings page.

The Suite ships what these standalone modules do, plus extras:

• Advanced SEO Sitemap Builder, XML/HTML sitemaps, hreflang and image entries, with automatic splitting at the 50,000-URL limit.
• Automatic SEO Schema Rich Snippets, Product, Offer, BreadcrumbList, Organization, Article, FAQ and Review markup.
• Product Canonical Manager, canonicals, hreflang and noindex/nofollow control.
• Automatic Internal SEO Linker, keyword-to-URL internal linking suggestions across your content.

On top of that it adds meta title/description templates with token placeholders, a 301/302/410 redirect manager with hit logging, 404 monitoring, robots.txt and llms.txt editors, Open Graph and Twitter Card output, Google Search Console import, and AI bulk meta generation that can use OpenAI, Claude or Gemini.

The buying logic is simple: if you only need one feature in isolation, say, just canonicals, the matching standalone module may be the leaner choice. The Suite bundles these SEO features into one module and dashboard, so compare it against the standalone modules based on the features you actually need.

As many as your shop needs. Advanced SEO Sitemap Builder does not use a fixed number of sitemap files, and it does not name child files by entity type. It collects the enabled URL sources, verifies them, writes chunked XML files, then writes a sitemap index for the shop.

By default the module includes products, categories, CMS pages, core pages, product images and hreflang alternates. Manufacturers and suppliers are available URL sources too, but they are disabled by default in the module defaults. The writer splits output when the configured URL limit is reached, with 50,000 URLs per file as the default, and also protects the sitemap protocol's 50 MB file-size limit.

Example generated files for shop ID 1:
modules/mprsitemapbuilder/sitemaps/sitemap_index_1.xml
modules/mprsitemapbuilder/sitemaps/sitemap_1_1.xml
modules/mprsitemapbuilder/sitemaps/sitemap_1_2.xml
modules/mprsitemapbuilder/sitemaps/sitemap_1_3.xml

<sitemapindex xmlns='http://www.sitemaps.org/schemas/sitemap/0.9'>
  <sitemap>
    <loc>https://www.example.com/modules/mprsitemapbuilder/sitemaps/sitemap_1_1.xml</loc>
    <lastmod>2026-06-17T10:00:00+00:00</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/modules/mprsitemapbuilder/sitemaps/sitemap_1_2.xml</loc>
    <lastmod>2026-06-17T10:00:00+00:00</lastmod>
  </sitemap>
</sitemapindex>

Submit only the index URL in Google Search Console. Google reads the child files from the index, so you do not have to manage each generated XML file by hand. On multistore installations, each shop gets its own shop-ID-based index and child files.

Yes. With the Product Canonical Manager you set per-entity rules for products, categories, manufacturers, suppliers and CMS pages, and it writes the selected noindex and/or nofollow directives into the page's robots meta tag. The same module regenerates hreflang tags from your active shop languages and adds x-default for your default language, so each language version points at the right alternates.

In the page <head> the rules render as the standard tags search engines read, a single canonical, the robots directive, and one hreflang alternate per language plus x-default:

<link rel="canonical" href="https://yourshop.com/en/blue-widget" />
<meta name="robots" content="noindex, follow" />
<link rel="alternate" hreflang="en" href="https://yourshop.com/en/blue-widget" />
<link rel="alternate" hreflang="de" href="https://yourshop.com/de/blaues-widget" />
<link rel="alternate" hreflang="fr" href="https://yourshop.com/fr/widget-bleu" />
<link rel="alternate" hreflang="x-default" href="https://yourshop.com/en/blue-widget" />

This keeps thin or duplicate pages (filtered listings, internal search, account pages) out of Google's index while your real products stay indexable, and it tells Google which language to serve to which audience. A common mistake is adding noindex and a canonical that point in different directions on the same URL; decide per page whether you want it indexed-but-canonicalised or fully noindexed, not both at cross purposes.

The Smart SEO Revolution Suite shares the same canonical, hreflang and noindex engine, so the same per-entity rules are available there too.

Rules have a priority and shop scope. The lookup accepts the exact entity ID or entity ID 0, and exact or shop-global rules can be ordered by priority. That lets you create a broad rule for all products, then override one important product, category or CMS page without duplicating every setting.

The robots tag is built only from the directives you choose. If you tick noindex, the module adds noindex; if you tick nofollow, it adds nofollow; if neither is selected, it does not invent a robots tag just to be visible. Existing robots tags are replaced when a rule applies, so you avoid two conflicting robots meta tags in the same head.

Hreflang generation only makes sense on multilingual shops. The module checks active languages, generates alternate URLs for each active language and adds x-default for the configured default language. It also removes existing hreflang tags before inserting its own, which helps avoid duplicate alternate clusters from the theme and the module both trying to own the same signal.

Use noindex carefully with sitemaps. A noindexed URL should not be promoted as an indexable sitemap URL, and the SEO Suite's policy tables include separate index, hreflang, sitemap and schema overrides for that reason. Keep the signals aligned: indexable pages get canonical and hreflang; intentionally hidden pages get noindex and should normally stay out of the XML sitemap.

Usually it comes down to a few fixable things, and the most common is missing or empty alt text. Google leans heavily on the alt attribute and surrounding context to understand what an image shows, so images with no descriptive alt rarely surface in Image search. Walk through this list:

• Empty or generic alt text, the biggest factor; fix this first.
• robots.txt blocks the image folder, Google can't index what it can't fetch.
• Images only loaded by lazy-loading JavaScript the crawler doesn't run (less common now with native lazy loading).
• No image entries in your sitemap, so discovery is slower.
• Very small or low-quality images Google may choose not to index.

Start with the alt text. Automatic SEO Images Alt Tags generates it from your catalog data, product name, manufacturer, category, reference and more, and can fill only the empty legends or replace existing ones. Note it gives Google clean alt text to read; it does not guarantee indexing or rankings.

In the module, the default product template is {product_name} - {manufacturer}, listing pages use {product_name} - {category}, categories use {category_name}, and the default maximum length is 125 characters. You can add placeholders such as {reference}, {ean13}, {mpn} and {image_position} to make gallery images more distinct. The builder removes empty separators and cuts long text at a word boundary, so a template like {product_name} - {manufacturer} - {reference} stays readable even when one field is missing.

The module fills the image legend/alt value at presentation time for product cover images, product gallery images, listing images and supported category images. By default it fills empty values without overwriting hand-written legends; enable replacement only after checking that your manual alt text is not better. After changing templates, clear cache and inspect the rendered img alt attributes on a product and category page. This is not an image sitemap generator and it cannot force Google to index an image, but it removes one of the main catalog-side blockers.

Yes. The module records old URLs when product/category/CMS/manufacturer/supplier URLs change and serves redirects from the history table. That is exactly for protecting indexed Google URLs after slug or pattern changes. Use 301 redirects for permanent moves, keep redirect history enabled, and avoid changing URL patterns repeatedly unless you are ready to manage the redirect chain.

The history table stores the old URL, new URL, redirect type, entity type, entity ID, shop ID, active flag, hit count, last hit date, and change reason. The lifecycle handler captures old URLs before entity updates, compares them after the update, and records URL changes for products, categories, CMS pages, manufacturers, and suppliers. It also has delete and disable behavior that can redirect to a parent, homepage, 410 Gone, or nothing, depending on configuration.

At request time, the router checks overrides and history entries and returns the configured redirect URL and redirect type when an old URL is matched. For SEO migrations, keep the old history rows enabled long enough for search engines and external links to settle, prefer 301 for permanent slug changes, and test important indexed URLs with a direct HTTP request to confirm they return one clean redirect to the final destination.

PrestaShop schema, also called structured data, is a small extra layer of code that tells search engines what each piece of content on your page represents: a price, a stock state, a product, a rating, a breadcrumb trail or an FAQ entry. Search engines can use that data for eligible rich result features such as product price and stock snippets, review stars where supported, breadcrumb links, or FAQ-style presentation where the search engine still supports it.

Rich results do not push your page higher in the ranking on their own, but they can make the listing more useful and easier to trust. For a store, the schema types that usually matter are Product, Offer, AggregateRating/Review, BreadcrumbList, Organization, WebSite, CollectionPage, Article and, where appropriate, FAQPage.

Our Automatic SEO Schema Rich Snippets module attempts to add Product, Offer, rating/review, breadcrumb, Organization, WebSite, category and CMS-page markup without template editing. The same schema functionality is also part of the Smart SEO Revolution Suite if you also want sitemaps, canonicals and meta-tag automation in one place.

Important current-code caveat: the module outputs JSON-LD from hookDisplayHeader, but clean_existing_jsonld is enabled by default and the final-output cleanup preserves only JSON-LD scripts containing the <!-- mprschema --> marker. The header hook currently emits unmarked JSON-LD, so with JSON-LD cleanup active the final HTML can remove the module's own schema. Until the renderer marks its scripts or the cleanup logic is disabled/fixed, verify the final page source before treating the JSON-LD as reliably present.

On product pages, the Product schema can include the product name, URL, description, SKU, GTIN/UPC/ISBN/MPN identifiers, manufacturer/supplier/feature-based brand data, images, item condition, offer data, weight, category and review data when the shop has that data. The brand generator uses the configured catalogue source, such as manufacturer, supplier or a feature named like Brand, with a manufacturer fallback; the declared override-brand field is not used by the current generator. Offer data can include price, currency, availability, seller, shipping details and return policy. For products with combinations, the implementation can build aggregate offer data instead of pretending every variant has one identical offer.

Category pages are handled differently: they are rendered as CollectionPage data with a category name, URL, description, image, number of items and an ItemList sample of products. CMS pages are rendered as Article schema with headline, URL, description, article body, word count, dates, author, publisher, logo, language and main entity URL.

The practical merchant rule is to fill the underlying data, not just switch schema on. If a product has no identifier, weak images, no stock state, no reviews or an empty description, the schema can only describe that weak data. Structured data works best when your catalogue data is already clean, and in the current module you should also check that cleanup settings are not removing the JSON-LD you expect to publish.

Be realistic: an SEO module puts the technical signals in place, schema markup, cleaner URLs, canonical tags and internal linking, but when those changes show up in search results depends on Google, not the module. Google has to recrawl and reprocess your pages first, and that timing varies from store to store: it can be days for some pages and much longer for others, depending on how often Google revisits your store. No one can put a fixed date on it.

A few things help the early signals along: submitting a fresh XML sitemap, fixing 404s and redirecting old URLs so crawl budget lands on pages that matter. Those are exactly the levers our Smart SEO Revolution Suite handles. What no module can do is promise rankings on a fixed date. Anyone selling overnight results is misleading you. We run shops too, so we set expectations honestly: SEO is a long game, and a good module shortens the technical part of it, not Google's clock.

Run one of your product URLs through Google's Rich Results Test - it shows which structured data Google finds on the page and flags errors or warnings. You can also monitor coverage over time in Google Search Console under the Enhancements reports. After installing our Schema & Rich Snippets module, test a few product, category and CMS pages before relying on the storefront output.

In the module back office, the preview screen lets you choose a page type and generate JSON-LD before you rely on the live page. Product, Organization, WebSite, Breadcrumb, Category and CMS schema are enabled by default, while FAQ markup is off by default because FAQ content must match visible page content. Product schema uses catalog data such as manufacturer/brand, SKU-style identifiers, condition, reviews, variants and up to five images unless you change the image-limit setting.

Important current-code caveat: live storefront schema should be verified with existing JSON-LD cleanup disabled, or after the module output is marked so the cleaner preserves it. The module outputs JSON-LD scripts in displayHeader, but the cleanup step runs on the final HTML and removes application/ld+json blocks unless they contain the module marker comment. The current header output does not include that marker, so default cleanup can remove the schema the module just rendered.

That means you should validate both the preview output and the real public URL after cache, theme hooks and other SEO modules have run. If cleanup is enabled, check the actual page source to confirm the JSON-LD is still present. Warnings for optional fields do not always block eligibility, but errors in required Product fields should be fixed before expecting rich results. Even valid schema is not a guarantee that Google will show rich results; it only makes the page eligible.

Partly, and it depends on the reason Google lists next to each URL. Be honest with yourself first: no module can force Google to index a page. What we can do is fix the technical reasons Google often gives.

• Discovered/crawled, not indexed, or missing sitemap: the Advanced SEO Sitemap Builder generates a verified XML sitemap and can ping Google and Bing when it changes, so good URLs are easy to find.
• Duplicate / alternate page with canonical: handled by the canonical and noindex rules in the Smart SEO Revolution Suite, which also manages 301/302 redirects for URLs that moved.

The rest is content and server work the module can't do for you: thin or near-empty pages, pages Google judges low value, or server errors. Open the exact reason in Search Console per URL, fix that cause, then resubmit. A common mistake is keeping pages in the sitemap that you've also set to noindex, the sitemap builder skips noindexed and non-200 URLs so you don't send Google mixed signals.