Woocommerce SEO: the complete guide

Decide your URL structure at the start and then leave it alone, because changing it later means redirecting every product and category on the site. This is the one decision on this platform that is genuinely expensive to reverse.

WordPress controls the general permalink format and WooCommerce adds its own settings for the product and category bases. You can put products under a simple base, nest them under the shop page, or nest them under their category. Each has trade-offs and none of them is dramatically better for ranking.

The practical advice is to keep URLs short, readable and stable. A short base plus a descriptive product slug is easy to work with and does not break when a product moves between categories. Nesting products under categories produces URLs that read nicely and creates a maintenance problem, because changing a product's category changes its address.

For categories, a short base or no base at all both work. Removing the base entirely is possible but it introduces conflicts with pages and other content types, so it is a choice to make consciously rather than because it looks tidier.

Set the general WordPress permalink format to post name rather than dates or identifiers, since dated URLs on content that is not news read badly and age.

Write the slug conventions down and enforce them. WordPress generates a slug from the title, which means a product titled with a supplier code produces a URL nobody would search for, and a long product name produces a very long slug. Trim them at creation. A slug that names the product in the words a customer would use is worth the ten seconds.

One detail that catches people: WordPress keeps the original slug when you rename a published item and creates a new one, and the old address will typically stop working unless a redirect is created. Check what your setup does before assuming it is handled, and put a redirect in whenever a slug changes.

Exclude the functional pages that WordPress and the store plugin create automatically, because several of them will otherwise be indexed and none of them should be. This is quick to do and it is a common finding on stores that have never been audited.

The obvious ones are the cart, the checkout and the customer account pages. They have no search value, they can expose parameter-laden URLs, and they sometimes appear in results, which looks careless. Mark them as excluded from indexing.

The less obvious ones come from WordPress itself. Author archives on a single-author store duplicate the blog. Date archives duplicate it again. Attachment pages create a thin page for every uploaded image, which on a store with thousands of product photos is a large number of worthless pages. Internal search result pages are generated by visitors and belong nowhere near the index. Tag archives duplicate category content unless you are using tags deliberately for real groupings.

Handle these through your SEO plugin's settings, which is the maintainable way, rather than by editing template files. The settings survive theme changes and are visible to whoever works on the site next.

Check the results rather than trusting the setting. Look at the indexed page count for the domain and compare it against the number of products, categories, pages and posts you actually have. A count several times higher than expected means something is generating pages you have not accounted for.

Also check that you are not blocking things you need. A robots file that disallows the directory holding your theme's stylesheets and scripts can prevent proper rendering. And check that the site-wide discourage search engines setting is off, since it is switched on during development and forgotten with impressive regularity.

Finally, confirm that your sitemap contains only what you want indexed. A sitemap that lists pages you have excluded sends contradictory instructions.

Treat category archives as your most important commercial pages and give them real content, because by default they are a bare grid with a title and nothing to rank with. This is where the largest available gain usually sits on a WooCommerce store.

Start with the structure. Your categories should match how people search rather than how the business files stock, which usually means creating more of them and organising them by use, material, size, compatibility or who the product is for. Subcategories should exist where a real search exists for them, not just to tidy a long list.

Then write. Each category that targets a search needs a title and description written for that search, an introduction that helps a shopper choose, and detail further down covering differences between options, what to look for, and the questions buyers ask. Most themes place the category description above the products, which is fine for a short introduction and poor for longer material, so a theme adjustment that puts a second block below the grid is usually worth making.

Pagination needs a decision. Long category archives split across many pages leave products several clicks deep. Increasing products per page reduces the depth at some cost to speed, and creating more specific subcategories is usually the better answer because it produces pages that can rank rather than just pages that exist.

Sort out how a product in several categories behaves. Depending on your URL structure this can produce more than one address for the same product, and the canonical needs to resolve to one of them.

Add internal links between related categories in the descriptions, using text that names the destination. Category-to-category linking is underused and it helps both crawling and shoppers.

Finally, do not create categories with almost nothing in them. A page listing two products for a search that expects a range will not hold a position, and it adds thin content to the domain.

Decide which attribute and filter URLs are allowed into the index, because layered navigation generates combinations faster than anything else on this platform. A store with several filterable attributes can produce a very large number of addresses that are all slight variations of one another.

Understand the mechanism first. Filtering typically appends query parameters to the archive URL, one per selected attribute, and multiple selections combine. Sorting adds more. Product attributes can also have their own archive pages if archives are enabled for them, which creates a second set of URLs describing the same products from a different angle.

