How We Built a Multilingual Website With MCP, End to End

beste.co now runs in three languages: English, Turkish and Spanish. We built every Turkish and Spanish page together with an AI, connected to our builder through MCP. It drafted, suggested options and did the heavy lifting. We made every call on content and voice, then went over each page one last time before it went live.

Anyone who has run a multilingual site knows the copy is only half the job. The other half is technical SEO: URL structure, hreflang, alternate links, a sitemap that lists every version, and the slow work of setting all of it page by page in a CMS. That is the part that usually takes weeks. With Beste MCP, it became a conversation.

This post shows how that worked in practice: the decisions we made, the tools the AI called, where it saved us the most time, where our own judgment still mattered, and how we keep three languages in sync now that they are live. It is part of our MCP guide.

Why we did it now

Turkish came first because our first customers outside the English-speaking market were Turkish, and because I am Turkish myself. I could judge every line of the output, which made the first language the right place to find out whether this approach worked at all. Spanish came second because it was the largest market where we had no content, and because a second language would tell us whether the method held up when nobody on the team could judge every line by ear.

What MCP changes for a website builder

MCP, the Model Context Protocol, is an open standard that lets an AI assistant use another product's tools directly. Claude, Codex or Cursor stops writing instructions for you and starts doing the work itself, inside the product.

For most website builders, an AI can give you advice. With an MCP server, it can open your site, read every page, write a section and publish. Beste has its own MCP server, so the AI works on the real site, not on a copy or an export.

This matters a lot for translation. Localizing a site is not one big task. It is hundreds of small ones: every heading, every button, every slug, every meta description, the navbar, the footer. That kind of patient, repetitive work is exactly where an AI with real tools is better than a person with a spreadsheet.

Why multilingual technical SEO is usually the hard part

Translation gets the attention. Technical SEO is where multilingual sites quietly fail. Before you write a single translated line, you have to get these right:

• Subfolder, subdomain or separate domain. /tr/, tr.example.com or example.com.tr. Subfolders keep every language under one domain, so the authority you build is shared. That is why beste.co uses /tr/ and /es/.
• hreflang on every page. Each page has to list every language version of itself, itself included, and every version has to point back. Google's documentation on localized versions is explicit that each version must list itself and all the others. Miss one return link and search engines may ignore the whole set.
• A default for everyone else. An x-default alternate tells search engines which version to show visitors whose language you do not serve. Point it at the language you would rather a stranger land on, which for most sites is the original.
• Localized slugs. A Turkish page at an English URL looks unfinished to visitors and to search engines.
• A sitemap that knows about languages. Every language version listed, with its alternates, and updated the moment a page is added.
• Canonical and noindex for pages that stay in one language. Otherwise search engines see near-duplicates.
• Meta titles and descriptions per language. Written for local search, not translated line by line.

In a typical CMS, most of this is done one page at a time, often with a separate plugin for each problem. Our site has 46 pages. In three languages that is 138 pages to keep consistent, and every new page adds three more.

In Beste, the structure is built in. Each language gets its own subfolder URL, hreflang and alternate links are generated for every page, and the sitemap includes every language version. What is left, like localized slugs, per-language SEO and canonical choices, is a set of MCP tool calls the AI can run across the whole site in one session.

That is what changed for us. Adding a language stopped being a project.

The decisions we made before translating a single word

The AI did the typing. The thinking still had to come from us. These are the calls we made first, and every one of them ended up in the instructions the AI followed.

Which language first. Turkish, because we know it best and could judge the output line by line. Spanish came second. We picked Spain Spanish (es-ES) over a mix of variants, so the voice stays consistent.

Which pages first. Home, Overview and Features. These pages carry the product story. Getting them right taught us more than translating 40 pages at once would have.

What stays in English. The Privacy Policy, the Terms of Service and the Our Story page stay English only. Legal text has one binding version, and a translation that drifts from it helps no one. The story page is personal, and we wanted it in the voice it was written in. Their Turkish and Spanish URLs are set to noindex with a canonical pointing to the English page.

The editor itself stays in English. We localized the website, not the product. That kept the scope honest.

Tone rules, written down. This was the most important step. A loose instruction like "translate this naturally" gives you loose results. We wrote specific rules for each language:

• Natural copy, not literal translation. The same clean, clear tone as the English.
• Industry terms stay in English when that is what people in that market actually say, and get a local word only when the language really uses one. In Turkish, "section" stays "section". In Spanish, it becomes "sección", because Spanish speakers say that.
• One form of address, informal and consistent, in every language.
• A fixed glossary, so the same idea never gets two names.
• No em dashes, no filler phrases, nothing that reads like default AI copy.

Native editing is not optional. A translation can be correct and still sound foreign. Every language got a native pass on terminology, address and rhythm, and that local editing is what makes a page read like it was written in that language. It is the one step we would never skip.

Languages stay in sync. Anything added in one language has to exist in the others. Each language keeps its own voice, but no page or section is allowed to exist in only one of them.

How we did it, step by step

Here is the actual flow, with the Beste MCP tools the AI called at each step. You can follow the same path in Claude, ChatGPT, Codex or any client that supports MCP.

