Duplicate content in ecommerce: Which URLs should Google index?

A customer may find a product through navigation, a campaign or a filtered list. The key questions are which destination URL each route creates and what it returns. A tracking URL may show exactly the same item, while a size filter may change the product selection. Applying the same rule to both without checking would be a mistake.

Google explains that unnecessary alternative URLs can cause additional requests. A crawler cannot reliably identify identical content from the address alone. Source: ecommerce URL structure.

We would group the findings by page type and compare them with the store's commercially important entry pages. A warning in an SEO tool is a starting point for investigation, not an instruction to delete every affected page. Rules that unintentionally remove a valuable category from search deserve particular attention.

Consider a simplified planning example involving an outdoor retailer. Its hiking boots category also exists with prices sorted in ascending and descending order. A separate selection shows waterproof hiking boots for women. The first distinction mainly changes presentation; the second may address a specific purchasing need.

Before recommending a separate search landing page, we would examine the queries, the sustained product range and the benefit to shoppers. A page containing two incidental matches and interchangeable copy is not yet a convincing landing page. A maintained selection with relevant information may be worthwhile.

This gives the retailer a concrete decision: which pages should we actively maintain and link to, and which should remain shopping controls? That decision comes before the technical rule. Installing a filter module in PrestaShop does not make it automatically.

A canonical annotation indicates the preferred address for identical or very similar content. It is a signal to Google, not a guarantee. A 301 redirect is appropriate when one address permanently replaces another. Internal links and the sitemap should support the intended destination. noindex is not a substitute for consolidating duplicates. Source: Google's canonical guidance.

noindex can exclude an accessible page from indexing. Google must be able to fetch the page and read the instruction. Blocking it in robots.txt at the same time can prevent that. A crawling block is therefore not a reliable removal request for an already indexed URL. Source: Google's noindex guidance.

In an implementation, we separate these tasks explicitly: consolidating addresses, keeping a page out of the index or reducing unnecessary requests. Only then do we assign a rule to each URL type. Sending everything to the homepage would not be a useful solution.

Filters help customers find suitable products. We want to preserve that function. At the same time, combining many attributes can create large numbers of addresses. Google recommends targeted crawl controls for filter URLs that are not needed in search; a canonical alone is often less effective for that purpose. Source: faceted navigation and crawling.

Before blocking anything, we establish the current situation: which URLs are indexed, which are used internally and which should remain discoverable? Unwanted pages that are already indexed need a coordinated indexing strategy. Blindly copied robots.txt rules can obstruct the cleanup they were meant to support.

In the outdoor example, we would treat the chosen landing page separately from arbitrary combinations of size, colour, price limit and sorting order. Customers can still filter the catalogue. The SEO strategy does not have to treat every possible selection as an independent search entry page.

Our assessment connects search data with the store's actual functionality. A manageable sample should cover at least its most important URL types:

• URL creation: Which addresses do navigation, search, filters and sorting generate?
• Content: Which pages are identical or very similar, and which serve a distinct purpose?
• Output: Which status codes, canonical annotations and indexing instructions does the store actually return?
• Discovery: Can important categories and products still be found without unwanted URL detours?
• Google's records: What does Search Console report about indexing and the selected canonical URL?
• Ownership: Does the relevant rule originate in the theme, a module, store configuration or server environment?

PrestaShop provides a useful foundation for retailers who want to align categories, filters and technical rules with their catalogue. The work required depends on the installed theme and extensions. We therefore inspect the actual store output rather than routinely recommending another SEO module. For a broader starting point, see our PrestaShop SEO settings guide.

At sjmedia, we would first document the findings with example URLs and the proposed treatment. The retailer confirms which pages matter to the range and the business. We then implement the technical changes in a test environment where possible and compare the agreed cases before and after the change.

Acceptance involves more than a clean crawl report: filtering, sorting, variant selection and purchasing must still work. The product list must not inadvertently hide important items. New rules should also not be silently overwritten by the next module import or theme update.

After deployment, we check the technical output again. We assess developments in Google Search Console separately: fixing the store does not mean Google immediately processes every change. Success means URLs are handled as intended and relevant pages remain accessible. A larger or smaller index count is not an achievement by itself.

If several extensions affect the same URLs or responsibility for the rules is unclear, SEO and technical support should work together. This is where we connect ecommerce SEO with our PrestaShop development and support.

A key category, a few problematic filter URLs and any existing Search Console findings provide a useful starting point for a conversation. From those, we can define an appropriate assessment. The solution might be a small correction, a filter module adjustment or a more substantial revision of URL handling. We explain which approach is needed from the findings. It does not automatically require a platform migration or rewriting the entire catalogue.