Content Localization for Shopify: The Translate Apps Compared

Most Shopify merchants who install a translation app pick one of four names. Translate and Adapt, which Shopify built itself. Weglot, the most visible paid option in the Shopify ecosystem. Langify, which has been around long enough that a meaningful share of older stores still run it. GTranslate, which sits at the cheap end of the market and covers a wide range of quality depending on tier. The comparison content online tends to stop at feature checklists and pricing tables, which is exactly the part of the decision that does not matter most. What matters is how each app hooks into the Shopify storefront, how Google sees the localized pages, and what happens to the store when the catalog grows to five languages and a hundred thousand SKUs. The shopify translation app decision is at heart a platform architecture decision, and the four options sit in three genuinely different architectural camps.

The three architectures behind every translation app

Before comparing the four, the distinction between the three underlying approaches needs to be clear, because the app's architecture determines almost everything about its SEO behaviour, its performance footprint, and its long-term maintenance cost. The first approach is native, where translations live as first-class data inside the Shopify platform via the Translations API. The second is proxy-based, where a separate service fronts the localized version of the storefront, fetches pages from origin, swaps strings, and serves the result. The third is duplicate-content or parameter-based, where the localized version of a page exists at a different URL, often with a query parameter such as ?lang=fr or on a subdomain, with translation content stored in the app's own database.

Native means the Liquid template renders the translated string at request time, with the locale resolved by Shopify Markets. There is no separate URL, no separate HTML document, no JavaScript layer that rewrites text after the page loads. The server emits the French version of the page at the French URL, the English version at the English URL, and hreflang tags that map them together. Proxy means there is a real separate service that sits in front of the store, sometimes on a subdomain such as fr.yourdomain.com, sometimes transparently integrated with Shopify Markets subfolders. Proxies are SEO-valid when hreflang is correct, but they add a network hop and a dependency, and they can scale expensively on high-traffic stores. Duplicate-content means the localized page is a second URL that the app controls, often with the translation happening partly server-side and partly via a JavaScript switcher. Google has historically been suspicious of this pattern, not because it is inherently wrong, but because a poorly-configured implementation looks identical to cloaking or to low-effort parameter-duplication.

Those three camps map onto the four apps imperfectly, and understanding the overlap is the point of this article.

Translate and Adapt, the native option

Translate and Adapt is the app Shopify ships itself, free on the base tier with two languages and a paid upgrade that unlocks unlimited locales with AI pre-translation. It is the only shopify translate and adapt setup that is fully integrated with Shopify Markets, because Shopify built both. The mechanics are simple. Translations are stored as resources attached to the primary object, a product, a collection, a page, a metafield, a theme setting. Liquid, which is the templating engine that renders every Shopify storefront, resolves the current locale at request time and substitutes the translated value. The HTML that leaves the server is already translated. There is no JavaScript layer, no proxy, no separate URL that the app manages. The locale routing comes from Markets, which can serve translations on subfolders such as /fr or /de on the primary domain, on country-specific top-level domains, or on subdomains, with hreflang tags emitted automatically.

The SEO behaviour is the cleanest of the four. Googlebot fetches the localized URL, receives server-rendered translated HTML, sees correct hreflang, and indexes the page in the same way it indexes the English version. There is no client-side dependency, no risk of Google seeing one version while users see another, no script to block. Page weight is unaffected because nothing is injected. Core Web Vitals on localized pages mirror the primary language version.

The limits of Translate and Adapt are workflow and coverage. The editor is functional, with AI pre-fill, inline editing, and CSV export and import, but it lacks a translation memory, a glossary, role-based permissions, and an integrated marketplace of professional translators. A solo merchant or a small team managing translations in-house will find it adequate. A brand with three translators, a style guide, and a QA process will outgrow it quickly. Coverage gaps appear around third-party app blocks and theme strings that have not registered their schemas with the Translations API, which means a store that leans heavily on app-driven content sections may find pockets that Translate and Adapt cannot reach. For the majority of DTC brands with small to mid catalogs and two or three languages, it is the right default.