The default position should be that filtered and sorted URLs are not indexed. Set them to be excluded, and make sure the canonical on a filtered view points back to the unfiltered archive so any value they accumulate is consolidated.

Then choose your exceptions deliberately. Some filtered views represent real searches, such as a particular colour, size or material within a category. For those, create a proper subcategory or a dedicated page with its own URL, its own text and its own place in the navigation, rather than trying to index a parameter URL. You end up with a page you control and can write for.

Attribute archives are worth a separate decision. Enabling them creates a page per attribute value across the whole catalogue, which occasionally serves a real search and more often creates thin duplicates. Enable them only where the attribute genuinely defines a category shoppers search for.

Watch crawl behaviour after any change. If server logs or crawl statistics show a large amount of attention going to parameter URLs, the settings are not doing what you think they are.

There is also a performance dimension. Filtered queries on a large catalogue can be expensive to generate, and a crawler working through thousands of combinations puts real load on the database. Controlling what is crawlable protects the site as well as the index.

Deal with the store-specific performance issues before general optimisation, because a WooCommerce site is slow for different reasons than a brochure site. Generic advice about images and minification helps, and it is not where the biggest problems are.

Caching is the first and largest. Full page caching makes a site fast, and store pages complicate it because cart contents and account state are personal. A poorly configured cache either serves stale personalised content or excludes far too much from caching, and the second is more common. Product and category pages should be cached for logged-out visitors, with cart, checkout and account excluded. Get this right and everything else matters less.

The store plugin's cart update mechanism is a known cost. It refreshes cart contents through a request on page loads, which on a cached site adds an uncached request to every page including ones with no cart on them. Limiting that behaviour to the pages that need it is a well-known and worthwhile fix.

Database load is the second area. Options that load on every request, accumulated scheduled tasks, expired temporary data and revision history all build up over years. A store several years old often has a database doing significant unnecessary work on every page load. Cleaning it is unglamorous and effective.

Hosting matters more here than on a hosted platform, because you chose it. Store pages cannot be entirely static, so the server has to execute code for a meaningful share of requests. Shared hosting that is fine for a blog struggles with a catalogue and a cart. Object caching and adequate resources make a visible difference.

Images come third, not first, but they still matter. WordPress generates several sizes of every upload and themes do not always request the right one, so check what is actually being served on a product page.

Measure on a product page on a mid-range phone, and watch how much the page moves while loading as well as how long it takes.

Check what structured data your site actually outputs before adding any, because on this platform several components can each add their own and the result is conflicting or duplicated markup. The store plugin outputs product data. An SEO plugin may output its own. A review plugin adds ratings. A theme may add more.

View the source of a product page and find every block of structured data on it. You are looking for how many product descriptions there are, whether the values agree with the visible page, and whether anything is describing something that is not there.

When you find duplication, resolve it by turning off all but one source rather than trying to make them agree. Most plugins have a setting for this, and the one to keep is usually whichever is most complete and most reliably updated.

Check the values themselves. Price and availability must match what a shopper sees. On variable products, decide what the markup describes, since a price range behaves differently from a single price. Availability that stays in stock on a sold-out product is a common and damaging error.

Ratings need care. Only mark up review data that is genuinely displayed on the page and genuinely from customers. Marking up aggregate ratings that are not visible, or that do not exist, creates a problem rather than an advantage.

Add breadcrumb markup if it is missing, since it helps express a hierarchy, and add organisation details on the home page covering the store name, logo and contact information.

Validate with a testing tool after any change, and re-check after plugin updates. On a platform where components update independently and frequently, markup that was correct last month can silently change. Building a quarterly check into your routine catches it.

One rule holds throughout: the markup describes the page. If the two disagree, fix the markup or fix the page, but do not leave them apart.

Treat every plugin as an ongoing cost rather than a one-time addition, because a WooCommerce site's problems usually trace back to the number of independent things running on it. Each one loads code, updates on its own schedule, and can conflict with another.

Start with an inventory: what is installed, what it does, who asked for it, and whether it is still used. Most stores find several plugins that solved a problem that no longer exists. Removing them is the cheapest performance and stability work available.

Then look for overlap. Two plugins doing sitemaps. Two adding structured data. Two handling redirects. Two adding image optimisation. Overlapping functionality creates contradictions that are hard to diagnose because each component behaves correctly on its own.

Be deliberate about what loads where. Many plugins load their code on every page whether or not it is needed, and there are ways to limit that by page type. This is developer work and it makes a measurable difference on a store with a long plugin list.

Update on a schedule, with a staging copy to test on. On this platform an update can change output, break a template or conflict with something else, and finding that out on the live store during a busy week is avoidable. A staging site that mirrors production is not optional for a store of any size.

