WooCommerce 11.0 explicitly registers product_shipping_class as a private taxonomy. Shipping class terms, product assignments, and rate calculations remain, but code that treats shipping classes as public archives or discovers them through public taxonomy queries can stop working.
Use this before updating a store that exposes shipping-class URLs, includes shipping classes in XML sitemaps, builds filters from public taxonomies, or uses custom REST, GraphQL, search, or navigation integrations.
Quick answer
WooCommerce 11.0 Product Shipping Class Private Taxonomy Migration should be handled with a narrow evidence-first workflow: inventory public dependencies, record current behavior, test woocommerce 11.0, then verify the result before making broader changes.
What to check first
- Inventory every use of product_shipping_class outside normal shipping-rate calculation.
- Capture current archive URLs, sitemap entries, REST responses, filters, and navigation links on staging.
- Install WooCommerce 11.0 beta and verify is_taxonomy_viewable returns false while product assignments remain intact.
- Replace accidental public use with product categories, attributes, tags, or an intentional custom taxonomy.
- Retest shipping zones, flat-rate class costs, product editing, imports, and checkout totals before release.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Inventory public dependencies | Inventory every use of product_shipping_class outside normal shipping-rate calculation. | Product shipping class terms and assignments are unchanged after the update. |
| Record current behavior | Capture current archive URLs, sitemap entries, REST responses, filters, and navigation links on staging. | Shipping rates match the same cart, address, and shipping method used before the update. |
| Test WooCommerce 11.0 | Install WooCommerce 11.0 beta and verify is_taxonomy_viewable returns false while product assignments remain intact. | No broken archive, sitemap, filter, REST, or GraphQL dependency remains. |
| Replace unintended archives | Replace accidental public use with product categories, attributes, tags, or an intentional custom taxonomy. | Any intentional public taxonomy behavior is documented as custom code with an owner and test. |
Why this usually happens
- WordPress previously inferred public taxonomy behavior because WooCommerce did not set the public argument explicitly.
- SEO and sitemap plugins can enumerate every public taxonomy without understanding that shipping classes are operational data.
- Custom filters may depend on is_taxonomy_viewable or get_taxonomies with a public query.
- A public override can hide the migration problem while preserving URLs that were never meant for customers.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp eval 'var_export( is_taxonomy_viewable( "product_shipping_class" ) );'
wp term list product_shipping_class --fields=term_id,name,slug,count
wp option get woocommerce_flat_rate_settings --format=json
# Compare staging before and after 11.0 without changing production terms.
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Inventory public dependencies
- Record current behavior
- Test WooCommerce 11.0
- Replace unintended archives
- Verify shipping totals
What to tell the client or owner
Share the affected URL or integration, current taxonomy query, WooCommerce versions, staging result, replacement taxonomy decision, and checkout comparison.
Production verification checklist
- Product shipping class terms and assignments are unchanged after the update.
- Shipping rates match the same cart, address, and shipping method used before the update.
- No broken archive, sitemap, filter, REST, or GraphQL dependency remains.
- Any intentional public taxonomy behavior is documented as custom code with an owner and test.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, review a WooCommerce 11.0 compatibility change.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references