Ecommerce SEO · Shopify · WooCommerce · Custom
Most stores that struggle in organic search are not badly optimised. They are badly organised. A catalogue of two thousand products can generate fifty thousand crawlable URLs, bury its best-margin categories four clicks deep, and give Google no clear signal about which page should rank for which purchase. The titles get rewritten, a blog gets published, and nothing moves.
I work on the layer underneath that: how the catalogue is structured, which page is built to answer which search, what Googlebot can actually reach and index, and how product data is communicated to Google. That work is what makes category and product pages capable of ranking at all. It is available as a standalone audit or an ongoing engagement, and it is part of my wider SEO services.
On a service website the page count is finite and every page is written by a person. On an ecommerce site the page count is a function of the catalogue and the software, and most URLs are generated automatically. That single difference changes what the work is.
A store with 2,000 products rarely has 2,000 URLs. Sort orders, filters, pagination, session parameters, tracking parameters and variant URLs multiply the real number, often by a factor of ten or more. Most of those URLs are near-identical to one another. Left alone, they compete for the same queries, split internal link signals across duplicates, and consume crawling on pages that will never earn a visit. The catalogue is not the problem; the uncontrolled URL space around it is.
Three searches that look similar want three different page types. Someone searching silk saree wants a category listing to browse. Kanjivaram vs Banarasi wants an editorial comparison. buy red kanjivaram saree with zari border wants a product page they can purchase from. If the same page is pointed at all three, it will under-serve all three. Deciding which URL owns which query — before writing anything — is the highest-leverage decision in ecommerce SEO.
Ecommerce inventory is not static. Products go out of stock, get discontinued, change price, and exist in a dozen size and colour combinations. Each of those states raises a real SEO question: should this variant have its own indexable URL, should a discontinued product 404 or redirect to its nearest replacement, and what should happen to a page that has ranked for two years and just sold out? Those answers need to be a policy applied consistently across the catalogue, not a decision someone makes per product.
| Area | Regular SEO | Ecommerce SEO | Why it matters |
|---|---|---|---|
| Page inventory | A fixed set of hand-written pages | Templates that generate URLs from catalogue data | Fixing one template fixes thousands of pages — or breaks them |
| Architecture | Flat structure, shallow menu | Homepage → category → subcategory → product hierarchy | Determines what Google can reach and how importance is distributed |
| Duplication | Occasional, usually accidental | Structural — filters, sorts, variants, pagination | Needs canonicalisation policy, not one-off fixes |
| Keyword mapping | Mostly informational and brand terms | Commercial and transactional terms mapped to specific templates | The wrong page type cannot satisfy a purchase query |
| Product data | Not applicable | Price, availability, shipping, returns, identifiers | Feeds Google's product understanding and Merchant Center surfaces |
The order matters more than the list. Every stage below depends on the one before it, which is why running them in parallel — or starting with content because it is the easiest to begin — tends to waste the first six months.
Content published onto a site that cannot be crawled cleanly is content Google may take months to find. Keyword research done before the URL structure is settled produces a map that points at pages which will be consolidated or removed. Fixing accessibility first is not perfectionism — it is what makes the later stages measurable.
The last stage feeds the second. Once real query data arrives in Search Console for pages that were previously invisible, the demand picture changes — categories you assumed were marginal turn out to convert, and terms you targeted turn out to be served better by a different template. The plan should change in response to that.
Architecture is the set of paths that lead to a page, and internal linking is what makes those paths meaningful. Google has said it uses the relationships and links between pages to work out how an ecommerce site is organised and which pages matter most — which means the structure is itself a ranking input, not just a navigation convenience.
Every product should sit under a category that describes it in the words buyers use, and every category should be reachable from the homepage in as few steps as the catalogue honestly allows. Breadcrumbs then make that hierarchy explicit on the page and in structured data. Where subcategories are needed, they should reflect real demand — a subcategory that exists because there are searches for it will earn traffic; one that exists because the merchandising team wanted a tab will not.
Navigation links connect the hierarchy. Contextual links connect intent. A buying guide that compares two fabrics should link into the category a reader would browse next and to the specific products it discusses, using anchor text that describes the destination. This is also how informational content earns its place commercially: it is a route into the pages that convert, not a separate traffic project.
Best-sellers and high-margin lines should not be as hard to reach as the slowest item in the catalogue. Linking them from the homepage, from category landing content, and from related guides shortens their crawl path and signals their importance. In large catalogues this is often the difference between a product page being crawled weekly and being crawled twice a year.
Architecture decides which paths exist. Technical SEO decides whether a crawler can follow them, whether the resulting pages get indexed, and whether the version that gets indexed is the one you intended.
The first question on any store is simple: which pages does Google know about, and which of those has it chosen to index? Search Console's index coverage data usually answers this faster than any crawling tool. What it surfaces most often is orphan pages — products with no internal link pointing at them, reachable only through the sitemap — and pages excluded for reasons the owner did not know were configured. An XML sitemap should list the canonical, indexable URLs and nothing else; robots.txt should block what genuinely must not be crawled, not what you merely want kept out of the index.
Most ecommerce duplication is structural rather than editorial. The same product is reachable through two categories, a tracking parameter creates a second copy, a variant selection appends a query string, and pagination produces a series of pages that look alike. A canonical tag tells Google which URL you consider the primary version. Applied inconsistently — self-referencing on some templates, cross-domain on others, pointing at redirected URLs — it does more harm than leaving it absent, because Google then has to guess. The goal is one indexable URL per genuinely distinct piece of content, with everything else consolidated onto it.
Faceted navigation — the filter set on a category page — is the single most common cause of runaway URL generation on large stores. Four filters with five options each, combinable and in any order, produce thousands of URLs from one category. Google identifies this pattern as a major source of overcrawling. The decision is per facet, not global: a facet that matches real search demand may deserve an indexable, linkable URL, while combinations that no one searches for should not be crawlable at all. I would not assume your store has a crawl problem before looking — it depends on catalogue size, how the URLs are generated, and what the server logs and Search Console crawl stats actually show.
On ecommerce templates the usual culprits are predictable: an oversized hero or first product image driving Largest Contentful Paint, third-party scripts and app embeds delaying interaction and hurting Interaction to Next Paint, and images or banners without reserved dimensions causing layout shift. Product listing pages are especially prone to shift because they load many images at once. These are template-level fixes, which is what makes them worth doing — one change applies to every page built from that template.
| Layer | What is optimised | Typical problems | Business outcome |
|---|---|---|---|
| Technical | Crawl access, indexation, canonicals, speed | Filter URLs consuming crawling; duplicates competing; slow product templates | Pages become eligible to rank at all |
| Category | Taxonomy, keyword mapping, listing quality | No page owns the main commercial term; thin or absent category content | Captures high-intent browse demand |
| Product | Titles, descriptions, attributes, variants, availability | Manufacturer copy duplicated; variants split or merged wrongly | Long-tail purchase queries convert |
| Product data | Structured data and Merchant Center feed | Price and stock mismatched between page and feed | Eligibility for supported product appearances |
| Content | Guides, comparisons, research-stage questions | Blog disconnected from commercial pages | Reaches buyers earlier and links them onward |
| Measurement | Search Console and GA4 reporting | Rankings tracked, revenue not attributed | Spend decisions based on outcome, not position |
Category pages carry most of the commercially valuable non-brand demand in a typical store. They sit exactly where a buyer has decided what type of thing they want but not which one — which is the moment the search volume is highest and the intent is still winnable.
Mapping starts with the demand, not the existing menu. For each commercially relevant term, one page is nominated as its owner, and that page is usually a category or subcategory rather than a product. Two problems surface almost immediately: important terms with no page that could plausibly rank for them, and several pages competing for the same term. The first calls for a new category; the second calls for consolidation.
A category page's primary content is its product listing, and it should be judged as a browsing tool first: sensible default ordering, filters that match how people actually choose, and enough products to justify the page existing. Supporting copy earns its place when it helps a decision — what distinguishes the options, what to consider when choosing, which subcategory to go to next. A paragraph of keyword-bearing text below the fold that nobody reads helps nothing.
Categories should be linked from the places that reinforce their importance: main navigation where they warrant it, breadcrumbs on every product beneath them, sibling and parent categories, and any guide covering the same subject. Where a subcategory has been created to own a specific term, its parent should link to it in body content, not only in a filter dropdown that may not be crawlable.
Individually, product pages attract small volumes of very specific, very late-stage search. Collectively — across a catalogue of thousands — they are frequently the largest untapped source of organic revenue in a store, because they are the pages least likely to have received any attention at all.
A product page has to answer the questions that stand between interest and checkout: exact specification, materials, dimensions, compatibility, care, delivery and returns. Where the description is manufacturer copy used verbatim, the page is identical to every other retailer selling the item and has nothing to distinguish it. Titles should read the way a buyer searches — the attributes people actually type, in a natural order — rather than the internal SKU naming convention.
Variants are where product SEO most often goes wrong in both directions. Give every size and colour its own indexable URL and you create dozens of near-duplicate pages competing with each other. Collapse everything to one URL and you lose the ability to rank for a specifically searched variant. The workable position is usually a parent product page as the canonical entry point, with variants exposed through structured data using ProductGroup so their differences are machine-readable, and separate URLs only where a variant has genuine independent search demand.
A temporarily out-of-stock product that has accumulated ranking and links should keep its URL, state its availability honestly, and offer alternatives or a restock notification — deleting it discards the asset. A permanently discontinued product is a different case: if a direct replacement exists, redirect to it; if the whole line is gone, let the URL return 404 or 410 and make sure the parent category absorbs the traffic. What matters is that this is a documented rule applied by the platform, not a judgement call repeated a thousand times.
Everything above concerns what a person sees. This section concerns what a machine reads. Google states that structured data can improve its understanding of ecommerce content, and that Product structured data can make eligible pages capable of richer product appearances in search.
A product page should describe itself in Product markup with its identifiers, Offer details covering price, currency and availability, and any genuine review or AggregateRating data. Where a product exists in multiple variants, ProductGroup expresses the parent-child relationship and the attributes that vary. Google's Product structured data documentation explicitly supports variants along with detailed merchant information such as pricing, availability, shipping and returns.
The feed in Merchant Center and the markup on the page describe the same products and need to agree. When they disagree — a price updated on site but stale in the feed, an item in stock on the page and out of stock in the feed — the disagreement itself becomes the problem. Getting identifiers right (GTIN, MPN, brand), keeping shipping and return information accurate, and reconciling feed data against the live page is unglamorous work that directly determines whether products appear where they could. It also sits alongside paid activity: the same clean feed serves Google Ads for ecommerce campaigns.
Beyond products, a small set of types does real work: BreadcrumbList to make the hierarchy explicit, Organization to describe the business consistently, and Review only where reviews genuinely exist on the page. Marking up content that is not present, or adding types because they might help, invites manual action rather than visibility. Less markup that is accurate beats more markup that is aspirational.
Content on an ecommerce site has one job: to reach buyers at the point where they are still researching, and to lead them to the category or product that serves them. A blog that ranks well but never sends anyone into the catalogue has not succeeded at that job.
The useful topics are the ones buyers raise before they are ready to choose: how two materials differ, how to size something, what to look for at a given budget, whether an item suits a specific occasion. These are answerable from what you already know from customer questions and support tickets, which is also what makes them hard for a competitor to replicate. I do not commit to a fixed number of posts per month — the selection comes from search demand, commercial relevance, and what the site does not already cover.
Every guide should have an obvious next step for a reader who is convinced, linking into the relevant category and to the specific products discussed with descriptive anchors. Done consistently, this also strengthens those commercial pages structurally, since they gain contextual internal links from topically related content rather than from navigation alone.
Depth on a subject you sell into is worth more than breadth across subjects you touch on. That usually means fewer, more thorough pieces, plus a willingness to prune: older posts that attract no search interest and support no commercial page are worth consolidating or removing rather than leaving to dilute the site. If you would rather learn this side yourself, I also teach it through my SEO training.
The principles do not change between platforms. What changes is how each one generates URLs, structures product data, renders templates and constrains what you are allowed to alter. Knowing those constraints is the difference between a recommendation that can be implemented and one that sits in a document.
Shopify's structure creates specific, recognisable situations: products reachable both at a canonical path and within collection paths, collection filtering and sorting that generates parameter URLs, and template control that runs through Liquid rather than free-form markup. Metafields are often the practical route to richer structured data. Themes and apps matter more than they should — a stack of apps injecting scripts is one of the more common performance problems I see on otherwise well-run Shopify stores.
WooCommerce inherits WordPress's flexibility and its failure modes. Product categories, tags and attributes each generate archive URLs, and left at defaults they produce large numbers of thin pages that overlap one another. Multiple plugins frequently output conflicting or duplicated structured data. The upside is that almost everything is changeable — permalinks, templates, canonicals and markup — provided the decisions are made deliberately rather than accumulated plugin by plugin.
On a custom build — Laravel, or a bespoke stack — nothing is provided and nothing is in the way. Sitemaps, canonical logic, breadcrumbs, pagination and structured data all have to be implemented, which means they can be implemented correctly. The recurring risk is rendering: if key content or links only appear after client-side JavaScript runs, discovery becomes unreliable, and server-side rendering for crawlable content is the safer default. I work in Laravel myself, so these recommendations tend to arrive as something a developer can act on.
| Platform | Key SEO considerations | Typical ecommerce issues |
|---|---|---|
| Shopify | Collection and product URL paths, Liquid templates, metafields, app load | Parameter URLs from filters and sorting; duplicate product paths; app-driven slowdown |
| WooCommerce | Permalink structure, category and attribute archives, plugin-generated schema | Thin overlapping archives; conflicting structured data from multiple plugins |
| Magento | Layered navigation, store views, URL rewrites | Large volumes of filter URLs; duplication across store views |
| OpenCart | SEO URL settings, category paths, multi-store | Same product served at several paths; default parameter handling |
| Custom | Rendering strategy, canonical logic, sitemap generation, structured data | Client-side rendering blocking discovery; missing pagination and canonical rules |
A large share of the Indian D2C brands I work with sell into the United States, United Kingdom, Canada and Australia. Selling across borders creates a structural question before it creates a marketing one: how many versions of each page exist, and how does Google know which is for whom?
The first decision is whether you genuinely need separate URLs per market. If the catalogue, currency, pricing and shipping terms differ materially, separate country versions with reciprocal hreflang annotations are appropriate — every version pointing at every other, including itself, with a sensible fallback. If the only difference is a displayed currency, duplicating the entire site usually creates more duplication risk than targeting benefit. Getting this wrong is expensive: incorrect or one-directional hreflang tends to leave the wrong version ranking in each market, which reads to a customer as a broken store.
Search vocabulary is not consistent across markets, so category naming and keyword mapping have to be redone per market rather than translated. Availability and pricing differ by region and must be reflected accurately in both structured data and the Merchant Center feed for that country — mismatches here surface directly as product disapprovals. Where the same garment sells under different terminology in Ahmedabad and in New Jersey, the category structure needs to accommodate both without creating two competing pages in one market.
Rankings are a leading indicator, not a result. The chain that matters runs from visibility to qualified traffic to transactions to revenue, and a report that stops at the first link cannot tell you whether the investment is working.
Search Console is the primary source here: impressions and clicks by query and by page, average position, click-through rate, and index coverage over time. The split worth watching closely is brand versus non-brand — brand traffic largely reflects demand you created elsewhere, while non-brand growth is what SEO is actually accountable for.
Aggregate traffic hides what matters in a catalogue. Reporting should break performance down by page type — how many product pages receive organic traffic at all, which categories are growing, which have plateaued — and pair that with landing-page conversion rate. A category gaining traffic while converting worse than before is a different problem from one simply not gaining traffic.
In GA4 the organic channel should be reported on transactions, revenue, conversion rate and average order value — the same terms every other channel is judged on. That is also what makes the comparison against paid acquisition honest, and what turns an SEO conversation into a budget conversation. Where paid social is part of the mix, Meta ads for ecommerce should be measured on the same basis.
Four engagements, described as specifically as client confidentiality allows. These are individual project outcomes from particular starting points, not averages and not what you should expect — timeline and scale depend on domain history, platform, existing authority and competition.
Saree D2C · Surat · Shopify
₹0 → ₹4.2L
Monthly organic revenue · 9 months
A new store with no organic presence. The catalogue was live but categories were named internally rather than the way customers search.
Fashion ecommerce · India · WooCommerce
340%
Organic traffic growth · 14 months
An established store whose filter URLs had flooded the index, leaving genuine category pages competing against thousands of near-duplicates.
Electronics · India · Custom platform
62%
Reduction in paid ad spend · 12 months
A large catalogue almost entirely dependent on Google Shopping, with product pages that had never been optimised.
Beauty D2C · UK · Shopify · White-label
£850/mo
Agency retainer · delivered under their brand
A UK agency without in-house ecommerce SEO capability outsourced delivery for a Shopify client while retaining the relationship.
Platforms worked on include Shopify, WooCommerce, Magento, OpenCart and custom Laravel builds, across the Indian market and export-focused D2C brands selling into the UK, US, Canada and Australia. I also work locally as an SEO expert in Surat.
Every engagement begins with an audit, because recommending work before understanding the site is guesswork. What follows depends on what the audit finds.
Stage one
A full crawl of the site alongside Search Console and GA4 data, examining how URLs are generated, what is indexed against what should be, how categories and products are structured, what product data exists, and where competitors currently hold the commercial terms. The output is a written diagnosis of what is limiting organic performance, ordered by impact.
Stage two
A keyword-to-page map covering the commercially relevant terms, together with a sequenced plan separating what must be fixed before anything else can work from what will compound later. Each item states what needs doing, who does it, and what it should affect — so that items can be dropped on cost grounds with the trade-off understood.
Stage three
Technical fixes specified for your developers or implemented directly where I have access, on-page work across category and product templates, structured data, internal linking, and content produced against the plan. Reporting on the measures in the previous section, with the roadmap revised as real query data arrives.
Pricing depends on catalogue size, platform, how much implementation sits with me rather than your team, and how many markets are involved. As a starting reference:
| Engagement | Indicative fee | Typically suits |
|---|---|---|
| Focused | From ₹22,000 / month | Smaller catalogues, single market, your team implements |
| Standard | From ₹40,000 / month | Established stores, ongoing technical and content work |
| Extended | From ₹70,000 / month · from USD $950 | Large catalogues, multiple markets, white-label or agency delivery |
Standalone audits are quoted separately. Figures are indicative starting points, not a quotation.
Ecommerce SEO is not the right first investment for every store. It compounds slowly and rewards sites that already have something to build on. It tends to fit these situations:
Product-market fit established and paid acquisition working, but no organic base — so every additional sale costs the same as the last.
Years of trading, reasonable brand traffic, and non-brand organic that has stopped growing without an obvious cause.
Thousands of products where most receive no organic traffic — usually the largest and most tractable opportunity of any of these.
Selling into multiple countries, where country targeting and market-specific keyword mapping are as important as anything on-page.
Where rising acquisition cost is compressing margin and there is no channel that keeps working when spend pauses.
Agencies with strong client relationships but no in-house ecommerce SEO capability, delivered white-label under their brand.
Send me your store URL and the markets you sell into. I will look at how your catalogue is indexed and structured, and tell you what is limiting organic revenue — including if the answer is that SEO is not your best next investment.