PrestaShop SEO: URLs, indexing, content and technical checks

What we would do

We would start with the selling pages you need customers to find, and establish whether the problem is discovery, indexing, search presentation or the purchase journey. The right route depends on your existing PrestaShop release, theme, modules, integrations, catalogue data, languages and markets, and on who in your team can maintain the result. Record the exact PrestaShop, theme and module versions alongside the shop's rendered output before changing settings or buying another SEO tool, and check version-specific routes, template paths and generated rules against that installed release.

Keep working URLs and useful indexed pages stable. If a fault affects a shared template or routing rule, reproduce it on a protected staging copy with the same relevant configuration and data. Rehearse the correction, customer journeys and crawler checks, record how to reverse it and agree a planned live switch with a named owner. Isolate that copy from live email, payments and fulfilment integrations; a public staging shop can itself create duplicate pages and expose customer information.

Choose a starting point

Choose an affected page and a comparable unaffected page before opening the detailed sections below. This gives you a useful comparison and a route through the reference without changing every setting at once.

For a shop-specific ranked diagnosis, the PrestaShop SEO Audit & Action Plan provides read-only findings and proposed fixes; implementation, content writing, link building and ongoing monitoring are separate.

Choose stable URLs and keep required route fields

Start in Shop Parameters → Traffic & SEO → SEO & URLs. In Set up URLs, check the Friendly URL setting and the current route patterns. On a live shop, export your existing URLs before changing them.

A product URL such as index.php?id_product=42&controller=product can become a readable path such as /42-mens-leather-wallet.html. Numeric IDs do not prevent a page from ranking. Keep established URLs unless the change has a clear purpose.

Saving Set up URLs invokes .htaccess generation for Apache. Check that rewriting and the shop's physical base path work. Nginx does not read .htaccess; configure equivalent rules on the server. If friendly URLs return 404, check the rewrite configuration, base path and requested route before renaming products.

Core routes still need IDs

Core product and category routes require their ID keywords. Removing {id} from the route field does not add slug-based entity lookup. PrestaShop 9's default product pattern omits the category component, but it still contains the product ID and optional combination ID.

# PrestaShop 9 core product route
{id}{-:id_product_attribute}-{rewrite}.html

# Core category route
{id}-{rewrite}

ID-free routing needs an implementation that resolves those routes and handles collisions and redirects; see the Smart SEO Friendly URL Manager help if that is the requirement.

Check collision scope before a routing change

Use the real database prefix. The following read-only query finds product slugs shared by distinct product IDs within the same shop and language. It is a preliminary check for slug-based routing, not a reason to change functioning core URLs.

SELECT id_shop, id_lang, link_rewrite,
       COUNT(DISTINCT id_product) AS product_count
FROM ps_product_lang
GROUP BY id_shop, id_lang, link_rewrite
HAVING COUNT(DISTINCT id_product) > 1;

If your routing implementation uses category paths, include the effective path in the collision check. Check products, categories, CMS pages, brands and any module routes that share the same namespace. Do not count the same product in several shops as several conflicting products.

• Use descriptive words and hyphens. Prefer readable slugs to a fixed word-count rule.
• Choose a consistent trailing-slash and suffix policy for each route type. Core categories do not universally require a trailing slash.
• Keep internal links, canonicals, sitemap entries and redirects aligned with that policy.
• Plan a permanent redirect when an existing URL actually moves.

Verify HTTPS, domain normalisation and migration redirects

Provision a valid certificate first. Then enable SSL and SSL on all pages in Shop Parameters → General. Check the shop domain and SSL domain, generated asset URLs and the browser's mixed-content warnings.

PrestaShop's front controller implements SSL redirects. A reverse proxy must pass HTTPS information correctly or the application can generate wrong URLs or enter a redirect loop. Server rules can complement application redirects and combine host and scheme normalisation.

1. Choose the preferred HTTPS host, with or without www.
2. Test HTTP, the alternate host, the preferred host and representative language paths.
3. Check each redirect target and final response. Aim for a direct redirect to the final destination.
4. Test products, categories, CMS pages, module URLs, checkout and callbacks after server-rule changes.

curl -I -L https://example.com/42-mens-leather-wallet.html
curl -I -L http://www.example.com/42-mens-leather-wallet.html

Three different redirect controls

Export old URLs and map each changed address to its equivalent destination. Avoid chains and blanket redirects to the homepage. A theme change only needs URL redirects if URLs actually change; separately test its canonicals, schema, internal links and headings.