1. Add the language. The AI called add_language with tr. Beste copied the existing English content into the new language as a starting point. The layout, sections and images were already in place. Only the words were left to change.
2. Pull every string that needs translating. get_translatable_text returns every piece of text on a page, each with its own id: headings, body copy, buttons, image alt text, FAQ answers. Fields the renderer depends on, such as link types and URLs, are left out, so a translation cannot break the page. Nothing gets missed because nothing is copied by hand.
3. Translate with the rules. The AI drafted each page with our tone rules in context and suggested options wherever the wording was a judgment call. We picked, edited and sent our decisions back. Because the rules were written down, page 30 sounds like page 1.
4. Write it back. apply_translation sends the translated strings back, keyed by the same ids. Each string lands exactly where its English version sits.
5. Give every page a local URL. A Turkish URL with an English slug looks half done. With update_page, each page got its own slug per language. Our Multi-Language Support page lives at /features/multi-language-support in English, /tr/ozellikler/coklu-dil-destegi in Turkish and /es/funciones/webs-multidioma in Spanish.
6. Translate the shared parts once. The navbar and footer are shared components, so they were translated once with set_navbar and set_footer and show up correctly on every page.
7. Localize the SEO, not just the copy. Every page got its own title and meta description per language. These were written for how people search in that language, not translated word for word. Our Spanish title for the same page leads with "Webs multidioma sin coste por idioma", which is closer to what a Spanish speaker types.
8. Check it as a visitor. preview_url with a language returns the right address for each version, so we read every page as a visitor would before it went public.
9. Publish. After our final read of every page, one publish call put the draft live. Each language has its own URL, and Beste adds the hreflang tags, so search engines know which page to show to whom.

After Turkish worked, Spanish was the same nine steps with a new set of tone rules. Most of the hard part, the decisions about scope and what stays in English, was already settled. The second language took a fraction of the first, and most of that time was the native review.

Who did what: the AI's part and ours

We would rather show both sides than pretend it was flawless.

Where it was better than us. Volume and consistency. It never skipped an alt text, never left a button in English, never forgot the FAQ at the bottom of a page. Once a word choice was set, it kept it across the whole site. A person doing this by hand gets tired by page 15. The AI does not.

Where we stepped in. Three kinds of fixes came up again and again:

• Headlines that were correct but flat. The meaning was right, the punch was gone. Short marketing lines need a native ear, so we rewrote some hero headlines ourselves.
• Native word choices. Some terms are right in a dictionary and still wrong for the market or for the brand. In Turkish we wanted "yapay zeka" where the English said "agent", because that is how our Turkish customers talk, and we wanted "emlak" rather than "gayrimenkul" for real estate, because it is the everyday word. An AI cannot know a team's preferred words until you tell it. Every fix like this became a new rule, and the rule list got better as we went.
• Search intent. A literal translation of an English meta title rarely matches what people type in another language. We checked titles and descriptions for the pages that matter most.

The pattern is simple: the AI drafts and suggests, we decide, and a native speaker gives every page a final pass. Reviewing is a much smaller job than translating from scratch. Everything we learned about writing those rules is in Writing Rules for Your Website Agent.

Checking the technical side after publishing

The builder generates hreflang and the sitemap, but we still checked them once, the way a search engine would see them:

• Open the page source of one page in each language and confirm the alternate links list all three versions, the page itself included, plus x-default.
• Open the sitemap and confirm each page appears with its language versions.
• Open a single-language page, such as the Turkish Terms of Service URL, and confirm it carries noindex and a canonical to the English page.
• Inspect a few URLs in Google Search Console after a couple of weeks to see which version Google treats as canonical.

This took under an hour. It is worth doing once, so you trust the setup, and again after any change to your URL structure.

Keeping three languages in sync after launch

Launch is the easy part. The real test is month three, when the English pricing page gets a new FAQ and nobody remembers the other two. What we do now:

• Every change ships in every language, in the same session. When we ask for a change in English, the request ends with "and the same in Turkish and Spanish". The agent pulls the new strings with get_translatable_text and writes them back with apply_translation before we review.
• New pages are created in all languages before anyone reviews them, with local slugs and per-language titles set at the same time.
• A monthly sync check. We ask the agent to compare the section list of each page across the three languages and report any page where the counts or headings differ. Most months it finds nothing. When it finds something, it is usually a section we added in a hurry.
• Blog posts are linked as translations. A translated post is created with translationOf, so the site emits hreflang for the pair and the language switcher jumps to the right article.

Six mistakes to avoid when you add a second language with AI

1. Starting without written rules. "Translate naturally" means something different on every page. Write the rules first, then add to them every time you fix something.
2. Keeping English slugs. /tr/features/pricing tells a Turkish visitor and a search engine that the page is a leftover. Localize the URL along with the copy.
3. Translating meta titles word for word. Search behavior changes with the language. Write titles for what people actually type.
4. Translating pages that should stay in one language. Legal pages are usually better left in their binding original. If a translated version exists anyway, point its canonical to the original and set it to noindex.
5. Letting languages drift apart. A section added to the English page and nowhere else is how a multilingual site slowly breaks. Make "every language gets every change" a rule, not a hope.
6. Skipping the native review. An AI gets meaning right far more often than voice. A native speaker reading the key pages once is the cheapest quality step you have.

One more that is easy to miss: words inside images do not translate. If a screenshot or a banner carries text, it will stay in English on every version. Keep text out of images where you can, and write alt text per language where you cannot.

Try it on your own site

We built Beste so a site could be run by talking to it, and translating our own site was the biggest test of that idea so far. Three languages, local URLs and local SEO across a 46-page site, all through MCP. Beste supports more than 50 languages, with no fee per language, on every plan.

The AI did not replace our judgment. It replaced the copying, the pasting, the hreflang checklists and the tired page 15. That is the part nobody misses.

If you want to try it, connect Beste to Claude, ChatGPT or any MCP client through our MCP server, open your site and ask it to add a language. Start with one page you know well. Read the result. Write your first rule.

Sources

Checked in October 2026.

• Google Search Central: Tell Google about localized versions of your page
• Model Context Protocol: What is MCP?
• Beste: Multi-Language Support
• Beste: MCP Server & Tools