Как настроить robots.txt для многоязычного сайта WordPress

На многоязычном WordPress robots.txt часто правят по привычке: закрывают все подряд, добавляют лишние директивы и потом удивляются, почему переводные страницы не попадают в индекс или в Search Console появляются странные URL. Проблема обычно не в самом файле, а в том, что его настраивают без понимания структуры сайта: языковые каталоги, служебные страницы, параметры фильтрации, sitemap и админка живут по разным правилам.

Ниже — рабочая схема для сайта, где переводы сделаны через плагин мультиязычности или код, а SEO-цель простая: не пускать в индекс мусор, но не мешать поисковику обходить нужные страницы на всех языках.

Когда robots.txt действительно мешает индексации

Сначала стоит проверить, не пытаетесь ли вы решить robots.txt проблему, которая на самом деле находится в noindex, canonical или настройках самого плагина перевода. Если переводные страницы открываются в браузере, но не индексируются, robots.txt — только один из возможных факторов.

Типичные симптомы

• в Search Console видны URL переводов, но статус обхода показывает Blocked by robots.txt;
• в индексе остаются только страницы основного языка;
• XML-sitemap содержит переводы, но бот не может их обойти;
• в robots.txt закрыты каталоги вида /en/, /de/, /fr/ или параметры, которые нужны для работы мультиязычности;
• закрыт /wp-content/uploads/, а изображения переводных страниц перестали нормально индексироваться.

Если у вас Polylang, WPML или другой плагин, сначала проверьте, как он формирует URL языков: подкаталоги, домены или параметры. От этого зависит, что именно можно закрывать без вреда.

Что должно быть в robots.txt на мультиязычном сайте

Базовая задача robots.txt — отсечь служебные разделы WordPress и не мешать обходу публичного контента. Для многоязычного сайта это означает: закрыть админку, системные файлы и лишние технические endpoints, но не трогать языковые URL и sitemap.

Безопасный базовый вариант

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/cache/
Disallow: /trackback/
Disallow: /cgi-bin/

Sitemap: https://example.com/sitemap_index.xml

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

Пошаговая настройка robots.txt для переведенных страниц

1. Определите структуру языковых URL

Если переводы живут в подкаталогах, например /en/ и /de/, не добавляйте их в Disallow только потому, что это «дополнительные разделы». Для поисковика это обычные страницы сайта. Закрывать их имеет смысл только если это служебные языковые маршруты, а не контент.

Если языки вынесены на поддомены, robots.txt нужен отдельно для каждого хоста. Файл robots.txt на example.com не управляет обходом en.example.com.

2. Оставьте sitemap доступным

Если sitemap закрыт или указан неверно, поисковик может дольше находить переводы. Убедитесь, что в robots.txt указан актуальный адрес карты сайта, а сама карта содержит только канонические URL, без дублей и лишних параметров.

3. Закройте только технические параметры

На мультиязычных сайтах часто появляются URL с параметрами вроде ?lang=, ?replytocom=, ?utm_ и похожими. Не стоит закрывать все параметры подряд, если они используются для навигации или переключения языка. Лучше точечно убрать только те, что создают мусорные дубли.

Как управлять robots.txt через код в WordPress

Если нужен предсказуемый результат, можно менять содержимое robots.txt через фильтр robots_txt. Это полезно, когда языковые каталоги формируются динамически и вы не хотите редактировать файл вручную после каждого изменения.

<?php
add_filter('robots_txt', function ($output, $public) {
    $lines = array();

    $lines[] = 'User-agent: *';
    $lines[] = 'Disallow: /wp-admin/';
    $lines[] = 'Allow: /wp-admin/admin-ajax.php';
    $lines[] = 'Disallow: /wp-includes/';
    $lines[] = 'Disallow: /wp-content/cache/';
    $lines[] = 'Disallow: /trackback/';

    $lines[] = '';
    $lines[] = 'Sitemap: ' . home_url('/sitemap_index.xml');

    return implode("\n", $lines);
}, 10, 2);

