Ecommerce SEO services for catalogs too big for a blog strategy.

What ecommerce SEO covers on a large catalog#

On a big catalog, SEO services for ecommerce are mostly plumbing. Category and product pages carry the revenue, and they break where a content calendar never looks: facets, canonicals, templates, internal links, structured data, speed and the crawlers behind AI answers.

Large catalogs break in eight predictable places. Each row names the fix and the Google document behind it, because "experts agree" isn't a source.

Check our homework: view source, and our structured data is right there.

Technical SEO for large and enterprise catalogs#

Big stores lose crawl to URLs nobody meant to publish. Google's crawl budget guide is written for sites with "1 million+ unique pages" changing weekly, 10,000+ pages changing daily, or "a large portion" of URLs stuck in "Discovered - currently not indexed". Faceted navigation gets a catalog there fast: Google's faceted navigation guide says crawlers "will typically access a very large number of faceted navigation URLs", leaving "less time to spend on new, useful URLs".

Our technical SEO services start there, because SEO for large ecommerce sites comes down to giving every URL one job:

• Facets and parameters. Filters buyers search for get clean, indexable URLs. The rest get a robots.txt disallow or move into URL fragments. Google calls canonical tags and nofollow "generally less effective in the long term" for this. Filter URLs already indexed get noindex first, and the robots.txt block once they drop out.
• Block or noindex, never both. A noindex page "must not be blocked by a robots.txt file" (Google), and robots.txt is no canonicalization tool either.
• Pagination. Each page gets its own URL and canonical. Google: "Don't use the first page of a paginated sequence as the canonical page" (pagination guide).
• XML sitemaps by type. Products, categories and content in separate files under one index, within Google's per-file limit of 50,000 URLs or 50MB uncompressed.
• Log files. We verify Googlebot against Google's published IP ranges, with reverse DNS for spot checks, because "spammers or other troublemakers" claim to be Google too.
• Release gates. Each fix gets a test that runs on every deploy, and on the live site on a schedule, to catch changes made outside a deploy. On Magento, the SEO settings get locked into app/etc/config.php, which makes them read-only in the Admin.

That last gate is the part enterprise ecommerce SEO can't skip.

How we optimize category and product pages#

Category pages carry the head searches, so they need more than a product grid. We write category copy that answers what buyers compare (sizes, materials, compatibility, standards) and place it where it helps the decision, not in a wall of text below the grid.

Product pages get Product markup with a nested Offer. Merchant listings require a name, an image and an offer, with "a price greater than zero". Google says markup plus a Merchant Center feed "maximizes your eligibility" (Product structured data), so we keep the two in sync.

• Variants. Our default is one canonical page per product group, marked up with ProductGroup, productGroupID, variesBy and hasVariant, a unique sku or gtin per variant, and a distinct URL that preselects each variant, as Google's variant guide requires.
• Out of stock. Coming back: the page stays live, marked OutOfStock or BackOrder. Gone for good: a 301 to a true replacement, or a 404 or 410. Google's crawl budget guide is direct: "Return a 404 or 410 status code for permanently removed pages." A part number buyers still search stays live as Discontinued, with its successor linked. Never a blanket redirect to the home page, which Google's site-move guide says "might be treated as a soft 404".

Platform SEO#

No platform is best for SEO out of the box. Each ships defaults that hold on a small catalog and break somewhere specific on a big one. When the platform itself is the problem, that's ecommerce development work. When it isn't, here's where each one needs help.

Magento SEO#

Magento is home, and its core Catalog config sets both canonical settings to 0; Adobe recommends enabling both. Core marks its layered-navigation links nofollow; for links within your own site, Google says to use robots.txt. A default 2.4.6 or later store gives each product one address; stores set up earlier, or with category paths switched on, can answer at several. In HTTP Archive's September 2026 field data, 66% of Hyvä stores pass Core Web Vitals on mobile, against 45% of all Magento stores. The server side is our Core Web Vitals and speed work.

Shopify SEO#

Shopify fixes the URL shape: "You can't edit subdirectory names," says its help center. Products live at /products/:handle, collections under /collections/, and a collection-scoped product URL serves "the same content on separate URLs" (Shopify). Its default robots.txt already blocks sorted collections, tag combinations and multi-filter URLs, leaving single-filter URLs to decide. Apps are the other drag: Shopify warns that "uninstalling an app doesn't automatically remove its code from your theme." A Shopify SEO agency earns its keep in the theme code, which is where our Shopify development work starts.

BigCommerce SEO#

BigCommerce does part of the facet work for you. Every store's robots.txt disallows listings with product filters applied (_bc_fsnf=1). A rule set for "known high-volume and AI crawlers" adds Crawl-delay: 10, and you can't view or edit it in the store settings. Google ignores crawl-delay, but a crawler that honors it fetches at most 8,640 pages a day, so any BigCommerce SEO agency should read the live file first.

WooCommerce SEO#

WooCommerce grows taxonomy pages quietly. Product tags get landing pages, and a global attribute with "Enable archives" on gets an archive for every term, like /color/black/ in WooCommerce's own example. The classic layered-nav widget builds filter_ and query_type_ URLs and marks each link rel="nofollow", which Google says works only when "every anchor" to a URL carries it. We decide which archives earn an index.

Headless storefronts#

A headless front end, Next.js or otherwise, owns rendering, canonicals, sitemaps and redirects, so SEO moves into code. Google's JavaScript SEO guide says a page waiting to render "may stay on this queue for a few seconds, but it can take longer than that", and warns against changing a canonical with JavaScript. So canonicals, prices and Product markup go in the server HTML, and preview hosts stay unindexed. It's the same checklist behind our headless commerce development work.

