AI Website Translation: Content, Navigation, Metadata and Localization

Translating a website is not the same as translating an article.

For production multilingual workflows, see our AI Translation service for the delivery path behind the guidance in this article.

A website is a connected system of pages, navigation, user-interface strings, metadata, forms, structured data, links and locale rules. If only the visible paragraphs are translated, the site may still feel half-localized and search engines may struggle to understand which version belongs to which audience.

AI can accelerate website translation dramatically, but the workflow must respect web architecture.

Google’s current international-site guidance recommends locale-specific URLs and hreflang or sitemaps for multilingual or multi-regional versions. W3C guidance recommends declaring the natural language of HTML content with the lang attribute.

Website translation versus website localization

Translation changes language.

Localization adapts the experience for a particular audience.

Localization may also change:

• currency;
• date format;
• address format;
• measurement units;
• legal notices;
• examples;
• images;
• contact details;
• calls to action;
• terminology;
• form fields.

Microsoft’s localization guidance explicitly distinguishes translation from the broader adaptation required for target markets.

A professional multilingual site needs both layers.

What needs to be translated?

A typical website contains language in more places than the main article body.

Inventory:

• headings;
• paragraphs;
• navigation;
• buttons;
• forms;
• error messages;
• tooltips;
• modal dialogs;
• breadcrumbs;
• footer;
• legal links;
• alt text;
• page titles;
• meta descriptions;
• Open Graph text;
• structured-data text values;
• email templates;
• transactional messages;
• CMS labels that appear publicly.

If the user can see or hear it, ask whether it is translatable.

What should not be translated?

Protect:

• code;
• variable names;
• CSS classes;
• URLs unless intentionally localized;
• tracking parameters;
• product names under brand policy;
• IDs;
• API paths;
• model numbers;
• database keys.

W3C documents the HTML translate attribute, which can mark content that should or should not be translated. translate="no" can protect product names, code terms or other content from translation tools that honor the standard.

This is better than asking translators to remember exclusions manually.

Separate content from code

A localization-friendly website stores user-facing strings separately from application logic.

Instead of:

if (status === "approved") { button.innerText = "Continue"; }

use a translation resource key such as:

checkout.continue

with locale files containing the display text.

This allows:

• controlled translation;
• versioning;
• automated QA;
• fallback behavior;
• reviewer workflows.

It also prevents AI from accidentally editing executable code.

Language and locale architecture

Decide how localized content will be routed.

Common structures include:

• example.com/fr/
• example.com/de/
• country subdomains;
• country-code top-level domains.

Google recommends separate locale-specific URLs for multilingual or multi-regional content rather than relying entirely on dynamic adaptation.

Stable URLs give users and search engines a consistent destination.

Avoid forced IP redirection

A visitor’s physical location does not always reveal the language they want.

Google’s current multilingual-site guidance warns against relying on IP analysis to adapt content because it can be inaccurate and can make variants difficult for Google to crawl.

Provide visible language and region selectors.

If you redirect, give users an easy way to choose another locale.

hreflang

hreflang helps Google understand equivalent pages intended for different language or regional audiences.

For example, equivalent pages could target:

• English;
• English for the United States;
• English for the United Kingdom;
• French;
• French for Canada.

hreflang is not a translation quality signal. It is an indexing relationship.

Use it only between pages that genuinely correspond.

Google supports implementing these relationships in HTML, HTTP headers or sitemaps.

Page language

W3C recommends declaring the default language on the HTML element:

``

A French page would use the corresponding language code.

This helps:

• screen readers;
• speech synthesis;
• spell checking;
• fonts;
• browser processing;
• accessibility.

When a page includes content in another language, wrap that content with its own language declaration where appropriate.

Do not confuse page language with audience targeting. They are related but distinct metadata concepts.

Translate page titles

The HTML title is one of the highest-value pieces of page text.

A translated page should have a target-language title that:

• accurately describes the page;
• reflects local search wording;
• fits the target intent;
• avoids keyword stuffing.

Do not simply keep the English title because the body has been translated.

A local user who sees an English search-result title may assume the page is not for them.

Meta descriptions

Translate and localize meta descriptions too.

They should summarize the target-language page naturally.

Avoid mechanically translating a source keyword if users in the target market search for a different phrase.

Multilingual SEO needs localized keyword research, not only translated keyword lists.

Slugs and URLs

Should URLs be translated?

There is no universal requirement.

Options include:

• keep stable source-language slugs;
• localize slugs;
• use language-neutral IDs.

The important priorities are:

• stable URLs;
• consistent architecture;
• correct internal links;
• redirects when structures change.

If slugs are localized, avoid changing them frequently just to refine wording.

Navigation

Navigation is a controlled terminology system.

Terms such as:

• Solutions;
• Resources;
• Pricing;
• Contact;
• Sign in;

should be consistent across every page.

Treat navigation labels as product terminology, not isolated translation segments.

Test whether longer target-language words fit the header at:

• desktop width;
• tablet;
• mobile.

Localization can expose brittle responsive layouts.

Buttons and calls to action

A CTA must preserve intent.

“Get started” is not always best translated literally.

The localized version should match:

• action;
• tone;
• expected next step.

Short interface text is context-sensitive. A translator needs to know whether “Open” is a verb, state or menu label.

