# General Translation Knowledge Base: Как сделать сайт многоязычным? URL: https://generaltranslation.com/ru/kb/make-website-multilingual.mdx Docs index: https://generaltranslation.com/llms.txt Description: Выберите, где будут храниться переводы — в прокси, плагине CMS, конструкторе сайтов или в вашем собственном коде, — а затем выделите каждому языку собственный URL, как рекомендует Google. Переводите страницы целиком, включая заголовки и метаописания, связывайте языковые версии с помощью hreflang и предлагайте переключатель языка вместо автоматического перенаправления посетителей. Category: Интернационализация Last updated: 2026-10-20 Authors: Kevin Wu, Jackie Chen Published: 2026-10-20 Многоязычный сайт отдаёт каждую страницу на нескольких языках: у каждой версии свой URL, а поисковые системы знают, как эти версии связаны между собой. Подходы различаются прежде всего тем, где хранится переведённый текст, и от этого зависит, какой контроль над SEO, качеством и обновлениями останется у вас. Поэтому определитесь с подходом до того, как начнёте что-либо переводить. ## Какой подход выбрать? Самый простой вариант не требует от вас никаких усилий: браузеры посетителей умеют переводить страницы сами. Например, [Chrome](https://support.google.com/chrome/answer/173424) может перевести страницу с помощью Google Translate, исходя из языковых настроек читателя. Это помогает отдельному читателю, но не делает ваш сайт многоязычным. Языковых URL для индексации нет, проверить результат вы не можете, а единственное, на что вы можете повлиять, — пометить текст (например, названия брендов) атрибутом [`translate="no"`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/translate). Прокси-сервисы перевода и JavaScript-оверлеи работают поверх готового сайта. [Обратный прокси Weglot](https://weglot.com/technical-presentation/) получает вашу страницу, переводит её содержимое через API Weglot и отдаёт результат на языковом поддомене или в подкаталоге, добавляя hreflang. JavaScript-интеграция Weglot, напротив, вставляет переводы в браузере уже после загрузки страницы; по словам Weglot, поисковые системы такие переводы не видят, поэтому этот режим рекомендуется для тестирования или закрытого контента. В обоих случаях переводы хранятся в панели управления поставщика. Плагины для CMS и конструкторы сайтов хранят переводы внутри платформы. В WordPress [WPML](https://wpml.org/documentation/getting-started-guide/language-setup/language-url-options/) размещает языки в каталогах, на отдельном домене или поддомене для каждого языка либо в параметре `?lang=`, а [Polylang](https://wordpress.org/plugins/polylang/) определяет язык по коду в URL либо по отдельному поддомену или домену. [Webflow Localize](https://webflow.com/localization) отдаёт локали в подкаталогах вроде `/es/`, переводит мета-заголовки и описания и генерирует карту сайта с тегами hreflang. Многоязычный режим Squarespace [подключает Weglot](https://support.squarespace.com/hc/en-us/articles/205809778-Creating-a-multilingual-site-with-Weglot) на сайтах версии 7.1, а переводы редактируются в Weglot, поскольку сам Squarespace редактировать их не умеет. Генераторы статических сайтов и библиотеки интернационализации хранят переводы в вашем репозитории. [Docusaurus](https://docusaurus.io/docs/i18n/introduction) хранит переведённые файлы в `i18n/[locale]/` и автоматически задаёт заголовки hreflang. [Hugo](https://gohugo.io/content-management/multilingual/) определяет язык страницы по суффиксу имени файла (например, `about.fr.md`) или по каталогу контента, а затем отдаёт её с префиксом вроде `/fr/`. В приложении на React, Next.js или Vue библиотека вроде i18next или next-intl выполняет рендеринг переводов из файлов, которые поддерживаете вы. Сами переводы ни один из этих инструментов не создаёт: вы пишете их сами, заказываете или подключаете инструмент перевода. | Подход | Где хранятся переводы | Контроль SEO | Контроль качества | Трудозатраты на разработку | Лучше всего подходит для | | ---------------------------------------------------------- | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | Перевод в браузере | Генерируются в браузере каждого посетителя | Нет; языковых URL нет | Только `translate="no"` | Нет | Читателей сайтов, которые вы не локализовали | | Прокси или оверлей (Weglot) | Панель управления поставщика | Режим прокси добавляет языковые URL и hreflang; режим JavaScript не индексируется | Машинный перевод, затем правки или заказной перевод, выполняемый людьми, в редакторе поставщика | Изменение DNS или тег script | Готовых сайтов, которые вы не хотите переделывать | | Плагин CMS (WPML, Polylang) | Ваша база данных WordPress | Формат URL и переключатель настраиваются в плагине | Ручной, машинный или агентский перевод внутри WordPress | Настройка плагина, затем работа над каждой страницей | Сайтов на WordPress | | Конструктор сайтов (Webflow Localize, Squarespace) | Конструктор или Weglot для Squarespace | Управляется конструктором | Машинный перевод плюс ручные правки | Низкие | Сайтов, созданных и размещённых на этом конструкторе | | i18n в генераторе статических сайтов (Docusaurus, Hugo) | Файлы в вашем репозитории | Полный; URL и шаблоны под вашим контролем | Зависит от процесса, в котором создаются файлы | Умеренные; перевод — отдельная задача | Сайтов документации и контентных сайтов на основе Markdown | | General Translation | Сгенерированные файлы в вашей сборке или CDN GT | Маршрутизация и метаданные под вашим контролем; `gt-next` предоставляет вспомогательные функции для маршрутизации по локалям | Контекст, извлекаемый из кода, общая терминология и встроенная проверка | Пометить исходный текст или подключить существующие каталоги, сгенерировать переводы перед сборкой, протестировать локали | Сайтов, которыми управляют разработчики и которым нужна не только рендеринг, но и генерация переводов | | Только библиотека интернационализации (i18next, next-intl) | Файлы перевода в вашем репозитории | Полный | Зависит от процесса, в котором создаются файлы | Извлечение строк, маршрутизация, доставка переводов и QA; существующие интеграции могут взять часть работы на себя | Приложений, в которых процесс перевода уже налажен | Если маркетинговой команде нужны переведённые страницы без пересборки сайта, используйте прокси или встроенную функцию конструктора сайтов. Для WordPress подойдёт CMS-плагин. Если сайт ведут разработчики и переводы уже есть, используйте средства i18n генератора статических сайтов или библиотеку интернационализации. Выбирайте General Translation, если вам также нужно генерировать и проверять обновления в рамках релизов: его CLI умеет переводить существующие файлы, не заменяя вашу библиотеку. Объём работы зависит от того, как у вас устроены маршрутизация, контент и процесс проверки; в таблице перечислены задачи, а не замеренное время настройки. ## Вопросы, на которые должен ответить любой подход Какой бы подход вы ни выбрали, в нём придётся решить семь вопросов — примерно в таком порядке. ### 1. Выберите языки и локали Начните с тех рынков, откуда уже приходят ваш трафик и клиенты. Каждая новая локаль — это набор страниц, которые нужно перевести, проверить и поддерживать в актуальном состоянии. Поэтому добавляйте региональный вариант только там, где для этой аудитории отличаются формулировки или форматы: например, бразильский и европейский португальский (`pt-BR`, `pt-PT`) различаются лексикой, а одной локали `fr` вполне достаточно для франкоязычных читателей из разных стран. О том, как записывать и выбирать эти теги, рассказывается в [руководстве по кодам локалей](/docs/platform/core/guides/locale-codes). ### 2. Выберите структуру URL Google [рекомендует использовать отдельный URL для каждой языковой версии](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites), а не один URL, язык которого меняется в зависимости от cookie-файла или настроек браузера. Подойдут и подкаталоги (`example.com/fr/`), и поддомены, и национальные домены; их сравнение приведено в [руководстве по структуре URL](/kb/multilingual-url-structure). ### 3. Переведите контент и метаданные Google [определяет язык страницы по её видимому содержимому](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites), а не по атрибутам `lang` или URL, и не рекомендует переводить только навигацию, оставляя основной текст на исходном языке. Переводите страницу целиком, а также её заголовок, метаописание, alt-текст изображений, сообщения об ошибках в формах и письма, которые отправляет страница. При этом всё равно указывайте `` в каждой языковой версии: [браузеры и программы чтения с экрана используют этот атрибут](https://www.w3.org/International/questions/qa-lang-why) для выбора шрифтов, расстановки переносов и озвучивания текста. ### 4. Добавьте hreflang Аннотации hreflang сообщают поисковым системам, какие URL являются языковыми версиями одной и той же страницы, чтобы в результатах поиска пользователь видел версию на своём языке. В статье [Что такое hreflang](/kb/what-is-hreflang) описаны правила, `x-default` и типичные ошибки. ### 5. Добавьте переключатель языка Добавьте на страницу заметный элемент управления, который переводит посетителя на ту же страницу на другом языке, и не [перенаправляйте его автоматически](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) в зависимости от предполагаемого языка — Google не рекомендует так делать. Подробнее см. [руководство по переключателю языка](/kb/language-switcher), а о том, как выбрать подходящий язык для первого посещения, рассказывается в статье [об определении языка пользователя](/kb/detect-user-language). ### 6. Локализуйте форматирование Даты, числа, валюты и формы множественного числа подчиняются разным правилам в зависимости от локали: `1,234.5` в английском записывается как `1.234,5` в немецком. API `Intl` в JavaScript и большинство библиотек интернационализации форматируют такие значения за вас. Если вы добавляете арабский или иврит, макет также нужно отразить зеркально — см. [CSS для right-to-left](/kb/right-to-left-css). ### 7. Поддерживайте переводы в актуальном состоянии Версии сайта на других языках устаревают, как только кто-то впервые правит исходный текст, а перевод никто не запускает заново. Решите, кто или что будет переводить изменения и когда: при каждой публикации, при каждом развертывании или по графику проверок. Перед запуском пройдите [чек-лист запуска многоязычного приложения](/kb/multilingual-app-launch-checklist) для каждой локали. ## Как General Translation делает сайт многоязычным Если сайт или приложение написаны в коде, выполните `npx gt@latest` в проекте Next.js или React: [мастер настройки](/docs/cli/quickstart) определит фреймворк и создаст конфигурацию. Затем оберните существующую разметку в [``](/docs/react/reference/components/t) (в `gt-vue` есть такой же компонент): текст останется там, где он написан, и вам не придётся поддерживать отдельный ключ источника для каждого сообщения. Перед сборкой выполните [`npx gt translate`](/docs/cli/reference/commands/translate), чтобы сгенерировать переводы для всех локалей. Каждая настройка пошагово описана в руководствах «Быстрый старт» для [Next.js](/docs/react/nextjs-quickstart), [React](/docs/react/react-quickstart) и [Vue](/docs/vue/quickstart). [`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware) из `gt-next` обслуживает пути с префиксом локали, например `/es/about`. Однако по умолчанию основной язык остаётся без префикса, а такие URL перенаправляются в зависимости от cookie-файла локали посетителя или заголовка `Accept-Language`. Чтобы каждый URL с контентом всегда соответствовал одному языку, задайте `prefixDefaultLocale: true`. (Плюсы и минусы этого подхода описаны в статье [«Маршрутизация по локалям и SEO»](/kb/locale-routing-seo).) Размеченный JSX передаёт сервису перевода структуру элементов текста и все явно заданные контекстные заметки. Перед публикацией проверьте сгенерированные формулировки в [редакторе панели управления](/docs/platform/dashboard/guides/reviewing-translations). При последующих запусках совпадающие переводы используются повторно, поэтому после правки источника не нужно заново генерировать переводы для всего сайта. Помимо кода приложений, CLI переводит файлы [HTML](/docs/cli/reference/formats/html-files), [Markdown и MDX](/docs/cli/reference/formats/mdx-md-files), [Locadex](/docs/platform/locadex/quickstart) переводит документацию на Mintlify, Fern и Docusaurus, а интеграции позволяют подключить [Sanity](/docs/integrations/sanity/quickstart), [Payload CMS](/docs/integrations/payload/quickstart) и [Storyblok](/docs/integrations/storyblok/quickstart). Во всех случаях для терминологии и стиля используются общие [контекстные группы](/docs/platform/dashboard/guides/defining-context-for-translations). ## Ключевые выводы * Прежде всего решите, где будут храниться переводы. Браузерный перевод и JavaScript-оверлеи не создают индексируемых языковых страниц; прокси, конструкторы сайтов и плагины хранят переводы у поставщика или на платформе, а при подходах на основе кода переводы хранятся в вашем репозитории. * При любом подходе нужно решить одни и те же семь задач: локали, URL, переведённый контент и метаданные, hreflang, переключатель языков, форматирование и обновления. * Google рекомендует использовать отдельный URL для каждого языка, определяет язык по видимому контенту и просит не перенаправлять посетителей автоматически. * Для сайтов, написанных в коде, используйте [``](/docs/react/reference/components/t) для UI и [`npx gt translate`](/docs/cli/reference/commands/translate) для генерации переводов, затем настройте маршрутизацию и перед запуском протестируйте каждую локаль. ## Related questions - [Подкаталог, поддомен или ccTLD для многоязычного SEO](https://generaltranslation.com/ru/kb/multilingual-url-structure.mdx): Используйте подкаталоги вида example.com/de/, если один продукт работает на общем сайте с единым процессом релизов. На страну указывает только ccTLD, поддомены позволяют размещать версии на отдельном хостинге, параметры ?lang= Google не рекомендует, а «имиджевые» домены вроде .io и .ai считает общими. - [Что такое hreflang и как его настроить?](https://generaltranslation.com/ru/kb/what-is-hreflang.mdx): Hreflang сообщает Google, какие URL являются языковыми или региональными версиями одной и той же страницы, чтобы в результатах поиска показывалась нужная. Добавьте его с помощью HTML-тегов link, HTTP-заголовков Link или карты сайта, сделайте все ссылки взаимными и используйте корректные коды, например en-GB, а не en-UK. - [Переключатель языка: лучшие практики UX, SEO и доступности](https://generaltranslation.com/ru/kb/language-switcher.mdx): Называйте каждый язык на нём самом, например Deutsch или 日本語, и не используйте флаги — они обозначают страны. Каждый вариант должен вести на ту же страницу на выбранном языке через индексируемую ссылку. Запоминайте выбор в cookie-файле и никогда не перенаправляйте автоматически с локализованного URL. - [Чек-лист тестирования локализации для многоязычных приложений](https://generaltranslation.com/ru/kb/multilingual-app-launch-checklist.mdx): Проверьте девять аспектов в каждой поддерживаемой локали на сборке для рабочей среды: пользовательские сценарии целиком, включая состояния ошибок и письма; переключение языка; формы множественного числа; валюту и часовые пояса; увеличение длины текста; вёрстку для языков right-to-left; доступность; доставку переводов; индексируемые языковые URL. Задайте для каждой проверки явный критерий успешного прохождения. - [Какое ПО для локализации лучше всего подходит разработчикам?](https://generaltranslation.com/ru/kb/best-localization-software.mdx): Лучшее ПО для локализации для разработчиков переводит контент прямо там, где он написан в коде, учитывает контекст вашего продукта и поддерживает все языки в актуальном состоянии. General Translation делает это с помощью библиотек с открытым исходным кодом, контекстных групп и Locadex — AI-агента, который открывает пул-реквесты. ## Previous and next questions - Previous question: [Как поддержать RTL-языки (right-to-left) в CSS?](https://generaltranslation.com/ru/kb/right-to-left-css.mdx) - Next question: [Переключатель языка: лучшие практики UX, SEO и доступности](https://generaltranslation.com/ru/kb/language-switcher.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/ru/kb/sitemap.md) for every article.