Ecommerce SEO: the four things that compound, and the rest that does not
Product data, structured markup, one canonical page per product and copy a person would actually read. Everything else is a rounding error on a catalogue of a thousand items.
Search is the only acquisition channel that does not switch off when the budget does. It is also the one most likely to be handled by nobody in a small shop, because the advice available is either aimed at publishers with an editorial team or aimed at agencies selling retainers.
For a catalogue of a few hundred to a few thousand products, four things account for nearly all of the result. They are unglamorous, they are mostly structural, and they compound — which is the entire reason to do them before anything else.
1. One canonical URL per product, and mean it
WooCommerce is generous with URLs. Variations, filters, sort orders, pagination and tag archives can produce dozens of addresses that serve nearly the same content. Google then has to guess which one is the page, and it will sometimes guess differently from you.
- Point variants at the parent. A colour or size variation is usually not a separate page worth ranking. Set a
rel=canonicalto the main product URL. - Keep faceted navigation out of the index. Filter combinations are for shoppers, not for crawlers. Block the parameter patterns or mark them
noindex, and never link to them from navigation. - Do not delete discontinued products. Redirect them to the closest replacement or the parent category with a 301. A dead product page that returns 404 throws away every link and every ranking it ever earned.
- Check what is actually indexed. Google Search Console's page indexing report will tell you how many URLs it found and how many it chose to ignore. On most catalogues the gap is a surprise.
This is the least interesting work in the article and the one with the highest return, because it decides whether your effort lands on one strong page or is spread across nine weak ones.
2. Structured data that matches what is on the page
Google's product rich results are driven by schema.org/Product markup: name, image, description, brand, and an offers block with price, currency and availability. When it is present and correct, the search result can show price and stock status directly — which changes the click-through rate before anyone reaches your site.
The requirement that gets shops in trouble is consistency. The structured data has to match the visible page. If the markup says 39 € and in stock while the page says 49 € and backordered, the rich result can be suppressed and the domain can pick up a manual action for structured data spam. This is one of the few areas where a technical mistake becomes a penalty rather than merely an absence.
- Generate the markup from the same source as the page — the product record — not from a separate field somebody updates by hand.
- Include
availabilityand keep it live. Stale stock status is the most common mismatch. - Add
AggregateRatingonly if the ratings are genuinely on the page and genuinely from customers. - Validate with the Rich Results Test after any theme or plugin change, because templates are where markup quietly breaks.
3. Product copy written for the question, not the keyword
The manufacturer description on your page is on four hundred other pages. It is not that duplicate content gets you penalised — Google is explicit that it does not, in the ordinary case — it is that there is no reason for a search engine to prefer your copy of it over a larger retailer's.
What differentiates a product page is the information a shopper needs before they can commit, which the manufacturer never writes:
- Fit, size and compatibility in concrete terms. “Fits a 60 cm shelf” beats “compact design”.
- What is in the box. Counts, dimensions, materials, what you have to buy separately.
- Who it is not for. The single most trust-building paragraph you can write, and the one that reduces returns.
- The questions support actually receives. Your inbox is a keyword research tool that nobody else has access to.
- Delivery and returns for this item, if it differs from your general policy.
Do this for the twenty products that matter — the ones with search demand, margin, or stock you need to move. Doing it for all 1,200 is how the project dies in week two.
Where AI fits, and where Google draws the line
Google's position has been consistent and is worth quoting accurately: it rewards high-quality content, however it is produced, and its spam policies target scaled content abuse — generating many pages primarily to manipulate rankings rather than to help people. Automation is not the problem. Publishing a thousand thin pages nobody asked for is.
That distinction gives a workable rule for a small team:
- Reasonable: using a model to draft a product description from your own specification sheet, in your own tone, which a person then checks against the physical item.
- Reasonable: generating alt text, meta descriptions and internal-link suggestions at catalogue scale, where the source facts come from your product data.
- Not reasonable: generating category-landing pages for every keyword combination you can think of, or descriptions for products nobody on your team has seen.
4. The technical floor: speed, mobile, and not much else
Core Web Vitals are a real but modest ranking input, and since March 2024 the responsiveness metric is Interaction to Next Paint rather than First Input Delay. The honest framing: these thresholds matter for conversion far more than they matter for ranking, which is a better reason to fix them anyway.
- LCP under 2.5 s — usually the hero or first product image. Serve it in a modern format, at the size it is displayed, and do not lazy-load the one above the fold.
- INP under 200 ms — usually a script that blocks the main thread. The apps you installed and forgot are the first place to look.
- CLS under 0.1 — set explicit width and height on images so nothing jumps.
- Use the Search Console Core Web Vitals report, which is field data from real visitors, rather than a lab score that flatters your laptop.
Where SEO and campaigns actually meet
These are usually run as separate disciplines, which wastes most of the overlap. Three connections are worth making deliberately:
- The same product data feeds both. Price, stock and images that are correct on the product page are also what a campaign should quote. If your newsletter advertises a price the page no longer has, that is the same data problem as broken structured markup.
- Campaign copy is a draft of page copy. The angle you wrote for an email — why this product, for whom, right now — is often better than what is on the product page, and it is already in your voice.
- Search tells you what to send. The queries bringing people to a category are a free, honest signal of what your audience wants this month. It is better demand research than guessing a subject line.
None of this makes SEO fast. It makes it cumulative, which is the point: a product page fixed once keeps earning, while a campaign earns once and stops.
Sources and further reading (9)
- Google Search Central — Product structured data
- Google Search Central — Consolidate duplicate URLs (canonicalization)
- Google Search Central — Faceted navigation best practices
- Google Search Central — Google Search's guidance about AI-generated content
- Google Search Central — Spam policies for Google web search (scaled content abuse)
- Google Search Central — Creating helpful, reliable, people-first content
- web.dev — Interaction to Next Paint (INP)
- Google Search Central — Understanding Core Web Vitals and Search results
- Google Search Central — Rich Results Test
Checked on 21 September 2026. Provider prices, mailbox rules and legal guidance change — verify anything you plan to act on.
The product data behind your campaigns is the same data search engines read
Auralata reads prices, stock and images straight from WooCommerce, so what a campaign promises is what the product page shows. Copy you approve for a campaign can be reused on the page, in the same voice from the same brand kit.