WooCommerce wishlists are not only a front-end feature to switch on. They affect how visitors save products, return to a store, share selections and continue toward checkout. The documented WooCommerce Wishlists extension supports multiple lists, temporary guest lists, persistent lists for registered users, three visibility modes and configurable post-purchase processing.
The important decisions are practical rather than universal. A store must decide whether guests may create lists, which privacy mode fits each use case, which sharing channels to expose and when purchased products should be removed. The guidance below focuses on configuration and testing. It does not claim that one setup produces better conversion, retention or revenue for every store, and compatibility with a particular theme, builder or extension should be verified on the target site.
What WooCommerce Wishlists Can Do
The WooCommerce Wishlists extension allows visitors and customers to create multiple wishlists and add products to them. A customer can select an existing list during the add-to-wishlist flow or create a new list without leaving that process. This is useful when one shopper wants separate lists for different occasions, projects or purchasing plans.
Customers can manage their lists after creation. The documented workflow includes updating quantities, removing products, moving items to the cart and transferring selected products to a new list. Lists can also use one of three visibility modes: Public, Shared or Private. These modes determine whether a list can be discovered, accessed through a link or viewed only by its owner.
Guest Wishlists vs Account-Based Wishlists
Guest access removes the immediate requirement to create an account, but it also changes how long and where wishlist data remains available. Guest users can store wishlist data for 30 days. Registered users can save wishlists indefinitely. Guest data relies on browser cookies and is available only on the same computer and browser. If cookies are cleared or expire, the list may become inaccessible.
This makes the choice dependent on the customer journey. A store may allow guests to save products during initial browsing, then invite them to log in when they need longer-term or cross-device access. A guest can log in later to save the lists to the account. The documentation does not provide performance evidence proving that guest access or account-only access is universally superior.
When guest access lowers the entry barrier
Guest wishlists let a visitor create a list without immediate account creation. That can be appropriate when shoppers are still comparing products or are not ready to provide account details. However, the store should explain the temporary, browser-dependent nature of the list near the wishlist experience. Visitors should understand that cookie deletion or expiry can affect access.
Before enabling the feature, review the store’s privacy policy and cookie-consent configuration. The aim is not to promise permanent storage, but to make the limitation visible and give customers a clear reason to register when continuity matters.
When account-based continuity matters
Registered users can retain wishlists indefinitely according to the documentation. Account-based access is therefore the relevant option when shoppers need a longer-term record rather than a temporary browser list. Prompts to log in or register should be tied to that persistence need, not presented as proof of better business performance.
Keep both paths distinct in the customer journey: guest lists provide temporary access, while account-based lists provide the documented indefinite storage available to registered users.
Configure Guest List Access
In the Wishlists settings, locate the option named Allow Guests To Create Lists. Enable it when the store wants visitors to create temporary lists without logging in. Disable it when all list creation should require an account.
When guest list creation is disabled, wishlist buttons are hidden from products and users must log in before creating a list. After changing this setting, test the logged-out product flow and check the wording shown to visitors. If guest access is enabled, messaging should accurately describe browser-based storage and the possibility of losing access after cookie deletion or expiry.
Configure Private, Shared, and Public Lists
Customers can change a list’s privacy in the list settings. Public lists can be searched for and viewed by anyone. Shared lists are available through a shared link and do not appear in search. Private lists are visible only to the owner and cannot be shared.
These modes should be explained in the interface rather than treated as interchangeable labels. A public list is discoverable, a shared list is link-accessible without search visibility, and a private list is owner-only. The store should also expose the relevant wishlist, create-list and find-list pages in its navigation, because these links are not automatically added to menus.
Match visibility to the intended use
Use Public visibility for lists intended to be found by other people. This may suit a use case where discovery is part of the experience, but public visibility should never be described as private. Use Shared visibility when selected people should access a list through a link without the list appearing in search. Use Private visibility for personal or sensitive selections that should remain visible only to the owner.
Before launch, verify what each mode exposes. Minimize personal information on public or shared lists and check names, email addresses, descriptions, product data and shared links. The selected mode is a practical configuration choice, not a universal legal determination.
Choose Wishlist Sharing Channels
The extension provides built-in sharing options for Facebook, Twitter, Email and Pinterest. Store managers can choose which options are available to users. Enable only channels that match the store’s audience and the intended privacy model; the documentation does not rank these channels or provide engagement comparisons.
Email and link-based sharing can fit invitation-based use cases, while public-list discovery may fit a store where users intentionally want lists to be found. These are use-case recommendations, not performance claims. Review shared URLs before launch and verify that they do not expose more personal information than intended. Browser storage and third-party sharing should also be documented as part of the store’s privacy review.
Set Up Multiple Lists and Customer Workflows
Multiple-list support gives customers a way to organize products instead of placing every saved item in one long collection. During the add-to-wishlist flow, a customer can add an item to a selected existing list or create a new list. Afterward, the customer can update quantities, remove products and move items to the cart.
Customers can also transfer selected items to a new list when their plans change. Keep the wishlist, create-list and find-list pages easy to discover through site navigation. Then test the complete flow on the actual storefront, including product pages, list management and the transition from selected items to the cart.
Ownership is especially important when custom themes, blocks or other extensions are involved. Check the experience while logged out and while signed in as different customers. One customer’s wishlist data should not become visible to another customer through the storefront or a customized integration.
Define Post-Purchase Wishlist Behavior
The extension allows store managers to remove purchased products from wishlists when wishlist processing is enabled. The manager can also choose the order status that triggers removal. Purchased items are not removed unless this behavior is enabled.
For an ordinary personal wishlist, removing an item after the intended order state can reduce duplicate entries. However, no single order status is correct for every store. Test the selected status against payment failures, cancellations, refunds, backorders, partial orders and shared-list use cases. Confirm that removal happens only when the order reaches the state the store actually considers appropriate.
Do not assume that this default behavior represents a gift registry or every shared purchasing workflow. Those scenarios may require different handling or customization, and the supplied documentation does not establish a universal rule for them.
Privacy, Compatibility, and Launch Testing Checklist
Complete a focused test before making the wishlist experience widely available. The goal is to verify persistence, visibility, ownership and post-purchase behavior on the store’s actual configuration.
- Test wishlist access while logged out and while logged in as different customers.
- Open the flow in a private browsing window and test it again after deleting cookies.
- Check Public and Shared lists for unintended exposure of names, email addresses, descriptions, product data and links.
- Review the privacy policy, cookie-consent setup, browser-storage explanation and data-cleanup procedures.
- Verify that shared access works through the intended link without making the list searchable when it should not be.
- Test the selected order status with incomplete, changed and cancelled order scenarios.
- Check the target theme, page builder, multilingual setup, caching layers and other extensions rather than assuming compatibility.
WooCommerce privacy guidance supports minimizing personal data shown on the frontend, restricting access to personal data, securing storage, documenting browser storage and third-party sharing, and maintaining cleanup procedures. When a customized theme, block or API-related integration is used, verify that exposed resources belong to the current user or are non-sensitive. Data from another customer should not be returned.
Separate documented and experimental wishlist functionality
Keep the documented WooCommerce Wishlists extension separate from WooCommerce core’s experimental Shopper Lists features. They are not one combined setup. The core features are described as experimental, opt-in and focused on logged-in shoppers in suitable block-based stores. They should not be presented as stable, equivalent to the extension or ready for production without independent testing.
For this reason, document which implementation the store uses, configure only the relevant settings and test the customer journey that belongs to that implementation. The research does not verify behavior across every browser, device, consent configuration, caching layer or third-party stack.
WooCommerce wishlists work best when configuration follows the intended customer journey. Allow guest lists when temporary, browser-based storage is acceptable, and explain the limitation clearly. Encourage account access when customers need indefinite continuity. Choose Public, Shared or Private visibility according to the audience, enable only appropriate sharing channels and review exposed data. Finally, select post-purchase removal behavior through testing rather than assumption. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.