How to Build a Multilingual Website With AI

A multilingual website serves the same content in several languages, each at its own URL such as /en/ or /es/, linked with hreflang tags so search engines show the right version. With WisyLink you name the languages and the default; it builds language paths, a switcher, hreflang and x-default, and stores translated content per language.

• Give every language its own URL path. A cookie or script that swaps the text hides your other languages from search engines.
• hreflang tells search engines which pages are the same content in another language. Every version must list itself and all the others.
• AI writes good first drafts in each language, but a native speaker should review anything that sells, promises or has legal weight.
• Store translations as fields on the same record, so a new dish or product appears in every language at once.
• Local details decide whether a page feels native: currency, date formats, payment methods and legal pages per market.
• On WisyLink, one link serves all languages from one domain. Separate domains per language would mean separate sites.

When you need a multilingual site

Add a language when people already look for you in it. The common cases:

• Tourists and visitors. A guesthouse, restaurant or tour operator whose guests search in their own language before they travel.
• Expat and immigrant communities. A dentist, tax adviser or school whose clients are more comfortable reading in their first language.
• Selling abroad. A small shop or studio getting enquiries from another country, often by email in a language the site doesn't speak yet.
• Bilingual regions. Places where two languages are part of everyday life and customers expect both.

The test that matters: can you answer customers in that language, by email, phone or at the counter? A translated site that leads to a conversation you can't hold creates frustration, not sales. Every language is also a maintenance commitment, because each new price, menu change or policy update has to land in all of them. Two well-kept languages beat five stale ones.

If visitors in a second language only need your opening hours and address, one well-written page in that language may be enough for now.

Machine translation vs native-written copy

There are three levels of quality, and most businesses need a mix:

1. Machine translation, unreviewed. Fast and cheap. Acceptable for low-stakes text such as directions or parking notes; never for allergens. Risky for anything with prices, conditions or tone.
2. AI draft, reviewed by a native speaker. The practical default. Modern AI writes fluent text in many languages, and a reviewer fixes the idioms, the formality and the claims.
3. Written natively. For your homepage headline, key calls to action and anything legal. These few sentences carry most of the weight.

Is machine translation good enough for a business website? For informational filler, often yes. For checkout, booking conditions, cancellation terms and your privacy notice, no. A literal error there costs money or trust. Formality is the other trap: German, French and Spanish all have formal and informal address, and switching between them mid-page reads as careless.

Search engines judge whether the page is useful, not how it was translated. Google's guidance says localized versions are only treated as duplicates if the main content stays untranslated, and that translating only the menus and footer while the body stays in one language makes a poor experience. Translate the main content or don't publish that language.

WisyLink can write the content in each language for you, but you have to ask. The build keeps page text in the page's language and never translates on its own initiative. Wisy, the chat assistant, replies in the language of your latest message, so you can brief it in Turkish and get an English and Spanish site.

URL structure: language paths, not cookies

Google recommends a different URL for each language version, not cookies or browser settings that change the text on one URL. Its guide to multi-regional and multilingual sites also says not to adapt content by IP address, and calls URL parameters such as ?lang=es not recommended. That leaves three serious options, compared here with the cookie approach:

Should you use subdirectories or separate domains? For most small and mid-sized businesses, subdirectories. Separate country domains make sense when each country is effectively its own business, with its own prices, stock, legal entity and team. One language and many countries is a different problem from many languages.

Avoid redirecting people automatically by location. A Spanish speaker in London still wants Spanish. Let the switcher do the work, and keep the language in the URL so a shared link opens in the language it was shared in.

hreflang and x-default explained

hreflang

A tag in each page's head listing the URL of every language version of that page, including itself. It tells search engines which result to show to which searcher.

Return links

If the English page lists the Spanish one, the Spanish page must list the English one. Google ignores pairs that don't point to each other.

x-default

The version for visitors whose language you don't serve, usually your main language.

Language codes

ISO 639-1 language codes such as es, optionally with an ISO 3166-1 region such as es-MX. Google doesn't support codes outside those standards, such as es-419.

html lang

The language attribute on the page. Browsers and screen readers use it. Google says it detects language from visible content, not from this attribute, so the visible text has to be right too.

Canonical

Each language version points its canonical tag at itself. Google advises choosing a canonical in the same language, never pointing every version at the English page.

For a menu page in two languages, every version carries the same three lines:

• <link rel="alternate" hreflang="en" href="https://example.com/en/menu">
• <link rel="alternate" hreflang="es" href="https://example.com/es/menu">
• <link rel="alternate" hreflang="x-default" href="https://example.com/en/menu">

Google's hreflang documentation requires fully qualified URLs, which is where hand-built sites often slip. When you ask WisyLink for a multi-language site, the build puts the language in the path, adds one hreflang tag per language plus x-default, sets a matching html lang and builds every URL from the address the site is actually served on, so the tags stay correct when you move to your own domain. By default the path after the prefix is the same in every language: /en/menu and /es/menu. Translated slugs are possible if you ask, but shared paths keep the language pairs simple and reliable.

Build it: steps and a prompt template