Check home-page variants such as /, /index.php, /en/ and /en/index.php. Keep intentional language versions. Do not use a broad index.php rule that also catches functional query-string routes. Normalise ?page=1 only when it represents the same first listing page and preserve unrelated parameters.

For discontinued products, redirect only to a genuinely equivalent replacement. Otherwise keep useful unavailable-product information or return an appropriate 404/410. A redirect to a merely similar item can confuse shoppers and be treated as a soft 404.

Write useful titles, descriptions and page content

Edit product metadata in the product SEO section, category metadata in the category editor and CMS metadata in its page editor. In Traffic & SEO, review the index entry for the homepage and the other static-page entries, including contact and stores.

Replace ps_ with your installation's prefix. An empty product meta title can fall back to the product name; the final title also depends on the installed theme and SEO modules. Inspect the rendered title instead of assuming a particular suffix.

Practical title and description patterns

Product: Main product name - useful distinction | Shop name
Category: Category name - useful distinction | Shop name
CMS: Page topic | Shop name

Lead with the topic and make each title distinguishable. A concise title around 50 to 60 characters can be an editorial target, but Google has no fixed character limit and may rewrite or truncate the displayed title. Follow Google's title guidance.

Write a page-specific description that accurately summarises the content. Include a useful feature, delivery detail or call to action only when it is true for that page. Google can use page text instead, and snippet length varies by device and query. Programmatic descriptions are appropriate when they remain readable and specific; leaving a field blank is not universally better than a good template. See Google's snippet guidance.

Bulk changes

Back up the database and preview bulk metadata changes as a SELECT before any update. Join product, default-category and translation data within the correct shop and language. Preserve manually written values unless replacement is intentional. Use supported imports or APIs when you need validation, hooks and cache invalidation.

SELECT id_product, id_shop, id_lang, name, meta_title
FROM ps_product_lang
WHERE meta_title IS NULL OR TRIM(meta_title) = '';

Content and headings

Give category pages useful descriptions that explain the selection and link to relevant subcategories. PrestaShop 8 and 9 provide an additional category description; its placement depends on the theme. For an older shop needing that extra content area, use the Second Category Description help.

Replace copied supplier descriptions with accurate product-specific information. Prioritise commercially important pages, then expand. Add original buying advice, dimensions, materials, compatibility and care information where those details help the customer. Review automatically generated copy before publishing it.

Turn a search topic into a useful page brief

Map the search topic to an existing category, product or guide before creating another page, and check that choice against Search Console queries and customer questions. For an office-chair category, start with the questions that determine the selection: seat adjustment, desk clearance, materials and suitability for the intended use. Put the short explanation where it helps someone choose, and link to the relevant ranges or a fitting guide. A sentence that repeats “office chairs” without helping that decision adds little to the grid.

For an individual chair, collect the verified dimensions, adjustment range and included parts before writing. If those facts come from an import, identify the authoritative fields and who corrects them. A title promising adjustable arms must agree with both the product details and the option delivered to the basket. Keep delivery or availability promises out of reusable text unless your team can keep them accurate for every affected market.

Check the result on the actual mobile page: can a customer see the selection, find the buying advice and reach the linked range? A saved category description that the theme never displays does not answer the buyer's question. Keep the useful brief with the product data so later translations and imports preserve its meaning.

Use a clear main heading and a semantic hierarchy that works for screen readers. Google does not require exactly one H1 or a magical heading count. Match the heading to the visible subject and keep important content accessible on narrow screens. The product SEO content guide covers the content workflow.

Separate canonical URLs, crawling and indexing

A canonical link identifies the preferred URL for duplicate or very similar content. It is a signal, and Google can choose another URL. A redirect moves the request. noindex prevents indexing when the crawler can read it. A robots.txt rule controls crawling.

<link rel="canonical" href="https://example.com/42-mens-leather-wallet.html">

Inspect the final HTML head and response headers for your actual theme. Test a normal product, a combination, an alternative category path, a filtered listing, a sorted listing and a tracking URL. Core canonical redirection does not generally strip arbitrary query parameters: an additional query string can be accepted without redirecting.

PrestaShop 9's listing controller sets noindex when q or order is submitted. Check the rendered result because themes and modules can change it. Do not assume that every custom filter, legacy parameter or module route receives the same treatment.

For multistore, verify the host, path, language and canonical in every shop context. Cross-domain canonicals are appropriate only when you deliberately want duplicate content consolidated to another domain. For explicit product exceptions, see the Product Canonical Manager help.