Provide screenshots or string descriptions for ambiguous UI labels.

Microsoft’s application localization guidance notes that even simple strings can translate differently depending on context.

Forms

Translate:

• labels;
• placeholder text;
• helper text;
• validation errors;
• consent text.

Localize:

• address fields;
• phone formats;
• postal codes;
• date pickers;
• name order;
• required legal consent.

Do not assume a US address form works globally.

A website can be linguistically translated and still impossible for a local user to complete.

Images and alt text

Images may contain:

• visible text;
• culturally specific references;
• diagrams;
• screenshots.

If the image itself remains appropriate, translate its meaningful alt text.

If the graphic contains essential source-language text, create a localized asset or use an image-translation workflow.

Do not localize decorative imagery unnecessarily.

Google’s SEO guidance emphasizes useful image context and descriptive alt text; accessibility requires the same discipline.

Structured data

Structured data can contain natural-language values such as:

• headline;
• description;
• job title;
• recipe name.

Localized pages should expose structured data that accurately matches the visible localized content.

Do not use schema markup to insert claims or answers that users cannot see.

The markup should represent the page, not a hidden SEO layer.

Internal links

A French page should generally link to the French version of another page when an equivalent exists.

Common multilingual linking failures include:

• navigation jumps back to English;
• CTA opens the wrong locale;
• breadcrumbs cross languages;
• related articles point to source pages.

Build locale-aware link resolution rather than hard-coding source-language paths.

Canonical URLs

Canonicalization and hreflang solve different problems.

A localized page should not normally canonicalize to the source-language page simply because the content is equivalent in meaning. Doing so can tell search engines the translated page is a duplicate rather than a distinct language version.

Use self-consistent canonical and internationalization signals according to your site architecture and Google’s documentation.

CMS workflows

For a content-managed site, define statuses such as:

• source draft;
• ready for translation;
• AI draft;
• linguistic review;
• SEO review;
• approved;
• published;
• source changed.

When the English page changes, the system should know which translations are now out of date.

Without content synchronization, multilingual sites drift.

Translation memory and glossary

Recurring website terms should be controlled.

Maintain:

• product names;
• navigation labels;
• feature terminology;
• legal phrases;
• preferred CTAs;
• industry vocabulary.

AI can use glossaries and prior approved content as context.

This improves consistency across thousands of strings.

Brand voice

A website is often a company’s primary brand surface.

The AI translation brief should specify:

• formal or informal address;
• tone;
• sentence length;
• terminology;
• phrases to avoid;
• market-specific examples.

Marketing pages may require more creative adaptation than documentation.

Do not apply one literal translation style to every site section.

Website QA

Linguistic QA

Check:

• meaning;
• tone;
• terminology;
• completeness;
• names.

Functional QA

Check:

• links;
• forms;
• menus;
• search;
• filters;
• checkout;
• authentication;
• email confirmations.

Visual QA

Check:

• overflow;
• line wrapping;
• fonts;
• RTL layout;
• mobile navigation.

SEO QA

Check:

• title;
• meta description;
• lang;
• hreflang;
• canonical;
• sitemap;
• indexability;
• internal links.

A page can pass linguistic review and still fail launch because the translated CTA leads to an English checkout.

AI and AEO

Answer-engine optimization should begin with helpful content structure, not tricks.

For informational pages:

• answer the primary question early;
• use descriptive headings;
• define concepts clearly;
• include evidence;
• use concise summaries;
• provide useful comparisons.

Google currently states that the same foundational SEO practices apply to its AI search features; there is no separate technical optimization required to appear in AI Overviews or AI Mode.

Translated pages should therefore be genuinely useful in the target language rather than mass-produced variants.

Scaled translation quality

AI makes it possible to translate thousands of pages rapidly.

That makes quality governance more important.

Prioritize human review for:

• high-traffic pages;
• pricing;
• conversion pages;
• legal pages;
• high-value markets;
• health or safety content.

Lower-risk long-tail pages can use sampling and automated QA if performance is proven.

Frequently asked questions

Can AI translate an entire website?

Yes. The best workflows connect to a CMS or localization pipeline and translate structured content and UI strings rather than scraping rendered pages only.

Should translated websites use different URLs?

Google recommends locale-specific URLs for multilingual and multi-regional content.

What is hreflang?

It is a signal that helps Google understand which localized page version is intended for which language or region.

Should meta descriptions be translated?

Yes. Localize titles, descriptions and other user-facing metadata so search results accurately represent the target-language page.

Is website translation the same as localization?

No. Translation changes language; localization also adapts formats, cultural references, UX and market-specific content.

Conclusion

AI website translation is most effective when language is treated as part of the product architecture.

Extract content cleanly, protect code, localize for real markets, publish stable locale URLs, declare language, connect equivalent pages, and test the entire user journey.

A multilingual site is successful when the visitor never feels that they have wandered into a translated copy of someone else’s website. It should function as a complete local experience.

Research references

• Google Search Central, International and multilingual site topics:
• Google Search Central, Managing multi-regional and multilingual sites:
• W3C, Declaring language in HTML:
• W3C, Using HTML's translate attribute:
• Microsoft Learn, Localization overview:
• Google Search Central, AI features and your website: