Hide Related Products for WooCommerce: safe setup, failure cases, and rollback

Direct answer

To hide WooCommerce's native Related products section safely, return an empty array through the native woocommerce_related_products filter when a bounded hide rule matches. Do not delete products, edit categories or tags, remove template actions, replace theme files, or hide unknown elements with CSS. Turning the setting off or deactivating the plugin should restore WooCommerce's previous result immediately.

StoreFixKit's Hide Related Products for WooCommerce follows that narrow model. Free has one store-wide switch. Pro can target selected products or categories and supplies an explicit product-level Show or Hide choice.

Related products, upsells, and cross-sells are different

WooCommerce uses several recommendation surfaces:

• Related products are generated from product relationships such as categories and tags.
• Upsells are merchant-selected products normally shown on a product page.
• Cross-sells are merchant-selected products commonly shown in the cart.
• A theme, builder, block, slider, or recommendation service can run its own query.

Hiding one should not silently hide all four.

WooCommerce's current wc_get_related_products() implementation applies the woocommerce_related_products filter to the related ID result. The core template hooks place tabs, upsells, and related products at separate priorities. That separation is a useful safety boundary.

Why deleting or reassigning products is the wrong fix

The visible Related products row is output, not stored recommendation truth that must be destroyed.

Editing categories or tags to suppress one row can also change:

• navigation and archives;
• product filters;
• breadcrumbs;
• feeds;
• internal search;
• other merchandising rules;
• SEO landing pages.

Deleting products is obviously worse. It affects inventory, URLs, orders, reports, and customer access.

A focused remover should intercept only the final native related-product result. An empty result gives WooCommerce nothing to render and leaves catalog data intact.

Do not remove broad template actions

One popular snippet strategy removes woocommerce_output_related_products from a template hook. It can work for a specific classic template, but it expands ownership:

• another plugin can move the action;
• a block theme can render related products differently;
• a builder can replace the entire product layout;
• an update can change hook placement;
• a broad removal can become difficult to reverse when several tools modify the same hook.

A public support report says a related-products remover stopped working while unrelated items appeared. Another reports site design breakage around a remover. Individual reports do not prove a single cause. They do justify a release rule: do not modify templates, global layout CSS, or unrelated actions for this one job.

CSS hiding is not removal

display:none can make a section invisible while the server still:

• queries products;
• renders links and images;
• sends the markup;
• exposes it to assistive technology or crawlers depending on implementation;
• reserves layout behavior in a custom component;
• changes when a theme renames a class.

It can also hide the wrong element when a selector is shared.

Returning an empty native data result is a smaller contract. WooCommerce's native renderer sees no products and produces no native row. It does not solve a builder's separate recommendation query, and it should not pretend to.

Blocks and builders can have another owner

WooCommerce's block implementation has dedicated related-products behavior. The current RelatedProducts block source builds and renders its own product query. A custom theme or builder can do something else again.

When a visible section remains:

1. inspect its block name, template, shortcode, or plugin;
2. clear full-page, object, block, and CDN caches;
3. disable the section in its actual owner;
4. do not keep adding CSS until it disappears.

A one-job native filter should remain honest: it controls the native WooCommerce result, not every recommendation on the internet.

Free and Pro should have one predictable precedence

Free's store-wide switch solves the ordinary case. Pro needs only a bounded exception model:

1. Product Always show wins.
2. Product Always hide wins.
3. A selected product is hidden.
4. A selected category is hidden.
5. Otherwise the Free store-wide switch decides.

The explicit product choice is valuable because stores usually have exceptions. A replacement-parts store may hide weak automatic matches on most products but keep useful native recommendations on a few carefully categorized items.

The rule should not become a visual condition builder with user roles, geolocation, cart totals, time schedules, analytics, and remote personalization. Those are separate products with a much larger support and privacy surface.

A category rule should not scan the catalog

The current product is already known on a single-product request. A Pro rule can inspect its bounded category IDs and compare them with saved selected IDs.

It does not need to:

• enumerate every product in the category;
• write a hidden flag to each product;
• schedule a synchronization job;
• rebuild related-product transients;
• save a copy of WooCommerce relationships.

This matters for both performance and rollback. Changing a category selection should affect only future rendering decisions. Removing Pro should leave every product untouched.

Cache can make the old result look active

Related-product IDs and product pages can be cached at several levels:

• WooCommerce or WordPress object cache;
• full-page cache;
• reverse proxy;
• CDN;
• block output cache;
• browser cache.

After changing the setting, use a private window and a cache-busting test URL where appropriate. Purge only the affected product URLs when possible. Do not rewrite product data merely to force cache invalidation.

If deactivation does not appear to restore the section, test the uncached origin before concluding that uninstall changed the theme.

Test the surfaces you do not intend to change

A release test should include:

This catches the difference between "the heading disappeared" and "the product page remained safe."

Resource and failure boundary

The safe Free path reads one small setting and returns either the native array or an empty array. Pro can resolve the current product once and compare bounded IDs.

It needs no:

• custom table;
• cron event;
• storefront remote request;
• catalog scan;
• product write;
• frontend JavaScript or stylesheet;
• template copy;
• telemetry or customer cookie.

Missing WooCommerce, malformed settings, missing product context, inactive Pro, or an unavailable license service returns the original native array. Free remains independent of Stripe.

The Hide Related Products documentation includes screenshots, exact setup, owner boundaries, troubleshooting, rollback, uninstall ownership, and the support evidence checklist.

Beginner launch checklist

Record the native baseline

Choose a product that currently has related products. Record the heading, product IDs, upsells, and cart cross-sells.

Enable Free

Turn on the single switch. Confirm only the native related row disappears.

Restore Free

Turn the switch off. Confirm the same native result returns after caches are cleared.

Test Pro targets

Use one selected product, one selected category, one non-match, one explicit Show, and one explicit Hide.

Test the live template

Check the real classic or block theme on desktop and mobile. Confirm no empty wrapper, overflow, or footer movement.

Test custom owners

Inspect product builders, sliders, quick views, recommendation apps, and shortcodes. Label each as native-filter compatible or separately owned.

Test rollback and uninstall

Deactivate Pro, then Free. Install the previous ZIPs. On a staging copy, uninstall both and confirm products, categories, tags, upsells, cross-sells, and historical orders remain.

Security and support evidence

Only a WooCommerce manager should save global or Pro groups. Product Show/Hide requires permission to edit that product. Every write needs a capability check, nonce, bounded sanitization, and escaped output. WordPress's Settings API documentation explains the value of the core settings flow, while the plugin security guidance covers validation, nonces, sanitization, and escaping.

Useful support evidence includes the product ID, exact URL, visible section owner, Free switch, matching Pro group, product Show/Hide choice, WooCommerce and plugin versions, theme or builder, cache/CDN, expected result, actual result, and screenshots. Remove credentials, customer data, payment details, and full license keys.

FAQ

Does hiding related products delete them?

No. It returns an empty native result and does not edit products.

Does it hide upsells and cart cross-sells?

No. They are separate WooCommerce surfaces.

Why does my page builder still show recommendations?

The builder may run a separate query and bypass the native related-products filter.

Does it remove a WooCommerce action or template?

No. This release uses the native data filter only.

What happens when Pro expires?

The Free store-wide switch continues locally. Product, category, and explicit Show/Hide rules require an active product-bound license.