Pagination

Keep useful category pagination crawlable and give each page its own canonical URL. A second listing page contains different products from page one. Do not point all pages at page one or automatically noindex every page after page three. Google no longer uses rel="next" and rel="prev" as indexing signals. Follow the pagination guidance.

Provide normal crawlable links to later pages and back to the category start. Infinite scroll or a Load more button still needs discoverable paginated URLs. Increasing products per page reduces page count but also changes rendering cost, so test both usability and performance. Test with a product that appears only on a later page: follow ordinary links from the category to that page and then the product, without relying on scrolling or an internal search. This exposes a discovery gap that a healthy first-page canonical can hide.

Faceted combinations

Filters can multiply URL variants. For example, choosing one of five colours, one of eight sizes and one of four price bands gives 160 combinations before other options. Keep only intentional landing pages indexable. Do not combine a robots block with an expectation that Google will read the page's noindex or canonical tag. If unwanted variants are already indexed, establish how the crawler will receive the removal signal before introducing a crawl block; do not assume a newly saved robots rule removes them from the index.

Map language and regional alternatives correctly

Use hreflang to help Google serve the suitable language or regional version. It is not required for Google to discover or index translated pages. Each alternate should be a reachable, indexable URL representing the equivalent content.

<link rel="alternate" hreflang="en" href="https://example.com/en/42-wallet.html">
<link rel="alternate" hreflang="fr" href="https://example.com/fr/42-portefeuille.html">
<link rel="alternate" hreflang="x-default" href="https://example.com/en/42-wallet.html">

Include each page itself and the other alternates. Use fully qualified URLs and reciprocal links. Missing return links affect the relevant relationships; they do not inevitably invalidate every other pair. HTML tags, HTTP headers and XML sitemaps are equivalent delivery methods, so choose the one you can maintain consistently.

Use language-only codes such as en or fr when appropriate. Add a region for regional versions, such as en-GB or en-US; en-UK is incorrect. x-default is a useful fallback for unmatched visitors, often a selector or default-language page, but its absence alone does not invalidate other annotations.

Check reciprocal links, canonical targets, indexability and the mapping of equivalent products in each shop. Separate domains are allowed. For cross-shop mappings, do not assume that a translated slug or product ID is identical everywhere. See Google's localised-version guidance and the PrestaShop hreflang guide.

Suppose a product is sold in the English shop but has no equivalent French product page. Do not substitute the French homepage just to fill the alternate set. Record the missing equivalent, omit that relationship and retest when the translated page is published. Keep that mapping decision separate from whether the product is temporarily out of stock in an existing market.

The Hreflang Tags Manager help explains language alternates built from each shop's own page addresses; for independent shops with different product IDs or catalogues, confirm how equivalent pages will be mapped before choosing an implementation.

Validate the rich-result type you actually want

Structured data can make a page eligible for enhanced search appearances. Valid markup does not guarantee display or a ranking increase. Keep its name, price, currency, availability and reviews consistent with the visible page.

Use the applicable product snippet or merchant listing requirements. Missing required properties can prevent eligibility. Recommended-property warnings are different from errors, and neither is automatically a general negative ranking signal. Structured-data spam is a separate issue.

Find the producer before editing

Search the installed theme and modules for application/ld+json and the relevant schema type. Theme releases differ. Hummingbird's product template includes _partials/microdata/product-jsonld.tpl; do not assume that its product-details partial owns the schema.

Breadcrumb rendering and JSON-LD are theme- or module-dependent. Identify the component producing them instead of looking for a universal core breadcrumb module. Custom JSON-LD can be built as a PHP array, encoded safely with json_encode() and rendered through a supported hook or template. Keep one owner for each overlapping entity and property. For a product with combinations, select a different option and compare the visible price, stock message and submitted basket with the structured data for the URL being tested. If an import changes availability, repeat that check after the import and after the relevant cache refresh; manually fixing a value in a template can hide a stale source rather than repair it.

For managed Product, Offer, Breadcrumb and Organization output, see the Automatic SEO Schema Rich Snippets help; FAQ output belongs to a separate implementation such as SEO Revolution.

1. Test representative products, categories, the homepage and content pages in Rich Results Test.
2. Inspect the rendered HTML and confirm the values match the customer-visible page.
3. Check logged-out prices, currency, variants, tax and availability in the relevant shop context.
4. After release, monitor the applicable Search Console rich-result reports.

