Основной Поток

SEO многоязычного сайта в Казахстане: русский, казахский и английский

2025-01-27 09:00 SEO

SEO многоязычного сайта в Казахстане: русский, казахский и английский

Многоязычный сайт можно нормально продвигать в Google, если у каждой языковой версии есть собственный URL, полноценный перевод, корректный hreflang и правильный canonical.
Для Казахстана чаще всего речь идёт о трёх версиях:
  • русском;
  • казахском;
  • английском.
Главная задача SEO здесь не в том, чтобы просто перевести существующий текст. Нужно построить структуру так, чтобы Google понимал, какие страницы являются альтернативными языковыми версиями, а пользователь всегда попадал на подходящий ему язык.

Как должна выглядеть структура многоязычного сайта

Если сайт создаётся с нуля, понятный вариант выглядит так:
site.kz/ru/
site.kz/kk/
site.kz/en/

Для конкретной услуги:
site.kz/ru/services/seo/
site.kz/kk/services/seo/
site.kz/en/services/seo/

Каждый URL должен открывать полноценную самостоятельную страницу.
При этом наличие /ru/, /kk/ или /en/ само по себе не улучшает позиции. Такие папки прежде всего помогают поддерживать понятную архитектуру сайта.
Если русский сайт уже давно работает без /ru/, например:
site.kz/services/seo/

не обязательно переносить весь раздел на новый URL только ради симметрии.
Можно сохранить существующую русскую страницу и добавить:
site.kz/kk/services/seo/
site.kz/en/services/seo/

Главное — правильно связать версии между собой.

Казахский язык в hreflang — kk, а не kz

Это одна из наиболее частых технических ошибок на сайтах Казахстана.
Для hreflang используются коды языков:
ru — русский
kk — казахский
en — английский

Поэтому правильно:

hreflang="kk"

А не:

hreflang="kz"

KZ обозначает Казахстан как страну, а не казахский язык.
Если нужно указать и язык, и регион, можно использовать:
ru-KZ
kk-KZ
en-KZ

Сначала указывается язык, затем страна.

Обязательно ли менять папку /kz/ на /kk/

Нет.
Важно различать код языка в hreflang и название папки в URL.
Например, адрес:
site.kz/kz/

может существовать, а в коде страницы использоваться:

hreflang="kk"

Google не определяет язык только по названию папки.
Если сайт уже индексируется с /kz/, менять все адреса только ради /kk/ обычно не имеет смысла.
Но если структура создаётся с нуля, вариант /kk/ логичнее, потому что соответствует международному коду казахского языка.

Что такое hreflang

hreflang сообщает Google, что несколько URL являются языковыми или региональными версиями одной страницы.
Например:

<link rel="alternate" hreflang="ru"
href="https://site.kz/ru/services/seo/">

<link rel="alternate" hreflang="kk"
href="https://site.kz/kk/services/seo/">

<link rel="alternate" hreflang="en"
href="https://site.kz/en/services/seo/">

Так Google получает явный сигнал:
  • это русская версия;
  • это казахская версия;
  • это английская версия.
Сам hreflang не переводит страницу и не является способом искусственно повысить позиции.
Он помогает поисковой системе сопоставлять языковые варианты.

Hreflang должен быть взаимным

Каждая страница должна ссылаться:
  • на себя;
  • на остальные языковые версии.
Если русская версия содержит ссылки на казахскую и английскую, то казахская и английская тоже должны содержать тот же набор.
Например, на всех трёх страницах:

<link rel="alternate" hreflang="ru"
href="https://site.kz/ru/services/seo/">

<link rel="alternate" hreflang="kk"
href="https://site.kz/kk/services/seo/">

<link rel="alternate" hreflang="en"
href="https://site.kz/en/services/seo/">

Это важно: связь должна быть двусторонней.

Связывайте только эквивалентные страницы

Нельзя связывать русскую страницу услуги с казахской главной только потому, что нужного перевода ещё нет.
Правильно:
/ru/services/seo/
↕
/kk/services/seo/
↕
/en/services/seo/

Неправильно:
/ru/services/seo/
↕
/kk/

Если казахской версии конкретной страницы пока нет, лучше вообще не добавлять для неё hreflang="kk".
Когда перевод будет опубликован, страницу можно добавить в кластер.

Что такое x-default

Дополнительно можно использовать:

