Everything Shopify store owners get wrong with Translate & Adapt (and the one important thing they don’t)

Let’s start with the one thing Translate & Adapt genuinely gets right, because it’s the reason to use it at all. It serves multiple languages from a single domain. No fragmented .be, .nl and .de TLDs each fighting for their own authority, no duplicate stores to keep in sync. One domain, subfolders per market, all the link equity pooling in one place.

Shopify sets the rules, you play inside them

That is the correct architecture for the overwhelming majority of stores, and Shopify makes it the default. The catch is that Shopify also decides how that architecture behaves, and you only get to play inside those rules. Most of the problems I’m called in to fix start when someone assumes installing the app was the same as finishing the job.

The failures I actually see

When a multilingual Shopify store underperforms, it’s almost never the engine. It’s the configuration sitting on top of it. Three issues account for nearly everything:

Untranslated URL handles. The visible copy is translated, but the URL slug is still English, or worse, still a random Shopify handle. To a search engine the page reads as half-localised, and the market it’s meant to serve never fully trusts it.

Too many language variants. This is the big one, and it deserves its own section below. Stores add every plausible locale “to be safe”, and quietly cannibalise themselves.

Broken hreflang pointers. Variants reference each other incorrectly, or point at pages that no longer exist. Google can’t build a clean cluster, so it picks a winner for you, and it rarely picks the one you wanted.

Fixing the handles: it’s in there, but it wasn’t always

Here’s the one thing most people don’t know: handle translation exists in Translate & Adapt. You can localise the slug per market. The reason so many stores never do it is timing, not capability.

Stores set up before early 2023 predate the feature being obvious, so the habit never formed. The English handle became the permanent handle, and nobody went back. If that’s you, the fix isn’t manual page-by-page editing. Export your content, translate the handles in bulk, and re-import with a CSV. It’s the difference between an afternoon and a quarter.

The tool isn’t the thing that breaks. The assumption that installing it finished the work is.

The language trap, specifically

Now the expensive mistake. Faced with a Dutch-speaking audience across the Netherlands, Belgium and the wider EU, the instinct is to create a variant for each: nl, nl-BE, nl-EU. It feels thorough. It’s actually three near-identical pages competing for the same queries, splitting signals and confusing Google about which one to rank.

Add a variant only when it earns its place with genuinely differentiated content, pricing or shipping. Otherwise you’re not covering more ground, you’re diluting the ground you already own.

Variant	Differentiated?	Verdict
nl	Core market, full catalogue	Keep
nl-BE	Own pricing, shipping, BTW	Keep, if real
nl-EU	Duplicate of nl	Drop

One good variant beats three anxious ones. Every time.

Where the app itself hits a ceiling

To be fair to the tool, there’s a point where the problem stops being your configuration and starts being the app’s limits. Translate & Adapt handles core content well, but it thins out around the edges: third-party app content, collection filters, and image metadata often slip through untranslated.

If you’re hitting those walls, that’s not failure. It usually means you’ve outgrown a plug-in and into a real localisation workflow, with proper translation memory and coverage of everything the app can’t reach.

So, keep it or leave it?

Keep it, for almost everyone. For a store that wants many languages on one domain without running a localisation stack, Translate & Adapt is the right default and does the hard part well. Just treat installing it as the start of the work: translate your handles, be ruthless about variants, and check your hreflang cluster is actually clean.

Leave it only when you’ve genuinely outgrown it, when third-party content, filters and metadata matter enough that the ceiling is costing you real revenue. Reaching that point isn’t a failure of the tool. It’s a sign you’re winning.