Key takeaways
- The platform types are translation proxies, CMS-native multilingual plugins, headless CMS with localization, framework i18n modules and translation management systems.
- Hreflang only works when each version lists itself and every alternate, the pages link back to each other and the URLs are fully qualified. Platforms differ in how reliably they output that.
- AI translation suggestions speed up the work, but Google's spam policy names automated translation as an example of scaled content abuse when it is used to produce many pages without value for users, so review what you publish.
- Test any platform on three things before you commit: the hreflang it emits, which metadata it translates and who owns the translations if you leave.
What a multilingual platform has to do
A multilingual website platform needs three capabilities: publish a separate URL for each language, connect equivalent pages with hreflang, and let you edit translated content and metadata. AI translation helps draft the words. Your publishing system must still produce the correct pages and tags. Compare platforms by their rendered output, not their feature list.
The five types of platform
| Type | Hreflang | Localized metadata | AI translation suggestions | Main trade-off |
|---|---|---|---|---|
| Translation proxy or overlay (Weglot is a typical example) | Usually automatic | Often covered, including titles and descriptions | Built in, with an editor for review | Fast to launch on almost any site, but translations and URL handling depend on the vendor |
| CMS-native multilingual (WordPress with WPML or Polylang, Shopify Markets, Wix, Webflow) | Usually automatic | Per language, as the CMS and plugins allow | Built in or by add-on | Convenient for standard sites, limited when you need custom structures |
| Headless CMS with localization (Storyblok, Contentful, Sanity and similar) | Not output by the CMS. Your front end must do it | Field-level translation of any metadata you model | Through built-in features or integrations | Most flexible content model, more engineering work |
| Framework i18n modules (Nuxt i18n, next-intl, Astro i18n) | Generated from your route configuration | As complete as you build it | Not included. Add scripts or a service | Full control over URLs and markup, you maintain it |
| Translation management systems (Crowdin, Lokalise, Phrase, Smartling) | No. They supply translations to the other layers | Strings and fields you sync | Strong: suggestions, translation memory and glossaries | Not a website platform, so it needs one of the types above |
What correct hreflang looks like
Google accepts hreflang in the HTML head, in HTTP headers or in the sitemap, and treats them as equivalent, so there is no advantage in doing it twice. Whatever the platform, check the output against these rules from Google's documentation, plus one common practice.
- Each version lists itself and all the others. If two pages do not point at each other, Google ignores the tags.
- URLs are fully qualified, including https.
- Language codes follow ISO 639-1 and region codes follow ISO 3166-1 alpha-2. A country code on its own is invalid, and EU or UK are not valid region codes.
- An x-default entry names the fallback page for users whose language is not listed.
- Common practice rather than a Google rule: each language version carries a canonical URL that points to itself, so that your translations are not folded into one page.
Which metadata should be localized?
- Title tag and meta description, written for the local search query and not translated word for word.
- Open Graph and social tags, so shared links read correctly.
- Structured data text such as names, descriptions and FAQ answers, plus the inLanguage property.
- Image alt text and captions.
- URL slugs, where a translated slug helps readers. Keep them stable once published.
- The html lang attribute and a language switcher made of real links that crawlers can follow.
How does AI translation handle SEO metadata and hreflang?
On its own, an AI translation tool does neither well. It translates the text it is given. Whether the title tag, meta description, social tags and image alt text are included depends on whether your platform or pipeline sends those fields to it, and hreflang is not a translation task at all: it comes from the platform or framework that publishes the pages. AI translation helps with the words, and the platform has to handle the signals.
| Item | Does AI translation do it? | What to check |
|---|---|---|
| Body text | Yes, as a draft | A human reads it for accuracy and tone |
| Title and meta description | Only if those fields are sent for translation | Length after translation, because a longer title can be cut in results, and wording for the local search |
| Open Graph and social tags | Only if included | Shared links read correctly in each language |
| Image alt text and structured data text | Only if included | Names, descriptions and FAQ answers match the page |
| URL slugs | Rarely, and only when set up | Keep them stable after publishing, and use the final URLs in hreflang and canonicals |
| hreflang tags | No, the platform generates them | Reciprocal, self-referencing, fully qualified URLs, plus an x-default |
| Canonical URL | No | Each language version points to itself |
| Language attribute and sitemap entries | No | The html lang attribute is set per page and each version is listed |
Two failures come up repeatedly. A translation layer that swaps text in the browser with JavaScript leaves search engines with only the source-language page. And translated pages published without their hreflang partners are treated as unrelated pages. Test by viewing the source of a translated page and checking both.
Where AI translation helps and where it can hurt
AI suggestions are good at a first draft, at keeping terminology consistent through a glossary and at handling volume. They are weaker on legal wording, on culture-specific phrasing and on anything where a mistake has a cost. Google's spam policy on scaled content abuse says that generating many pages without adding value for users is abusive no matter how the pages are created, and it lists automated transformations such as translating among the techniques. The problem is the lack of value, not the tool.
Eight things to test before you choose
- View the source of a translated page and check the hreflang block against the rules above.
- Confirm every language has its own indexable URL, not a script that swaps text in the browser.
- Check that titles, descriptions and social tags are translated, not only the body.
- Check that the sitemap lists each language version.
- Ask who owns the translations and whether you can export them in a standard format.
- Ask what happens to your URLs and rankings if you stop paying.
- Check that a human review step exists before AI text is published.
- Measure page speed with the translation layer switched on.
Tell us your languages, publishing workflow and existing platform. We can help you choose a multilingual setup or build one around your content needs.
Plan your multilingual websiteFAQ
Which type of platform handles hreflang, metadata and AI translation together?
Translation proxies and CMS-native multilingual plugins bundle all three most completely. Headless and framework setups give more control, but you assemble the pieces yourself, usually with a translation management system for AI suggestions.
Is machine translation bad for SEO?
Not by itself. Google's spam policy targets pages produced at scale without value for users, however they are made. Reviewed, accurate translations that serve a real audience are fine.
Do I need hreflang in both the HTML and the sitemap?
No. Google treats HTML tags, HTTP headers and sitemap entries as equivalent, so pick one method and keep it correct.
Sources
- Google Search Central, Tell Google about localized versions of your page
- Google Search Central, Spam policies for Google web search: scaled content abuse
- Nuxt i18n module documentation
About the author
Erik Salo Akimov · Co-founder · Engineering
Erik runs engineering at ESADEX. He designs the platforms, infrastructure and security controls that sit behind client systems.
