multilingual ai websites

Multilingual AI Websites: How to Build and Translate Them

Build a multilingual AI website that ranks: URL structure, hreflang, language switchers, translation quality and a step-by-step workflow for your sites and apps.

You can have an AI assistant write, translate and publish a site in several languages in one afternoon. The hard part is not the translation. It is the structure around it: clean URLs, hreflang tags, translated metadata, a language switcher people can actually use, and a human check on the pages that matter. This guide covers each of those, then shows how to run the whole job through WebsitePublisher, the AI web platform where your assistant builds and publishes websites and apps.

TL;DR

Give every language its own clean URL path, such as /es/, and avoid ?lang=es parameters.
Translate everything a visitor or search engine sees: body text, titles, meta descriptions, Open Graph fields and image alt text.
Let AI produce the first draft. Have a fluent human review pages with branding, humor, legal or sales weight.
Use a visible language switcher that names each language in its own language, and skip automatic redirects.
With WebsitePublisher, your AI assistant builds each language version as real pages, and every change is live immediately.

What a multilingual AI website really is
Pick one URL structure and keep it
Set up hreflang so the right page reaches the right reader
Translate everything, not just the body
How good is AI translation, and when do you need a human?
Build a language switcher people can use
Markup details that save you later
Building it on WebsitePublisher
Our perspective: structure first, then language
Common mistakes to avoid
A quick pre-launch check
FAQ
Sources

What a multilingual AI website really is

The phrase covers two different things, and people searching for it often mean one of them.

A site built with AI that serves content in more than one language. Your assistant (ChatGPT, Claude, Gemini or another) writes and structures the pages, and the finished site has an English version, a Spanish version, a German version and so on.

A site that bolts an AI translation layer on top of existing pages. The text is translated on the fly or in bulk, usually by a plugin or a service.

Both can work. The first gives you real, editable pages for each language, which search engines can index and you can refine. The second is faster to switch on but gives you less control over what visitors see. This article focuses on the first approach, because it is the one that holds up for search and for brand quality.

If you only need to translate website copy with AI, the same rules apply. A translation is only as useful as the structure that delivers it.

Pick one URL structure and keep it

Search engines need to know which page belongs to which language. Google’s guide to multi-regional and multilingual sites describes three common patterns:

Pattern	Example	Best for
Subdirectory	`example.com/fr/`	Most small businesses, freelancers and agencies
Subdomain	`fr.example.com`	Large sites with separate teams per market
Country-code domain	`example.fr`	Brands with a local legal entity and budget for each domain

For most readers of this guide, subdirectories are the sensible default. One domain, one set of settings, and each language lives under its own path.

The key rule is to choose one pattern and apply it everywhere. The internationalisation guidance at Website Spec recommends exactly that: a single URL pattern for multilingual or multi-regional content.

Avoid language parameters

Switching language with a query string like ?lang=es is a common shortcut. Multilingual CMS guidance calls it poor for SEO. Give each language real paths instead: /es/precios rather than /pricing?lang=es. Clean paths are easier to share, easier to index and easier to read.

Set up hreflang so the right page reaches the right reader

Hreflang is a link attribute that tells search engines which language and region a page targets and where its siblings live. According to the Hreflang overview, without it search engines may struggle to serve the correct locale, which can lead to duplicate content problems. The same source notes that every page in a set needs a self-referential hreflang tag.

In practice, each page carries a list like this:

A tag pointing to itself.
A tag pointing to every translated version.
Optionally, an x-default tag pointing to the page you want shown when no language matches.

Two habits prevent most mistakes:

Make the links reciprocal. If the English page points to the Spanish page, the Spanish page must point back.
Update the set whenever you add or remove a language page. A page that disappears but is still referenced creates broken pairs.

Because hreflang has to be consistent across every page, it is a good job to hand to your AI assistant with a clear rule, then check a few pages by viewing the source. Developers can also generate the tags in code, but for a small site a written rule and a spot check are enough.

Translate everything, not just the body

A page that shows Spanish text under an English title is half-finished. The Website Spec i18n page is explicit that internationalization covers all visible metadata: titles, meta descriptions, Open Graph fields, JSON-LD names and image alt text. A localized body with English metadata is incomplete, and it hurts both search results and accessibility.

Use this checklist for every translated page:

✓ Page title and H1
✓ Meta description
✓ Open Graph title and description (what shows when someone shares the link)
✓ Image alt text
✓ Button labels, form labels and error messages
✓ Navigation and footer
✓ Structured data names
✓ The URL slug itself

That last item is easy to forget. A slug in the reader’s language looks trustworthy in search results and tells people what the page is about before they click.

How good is AI translation, and when do you need a human?

Good enough to start with, and not always good enough to publish untouched.

A 2026 study of English translations of Chinese city publicity texts compared dedicated machine translation systems with large language model agents. Both groups scored high on a five-point scale, with the top dedicated system at 4.683 and leading LLM agents at 4.599 and 4.553. Standard Google Translate came in lower, at 4.261. The authors also note that automated tools work best inside a structured workflow with human oversight, especially for high-stakes branding. That is one language pair and one text type, so treat it as a signal, not a universal ranking.

Study scores for four translation systems

Research on perceptions of machine versus human translation points the same way. A study of translation students localising a website found that automated tools are strong at grammar and syntax, while human translation is seen as superior for humor, local expressions and idioms. For professional institutional communication, human judgment or at least professional post-editing remains the standard.

For a working site, that suggests a simple split:

Page type	Approach
Product specs, FAQs, how-to content	AI draft, quick skim by a fluent reader
Home page, pricing, calls to action	AI draft, full review by a native speaker
Legal, medical, financial text	AI draft only as a starting point, professional review required
Slogans, jokes, wordplay	Rewrite for the market (transcreation), do not translate literally

A public-sector example shows why this matters. A study on machine translation at the Ottawa Public Library tested translating sections of the library’s website into Spanish for newcomers. The idea was efficient and cost-effective access, and it was evaluated for usefulness rather than assumed to work. Do the same on your own site: ask a native speaker to read ten pages before you translate fifty.

Give the AI a style brief

You get better drafts when the assistant knows the audience. Tell it:

Who the reader is and which country they live in (Mexican Spanish and Spanish from Spain read differently).
Whether to use formal or informal address.
Which terms must never be translated, such as your brand and product names.
Which measurements, currencies and date formats to use.

Our AI website prompt templates show how to write briefs like this so the assistant has what it needs the first time.

Build a language switcher people can use

A switcher is the one control every multilingual site needs. Three rules from the language switcher guidance cover most of it:

List each language in its own language. Write “Deutsch”, not “German”, so a visitor who cannot read the current page can still find theirs.
Do not use flags. Flags represent countries, not languages. Spanish is spoken in many countries, and English is not only a US or UK language.
Mark each option with the right lang attribute.

Place it somewhere persistent, usually the header or footer, and link each option to the equivalent page in the other language, not just to that language’s home page. A reader on your Spanish pricing page who switches to English should land on the English pricing page.

Do not redirect by location

It is tempting to detect a visitor’s country or browser language and send them to a matching version. The Website Spec guidance treats automatic geo-redirects based on IP or Accept-Language as an anti-pattern. They trap users, break search engine crawlers and invalidate shared links. Serve a sensible default and let people choose, with the switcher always visible.

Markup details that save you later

Two small attributes make a real difference, both described on the Website Spec i18n page:

translate="no" on brand names, technical identifiers and code blocks, so automated translation does not mangle them. Your product name should read the same in every language.
The lang attribute on any inline content that differs from the page language. WCAG 3.1.2 requires it, and it lets screen readers switch pronunciation correctly.

If you quote a French phrase on an English page, wrap it with lang="fr". It takes seconds and helps every visitor who relies on assistive technology.

Building it on WebsitePublisher

WebsitePublisher is the AI web platform. Your AI assistant, whether that is ChatGPT, Claude, Gemini or another supported assistant, connects through the WebsitePublisher connector and builds and publishes websites and apps from your instructions. You can see the supported AI platforms before you start.

That setup suits multilingual work for three reasons.

Real pages, not a hidden layer. Each language version is a page you can open, read and edit in the visual browser editor.
Reusable components. Navigation, footers and calls to action can be defined once and reused, which keeps design consistent across language versions.
Instant changes. Every change is live immediately. There is no separate deploy or publish step, so you can fix a mistranslation and see it on the site at once.

You also stay free to switch assistants. Your project is not locked into one AI session, so you can draft in one tool and refine in another.

A practical workflow

