WooCommerce SEO
agency.

Parameters, archives and the URLs nobody meant to create

WooCommerce is a plugin running on top of WordPress, so a store inherits everything WordPress publishes by default as well as everything WooCommerce adds. Product tags each get an archive page. Attributes can be given public archives. Sorting a category adds ?orderby= to the URL, filter widgets add their own parameters, and “Add to cart” buttons are often plain links with ?add-to-cart= and a product ID. Crawlers follow all of it. On a store with a few thousand products, we regularly find many times more crawlable URLs than real pages, most of them thin, duplicated or uncacheable.

The cleanup is methodical. Tag and attribute archives that have no search demand get noindexed or removed and their links pulled from templates. Cart and sort parameters are kept out of the crawl with robots rules and, where the theme allows, by making those actions buttons rather than links. Filtered views that do match real searches, such as a material or size people actually type into Google, get turned into proper category or landing pages with their own copy. Pagination stays crawlable with plain links, because hiding page two often hides the products listed on it.

One SEO plugin, configured properly

Yoast SEO and Rank Math are both capable, and either is fine. The problems start when a store runs one of them alongside a separate schema plugin, a theme with its own SEO settings and a page builder that outputs its own meta tags. The result is two canonicals, three product schema blocks and titles that change depending on which plugin loaded last. We pick one source of truth, switch the duplicates off, and check the rendered HTML rather than the settings screen, because what matters is what Google actually receives.

Variable products need the same scrutiny. By default, a WooCommerce variable product lives on one URL and the size or color is chosen on the page, which is right for most catalogs. Where a variation is searched for on its own, such as a specific capacity or finish, it can be worth splitting it into a separate product with its own copy and reviews. Out-of-stock and discontinued products are handled case by case: keep the page with alternatives if it still earns traffic, or redirect it to its closest replacement rather than letting it return an error.

Speed starts with hosting

No front-end tuning fixes a slow server. Cheap shared hosting that handled a small catalog often struggles once the database grows with orders, sessions and plugin data. We look at server response times, database bloat such as oversized autoloaded options, object caching and full-page caching, then make sure cart, checkout and account pages are excluded from the cache so customers never see someone else’s basket. After that, the usual front-end work: fewer plugins loading assets sitewide, properly sized images and fonts that do not block rendering. We cover the wider technical requirements for AI search at the same time, since assistants rely on fast, cleanly rendered pages too.