Как закрыть staging-сайт WordPress от индексации без ошибок в robots.txt и meta robots

Тестовый сайт WordPress часто уезжает в индекс не из-за одной ошибки, а из-за набора мелких недочетов: забыли снять галочку в настройках, оставили открытый robots.txt, не закрыли доступ по HTTP-авторизации или перенесли staging на поддомен и не проверили канонические URL. В итоге поисковики видят копию боевого сайта, а потом в выдаче появляются дубли.

Если у вас staging нужен только для разработки, его лучше закрыть сразу на нескольких уровнях. Один Disallow в robots.txt не спасает, если страница уже доступна и на ней нет запрета на индексацию. И наоборот: noindex на страницах не гарантирует, что бот не зайдет на сайт и не увидит внутренние ссылки. Ниже — рабочая схема, которая закрывает типичный тестовый WordPress без лишней магии.

Как понять, что staging уже попал в зону риска

Начинать стоит не с правок, а с диагностики. Обычно проблема проявляется так:

• staging открывается без логина по адресу вида staging.site.ru или dev.site.ru;
• в поиске уже есть страницы с этим доменом;
• в исходном коде нет noindex или он стоит только на главной;
• robots.txt разрешает обход или вообще не настроен;
• внутренние ссылки и sitemap ведут на тестовый домен;
• на сервере нет базовой защиты, и любой бот может сканировать сайт.

Проверка занимает несколько минут. Откройте:

• https://staging.example.com/robots.txt;
• исходный код главной и пары внутренних страниц;
• XML-карту сайта, если она включена;
• поиск по запросу site:staging.example.com.

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

Пошаговое решение: закрываем staging на трех уровнях

1. Ставим базовую защиту на сервере

Самый надежный вариант для тестового сайта — HTTP Basic Auth. Он не зависит от темы, плагинов и настроек WordPress. Для Apache это обычно делается через .htaccess и файл паролей:

AuthType Basic
AuthName "Staging Area"
AuthUserFile /var/www/.htpasswd
Require valid-user

Для Nginx логика другая: доступ закрывается на уровне конфигурации сервера. Если у вас нет доступа к конфигу, попросите хостинг или DevOps сделать это на стороне виртуального хоста. Это лучше, чем пытаться закрыть staging только средствами WordPress.

2. Запрещаем индексацию в WordPress

В админке откройте Настройки → Чтение и включите опцию Попросить поисковые системы не индексировать сайт. Это добавляет сигнал для поисковиков, но не считается полноценной защитой. На staging его нужно использовать вместе с серверной блокировкой.

Если нужен контроль на уровне кода, можно принудительно добавить noindex, nofollow для всех страниц тестового сайта. Такой вариант полезен, когда staging живет отдельно и вы не хотите полагаться на ручную настройку в админке.

add_action('wp_head', function () {
    if (is_admin()) {
        return;
    }

    echo '<meta name="robots" content="noindex, nofollow, noarchive" />' . "\n";
}, 1);

Этот код можно добавить в mu-plugin или в functions.php тестовой темы. Но если сайт уже открыт для ботов, одного meta-тега мало: робот может увидеть страницу, а затем продолжить обход по ссылкам.

3. Закрываем robots.txt и sitemap

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

User-agent: *
Disallow: /

Если на тестовом домене уже есть sitemap, его лучше вообще не публиковать. Когда карта сайта доступна, поисковик получает список URL и может быстрее понять структуру копии. На staging это лишнее.

Если вы генерируете robots.txt через WordPress-фильтр, можно отдать его программно:

add_filter('robots_txt', function ($output, $public) {
    $output  = "User-agent: *\n";
    $output .= "Disallow: /\n";
    return $output;
}, 10, 2);

Но повторюсь: robots.txt — это не замок, а инструкция для робота. Для закрытого staging он нужен, но не как единственная мера.

Сравнение подходов: что выбрать для тестового сайта

Если выбирать только один способ, берите Basic Auth. Если нужен практичный набор без сюрпризов — Basic Auth + noindex + Disallow: /.

Как проверить, что решение сработало

После настройки не ограничивайтесь ручным открытием главной страницы. Проверьте именно те точки, через которые staging обычно “протекает” в индекс:

1. Откройте сайт в режиме инкогнито — он должен запрашивать логин и пароль.
2. Проверьте /robots.txt — там должен быть Disallow: /.
3. Посмотрите исходный код страницы — в <head> должен быть noindex, если вы его добавляли.
4. Убедитесь, что sitemap не доступен или не содержит публичных URL.
5. Проверьте запрос site:staging.example.com через поиск — новые страницы не должны появляться.

Если сайт уже был в индексе, удаление может занять время. В таком случае важно не только закрыть доступ, но и убрать причины повторного обхода: открытые ссылки, sitemap, публичные превью и канонические URL на staging.

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

Ошибка: закрыли только robots.txt

Это самая частая недоработка. Бот может увидеть URL из внешних ссылок или старого sitemap и все равно попытаться открыть страницу. Исправление: добавьте Basic Auth или хотя бы серверный запрет доступа.

Ошибка: noindex стоит только на главной

Иногда разработчик добавляет meta robots вручную на главную, а внутренние страницы остаются открытыми. Исправление: проверяйте шаблон wp_head и убедитесь, что тег выводится на всех публичных страницах staging.

Ошибка: staging использует боевой sitemap

Такое бывает после клонирования сайта. Поисковик получает карту с реальными URL и начинает путаться в версиях. Исправление: отключите генерацию sitemap на тестовом домене или отдавайте пустой вариант.

Ошибка: забыли про canonical

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

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

Закрытый staging — это не только про SEO. Это еще и про безопасность. На тестовом сайте часто лежат дампы базы, включены отладочные сообщения, а иногда доступны формы входа и REST API. Если staging открыт, вы даете лишнюю поверхность атаки.

• не храните на staging реальные пользовательские данные без необходимости;
• отключите публичный доступ к резервным копиям и архивам;
• не оставляйте одинаковые пароли на боевом и тестовом домене;
• проверьте, что письма с staging не уходят реальным клиентам;
• если используете плагин для SEO или чистки дублей, убедитесь, что он не генерирует публичные страницы для тестовой среды.

Если у вас несколько сред, удобно держать отдельные правила для каждой: production открыт, staging закрыт, local недоступен извне. Это проще поддерживать, чем каждый раз вручную вспоминать, что именно нужно выключить перед публикацией.

Для сайтов, где часто клонируют окружения, полезно вынести закрытие staging в отдельный mu-plugin. Тогда правило не потеряется при смене темы и не зависит от того, какой редактор кода сейчас открыт.