Build the source language first. Finish and approve the English site, including metadata. Changing the source after translating multiplies the work.
Define the structure. Tell your assistant: “Create each language under its own path, such as /es/ and /de/, with translated slugs. No query-string language switching.”
Write the style brief. Include audience, tone, protected terms and formats, as described above.
Translate page by page. Ask for body text, title, meta description, Open Graph text and alt text together, so nothing is left in English.
Add hreflang and the switcher. Ask for self-referential and reciprocal tags, plus a switcher that names each language in its own language.
Have a native reader review key pages. Fix problems in the visual editor, or ask your assistant to apply the corrections everywhere the term appears.
Check in a search tool. After the pages are indexed, use Google Search Console to look for hreflang and indexing errors.

If you are starting from nothing, begin with our AI web platform page or our walkthrough on how to build a small business website with AI. If you are adding languages to an existing site, read the website migration checklist first, because moving URLs without redirects is the fastest way to lose traffic.

To try it, see the plans on the pricing page. There is a free plan.

Our perspective: structure first, then language

We build WebsitePublisher around one idea: your AI assistant should do the building, and you should keep control of the result. For multilingual sites, that leads to a clear view.

The translation step is the part everyone talks about, and it is the part that is getting easier every year. The part that still separates good multilingual sites from bad ones is structure. A site with clean paths, reciprocal hreflang, translated metadata and a switcher that respects readers will outperform a site with perfect prose and none of those.

That is why we recommend data-driven pages and reusable components over one-off layouts. When your navigation, footer and calls to action are defined once, adding a language means filling in content, not rebuilding design. When content is managed as data, a correction to a product name can be made in one place.

We also think AI should draft and humans should approve where the stakes are high. The research above supports that split. Use your assistant for speed on the long tail of pages, and spend your human review time on the home page, the pricing page and anything with legal weight.

Our perspective: structure first, then language — overview diagram

Finally, we think visibility is changing. Readers increasingly meet your content through AI answers as well as search results, and clear, well-labeled language versions help in both places. Our piece on generative engine optimization covers that side.

Common mistakes to avoid

Translating the body and leaving the rest. Titles, descriptions and alt text are part of the page.
Using flags for languages. A flag excludes everyone who speaks the language in a different country.
Redirecting by IP. It breaks crawling and shared links.
Translating brand names. Mark them translate="no".
Launching every language at once. Start with the one or two markets where you have customers, review them well, then expand.
Treating translation as finished at launch. When you edit the source page, update the translated versions too, or they drift out of sync.
Linking every language to the home page only. Link to the equivalent page.

Freelancers and agencies can make this repeatable by writing the rules once and reusing them on each client project. Our article on AI for web agencies explains where to automate and where to keep review human.

A quick pre-launch check

Check	Pass condition
URL pattern	One pattern used on all pages, no query-string languages
Hreflang	Self-referential and reciprocal on every page
Metadata	Title, description, Open Graph and alt text translated
Switcher	Languages named in their own language, no flags, links to equivalent pages
Redirects	No automatic location-based redirects
Markup	`translate="no"` on brand names, `lang` on foreign inline text
Review	Native speaker has read the key pages

Work through the table on a sample of pages in each language before you announce anything.

FAQ

Can I translate my website with AI and publish it as is?

You can for low-risk content such as how-to pages or product descriptions, but check it first. Dedicated translation systems and large language models both score well in recent testing, yet human review is still the norm for branding, humor and institutional content. Have a fluent reader check your home page, pricing page and any legal text before they go live.

Is a multilingual site good for SEO?

It can be, when each language has its own indexable URL and hreflang tags connect the versions. Without hreflang, search engines may serve the wrong version or treat translations as duplicates. Translating metadata and slugs also helps each version match what local readers search for.

Should I use subdirectories or separate domains?

For most small businesses, freelancers and agencies, subdirectories such as /fr/ are the simplest choice. You manage one domain and one site. Separate country-code domains make sense when you have a local entity and resources for each market. Whichever you pick, use it consistently.

Do I need a language switcher if I use geo-redirects?

You should not use geo-redirects at all. They trap visitors, break crawlers and invalidate shared links. Serve a default language and keep a visible switcher with each language named in its own language.

Can I build multilingual websites and apps with WebsitePublisher?

Yes. Your AI assistant builds each language version as regular pages through the WebsitePublisher connector, and you can edit them in the browser. Every change is live immediately. See the AI website maker page to get started.