<link rel="alternate" hreflang="x-default"
href="https://site.kz/">

x-default указывает Google страницу по умолчанию для пользователей, которым не подходит ни одна из явно заданных языковых или региональных версий.
Например, это может быть:
  • страница выбора языка;
  • основная версия сайта;
  • нейтральная международная страница.
Использовать x-default обязательно не всегда, но для сложных многоязычных проектов он может быть полезен.

Как настроить canonical

Одна из самых серьёзных ошибок — отправлять canonical всех языковых версий на русский URL.
Например, есть:
/ru/services/seo/
/kk/services/seo/
/en/services/seo/

Если каждая страница действительно переведена, логика должна быть такой:
RU canonical → RU
KK canonical → KK
EN canonical → EN

А отношения между языковыми версиями передаются через hreflang.
Не нужно делать:
KK canonical → RU
EN canonical → RU

иначе сайт сам сообщает поисковой системе, что русская версия является предпочтительной вместо самостоятельных языковых страниц.

Переведённые страницы — это не обязательно дубли

Полноценная русская и казахская версии одной услуги могут содержать один и тот же смысл, но на разных языках.
Это нормально.
Проблема возникает, когда страница формально считается казахской, но на казахский переведены только:
  • меню;
  • H1;
  • кнопки;
а основной текст остаётся русским.
Такая страница уже не является полноценной языковой версией.

Переводите не только основной текст

Для полноценной локализации стоит адаптировать:
  • Title;
  • Description;
  • H1;
  • H2 и H3;
  • основной текст;
  • кнопки;
  • формы;
  • меню;
  • футер;
  • сообщения после отправки форм;
  • подписи;
  • содержательные alt изображений.
Пользователь должен видеть нормальную страницу на своём языке, а не частично переведённый интерфейс.

Семантику нужно собирать отдельно для каждого языка

Одна из главных ошибок multilingual SEO — взять русские ключевые слова и дословно перевести их на казахский и английский.
Реальный поиск так не работает.
Пользователи разных языков могут:
  • использовать другие формулировки;
  • смешивать казахские и русские термины;
  • искать услугу под другим названием;
  • чаще использовать брендовые или английские слова;
  • иметь немного другой интент.
Поэтому лучше делать три отдельных исследования:
Русский
Запросы русскоязычной аудитории.
Казахский
Отдельное исследование реальных казахскоязычных запросов.
Английский
Запросы международной и англоязычной аудитории.
Перевод помогает создать страницу.
Keyword research помогает понять, как её реально ищут.

Не нужно искусственно смешивать языки

На казахской странице могут естественно встречаться русские или английские профессиональные термины, если именно так ими пользуется аудитория.
Но превращать текст в смесь языков ради дополнительных ключей не стоит.
Основное содержимое должно оставаться однозначно казахским.
То же относится к русской и английской версиям.

Автоматический перевод можно использовать как черновик

AI и машинный перевод способны значительно ускорить локализацию большого сайта.
Но перед публикацией текст нужно проверять.
Особенно внимательно:
  • коммерческие предложения;
  • профессиональные термины;
  • юридические тексты;
  • медицинские материалы;
  • финансовую информацию;
  • цены;
  • условия;
  • CTA.
Проблема не в самом AI-переводе.
Проблема — в публикации неестественного или неправильного текста без редакторской проверки.

Нужно ли переводить весь сайт сразу

Нет.
Допустим, на русском сайте уже 150 страниц.
Нет необходимости перед запуском казахской версии переводить все 150.
Сначала можно локализовать наиболее ценные страницы:
  1. Главную.
  2. Основные услуги.
  3. О компании.
  4. Контакты.
  5. Цены.
  6. Ключевые коммерческие посадочные.
  7. Важные статьи.
Затем расширять раздел на основании реального поискового спроса.
Лучше 20 полноценных казахских страниц, чем 150 слабых машинных переводов.

Нужна ли английская версия каждому бизнесу

Нет.
Она оправдана, если компания действительно работает с:
  • иностранными клиентами;
  • экспатами;
  • туристами;
  • международным B2B;
  • инвесторами;
  • зарубежными партнёрами.
Если бизнес оказывает локальные услуги только русско- и казахскоязычной аудитории Алматы, английская версия может быть не первым SEO-приоритетом.
Количество языков должно соответствовать реальному рынку бизнеса.

Как должен работать переключатель языка

