WooCommerce Products Visibility by User Roles - WordPress Plugin

WooCommerce Products Visibility by User Roles Setup Guide

This guide to WooCommerce Products Visibility by User Roles will help you plan customer roles, hide the appropriate products and categories, configure the response to direct visits to restricted pages, and review the catalog from the perspective of every visitor type. It covers a practical path from mapping access rules and initial setup to a B2B use case, indexing, troubleshooting, and making a sound decision about whether the extension fits your store.

The purpose of this extension is not to make a product "invisible everywhere." Its purpose is to create different storefronts for different audiences within one store. A guest may see only the public assortment, a standard customer may see their own selection, and a wholesale buyer may see dedicated products and categories. This approach is useful when you do not want to maintain multiple sites with duplicated products, but it can cause problems if access rules have not been defined in advance.

WooCommerce documentation describes the extension through three settings areas: global visibility, role-based rules, and general settings for search-engine crawling of restricted pages. That is why a reliable setup starts not with randomly selecting products in the dashboard, but with answering three questions: who counts as a guest, which roles are actually assigned to users, and whether a restricted item should be completely excluded from the public-facing site or simply unavailable to part of the audience.

How Roles Turn One Catalog into Multiple Storefronts

The product has a clear operating model worth understanding before you start clicking through settings. It matches a visitor's status against the selected visibility rules and then determines whether a product or category appears in the public catalog for that visitor. Viewing context matters: an unauthenticated visitor is not the same as a registered customer, and a WordPress role will not affect the catalog until a user has actually been assigned that role.

The global tab is intended for a broad baseline restriction. According to the documented behavior, you can select products and categories to hide from logged-out visitors or from all registered customers, enable the rule, and provide a custom message for attempts to open a restricted page. This works well as a first layer: for example, you can hide a wholesale category from guests and standard customers before making it available to a specific role.

The Visibility by User Roles tab adds a second layer. You enable a separate setting for a role, choose either Show or Hide, and select products or categories. These modes are not two labels for the same action. With Hide, the listed items are restricted only for the selected role while everything else remains available. With Show, the role receives access only to the selected items and everything else becomes unavailable. The second rule is the one most likely to produce unexpected behavior when an administrator adds one product but forgets to include categories that should also remain visible.

Choose an Access Model Before You Start Checking Boxes

For a small restricted section, it is usually easier to think in terms of exclusions: the catalog is open by default, while specific products are hidden from one role. That is the Hide model. For a wholesale portal or members-only collection, an allowlist is often more practical: the role can see only an approved assortment. That is the Show model. Neither model is inherently "stricter" outside its context. The actual level of control depends on whether the selection is complete and every path to the product has been tested.

This map does not replace configuration, but it protects you from the most common mistake: creating dozens of disconnected exceptions first, then trying to guess why a visitor sees the wrong assortment. Document the baseline rule and its exceptions on paper or in a working document first, then reproduce them in the admin dashboard.

What Happens to Categories and Direct Links

Product behavior is easier to understand: documented restricted items disappear from listings and standard search results. Categories have an important caveat. The documentation warns that a category may not disappear completely as a navigation item: when a restricted visitor opens it, they receive the configured message or redirect. This means that the absence of product cards on the shop page is not proof that a visitor cannot reach the category through a menu, an old link, or a bookmark.

Rule-intent check: visibility restrictions control how the catalog is presented in the selected context. They do not replace role design, menu testing, or separate protection for confidential data if data protection is the actual objective.

If a product contains commercially sensitive descriptions, files, or data, do not assume that a display restriction alone is sufficient without separately testing what remains accessible through direct links and how materials are delivered. The extension addresses role-based catalog visibility; it does not claim to provide a universal protection model for all site content.

Prepare the Store: Roles, Assortment, and a Safe Rollback Point