Этот вариант удобен, если вы хотите держать правила рядом с кодом темы или собственного плагина. Но не забывайте: если SEO-плагин тоже генерирует robots.txt, проверьте, кто именно отдает файл в итоге. Два источника правды здесь не нужны.

Если нужно убрать языковые параметры из обхода

Иногда сайт использует параметр языка, например ?lang=ru. В таком случае не закрывайте весь URL с вопросительным знаком, а ограничьте только конкретный технический шаблон, если он действительно создает дубли. Для этого лучше сначала посмотреть логи обхода и понять, какие URL бот получает чаще всего.

<?php
add_filter('robots_txt', function ($output) {
    $output .= "\nDisallow: /*?lang=*";
    return $output;
});

Такой шаблон не везде отработает одинаково, потому что поддержка wildcard в robots.txt зависит от поисковика. Перед внедрением проверьте поведение именно в той системе, на которую ориентируетесь.

Диагностика: как понять, что проблема именно в robots.txt

Не стоит править файл вслепую. Сначала проверьте, что именно блокируется и где.

• Откройте /robots.txt в браузере и убедитесь, что там нет случайных Disallow: /en/ или аналогичных правил.
• Проверьте URL переводной страницы в Search Console через проверку URL.
• Сравните канонический адрес страницы и адрес в sitemap.
• Посмотрите, не закрыт ли sitemap отдельным правилом.
• Если используется кэш или CDN, очистите его после изменения файла.

Если страница доступна, но Search Console пишет о блокировке, это почти всегда означает, что бот видит не ту версию robots.txt, которую вы открываете локально: кэш, CDN или отдельный виртуальный хост могут отдавать другой файл.

Проверка результата после внедрения

После правки robots.txt не ограничивайтесь визуальной проверкой. Нужен короткий технический чек.

1. Откройте https://example.com/robots.txt и убедитесь, что правила совпадают с ожидаемыми.
2. Проверьте, что sitemap доступен по указанному адресу и возвращает 200 OK.
3. В Search Console отправьте на проверку несколько переводных URL.
4. Убедитесь, что статус обхода больше не показывает блокировку robots.txt.
5. Посмотрите серверные логи: бот должен запрашивать языковые страницы и sitemap.

Если после правки страницы все равно не индексируются, ищите причину в noindex, canonical, редиректах или дублях контента. Robots.txt не решает эти задачи.

Частые ошибки и как их исправить

Закрыли языковой каталог целиком

Это самая частая ошибка. Если /en/ или /de/ — это реальные страницы контента, их нельзя закрывать. Исправление простое: уберите правило Disallow для языкового префикса и проверьте sitemap.

Указали неверный sitemap

После миграции или смены SEO-плагина адрес карты сайта часто меняется. Если в robots.txt остался старый путь, поисковик будет ходить в пустоту. Обновите ссылку и проверьте ответ сервера.

Смешали ручной robots.txt и генерацию плагином

Если SEO-плагин генерирует файл автоматически, а вы еще и положили свой robots.txt в корень, итоговое поведение может отличаться от ожидаемого. Оставьте один источник управления.

Закрыли то, что должно быть доступно для рендера

Иногда в robots.txt по ошибке закрывают CSS, JS или папки темы. Для современных сайтов это плохая идея: поисковику нужно видеть страницу так же, как ее видит пользователь. Не закрывайте ресурсы без причины.

Практические советы по безопасности и производительности

Robots.txt не защищает сайт от атак. Он только подсказывает поисковым роботам, что не обходить. Поэтому не используйте его как замену реальной защите админки, ограничениям доступа или настройкам сервера.

Для производительности полезнее держать robots.txt коротким и понятным: меньше шансов случайно заблокировать нужный URL и проще сопровождать при изменении структуры сайта. Если у вас много технических дублей, сначала уберите причину на уровне плагина, шаблона или маршрутизации, а уже потом закрывайте остатки в robots.txt.

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

Главный принцип простой: robots.txt должен помогать обходу, а не маскировать ошибки в мультиязычной архитектуре. Если файл читается человеком за минуту и не содержит лишних исключений, значит, он, скорее всего, сделан правильно.