Перевод сайта на английский: как сделать англоязычную версию

Чтобы правильно сделать англоязычную версию сайта, мало перевести тексты: нужна локализация под зарубежного клиента (цены, валюта, контакты, юридические страницы), отдельные адреса для каждого языка вроде /en/, разметка hreflang и переключатель языка без автоматического редиректа. Перевод удобно делать связкой «машинный перевод плюс редактура носителем или профильным переводчиком» с единым глоссарием терминов. Формы, CRM и аналитику настраивают так, чтобы заявки с английской версии было видно отдельно. И заранее решают, кто и как будет поддерживать обе версии в актуальном состоянии.

Отдельно о тех, кто ищет «перевод сайта на английский», чтобы прочитать чужой сайт: для этого не нужны сервисы или специалисты. Встроенный переводчик в Яндекс Браузере, Chrome, Edge и Safari переводит страницу целиком одной кнопкой в адресной строке или через контекстное меню. Дальше речь пойдёт о другой задаче — как сделать английскую версию собственного сайта для иностранных клиентов.

Перевод, локализация или отдельный сайт под рынок

Самая частая ошибка — считать англоязычную версию копией русской на другом языке. Иностранный посетитель сравнивает вас с местными компаниями, и любая деталь «не отсюда» снижает доверие: цены в рублях, телефон с +7 без пометки о часовых поясах, адрес в формате, который он не может прочитать.

Локализация — это адаптация всего, что видит человек из другой страны:

• цены и валюта — доллары или евро, условия оплаты, понятные зарубежному клиенту, налоги и порядок их указания;
• единицы и форматы — дюймы и фунты для США, метрическая система для Европы, формат дат, чисел и телефонов;
• контакты — международный номер, почта, мессенджеры, которыми пользуются на целевом рынке, часы работы в местном времени;
• юридические страницы — политика конфиденциальности, условия использования, уведомление о файлах cookie по правилам рынка;
• тон и примеры — без канцелярита, с примерами и отраслевыми реалиями, понятными западному читателю, без отсылок к российским законам и сервисам там, где они не нужны.

Машинный перевод, редактура или профессиональный переводчик

Машинный перевод и переводчики на основе ИИ сегодня дают читаемый текст, и для черновика это нормальная отправная точка. Проблемы начинаются в деталях: термины переводятся по-разному на соседних страницах, маркетинговые формулировки звучат дословно и неестественно, а названия услуг превращаются в набор слов, которые на целевом рынке никто не ищет.

Варианты на практике такие:

• Машинный перевод без проверки — самый дешёвый и самый рискованный. Google в правилах о спаме относит к злоупотреблениям массово созданный контент, в том числе автоматически переведённый, если он почти не несёт пользы для пользователя. Для коммерческого сайта такой текст ещё и плохо продаёт.
• Машинный перевод с редактурой — оптимальный по цене вариант для большинства корпоративных сайтов. Редактор с хорошим английским или носитель языка вычитывает текст, выравнивает терминологию и переписывает ключевые экраны. Стоит заметно дешевле перевода с нуля.
• Профессиональный переводчик или копирайтер-носитель — дороже всего, но оправдан для главной страницы, страниц услуг, презентаций и всего, что связано с юридическими или техническими формулировками.

В любом варианте до начала работы стоит собрать глоссарий: названия продуктов и услуг, отраслевые термины, должности, фразы, которые нельзя переводить. Это таблица на одну-две страницы, но она экономит часы правок и делает тексты единообразными, особенно если переводят несколько людей или сайт пополняется постепенно.

Техническая сторона: адреса, hreflang и переключатель языка

У каждой языковой версии должны быть свои адреса. Если язык меняется скриптом на том же URL или параметром вроде ?lang=en, поисковики видят только одну версию, а Google прямо не рекомендует параметры для разделения языков. Варианты структуры:

• Подпапка /en/ — проще и дешевле всего: один сайт, один хостинг, накопленный авторитет домена работает на обе версии. Для большинства компаний это лучший выбор.
• Поддомен en.site.ru — удобен, если английская версия работает на другой платформе или её ведёт отдельная команда. По адресу не всегда понятно, язык это или страна.
• Отдельный домен (.com или национальный домен страны) — самый ясный сигнал рынку и пользователю, но и самый затратный: отдельная инфраструктура, а доверие поисковиков набирается с нуля.

Hreflang сообщает поисковикам, что страницы — версии друг друга на разных языках. На каждой странице перечисляются все её версии, включая её саму, и ссылки должны быть взаимными: если английская страница ссылается на русскую, а русская на английскую — нет, Google может проигнорировать разметку. Коды языков — по ISO 639-1, при необходимости с регионом: en, en-US, en-GB. Значение x-default указывает страницу для тех, чей язык не совпал ни с одной версией. Обычно это страница выбора языка или основная версия.