Keep the theme in the same discipline. A heavy multi-purpose theme with a page builder adds weight to every page and often duplicates functionality you also have in plugins. Changing a theme is a large project, so this is a decision made at rebuild time rather than casually, but it should be an explicit decision.

Document the stack. One page listing every plugin, its purpose, its settings that matter and who to contact about it saves an enormous amount of time when something breaks or when a new person takes over.

Decide deliberately how out-of-stock and variable products behave, because the platform's defaults make choices that affect search without announcing it. These settings sit in the store configuration and are rarely revisited.

On stock, there is an option to hide out-of-stock items from the catalogue. It keeps archives tidy and it removes those products from category pages, which means they lose internal links while remaining live at their own address. For a product that will restock, that is usually the wrong trade. A better pattern is to keep it visible, show clearly that it is unavailable, give an expected date if you have one, and offer alternatives and a notify option.

For products that are gone permanently, redirect to the nearest replacement or to the category. Leaving a permanently dead product page live with no explanation serves nobody, and deleting it without a redirect throws away whatever it had earned.

Variable products need a decision about addresses. Selecting a variation typically adds parameters to the URL, and those should resolve back to the parent product. Where a variation is genuinely something people search for by name, such as a distinct model rather than a size, consider making it a separate product with its own page.

Think about how variations affect the page's content. A product page that only shows the selected variation's details in script-loaded content may present very little to a crawler. Check the source and make sure the key specifications are present in the HTML.

Product visibility settings, including catalogue and search visibility, are worth auditing on a mature store. Products hidden years ago for a reason nobody remembers are common, and each one is a page nobody can find.

Finally, check how your feed for shopping channels treats these states, because stock status inconsistency between the site and the feed causes problems on both sides.

Plan any structural change as a migration with a URL map, because this platform makes it easy to change things that quietly break addresses. A permalink setting, a category rename, a plugin that alters slugs, or a theme with different templates can all move URLs.

Start by exporting the current state before you touch anything. A full crawl of the site giving every URL, plus a list from your analytics and search console of the pages that receive organic traffic and the queries they rank for. That export is what you compare against afterwards, and without it you are guessing.

Build the map. Every existing URL that receives traffic gets a destination on the new structure. Where there is a direct equivalent, map to it. Where there is not, map to the closest relevant page. Do this in a spreadsheet, reviewed by a person, rather than relying on a rule to handle everything, because rules handle the common cases and miss the ones that matter.

Implement redirects at the server level where you can, since that is faster than doing it in the application, and it does not depend on a plugin continuing to work. A redirect plugin is acceptable and it adds a database lookup to every miss.

Avoid chains. If a URL already redirects once, point the new redirect at the final destination rather than adding a hop.

After launch, crawl the site again and compare against your export. Look for anything that returns an error, anything that redirects more than once, and anything on your traffic list that has no working destination. Then watch the coverage report for a few weeks, because problems surface gradually.

Update internal links to point at the new addresses rather than relying on redirects. Navigation, category descriptions and content all accumulate old links, and a site full of internal redirects is slower and messier than it needs to be.

Expect a dip. A well-executed change recovers within weeks. A badly executed one may not recover at all.

Build a maintenance routine, because a self-hosted store has more moving parts than a hosted one and no vendor watching them for you. The work is small when it is regular and large when it is not.

Monthly, check the indexed page count against what you expect, review coverage errors, run a crawl looking for broken links and redirect chains, and confirm the sitemap is current and contains what it should. Look at which pages produce organic revenue and follow up anything that has dropped.

Also monthly, check that updates have been applied on staging and then live, and that nothing broke. Security matters here for search reasons as well as obvious ones: a compromised store gets removed from results, and recovery is far harder than prevention.

Quarterly, go deeper. Validate structured data on a sample of product and category pages. Re-measure speed on a real phone. Review the plugin list and remove what is unused. Clean the database. Check the product visibility settings for items hidden and forgotten. Review which categories earn traffic and improve or retire the rest.

Keep backups you have actually tested restoring. An untested backup is a hope.

Maintain a change log with dates covering plugin updates, theme changes, permalink or category edits, and content rewrites. On a platform where many components change independently, that log is often the only way to connect a traffic movement to a cause.

Once a year, step back and check that the category structure still matches how people search, since catalogues drift. Look at your on-site search terms for demand you are not serving, and at your top queries for products you should be stocking.

Finally, write down who is responsible for each part. Self-hosted stores fail when everyone assumes someone else is watching the updates, and the failure usually shows up as a slow decline nobody notices until a quarter has gone.