The short answer
WooCommerce SEO is the work of making a WordPress store fast, crawlable and worth ranking. The two problems specific to the platform are server performance as the catalogue grows and the volume of indexable URLs the plugins create. AR Digital Solutions fixes both, and hosts the stores too.
What we work on
A crawl and an index count.
How many URLs exist against how many products.
Speed at the server.
Hosting, PHP version, workers and object caching, before plugins.
URL and taxonomy cleanup.
Categories, tags, attributes and filters sorted into keep, noindex and stop linking.
Category page content.
The pages carrying demand, empty above the grid.
Product page work.
Titles, descriptions people read, valid schema.
Reporting on revenue.
Sessions and rankings sit beneath it.
The two problems specific to WooCommerce
General eCommerce issues are covered on eCommerce SEO. These two belong to WooCommerce.
One: speed, and why another caching plugin won't fix it
WooCommerce is WordPress underneath. Every product is a post, and every price, SKU, stock level and attribute is a meta row. Each variation is another post. A 500 product store with three variants each isn't 500 records, it's tens of thousands, and every category page, filter and admin search queries across them.
On shared hosting with two PHP workers and no object cache, the admin products screen takes ten seconds, the orders page times out during a sale, and the homepage tests fine while category and checkout pages drag.
The usual response is another caching plugin. It doesn't help, because the slow pages can't be cached. Cart, checkout, account and any filtered category are built per user, so a full page cache makes the homepage quick in a testing tool and changes nothing a customer feels.
Fix it in order. Hosting first: enough PHP workers, a current PHP version, object caching. Then the database, carrying expired transients, revisions and orphaned meta from products deleted in 2021. Then images, at the size the template displays. Then the plugins loading page builder assets onto every page. Caching last.
Server location matters more here than on a brochure site. Every uncacheable request is a round trip, so a server in Texas makes an Australian customer pay that latency at every checkout step, and a CDN can't help because those responses can't be cached. Our hosting sits in a Sydney data centre, and on a busy store the difference is measurable. See web hosting.
Two: the URL and taxonomy mess
WooCommerce generates more indexable URLs than owners realise: categories, subcategories, product tags, attribute archives, the shop page, sort orders, layered navigation filters, internal search and add to cart links. A 400 product store routinely carries tens of thousands of crawlable URLs, so crawling goes on ?orderby=price and colour filter combinations while your category pages get visited less.
Diagnose it in order. Crawl the site and compare crawlable URLs against product count. Then read the Pages report in Search Console, where "Crawled, currently not indexed" fills with parameter URLs. Then sort the URL types into three groups.
Keep the top level categories, the subcategories matching how people search, and product pages. Keep single filter combinations with real demand behind them, like waterproof work boots, and give those a clean URL, copy and an internal link.
Noindex the sort orders, multi filter combinations, internal search, cart, checkout, account pages, product tag archives you've never written for, and attribute archives unless you built them deliberately. Leave pagination alone: page two keeps a self referencing canonical and stays indexable, because noindexing it cuts the crawl path to deeper products.
Use meta robots noindex rather than a robots.txt disallow, because a blocked URL can still be indexed and Google can't read a noindex it isn't allowed to fetch. Canonicals won't fix filters either, being only a hint. Stop putting crawlable filter links in the navigation and the problem shrinks at source.
Slow admin means a slower front end for customers.
How a store project runs
Crawl, benchmark and count
URLs, index status, speed on real pages rather than the homepage, and where revenue comes from.
Fix the foundations
Hosting, database, images and URL rules, before anything gets published.
Build the category layer
Copy, structure and internal links on the pages with demand.
Measure and extend
Revenue by landing page, then the next tier.
Who this suits, and who it doesn't
It works for stores past a few hundred products that have started dragging, stores stuck on shared hosting, and stores whose category pages have never had a word written on them.
It's a poor fit if you sell three products and need brand awareness, or if the store is so customised nobody knows what the last developer did. We'll still look, though the answer is sometimes a rebuild. That's WordPress website design.
For the rest of the platform, see WordPress SEO.
Why stores stay with us
We build WooCommerce, not just report on it.
Developers in house, so a filter logic change gets built, not emailed to you.
We host it too.
Australian hosting, Sydney data centre. A server side fix has nobody else to argue with.
No lock in contracts.
Month to month, and the site, hosting and data stay yours.
"Our last agency said the site was fine and just needed content."
Sometimes true. Usually it means nobody looked at the server. Ask for the crawl and the URL count.