Meilisearch synonyms and stop words: when to use each

Synonyms tell Meilisearch that two different words mean the same thing. Stop words tell Meilisearch to ignore certain words entirely. They solve adjacent but distinct problems — and most teams use one when they should be using the other.

The 30-second answer

• Use synonyms when users type one word but you index another — brand variations, abbreviations, plurals that don't naturally match, technical aliases.
• Use stop words when filler words ("a", "the", "of") are diluting search relevance and you want them ignored entirely.
• Almost everyone needs synonyms. Only some teams need stop words.

Synonyms: configuring word equivalence

Synonyms in Meilisearch are configured as a JSON object where each key is a word and the value is the list of words it's equivalent to. Equivalences are bidirectional unless you configure one-way explicitly.

PATCH /indexes/{uid}/settings/synonyms
{
  "tv": ["television", "telly"],
  "television": ["tv", "telly"],
  "telly": ["tv", "television"]
}

A search for "tv" now also matches documents containing "television" or "telly", and vice versa.

One-way synonyms

Sometimes you want a search for one word to match another, but not the reverse. Common case: a typo correction or an abbreviation expansion.

{
  "iphone": ["iphone 15 pro max"],
  "kg": ["kilogram", "kilograms"]
}

A search for "iphone" matches documents about "iphone 15 pro max", but searching for "iphone 15 pro max" doesn't suddenly match every "iphone" document. (To make it bidirectional, add the reverse mapping.)

Real-world synonym patterns

E-commerce

{
  "tv": ["television"],
  "iphone": ["apple phone", "iphone 15"],
  "shoes": ["sneakers", "trainers", "footwear"],
  "couch": ["sofa", "settee"]
}

Documentation search

{
  "k8s": ["kubernetes"],
  "psql": ["postgresql", "postgres"],
  "node": ["nodejs", "node.js"],
  "ts": ["typescript"]
}

Multi-language brand variations

{
  "color": ["colour"],
  "organize": ["organise"],
  "favorite": ["favourite"]
}

Stop words: telling Meilisearch to ignore filler

Stop words are common words that carry little meaning ("the", "a", "and", "of") but show up in nearly every document. Meilisearch can be told to ignore them entirely:

PATCH /indexes/{uid}/settings/stop-words
[
  "the",
  "a",
  "an",
  "and",
  "or",
  "of",
  "in",
  "on",
  "at",
  "to"
]

After this, a search for "lord of the rings" effectively becomes a search for "lord rings" — the engine treats "of" and "the" as if they weren't there. This is a relevance tradeoff: it speeds up matching and improves relevance for content-heavy searches, but it breaks any query where the stop word is meaningful (e.g. "to be or not to be").

When to use stop words

• News / blog content with verbose titles where filler words dominate.
• Recipes ("a dash of salt", "the best cookie") where users want to match content words.
• Long-form documentation where common words appear in every page.

When NOT to use stop words

• Short titles (product names, song titles) where every word matters.
• Quoted phrases where exact word order is part of the meaning.
• Code search — programming languages have their own stop-word-like tokens that you usually want to keep.

The default stop word list (there isn't one)

Meilisearch ships with an empty stop word list. This is intentional — the right list depends entirely on your content. If you want a starter list for English, the standard NLP one (~200 words) is a reasonable starting point: a, about, above, after, again, against, all, am, an, and, any, are, as, at, be, because, been, before…

Synonyms vs stop words: the decision matrix

Operational tips

• Both are reindex-on-update. Changing synonyms or stop words triggers a reindex of the affected index. Quick on small indexes, ~minutes on large ones.
• Track them in version control. Both lists are configuration — keep them in a Git repo so changes are reviewable.
• Iterate on real queries. Pull a sample of zero-result queries from your search analytics; many of them point at missing synonyms.

FAQ

Do I need to add both directions of every synonym?

For bidirectional equivalence, yes — the easiest pattern is to list every synonym group with all variations as keys and the others as values. A small Python script generates this from a flat list of equivalence groups.

How many synonyms can I have?

Meilisearch supports up to 1000 synonym groups per index by default. For most teams, 50–200 is plenty. Beyond that you're usually solving the wrong problem (e.g. should be using a thesaurus or query expansion at the application layer).

Are stop words case-sensitive?

No. Both stop words and synonyms are matched case-insensitively after Meilisearch normalises them.

Can AdminDex help configure these?

Yes — AdminDex's settings editor has a JSON editor for synonyms with inline validation + a "Beautify" button, and a tag-style input for stop words (Tab/Enter/comma to commit each word). Both with help drawers explaining when to use which.