Multilingual Stores: Which Translation Plugins Work With AI Search?

If your WordPress or WooCommerce store runs in 2+ languages, AI search behavior depends entirely on which translation plugin you use. Some pair well with Queryra out of the box. Others mix languages in search results until we ship dedicated support. This post is the honest status — what works today, what's coming, and what to do if you can't wait.

A store owner installed Queryra last week and uninstalled three days later. The deactivation note said:

> *I have a store with two languages and do not want to receive mixed results.*

That's a fair complaint. The store ran on WPML — Bulgarian and English. Queryra indexed every translated post as a separate record (which is correct), but didn't filter results by the visitor's active language. So someone shopping in Bulgarian saw English results sprinkled in. Useless, slightly insulting, and an instant uninstall.

We could have hidden behind "multilingual support is on the roadmap." Instead — this post. If you run a store in two or more languages, you deserve a clear answer before you install.

When a French shopper types *crème hydratante* and gets back a mix of French moisturizers and English ones, three things happen:

• The results feel sloppy — the kind of thing you'd expect from a hobby site, not a store you're about to give your card to
• The shopper has to mentally filter the wrong language out, which is friction nobody signed up for
• Trust drops. If the search can't speak my language, what else doesn't work?

For a store owner running localized SEO and customer service, this is a dealbreaker. Single-language queries on a single-language store work great with AI. The trouble starts the moment you add a second language to the same WordPress install.

Before the status table, a quick technical note — because the answer depends on how each plugin stores translations.

Model A: Separate posts (WPML, Polylang)

Each translated version is a separate row in wp_posts with its own ID. So a product with English, French, and German has three IDs in the database. Plugins link them via a translation group ID in a helper table.

For Queryra, this means three records per product, one per language. Without a language filter at search time, the AI sees them as three different things and may return any of them.

Model B: One post with translations stored separately (TranslatePress, Weglot)

One row in wp_posts. The translations live in a custom table (TranslatePress) or a JavaScript layer (Weglot), and the right version is rendered based on URL or visitor language.

For Queryra, this means each language version comes through with the right content already attached — the plugin handles language selection at render time, before the data hits us.

The difference is everything for AI search compatibility.

Here's where each plugin stands:

If you're shopping for a translation plugin and AI search matters, TranslatePress and Weglot are both safe picks today. They handle multilingual stores differently (TranslatePress duplicates posts in WordPress, Weglot stores translations on its cloud), but both pair cleanly with Queryra. More on Weglot specifically.

When a visitor lands on /en/ and types *crème hydratante* in French, Queryra returns the English moisturizers — not the French ones. Why? The visitor is browsing the English version of your store. Switching them to French results would yank them off the page they're shopping on.

The rule: the active URL prefix wins, not the query language.

• Visitor on /en/ → English results, regardless of how the query was typed
• Visitor on /pl/ → Polish results, even if they search *écharpe rouge*
• Visitor on /de/ → German results, no exceptions
• Visitor on /bg/ → Bulgarian results — even if a French shopper accidentally lands there

This is the right behavior for stores. A French-speaking visitor on the English site is probably checking prices, shipping, or product specs — not signaling they want to switch languages mid-flow. They want their query understood (the embedding model handles 50+ languages out of the box) but the results need to stay where they are.

If you *want* to redirect visitors to their language version, that's a navigation concern — handled by the translation plugin's language switcher or your theme's geolocation logic, not by search.

Five-minute version:

1. Pretty Permalinks must be on — Settings → Permalinks → anything except "Plain." TranslatePress uses URL-based language switching (/fr/, /de/) which needs pretty permalinks.
2. Add languages in TranslatePress — Settings → TranslatePress → set default + translation languages. Translate posts and products in the front-end editor.
3. Sync your records to Queryra — Dashboard → Sync. For a 100-post store with 3 languages you'll see 300 records. Each language version is treated as its own searchable item, which is exactly what you want.
4. Test from the front-end — open in incognito, switch language with the TranslatePress switcher, run a search. Results should appear in the active language only. If you see mixed results, re-sync once more — TranslatePress sometimes adds slugs after the first sync.

For the full guide with FAQ and edge cases: TranslatePress integration docs.

If you're already on WPML or Polylang and can't switch, you have two options.

Option 1 — Wait 2-3 weeks. We're actively working on language detection at sync (using apply_filters('wpml_post_language_details') for WPML and pll_get_post_language() for Polylang) plus a lang filter at search time. When ready, you flip a toggle and language-aware results just work. No re-sync, no setup. Roadmap pages: WPML, Polylang.

Option 2 — REST API with custom language tagging (today). If you have a developer, this works now: send each record to Queryra with a language field in the metadata, and at search time pass ?lang=xx to filter. This bypasses the plugin entirely. Implementation guide: PHP integration.

Which option makes sense depends on whether "two weeks" is acceptable for your launch timeline. If you're in a soft pre-launch phase, waiting is cheaper. If you're already live and bleeding signups, the REST API workaround unblocks you immediately.

On Weglot: unlike WPML and Polylang, Weglot already works without waiting — see the Weglot integration guide for the recommended setup.

A few "workarounds" we've seen suggested elsewhere — none of them work well:

• "Just sync only one language and hide the rest from search" — sometimes recommended, but breaks the second language entirely. Customers in the hidden language get zero results.
• "Use language as a synonym list" — keyword-search trick that doesn't translate to semantic AI. The embedding model handles meaning, not literal substitution.
• "Run two Queryra accounts, one per language" — technically possible, doubles your record limit cost, and the language switch from your front-end has to swap API keys at runtime. Brittle and expensive.

The right answer is language-aware filtering at the API level. That's the work in progress.

Concrete dates, not "soon":

• WPML support — 2-3 weeks. Detection of active WPML license, per-language indexing tags, and a language filter on search. Targets WPML Multilingual Blog, CMS, and Agency tiers.
• Polylang support — 2-3 weeks. Same approach, using Polylang's hooks. Free and Pro tiers both supported.
• Magento module — 6-8 weeks. Native module with multi-store and multi-language support out of the box (since Magento has both built-in).

Weglot already works today — Queryra's multilingual parser handles queries natively, regardless of how Weglot renders translations. See the Weglot integration guide for the recommended setup.

The feature work tracks the Queryra status page on GitHub — if you want to follow along, that's the source of truth.

• Single-language store — AI search works in any language. No special setup. The 50+ language embedding model handles queries in any tongue automatically.
• TranslatePress / Weglot (multilingual store) — both work today. TranslatePress duplicates posts; Weglot keeps translations on its cloud. Either pairs cleanly with Queryra.
• WPML / Polylang (multilingual store) — currently mixes languages. Native support shipping in 2-3 weeks.
• Developer with WPML or Polylang who can't wait — use the REST API with custom language metadata, works today.

If you tried Queryra on a multilingual store and uninstalled, this is on us. We're shipping the fix.