1. Decide the languages and which one is the default. Write down who reviews each language.
2. Collect your copy: your own text per language in a .docx, or let the build write drafts you'll review.
3. Paste the prompt below into a new WisyLink chat and attach your files.
4. When the build finishes, open a few pages in each language and view the page source. Check the hreflang lines, the html lang value and the canonical.
5. Send the native-speaker review back as follow-up messages, such as "In Spanish, use tú instead of usted everywhere". Each change is a new build, and a failed build never replaces the live site.
6. Add or edit records such as rooms and menu items in the admin area, filling every language.
7. Before launch, connect your domain (any plan works) and move to a paid plan; free links expire after 30 days plus a week. See how to connect a custom domain.

Build a bilingual website for Casa Lúa, a six-room guesthouse in Santiago de Compostela.

Languages: English and Spanish at /en/ and /es/. English is the default and the x-default. Every page exists in both languages with the same path after the prefix. Add hreflang tags for both languages plus x-default, a matching html lang and a self-referencing canonical on every page.

Language switcher: in the header, linking to the same page in the other language, never to the homepage.

Pages: home, rooms (one page per room from saved data), breakfast menu, getting here, contact form.

Content: rooms and menu items store name and description per language. Write the Spanish copy natively for travellers from Spain, informal tú, not as a literal translation.

Local details: prices in EUR in both languages; dates as "15 March 2027" in English and "15 de marzo de 2027" in Spanish.

Admin: a login-protected page to edit rooms and menu items in both languages, and to read contact messages.

Attach photos of the rooms if you have them. Your images are used as they are; without them, the build uses stock photos or simple vector art, because WisyLink doesn't generate photos. For more ways to phrase a first request, see prompt templates for AI website builders.

Translating dynamic content stored per language

Static copy, such as your homepage text, lives in the pages. Dynamic content, such as rooms, dishes, products, events and blog posts, lives as saved records, and that's where multilingual sites usually break. Two models work:

• Fields per language on one record: name_en, name_es, with a shared price and photo. Best for catalogs where every item exists in every language. One record means one price and one stock count to keep right.
• One record per language, with a language field. Best for content that differs by market, such as a blog post written for Spanish readers that has no English twin.

New and edited records appear on the live site without a rebuild, usually within a minute. Plan three details up front:

• The admin form. Ask for each language's fields side by side, with a "translation missing" flag you can filter on.
• The fallback. Decide what a Spanish visitor sees when an item has no Spanish text yet: the English text with a note, or nothing. A page's hreflang should only list languages it really has.
• Translation on save. If you add items often, the admin can send new text to a translation service through its API, with your key under Integrations. Treat the result as a draft, like any machine translation.

Restaurants are the classic case: a menu changes weekly and every dish needs a name, description and allergens in each language. The restaurant website guide covers menus as data in detail.

Local details: currency, dates, payment methods, legal pages

Translation gets you understood; local details get you trusted.

• Currency. Show the currency you actually charge. If you charge in euros, show euros in every language; converted estimates create disputes at checkout.
• Dates, times and numbers. 03/04 is March 4 in one country and April 3 in another. Spell the month, use the 24-hour clock where it's normal, and mind decimal commas.
• Payment methods. Card brands, wallets and bank payments vary by country, and payment providers aren't available to merchants everywhere. Check what your provider supports for your account before you promise a method. The online store guide explains how payments connect with your own keys.
• Legal pages. Your privacy notice, terms and any legal notice your market expects should exist in each language you sell in, reviewed by someone who knows the rules there.
• Contact details. Phone numbers with the country code, opening hours in local time, and the languages you answer in.
• Forms and emails. Store the visitor's language with each submission, so confirmation emails and replies go out in that language.

Pre-launch checklist

1. Every language URL loads and shows that language in the visible text, including buttons, form errors, the 404 page and confirmation emails.
2. View the source of three pages per language: one hreflang line per language plus x-default, a canonical pointing to the page itself, and the right html lang.
3. The switcher lands on the same page in the other language.
4. Page titles and meta descriptions are translated, not just the body.
5. The sitemap at /sitemap.xml lists every language URL. WisyLink sites generate their own.
6. Prices, dates and units follow each market's conventions.
7. A native speaker has read the homepage, the main conversion page and the legal pages.
8. Forms in every language save correctly and send replies in that language.
9. The site is added to Google Search Console with the sitemap submitted. For the wider SEO picture, see do AI-built websites rank on Google?
10. Someone owns each language after launch, with a rule for how fast price and policy changes reach all of them.

Build your multilingual site with WisyLink

Name your languages and default, say what each page holds and who it's for, and attach the copy you have. WisyLink builds the language paths, switcher, hreflang, x-default and per-language content, hosted at its own address with HTTPS. You can talk to it in your own language: the site and app are available in nine languages, and Wisy answers in whichever one you write in.

Start free on the Community plan with no card, and build the first version. To see how each site runs in isolation and what the platform can and can't do, read how WisyLink is built. When you're ready to publish on your own domain, which works on any plan, a paid plan keeps the site live while you're subscribed.