Before installation, separate two distinct concepts. A WordPress role determines which group an account belongs to. An extension rule determines which part of the catalog that group sees. The extension does not create a sound business model for you or correct an incorrectly assigned role. If two customers share the same role, they will see the same assortment unless another tool changes the role itself or applies additional conditions.

Start with a small access table outside the dashboard. List guests, standard customers, wholesalers, partners, and any other roles that are actually used in the rows. In the columns, specify public categories, restricted categories, exceptional products, the expected behavior for direct links, and the person responsible for assigning the role. Do not add a role "just in case." The more similarly defined roles you create, the harder it becomes to prove that each user reaches the correct rule branch.

Review Your Source Data Before Changing the Storefront

The product picker in the settings is useful only when it already reflects the structure of the store. For a wholesale setup, first make sure product groups are separated into categories and that product names make them easy to identify. If one product belongs to both public and restricted rules, document it as an exception. Trying to solve unclear classification with visibility rules alone almost always creates a long list that is difficult to maintain.

• Create a backup of the database and files, or work on a site copy, especially if the live store is already processing sales.
• Record the current storefront state: capture the visible product list, standard search results, and category links for every important audience.
• Verify role assignments with two or three test users, rather than checking only that the role name exists in the list.
• Review menus and theme sections that may lead to a restricted category: the primary menu, footer, banners, collections, related products, and links in articles.
• Define the restricted-page response: a clear message, a redirect to the login page, or a redirect to an allowed catalog page.

This is especially important in stores with aggressive caching. A cache layer may serve a previously generated page to another visitor if it does not separate guest and authenticated variants. The extension should not become the place where you try to guess cache behavior. After enabling rules, verify how caching is configured for authenticated sessions and shop pages, and always test changes after clearing the cache that actually serves the public-facing site.

Separate Visibility from Pricing and Purchase Rights

Products Visibility by User Roles focuses on showing or hiding products and categories according to a role. Do not substitute pricing rules for that purpose. If a wholesaler must see a separate assortment and receive different prices, first make sure a second tool is responsible specifically for pricing and that the two systems do not conflict over which product cards remain visible. The safer order is simple: verify catalog access first, then price presentation, then add-to-cart behavior, and only afterward run a test order in an isolated environment.

You should also distinguish a guest from a role. In documentation for this class of extensions, a guest is a visitor who is not logged in, not an ordinary WordPress user role with editable capabilities. Do not try to assign a "Guest" role to a real user. For testing, use a clean browser window or sign out; for the customer path, sign in with a prepared test account.

Installation and the First Sign That the Extension Is Connected

The official installation sequence is standard for a WooCommerce extension: in the WordPress dashboard, open Plugins, choose Add New, then Upload Plugin, select the ZIP file you have, install it, and click Activate. After activation, do not immediately start hiding items in bulk. First, open the WooCommerce menu and confirm that Product Visibility is available. Its presence is a practical sign that the extension's administrative interface is accessible.

If the new menu item is missing, stop configuring rules. Confirm that the extension is actually active, WooCommerce is active, and the account has permission to manage the store. Do not try to compensate for a missing screen with rules from another, similar plugin: different products use different menu locations and priority models. Mixing instructions is a common reason an administrator believes a rule was saved when they were configuring the wrong tool.

Build a Minimal Test Before a Full Rollout

Create one test product, one test category, and, if the business use case requires it, one test role. Use names that are recognizable to administrators but contain no real customer data. Then prepare three viewing methods: a clean window for a guest, a standard customer login, and a login for the target role. Add visits from the shop page, a category, search, and the product's direct URL to your checklist.

Why is that necessary? Because a catalog rarely appears in only one archive. Your theme and WooCommerce may build collections, search results, or product links through different queries. Official documentation confirms that hidden products are excluded from listings and standard search, but specific theme sections and third-party widgets must be checked in your own configuration. Prove the behavior with a test item first, then apply the same principle to the live assortment.

Required step before bulk configuration: save the original visible-product list for every test visitor. It will help you distinguish a new rule from an old cache entry, a theme issue, or an accidentally assigned role.

