If product pages are missing from Google, start with the mechanics: confirm the page returns a 200 status, is not blocked by robots.txt or a noindex directive, has a self-referencing canonical, and appears in a valid XML sitemap. This WooCommerce indexing guide focuses on those checks because most indexing failures are technical, not mysterious SEO penalties. Google cannot index a page it cannot crawl, and it should not index a page your store labels as a duplicate or low-value variant.
Indexing is not the same as ranking
A product can be indexed and still rank poorly. It can also have excellent copy and never appear in search because a technical rule prevents crawling or indexing. Treat these as separate problems.
For an indexation issue, use Google Search Console's URL Inspection tool on one affected product and compare it with a similar product that is indexed. Look for the reported crawl status, canonical selected by Google, indexing directive, and last crawl date. Do not start by changing titles, adding keywords, or installing another SEO plugin. Those actions rarely fix a blocked URL.
The fastest path is to identify whether the problem affects one URL, one product category, or the whole store. A single product usually points to its content, canonical, or publication status. Hundreds of missing products usually point to a sitemap, robots rule, template-level noindex tag, server error, or poor internal linking.
WooCommerce indexing guide: run the core checks
Confirm the product is public and returns HTTP 200
Open the product in an incognito browser, then inspect its response with a command-line request:
curl -I https://example.com/product/product-slug/The expected response is `HTTP/2 200` or `HTTP/1.1 200`. A 301 redirect is not inherently wrong, but it adds another step and should point directly to the final canonical product URL. A 404, 410, 401, 403, 429, or 5xx response will stop or delay indexing.
In WordPress, verify the product is published rather than private, draft, pending, or password protected. Also check catalog visibility in the Product data panel. A product hidden from the catalog may still be crawlable, but it often has weak internal linking and is easier for Google to deprioritize.
For bulk checks, WP-CLI gives a quick view of product status:
wp post list --post_type=product --fields=ID,post_title,post_status --format=tableIf a large set of products produces intermittent 5xx responses, this is not an SEO task. Check PHP error logs, PHP worker saturation, database slow queries, and upstream timeouts. Googlebot sees the same unstable application your customers see.
Check the site visibility setting and page-level noindex
WordPress has a sitewide visibility setting under Settings > Reading: "Discourage search engines from indexing this site." It is useful on staging but dangerous on production. Depending on the setup, it can generate a `noindex,nofollow` directive across the site.
Confirm the underlying value with:
wp option get blog_publicA production site should normally return `1`. If it returns `0`, correct the setting, clear page and CDN caches, then inspect the rendered HTML for the `` tag.
Next, check the product's SEO plugin settings. Common mistakes include noindexing all product post types, noindexing product categories, or applying noindex to products with thin descriptions. Noindex can be reasonable for internal search pages, cart, checkout, account pages, and filter-generated URLs. It is usually the wrong choice for sellable products and useful category pages.
Also inspect the HTTP response headers. Some security plugins, reverse proxies, or custom NGINX rules send an `X-Robots-Tag: noindex` header even when the HTML appears normal. Header directives can override what you expect from the page source.
Test robots.txt without blocking essential assets
Your robots.txt file should keep crawlers away from private or wasteful paths without blocking your public products, categories, images, CSS, or JavaScript. Do not block `/wp-content/` broadly. Google needs render-critical assets to understand modern WooCommerce templates.
A sensible baseline often disallows cart, checkout, account, and internal search paths while leaving `/product/`, `/product-category/`, and media files available. Exact rules depend on your permalink structure and plugins.
Be careful with broad patterns. A rule intended to block query-string filters can accidentally block every product URL if your catalog uses query parameters for variations, landing pages, or sorting. Test the exact affected URL in Search Console rather than assuming a robots rule behaves as intended.
Fix canonical URLs before Google chooses for you
Canonical confusion is one of the most common WooCommerce indexation problems. The same product may be reachable through its normal permalink, a category-based URL, a tracking parameter, a filtered collection, an attachment page, or an alternate domain version. Google will choose one version. If your signals conflict, it may choose a URL you did not intend to rank.
Each indexable product should usually contain a self-referencing canonical pointing to its preferred permanent URL. That URL should return 200, be internally linked, be included in the sitemap, and not be blocked by robots.txt.
Avoid canonicalizing a genuinely distinct product to a parent product merely because the descriptions are similar. This is especially relevant for variations marketed as separate products, such as different bundle sizes or model-specific parts. If each version has its own demand and useful content, give it a unique URL and enough differentiation to stand on its own. If it does not, keep it as a variation rather than creating dozens of near-duplicate product pages.
Parameter URLs need deliberate handling. Marketing parameters generally belong on the canonical product URL, not in the index. Filter and sort pages are more nuanced. A filtered page targeting a real search demand, with unique copy and stable internal links, may deserve indexation. Thousands of automatically generated combinations usually waste crawl budget and dilute category signals.
Repair XML sitemaps and internal discovery
An XML sitemap is a discovery aid, not a command. Submitting one does not force Google to index weak, duplicate, blocked, or unavailable pages. Still, a clean sitemap makes problems obvious.
Your product sitemap should include only canonical, indexable URLs that return 200. It should exclude redirected, deleted, noindexed, parameterized, and staging URLs. If you changed domains, permalink rules, or SEO plugins, inspect the sitemap for old URL formats and accidental duplicates.
Caching can complicate this. An SEO plugin may generate the correct sitemap while a CDN serves an old cached version. Purge the specific sitemap URL and verify its current output. If the sitemap returns HTML, a login page, or a 5xx error under load, Google cannot reliably use it.
Internal links matter just as much. Product categories, related products, editorial buying guides, brand archives, and on-site search can help crawlers discover inventory. A product that exists only in a sitemap is less trustworthy than one connected to a clear catalog structure.
For large stores, do not blindly display hundreds of related products or run expensive random-product queries on every page. That can increase database load and TTFB. Use curated relationships, cached queries, and paginated category archives. Crawlability should not come at the cost of a slow storefront.
Handle out-of-stock, discontinued, and seasonal products correctly
Do not noindex every out-of-stock product by default. If an item will return, keep the page live, show the stock status clearly, offer alternatives, and preserve its URL. Removing an established product page every time inventory reaches zero creates avoidable index churn.
For permanently discontinued products, the right answer depends on the replacement. Redirect to the closest true successor when one exists. Keep a useful discontinued page when it has search demand, support value, or compatible alternatives. Return a 410 or 404 only when there is no relevant replacement and no reason to preserve the URL.
Seasonal collections can remain indexed if they become useful early enough before demand returns. If they are empty for most of the year, improve the page with upcoming availability, related items, and clear navigation rather than leaving a thin archive online.
Watch server behavior during crawls
Indexing can stall when a store is technically allowed to crawl but too slow or error-prone to crawl efficiently. High TTFB, exhausted PHP workers, database lock contention, and aggressive rate limiting all reduce Google's willingness to request pages consistently.
Check access logs for Googlebot response codes and response times. Look for spikes in 429 and 5xx errors, particularly during imports, backups, scheduled sales, or plugin cron activity. WooCommerce pages are dynamic, and uncached product requests can become expensive when plugins add stock lookups, personalized pricing, or external API calls.
Object caching, properly sized PHP workers, database query cleanup, and fast CPU performance reduce that risk. On busy stores, server-level page caching must exclude cart, checkout, account, and customer-specific sessions while still caching public catalog pages safely. This is where infrastructure choices matter: a fast platform cannot repair a noindex tag, but it can prevent slow application behavior from becoming a crawl reliability problem.
After each fix, request indexing only for representative pages. Then monitor the Indexing report, sitemap status, server logs, and real product traffic over the next few weeks. The goal is not to force every URL into Google. It is to make your best commercial pages easy to crawl, unambiguous to interpret, and dependable every time a crawler or customer requests them.
