A catalog is a crawl problem
before it is a content problem.
Your filters generate URLs faster than any crawler can read them. Your variants split one product across two dozen pages that compete with each other. Google has published guidance on both since long before AI search existed, and most stores still have neither handled. Fix the architecture and the content work you do afterwards actually counts.
We work with pure-play ecommerce operators, manufacturers with parts catalogs, franchise systems selling product alongside service, medical and aesthetics practices with retail lines, and mid-market and private equity portfolio companies with a commerce arm — a hundred SKUs or a hundred thousand.
Your filters can generate more URLs than a crawler will ever read.
Google publishes specific guidance for large sites on managing crawl budget, and the reason is arithmetic: a category with eight filters, each with a handful of options, can produce hundreds of thousands of unique addresses — every one of them a page a crawler may try to fetch. That is not a hypothetical risk. It is the default behavior of nearly every commerce platform, and it is why large stores frequently have products that have simply never been discovered.
This is one of the best-documented problems in search, which is what makes its persistence remarkable. Google has published guidance on faceted navigation for over a decade, maintains an entire ecommerce documentation section, and covers duplicate URL consolidation in detail. None of this is secret. It is simply invisible from the front end, so nobody looks until a content program has already underperformed.
The sequencing matters more than any single fix. Content written for a page a crawler rarely reaches is content nobody will see. Authority split across two dozen variant URLs is authority no single page holds. Both problems are architectural, both are solvable in weeks rather than quarters, and both make everything done afterwards work harder. Starting with keyword research on a catalog in this condition is the most common way ecommerce SEO budgets are wasted.
Not every store is at risk to the same degree, and we will tell you where you sit. A hundred-product catalog with simple variants rarely has a crawl problem worth solving; its constraint is almost always product content and category relevance. A fifty-thousand-SKU catalog with faceted filtering usually has nothing but crawl problems. Diagnosing which you are takes days and determines the whole plan — the same principle behind our technical SEO practice.
The AI shift has raised the stakes without changing the work. Assistants increasingly summarize product options before a shopper reaches any store, and they assemble those summaries from pages and structured data they can read and reconcile. A catalog that contradicts itself across variants, or whose product pages carry the same manufacturer copy as every competitor, gives them nothing to cite you for. The remedy is the same architecture and content work that has always mattered — it simply pays in two places now. Our method is on the AI SEO agency page, and the answer layer under answer engine optimization.
One product in twenty-four pages, or one page holding twenty-four variants.
This is the most common structural defect in ecommerce catalogs and the one with the clearest fix. A product in six sizes and four colors becomes two dozen near-identical URLs, each holding a fraction of the authority the product should have, each competing with the others for the same queries.
Every variant its own page
- Two dozen URLs for one product, generated automatically by the platform because that is the default.
- Near-identical content across all of them, differing only in a size or color value.
- Authority divided, so no single page is strong enough to rank for the product itself.
- Links and reviews scattered across whichever variant a customer happened to land on.
- Crawl budget consumed re-reading twenty-four versions of the same thing.
One page, variants inside it
- A single canonical product page with variants selectable rather than separately addressed.
- All content, links and reviews on one URL, so the page is genuinely as strong as the product.
- Variant detail still available to shoppers and to feeds, without fragmenting the page.
- Exceptions made deliberately where shoppers really do search for a specific variant.
- Crawl effort spent on products rather than on permutations of one.
Four things we do that most ecommerce SEO agencies will not.
Each of these is slower to start, produces no reportable movement in month one, and is the reason the content work afterwards is worth paying for.
Keyword research on a catalog with unresolved facets and split variants produces a plan for pages that cannot compete. We map what is genuinely crawlable and indexable first, then decide what to write — which occasionally means telling a partner their content budget is premature.
It is the least popular thing we say in a first meeting and the reason our ecommerce work compounds instead of plateauing at month six.
- Crawl and index reality established before any content plan is written.
- Facet handling decided per category rather than applied as a blanket rule.
Consolidating everything is as wrong as splitting everything. Some variants are effectively separate products that people search for by name; most are not. The distinction is visible in search data and invisible in a platform setting.
We make the call per product family and document why, so a later developer does not undo it because the reasoning was never written down.
- Variant strategy set from actual query data per family, then implemented consistently.
- Canonical signals and internal linking aligned so the decision actually holds.
Nobody rewrites four thousand product pages. So the question is which hundred, and the usual answer — highest search volume — is frequently wrong. A high-traffic product you barely earn on is a poor place to spend a writing budget.
We ask for contribution by product line first, and where a partner cannot supply it we say plainly that we are prioritizing on a proxy until they can.
- A ranked content list built from margin and demand together, not volume alone.
- Writing handled by our content team against that list.
A product page has to help somebody choose between three options and be structured enough for a shopping surface or an assistant to represent accurately. Those goals mostly agree — clear specifications, honest limitations, questions answered on the page.
Where they conflict the shopper wins, because a page optimized for machines that nobody buys from has solved the wrong problem entirely.
- Structured data reflecting the visible page rather than a parallel dataset.
- Specifications marked up properly so they survive being summarized elsewhere.
Reachable in theory is not reachable.
Category structure decides which products can rank at all. Depth is not a neutral organizational choice — every additional step between the homepage and a product reduces the likelihood that crawlers reach it often, and that shoppers reach it ever.
Why depth is a decision rather than an accident
Most category trees were not designed. They grew — a merchandising decision here, a supplier taxonomy there, a seasonal collection that became permanent. The result is a structure that mirrors how the business thinks about its products rather than how customers search for them, with some branches three steps deep and others seven.
The products in those deep branches are the ones nobody can explain. They exist, they are in stock, they have perfectly reasonable pages, and they receive no traffic. Not because they are uncompetitive but because almost nothing links to them and crawlers reach them rarely. The fix is structural rather than editorial, and it frequently produces movement on products that have been dormant for years.
Facets interact with this badly. A category that generates filtered URLs is not just producing crawl waste — it is diluting the internal linking that should be flowing to real category and product pages. Google's faceted navigation guidance covers the crawl side; the linking side is where most of the recoverable value sits, and it is rarely discussed.
What you control here is more than most platforms suggest. Which facets generate crawlable URLs, which are rendered in the browser, what the robots file permits, where canonical signals point, and how internal navigation distributes authority are all decisions rather than platform defaults — even on hosted platforms that appear to remove the choice. Making them deliberately is most of what separates a catalog that grows from one that stalls.
- Depth per branch — measured, not assumed even across a category
- Facets that generate URLs — decided per category, not globally
- Canonical signals — pointing where the decision says they should
- Internal linking — distributing authority to what should rank
- Pagination — handled so deep pages remain reachable
- Orphan products — found, because nothing else will surface them
Crawl, then structure, then write where it pays.
The order is the method. Content produced before the architecture is settled has to be produced again, and that is the most common way an ecommerce SEO budget disappears without result.
Crawl reality
- Full crawl against the actual catalog, not a sample of it
- Facet-generated URLs quantified and their crawl cost established
- Variant handling audited product family by product family
- Orphan and deeply buried products identified
Fix the structure
- Facet handling decided per category and implemented consistently
- Variants consolidated or split deliberately, with the reasoning recorded
- Category depth corrected and internal linking redistributed
- Structured data aligned so markup and page agree
Content where it pays
- Products ranked by margin and demand together, not volume alone
- Category and product content written against that ranking
- Specifications structured so they survive being summarized elsewhere
- Progress reported per product group rather than as a site average
What an ecommerce SEO program covers
Architecture underneath, content on top, both reported against products rather than site averages. These are the pieces, and each is a practice you can read about and hold us to.
Crawl and index management
Facet handling, robots directives, pagination and orphan discovery — the work that decides whether a crawler ever reaches the pages you want ranked.
Runs with: technical SEO
Variant and duplicate strategy
Consolidation or separation decided per product family from real search behavior, then implemented with canonical signals and linking that hold.
Runs with: catalog management
Category architecture
Depth, taxonomy and internal linking rebuilt around how customers search rather than how the business files things internally.
Runs with: site structure and store design
Product and category content
Written for the items carrying margin — what the product is for, who it suits, where it falls short — replacing supplier copy that every competitor also has.
Runs with: content writing and content strategy
Structured data across the catalog
Product markup that reflects the visible page, deployed at catalog scale so machine-readable facts and human-readable facts never disagree.
Runs with: Shopping and feed work
AI visibility for products
The same clean architecture and honest product detail that earns rankings is what lets an assistant represent your products accurately rather than skipping them.
Runs with: AI SEO and generative engine optimization
A hundred SKUs or a hundred thousand, the diagnosis comes first.
Catalog size changes which problem you have, not whether the method applies. Small catalogs rarely have crawl problems; large ones rarely have anything else.
We will tell you your content budget is premature.
Most ecommerce SEO proposals open with keyword research and a content calendar, because those are visible and easy to price. On a catalog with unresolved facets and split variants, that plan produces content for pages that cannot compete. We map crawl and index reality first and occasionally have to say the writing should wait — which is not what anybody wants to hear in a first meeting.
The rest follows from the same principle. We decide variant strategy per product family from real search data rather than applying a blanket setting. We ask for margin before recommending what to write, because the highest-traffic product is frequently not the one worth a writing budget. And we built Allegiant as an AI-first agency rather than a traditional shop with AI added on — which in a catalog means treating structured product data as the visibility strategy rather than as technical housekeeping.
Ecommerce SEO runs alongside the wider ecommerce program, paid media and the full digital plan. See the work in our case studies.
Six elements that earn a ranking. One that is usually still the supplier's.
Every element below is free to get right and cheap to get wrong. The last row is the one nearly every catalog leaves untouched, and the one that decides whether there is any reason to prefer your listing.
| Element | How most catalogs handle it | Allegiant How we handle it |
|---|---|---|
| Product title | The manufacturer's SKU string | Written to match how people actually search for the item |
| Specifications | A block of unstructured text | Structured so machines can read them and shoppers can scan them |
| Images | Filenames from the supplier | Named and described so they carry meaning rather than a part number |
| Reviews | Loaded by a script after the page | Present in the page and marked up according to published guidance |
| Questions answered | Left to a support ticket | Answered on the page, which reduces returns as much as it lifts orders |
| Description | Manufacturer copy, unchanged | Written for the product — the one element every competitor also has |
Take the last row to your own catalog this afternoon. Search a distinctive sentence from one of your product descriptions in quotes. However many other stores come back is how many competitors are running the identical page.
Four ecommerce SEO line items you can stop paying for.
Each is common, each bills reliably, and each is worth very little on a catalog whose architecture has not been settled.
Keyword research delivered before a crawl. A plan built without knowing which pages are reachable and indexable is a plan for pages that may not compete. It is the most professional-looking deliverable in ecommerce SEO and frequently the least useful thing to receive first.
Bulk-generated product descriptions. Four thousand thin pages produced automatically give a search engine no reason to prefer any of them and give a shopper nothing to decide on. A hundred well-written pages covering most of your revenue beats them comfortably and is achievable this quarter.
Blanket variant policies. Consolidating everything is as wrong as splitting everything. Any agency applying one rule across a whole catalog has not looked at which variants people actually search for, and the cost of getting it wrong is products that cannot rank for their own names.
Site-average reporting. Organic traffic up eleven percent tells you nothing about a catalog. Which product groups moved, which are still invisible, and which are ranking but not converting are three different questions, and an average answers none of them.
The pattern beneath all four: on a catalog, work that scales cleanly is rarely work that changes which products get found.
- Google Search Central — Ecommerce documentation
- Google Search Central — Faceted navigation guidance
- Google Search Central — Consolidate duplicate URLs
- Google Search Central — Product structured data
- Google Search Central — Review snippet structured data
- Google Search Central — robots.txt specification
- Google Search Central — Creating helpful, reliable, people-first content
- Google Search Central — SEO starter guide
- Google Search Central — AI features and your website
- Google Merchant Center — Product data specification
- Google Search Central — Managing crawl budget for large sites
- Google Search Central — Sitemaps overview
- web.dev — Core Web Vitals
Ecommerce SEO, answered
Straight answers, including the ones that cost us work.
Why is ecommerce SEO different from ordinary SEO?
Scale turns architecture into the primary constraint. A brochure site has dozens of pages and a content problem; a catalog has thousands of pages, filters that generate thousands more, and variants that split single products across many URLs. Google maintains a dedicated ecommerce documentation section for exactly this reason. The fundamentals are identical — what changes is that getting the structure wrong wastes every hour of content work built on top of it. The general practice is on our SEO page.
Should our filters create indexable URLs?
Some should, most should not, and the decision is per category rather than global. A filter combination people genuinely search for — a size, a material, a compatibility — can deserve a crawlable page. The other several thousand combinations are crawl waste that also dilutes internal linking. Google's faceted navigation guidance covers the mechanics and the robots specification covers the controls. Getting this right is usually the single largest technical win available — handled in our technical practice.
Should each product variant have its own page?
Usually not, but not never. A product in six sizes and four colors generating two dozen near-identical URLs splits its authority so no page is strong enough to rank for the product. Where shoppers genuinely search for a specific variant, that variant deserves a page — a capacity, a finish, a size that is effectively its own product. We make the call per product family from real query data and record why, so a later developer does not undo it. Google's consolidation guidance covers implementation, and the feed side sits in catalog management.
Do we need to rewrite every product description?
No, and attempting it is how these projects stall. Start with the products carrying revenue and margin, which in most catalogs is a small fraction of the range. Supplier copy is identical across every retailer selling the item, so there is nothing to prefer and nothing to cite you for — but that only matters where the product can actually earn. Google's guidance on helpful, people-first content applies to a product page as much as an article. Our content team works from a ranked list rather than the whole catalog.
Some of our products get no traffic at all. Why?
Frequently because almost nothing links to them and crawlers reach them rarely — they are buried several steps deep in a category tree that grew rather than being designed. Those products are not uncompetitive; they are undiscovered, which is a structural problem with a structural fix. Correcting depth and redistributing internal linking often produces movement on items dormant for years. Google's starter guide covers why internal linking matters this much. Related: store structure.
How does AI search change ecommerce SEO?
It raises the cost of thin and contradictory product data without changing the remedy. Assistants summarize options before a shopper reaches any store, assembling those summaries from pages and structured data they can read and reconcile — so supplier copy and split variants give them nothing to cite you for. Google states that standard SEO practices are what qualify content for its AI features. Nobody controls what an assistant says, and we do not claim to; the honest position is on our GEO page.
What structured data should product pages carry?
Product markup that reflects what is genuinely on the page, plus review markup where reviews are present. Google documents both product structured data and review snippets. The value is not the markup itself but that machine-readable and human-readable facts agree — where they disagree you have given two answers about the same product, which is precisely what makes an item hard to represent accurately. Deployment at catalog scale is technical work.
Does site speed matter as much on a catalog?
More, because the failure is systemic rather than local. Product pages are generated from shared templates, so one unoptimized image pipeline or a heavy script degrades every product simultaneously — and on a catalog the same code path is executed thousands of times. Core Web Vitals are the published measures. The commercial argument is simpler than the technical one: a slow product page loses the shopper you already paid to attract. Store-side work sits on our ecommerce web design page.
How long does ecommerce SEO take to show results?
Architecture fixes can move quickly, because a product going from undiscovered to crawlable is a step change rather than a climb. Content and authority take longer and vary by category and competition. We will not quote a single timeline for a whole catalog — a buried product with a technical blocker and a product in a saturated category are different problems on different clocks, and any agency giving you one number for both has not looked. The audit tells us which is which, and Google's starter guide is candid about the same point. Start with the A.R.C. Report.
Our platform limits what we can change. Does that block this?
Less often than teams assume. Hosted platforms restrict some things and expose more than most merchants realize — canonical handling, robots directives, internal linking, template structure and how facets are rendered are usually all controllable even where the interface hides them. Where a genuine limit exists we say so plainly rather than billing for work the platform will not permit, and occasionally the honest answer is that a replatform is the real fix. Google's product data requirements apply regardless of platform. Related: ongoing maintenance.
Should we report organic traffic or something else?
Something else, on a catalog. Site-wide organic traffic conceals everything that matters — which product groups moved, which remain invisible, which rank but do not convert, and which are selling at a margin you would rather not grow. We report per product group and net of returns, because revenue that came back is not revenue. That is the same reconciliation standard applied across the wider ecommerce program, and it depends on the order data in your own systems rather than a platform's estimate, and on the coverage data Google exposes through sitemaps and index reporting.
What makes Allegiant different from the ecommerce SEO agency we use now?
Three things you can verify. We crawl before we plan, and we will tell you when a content budget is premature. We decide variant strategy per product family from real search data rather than applying one setting across the catalog. And we ask for margin before recommending what to write, because the highest-traffic product is often not worth the writing budget. We are also built as an AI-first agency rather than a traditional shop with AI added on. Start with the A.R.C. Report and judge us on the findings, measured against Google's own ecommerce guidance.
Find out how much of your catalog can even be found.
The A.R.C. Report covers your whole marketing position. For a catalog we crawl the real thing rather than a sample, quantify what your filters are generating, audit how variants are handled, and identify the products nothing links to. Findings are yours whether or not we work together.
- Full crawl against the actual catalog, not a representative sample
- Facet-generated URLs quantified with their crawl cost established
- Variant handling audited product family by product family
- Category depth measured per branch and orphan products identified
- Product content checked against what every competitor also publishes
- A straight answer on whether your content budget should wait
Explore the wider program: ecommerce digital marketing, ecommerce PPC, ecommerce web design, all services and the A.R.C. Report.
Tell us your platform and roughly how many products you carry, and we will show you what a crawler actually sees.
No cost, no commitment. We will follow up by email or phone to walk you through the findings.