If the test fails, the easiest rollback is to disable the relevant tab's rule or remove the test item from it, save the changes, and clear the storefront-related cache. Do not delete real products for diagnostic purposes. The purpose of the first run is to confirm the setup path and role behavior, not to rebuild the catalog structure.

Global Visibility: Build a Baseline Layer Without the "Show Everything" Trap

The global tab is useful when access must be restricted for a broad audience rather than for one role. According to the official description, it lets you choose whether specific products and categories are hidden from logged-out visitors or from all registered customers. This setting should not become a dumping ground for exceptions. Its strength is a clear initial barrier: the selected section is unavailable to an audience it was not intended for until a later role rule opens the required exception.

Imagine a supplier store with retail products open to everyone and a "Wholesale Bundles" category intended only for partners. If you immediately configure Show for wholesalers with only a few products, it is easy to forget that guests and standard customers may still see the category itself. A more practical approach is to select the wholesale category and its dedicated products under Global Visibility, hide them from guests and registered customers, and then explicitly restore access for the wholesale role on the roles tab.

Order of Global Restriction Setup

1. Open WooCommerce > Product Visibility and go to the Global Visibility tab.
2. Select the audience to restrict: logged-out visitors or all registered users.
3. Add only the products and categories that form one clearly defined restricted set.
4. Enable the rule through the appropriate interface control and save the changes.
5. Enter the visitor message or prepare the URL of a page where the person may be redirected.
6. Check the behavior in a clean browser window and under a standard test account before opening exceptions for the required role.

Each step supports a different check. Selecting items without enabling the rule proves nothing. Saving without testing as a guest does not prove behavior for an unauthenticated visitor. Testing only the shop page does not reveal the response to a saved direct link. After every change, it is helpful to record two things: which audience was restricted and which page you opened during the test.

Messages and Redirects Should Not Hide an Error

The extension allows you to prepare custom text for a visitor on a restricted page, and the documentation also describes redirecting to another address. This is a user-experience decision, not a technical formality. A good message explains the next permitted step without exposing internal rules: for example, it may ask the visitor to sign in or contact a manager if that is the store's intended path. A poor message says "error" when access is actually blocked by a role rule, or promises a registration form that the site does not provide.

A redirect is useful when a restricted category should not leave visitors at a dead end. However, verify that the target page is itself accessible to the restricted visitor and does not send them back in a loop. To test this, open the direct URL of a restricted product, follow the entire path, and make sure the browser does not enter an endless redirect loop. If the goal is simply to give the visitor a clear signal, a custom message is often safer to start with than a complicated redirect chain.

A Hidden Category Is Not the Same as a Removed Menu Item

The documentation specifically notes that a category may not be hidden completely: a restricted visitor attempting to open its page will see a message or be redirected. This leads to a practical rule. After configuration, check not only the category page but also menu items, footer links, banners, "Popular" sections, and internal links in articles. If a navigation item is not useful for guests, remove or restructure it through the theme, menu, or selected page builder. Do not expect one visibility rule to make navigation understandable automatically.

This is where responsibility boundaries matter. The extension controls the display of selected products and categories within its own use case. The theme controls which links appear on the page. The cache controls whether another visitor receives an outdated variant. Do not try to fix a menu problem by changing an access rule. First identify where the link is generated, then correct that layer and retest the restriction.

When the Global Tab Is Not Needed

Do not enable a global restriction merely because the extension provides one. If the regular catalog is open to everyone and you only need to hide one product from one internal role, a baseline restriction for everyone will only make future maintenance harder. The same applies when roles overlap in real responsibilities but the assortment should not differ. In those cases, it is better to keep the catalog open and use only a precise Hide rule for the required group.

Another unsuitable use case is trying to turn visibility into a registration-approval system. If a user requires manual approval, there first needs to be a transparent process defining who assigns the role and when after review. Without that process, a restricted storefront turns into a stream of messages saying, "I'm logged in, but I can't see anything." The extension will correctly apply the rule, but it cannot explain why the required role was not assigned.

