Verdict up top: Shopify’s Translate & Adapt does one genuinely good thing. It lets you serve multiple languages on one domain instead of running a rat’s nest of TLDs, one per country. That’s the right instinct. But nearly every broken multilingual Shopify store I audit is broken in the same handful of ways, and the app makes some of those mistakes easy to walk into and hard to see. So: good starter tool, weak foundation for serious multilingual organic visibility at scale.
Let me be fair before I get critical. The alternative most people came from was worse. Separate .nl, .be, .de domains means splitting your authority across three or four properties, maintaining three or four stores, and managing hreflang between domains anyway. One domain with language subpaths is cleaner, cheaper, and consolidates signals where you want them. Translate & Adapt gets you there without a developer. For a store touching one or two markets, that’s a perfectly sensible place to start.
Shopify sets the rules, you play inside them
It helps to remember what you’re actually building on. Shopify launched in 2006 and has grown into one of the largest commerce platforms in the world, powering millions of live storefronts and well over a trillion dollars in cumulative merchant sales. That scale matters for multilingual work, because Shopify’s conventions are inherited, not chosen. The URL structure, the way languages attach to a store, the hreflang Shopify emits on your behalf, all of it comes with the platform. Translate & Adapt lives inside those constraints, and a good chunk of the failures below come from people fighting them instead of working with them.
The problem is that “sensible place to start” and “done” are not the same sentence, and the app quietly encourages people to confuse them.
The failures I actually see
Here’s what lands on my desk, ordered by how much damage it does.
| Priority | What’s broken | Why it happens | What it costs you |
| 1 | URL handles left in the primary language | The app can translate handles now, but the feature is recent and the field is easy to miss. Older stores never had it, so the handles were never filled in. | Localised pages sit on /nl/collections/running-sneakers instead of a translated slug. Weaker relevance signals and a dead giveaway the translation is skin-deep. |
| 2 | Too many near-identical language variants live | “More languages must be better.” So NL, NL-BE and a phantom NL-EU all go live at once. | Cannibalisation between variants that say almost the same thing, plus an invalid region code doing nothing but diluting. |
| 3 | hreflang pointing at pages that don’t exist | Shopify auto-generates hreflang and sitemaps for published languages. People publish only some pages in the second language, so live pages carry hreflang references to translated URLs that were never published. | Google follows the reference, finds nothing, and loses confidence in your whole language-mapping. The tags meant to help end up as noise. |
| 4 | Canonical inconsistencies | Translated variants pointing canonicals back at the primary, or at each other, in ways nobody intended. | You tell Google the translated page isn’t the one to index. Then wonder why it doesn’t rank in that market. |
| 5 | Incomplete content coverage | Meta fields, theme strings, filters, tags and third-party app content left untranslated because the app can’t reach some of them. | A page that’s 80% Dutch and 20% English. Feels unfinished because it is. |
Notice the pattern. Only the last one is really about the app’s reach. The rest are configuration, and configuration is where the app gives you just enough rope.
Fixing the handles: it’s in there, but it wasn’t always
Here’s a thing people get wrong: they assume the app can’t translate URL handles at all. It can. But there’s a reason so many stores have English slugs sitting under Dutch content: handle translation only rolled out in early 2023, as a beta, and at first it only covered products, not pages, collections or blog posts. Before that, the handle stayed identical across every language whether you liked it or not. So if your store was set up before then, no amount of auto-translating ever touched those slugs, and they’re very likely still sitting there in your primary language waiting for someone to notice.
When you do translate a handle, the app behaves well. According to Shopify’s own documentation, the sitemap updates to include the translated URL handles, and redirects are created from the default-language URLs to the translated ones. That automatic 301 is a genuinely nice touch, because handle changes on an indexed page normally strand the old URL unless you remember to redirect it yourself.
The click path
Go check your own store:
- Apps > Translate & Adapt
- Select the language you’re translating
- Filter to URL handles (the search and filter controls let you isolate them, instead of scrolling every resource)
- Fill in the translated slug so /nl/collections/running-sneakers becomes /nl/collections/hardloopschoenen
- Save
For anything past a handful of pages, doing this by hand is a slog. The scalable route is the Translations CSV export under Settings > Languages, edit the handles there, reimport. Same result, minus the repetitive stress injury.
What it won’t do (and why one of those doesn’t matter)
One thing people flag as a limit that I don’t: the path segment itself can’t be translated. A handle like /products/en-ca/shoes becomes /products/es-mx/zapatos, but the word products stays products. Don’t lose sleep over it. Every Shopify store on earth runs /products/, /collections/, /pages/ and /blogs/news/, Google has indexed those patterns since forever, and no Dutch shopper has ever abandoned a sneaker purchase because the slug prefix was English. It’s a cosmetic quirk, not an SEO problem. The limit that does matter is the next one.
The one that matters is that handles are per language, not per market. You can’t customise a URL handle for a single market; the translation applies across every market where that language is visible. If your strategy needed market-specific paths, this isn’t your tool.
The language trap, specifically
This one deserves its own paragraph because I see it constantly and it’s the clearest example of “more feels safer” being wrong.
Say you’re selling sneakers into the Netherlands and Belgium. You reason that Flemish is different enough to warrant its own variant, then add a European catch-all for good measure. Three Dutch variants go live. Two of them are 95% identical, and the third, nl-EU, isn’t a valid hreflang region at all. Region codes are countries, not continents.
The fix is boring, which is exactly why people skip it:
- nl as your base. This covers Dutch speakers by default.
- nl-BE only if the Belgian content genuinely differs. Pricing, legal text, spelling and word choice where it actually diverges. A Belgian might search “baskets,” a Dutch shopper “sneakers,” and if that difference shows up in your content, fine, earn the variant. If your Belgian page is a carbon copy of your Dutch one, you don’t need it, and adding it just gives Google two near-duplicates to referee.
- Drop nl-EU entirely. It does nothing. It has never done anything.
One good variant beats three anxious ones. Every time.
Where the app itself hits a ceiling
Strip away the self-inflicted wounds and there’s still a real limit worth naming, because this is the part people miss when they’re deciding whether to grow into the tool or out of it.
Translate & Adapt is a content-translation layer. It is not a full localisation and international-SEO layer. The language-not-market handle model, the content types it flat-out can’t reach (collection filters, tags, product images, Shopify Forms, and third-party app content that isn’t a Shopify translatable resource), and the hreflang and canonical behaviour you can’t fully steer all add up to the same conclusion. It handles the visible text well and leaves the plumbing to you. For one or two markets, you can manage that plumbing by hand. At five, ten, fifteen locales, hand-managing it is a second job, and this is where teams start looking at dedicated platforms like Weglot and similar tools built for that scale. Not because Shopify’s app is bad, but because it was never trying to be that.
The caveat that matters most
Shopify actively updates this app, and has signalled that fuller URL localisation is on its radar. Handle behaviour, hreflang output and canonical handling have all shifted over past releases and may shift again. The handle-translation feature I just walked you through is itself proof of that, it didn’t exist a couple of years ago. So before you make a migration decision off the back of this article, open your own admin and confirm what’s actually editable for your store today. Don’t take my snapshot, or anyone’s, as gospel on software that moves.
So, keep it or leave it?
Keep it if you’re serving one or two markets and you’re willing to do the config properly. Translate the handles, prune the variants, finish the hreflang, check your canonicals, and translate everything and not just the body copy. Do that and it holds up fine.
Leave it when the plumbing becomes the job. The moment you’re fighting the tool to do things it was never built to do, you’ve outgrown it, and that’s not a failure of the app. That’s you succeeding into a bigger problem.
The tool isn’t the thing that breaks. The assumption that installing it finished the work is.