Weglot, the workflow-heavy paid option

Weglot has been the most marketed translation solution in the Shopify ecosystem for years, and its reputation is built less on technical elegance than on workflow. The editor is the best of the four, with an in-context visual interface, a translation memory that reuses prior decisions, a glossary for brand terms, role-based access for internal reviewers, and an integrated marketplace for ordering professional translations. For a merchant running a real localization program with multiple translators and a QA pass, the weglot shopify workflow is a legitimate productivity tool.

The architecture is more nuanced than the legacy reputation suggests. Weglot started as a pure JavaScript overlay on non-Shopify platforms and as a subdomain proxy on Shopify, with localized content served from fr.domain.com or similar. The current Shopify plan has shifted. Weglot now integrates with Shopify Markets where possible, writing translations into the Translations API so that Liquid can render them server-side, and using its own layer only for content that cannot be registered, such as certain third-party app strings or dynamically-loaded blocks. On a Markets-enabled store, the shopify weglot vs langify comparison narrows on the SEO axis, because both can produce server-rendered translations on Markets subfolders.

The cost of Weglot scales with word count and language count, which becomes a real line item on stores with large catalogs. A five-language rollout across a catalog of 50,000 products with rich descriptions can push monthly cost into three or four figures, which is rational if the workflow pays for itself in translator productivity and which is not if the translations are mostly AI-generated and untouched. Stores that run Weglot purely for the machine-translation pre-fill and never use the glossary, memory, or marketplace are paying for features they do not need.

Performance impact on the Shopify plan is modest. The switcher script is small, the heavy lifting happens server-side, and the Markets integration avoids the round-trip cost of a true proxy. On older installs that still use the subdomain proxy, an extra DNS lookup and TLS handshake add latency on first request, and the origin fetch adds a server hop on every request. Stores that inherited a Weglot install from a previous agency should check which mode they are on.

Langify, the long-tail legacy option

Langify predates the Shopify Translations API. It was built in the era when Shopify had no native localization layer, and it solved the problem by storing translations in its own database and exposing them via URL parameters or a subdomain configured by the merchant. Current versions of Langify can write to the Translations API and integrate more cleanly with Markets, but a substantial population of Langify installs still run the legacy parameter-based approach, because the migration path was not obvious and the merchant never had a reason to change something that appeared to work.

The legacy approach is where the SEO risk lives. Parameter-based switching, where the localized version lives at /product-handle?lang=fr, creates a second URL that the app controls. If the switcher rewrites HTML on the client side after page load, Googlebot may see the English version during an early crawl and the French version only on a later render pass, which looks like cloaking. If the canonical tag on the French URL points back to the English URL, Google will consolidate the two and the French version will not rank independently. If hreflang is missing or incorrect, Google cannot tell which URL serves which audience and picks one, usually the English version, to show everywhere. None of these failure modes are Langify's fault in a strict sense. They are configuration failures that the app allows. But they happen often enough that shopify localization app audits frequently surface Langify installs as the source of unexplained ranking losses on localized pages.

The editor is workmanlike. Auto-translation, manual editing, image translation, metafield translation. Pricing is cheaper than Weglot, which is why Langify has survived. For a legacy store with years of curated translations already in the Langify database, a migration to Translate and Adapt is non-trivial, and the calculus comes down to whether the SEO risk of the current setup outweighs the migration cost. For a new store, there is no reason to start on Langify.

GTranslate, the tiered option with a trap