The brief checkpoint after global setup should be simple: guests and standard customers do not see the selected test item in the shop or search, the direct URL produces the response chosen in advance, and the wholesale role is not yet open. Only then should you move on to the role rule. This allows you to see which layer produced the outcome rather than mistaking a coincidence for a working configuration.

Practical guideline: use the global layer as the foundation for a restricted segment, not as a way to implement every possible exception. The simpler the initial barrier, the easier the rules are to maintain when new products are added.

Role Rules: How Not to Confuse Show and Hide

After the baseline restriction comes the part where the extension becomes genuinely useful for B2B stores and restricted collections. On the Visibility by User Roles tab, you open a specific role, enable a separate setting for it, and select a mode. The documentation confirms two behaviors: Show makes the selected products available to the chosen role and restricts everything else, while Hide hides selected products from the chosen role while leaving the rest of the assortment available. Before saving, say the rule as a complete sentence: "A wholesaler sees only these items" or "A standard customer cannot see these items." If the sentence is unclear, the configuration is not ready yet.

The most dangerous mode is Show because it acts as an allowlist. Suppose you want a wholesaler to see a restricted bundle and select one product. After saving, the wholesaler may stop seeing other products that were previously available because they were not included in the Show selection. The official instructions for a "retailers only" use case explain this effect separately: if other categories should remain visible to the role, they must be included. Do not treat this as an interface inconvenience; it is the logical consequence of a "show only what is listed" model.

A Working Procedure for Each Role

1. Open the role you intend to test, not an administrator or customer role with a similar name.
2. Click Enable for this Role if the interface requires rules to be enabled for the selected role.
3. Choose Show for an allowlist or Hide for a targeted exclusion.
4. Add products and categories according to the access map prepared in advance.
5. Save the changes and write down the expected assortment for that role in one sentence.
6. Sign in as a test user with that role and check the shop, search, category, and direct product URL.

At first glance, this may feel excessive, but the step of stating the expected outcome saves considerable time. When a test reveals an extra or missing product, you can compare the observation to the rule immediately instead of trying to remember which combination of checkboxes you selected. For a large catalog, maintain this map in a table: role, mode, selected categories, exceptional products, test status, and date last reviewed. Visitors do not need to see those dates, but the store team benefits from them.

Build an Allowlist from Catalog Structure, Not from a Random Product Card

The Show mode is easier to maintain when categories form its foundation and individual products are added only as deliberate exceptions. First list the sections that should be fully available to the role: for example, the wholesale category, common supplies, and a product-documentation section if it is structured as a product category. Then separately mark products that should be available outside those sections or, conversely, should be excluded from the general selection. This keeps the rule readable: another employee can understand why a category was selected instead of trying to reconstruct the rationale from dozens of similar product names.

Check each category boundary before saving. A product assigned to both public and partner groups may be convenient for inventory management, but it makes the behavior harder to explain. Do not change the store structure merely to create a neat list in the extension. It is enough to document that product as an exception and test it separately for every role. If overlaps become frequent, that is a sign to revisit the assortment map: perhaps the wholesale line has not yet been separated into a clear product group, or it requires a different access model.

A useful control question before enabling Show is this: can an employee list every section that will remain available to the role after a new product is added? If the answer sounds like, "Probably everything that was visible before," the rule has not been defined precisely enough. In this mode, the safer assumption is the opposite: only items explicitly included in the allowed selection will remain visible. Select the smallest complete set of categories first, then sign in as a test user and compare the actual storefront with the list you created. Add uncommon product-level exceptions only after that.

How to Add a New Product After Rules Are Live

