WooCommerce product restrictions can fail if the site’s live-search plugin does not honor the same visibility rules used by the catalog. In this case, restricted products were blocked from their product pages but still appeared in Ajax Search Pro results for logged-out visitors. A custom integration connected Ajax Search Pro to the existing Catalog Visibility settings, ensuring that products marked as hidden were excluded from public search while remaining available to authorized users.
Issue background
A group of regional WooCommerce stores sold certain products that could only be viewed by logged-in customers.
The existing Catalog Visibility configuration already prevented public visitors from opening the restricted product pages or purchasing those items. However, the same products still appeared in Ajax Search Pro results.
This created an inconsistent experience:
- The restricted products were visible in search.
- Logged-out visitors could see product names and images.
- Opening the result led to a blocked or inaccessible product page.
- Non-restricted products needed to remain searchable for everyone.
The visibility requirement applied only to selected products, not to every professional or member-only product category.
Diagnosis
The Catalog Visibility plugin and Ajax Search Pro were applying separate query logic.
Catalog Visibility controlled access to WooCommerce products and product pages, but Ajax Search Pro generated its own search results. Because the search plugin did not automatically inherit the catalog’s user-based visibility rules, restricted products could still be indexed and displayed in public search.
The initial concern was that the search plugin might require support from its developer. Further review showed that custom code could bridge the two systems directly.
The correct solution was not to hardcode one product brand or list of product IDs. Instead, Ajax Search Pro needed to respect whichever products were already marked as hidden through the existing Catalog Visibility workflow.
Testing also revealed that product variations or related product records needed to follow the same restrictions as the main products.
Resolution steps
- Confirm the existing visibility rules. Verify that the restricted products are already configured correctly in the Catalog Visibility plugin.
- Test the product page while logged out. Confirm that an unauthorized visitor cannot access or purchase the restricted product directly.
- Test Ajax Search Pro separately. Search for the same product while logged out and verify whether it still appears in the live results.
- Review the search query hooks. Identify the Ajax Search Pro filters or query arguments that can modify the products returned by the search engine.
- Retrieve the existing visibility state. Use the Catalog Visibility data already stored for each product rather than maintaining a second list of restricted items.
- Apply the restriction conditionally. Exclude hidden products only when the current visitor is not logged in or does not have the required access.
- Include product variations. Make sure restricted variations, child products, or other related WooCommerce records do not remain visible after the parent product is excluded.
- Avoid brand-specific code. Build the integration so future products can be hidden through the WordPress admin without another code deployment.
- Deploy the code to staging. Test the change away from production before applying it to every store.
- Test restricted and unrestricted searches. Confirm that hidden products do not appear for logged-out visitors while normal products still return as expected.
- Test while logged in. Verify that authorized customers can still find the restricted products through Ajax Search Pro.
- Test exact names and partial keywords. Search by product title, variation name, SKU, brand term, and common partial matches.
- Clear search and page caches. Purge Ajax Search Pro indexes, WordPress caches, hosting caches, and browser caches after deployment.
- Deploy consistently across all stores. Apply the same tested integration to each regional site using the shared visibility workflow.
- Document the editor process. Explain that site administrators can hide future products through Catalog Visibility and that Ajax Search Pro will automatically follow those rules.
A simplified implementation pattern might look like this:
add_filter( 'asp_query_args', function ( $args ) {
if ( ! is_user_logged_in() ) {
$restricted_ids = get_catalog_hidden_product_ids();
$args['post_not_in'] = array_unique(
array_merge( $args['post_not_in'] ?? array(), $restricted_ids )
);
}
return $args;
} );The exact hook and visibility lookup depend on the installed versions of Ajax Search Pro and the Catalog Visibility plugin. The production implementation should use the plugins’ supported APIs or stored metadata rather than relying on placeholder functions.
Final outcome
The custom integration was tested successfully on a staging environment. Restricted products and their related records no longer appeared in Ajax Search Pro results for logged-out visitors.
Public products continued to appear normally, and logged-in users retained access to the restricted catalog.
Because the code followed the existing Catalog Visibility settings instead of targeting one brand, administrators could manage future restrictions through the WordPress dashboard without changing the integration.
After approval, the same fix was deployed across four regional WooCommerce stores.
The key lesson is that product-page access and search-result visibility are separate layers. When a third-party search plugin builds its own product query, it must be explicitly connected to the site’s catalog-access rules.
For help integrating Ajax Search Pro with WooCommerce visibility rules or protecting restricted ecommerce products, contact Freshy.