GTranslate is the cheapest of the four and the one where the tier choice matters most, because the lower tiers and the higher tiers are architecturally different products that happen to share a brand. The lower tiers are a JavaScript-based client-side translation layer that injects a Google Translate widget into the storefront. The translations happen in the browser, after the page loads, and they are not visible to Googlebot in any useful way. The localized pages do not rank. The switcher adds forty to a hundred kilobytes of script and execution cost, which on mid-range Android hardware on a 4G connection is a measurable Core Web Vitals hit. For a merchant who just wants a switcher so that visitors can self-serve a rough translation, the lower tier is functional. For any SEO outcome, it is worthless.

The higher tiers of GTranslate are a subdirectory or subdomain proxy with server-rendered translations and hreflang emission. These tiers are architecturally closer to Weglot's legacy proxy mode. They produce indexable localized URLs, they emit hreflang, and they behave sensibly in search. They are also more expensive than the lower tiers by an order of magnitude, which removes the pricing advantage that drives most GTranslate installs in the first place. A merchant who has chosen GTranslate for the price and then upgrades to the proxy tier to fix the SEO is usually within a few dollars of the Weglot equivalent, at which point the workflow difference tips the decision.

How Google actually treats each approach

The SEO behaviour of a shopify translation app is not a feature on a checklist. It is the result of three mechanical properties. First, whether the translated content is present in the HTML returned by the server, or whether it arrives later via JavaScript. Server-rendered translations index faster and more reliably. Second, whether the localized URL is distinct from the primary-language URL, and whether hreflang correctly maps the two. Without hreflang, Google may show the wrong language version to the wrong audience, or consolidate the two URLs and rank only one. Third, whether the HTML returned to Googlebot matches the HTML rendered to users. When they diverge, Google treats the divergence as cloaking and applies ranking penalties or removes the pages from the index entirely.

Translate and Adapt is clean on all three. Weglot on the current Shopify plan with Markets integration is clean on all three. Weglot on the legacy subdomain proxy is clean on the first two and dependent on configuration on the third. Langify on the modern Translations API integration is clean on all three. Langify on the legacy parameter-based approach is dependent on configuration on all three, and the common failure modes are hreflang mistakes and switcher scripts that alter HTML in ways that Googlebot interprets as cloaking. GTranslate lower tiers fail the first criterion because translation happens client-side. GTranslate higher tiers pass all three.

Recommendation by merchant type

A DTC brand with a catalog under ten thousand SKUs and two or three target languages should default to Translate and Adapt. The native integration with Markets is the right architecture, the cost is zero or low, the SEO behaviour is clean, and the workflow limitations do not matter at that scale. A mid-market brand with three to five languages, an in-house or agency translation team, a style guide, and a QA process should choose Weglot, because the editor, glossary, and translation memory pay for themselves in translator productivity, provided the setup uses the Markets integration rather than the legacy proxy. A legacy store already running Langify with years of curated translations should audit hreflang, canonical tags, and the switcher behaviour before deciding. If the audit is clean and the Translations API integration is in place, staying is reasonable. If the audit finds canonicalization errors or cloaking signals, migrating to Translate and Adapt or Weglot is worth the cost. A small merchant with a catalog under a thousand products and a desire for a visitor-facing switcher with no SEO ambition can use GTranslate's lower tier, though Translate and Adapt's free tier covers the same ground more cleanly. An enterprise operation with an existing translation management system such as Lokalise, Phrase, or Smartling should bypass the app store entirely and integrate with the Translations API via a custom build, because none of the four apps is the right abstraction layer for that scale.

The localization decision is reversible but expensive to reverse. Translations live in the app that created them, and migrating a catalog of product descriptions and meta fields from one app's database to another, or from one app's proprietary format to the Translations API, is a real engineering project. Choosing the right architecture at the start is worth more than choosing the right workflow, because the architecture is what determines whether the SEO outcome is ever achievable in the first place.

Getting localization wrong is rarely visible until organic traffic from the target country fails to materialize six months after launch, by which point diagnosis is expensive and remediation requires rework. WitsCode has run localization audits across more than two hundred and fifty Shopify stores and can assess whether the current setup is earning the SEO value it is capable of. > Localization consultation.