A new product card should not enter a restricted segment automatically simply because an employee remembers the general idea behind the store. Before publishing, determine where it belongs on the access map: is it part of an open category, a restricted group, or both storefronts? Then review how the target role's rule was built. With Hide, check whether the new item must be explicitly added to the restricted list. With Show, make sure the product is already covered by an allowed category or has been deliberately added as an individual item. This short review prevents two separate mistakes: a guest sees a prematurely published product, or the intended role cannot find the new item after launch.

After making the change, do not limit testing to viewing the product as an administrator. Administrators often have different capabilities and may not reproduce a customer's path. Open the shop page, the target category, and standard search in the session for which the rule was designed. Then use the new product's direct URL. If it should be hidden, record not only its absence from listings but also the clear response to that URL. If it should be available, make sure the user can find it through normal navigation rather than only through a saved link.

Keep Role Changes Separate from Rule Changes

When a partner reports that they cannot see the assortment, there are two independent things to inspect: their actual role and the contents of that role's rule. Do not correct both at once. First open the profile of the test or real user and confirm the target role according to your internal process. Then, in a separate window, inspect the Visibility by User Roles rule: is it enabled for that role, is the expected mode selected, and does it include the necessary products or categories? If you change both places at the same time, a successful outcome will not tell you what caused the problem, and the next issue will be harder to reproduce.

The same principle is useful when revoking partner access. First change the role assignment for one test account and confirm that the restricted storefront disappears after a new login and clearing the relevant cache. Then retest the ordinary public catalog: revoking access to a special line should not accidentally remove the person's access to retail products. The visibility rule remains the catalog map, while the role is the key that determines how that map is applied. This separation keeps the process understandable even when the store is handed over to a new administrator.

For ongoing maintenance, a short record after every notable change is enough: who changed the role or rule, which segment was affected, which test user was used, and which four entry points were checked. This is not bureaucracy for its own sake. The record helps distinguish new extension behavior from an outdated session, cache, menu edit, or parallel product change. If a rollback is needed, the team can restore the last clear rule instead of deleting all settings because of one unexplained outcome.

The Wholesale Role as a Concrete Setup Example

Consider a sequence close to the official example. Goal: show a "Wholesale Bundle" and the "Wholesale Products" group only to the Wholesale role while keeping the retail catalog available to regular visitors. Preparation: the role already exists and is assigned to a test user; the products and categories are identified; and the store has a test standard customer.

First, under Global Visibility, hide the wholesale product and category from guests and registered users, enable the rule, and save it. Then open Visibility by User Roles, select Wholesale, enable the role rule, choose Show, and add the restricted product. If wholesalers should continue to see the public part of the catalog, add the relevant categories as well, as the documentation recommends for Show. Save the rule, and only then begin testing.

How to Verify That the Setup Is Actually Complete

A guest should not find the wholesale item on the shop page or in standard search results. A standard customer should see the same behavior. A user with the Wholesale role should see the required bundle, category, and every public group that was intentionally added to the allowlist. Then, in every session, open the saved direct link to the product. If a guest receives a custom message or a redirect, that is the expected path. If a wholesaler reaches a restricted page, first compare their actual role with the role selected in the rule, then check whether a category was omitted in Show mode.

Multiple Roles for One User

This situation requires particular care. WordPress and additional role-management tools may allow a user to have more than one role. The product documentation explains configuration for each role in detail, but the reviewed materials do not provide a universal priority rule for every multi-role combination. Therefore, do not promise predictable intersection behavior without testing your exact version and set of extensions.

A safe practice is to assign one target commercial role to customers whose storefront must differ and avoid giving them competing access roles. If multiple roles are unavoidable, create a separate test user with the same combination, document the expected product set, and test all catalog entry points. Record the observed behavior in the store's internal instructions. If the behavior does not match the business rule, simplify the user to one target role or consult the developer documentation before launching on the main store.

Bulk Setup and Assortment Maintenance