AI search: Google AI Overviews, ChatGPT and llms.txt#

Here's the line most AI SEO pitches leave out. Google Search Central's AI features guide says: "You don't need to create new machine readable files, AI text files, or markup to appear in these features." A page has to be "indexed and eligible to be shown in Google Search with a snippet", so the work for AI Overviews and AI Mode is the SEO above, done thoroughly, plus three checks:

• Crawl access. Google's list includes crawling "allowed in robots.txt, and by any CDN or hosting infrastructure". AI Overviews and AI Mode draw on the Search index, which Googlebot crawls. ChatGPT search uses OAI-SearchBot, and OpenAI says "Sites that are opted out of OAI-SearchBot will not be shown in ChatGPT search answers, though can still appear as navigational links." Training is a separate call. GPTBot covers OpenAI's model training; Google-Extended, a robots.txt token, covers Gemini training and grounding in Gemini Apps, and it "does not impact a site's inclusion in Google Search".
• Markup that matches the page. Google asks that structured data "matches the visible text on the page".
• Measurement with a stated method. Search Console folds AI feature traffic into the "Web" search type, so we track a fixed set of buyer questions in AI Mode and ChatGPT search and log every URL they cite.

And llms.txt? It's a proposal, not a standard, and Google's AI features don't need it. We publish our own llms.txt anyway, generated from the same frontmatter as the pages it lists.

SEO for replatforms and migrations#

Replatforms lose organic revenue when old URLs stop resolving. Google's site-move guide says to "map your old site's URLs to the URLs for the new site", serve server-side permanent redirects, keep them "for as long as possible, generally at least 1 year", and warns: "Expect temporary fluctuation in site ranking during the move." Our method: a full redirect map, every old URL crawled on launch day and diffed against it, and Search Console watched for new 404s.

Our receipt for this method: tens of thousands of redirects mapped for a zero-downtime replatform.

The rest is on our ecommerce migration page.

B2B ecommerce SEO#

B2B buyers search by part number, spec and standard, so B2B ecommerce SEO starts with spec-led category pages: the attributes buyers filter by, as crawlable text, and on each product page your part number, the manufacturer's and known cross-references. Spec tables go in the product page's HTML, not only in PDF datasheets: a PDF is a separate document, without the page's price, markup or cart.

Gated pricing works; gated products don't. Google's merchant listings need a page that isn't blocked by "login requirements", with a price above zero, so log-in-for-price products won't get them. Keep product pages public, gate the price, and they can still appear as ordinary results. We build the storefront side too: B2B ecommerce builds.

Analytics, tracking and ad-account rebuilds#

Yes, as project work. SEO numbers are only as good as the tracking under them, so we set up and rebuild:

• GA4 and Google Tag Manager implementations, with each conversion counted once.
• Merchant Center feeds, checked against the price and stock on the page. Google can update its copy of your product data from your site, if you turn that on.
• Conversion tracking and closed-loop attribution: click, quote, order, ERP, ad platform.
• Ad accounts, set up or rebuilt on that clean data.
• Conversion-rate work, measured against a control.

What we don't do is ongoing campaign management. We rebuild the account, document it and hand it back to whoever runs it.

What our SEO audit covers#

An audit is a project with a written deliverable, yours whether or not you hire us for the fixes. Hire us as an ecommerce SEO consultant for the audit alone, or to ship the fixes after it. It covers:

• A crawl of every template type, raw HTML and rendered.
• Search Console's page indexing statuses, traced to the URL patterns behind them.
• A log sample, with Googlebot verified against Google's published IP ranges.
• A facet and parameter map: index, block or fragment, filter by filter.
• Canonicals, redirects and sitemaps checked against the URLs you want indexed.
• Structured data checked against the visible page, template by template.
• Core Web Vitals field data for every template type.
• AI crawler access across robots.txt, CDN and WAF rules, and the logs.
• The fix list, ranked by revenue at stake and written as tickets your developers, or ours, can ship.

What drives the cost of ecommerce SEO#

We don't publish prices for our ecommerce SEO services. On a catalog the work follows templates and technical debt, not SKU count, and a number on a web page can't see either. What moves the scope:

• Catalog size and template count: how many URLs, and how many page types behind them.
• Platform constraints: what the platform lets you change without custom code.
• Technical debt: old redirects, duplicate URLs, extensions that inject their own markup.
• Content volume: how many category pages need copy.
• Who implements on your side: your developers ship the fixes, or ours do.

For what the market charges, with sources, read our ecommerce SEO pricing guide.

How to choose an ecommerce SEO agency#

Most ecommerce SEO agencies show the same deck. Four questions sort one ecommerce SEO company from the next, us included:

• Do they ship code fixes, or only reports? On a big catalog the fix lives in templates, robots.txt and the deploy pipeline. A PDF changes none of them.
• Do they show their own markup? Ask to see their structured data and their llms.txt. Ours: this page's own markup, and the llms.txt link above.
• Do they measure AI visibility with a stated method? "Trust us" isn't one.
• Do they know your platform's defaults? Magento's canonicals, Shopify's collection URLs, BigCommerce's robots rules.

Google's guide to hiring an SEO adds the rest: no one can promise a #1 ranking, and if an SEO promises first place, "find someone else." It also suggests giving a candidate read access to Search Console, not write access.