WooCommerce categories and tags give a chatbot structured signals for product discovery, recommendations, and support. Categories usually represent the store’s primary product hierarchy, while tags describe additional attributes or relationships that can cut across that hierarchy. A chatbot can use both taxonomies to narrow catalog queries, build useful follow-up questions, and return links to filtered product listings.
Use categories for primary product intent
Categories are generally the best starting point when a shopper expresses a broad need such as “running shoes,” “laptop bags,” or “organic coffee.” They provide a stable navigation structure and commonly map to customer-facing landing pages.
For example, a chatbot can translate the request “Show me women’s waterproof jackets” into a category constraint, then ask for missing criteria such as size, color, or price range. The category should be identified by its WooCommerce term ID or a controlled slug rather than by blindly matching arbitrary text.
- Use parent categories for broad discovery.
- Use child categories when the shopper has specified a more precise product type.
- Use category descriptions and curated metadata to explain the scope of a category.
- Do not assume that a category name is unique across every store or language.
Use tags for cross-category attributes
Tags are useful when a property applies to products in several categories. Examples include new-arrival, best-seller, vegan, travel-friendly, or limited-edition. A shopper asking for “vegan products under $50” may need both a tag-based constraint and a price filter.
Tags should not replace structured product attributes. Color, size, material, and technical specifications are usually better represented with global WooCommerce attributes because attributes support variations and more consistent filtering. Tags work best for editorial labels, campaigns, use cases, and merchandising groupings.
Map natural language to controlled terms
A production chatbot should maintain a taxonomy map rather than creating a new term every time a customer uses a synonym. For example, “trainers,” “sneakers,” and “gym shoes” may all map to the same category or product attribute, depending on the store’s catalog model.
A term map can include the public label, slug, taxonomy, term ID, synonyms, and whether the term is allowed as a filter:
{
"label": "Waterproof jackets",
"taxonomy": "product_cat",
"term_id": 42,
"slug": "waterproof-jackets",
"synonyms": ["rain jackets", "water-resistant coats"],
"filterable": true
}Resolve the customer’s wording against this controlled list before calling the product search endpoint. If the match is ambiguous, ask a clarification question instead of selecting a category based only on string similarity.
Query products with category and tag constraints
WooCommerce’s REST API supports product queries using category and tag parameters. The exact parameters depend on the API version and the integration’s authentication model, but a typical request uses term IDs:
GET /wp-json/wc/v3/products?category=42&tag=17&per_page=12For a public storefront search, an agency may instead call a custom WordPress endpoint, a Store API endpoint, or an internal search service. Keep the taxonomy translation on the server where possible. This prevents clients from submitting arbitrary query parameters and gives the integration one place to enforce visibility, stock, pricing, and channel rules.
When combining constraints, define the expected behavior explicitly. A category and tag filter normally means “products matching both conditions.” Multiple category or tag IDs may be treated differently depending on the endpoint. Test whether the implementation applies an AND or OR relationship, and document that behavior for the chatbot team.
Build conversational filters incrementally
Do not require the shopper to specify every filter in the first message. A useful sequence is:
- Identify the product category or shopping goal.
- Apply a known tag or campaign label when the request includes one.
- Ask for the most valuable missing constraint, such as budget, size, or availability.
- Return a small result set with product names, prices, stock status, and links.
- Offer a precise refinement such as “Would you like waterproof options only?”
For example, “I need a gift for a cyclist” might map to a cycling-related category and a gift-oriented tag if the catalog supports both. The chatbot can then ask whether the customer wants accessories, apparel, or a specific price range. This is more reliable than returning every product whose description happens to contain the word “cyclist.”
Distinguish taxonomy filters from text search
Taxonomy filters should handle known catalog structure, while text search should handle product names, descriptions, SKUs, and unresolved phrases. Combining them can improve relevance: use a category constraint to establish scope, then use text search for a model name or feature.
For instance, “black waterproof hiking boots from Brand X” may require a category filter, an attribute filter for color, a feature or tag filter for waterproofing, and a brand constraint. If “waterproof” exists only in product descriptions, the chatbot should state that the match is text-based and may be less complete than a structured filter.
Account for term hierarchy and catalog governance
WooCommerce categories are hierarchical, but tags are not. A chatbot should know whether selecting a parent category includes products assigned only to child categories. This behavior can vary by search implementation, so agencies should verify it rather than assuming inheritance.
Taxonomy governance also matters. Establish rules for:
- Who can create, rename, merge, or delete terms.
- Which synonyms map to each term.
- Whether old slugs redirect to new category or tag URLs.
- Which terms are customer-facing and which are internal.
- How translated taxonomies are connected across languages.
When a term is renamed, preserve the term ID relationship where possible and update the chatbot’s cached labels and URL mappings. A deleted term should not remain available as a selectable filter in a long-lived conversation session.
Protect product visibility and pricing rules
Never treat taxonomy filtering as an authorization mechanism. A category or tag query must still pass through WooCommerce visibility rules and the store’s business logic. Exclude hidden, private, out-of-stock, restricted, or channel-specific products according to the store configuration.
For authenticated shoppers, apply customer-specific pricing and eligibility on the server. The chatbot should not expose internal tags such as wholesale-only, supplier-review, or clearance-calculation unless those labels are intentionally customer-facing.
Measure taxonomy-driven conversations
Track which terms are selected, rejected, or followed by a clarification question. Useful events include category resolution, tag resolution, zero-result searches, filter removal, product click-through, and conversion after a taxonomy-based recommendation.
Zero-result reports often reveal catalog problems rather than chatbot problems. A tag may be too narrowly applied, a category may contain outdated assignments, or the chatbot may be combining filters with an unintended AND relationship. Review these cases with the merchandising team and update the catalog or term map instead of adding more speculative synonyms.
Recommended implementation pattern
For agency projects, keep taxonomy resolution, product querying, and response formatting as separate services or modules. The resolver converts language into approved term IDs. The query layer applies WooCommerce and store-specific visibility rules. The response layer explains the active filters and provides product links.
Before launch, test parent and child categories, synonyms, renamed terms, multilingual labels, empty combinations, out-of-stock products, and conflicting filters. The chatbot should be able to say which category or tag it applied and give the customer a clear way to remove or change that filter.