Official documentation states that products and categories can be shown or hidden for roles at the same time. This is useful during initial setup, but it does not remove the need for discipline. Do not add a new product to a restricted category and consider the task complete without checking how the selected mode handles it. With Hide, the new product may remain available if it was not included in the restriction. With Show, it may remain hidden if it was not included in the allowed selection. Which response is correct depends on your access model.

Assign ownership of the process: one employee updates the assortment, another manages customer roles, and a third manages menus. Without this, rules will remain correct only on the launch date. A good recurring review includes a new product, an updated category, a new role, and a removed role. For every change, ask one question: what will a guest, customer, and target partner see after publication?

Summary: Hide answers, "Who should not access the listed items?" while Show answers, "What should remain available to this user?" Do not switch modes to quickly fix a missing product card until you have recalculated the entire selection that should be available to the role.

Visibility, Search, and Indexing: Check More Than the Shop Page

The settings include a separate General Settings group related to whether search engines may crawl and rank restricted pages. The official documentation draws an important boundary: if a product or category is hidden from logged-out users, it is hidden from Google by default as well; a separate toggle can allow crawling and ranking of those restricted pages. This option affects how you think about a product's public availability, but it does not replace an overall SEO strategy or promise that a page will immediately appear or disappear in search.

Start by deciding what the page is for. If the restricted item is intended only for partners and should not attract public demand, keeping it out of crawling is a logical choice. If a catalog is designed to encourage registration through a public description, another approach may be useful, but it must align with what a visitor arriving from search will see. Do not create a situation where a search snippet promises a product but the visitor receives an unhelpful message with no path to access.

Check the Outcome in Four Contexts

The same product card should be checked in four ways because the catalog experience is not formed on the storefront alone. Create a simple matrix for each mode and repeat it after any significant change to rules, the theme, caching, or the assortment.

Repeat the matrix for a guest, standard customer, and target role. Do not perform every check in one browser window by merely switching tabs: cookies and an active session can easily distort the outcome. Use a clean session for the guest, separate browser profiles, or sign out between tests. Record not only whether a product is "visible" or "not visible," but also the context, URL, role, and actual response.

Why Cache Can Distort Your Conclusions

Role-based visibility depends on the current visitor. A page generated for a guest and a page generated for a logged-in partner should not be treated as interchangeable. If a caching plugin, server cache, or external delivery network stores one version as a shared page, two symptoms are possible: a wholesaler receives the guest's empty storefront, or a guest sees part of the partner assortment. In that case, the problem may not originate in Products Visibility by User Roles, but the entire delivery chain still needs to be checked.

A safe diagnostic sequence is to temporarily exclude shop pages and the test product page from cache on a site copy or during a short maintenance window, or disable the caching layer according to its developer documentation. Repeat the test in clean sessions. If the behavior becomes correct, restore caching gradually while configuring proper treatment for logged-in users and exclusions for sensitive paths. Do not leave the public catalog uncached as a permanent solution if the issue can be resolved by separating response variants.

Themes, Blocks, and Custom Collections

The official description refers to hiding products from listings and standard search results. However, a modern theme may display products through more than the ordinary shop page: popular items, related products, category collections, editor blocks, page builders, and third-party widgets may use their own data sources. You cannot promise identical behavior for every such section without testing. Instead, choose two or three real theme sections where the card normally appears and add them to your verification matrix.

If a restricted product remains visible in an unusual section, document that specific section and how it displays products. Then check theme updates and the documentation for the module in use. Do not add an untested PHP snippet to core files or an extension file. Without a documented extension mechanism, it is safer to temporarily remove the problematic section for the restricted audience, adjust its source through theme settings, or involve a developer who can inspect the query on a site copy.

A Practical Test with a Test Order

Although the extension is focused on the storefront, a store should confirm that an assortment change has not created an odd route into the cart. Once a wholesaler can see their test product, add it to the cart in a test environment, proceed to checkout, and make sure the product does not disappear unexpectedly. Then sign out and confirm that an old product-page link cannot bypass the chosen restriction. The goal is not to configure payment; it is to detect inconsistency between the catalog, cart, and active session before a customer encounters it.

