By Scott Sumner | AI Findability | Published October 1, 2026

A welcoming purple doorway marked Hola beside a closed help hatch, illustrating why AI website translation needs to cover the next customer step.

AI website translation can help you draft another language version of your site. Before publishing, check whether a customer can understand the offer, make an inquiry and get a useful response in that language.

Answer: Use AI to draft website translations, then have a qualified speaker review meaning and test the complete customer journey. Give language versions accessible URLs, let visitors switch languages, and explain the language your team can actually support.

The expensive mistake is translating the welcome while leaving the rest of the experience unfinished. Here is how I would approach a first additional language without turning a manageable project into a site-wide maintenance problem.

Jump ahead

Translate a journey, not a page count

Imagine a prospect reading your Spanish service page. The offer is clear. They click the inquiry button and reach an English form. The confirmation email is English too. Nobody has explained whether the consultation is available in Spanish.

That is an illustrative scenario, not a client result. It shows why a completed translation and a usable service experience are different things.

My starting point would be one service, one audience and one complete path. Include the service description, navigation needed to reach it, inquiry form, validation messages, confirmation and the first human response. If booking is part of the path, include the booking system.

This is a scope decision. You do not have to translate every old blog post to help someone buy one service. You do need to avoid promising a language experience that stops at the next click.

Language and location are separate decisions, too. A Spanish-language page for customers in Florida is not automatically an offer to serve every Spanish-speaking country. State your service area and delivery constraints clearly.

Ask the reviewer to check the promise, not just the grammar

AI is useful for a first draft and for comparing versions. It is not the person who decides what your company can promise. Have someone competent in the target language and familiar with the service review the translation before it becomes customer-facing.

Give that reviewer the original, the draft and a short terminology sheet. Include product names, service names, support hours, exclusions and words that must not change meaning. A fluent sentence can still describe the wrong offer.

  • Scope: Does a translation of ongoing maintenance sound like a complete redesign?
  • Timing: Did a response target turn into a guaranteed resolution time?
  • Availability: Are location, working-day and support-language limits still clear?
  • Action: Does the button describe what happens next, such as requesting a consultation rather than receiving an instant quote?

These are suggested review questions, not findings from a translation benchmark. The point is to define what an acceptable result means before admiring how natural the text sounds.

A useful AI brief would be:

Draft a Spanish version for this stated audience. Preserve the offer, exclusions, names and timing commitments. Use the supplied terminology sheet. Flag ambiguous phrases for review rather than silently choosing a stronger promise. Return the draft and a separate list of questions for the reviewer.

Do not publish the questions as customer copy. Resolve them with the person responsible for the offer. For regulated or contractual material, use the appropriate specialist review rather than treating a chatbot translation as approval.

Google recommends different URLs for different language versions, rather than changing the language only through cookies or browser settings. It also recommends language annotations, called hreflang, to help connect the right version to searchers.

For a small business site, a structure such as /es/services/ may be a practical option. That is an example, not a requirement or a ranking shortcut. Choose a structure your CMS and editorial team can maintain.

Google also advises against automatically redirecting visitors based on an assumed language. Provide a visible language choice. Someone in the United States may want Spanish; someone visiting from Spain may need to share the English page with a colleague.

And translate the substance. Google says it uses visible page content to determine language. A translated menu surrounding an English service description is not the same thing as a fully translated explanation.

That does not make HTML language labels pointless. They serve other purposes, including assistive technology. Do not confuse Google’s language-detection method with the whole job of building an accessible page.

These are documented search practices, not a promise of rankings or AI recommendations. They belong within a broader AI Findability strategy: make the business understandable without overstating what a technical setting will achieve.

Run one realistic inquiry before expanding

Ask a fluent reviewer to start from the translated page on a phone and complete a marked test inquiry. Do not coach them through it. The unclear step is the thing you are trying to find.

Check ordinary and awkward states: an empty required field, an invalid email address, a long service name and the confirmation screen. Make sure the language choice stays sensible when the visitor moves between pages.

Google’s web.dev guidance on internationalized forms recommends making form text visible and available in HTML so translation tools can access it. A screenshot of translated text does not give you the same usable form.

Then check the business response. If your team provides consultations only in English, explain that before someone books. If you use translated email replies, describe the arrangement honestly. A translated website should not leave customers to discover your support limits after making an inquiry.

This extends the practical contact-form testing process. Delivery still matters, but here the question is whether the person can understand and complete the next step.

A second language needs an update path

Publishing is the beginning of maintenance. When the English offer changes, who checks the Spanish version? What happens to a page while its translation is being reviewed?

Keep a small record for each translated journey: original URL, translated URL, reviewer, last review date and changes waiting for approval. AI can help compare revised source copy with the current translation and highlight likely differences. A reviewer should decide what needs changing.

My preference is a smaller language section that stays accurate over a large translated archive nobody owns. Page count is an easy thing to celebrate. An inquiry a customer can complete is a better acceptance test.

What to do next

Choose one service page and map every customer-facing step after its main button. Mark which steps are ready in the new language and which are not. That gives you a real translation scope before you buy software or commission hundreds of pages.

If you need help assessing the site structure, buyer path and search visibility together, the Findability OS Audit is the starting point. Translation review itself should sit with a qualified language reviewer.

Sources

This is an evergreen implementation guide, not an announcement of a new Google policy. The customer-journey workflow and examples are my recommendations; the search and form guidance is attributed above.