How to Choose a Way to Translate Your Website
Pick the method by what you need from search and how much control you have over your platform. If you want other-language search traffic, choose a way that gives every language its own address: your platform's native multilingual feature, a plugin or app that writes language addresses, or a build-time kit. If you only want visitors already on your site to read it in their language, or you cannot change your platform, a script tag is the quickest option, with known limits.
The four routes
| Route | How the translated page is produced | Separate language addresses | Typical platforms |
|---|---|---|---|
| Platform plugin or app | The plugin or app writes translated pages or content into your platform | Yes | WordPress, Shopify |
| Script tag | A script replaces text in the visitor's browser | No | Any site where you can add one line |
| Build-time kit | Translated pages are written when you build your site | Yes | Static sites, Next.js, Nuxt, Astro |
| Platform's own feature | The platform's built-in multilingual tools | Usually yes | Several website builders: check yours |
All routes can share the same translations; they differ in how the translated page reaches the visitor.
Why separate addresses matter
Google recommends using different URLs for each language version of a page and describes country-code domains, subdomains and subdirectories as the common structures. Its hreflang documentation explains how to tell it about alternates, and says each version must list itself and all the others. A script that swaps text on the same address gives Google nothing to list in another language, and most search crawlers do not run the script reliably (how other engines treat scripts is something we mark as verify). Titles, descriptions, structured data, address slugs and sitemaps also cannot be translated for crawlers that skip the script. See client-side vs server-side translation and SEO.
A decision path
- Is search traffic in other languages a goal? If yes, rule out script-only methods and look at routes with real addresses.
- Is your platform WordPress or Shopify? Use the native route. For WordPress see how to make a WordPress site multilingual; for Shopify see our Shopify multilingual store guide.
- Do you build static pages or use Next.js, Nuxt or Astro? A build-time kit writes translated copies of your pages with no runtime call.
- Do you use a website builder with a built-in multilingual feature? Compare it against the rest: it may give real addresses without extra tools. See translating Wix, Squarespace and Webflow.
- Can you add only one line of code? A script tag works anywhere, and is the quickest way to test demand before investing in a deeper route.
What each route needs from you
- Plugin or app: admin access, a compatible theme (WordPress themes need to call
wp_head()for the plugin's head output), and a plan to handle caching plugins and CDNs. - Script tag: the ability to add one script line; no change to server HTML. Note that a strict content security policy may need adjusting.
- Build-time kit: a build pipeline and a developer.
- Platform feature: nothing extra, but check its URL, SEO and export options.
How LgTranslate fits
LgTranslate offers all of these routes, with different maturity. This is where things stand, as written in our own help centre:
- Script tag: available now; works on most platforms; no separate language addresses.
- WordPress plugin: available as a download from the dashboard; it copies published files to your own site and serves them first from your domain, and includes a part for language addresses, hreflang and a translated-pages sitemap that has its own tests but has not yet been run inside a real WordPress together with the core part. It is not in the WordPress.org directory yet.
- Shopify app: built and tested against a simulated Shopify; not in the Shopify App Store yet. Shopify keeps checkout, accounts and order pages for itself.
- Framework kits: written and tested offline; public packages to follow.
Whatever you pick, the same safety property applies: published translations are static, signed files, so a failure leaves your original text rather than a broken page. See what happens to translated pages in an outage.
Things to avoid
- Running two tools on the same page. They fight over the same text and add two switchers.
- Choosing a script route and expecting search traffic in other languages.
- Choosing by price alone: a cheap route that gives no language addresses can cost you the traffic you wanted.
- Redirecting visitors by language automatically. Google advises avoiding it.
Next step
Decide your goal in one sentence ("visitors on my site read in their language" or "customers find me in Spanish search"), follow the decision path above and test on one page. To try the route that fits, create a LgTranslate account and open the Install page, which lists your platform with the steps; the platforms page shows what is available now.
Key takeaways
- Separate language addresses are what search engines need; script-only routes do not give them.
- Use your platform's native route when there is one; use a build kit for static and framework sites.
- A script tag is the quickest way to start and to test demand, with stated SEO limits.
- Let one tool own the switcher, language URLs and hreflang.
Sources
- Managing multi-regional and multilingual sites – Google Search Central – different URLs per language version; URL structures; avoid automatic redirects (checked 2026-11-06)
- Localized versions of your pages – Google Search Central – hreflang and return links (checked 2026-11-06)
- Languages – Shopify Help Center – publishing languages on Shopify (checked 2026-11-06)
- Manage languages – Shopify Help Center – unique URLs per translated page on Shopify (checked 2026-11-06)
Frequently asked questions
Does a script tag give me translated pages in Google?
Generally not. A script that swaps text in the visitor's browser creates no new address for each language, and Google recommends different URLs per language version. It suits visitors who are already on your site; for search traffic in other languages use a method with real language addresses.
Which method is best for WordPress?
If search traffic in other languages matters, a method that creates real language addresses, such as the folder pattern /fr/, and outputs hreflang. If you only want visitors on your site to read it in their language, a script is quicker. Check how each handles your theme and caching.
Can I combine methods?
Sometimes, but only one tool should own the switcher, the language URLs and the hreflang links for a given page. Use a second method only for the parts the first does not reach.