Advanced SEO Sitemap Builder

An XML sitemap is for search engines — it is a structured file that lists all your pages so Google can discover and index them efficiently. An HTML sitemap is a regular page on your site for human visitors, listing links to all sections. Both are useful: the XML sitemap for indexation, the HTML sitemap for navigation and internal linking. Our Sitemap Builder generates XML sitemaps.

Many SEO improvements take effect immediately — like schema markup, canonical tags, and image alt tags. Search engines typically need 2–4 weeks to re-crawl and re-index your pages. Our customers report noticeable ranking improvements within 4–8 weeks, with traffic increases of 20–50% being common for stores that had no prior SEO optimisation.

Learn more about PrestaShop SEO fundamentals

The Sitemap Builder creates multiple sitemap files automatically: one for products, one for categories, one for CMS pages, and one for manufacturer/supplier pages. If any of these exceed 50,000 URLs or 50MB (Google's limits), the module automatically splits them into multiple files with a sitemap index file linking them all together. You do not need to manage this manually.

Partially. Common indexing issues include: missing sitemaps (our Sitemap Builder fixes this), crawl errors from broken URLs (our Friendly URL Manager helps with redirects), and duplicate content (our Canonical Manager addresses this). However, "not indexed" can also mean: thin content pages, low-quality pages Google chooses to ignore, or server errors. You need to look at the specific reason Google gives for each URL in Search Console.

Learn how sitemaps help with indexing

What Google Lighthouse Measures

Google Lighthouse is an automated auditing tool built into Chrome DevTools that evaluates web pages across four main categories: Performance, Accessibility, Best Practices, and SEO. Each category produces a score from 0 to 100, and each score is calculated from specific metrics and checks that have different weights. Understanding what these scores actually mean for a PrestaShop store, and what realistic targets look like, is essential before you spend time optimizing.

Lighthouse runs in two environments. Lab data comes from a simulated environment with controlled network throttling and CPU slowdown. Field data comes from real users through the Chrome User Experience Report (CrUX). The scores you see when running Lighthouse in Chrome DevTools are lab data. The scores Google uses for ranking purposes (Core Web Vitals) come from field data. This distinction matters because lab and field results often differ significantly, and optimizing for one does not always improve the other.

For PrestaShop stores, Lighthouse is particularly revealing because PrestaShop's default configuration and most themes are not optimized for modern performance standards. A typical unoptimized PrestaShop store scores between 15 and 40 on Performance, 60 to 80 on Accessibility, 70 to 85 on Best Practices, and 75 to 90 on SEO. These baseline scores tell you where the biggest opportunities lie.

Performance Score: The Most Complex Category

The Performance score is a weighted composite of six metrics. Each metric captures a different aspect of how fast the page loads and becomes interactive. Understanding the individual metrics is far more useful than focusing on the overall number.

Largest Contentful Paint (LCP)

LCP measures when the largest visible content element finishes rendering. On a PrestaShop product page, this is usually the main product image. On a category page, it might be the first product image or a category banner. Google considers LCP good when it is under 2.5 seconds, needs improvement between 2.5 and 4 seconds, and poor above 4 seconds.

PrestaShop-specific LCP problems include oversized product images served without proper responsive sizing, render-blocking CSS from modules that load on every page, server response times slowed by unoptimized database queries (especially on category pages with many products), and third-party module JavaScript that delays the rendering pipeline.

To improve LCP on PrestaShop, start with image optimization. Ensure product images are properly sized for each context (do not serve a 2000x2000 image when the display area is 400x400). Enable lazy loading for below-the-fold images but ensure the LCP image is NOT lazy loaded, as this delays its rendering. Implement preload hints for the LCP image using a <link rel="preload"> tag in the page header. On the server side, enable OPcache, configure MySQL query caching, and ensure your hosting has adequate resources.

Cumulative Layout Shift (CLS)

CLS measures visual stability. Every time a visible element moves position after initially rendering, it contributes to the CLS score. Google considers CLS good when it is under 0.1, needs improvement between 0.1 and 0.25, and poor above 0.25.

PrestaShop stores commonly suffer from CLS caused by images loading without defined dimensions (the browser does not know how much space to reserve, so content jumps when the image loads), web fonts loading and causing text to reflow (FOUT, Flash of Unstyled Text), dynamically injected banners or notification bars from modules, cookie consent banners that push page content down, and lazy-loaded product images in grids that shift surrounding products when they appear.

Fixing CLS in PrestaShop requires setting explicit width and height attributes on all images (or using CSS aspect-ratio), preloading critical web fonts with font-display: swap or font-display: optional, reserving space for dynamic elements like cookie banners using CSS min-height, and ensuring ad or promotional modules inject content without shifting existing elements.

First Contentful Paint (FCP)

FCP measures when the first piece of content appears on screen. This could be text, an image, an SVG, or a canvas element. For PrestaShop, FCP is heavily influenced by the time it takes the server to respond (Time to First Byte) and the amount of render-blocking resources (CSS and JavaScript) that must be downloaded before the browser can paint anything.

PrestaShop's default configuration loads a significant amount of CSS and JavaScript synchronously in the head of every page. Each installed module can add its own CSS and JavaScript files. A store with 30 modules might load 15 to 25 separate CSS files and 20 to 30 JavaScript files before any content appears. This directly increases FCP.

Total Blocking Time (TBT)

TBT measures the total time between FCP and Time to Interactive where the main thread was blocked for long enough to prevent input responsiveness. Any task longer than 50 milliseconds has its excess time counted toward TBT. For example, a 200-millisecond task contributes 150 milliseconds to TBT.

PrestaShop stores are notorious for high TBT values. Common culprits include jQuery and its plugins executing synchronously, module JavaScript that performs heavy DOM manipulation on page load, analytics and tracking code from multiple modules, product page scripts that initialize sliders, zoom functionality, and combination selectors simultaneously, and chat widgets and social media embeds.

Reducing TBT requires deferring non-critical JavaScript, breaking long tasks into smaller async chunks, removing unused module JavaScript, and loading third-party widgets after the page becomes interactive.

Speed Index

Speed Index measures how quickly the visible area of the page is populated. It captures the overall visual progression of the page load. A page where the header, navigation, and first product row appear quickly but the rest loads gradually will have a better Speed Index than a page where everything appears at once after a long delay.

For PrestaShop, Speed Index improves when you prioritize above-the-fold content rendering. This means inlining critical CSS (the CSS needed to render the visible portion of the page without scrolling), deferring below-the-fold images, and avoiding JavaScript that blocks rendering of visible content.

Interaction to Next Paint (INP)

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. It measures the responsiveness of a page throughout its entire lifecycle, not just the first interaction. Every click, tap, and key press is measured, and the worst interaction latency (approximately) becomes the INP value. Google considers INP good under 200 milliseconds.

PrestaShop stores often have poor INP on product pages where clicking a combination attribute triggers a synchronous AJAX request that blocks the UI, on category pages where faceted filter clicks cause heavy JavaScript processing, and on any page where module JavaScript monopolizes the main thread during user interaction.

Accessibility Score

The Accessibility score evaluates whether your page can be used by people with disabilities, including those using screen readers, keyboard navigation, or other assistive technologies. Lighthouse checks for specific WCAG 2.1 compliance items and assigns each a weight based on user impact.

Common PrestaShop Accessibility Failures

Missing alt text on images is the most frequent issue. PrestaShop stores with thousands of products often have products uploaded without alt text descriptions. Lighthouse flags every image without an alt attribute. The fix is to add meaningful alt text to all product images through the back office, which also benefits SEO.

Insufficient color contrast is extremely common in PrestaShop themes. The theme designer may have chosen colors that look visually appealing but do not meet the WCAG minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. Typical problems include light gray text on white backgrounds (often used for product prices, descriptions, or footer links), white text on colored buttons where the color is not dark enough, and placeholder text in search inputs.

Missing form labels affect PrestaShop's search forms, newsletter signup forms, and contact forms. Many themes use placeholder text as the only indication of what an input field is for, but placeholders are not accessible labels. Each input must have an associated <label> element.

Incorrect heading hierarchy is common when themes skip heading levels (jumping from <h1> to <h3>) or when modules inject content with heading levels that break the page's document outline.

Missing ARIA attributes on interactive elements like dropdown menus, modal dialogs, and tab interfaces mean screen readers cannot convey the purpose and state of these elements to users.

Realistic Accessibility Targets

Most PrestaShop themes with effort can reach 85 to 95. A perfect 100 is achievable but requires theme template modifications, which may be overwritten during updates. Focus on the highest-impact items first: image alt text, color contrast, form labels, and keyboard navigation for the main user flows (browse, add to cart, checkout).

Best Practices Score

The Best Practices category covers general web development quality signals: HTTPS usage, avoidance of deprecated APIs, console error absence, and security headers.

Common PrestaShop Best Practices Failures

Browser console errors are flagged by Lighthouse. PrestaShop stores frequently have JavaScript errors from module conflicts, deprecated jQuery function calls, or failed AJAX requests. Each console error reduces the Best Practices score. Check your browser console on every page type (homepage, category, product, cart, checkout) and fix or suppress the errors.

Missing security headers reduce the score. PrestaShop does not set headers like Content-Security-Policy, X-Content-Type-Options, Permissions-Policy, or Referrer-Policy by default. Adding these via your .htaccess or web server configuration improves the Best Practices score and your site's security posture.

Deprecated APIs trigger warnings when older PrestaShop themes or modules use JavaScript APIs that browsers have deprecated. Common examples include document.write(), synchronous XMLHttpRequest, and the unload event listener. These are typically found in older modules that have not been updated for modern browser standards.

Mixed content (loading HTTP resources on an HTTPS page) is flagged severely. This happens when module assets, external fonts, or tracking pixels use HTTP URLs. Ensure all resources load over HTTPS.

Images without explicit width and height (which also affects CLS under Performance) are flagged here as well. PrestaShop themes that use CSS-only sizing for images without setting HTML attributes trigger this check.

Realistic Best Practices Targets

A well-maintained PrestaShop store should target 90 to 100. Most Best Practices issues are straightforward to fix through server configuration and module cleanup.

SEO Score

The SEO audit checks for basic technical SEO requirements. This is the easiest category to score well in because the checks are straightforward and PrestaShop handles many of them by default.

What Lighthouse Checks for SEO

The audit verifies that the page has a valid <title> tag, a meta description, a valid viewport meta tag, that links have descriptive text (not just "click here"), that the page is not blocked from indexing, that images have alt attributes, that the document has a valid hreflang if it serves multiple languages, that the font size is legible on mobile, and that tap targets (buttons, links) are adequately sized and spaced.

Common PrestaShop SEO Failures

Missing or duplicate meta descriptions are common on category pages, especially auto-generated ones. PrestaShop allows you to set meta descriptions per category and per product, but many store owners leave these fields empty during bulk product imports.

Non-descriptive link text appears when themes use generic text like "Read more" or "Details" for product links without additional context. Screen readers and Lighthouse both flag these.

Small tap targets affect mobile users. PrestaShop themes with compact product grids on mobile may have links and buttons that are too close together or too small. Google recommends a minimum 48x48 CSS pixel touch target with at least 8 pixels of spacing between adjacent targets.

Blocked resources can cause Lighthouse to report that JavaScript or CSS files are inaccessible. This happens when robots.txt blocks access to asset directories. PrestaShop's default robots.txt sometimes blocks directories that contain CSS or JavaScript files needed for rendering.

Realistic SEO Targets

A PrestaShop store should target 90 to 100 on the SEO audit. Most items are simple configuration fixes. The one persistent challenge is image alt text on stores with large catalogs and historical imports that skipped alt text.

Lab Data vs. Field Data

Understanding the difference between lab and field data is critical for interpreting Lighthouse results correctly and prioritizing your optimization work.

Lab Data (Lighthouse)

When you run Lighthouse from Chrome DevTools or the command line, it creates a simulated environment. It throttles the network connection (typically to a slow 4G speed of about 1.6 Mbps with 150ms latency) and slows the CPU (typically 4x slowdown). This simulated environment produces consistent, reproducible results but does not reflect any specific real user's experience.

Lab data is useful for debugging specific issues, comparing before and after optimization changes, and identifying specific bottlenecks in the loading process. But the scores should not be taken as representing real user experience.

Field Data (CrUX)

The Chrome User Experience Report (CrUX) collects real performance data from Chrome users who have opted in to usage statistic reporting. This data is aggregated at the 75th percentile, meaning the reported value represents the experience of 75 percent of your users being at or better than that threshold.

Field data is what Google actually uses for ranking signals through Core Web Vitals. You can view your field data in Google Search Console under the Core Web Vitals report, in PageSpeed Insights (which shows both lab and field data), and through the CrUX API or BigQuery dataset.

Why Scores Differ

Lab scores are typically lower than field scores for PrestaShop stores because Lighthouse uses aggressive throttling. A store on a fast server with a CDN might score 35 in Lighthouse lab mode but have perfectly acceptable field metrics because real users on decent connections experience the store much faster than the simulated slow 4G environment. Conversely, stores with issues that only manifest under real-world conditions (JavaScript errors from specific browser versions, third-party widget slowdowns, or geographic latency to users far from the server) may have better lab scores than field scores.

Which to Prioritize

For Google ranking purposes, prioritize field data and Core Web Vitals (LCP, INP, CLS). For developer debugging and optimization work, use lab data because it is consistent and gives you detailed diagnostic information. If your field data shows passing Core Web Vitals but your lab Performance score is 40, your users are fine and Google will not penalize you. If your lab score is 90 but field data shows failing Core Web Vitals, you have a problem that lab testing is not capturing.

Realistic Score Targets for PrestaShop

Setting realistic targets prevents wasted effort chasing diminishing returns. Here are achievable targets for a typical PrestaShop 1.7 or 8.x store.

Performance: 50 to 75 (Mobile), 80 to 95 (Desktop)

Mobile Performance scores above 75 are extremely difficult for PrestaShop stores with rich product pages, multiple modules, and dynamic content. The throttled mobile simulation is harsh. A score of 50 to 65 on mobile with passing Core Web Vitals in field data is a good result. Desktop scores of 85 to 95 are achievable with standard optimizations.

Do not chase a mobile Performance score of 100. The effort required to go from 70 to 100 on mobile typically involves removing functionality that your store needs (product image zoom, dynamic cart updates, combination selectors). Instead, focus on passing Core Web Vitals thresholds in field data.

Accessibility: 85 to 95

This range is achievable with theme template fixes and content discipline. The main ongoing effort is ensuring all new products have alt text and that any new modules do not introduce accessibility regressions.

Best Practices: 90 to 100

Achievable with server configuration, console error cleanup, and keeping modules updated. This score tends to degrade over time as new modules are added, so regular monitoring helps.

SEO: 90 to 100

The easiest to achieve and maintain. Most items are one-time configuration fixes.

Actionable Improvement Checklist

This checklist prioritizes optimizations by impact, starting with the changes that produce the largest score improvements for the least effort.

High Impact, Low Effort

Enable PrestaShop's CCC (Combine, Compress, Cache) feature under Performance settings to merge and minify CSS and JavaScript files. Add width and height attributes to all images in theme templates. Set explicit dimensions on product images. Enable browser caching through proper cache headers in your server configuration. Compress text resources with Gzip or Brotli. Remove or disable modules you are not actively using. Add security headers to your server configuration.

High Impact, Medium Effort

Implement critical CSS inlining for above-the-fold content. Defer non-critical JavaScript with the defer or async attribute. Optimize and properly size product images (serve different sizes for different contexts using srcset). Preload critical resources (LCP image, primary font files). Fix all browser console errors. Add missing alt text to all product and category images.

Medium Impact, Higher Effort

Implement a CDN for static assets and images. Switch to a more performance-oriented PrestaShop theme if your current theme is fundamentally slow. Optimize server-side performance (database indexes, OPcache, Redis for caching). Implement WebP image serving with JPEG fallback. Audit and optimize third-party module JavaScript for main thread blocking.

Monitoring Over Time

A one-time Lighthouse audit is less valuable than regular monitoring. Scores change as you add products, install modules, update themes, and modify configurations. Set up automated Lighthouse testing using tools like Google PageSpeed Insights API, web.dev Measure, or self-hosted Lighthouse CI. Run tests weekly at minimum and after any significant store change.

Track both the overall scores and the individual metrics. A Performance score drop from 65 to 55 is concerning, but knowing that it was caused by a CLS regression from a newly installed banner module is actionable. Without metric-level tracking, you are guessing at causes.

Pay particular attention to Core Web Vitals in Google Search Console. Google updates this data monthly, and any regression from "Good" to "Needs Improvement" or "Poor" can affect your search rankings. Set up alerts for Core Web Vitals changes so you can respond before the impact becomes visible in traffic data.

Further reading: Page Speed and SEO: How Slow Loading Kills Your Google Rankings and Image Optimization for PrestaShop: Faster Loading Without Losing Quality.

PrestaShop Product Feeds: Google Shopping, Facebook Catalog, and More

Product feeds are the backbone of modern e-commerce advertising. They connect your PrestaShop store's catalog to advertising platforms like Google Shopping, Meta (Facebook and Instagram), Pinterest, and comparison shopping engines. A well-optimized product feed can dramatically increase your visibility, drive qualified traffic, and boost sales. This guide covers everything from setting up your first feed to advanced optimization techniques that will give your products a competitive edge.

What Is a Product Feed and Why Does It Matter

A product feed is a structured data file (typically XML, CSV, or JSON) that contains detailed information about every product in your catalog. Advertising platforms ingest this file to display your products in shopping ads, marketplace listings, and social commerce features.

The quality of your product feed directly impacts:

• Ad eligibility - Products with missing or incorrect data get disapproved and never shown to shoppers
• Ad relevance - Better product titles and descriptions mean your ads appear for more relevant searches
• Click-through rate - Accurate prices, high-quality images, and compelling descriptions drive more clicks
• Cost per acquisition - Optimized feeds lead to better quality scores, which lower your cost per click

Google Shopping Feed Setup

Prerequisites

Before creating your Google Shopping feed, you need:

1. Google Merchant Center account - Create one at merchants.google.com. Verify and claim your website URL.
2. Google Ads account - Required if you want to run Shopping campaigns (free listings do not require this).
3. Product identifiers - GTIN (EAN-13 in Europe, UPC in North America), MPN (Manufacturer Part Number), and Brand must be present for most product categories.
4. Compliant website - Your store must have clear return policies, shipping information, and contact details visible to shoppers.

Required Feed Attributes

Setting Up the Feed in PrestaShop

Option A - PrestaShop Marketing with Google (Official Module)

The official module connects directly to Google Merchant Center. Install it from the PrestaShop Addons marketplace or your back office. Configuration steps:

1. Navigate to Modules > Module Manager, search for "PrestaShop Marketing with Google"
2. Install and click Configure
3. Connect your Google account using OAuth
4. Map your product attributes to Google's required fields
5. Select which products to include (you can exclude by category, stock status, or price range)
6. Set the synchronization frequency (daily is recommended)

Option B - Third-Party Feed Modules

Third-party modules often provide more flexibility. Look for modules that support:

• Custom attribute mapping (map any PrestaShop field to any feed attribute)
• Feed filtering (exclude products by category, manufacturer, stock, price)
• Multiple feed formats (XML, CSV, TXT)
• Scheduled generation via cron
• Support for product combinations/variants

Option C - Custom XML Feed

For maximum control, you can generate a feed programmatically. Create a PHP file that queries your database and outputs Google-compliant XML:

<?php
// Example - Basic Google Shopping feed generator
require_once(dirname(__FILE__) . '/config/config.inc.php');
require_once(dirname(__FILE__) . '/init.php');

header('Content-Type: application/xml; charset=utf-8');

$id_lang = (int)Configuration::get('PS_LANG_DEFAULT');
$id_shop = (int)Context::getContext()->shop->id;
$link = new Link();

$products = Db::getInstance()->executeS('
    SELECT p.id_product, pl.name, pl.description, 
           p.reference, p.ean13, p.price, p.quantity,
           m.name as manufacturer_name,
           cl.name as category_name,
           i.id_image
    FROM ' . _DB_PREFIX_ . 'product p
    JOIN ' . _DB_PREFIX_ . 'product_lang pl 
        ON p.id_product = pl.id_product AND pl.id_lang = ' . $id_lang . '
    JOIN ' . _DB_PREFIX_ . 'product_shop ps 
        ON p.id_product = ps.id_product AND ps.id_shop = ' . $id_shop . '
    LEFT JOIN ' . _DB_PREFIX_ . 'manufacturer m 
        ON p.id_manufacturer = m.id_manufacturer
    LEFT JOIN ' . _DB_PREFIX_ . 'category_lang cl 
        ON p.id_category_default = cl.id_category AND cl.id_lang = ' . $id_lang . '
    LEFT JOIN ' . _DB_PREFIX_ . 'image i 
        ON p.id_product = i.id_product AND i.cover = 1
    WHERE ps.active = 1 AND p.quantity > 0
');

echo '<?xml version="1.0" encoding="UTF-8"?>';
echo '<rss version="2.0" xmlns:g="http://base.google.com/ns/1.0">';
echo '<channel>';
echo '<title>Your Store Name</title>';

foreach ($products as $product) {
    $productObj = new Product($product['id_product'], false, $id_lang);
    $finalPrice = $productObj->getPrice(true);
    $productUrl = $link->getProductLink($product['id_product']);
    $imageUrl = $link->getImageLink(
        $productObj->link_rewrite, 
        $product['id_image']
    );
    
    echo '<item>';
    echo '<g:id>' . $product['id_product'] . '</g:id>';
    echo '<g:title>' . htmlspecialchars($product['name']) . '</g:title>';
    echo '<g:link>' . htmlspecialchars($productUrl) . '</g:link>';
    echo '<g:price>' . number_format($finalPrice, 2) . ' EUR</g:price>';
    echo '<g:availability>in_stock</g:availability>';
    echo '<g:image_link>' . htmlspecialchars($imageUrl) . '</g:image_link>';
    echo '<g:brand>' . htmlspecialchars($product['manufacturer_name']) . '</g:brand>';
    echo '<g:gtin>' . $product['ean13'] . '</g:gtin>';
    echo '<g:condition>new</g:condition>';
    echo '</item>';
}

echo '</channel></rss>';

Set up a cron job to regenerate the feed periodically (e.g., every 6 hours).

Facebook and Instagram Catalog Feed

Setting Up a Meta Product Catalog

1. Go to Meta Commerce Manager at business.facebook.com/commerce
2. Create a new catalog and select "E-commerce" as the catalog type
3. Choose "Data feed" as the upload method
4. Set up a scheduled feed URL pointing to your PrestaShop feed

Required Attributes for Meta

Meta Pixel Integration

For Dynamic Ads to work effectively, you need the Meta Pixel installed on your PrestaShop store. The pixel tracks user behavior and matches it with your product catalog to show relevant remarketing ads. Key events to track:

• ViewContent - When a user views a product page (pass the product ID)
• AddToCart - When a user adds a product to their cart
• Purchase - When a user completes an order (pass order value and product IDs)

Feed Optimization Best Practices

Title Optimization

Product titles are the single most impactful element of your feed. Follow these guidelines:

• Include the brand name first - "Nike Air Max 90 Men's Running Shoes" performs better than "Men's Running Shoes by Nike"
• Add key attributes - Color, size, material, and model number help match search queries
• Front-load important keywords - Google truncates titles after ~70 characters in Shopping ads
• Avoid promotional text - "SALE" or "Free Shipping" in titles violates Google's policies

Image Optimization

• Use white or neutral backgrounds for Google Shopping
• Show the product clearly without watermarks, logos, or promotional overlays
• Provide at least 800x800 pixels for standard products, 1200x1200 for apparel
• Include additional images via the additional_image_link attribute (up to 10)

Price and Availability Accuracy

Google and Meta both check that the price and availability in your feed match what is shown on your product pages. Mismatches lead to disapprovals. Ensure your feed regenerates frequently enough to reflect:

• Price changes from promotions or sales
• Stock level changes (in stock vs. out of stock)
• Sale prices (use the sale_price attribute with sale_price_effective_date)

Product Category Mapping

Google uses its own product taxonomy with over 6000 categories. You need to map each of your PrestaShop categories to the most specific Google category possible. For example:

Your category: "Shoes > Running Shoes"
Google category: "Apparel & Accessories > Shoes > Athletic Shoes > Running Shoes"
Google taxonomy ID: 3603

Handling Product Variants (Combinations)

PrestaShop combinations need special handling in product feeds. Each combination should be submitted as a separate item with:

• A unique id (e.g., product_id-combination_id)
• The parent product grouped via item_group_id
• Specific attributes like color, size, material
• The correct price for that specific combination
• The image showing that specific variant (if available)

<!-- Example: same product, two color variants -->
<item>
  <g:id>SKU-001-RED</g:id>
  <g:item_group_id>SKU-001</g:item_group_id>
  <g:title>Premium Running Shoes - Red</g:title>
  <g:color>Red</g:color>
  <g:size>42</g:size>
</item>
<item>
  <g:id>SKU-001-BLUE</g:id>
  <g:item_group_id>SKU-001</g:item_group_id>
  <g:title>Premium Running Shoes - Blue</g:title>
  <g:color>Blue</g:color>
  <g:size>42</g:size>
</item>

Automating Feed Generation with Cron

Set up a cron job to regenerate your feed automatically. This ensures Google and Facebook always have up-to-date product data:

# Regenerate Google Shopping feed every 6 hours
0 */6 * * * php /var/www/html/modules/yourfeedmodule/cron.php > /dev/null 2>&1

# Or if your module provides a URL-based cron
0 */6 * * * curl -s "https://yourstore.com/modules/yourfeedmodule/cron.php?token=YOUR_TOKEN" > /dev/null 2>&1

For stores with more than 10,000 products, consider generating the feed during off-peak hours to minimize server load.

Troubleshooting Common Feed Issues

Products Disapproved for Missing Identifiers

If Google disapproves products for missing GTIN/MPN, check that:

• The EAN-13 field in PrestaShop is filled for every product
• The GTIN is valid (correct format and check digit)
• The manufacturer is set for every product
• If your products genuinely have no GTIN (custom or handmade items), set identifier_exists to false

Price Mismatch Errors

This occurs when the price in your feed does not match the price displayed on your product page. Common causes:

• Feed shows price without tax, but product page shows price with tax (or vice versa)
• Currency mismatch between feed and target country
• Cart rules or group discounts changing the displayed price
• Feed generation timing - prices changed after the last feed update

Image Rejection

Google rejects images that are too small, have watermarks, or contain promotional text. Ensure your product images meet these criteria:

• Minimum 100x100 pixels (250x250 for apparel)
• No text overlays, watermarks, or logos on the image
• Product fills at least 75% of the image area
• White or light background preferred

Measuring Feed Performance

After your feed is live, monitor these metrics in Google Merchant Center:

• Active products - How many products are approved and eligible to show
• Disapproved products - Fix these first as they represent lost opportunity
• Click-through rate - Indicates how appealing your product listings are
• Impression share - What percentage of eligible impressions your products receive

In Meta Commerce Manager, check:

• Catalog diagnostics - Shows errors, warnings, and suggestions for improvement
• Item match rate - How many pixel events match products in your catalog

For more details, read our guides: Google Merchant Center Feed Optimization: The PrestaShop Store Owner's Complete Guide and Google Merchant Center: How to Get Your Products into Google Shopping.

The Hidden Cost of Machine-Translated E-Commerce Content

Expanding a PrestaShop store into multiple languages is one of the most effective ways to grow revenue. Studies consistently show that consumers overwhelmingly prefer to shop in their native language, and a significant percentage will not purchase from a website that is only available in a foreign language. The opportunity is clear. The question is how to get there.

The temptation to use machine translation is strong. Modern AI translation tools are faster and cheaper than ever. You can translate an entire product catalog of 5,000 products into five languages in minutes rather than months. But speed and cost savings come at a price that is not immediately visible. That price shows up in your search rankings, your conversion rates, your return rates, and your brand perception. Over the following months and years, poorly translated content quietly erodes the value of your international expansion.

This article examines why machine translation alone is insufficient for e-commerce content, where it causes the most damage, and how to build a translation strategy that balances quality with budget. This is not about dismissing machine translation entirely. It is about understanding where it works, where it fails, and how to use it as one tool among several rather than the entire solution.

How Machine Translation Fails E-Commerce Content

Machine translation has made remarkable progress. For casual reading, news articles, and general communication, tools like Google Translate and DeepL produce surprisingly usable output. But e-commerce content has specific characteristics that expose the weaknesses of machine translation.

Product Names and Brand Terms

Machine translation systems do not understand that product names, brand names, and proprietary terms should not be translated. A product called "Summer Breeze Moisturizer" might be translated literally into German as "Sommer Brise Feuchtigkeitscreme," losing the brand identity entirely. Technical product names suffer even more. A "DIN rail mounting bracket" translated through a general-purpose tool may produce a technically incorrect term that confuses professionals who know exactly what they need.

In PrestaShop, product names appear in multiple critical locations: the product page title, the category listing, the cart, the order confirmation, the invoice, and the shipping label. An incorrectly translated product name cascades across every touchpoint in the customer journey.

Units and Specifications

Product specifications require precise terminology. Weight, dimensions, material compositions, voltage ratings, and compatibility information must use the correct technical terms and units for each target market. Machine translation often produces approximate terms that sound plausible but are technically wrong. A product described as being made of "stainless steel" might be translated into a term that actually means "chrome-plated steel" in the target language, which is a completely different material with different properties and price points.

Measurement units also vary by market. Some countries use metric exclusively, others use imperial, and some use a mix depending on the product category. Machine translation does not convert units or adapt to local conventions. It translates the text literally, which may produce a technically correct translation that is nonetheless confusing or unhelpful to the local buyer.

Tone and Persuasion

Product descriptions are sales copy. They are written to persuade, to create desire, and to overcome objections. This requires an understanding of cultural expectations that machine translation simply does not have. German buyers expect detailed technical specifications and precision. French buyers respond to elegance and lifestyle framing. Japanese buyers value politeness markers and group-oriented language. A product description that converts well in English may fall completely flat in another language, not because the translation is wrong word-by-word, but because the persuasive approach does not resonate with the target culture.

Machine translation preserves the source language's persuasive structure while changing the words. That is exactly backwards for effective selling. What you need is to preserve the selling intent while changing the persuasive structure to match the target culture.

Legal and Compliance Text

Terms of service, return policies, warranty information, and regulatory compliance text must be legally accurate in each market. Machine-translated legal text is not just unhelpful; it can be legally dangerous. A return policy that uses ambiguous language due to poor translation might be interpreted in favor of the customer in a dispute. A warranty disclaimer that does not use the correct legal terminology might be unenforceable. GDPR privacy notices that are incomprehensible due to poor translation may not meet the "clear and plain language" requirement of the regulation.

The SEO Impact of Poor Translations

Search engines have become sophisticated at evaluating content quality, and poorly translated content is one of the signals they use to assess quality. The impact on SEO is both direct and indirect.

Keyword Mismatch

When people search in their native language, they use specific terms and phrases that may not be the literal translation of the English search term. In German, the word "Handy" means "mobile phone," but no English speaker would guess that. In Dutch, "actueel" means "current" or "up-to-date," not "actual." Machine translation cannot perform keyword research. It translates the words you give it, not the words your target audience is actually searching for.

Effective multilingual SEO requires keyword research in each target language. You need to know which terms have search volume, which terms have commercial intent, and which terms match your products. This is a fundamentally different task from translation, and machine translation does not even attempt it.

In PrestaShop, the ps_product_lang table stores the meta_title, meta_description, and link_rewrite fields for each language. These fields directly control how your products appear in search results. Machine-translated meta titles and descriptions perform poorly because they use translated phrases rather than searched phrases.

Thin Content and Quality Signals

Google's algorithms evaluate content quality using numerous signals, including readability, topical relevance, and user engagement metrics. Machine-translated content often reads awkwardly, with unnatural sentence structures, incorrect collocations (word combinations that sound wrong to native speakers), and inconsistent terminology. Users who land on such pages tend to bounce quickly, spend less time on the page, and are less likely to engage with internal links.

These behavioral signals tell search engines that the content does not satisfy user intent, leading to lower rankings. Over time, a pattern of poor-quality translated content can affect the domain's overall authority in the target language market.

Hreflang and Duplicate Content

PrestaShop supports multilingual content through its built-in language system, and properly configured stores use hreflang tags to tell search engines which language version of a page to show to which users. The hreflang setup itself is technical but straightforward. The problem arises when the content behind the hreflang tags is low quality.

If your French and Spanish versions are machine-translated and provide a poor user experience, search engines may choose to show the English version to French and Spanish users anyway, or they may not rank any version well. Hreflang tags are a suggestion to search engines, not a command. If the localized content is poor, search engines will make their own judgment about which version to serve.

Properly setting up hreflang tags in PrestaShop requires ensuring each language has its own URL structure (either subdirectories like /fr/ and /es/ or separate domains) and that the hreflang tags on each page reference all other language versions. PrestaShop handles this automatically through its language configuration, but the technical setup only works if the content behind it is worth indexing.

How Poor Translations Hurt Conversion Rates

Beyond SEO, poor translations directly reduce conversion rates. The checkout flow is where the damage is most severe.

Checkout Abandonment

The checkout process involves trust-sensitive interactions: entering personal information, providing payment details, and agreeing to terms. If the language on the checkout page feels unnatural, confusing, or unprofessional, customers hesitate. They question whether the store is legitimate, whether their payment information is safe, and whether they will receive the product they expect.

Machine translation frequently produces awkward phrasing in form labels, button text, error messages, and instructional text. A button that says "Proceed to Payment" might be translated into a phrase that feels stilted or ambiguous in the target language. An error message like "Please enter a valid phone number" might be translated into something that sounds accusatory or confusing. These small friction points accumulate throughout the checkout process, and each one gives the customer a reason to abandon the purchase.

Product Page Confidence

Product descriptions build confidence. They answer questions, address concerns, and help customers visualize owning the product. A machine-translated description that reads awkwardly undermines this confidence-building process. Customers who are uncertain about what they are buying do not buy. They leave to find a competitor whose product descriptions they can understand clearly.

This effect is particularly strong for high-consideration purchases. A customer buying a 10-euro phone case might tolerate awkward product descriptions. A customer buying a 500-euro piece of professional equipment will not. The higher the price and the more complex the product, the more important translation quality becomes.

Return Rate Impact

Poor translations do not just prevent sales. They cause wrong sales. When a product description is unclear or misleading due to translation errors, customers may order a product that does not match their expectations. The result is returns, refund processing costs, shipping costs, and negative reviews. A customer who receives the wrong product because the description was poorly translated is unlikely to return and very likely to leave a negative review, which compounds the damage.

The Checkout Flow: Where Every Word Matters

PrestaShop's checkout flow contains dozens of translatable strings. These include form labels (First Name, Last Name, Address, City, Postal Code, Phone), button text (Continue, Place Order, Add to Cart), status messages (Your order has been placed, Payment accepted, Shipping in progress), error messages (This field is required, Invalid email address, Card declined), and legal checkboxes (I agree to the terms and conditions, I have read the privacy policy).

Each of these strings exists in PrestaShop's translation files. PrestaShop 1.7 and 8.x use a combination of Symfony translation catalogs and legacy translation arrays. The back office provides a translation interface at International > Translations where you can edit every translatable string in the system.

For the checkout flow specifically, every string should be reviewed by a native speaker. Even if the rest of your catalog uses machine translation as a starting point, the checkout flow must be professionally translated. The ROI is direct and measurable: better checkout translations mean fewer abandoned carts.

Professional Translation vs Machine Translation: A Cost Analysis

Professional human translation typically costs between 0.08 and 0.25 euros per word, depending on the language pair, the subject matter, and the turnaround time. Technical content and marketing copy command higher rates. A typical product description of 200 words costs between 16 and 50 euros to translate professionally into one language.

For a catalog of 1,000 products with 200-word descriptions, the cost of professional translation into one language ranges from 16,000 to 50,000 euros. Into five languages, the cost ranges from 80,000 to 250,000 euros. These numbers give store owners pause, and reasonably so.

Machine translation costs a fraction of this. Even paid API access to advanced machine translation services costs pennies per thousand characters. Translating the same 1,000-product catalog might cost under 100 euros in API fees.

But comparing these numbers in isolation is misleading. The true cost comparison must include the revenue impact. If machine translation reduces your conversion rate in the target market by even 1-2 percentage points, the lost revenue quickly exceeds the savings on translation costs. For a store doing 50,000 euros per month in a market, a 2% conversion rate drop means 1,000 euros per month in lost revenue, which means the professional translation pays for itself within a few months to a year.

The Hybrid Approach: Best of Both Worlds

The most cost-effective approach for most PrestaShop stores is a hybrid strategy that uses machine translation as a starting point and human review for refinement. Here is how to implement it.

Tier 1: Professional Translation

Invest in full professional translation for your highest-impact content. This includes the checkout flow and all transactional emails, your top 50-100 products by revenue, your homepage and main landing pages, your terms of service and legal pages, your meta titles and meta descriptions for SEO-critical pages, and your main category descriptions.

Tier 2: Machine Translation Plus Human Review

For the bulk of your product catalog, use machine translation as a first pass, then have a native speaker review and correct the output. This is called post-editing, and it is significantly faster and cheaper than translating from scratch. A professional translator can review and correct machine-translated text three to five times faster than translating from zero, which reduces costs proportionally.

In this tier, the human reviewer corrects factual errors, adjusts tone and style, ensures technical terms are correct, and optimizes for target-market search terms. The machine translation provides the structural framework; the human provides the quality and cultural adaptation.

Tier 3: Machine Translation Only

For low-priority content that has minimal impact on SEO and conversion, machine translation alone may be acceptable. This includes internal back office content that only your staff sees, old blog posts with low traffic, and product features that are purely factual and numerical (dimensions, weight, etc.).

Implementation in PrestaShop

PrestaShop's translation system supports this tiered approach well. You can export all translatable strings, run them through a machine translation API, import the results, and then selectively review and improve the high-priority strings through the back office translation interface.

Several PrestaShop modules facilitate this workflow. Translation modules can connect to machine translation APIs and auto-fill empty translations. Some modules support translation memory, which stores previously approved translations and applies them consistently across your catalog. Others integrate with professional translation services, allowing you to send content for human translation directly from your back office.

For product content specifically, the ps_product_lang table can be exported, processed through machine translation, reviewed by a human translator, and re-imported. CSV and XML import tools in PrestaShop support updating existing products with new language data without affecting other product attributes.

Cultural Nuances That Machine Translation Misses

Beyond words and grammar, effective translation requires cultural adaptation. Here are areas where machine translation consistently fails.

Color and Size Naming

Colors have different cultural associations and naming conventions. What English speakers call "burgundy" might need a different name in markets where that color term is less common. Size naming conventions vary dramatically: S/M/L vs 36/38/40 vs I/II/III. Machine translation translates the word but does not adapt the convention.

Date and Number Formats

Date formats vary by country (MM/DD/YYYY vs DD/MM/YYYY vs YYYY-MM-DD). Number formats vary too: the decimal separator is a period in English-speaking countries and a comma in most of continental Europe. PrestaShop handles these through its localization packs, but custom text that includes dates or numbers needs manual attention.

Payment Method Names

Payment methods have local names and local preferences. Mentioning "Klarna" prominently in a Swedish store builds trust because it is a well-known local brand. Mentioning it in a store targeting Japan has no effect. Machine translation translates the surrounding text but cannot make these strategic content decisions.

Seasonal and Cultural References

Marketing copy often references seasons, holidays, and cultural events. A "Christmas sale" needs to become a different promotion entirely for markets that do not celebrate Christmas. A "back to school" promotion needs different timing in different hemispheres. Machine translation translates the words but does not adapt the cultural reference.

Setting Up Hreflang Tags in PrestaShop

Regardless of your translation approach, correct hreflang implementation is essential for multilingual SEO. PrestaShop supports multiple approaches to multilingual URL structure.

The most common setup uses language subdirectories: example.com/en/, example.com/fr/, example.com/de/. PrestaShop generates these automatically based on your configured languages. Each language has an ISO code and a URL prefix configured in the back office under International > Localization > Languages.

PrestaShop automatically generates hreflang tags in the page head for each language version of a page. These tags tell Google which language and regional variant of a page to serve to users searching in different languages. A properly configured PrestaShop store will include tags like:

<link rel="alternate" hreflang="en" href="https://example.com/en/product-name.html" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/nom-du-produit.html" />
<link rel="alternate" hreflang="de" href="https://example.com/de/produktname.html" />

Note that the link_rewrite field in ps_product_lang should be translated for each language. A French product URL should contain French words, not English words. This is both an SEO best practice and a usability improvement for visitors who see the URL in their browser's address bar or in search results.

Common hreflang mistakes to avoid: pointing hreflang tags to pages that return 404 errors (because the translation does not exist), using incorrect language codes, having asymmetric hreflang references (page A points to page B but page B does not point back to page A), and using the same content for multiple language versions (which search engines treat as duplicate content).

Translation Quality Checklist for PrestaShop Stores

Before launching a new language version, run through this checklist to ensure translation quality meets minimum standards.

Verify all checkout flow strings are correctly translated and read naturally. Test the complete purchase flow in each language, from adding a product to the cart through to the order confirmation page.

Check that product names are not incorrectly translated. Brand names, model numbers, and proprietary terms should remain in their original form unless there is a local equivalent that customers actually use.

Verify that meta titles and descriptions contain keywords that have actual search volume in the target language. Use keyword research tools that support the target language to validate your translated meta content.

Test all email templates in each language. Order confirmations, shipping notifications, and password reset emails should all be correctly translated and properly formatted.

Check that error messages are clear and helpful in each language. Test form validation by intentionally submitting incorrect data and verifying that the error messages guide the user to correct their input.

Verify that currency, date, and number formats match the conventions of the target market. PrestaShop's localization packs handle most of this, but custom content may need manual adjustment.

Have a native speaker review your return policy, terms of service, and privacy policy in each language. These pages have legal implications and must be accurate.

Summary

Machine translation is a useful tool, but it is not a translation strategy. Using it as your sole approach to multilingual e-commerce content leads to lower search rankings, reduced conversion rates, higher return rates, and brand perception damage. The most effective approach is a hybrid strategy: professional translation for high-impact content, machine translation with human post-editing for the bulk of your catalog, and machine translation alone only for low-priority internal content. PrestaShop's built-in multilingual support, combined with proper hreflang implementation and a tiered translation approach, lets you expand into new markets effectively without sacrificing the quality that converts visitors into customers. The investment in quality translation pays for itself through better SEO performance, higher conversion rates, and fewer returns. In international e-commerce, the quality of your language is the quality of your brand.

What Is Robots.txt and Why It Matters for PrestaShop

The robots.txt file sits at the root of your PrestaShop installation and acts as the first point of communication between your store and search engine crawlers. It tells bots like Googlebot, Bingbot, and others which parts of your site they may crawl and which they should skip. While it is not a security mechanism (it does not prevent access, only advises crawlers), it is one of the most important tools for managing your crawl budget — the number of pages a search engine will crawl on your site within a given timeframe.

For PrestaShop stores, this matters enormously. A typical PrestaShop installation can generate thousands of URL variations through filters, sorting options, pagination, currency switching, and search queries. If left unchecked, search engine bots will waste their crawl budget on these low-value pages instead of discovering and indexing your actual product and category pages.

How PrestaShop Generates Its Robots.txt

PrestaShop includes a built-in robots.txt generator accessible from the Back Office. Navigate to Shop Parameters > Traffic & SEO and scroll to the bottom where you will find the "Robots file generation" section. Clicking the generate button creates a robots.txt file at your store's root directory.

The default generated file typically includes rules like these -

User-agent: *
Disallow: /classes/
Disallow: /config/
Disallow: /download/
Disallow: /mails/
Disallow: /modules/
Disallow: /translations/
Disallow: /tools/
Disallow: /*?orderby=
Disallow: /*?orderway=
Disallow: /*?tag=
Disallow: /*?id_currency=
Disallow: /*?search_query=
Disallow: /*?back=
Disallow: /*?n=
Disallow: /*&orderby=
Disallow: /*&orderway=
Disallow: /*&tag=
Disallow: /*&id_currency=
Disallow: /*&search_query=
Disallow: /*&back=
Disallow: /*&n=
Sitemap: https://yourstore.com/sitemap.xml

While this is a reasonable starting point, it is far from complete. Many critical URL patterns that waste crawl budget are not included.

What You Must Block in PrestaShop

1. Cart, Checkout, and Account Pages

These pages are user-specific and provide zero SEO value. They should always be blocked -

Disallow: /*?controller=cart
Disallow: /*?controller=order
Disallow: /*?controller=authentication
Disallow: /*?controller=my-account
Disallow: /*?controller=identity
Disallow: /*?controller=addresses
Disallow: /*?controller=address
Disallow: /*?controller=history
Disallow: /*?controller=order-detail
Disallow: /*?controller=password
Disallow: /*?controller=discount
Disallow: /*?controller=order-return
Disallow: /*?controller=order-follow
Disallow: /*?controller=guest-tracking
Disallow: /cart
Disallow: /order
Disallow: /login
Disallow: /my-account
Disallow: /password-recovery

2. Faceted Navigation and Layered Filters

Faceted navigation is the single biggest crawl budget killer for e-commerce stores. When a customer uses filters like color, size, or price range, PrestaShop generates unique URLs for every combination. A category with 5 colors, 4 sizes, and 3 price ranges can produce hundreds of URL combinations — none of which should be in Google's index.

# Block layered navigation filter parameters
Disallow: /*?q=
Disallow: /*&q=
Disallow: /*?selected_filters=
Disallow: /*&selected_filters=
Disallow: /module/ambjolisearch/jolisearch

# Block price filter combinations
Disallow: /*?price=
Disallow: /*&price=

# Block attribute and feature filters
Disallow: /*?id_attribute_group=
Disallow: /*&id_attribute_group=
Disallow: /*?id_feature=
Disallow: /*&id_feature=

3. Internal Search Results

Internal search result pages are thin content and should never be indexed. They frequently create near-duplicate pages and are a known source of quality issues -

Disallow: /*?controller=search
Disallow: /*?s=
Disallow: /*&s=
Disallow: /search
Disallow: /*?search_query=
Disallow: /*&search_query=

4. Pagination Parameters

While category pages themselves should be crawlable, the pagination parameters that generate sort/page variants should be controlled -

Disallow: /*?page=
Disallow: /*&page=
Disallow: /*?p=
Disallow: /*&p=

Important note - Be careful with pagination. If you block /*?page= entirely, you may prevent crawlers from reaching products that only appear on deeper pages. A better approach is to implement rel="canonical" tags pointing paginated pages to the first page, or to use rel="next" and rel="prev" pagination signals.

5. Comparison Pages and Wishlists

Disallow: /*?controller=comparison
Disallow: /comparison
Disallow: /*?controller=wishlist
Disallow: /module/blockwishlist/

6. Admin and System Directories

Disallow: /admin*/
Disallow: /app/
Disallow: /bin/
Disallow: /cache/
Disallow: /classes/
Disallow: /config/
Disallow: /controllers/
Disallow: /docs/
Disallow: /download/
Disallow: /img/tmp/
Disallow: /localization/
Disallow: /mails/
Disallow: /override/
Disallow: /pdf/
Disallow: /src/
Disallow: /tools/
Disallow: /translations/
Disallow: /upload/
Disallow: /var/
Disallow: /vendor/
Disallow: /webservice/

7. URL Tracking Parameters

Marketing campaign parameters create duplicate content when bots crawl tagged URLs -

Disallow: /*?utm_source=
Disallow: /*?utm_medium=
Disallow: /*?utm_campaign=
Disallow: /*&utm_source=
Disallow: /*&utm_medium=
Disallow: /*&utm_campaign=
Disallow: /*?fbclid=
Disallow: /*?gclid=
Disallow: /*?ref=

What You Must Allow in PrestaShop

1. Product and Category Pages

These are the core of your store and must always remain crawlable. Do not block your main content directories.

2. CSS, JavaScript, and Image Files

Google needs to render your pages to evaluate content quality. Blocking CSS or JS files prevents rendering and can hurt rankings -

Allow: /themes/*/assets/
Allow: /themes/*/css/
Allow: /themes/*/js/
Allow: /js/
Allow: /img/
Allow: /modules/*/views/css/
Allow: /modules/*/views/js/

3. CMS Pages

Your legal pages, about pages, and content marketing pages should be fully crawlable. Ensure they are not accidentally caught by broad Disallow rules.

4. Manufacturer and Supplier Pages (If Used)

If you maintain rich manufacturer or supplier pages with unique content, keep them crawlable. If they are thin auto-generated pages, consider blocking them.

Handling AI Crawlers

The rise of AI services has introduced a new category of crawlers that scrape content for training purposes. If you want to prevent your product descriptions, images, and other content from being used by AI models, you can add specific rules -

# Block AI training crawlers
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: FacebookBot
Disallow: /

User-agent: Bytespider
Disallow: /

Note that blocking Google-Extended prevents Google from using your content for AI training (Gemini) while still allowing regular Googlebot to crawl and index your pages normally.

Complete Recommended Robots.txt for PrestaShop

Here is a comprehensive robots.txt file that you can adapt for your PrestaShop store -

# Main search engine crawlers
User-agent: *

# Allow static assets
Allow: /themes/*/assets/
Allow: /themes/*/css/
Allow: /themes/*/js/
Allow: /js/
Allow: /img/
Allow: /modules/*/views/css/
Allow: /modules/*/views/js/

# Block system directories
Disallow: /app/
Disallow: /bin/
Disallow: /cache/
Disallow: /classes/
Disallow: /config/
Disallow: /controllers/
Disallow: /docs/
Disallow: /download/
Disallow: /img/tmp/
Disallow: /localization/
Disallow: /mails/
Disallow: /override/
Disallow: /pdf/
Disallow: /src/
Disallow: /tools/
Disallow: /translations/
Disallow: /upload/
Disallow: /var/
Disallow: /vendor/
Disallow: /webservice/

# Block cart, checkout, account
Disallow: /cart
Disallow: /order
Disallow: /login
Disallow: /my-account
Disallow: /password-recovery
Disallow: /guest-tracking
Disallow: /*?controller=cart
Disallow: /*?controller=order
Disallow: /*?controller=authentication
Disallow: /*?controller=my-account
Disallow: /*?controller=identity
Disallow: /*?controller=history
Disallow: /*?controller=password

# Block filters and sorting
Disallow: /*?orderby=
Disallow: /*?orderway=
Disallow: /*?n=
Disallow: /*?q=
Disallow: /*?selected_filters=
Disallow: /*?id_currency=
Disallow: /*?tag=
Disallow: /*?back=
Disallow: /*&orderby=
Disallow: /*&orderway=
Disallow: /*&n=
Disallow: /*&q=
Disallow: /*&selected_filters=
Disallow: /*&id_currency=
Disallow: /*&tag=
Disallow: /*&back=

# Block search
Disallow: /*?controller=search
Disallow: /*?search_query=
Disallow: /*&search_query=
Disallow: /*?s=
Disallow: /*&s=
Disallow: /search

# Block tracking parameters
Disallow: /*?utm_source=
Disallow: /*?utm_medium=
Disallow: /*?utm_campaign=
Disallow: /*&utm_source=
Disallow: /*?fbclid=
Disallow: /*?gclid=

# Block comparison and wishlist
Disallow: /*?controller=comparison
Disallow: /comparison

# Sitemap
Sitemap: https://yourstore.com/1_index_sitemap.xml

# Block AI training crawlers
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

Common Mistakes to Avoid

Blocking the Modules Directory Entirely

The default PrestaShop robots.txt blocks /modules/. While you do not want module PHP files crawled, many modules serve critical CSS and JavaScript from this directory. The blanket block can prevent Google from rendering your pages correctly. Instead, block /modules/ but explicitly allow CSS and JS subdirectories as shown above.

Using Robots.txt Instead of Noindex

A critical misunderstanding - robots.txt tells bots not to crawl a URL, but it does not prevent indexing. If another site links to a page you have blocked in robots.txt, Google may still index it (showing "A description for this result is not available due to this site's robots.txt"). For pages you want completely removed from search results, use the noindex meta tag or the X-Robots-Tag HTTP header instead.

Forgetting the Sitemap Reference

Always include your sitemap URL at the bottom of robots.txt. This helps crawlers find your sitemap immediately. If you use a module that generates multiple sitemaps, reference the sitemap index file.

Using Overly Broad Rules

A rule like Disallow: /*? would block every URL with any query parameter, which would be catastrophic. Be specific with your rules and test them using Google Search Console's robots.txt tester before deploying.

Testing Your Robots.txt Configuration

1. Google Search Console - Use the Robots.txt Tester tool (found under the legacy tools) to check specific URLs against your rules
2. Manual testing - Visit yourstore.com/robots.txt directly in your browser to verify the file is accessible and correctly formatted
3. Coverage report - After deploying changes, monitor the Coverage report in Google Search Console for any unexpected increases in "Excluded" pages
4. Log file analysis - Check your server logs to verify that bots are actually respecting your rules and not wasting crawl budget on blocked URLs

Multistore Considerations

If you run a PrestaShop multistore setup, each store (domain) needs its own robots.txt file at its root. The PrestaShop generator creates rules for all shops in a single file, but if your stores are on different domains, you need to split them accordingly. Each store's robots.txt should reference its own sitemap and have rules appropriate to its URL structure.

When to Regenerate Your Robots.txt

You should regenerate or update your robots.txt whenever you -

• Add new modules that create public-facing URLs (search modules, filter modules)
• Change your URL structure or enable/disable friendly URLs
• Switch themes (different themes may serve assets from different paths)
• Add or remove languages (which changes URL prefixes)
• Enable or disable the multistore feature
• Notice unusual crawl patterns in your server logs or Google Search Console

Remember - always keep a backup of your working robots.txt before regenerating. The PrestaShop generator overwrites the file completely, and any custom rules you have added manually will be lost unless you re-add them after generation.

For more details, read our guides: PrestaShop SEO: The Complete Guide to Ranking Higher and The Complete Guide to XML Sitemaps for PrestaShop SEO.

Understanding the 'Crawled — Currently Not Indexed' Status

When you open Google Search Console and see pages marked as "Crawled — currently not indexed", it means Google's crawler (Googlebot) visited those pages, downloaded their content, evaluated them — and then decided not to add them to the search index. This is not a technical error. It is a quality or relevance judgment by Google's algorithms.

This status is different from "Discovered — currently not indexed" (where Google knows the URL exists but has not even crawled it yet) and from "Excluded by noindex tag" (where you explicitly told Google not to index it). With "Crawled — currently not indexed," Google actively looked at your page and made a conscious decision to skip it.

For PrestaShop store owners, this is particularly concerning because affected pages may include product pages, category pages, or CMS content pages that you specifically want ranking in search results. Let us walk through a systematic approach to diagnosing and fixing this issue.

Why Google Chooses Not to Index Pages

Google has limited index capacity and prioritizes pages it considers most valuable to searchers. Several factors can trigger this status on PrestaShop stores -

Thin or Duplicate Content

This is the number one cause for PrestaShop stores. Product pages with only a manufacturer's description (copied from the supplier or used on dozens of other stores), short two-sentence descriptions, or pages with mostly technical specifications and no narrative content are prime candidates for being crawled but not indexed. Google sees the same content on multiple sites and chooses the most authoritative version to index.

Poor Internal Linking

Pages that are buried deep in your site structure and receive few or no internal links send a signal to Google that they are not important. If a product page is only reachable through four clicks from the homepage, or only appears in search results or filtered navigation, Google may treat it as low-priority.

Crawl Budget Waste on Low-Value URLs

If Google is spending most of its crawl budget on filter combinations, search result pages, and session-parameter URLs, it may not have enough "crawl attention" left for your important content. When it does finally crawl those important pages, the overall site quality signal may be diluted.

Out-of-Stock Products

Google specifically deprioritizes product pages where the product is unavailable for extended periods. If your PrestaShop store has many out-of-stock items with no indication of when they will return, Google may crawl them but decide not to waste index space on unavailable products.

Slow Page Load Times

Pages that are slow to render or require excessive resources can be deprioritized. If Googlebot times out or experiences delays when fetching your pages, it may choose not to index them even after a successful crawl.

Missing or Broken Structured Data

While structured data is not a ranking factor by itself, errors in your Product schema, BreadcrumbList schema, or other structured data can create ambiguity about what the page is about, which may contribute to non-indexation.

Step 1 - Audit Which Pages Are Affected

Before fixing anything, you need to understand the scope and pattern of the problem.

1. Open Google Search Console and go to Pages (formerly Index Coverage)
2. Click on "Not indexed" tab and find "Crawled — currently not indexed"
3. Export the full list of affected URLs
4. Categorize them - are they product pages, category pages, CMS pages, or something else?

Look for patterns. If all affected pages are products in a specific category, the problem may be category-specific. If they are all older products, it may be a freshness issue. If they share characteristics like short descriptions, that points to thin content.

Step 2 - Fix Content Quality Issues

This is the most impactful fix and should be your primary focus.

Enhance Product Descriptions

Every product page that you want indexed needs unique, substantial content. Here is what "substantial" means in practice -

• Minimum 300 words of unique descriptive text (not copied from manufacturer)
• Address user intent - what problem does this product solve? Who is it for?
• Include usage information - installation instructions, care tips, compatibility notes
• Add original media - unique product photos, size comparison images, video demonstrations

In PrestaShop, edit your products through Catalog > Products and focus on the Description tab. The short description appears in category listings while the long description appears on the product page itself. Both matter for indexation.

Improve Category Page Content

Many PrestaShop stores have category pages with nothing but a product grid. Add substantial category descriptions that help users understand the product range -

<!-- Example category description structure -->
<div class="category-description">
  <h2>Walk-In Shower Drains for Modern Bathrooms</h2>
  <p>Our collection of linear shower drains combines 
  modern design with superior drainage performance...</p>
  
  <h3>Choosing the Right Drain Length</h3>
  <p>The drain length should match your shower width...
  Available in 600mm, 800mm, 1000mm, and 1200mm sizes.</p>
  
  <h3>Material and Finish Options</h3>
  <p>All drains are manufactured from grade 304 
  stainless steel for corrosion resistance...</p>
</div>

Handle Duplicate Content Across Products

If you sell multiple variants of similar products (same product in different sizes, colors, or configurations), each page needs differentiating content. Do not simply copy the same description and change the size number. Add variant-specific details -

• Specific use cases for each variant
• Installation differences between variants
• Customer reviews specific to that variant
• Unique images showing the variant in context

Step 3 - Strengthen Internal Linking

Internal links are one of the strongest signals you can send to Google about which pages matter.

Cross-Link Related Products

In PrestaShop, go to each product and add related products through the Catalog > Products > [Product] > Options section. Related products create valuable internal links between product pages.

Add Contextual Links in CMS Content

If you have a blog or CMS pages, link to specific products and categories from within the content. This is far more valuable than sidebar or footer links -

<!-- In a CMS page about bathroom design -->
<p>For walk-in showers, a 
<a href="/linear-drain-category">linear shower drain</a> 
provides better water flow than traditional point drains. 
Our most popular option, the 
<a href="/product-page">800mm stainless steel linear drain</a>, 
fits most standard shower configurations.</p>

Improve Breadcrumb Navigation

Ensure your PrestaShop theme generates proper breadcrumb markup. Breadcrumbs create a clear linking hierarchy that helps Google understand your site structure. Check that breadcrumbs include schema.org BreadcrumbList markup.

Create a Custom HTML Sitemap Page

In addition to your XML sitemap, create a CMS page that acts as an HTML sitemap. Link to all your important categories and top products. This gives both users and crawlers a roadmap of your site. Link to this page from your footer.

Step 4 - Technical Fixes Specific to PrestaShop

Check Canonical Tags

Incorrect canonical tags are a common issue in PrestaShop. If a product page has a canonical tag pointing to a different URL, Google will treat the page as a duplicate and may not index it. Check your page source -

<!-- Look for this in the <head> section -->
<link rel="canonical" href="https://yourstore.com/product-name.html" />

The canonical URL should match the actual page URL. Common PrestaShop issues include -

• HTTP vs HTTPS mismatches in canonical tags
• Canonical tags including query parameters
• Multiple canonical tags on the same page (caused by modules)
• Canonical tags pointing to non-existent pages

Check this in your theme's head.tpl file or through the URL Inspection tool in Search Console.

Verify Server Response Codes

Use the URL Inspection tool in Search Console to check what Googlebot actually sees when it visits your page. Look for -

• Redirect chains (multiple redirects before reaching the final page)
• Soft 404s (pages that return a 200 status but display "no products found" content)
• Mixed content warnings (HTTP resources on HTTPS pages)

Improve Page Speed

Check your Core Web Vitals in Search Console. For PrestaShop, common speed issues include -

• Unoptimized images - Enable WebP conversion and lazy loading
• Too many modules - Each module adds CSS and JS files; disable unused ones
• No caching - Enable Smarty cache and consider a caching module or CDN
• Database queries - Monitor slow queries that increase server response time

Fix Structured Data Errors

Use Google's Rich Results Test tool to check your product pages. PrestaShop should output Product schema with at minimum -

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Product Name",
  "description": "Product description",
  "image": "https://yourstore.com/img/product.jpg",
  "sku": "PROD-001",
  "offers": {
    "@type": "Offer",
    "price": "49.99",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}

Step 5 - Handle Out-of-Stock Products Properly

PrestaShop stores often have products that go in and out of stock. Here is how to handle them to avoid indexation issues -

• Temporarily out of stock - Keep the page active, show "out of stock" status, and update structured data to https://schema.org/OutOfStock. Add an "email when available" feature.
• Permanently discontinued - Set up a 301 redirect to the closest alternative product or the parent category. In PrestaShop, you can create redirects through the product settings or using an .htaccess rule.
• Seasonal products - Keep the page active year-round with updated content indicating when the product will return.

Never simply disable a product without handling its URL. A product that returns a 404 after being in the index will lose all accumulated SEO value.

Step 6 - Optimize Your XML Sitemap

Your XML sitemap signals to Google which pages you consider important. Optimize it by -

• Include only indexable pages - Remove any pages that have noindex tags or that you do not want indexed
• Set priority and frequency correctly - Product pages and categories should have higher priority than generic CMS pages
• Remove stale URLs - If products are discontinued and redirected, remove them from the sitemap
• Keep it under 50,000 URLs - Use a sitemap index file for larger stores

In PrestaShop, you can manage your sitemap through a dedicated module or by regenerating it from the SEO settings.

Step 7 - Request Re-Indexation

After making all your improvements, request re-indexation for the most important affected pages -

1. Go to Google Search Console > URL Inspection
2. Enter the URL of an affected page
3. Click "Request Indexing"

Note that Google limits the number of re-indexation requests you can submit per day. Focus on your highest-priority pages first. For bulk changes, updating your sitemap and waiting for Google to re-crawl is more effective.

Preventive Measures for PrestaShop Stores

Content Quality Checklist for New Products

Before publishing a new product, ensure it meets these minimum requirements -

• Unique product name (not just the manufacturer's SKU or generic name)
• At least 300 words of unique description
• 3 or more unique product images
• Complete product attributes (dimensions, weight, materials)
• Proper category assignment
• Completed meta title and meta description

Regular Content Audits

Schedule monthly checks of your Search Console coverage report. Track the number of pages in each status category and investigate any sudden increases in "Crawled — currently not indexed" pages. Investigate within the first week, as delays make it harder to correlate changes with indexation drops.

Monitor Crawl Stats

In Search Console, check Settings > Crawl stats to see how Google is crawling your site. Look for -

• Crawl rate - is it stable, increasing, or decreasing?
• Response time - are your pages loading quickly enough for Googlebot?
• Status codes - are there unexpected 404s, 301s, or 500s?

When Not to Worry

Not every page needs to be indexed. If the affected pages are -

• Legal pages (terms of service, privacy policy) — these are often low-priority for Google
• Pages with very similar content to other pages on your site
• Recently published pages (give them 2-4 weeks before investigating)
• Pages created for internal purposes rather than search traffic

Focus your efforts on pages that drive or should drive organic traffic. If a page is genuinely valuable to searchers and still not indexed after implementing the fixes above, consider consolidating thin pages into more comprehensive resources or creating fresh content that better addresses the search intent.

SEO audit tools flag everything — including optional markup. Not every page needs every type of schema. Product pages should have Product schema, your homepage can have Organization schema, and FAQ pages benefit from FAQPage schema. If a tool says "breadcrumb schema is missing" but your breadcrumbs work fine visually, the impact is minimal. Focus on Product and Review schema first — these have the biggest impact on how your pages appear in search results.

Read our guide on schema markup best practices