Woocommerce SEO agency

WooCommerce SEO from the permalink bases up: attribute archives that earn a page, filter URLs kept out of the index, category queries cached.

WooCommerce gives you more control over URLs, templates and markup than a hosted platform does, and the same freedom is what causes most of the SEO problems we find. The permalink bases can be changed, so they often have been, without redirects. Attributes can become archives, so every attribute has. Plugins can add structured data, so three of them do, each describing the product differently.

The things that move the number on WooCommerce are usually structural. Deciding which attribute archives deserve to exist, because a shopper searching for a size within a category is a real page while every possible combination is not. Keeping tag archives and filter query strings out of the index so crawling is spent on pages that can rank. Getting category pages to load quickly when they run product queries against a large catalogue and no cache.

WordPress and WooCommerce already output more than most stores realise, including product structured data, so a lot of the work is removing duplication rather than adding tools. We work with your host and your existing plugin set, and we remove before we add.

Native on WooCommerce

Permalink settings for the product base and the product category base
WooCommerce's own product structured data, output without any plugin
Global product attributes that exist as real taxonomies with their own archives
WordPress core sitemaps, which many stores duplicate with a plugin
Object caching and transients for the queries behind category pages
Template hierarchy, so category and product layouts can be changed without a page builder

Settings that matter

Set the permalink bases once and redirect the old ones

The product and category bases are editable, and changing them rewrites every URL on the store. That is fine as a deliberate one-time decision with redirects in place, and expensive as a Tuesday afternoon experiment. We decide the structure, apply it, map the old paths to the new ones, and then leave it alone. If the current structure is workable, the honest answer is usually to keep it.

Promote only the attribute archives people search for

Because attributes are taxonomies, WooCommerce can produce an archive for every colour, size and material in the catalogue. A handful of those match real searches, such as a material within a category. The rest are thin pages competing with your category pages. We choose the ones worth building, give them content and internal links, and stop the others from being indexed while keeping them usable as filters.

Keep filter and sort URLs out of the index

Layered filtering, sorting and pagination generate query string URLs by the thousand on a large catalogue. Crawlers work through them instead of your real pages, and near-identical content dilutes what you want ranked. We handle them consistently: canonical tags pointing at the clean page, parameters excluded where the platform allows, and internal links that never point at a filtered state.

Cache the category queries before blaming the host

A slow WooCommerce category page is usually running an uncached product query with several joins, not sitting on a slow server. We check whether object caching and page caching are actually active for logged-out visitors, whether the cart fragments script is loading on pages with no cart, and how many products a category loads at once. Those three account for most WooCommerce speed complaints that get diagnosed as hosting.

What we avoid

Adding a plugin that outputs product structured data on top of the markup WooCommerce already produces
Rendering category and product templates through a page builder, which adds weight to the pages that need to be fastest
Deleting discontinued products without a redirect, which throws away the links and rankings they held

Questions

Yes, unlike some hosted platforms. The product base is a setting, and it can be shortened or removed. Whether you should is a different question: the gain is small, and the risk is a full site of changed URLs. If the store is new, choose the structure now. If it has history and rankings, the redirect work usually outweighs the benefit.

You need something for titles, descriptions and control over what is indexed, and one plugin doing that is plenty. What causes problems is running two, or running one that duplicates WooCommerce's own structured data. We audit what each one is actually emitting on a product page and keep a single source for each output.

Usually because variations are being exposed as separate URLs, or because attribute archives are producing pages that describe the same product. A variable product should be one page with the variations selectable on it. If a specific variation genuinely has its own demand, it can justify its own page, but that should be a decision rather than a side effect of the setup.

Less than most people assume. Hosting matters when the server is slow to respond at all, and that is worth measuring first. After that, the usual causes are uncached queries, too many plugins loading on every page, images uploaded at full camera size, and scripts that run everywhere for the benefit of one page. We measure before recommending a move, because migrating a slow site produces a slightly faster slow site.

Send your WooCommerce store.

The plan is written for your store on the platform it runs on.