Пользователь должен иметь возможность изменить язык вручную.
Причём желательно переводить его не просто на главную страницу другого языка, а на эквивалент текущей.
Например:
пользователь находится здесь:
site.kz/ru/services/seo/

нажимает «ҚАЗ» и попадает:
site.kz/kk/services/seo/

а не:
site.kz/kk/

Это особенно важно для:
  • услуг;
  • товаров;
  • статей;
  • кейсов.

Не стоит жёстко перенаправлять пользователя по языку браузера

Можно предложить пользователю подходящую языковую версию, но принудительное автоматическое перенаправление может создавать проблемы.
Например:
пользователь открыл английскую страницу, но сайт каждый раз отправляет его на русскую только из-за настроек браузера.
Лучше:
  • дать доступ ко всем языкам;
  • показать понятный переключатель;
  • при необходимости предложить рекомендуемую версию;
  • сохранить выбор пользователя.
Каждый языковой URL должен оставаться доступным напрямую.

Можно ли делать внутренние ссылки между языками

Да.
Старая рекомендация «русская страница должна ссылаться только на русские» слишком категорична.
Большинство обычных внутренних ссылок действительно должно оставаться внутри текущего языка.
Например:
/ru/services/seo/
→ /ru/cases/
→ /ru/contacts/

Но переключатель языка должен связывать страницу с:
/kk/services/seo/
/en/services/seo/

То есть нужно разделять:
  • тематическую перелинковку;
  • переключение языковых версий.

Нужны ли отдельные sitemap для каждого языка

Не обязательно.
Можно использовать один sitemap, содержащий все индексируемые языковые страницы.
Отдельные sitemap:
sitemap-ru.xml
sitemap-kk.xml
sitemap-en.xml

могут быть удобны для большого сайта, но это не обязательное требование SEO.
Главное:
  • нужные URL доступны;
  • индексируемы;
  • присутствуют в структуре сайта;
  • sitemap корректен.

Hreflang можно передавать несколькими способами

Google поддерживает:
  • <link> в HTML;
  • HTTP headers;
  • XML sitemap.
Не нужно обязательно использовать все три варианта одновременно.
Для корпоративного сайта на Tilda проще всего обычно использовать hreflang в <head> каждой страницы.

Как добавить hreflang на Tilda

В Tilda код можно разместить в настройках страницы:
Настройки страницы → Дополнительно → HTML-код для вставки внутрь Head
Например:

<link rel="alternate" hreflang="ru"
href="https://site.kz/ru/services/seo/">

<link rel="alternate" hreflang="kk"
href="https://site.kz/kk/services/seo/">

<link rel="alternate" hreflang="en"
href="https://site.kz/en/services/seo/">

<link rel="alternate" hreflang="x-default"
href="https://site.kz/ru/services/seo/">

Один и тот же набор нужно добавить на все соответствующие языковые страницы.
После этого страницу необходимо переопубликовать.

Что делать с языком сайта в Tilda

В Tilda также можно указать язык проекта в настройках сайта.
Это полезно для корректного HTML и интерфейса.
Но одна настройка языка проекта не заменяет:
  • отдельные URL;
  • hreflang;
  • переводы;
  • canonical;
  • переключатель языков.
Многоязычное SEO нужно строить комплексно.

Папки или поддомены

Оба варианта допустимы.

Папки

site.kz/ru/
site.kz/kk/
site.kz/en/

Поддомены

ru.site.kz
kk.site.kz
en.site.kz

Для небольшого и среднего корпоративного сайта папки обычно проще обслуживать.
Поддомены могут быть удобнее, если языковые версии технически существуют как отдельные проекты.
Не стоит менять уже работающую архитектуру без веской причины только потому, что другой вариант выглядит аккуратнее.

Отдельные домены тоже возможны

Например:
example.kz
example.com
example.ru

Но тогда бизнесу приходится поддерживать несколько самостоятельных сайтов.
Для одной компании, работающей прежде всего в Казахстане, чаще проще использовать один основной домен и языковые разделы.

Какие ошибки встречаются чаще всего

hreflang="kz"

Для казахского нужен kk.

Одинаковый URL для всех языков

Язык переключается JavaScript, а адрес страницы не меняется.
Лучше использовать отдельные URL.

Canonical казахской страницы ведёт на русскую

Так языковая версия может потерять самостоятельность.

Hreflang стоит только на одной странице