Publish the preferred URLs in a current XML sitemap

Sitemap generation comes from an installed module, not the core SEO & URLs page. Install gsitemap if it is absent, or use the sitemap implementation appropriate to your shop. The Google Sitemap module supports image entries, modification dates and file splitting; those features do not require replacing it at an arbitrary product-count threshold.

Use the URL shown by the installed module. A common gsitemap index is /1_index_sitemap.xml, with the shop ID in the filename, rather than a universal /sitemap.xml. Use its generated scheduled-task URL, including the token and shop ID; do not copy an old root PHP cron filename.

• Include the canonical products, categories and content pages you want indexed.
• Include supplier or brand pages when they serve a useful customer-facing purpose.
• Exclude redirects, errors, noindex pages, account/checkout URLs and unselected filter variants.
• Use accurate lastmod dates for meaningful changes.
• Generate files for the correct shop domains and language paths.
• Regenerate at a frequency matching actual catalogue changes and check scheduled-job failures.

A sitemap has a limit of 50,000 URLs or 50 MB uncompressed per file. Use an index for multiple files. Submit the actual index URL in Search Console and reference it from robots.txt. Submission assists discovery; it does not force indexing. See Google's sitemap guidance.

Google's old sitemap ping endpoint is retired. Use Search Console and robots.txt rather than treating a successful module notification as proof that Google accepted the sitemap. Google's deprecation notice explains the current submission behaviour.

If you need HTTP verification and additional exclusion controls, see the Advanced SEO Sitemap Builder help.

A sudden reduction in published URLs needs investigation. Check non-200 responses, redirects, noindex headers or meta tags, and canonical mismatches before assuming the catalogue disappeared from search. Treat temporary server errors as failures to retry rather than healthy pages to publish.

Generate and test robots.txt for the actual shop

Serve the controlling file at the origin root, such as https://example.com/robots.txt. A shop installed at /shop/ cannot rely on /shop/robots.txt for crawler control. Include the real shop path prefix in rules.

Robots.txt manages crawling. It does not protect the admin directory or private data, and a blocked URL can still appear in search without a fetched description. For indexing removal, allow the crawler to read a noindex directive or return the appropriate removal status. Use authentication and server access controls for private resources. See Google's robots.txt guidance.

Start with the generated file

Back up custom rules before using Shop Parameters → Traffic & SEO → Robots file generation. Generation overwrites the file. Compare the result before deployment, then restore deliberate customisations.

Current PrestaShop 9 generation already includes q and order parameters, transactional controllers, language-specific friendly routes and shop physical paths. It also blocks system directories while allowing module CSS, JavaScript and image files. Preserve those exceptions.

The following is only an excerpt of the current generator's patterns. It is not a complete replacement file.