This test is especially helpful when the store uses saved carts, quick product views, or other add-ons. In such systems, user context can persist longer than a single page. Do not judge the configuration from one click. Proof of the outcome is a repeatable path from sign-in to a verification point that another employee can repeat.

How to Document the Indexing Decision

For every restricted segment, add a separate column to your internal map: "publicly indexed" or "not indexed," along with the reason. For example, a wholesale bundle is not indexed because it is available only to an approved role. A public partnership invitation page, by contrast, may remain open and explain collaboration terms without exposing the restricted assortment. This is clearer than trying to make one product page both promotional for everyone and invisible to most people.

Cautious wording: allowing crawling does not guarantee ranking, and blocking crawling does not replace checks of current links, the sitemap, and cached pages. The decision should be verified through search analytics and within the site's broader policy.

Practical Use Case: A Restricted Wholesale Line in a Regular Store

Now let us build a complete working use case without assumptions about pricing, payment, or licensing. Imagine a store selling supplies. Retail customers see the standard assortment. Partners with the Wholesale role receive a dedicated category of bulk packs while still being able to see the base groups needed for navigation. Guests should understand that the restricted line exists only through an appropriate message or login page, but they should not see its product cards in the ordinary storefront.

Goal, Preparation, and Scope of the Use Case

The goal is to make one shop page understandable to three audiences without creating duplicate products. Prepare a test category called "Wholesale Bundles," one product inside it, and one public category, such as "Supplies." Create one test user with the Wholesale role and another with the customer role. Confirm that both can sign in and that the wholesale role has been assigned to the user itself, rather than merely created in an additional role-management plugin.

The boundaries of this use case matter as well. It demonstrates visibility control for products and categories. It does not set different wholesale prices, add an approval form, or control shipping. If your store needs those capabilities, select separate solutions for each responsibility and test how they work together one layer at a time. Complex business rules become more reliable when every extension has a clear area of responsibility.

Step 1. Restrict the Wholesale Bundle as the Baseline State

Under WooCommerce > Product Visibility, open Global Visibility. Select restrictions for logged-out visitors and registered users, then add the test wholesale product and category. Enable the rule and save it. Enter neutral text for restricted visitors that does not reveal unnecessary commercial details. For example: "This section is available to approved partners after signing in." If you have a working login page or a clear partner page, you may choose an appropriate redirect, but test the text message first because it is easier to diagnose.

Open the store in a clean browser session. The test wholesale product should not appear in regular listings, and a name search should not return it through standard search. Then paste its direct URL into the browser address bar. You should receive the response you prepared. If the behavior differs, do not move on to the role: confirm that the rule is enabled, the changes are saved, the cache is cleared, and you are actually testing as a guest.

Step 2. Open the Assortment for the Wholesale Role

Go to Visibility by User Roles, select Wholesale, and enable rules for that role. For the restricted line, use Show and add the wholesale product and category. Then decide what happens to the public part of the store. If wholesalers should see it alongside the restricted line, add the necessary public categories to the allowed selection. The documentation highlights this point: Show leaves the role with only the selected items. Do not test the setup until you can state the full expected selection.

Sign in as the Wholesale user. First open the shop page and confirm that the wholesale bundle is visible. Then open the public category. If it has disappeared, this is not a reason to urgently replace Show with Hide; return to the allowlist and add the part of the catalog that should remain available. Save, clear the cache relevant to the test, and repeat the matrix. This preserves the access model instead of accidentally achieving a superficially similar outcome.

Step 3. Check the Standard Customer

In a separate session, sign in as a standard customer. This user should not see the wholesale line in the shop, category, search, or through the direct URL. At the same time, they must retain access to retail products. This is the part that reveals side effects from an overly broad global rule. If a retail category disappears, check whether it was accidentally included in the global selection or whether a cached variant for another session was served.