Переключатель языка должен быть заметным и вести на ту же страницу в другой версии, а не на главную. Автоматический редирект по IP или языку браузера Google не рекомендует: он мешает людям и поисковым роботам добраться до всех версий, а робот Google обычно заходит с американских адресов и без заголовка языка. Если хочется подсказать посетителю версию, лучше показать ненавязчивую плашку «Есть версия на вашем языке» и запомнить его выбор.

Остальные обязательные пункты:

• переведённые title и description, заголовки, alt изображений и разметка для соцсетей;
• английские адреса страниц: /en/services/web-development, а не транслитерация русского слага;
• карта сайта со всеми языковыми версиями;
• один язык на странице: Google определяет язык по видимому тексту, поэтому меню, кнопки и подвал тоже переводятся.

SEO: Google на целевом рынке и Яндекс

Англоязычную версию почти всегда продвигают в Google: на рынках США, Великобритании и Европы он основной. Это значит, что ключевые запросы нужно собирать заново на английском, а не переводить русскую семантику. Люди за рубежом называют те же услуги иначе, и дословный перевод часто попадает в запросы, которых никто не задаёт.

Яндекс тоже поддерживает hreflang и учитывает его для языковых версий на подпапках, поддоменах и разных доменах. Важное отличие: Google принимает hreflang и в HTML, и в карте сайта, а Яндекс в своей справке пишет, что больше не поддерживает языковые версии в файле Sitemap. Поэтому надёжнее размечать hreflang прямо в коде страниц — так разметку понимают оба поисковика. Английскую версию стоит добавить в Google Search Console отдельным ресурсом или следить за ней в общем отчёте с фильтром по папке.

Формы, CRM и аналитика для каждого языка

Заявки с английской версии должны отличаться от русских с первой секунды. В проектах мы обычно делаем так:

• в каждой форме есть скрытое поле с языком и версией сайта, и в CRM заявка сразу попадает в нужную воронку или к нужному менеджеру;
• автоответы, письма-подтверждения и уведомления написаны на языке посетителя;
• поля формы адаптированы: международный формат телефона, страна, часовой пояс для звонка;
• в аналитике языковые версии разделены — отдельными представлениями, фильтром по папке или параметром, чтобы видеть конверсию каждого рынка.

Если иностранных заявок много, иногда выгоднее вести их в отдельной CRM, привычной зарубежным менеджерам, и связать её с основной через интеграцию. Это решается на этапе проектирования, а не после запуска.

Юридические страницы для США и Европы

Переведённая российская политика конфиденциальности не подходит для иностранных посетителей. Для Европы ориентиром служит GDPR: понятное описание, какие данные собираются, на каком основании, кому передаются и как человек может их удалить, а также согласие на необязательные файлы cookie до их установки. В США единого федерального закона нет, зато есть законы отдельных штатов, самый известный — калифорнийский CCPA с поправками CPRA. Тексты таких страниц лучше доверить юристу, знакомому с правилами нужного рынка, а сайт — подготовить технически: баннер согласия, настройки cookie, ссылки в подвале каждой страницы.

Поддержка: как не дать версиям разойтись

Англоязычная версия, которую сделали один раз и забыли, через полгода начинает вредить: устаревшие цены, исчезнувшие услуги, новости только на русском. Чтобы этого не случилось, нужны три вещи.

• CMS с поддержкой языков, где у каждой страницы видны связанные версии и понятно, какие переводы устарели. Для WordPress это решается плагинами многоязычности, но связка с визуальным конструктором быстро тяжелеет — в таких случаях хорошо работает headless WordPress с отдельным быстрым фронтендом.
• Процесс: любое изменение на русской версии автоматически создаёт задачу на перевод, а у английской версии есть ответственный.
• Решение о составе: не обязательно переводить всё. Блог или архив новостей можно оставить на русском, если английская аудитория в нём не нуждается. Главное, чтобы в английской навигации не было ссылок на непереведённые разделы.

Как выбрать: наше правило

Если английская версия нужна партнёрам, инвесторам или для солидности, достаточно перевода ключевых страниц с редактурой в подпапке /en/, с hreflang и переключателем. Если вы продаёте иностранным клиентам — нужна полноценная локализация: цены, контакты, формы, CRM, юридические страницы и собственная английская семантика. Если же у рынка своё предложение, отдельная команда и маркетинговый бюджет, разумнее делать отдельный сайт под этот рынок.

Многоязычность проще заложить при создании сайта, чем добавлять потом: структура адресов, шаблоны и CMS сразу проектируются под несколько языков. Мы делаем многоязычные сайты и корпоративные сайты с англоязычной версией с первого дня — с hreflang, переключателем, раздельной аналитикой и формами, которые ведут заявки в нужную воронку.