Яндекс не индексирует переведённые версии страниц сайта на qTranslate или выдаёт ошибки в Вебмастере — типичный признак того, что плагин формирует мультиязычный контент способом, который робот не может корректно обработать. Чаще всего проблема сводится к тому, как именно qTranslate хранит и отдаёт переводы: все языки в одном посте, разделённые служебными тегами вроде [:ru]...[:en], либо динамическая подмена контента без отдельных URL.
Ниже разберём, как проверить, что именно видит робот Яндекса, почему переводы выпадают из поиска и какие варианты исправления существуют — от настройки до миграции на современное решение. Инструкции ориентированы на WordPress с плагинами семейства qTranslate (qTranslate-X, qTranslate-XT и их форки).
Как qTranslate хранит переводы и почему это проблема для Яндекса
Классический qTranslate сохраняет все языковые версии записи в одном поле базы данных, разделяя их служебными метками. На фронтенде плагин вырезает лишние языки и показывает посетителю только нужный. Для человека всё выглядит нормально, но поисковый робот может получить совсем другую картину.
Возможные сценарии сбоя:
- 🔎 Робот видит сырой текст со служебными тегами
[:ru]и[:en]вместо чистого контента — страница распознаётся как мусорная. - 🌐 Перевод отдаётся по тому же URL без языкового префикса, и Яндекс считает версии дублями.
- 🚫 Языковые подкаталоги или поддомены закрыты в
robots.txtлибо отдают код ответа, отличный от 200. - ⚙️ Конфликт с SEO-плагином: в
<head>отсутствуют или дублируются атрибуты hreflang.
⚠️ Внимание: qTranslate-X официально не поддерживается с 2016 года. На современных версиях WordPress и PHP плагин может работать со сбоями, и часть проблем с индексацией — следствие общей устарелости кода, а не отдельной настройки.
Диагностика: что именно видит робот Яндекса
Первый шаг — посмотреть на страницу глазами поисковика. Откройте Яндекс Вебмастер и используйте инструмент проверки ответа сервера и просмотра страницы как робот. Если в полученном коде присутствуют служебные теги вида [:] или контент на «неправильном» языке — источник проблемы найден.
Дополнительно проверьте вручную:
- 🧭 Откройте исходный код страницы (Ctrl+U) и найдите служебные метки qTranslate — их не должно быть в готовом HTML.
- 🔗 Убедитесь, что каждая языковая версия имеет собственный стабильный URL (префикс
/en/, параметр или поддомен) и открывается без редиректов. - 📄 Проверьте, что в
<head>каждой версии указан корректный<html lang="...">и взаимные ссылки hreflang. - 🗺 Откройте
sitemap.xmlи убедитесь, что туда попадают адреса всех языковых версий, а не только основного языка.
Проверка robots.txt и ответов сервера
Нередко языковые версии не индексируются из-за банальных запретов. Откройте файл robots.txt вашего сайта и проверьте, не закрыты ли директивой Disallow языковые префиксы или параметры, через которые qTranslate отдаёт переводы.
Затем проверьте HTTP-ответы каждой языковой версии. Сделать это можно через инструмент «Проверка ответа сервера» в Вебмастере или любым сервисом просмотра заголовков. Ожидаемый результат — код 200 OK для каждой версии.
| Код ответа | Что означает | Действие |
|---|---|---|
| 200 OK | Страница доступна роботу | Проверять контент и hreflang |
| 301/302 | Редирект на другой URL | Убрать лишние цепочки перенаправлений |
| 403/404 | Доступ запрещён или страницы нет | Проверить .htaccess и настройки ЧПУ |
| 500 | Внутренняя ошибка сервера | Смотреть логи PHP, конфликт плагинов |
Настройка hreflang и канонических адресов
Для мультиязычного сайта критично, чтобы каждая версия ссылалась на остальные через атрибут hreflang. Сам qTranslate этим не занимается — обычно разметку добавляет SEO-плагин (Yoast, Rank Math) или отдельное решение. Проверьте, что связка работает корректно и не возникает конфликтов: например, канонический URL каждой языковой версии должен указывать сам на себя, а не на русскую версию.
Типичная ошибка — SEO-плагин проставляет rel="canonical" на основной язык для всех версий. В этом случае Яндекс обоснованно склеивает страницы и выкидывает переводы из индекса. Исправляется настройкой SEO-плагина или фильтром в functions.php, который переопределяет canonical в зависимости от текущего языка qTranslate.
add_filter('wpseo_canonical', function($url) {
if (function_exists('qtranxf_getLanguage')) {
$lang = qtranxf_getLanguage();
// вернуть URL текущей языковой версии
}
return $url;
});
Приведённый код — лишь шаблон подхода: точная реализация зависит от вашего SEO-плагина и форка qTranslate. Перед правками сделайте резервную копию сайта.
☑️ Проверка мультиязычной индексации
Конфликты с кэшированием и другими плагинами
Если на сайте работает плагин кэширования, возможна ситуация, когда роботу отдаётся закэшированная версия не на том языке или сырой текст до обработки qTranslate. Проверьте, что кэш разделяется по языковым версиям (по URL или cookie), либо временно отключите кэш и повторите проверку ответа сервера.
Также конфликтовать могут плагины, модифицирующие контент «на лету»: автопереводчики, оптимизаторы HTML, минификаторы. Метод диагностики стандартный — отключать плагины по одному на тестовой копии сайта и смотреть, исчезают ли служебные теги из кода страницы.
⚠️ Внимание: не проводите эксперименты с отключением плагинов на рабочем сайте в часы пик. Используйте staging-копию или период минимальной посещаемости — qTranslate тесно переплетён с выводом контента, и его отключение мгновенно «обнажит» служебные метки для всех посетителей.
Почему теги [
ru] видны в коде страницы:Это значит, что фильтр qTranslate не сработал на этапе вывода. Причины: плагин частично несовместим с текущей версией WordPress или PHP, контент выводится кастомным кодом в обход стандартных фильтров the_content, либо другой плагин перехватывает вывод раньше. Проверьте, обновлён ли ваш форк (например, qTranslate-XT), и как именно шаблон выводит проблемные поля.
Миграция на поддерживаемое решение
Если диагностика показывает, что корень проблем — устаревшая архитектура qTranslate, разумный выход — переход на поддерживаемый мультиязычный плагин с отдельными URL и корректной SEO-разметкой: Polylang, WPML или их аналоги. Эти решения хранят переводы как отдельные записи, автоматически формируют hreflang и нормально воспринимаются поисковиками.
Миграция выполняется в несколько этапов: резервная копия, установка нового плагина, конвертация контента (для популярных связок существуют инструменты импорта из qTranslate), настройка языковых URL и постановка редиректов со старых адресов на новые. После переезда обязательно обновите карту сайта и отправьте её в Яндекс Вебмастер повторно.
Часто задаваемые вопросы
Почему Яндекс видит теги [:ru] и [:en] в тексте страницы?
Это означает, что фильтр qTranslate не обработал контент перед выводом. Возможные причины: несовместимость плагина с версией WordPress или PHP, вывод поля в шаблоне в обход стандартных фильтров, конфликт с другим плагином. Проверьте актуальность форка qTranslate и способ вывода проблемных полей в теме.
Склеиваются ли языковые версии как дубли?
Да, если у версий нет разных URL или canonical указывает на основной язык. Каждая версия должна иметь собственный адрес, самоссылочный canonical и взаимные hreflang — тогда Яндекс корректно различает их.
Нужно ли добавлять языковые версии в sitemap?
Да. Карта сайта должна содержать URL всех языковых версий. Большинство SEO-плагинов делают это автоматически, но при работе qTranslate стоит проверить результат вручную, открыв sitemap.xml в браузере.
qTranslate давно не обновляется — это критично?
Оригинальный qTranslate-X заброшен, но существуют поддерживаемые сообществом форки, например qTranslate-XT. Даже с форком архитектура «все языки в одном поле» остаётся слабым местом для SEO, поэтому в долгосрочной перспективе надёжнее миграция на Polylang или WPML.
Как быстро проверить, индексирует ли Яндекс переводы?
Введите в поиске Яндекса оператор site:вашдомен.ru вместе с языковым префиксом или уникальной фразой из перевода. Если страницы нет в выдаче, проверьте её статус в разделе «Индексирование» Яндекс Вебмастера — там видна причина исключения.