Связи должны быть взаимными.

Переведено только меню

Основной контент остался на другом языке.

Русские ключевые слова просто переведены

Поисковая семантика каждого языка должна исследоваться отдельно.

Переключатель отправляет только на главную

Лучше открывать эквивалент текущей страницы.

Созданы сотни машинных переводов

Количество URL не компенсирует слабую локализацию.

Указан hreflang на несуществующую страницу

В кластер включаются только реальные доступные URL.

После смены URL забыли обновить hreflang

При миграции нужно проверить:
  • redirects;
  • canonical;
  • hreflang;
  • sitemap;
  • внутренние ссылки.

Как проверить мультиязычный сайт

Для каждой важной страницы проверьте:
  1. URL открывается с кодом 200.
  2. Страница не закрыта от индексации.
  3. Язык основного текста соответствует версии.
  4. Canonical ведёт на правильный URL.
  5. Hreflang использует правильный языковой код.
  6. Страница содержит ссылку на себя.
  7. Остальные языковые версии ссылаются обратно.
  8. Hreflang ведёт на эквивалентные страницы.
  9. Переключатель языка работает.
  10. Страница доступна без принудительного редиректа.
  11. Title и Description локализованы.
  12. URL присутствует во внутренней структуре сайта.
  13. Страница присутствует в sitemap.
  14. Google Search Console видит ожидаемый canonical.

Как анализировать языковые версии в Search Console

После запуска важно смотреть не только индексирование.
Для каждого языкового раздела анализируйте:
  • показы;
  • клики;
  • CTR;
  • поисковые запросы;
  • посадочные страницы;
  • динамику позиций.
При структуре:
/ru/
/kk/
/en/

данные удобно фильтровать по URL.
Не стоит напрямую сравнивать абсолютный объём русского и казахского трафика без учёта реального спроса.
В одной нише казахскоязычная аудитория может быть значительной, в другой пока существенно меньше.
Главное — оценивать, насколько хорошо сайт охватывает доступный спрос конкретного языка.

Нужно ли делать одинаковый блог на трёх языках

Не обязательно.
Основные коммерческие страницы логично локализовать.
А контентный план можно строить отдельно.
Например, определённая тема может иметь заметный поисковый спрос на русском языке, но почти отсутствовать на английском.
И наоборот.
Поэтому зрелая multilingual SEO-стратегия выглядит так:
единая структура бизнеса + отдельный поисковый спрос каждого языка.
А не:
написали 100 русских статей → автоматически перевели все 100 два раза.

Практическая структура для сайта бизнеса в Казахстане

Если проект создаётся с нуля, можно использовать:
/
├── ru/
│ ├── services/
│ ├── cases/
│ ├── blog/
│ └── contacts/
│
├── kk/
│ ├── services/
│ ├── cases/
│ ├── blog/
│ └── contacts/
│
└── en/
├── services/
├── cases/
├── blog/
└── contacts/

Если русский сайт уже существует без /ru/, его можно сохранить и добавлять новые языки отдельно.
Не нужно создавать большую SEO-миграцию только ради идеально симметричных URL.

Чек-лист мультиязычного SEO

Перед запуском проверьте:
URL
У каждого языка есть отдельный адрес.
Контент
Основной текст действительно переведён.
Hreflang
Используются ru, kk, en.
Canonical
Каждая полноценная языковая версия указывает на себя.
Взаимность
Все альтернативные страницы связаны между собой.
Переключатель
Пользователь может вручную изменить язык.
Семантика
Поисковые запросы исследованы отдельно для каждого языка.
Метатеги
Title и Description локализованы.
Внутренние ссылки
Основная навигация ведёт внутри текущего языка.
Sitemap
Содержит нужные индексируемые страницы.
Search Console
Используется для проверки реального спроса и индексации.

Итог

Многоязычный сайт в Казахстане можно нормально продвигать одновременно на русском, казахском и английском.
Основная схема:
отдельный URL → полноценный перевод → отдельная семантика → self-canonical → взаимный hreflang → переключатель языка → Search Console.
Самая важная техническая деталь:
код казахского языка — kk, а не kz.
При этом не нужно массово менять уже работающие URL только ради красивой структуры и не нужно переводить весь сайт за один этап.
Для существующего проекта лучше начать с коммерчески важных страниц, правильно связать языковые версии и постепенно расширять каждый раздел на основании реального поискового спроса.