WooCommerce SEO Checklist: 15 Things to Check Before You Launch

A store launch checklist usually covers payment gateways, shipping zones, and tax settings, and stops there. SEO gets treated as something to circle back to after the store is live and selling. That order of operations is backwards for one specific reason: the fixes that matter most for WooCommerce SEO are far cheaper to make before a catalog is indexed than after. A missing GTIN on 40 products is a form field. A missing GTIN on 4,000 products that Google has already crawled and partially indexed without rich results is a slower, messier fix.

This is a working checklist, not a theory piece. Fifteen items, grouped into four categories, each one written as something you can actually go check right now rather than a vague principle to keep in mind. If you want the full technical reasoning behind the schema items here, including exact field names and JSON examples, that lives in the companion WooCommerce SEO product schema guide. This article is the checklist version of that guide, built for a launch day or a pre-audit pass rather than a deep read.

Product data and schema

This category carries the most weight on the list, because it decides whether your listings are even eligible for the search result treatments that drive clicks: the price, the star rating, the stock badge. Everything else on this checklist matters, but this is where the biggest single wins are.

1. 1Every product has valid Product schema with price, availability, and brand. Check the page source on a handful of products, or run one through a structured data testing tool, and confirm the JSON-LD block is present, not just a theme default that only fills in the name and image. A Product entity with no Offer is not eligible for a price or rating in search results at all.
2. 2Variable products use AggregateOffer with per-variation pricing and stock. A single flat price on a product with sizes or colors that actually differ in price or availability misrepresents the listing. Check one of your variable products specifically, a color or size that costs more or is out of stock should show that in the schema, not inherit the first variation's numbers. The product schema guide covers the exact AggregateOffer structure this requires.
3. 3GTIN, MPN, or ISBN is populated wherever the data exists. For mainstream physical retail products, a GTIN almost always already exists somewhere in the supply chain, on the manufacturer's spec sheet or the distributor invoice. Missing identifiers are one of the most common reasons a listing gets deprioritized in shopping engines even when the rest of the schema is correct.
4. 4Product descriptions are not copy-pasted manufacturer text or a single template reused across every variant. Search engines have no reason to rank a page that says exactly what a dozen reseller pages already say. Spot-check a few SKUs in the same product line and confirm each has language specific to that variant, not just the title swapped in.

Category and site structure

Individual product pages get most of the attention, but category pages carry the broader, higher-volume searches, someone looking for "merino wool socks" rather than one exact SKU. These checks make sure category pages can rank on their own terms instead of riding entirely on the product grid underneath them.

1. 1Every category page has genuine, category-specific text, not an auto-generated one-liner. A page that is just a product grid with no substantive text reads as thin to a crawler no matter how many products it lists, since the products are already indexed separately as their own pages.
2. 2Category and product pages link to each other, and to relevant guide content. A category page that links out to a buying guide or comparison post, and gets linked back from it, gives crawlers a clearer picture of the topical cluster and gives shoppers a path past hesitation before checkout.
3. 3URL structure is flat, readable, and stable. `/shop/category/product-name` style paths that will not need to change later are worth locking in before launch, since URL changes after indexing mean redirects and temporary ranking loss you can avoid entirely by getting the structure right up front.
4. 4Breadcrumb navigation and BreadcrumbList schema are present on both category and product pages. Breadcrumbs help both crawlers and shoppers understand where a page sits in the catalog, and the schema version of them is what actually renders the breadcrumb trail in search results.

Technical and performance

WooCommerce sites accumulate plugins fast: a payments add-on, a reviews widget, an upsell tool, live chat, each with its own JavaScript and CSS. These checks catch the specific Core Web Vitals failure modes that show up on product-heavy pages more than they do on a typical content site.

1. 1The hero product image is properly sized and excluded from lazy loading. Largest Contentful Paint on a product page is almost always this image. Serving an oversized source file, or lazy-loading it because a plugin lazy-loads everything indiscriminately, directly delays the exact element this metric measures.
2. 2Reviews widgets, variation selectors, and any injected banners load into pre-sized containers. Content that renders after the initial paint and pushes the page down is the most common source of Cumulative Layout Shift on WooCommerce pages. Reserve the space with explicit dimensions before the async content arrives.
3. 3Add-to-cart and variation selection respond quickly, without a pile-up of third-party scripts on the same click. Interaction to Next Paint tends to suffer specifically on these interactions, since that is exactly when a page is recalculating price, checking stock, and often firing several tracking pixels at once. Audit what actually fires on that click and remove anything not earning its keep.
4. 4Robots.txt and the sitemap are not accidentally blocking product or category pages. This sounds basic, but a staging robots.txt file left in place after launch, or a sitemap plugin misconfigured to exclude a product post type, is a real and common cause of a store that looks fine to visitors but is invisible to crawlers.

Trust signals

Ranking and rich-result eligibility get a listing seen. These last checks decide whether it gets clicked, and whether it converts once someone lands. They are easy to skip because nothing about them blocks a store from launching, but they are also the fastest to fix.

1. 1Product-specific Open Graph tags are set, so shared links show the right image, price, and title. A generic site logo as the preview image for every shared product link undersells the share and reads as a broken or low-effort link before it is even opened. Test this by pasting a product URL into a chat app and confirming the preview shows that product, not the homepage.
2. 2Schema and visible page content agree on price and availability. This is worth checking as its own item separate from item one, because it is a different kind of failure: the schema can be technically valid and still be wrong if it has drifted from what the page actually shows. Mismatches here are what get listings suppressed rather than rewarded.
3. 3SSL, checkout security badges, and clear return or shipping policy links are visible from the product page. None of this is structured data, but it directly affects whether a visitor who does click through actually completes a purchase, and search engines increasingly weigh engagement signals that trace back to page trustworthiness.

That is 15 checks across four categories. None of them individually takes long to verify. The value is in running them together, once, before a large catalog goes live or gets re-crawled, rather than discovering the gaps one support ticket or one missing rich result at a time.

A repeatable pre-launch QA sequence

If you want a fixed order to run this in rather than jumping between sections, this is the sequence worth turning into a repeatable pre-launch or pre-audit routine.

This sequence is deliberately fast to run, five products, one category page, one performance check, one share test. It is meant to be repeated, not just performed once at launch. Rankwyn's WooCommerce SEO feature handles the underlying schema, identifier fields, per-variation offers, and Open Graph generation automatically as product data changes, and the broader schema and structured data feature covers what gets generated site-wide beyond the product catalog. Pricing for both is covered on the Rankwyn pricing page.