User-agent: *
Allow: */modules/*.css
Allow: */modules/*.js
Allow: */modules/*.png
Allow: */modules/*.jpg
Allow: */modules/*.gif
Allow: */modules/*.svg
Allow: */modules/*.webp
Allow: */modules/*.avif
Allow: /js/jquery/*
Disallow: /*?order=
Disallow: /*&order=
Disallow: /*?q=
Disallow: /*&q=

Add a Sitemap: line with the actual public sitemap-index URL if it is not present. Do not block all query strings. Keep product and category URLs and resources needed for rendering crawlable.

Review each URL family

Test allowed and blocked examples

1. Fetch the public origin-root file and verify the response body is the intended text.
2. Run representative product, asset, filter, account and paginated URLs through a suitable rule validator for the relevant user agent.
3. Use Search Console's robots.txt report to check fetching and parsing, then URL Inspection for an affected page.
4. Review bot requests in server logs and monitor unexpected Page indexing changes.

For multistore, each origin must serve suitable rules at /robots.txt. Shops sharing one document root may serve a suitable shared file; physically separate files are needed only when your serving arrangement or rules require them.

Review the file after changing route patterns, public module routes, theme asset paths, languages, shop paths or multistore configuration. Keep the custom-rule backup so regeneration does not silently remove it.

Separate AI training, search and user-requested retrieval

Choose crawler preferences by purpose. Blocking a training bot and blocking a search crawler have different effects. Robots.txt relies on the service's documented behaviour; it is not an access-control system.

For a policy that excludes these two model-development crawlers, the additional groups are:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

These groups do not express your separate search preferences. Follow the official OpenAI documentation and Anthropic crawler documentation for the purpose of each agent.

Google-Extended is a separate control for certain Gemini training and grounding uses. It does not determine inclusion or ranking in Google Search. Check Google's crawler documentation before selecting that policy.

Set image legends and measure the delivered images

Edit the image Legend in the product editor and provide a concise description of what the image shows. Set the convention before imports. Core can fall back to the product's meta title or name when a stored legend is empty, so an empty database field does not necessarily produce an empty alt attribute. Inspect the final theme output.

There is no general core image-alt template setting in Traffic & SEO. Image URL rewrites and physical image filenames are also separate. Check the delivered URL, the visible image and its alt text rather than assuming renaming a slug changes every stored file.

When several photographs show the same item, describe the distinguishing view where it matters, such as the chair's adjustment controls or the underside fitting. Check a translated page as well as the default language. If the stored legend is accurate but the delivered alt text is wrong, trace the theme or module choosing that fallback before rewriting the whole image library.

Use the Automatic SEO Images Alt Tags help when catalogue-wide alt-text rules are needed.

• Choose image dimensions appropriate to the rendered size and provide responsive sizes where the theme supports them.
• Compare actual image file sizes and visible quality. Core has configurable encoding; its output is not universally poorly compressed.
• Use supported WebP or AVIF output when the PrestaShop release, PHP image library and theme support it. Regenerate the affected formats or thumbnails after changing settings.
• Choose quality from measured output rather than applying one fixed value to every format and catalogue.
• Lazy-load offscreen images. Keep the measured LCP image eager and readily discoverable.
• Give images intrinsic dimensions or a reserved aspect ratio to limit layout shifts.
• Include relevant images in the sitemap when your generator supports them.

If the theme's offscreen-image behaviour needs additional control, use the Automatic SEO Images Lazy Tags help.

Measure Core Web Vitals and test asset changes

Use Core Web Vitals field data to understand real customer experience, then reproduce the slow page or interaction in development tools. A good score does not guarantee a ranking outcome. Compare representative homepage, listing, product and checkout routes.

Assess these at the 75th percentile of visits. PageSpeed Insights can show CrUX field data when enough data is available; a normal Lighthouse page-load run does not provide an equivalent field INP measurement. Use reproduced interactions and traces to diagnose INP. Lighthouse Total Blocking Time is a useful diagnostic proxy, not INP itself. See the INP guidance.

Images, fonts and layout

Identify the actual LCP element before optimising it. If it is the main image, avoid lazy loading it, serve an appropriate format and size, and consider high fetch priority or a targeted preload. Check that preloads do not duplicate downloads or compete with more important resources.

Reserve space for banners and late content. Use suitable fallback fonts and test font-display behaviour for shifts. Self-hosting fonts can remove third-party connection setup, but still measure the result. Keep only necessary weights and character ranges, use WOFF2 where appropriate and preload only fonts needed early.

PrestaShop performance settings

In Advanced Parameters → Performance, review Smarty caching and CSS/JavaScript CCC options on staging. Measure cache behaviour and rendering before enabling each optimisation in production. Combining requests can help some pages and provide little benefit or create ordering problems on others.

Audit actual registered files and execution dependencies. A module hooked into displayHeader or displayFooter does not necessarily output JavaScript. Raw asset tags can bypass the asset manager. Bottom-position JavaScript without defer is supported behaviour, not automatically a bug.

Load assets only on pages that need them. Test defer and async against dependency and initialisation order. Review third-party analytics, chat and advertising scripts through interaction traces instead of assuming they explain every field-data regression.

Use the PrestaShop performance guide for cache, database, server and frontend diagnosis.

Build useful navigation and contextual links

Organise the category tree around how customers look for products. Use meaningful groupings such as Shoes, Men's Running Shoes and Trail Running Shoes when the catalogue supports them. Avoid empty or near-identical categories created only to target a keyword variation.

Check breadcrumbs on the page types you use. In current PrestaShop 9 code, PS_PRODUCT_BREADCRUMB_CATEGORY chooses the current access category or the default category. Set an appropriate default and test both navigation paths when a product belongs to several categories.

Connect relevant accessories and related products in the product editor, then verify that the theme renders crawlable product links. Link size guides, installation advice, shipping policies and care instructions from relevant descriptions and category content. Keep useful CMS and blog content reachable through normal navigation.

Use descriptive link text and correct final URLs. Avoid automated links that distort sentences or point to unrelated products. A blog can address informational questions and link naturally to useful products, and keep each page useful enough to justify publishing it.

For managed contextual links across your content, see the Automatic Internal SEO Linker help.

Diagnose Page indexing statuses and set realistic expectations

Open Search Console's Page indexing report and investigate URLs that should be indexed. A large Not indexed total is not automatically a problem: intentional duplicates, redirects and noindex pages belong outside the index.

For an important affected URL, inspect the indexed record and run a live test. Review status, robots permissions, noindex headers or meta tags, canonical, rendered content and internal links. Compare the live version with the version Google last processed. Use the Page indexing report documentation for each status. Keep a small URL register with the intended search role, current response, declared canonical, Google's selected canonical where available, last observed state and person responsible. Group URLs by shared template or rule so you can distinguish an isolated product mistake from a repeated category fault. Do not extrapolate from a tracking URL's expected exclusion to the canonical product's health.

Pages worth improving

Strengthen useful pages with accurate information and relevant internal links. For near-duplicate variants, decide which pages deserve separate indexation and align the content and canonical strategy. Keep a useful out-of-stock page with accurate availability when customers still need it. Remove genuinely obsolete pages or redirect only to equivalent replacements.

A curated search landing page can be useful when it has a stable topic, selected products, original guidance and internal links. A raw search query with repeated listings is a different page type. Keep ordinary search results out of sitemaps and publish curated pages deliberately.

Useful landing page: /search/walk-in-shower-trays with original advice and selected products.
Ordinary search: a raw ?s=shower result with repeated listings and no additional purpose.

After a fix

Keep sitemaps and internal links current. Request indexing for important changed pages when appropriate, and request validation for a resolved report issue. Repeated submissions do not force Google to index a crawled page.

There is no fixed date for SEO improvement after installing a module. Google must recrawl and reprocess changes, and it can take different amounts of time for different URLs. A module cannot guarantee indexing, rich results, rankings or traffic recovery. Track the affected URLs and search performance over time instead of treating an installation date as a deadline.

Give each SEO feature a clear owner

If you run more than one SEO tool, decide which component owns canonical links, robots directives, hreflang, Open Graph tags and each structured-data entity. Multiple JSON-LD blocks are not inherently wrong; contradictory or duplicate descriptions of the same entity need attention.

A familiar WordPress plugin name does not establish PrestaShop compatibility for a similarly named product or another platform's plugin. Check the actual module and platform version you plan to combine.

1. List the theme and modules producing SEO output.
2. Choose one owner for each overlapping feature and disable conflicting output elsewhere.
3. Inspect the final HTML and headers on all important page types, languages and shop domains.
4. Retest after theme, SEO module or catalogue changes.

SEO Revolution includes theme-head cleanup, and Blog Revolution can defer its blog structured data to that integration.

Choose configuration, a tool, development or an audit

Use a tool for a recurring, clearly diagnosed requirement. A single incorrect title, an accidental noindex or a missing redirect may only require a configuration or content fix. A suite is not a substitute for deciding which URLs should exist and be indexed.

A catalogue's product count alone does not choose the route. A small multilingual shop can have a complicated mapping fault, while a larger shop may already maintain coherent output. Before buying a tool, ask what repeated task it will remove, who maintains its rules and how you will tell whether it solved that task.

Recognise when an SEO audit will answer a real question

Start with a specific symptom and the pages affected. A traffic drop, a shrinking set of useful indexed pages, broken migration redirects or lost rich-result eligibility can justify a closer check. Use URL-level checks to find the cause behind a count or score.

• Compare Search Console clicks and impressions with analytics. Check date ranges, query groups, country, device and seasonality.
• Compare the change date with deployments, URL edits, robots changes, imports and confirmed search updates.
• Investigate a useful page disappearing from the index; do not treat every expected alternate exclusion as an error.
• After a redesign, test canonical links, schema, headings, content and internal links even when URLs remain unchanged.
• Check slow responses, repeated server errors and inaccessible resources alongside search-specific issues.

An unexplained drop is not automatically a fault in your shop. Search demand, competition, measurement changes and ranking changes remain possible. A confirmed search update also does not rule out a simultaneous technical problem.

Use a verified Search Console property that covers the shop URLs under investigation. If you lack access or the report is empty, ask the owner to confirm the property and its scope before drawing conclusions. The absence of data in the wrong property does not establish that your products receive no search visits.

A first self-check

1. Review Page indexing and Performance trends, then inspect a small set of important affected URLs.
2. Crawl representative pages and look for broken links, loops, unexpected canonical targets and contradictory directives.
3. Check a product, a category, page two, a filter variant, a language alternate and the homepage.
4. Fetch robots.txt and the actual sitemap index. Confirm the content and listed URLs are appropriate.
5. Use Rich Results Test and PageSpeed Insights for the page types where the symptom appears.

A site: search can reveal unwanted examples, but its result count is not a reliable index inventory. A crawler's own limits also affect what a quick crawl can tell you.

# Read the canonical in the returned HTML
curl -sS https://example.com/42-mens-leather-wallet.html | grep -i canonical

# Check public files using their actual locations
curl -sS -o /dev/null -w '%{http_code}
' https://example.com/robots.txt
curl -sS -o /dev/null -w '%{http_code}
' https://example.com/1_index_sitemap.xml

These commands are read-only. A canonical can wrap across lines or appear with attributes in another order, so confirm the full HTML when a simple text check misses it. Follow and inspect an unexpected redirect rather than treating every non-200 first response as the same fault.

If the check identifies one clear issue, fix it and verify the affected pages. If several systems disagree or the cause remains unclear, an audit should deliver affected URLs, reproducible findings, priority, proposed fixes and validation steps. Agree its scope, access and deliverables with the provider. An audit diagnoses; it does not promise traffic recovery. Distinguish a confirmed defect from a hypothesis and from a limitation of the evidence. A crawler cannot report a page it never discovered, and its clean report does not establish what Google indexed or what a customer receives in another shop context.

Work through a category losing search visits

Suppose a trail-running-shoes category loses search clicks after a theme deployment while a comparable road-running-shoes category appears stable. This is a hypothetical investigation, not a claim that a deployment always explains a decline. Keep the affected URLs and release record, and compare the relevant query groups, devices and countries over comparable periods before selecting a fix.

1. Check the observation. Confirm the correct Search Console property and landing-page filter. Compare impressions, clicks and queries, then check analytics and actual orders separately. A changed consent or analytics setup can alter recorded sessions without the same change in search clicks.
2. Compare the pages. Inspect the affected category and the comparison category in the same shop and language. Check the response, headers, robots directives, canonical, visible heading, product grid and links from the navigation.
3. Reproduce the fault. Suppose the affected category returns a normal page but declares the homepage as canonical, while the sitemap still lists the category. Record that output and check the indexed record; do not assume Google has already followed the wrong signal.
4. Find the producer. Compare the theme change with the component that generates the canonical. Check category-specific settings and module overrides of that output. If a shared template causes the fault, fix that producer rather than adding another canonical tag beside it.
5. Prove the correction on staging. Verify the intended category canonical and test other categories, pagination, filters and language versions that use the same code. Confirm that the product grid, links and buying journey still work.
6. Release and follow the URLs. Deploy the scoped correction, verify the live HTML independently and keep the release time with the evidence. Update any other conflicting signals and follow the affected URL records as Google recrawls.

The immediate acceptance evidence is the corrected output and a functioning shop. A later recovery in clicks is an observation to evaluate against demand and other changes, not proof that every lost visit had the same cause. If the canonical was already correct, retain that result and investigate the next plausible cause rather than applying the example's fix anyway.

Agree what the assessment will deliver

Ask for findings ranked by business impact and effort, with example URLs, the cause, a proposed correction and a way to validate it. An outside-in SEO review can work from public pages; read-only Search Console access adds indexing and performance evidence where available. Agree any additional access separately instead of assuming an auditor needs a back-office login.

A useful action plan distinguishes work your team can do in the editor from module configuration and development. Specify who will implement it, who will approve the page checks and who will monitor the result afterwards. A diagnosis alone does not include those jobs, and a generic export of crawler warnings does not explain which task your shop should do first.

What to ask your developer or agency

• Which commercially important URLs are affected, and which comparable pages still work?
• What evidence connects the symptom to the proposed cause, and what remains uncertain?
• Which theme, module, server rule or import produces the disputed output, and could a scheduled job overwrite the correction?
• Which shops, languages, currencies and customer contexts will be tested, including pages that should remain unchanged?
• What exactly will change, how will we reverse it, and will any product or order data be touched?
• Who will deploy, keep the before-and-after evidence, and review the affected URLs after release?

Keep a repeatable technical and SEO maintenance record

Schedule a brief recurring review and a fuller check after major changes. A half-hour session can cover a sample and identify follow-up work; it is not a complete audit guarantee for every store.

Preview cleanup candidates before deletion, keep appropriate retention periods and use limited batches when necessary. Old carts associated with orders, active references and other shops need deliberate protection. Do not delete order or customer data just because a table is large.

For the count-first cleanup workflow and task-specific retention controls, use the Database Cleanup help.

Track OPcache scripts, memory, hits and misses; compare slow-query groups by route or controller; and record included and skipped sitemap URL counts and the latest successful backup. Use comparable periods so the record shows trends.

For module cache-layer and slow-query diagnostics, use the Performance Revolution help.

Fix security exposure and broken shopping functions first. Then address server errors and accidental indexing blocks, incorrect destinations, content and structured-data issues, and measured performance problems. Verify changes on staging before deployment and repeat the affected customer and crawler paths afterward.

Rehearse a change and plan the live switch

1. Keep a baseline. Save representative URLs, redirects, HTML and headers with the shop, language and relevant module configuration. Include an unaffected comparison page and any old addresses that still bring customers.
2. Prepare the copy. Protect staging with access controls, neutralise transactional email and live external actions, and check that it reproduces the relevant theme, modules and catalogue state. Use host-appropriate canonical and alternate URLs during testing rather than leaving staging addresses to be copied into production.
3. Record the intended change. List the settings, files, rules or scoped data that will change and the component responsible for each output. If an import creates the fault, rehearse that import instead of testing only a manual editor save.
4. Run the acceptance paths. Check the affected page families and deliberate exceptions, then browse from navigation to a product, basket and checkout. Include functional module routes and provider callbacks when changing server rewrites or access rules.
5. Prepare reversal. Keep the previous relevant configuration and files, and define the symptom that would trigger reversal. For data edits, retain the scoped before-values and a reviewed reversal procedure; restoring an old whole-shop database can overwrite new live orders.
6. Agree the release. Choose a window your team can support, name the person applying and checking it, and account for imports, feeds and cache jobs that run around the change. Deploy the tested change to the current shop rather than copying stale staging data over it.
7. Check production independently. Confirm the live host, redirects, headers, canonical, language alternatives and affected customer paths after caches refresh. Confirm that production has no accidentally copied staging noindex or access block, while the protected copy remains protected.
8. Keep technical and search follow-up separate. Check output and shopping immediately, then review affected URL records and search trends as new observations arrive. Record unrelated releases so a later movement is not automatically attributed to this one.

Search Console, a site crawler, PageSpeed Insights and Rich Results Test answer different questions. Compare their findings with rendered pages and server behaviour. Use the troubleshooting guide for redirect loops, 404s and application errors before making further SEO changes.

Questions owners ask

Can I fix a clear problem without paying for an audit?

Yes. If you can identify the cause and verify the correction, use the configuration, content or development route that fits it. Diagnosis earns its place when the cause or scope is uncertain, not merely because a report contains warnings.

Do more excluded URLs mean my SEO is getting worse?

Check which URLs they are. Expected alternates and redirects can increase while useful pages remain indexed. Follow the commercial pages you intended to index and investigate changes in that set rather than pursuing a larger total at any cost.

Should a small shop buy an SEO suite or an audit?

Choose from the problem and your team's ability to maintain the solution. An isolated understood mistake needs a correction; recurring rules may justify a tool; an unexplained material loss may justify an assessment even for a small catalogue.

Must I remove product IDs or change my theme to rank?

Neither follows from a ranking problem alone. IDs are compatible with ranking, and a theme should be judged by its actual output and customer journey. Establish what fails before committing to a URL migration or replacement theme.

The crawler reports no errors. Can I stop investigating?

A crawl has a scope and a discovery path. Compare its coverage with the pages that matter, Search Console and the relevant customer context. A valid response does not establish useful content, correct indexing or a working purchase.

Does an audit include the fixes and ongoing monitoring?

The linked assessment supplies findings and an action plan. Implementation, content writing, link building and ongoing monitoring need separate scope and responsibility, so agree the handover before treating a report as completed remediation.

How do I know a correction worked before rankings change?

Keep the original reproduction and rerun its acceptance checks on the live shop. The corrected response or output is evidence you can obtain directly; search visibility needs subsequent observation and has no guaranteed recovery date.

Can we reverse an SEO release safely?

Prepare the reversal while rehearsing it. Restore the affected settings, files or scoped values as planned, with current orders protected, then check production again. A backup is useful only when you understand what restoring it would replace.