Searchable Attributes: The Most Important Setting You’ll Configure

For a WooCommerce search experience, few settings have as much influence as searchableAttributes. This setting tells Algolia which product fields can match a query and, just as importantly, establishes the priority of those fields.

If a shopper searches for a product name, SKU, category, or brand, the result quality depends on whether that value is indexed as searchable. Adding more fields is not automatically better. A broad, poorly ordered configuration can make descriptions outrank product names or cause weak matches to appear above highly relevant products.

What searchableAttributes controls

Algolia evaluates the fields listed in searchableAttributes when matching text queries. The order of the attributes affects relevance: an attribute listed earlier generally has more importance than an attribute listed later when other ranking criteria are comparable.

For example, this configuration gives product names the highest priority, followed by SKU, categories, brand, and descriptive copy:

const settings = {
  searchableAttributes: [
    'name',
    'sku',
    'categories',
    'brand',
    'short_description'
  ]
};

await index.setSettings(settings);

The exact attribute names depend on the records created by your WooCommerce integration. One connector may index name, while another may use post_title or a nested product object. Always inspect a real index record before configuring this setting.

A practical attribute order for WooCommerce

There is no universal order, but the following structure is a useful starting point for many catalogs:

Product name: The primary field shoppers expect to match.
SKU or model number: Essential for trade, wholesale, parts, and repeat purchasing workflows.
Brand: Important when shoppers search by manufacturer or label.
Category and product type: Useful for broad searches such as “running shoes” or “wireless keyboard.”
Curated search keywords: Synonyms, alternate names, and merchandising terms that are intentionally maintained.
Short description: Helpful for distinctive product features, but usually too broad to place near the top.
Long description: Include only when full-text product discovery is a deliberate requirement.

For a B2B store selling replacement components, SKU and manufacturer part number may deserve a position immediately after the product name. For a fashion store, brand, collection, color, and material may be more valuable. The order should reflect how customers identify products, not how fields happen to appear in the WordPress editor.

Why adding every field can reduce relevance

Descriptions often contain generic terms such as “premium,” “high quality,” “professional,” or “free shipping.” If long descriptions are searchable, a query containing one of those terms can match hundreds of products. Those matches may be technically valid but commercially unhelpful.

A focused configuration gives Algolia fewer opportunities to create weak matches:

const settings = {
  searchableAttributes: [
    'name',
    'sku',
    'brand',
    'categories',
    'search_keywords',
    'unordered(short_description)'
  ]
};

The unordered() modifier is useful for text where the presence of matching terms matters more than their position within the field. It can prevent the order of words in a long description from receiving unnecessary importance. Use it deliberately and validate the results against real searches.

Searchable attributes are not facets

A field can be searchable, facetable, or both. These are separate concerns.

Searchable: The field can match a free-text query.
Facetable: The field can be used for filters, refinement menus, or counts.
Displayed: The field is returned in search results.

For example, brand may belong in searchableAttributes so a query for “Acme” finds products, and in attributesForFaceting so shoppers can filter by Acme. Adding a field to one setting does not automatically add it to the others.

const settings = {
  searchableAttributes: [
    'name',
    'sku',
    'brand',
    'categories'
  ],
  attributesForFaceting: [
    'brand',
    'categories',
    'price_range'
  ]
};

Handling SKU and exact product identification

SKU searches are often high-intent. A customer who enters ABC-123 usually wants one product, not a collection of products whose descriptions happen to contain fragments of that value.

Keep SKU searchable, but test how it interacts with your catalog’s ranking configuration. If the integration creates multiple SKU-like fields, choose the canonical value rather than indexing every internal identifier. For stores with separate parent and variation records, decide whether shoppers should find the parent product, the individual variation, or both.

When exact lookup is important, consider adding a dedicated exact-match workflow in the application rather than trying to solve every case through attribute order alone. Searchable attributes determine where matching can occur; they do not replace a product identifier strategy.

Common WooCommerce implementation mistakes

Using WordPress field names without checking the index: The setting must reference Algolia record attributes, not necessarily database column names.
Indexing HTML descriptions as primary content: Strip presentation markup during indexing and avoid prioritizing verbose copy.
Putting categories above product names: This can make broad category terms dominate specific product searches.
Ignoring variation data: Size, color, and variation SKUs may be stored separately from the parent product.
Changing settings without re-testing merchandising: Search ranking rules, pinned results, and promoted products can make a change appear different across queries.
Assuming a reindex is always required: Changing index settings through Algolia updates the index configuration, but changes to the actual searchable values require the records to be synchronized.

A disciplined configuration workflow

Inspect representative records. Review simple products, variable products, products with missing descriptions, and products with multiple categories.
List customer vocabulary. Use site-search reports, support tickets, product data, and sales-team feedback to identify names, SKUs, brands, and common synonyms.
Start with a small attribute set. Begin with high-signal fields rather than indexing every text field.
Order fields by customer intent. Put the fields that identify a product most reliably first.
Test realistic queries. Include exact product names, partial names, SKUs, brands, categories, feature terms, misspellings, and empty-result searches.
Compare before and after results. Measure the first useful result, zero-result rate, click-through rate, and conversion from search.
Document the decision. Record why each attribute is included and who owns the source data, especially when several teams manage WooCommerce custom fields.

Questions to answer before going live

Do product names match before generic description text?
Can a shopper find a product by its SKU or manufacturer part number?
Are brand and category terms searchable without making them overpower product names?
Are variation attributes present in the records users actually search?
Are internal notes, shipping copy, and boilerplate excluded?
Do the configured attribute names match the production index rather than a staging schema?
Have the settings been tested with the same ranking rules and filters used by the storefront?

For agencies, searchableAttributes should be treated as part of the store’s search contract. Define it alongside the index schema, WooCommerce data mapping, facet configuration, and relevance test cases so that a connector update or custom-field change does not silently alter what shoppers can find.

Table of contents :