After checking the guest, customer, and wholesaler, ask another employee to repeat the test using your checklist. An independent review is useful because the person who created the rule often remembers the intended outcome and may overlook an inconvenient message, an incorrect link, or an open footer section.

Combining Registration with Role Assignment

Products Visibility by User Roles uses the existing user context. In a practical setup, you can use a standard WooCommerce account or a separate solution that assigns a role after an application is reviewed. This is not an officially stated integration between specific products; it is a safe separation of responsibilities: one mechanism determines who becomes a partner, while this extension builds the catalog after sign-in. Before launch, define who grants the role, how it is revoked when a partnership ends, and how to test the change with a test account.

Make the rollout order reversible. First create the role and test visibility with one product. Then extend the rule to one category. After that, add a standard public category to the Show selection if the wholesaler needs it. Only when all three use cases pass consistently should you apply the approach to the remaining wholesale groups. Rolling back any step means removing test items from the rule or disabling the relevant rule and clearing the cache again. Do not delete accounts or live products if you only need to return the storefront to its previous state.

Small Improvements Without Editing Extension Code

For this product, the safest improvements focus on the process rather than adding untested code. Add a new-product template to the administrative instructions: public, restricted for certain roles, or available only to a selected role. Specify the required verification for each option. If the theme displays a link to a restricted category in the menu, edit that menu using the standard theme or WordPress tools rather than changing extension files. This prevents product updates from overwriting your work.

Prepare one consistent message for restricted visitors and test it on both phones and computers as part of the page, not only in the settings field. The message should be short, contain no personal data, and provide a clear next step. If the business process includes manual approval, it is useful to explain it on a public partner page rather than placing a long instruction inside an access-denied message.

Use-case outcome: one store retains its shared retail catalog while a restricted line becomes visible only after the appropriate role has been assigned. You verify this not from the configuration alone, but through the repeatable path of every visitor type.

When WooCommerce Products Visibility by User Roles Is a Good Choice

The extension is especially appropriate when a store needs clear control over which products and categories are shown to guests and specific user roles. It fits a restricted wholesale line, partner section, pre-release collection, or segmented catalog when you can answer honestly: who belongs to each group, which items that group sees, and what path they receive when attempting to open a restricted page.

It is less convenient when business rules are determined not by a role but by a personal agreement, past order total, location, complex schedule, or price. In those cases, first state the conditions in plain language and compare them with the tool's area of responsibility. You may need a broader catalog module, a complete B2B solution, or a separate access system. Do not stretch a simple model with dozens of exceptions if the task requires a different type of rule from the beginning.

Checklist Before Enabling It on the Live Store

• Customer roles are defined and assigned to test users.
• Every segment has a map of products, categories, and the expected direct-URL response.
• A meaningful Show or Hide mode has been selected rather than a random set of checkboxes.
• Guest, standard customer, and target role have been tested through the shop, category, search, and direct link.
• Menus and theme sections that may lead to a restricted category have been checked.
• The cache does not mix storefront variants from different sessions.
• The decision about search-engine crawling of restricted pages matches the catalog's purpose.
• A reversible path exists: a test copy, a backup, and a documented initial state.

When this checklist passes without unexpected exceptions, you can download WooCommerce Products Visibility by User Roles and repeat the minimal test for your own catalog structure. Do not turn activation into one large live change during business hours. Start with one test group, check it with all three audiences, and then expand the configuration gradually.

The main sign of a well-configured setup is not the number of rules but the predictability of the store. A guest does not encounter unnecessary products, a customer does not lose access to the public assortment, a partner immediately finds the needed section, and the team understands where roles are changed, where the catalog is managed, and where the outcome is verified. That is what makes WooCommerce Products Visibility by User Roles a practical tool rather than another confusing tab in the admin dashboard.

Final check: ask a colleague who did not participate in the setup to sign in as every test user and go through the four entry points. If they receive the expected catalog without additional explanation, the working setup has been assembled correctly.