Как запретить индексацию тестового сайта WordPress через robots.txt и meta robots

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

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

Когда проблема уже есть: что обычно видно в поиске и логах

Сценарий почти всегда один и тот же: тестовый домен или поддомен уже доступен по прямой ссылке, поисковик успел его обойти, а в выдаче появляются страницы с заголовками вроде «Home», «Sample Page» или внутренние служебные URL. Иногда сайт открыт только частично: главная закрыта, а /wp-json/, архивы или медиафайлы продолжают индексироваться.

Перед правками полезно проверить три вещи:

• открывается ли сайт без авторизации;
• есть ли в исходном коде страницы meta name="robots";
• не разрешает ли robots.txt обход важных разделов.

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

Что именно нужно закрыть: robots.txt, meta robots и HTTP-авторизация

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

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

Пошаговое решение в WordPress

1. Включите запрет индексации в настройках WordPress

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

Проблема этого способа в том, что он не всегда покрывает все шаблоны и не защищает от прямого обхода по URL. Поэтому дальше нужен код или SEO-плагин.

2. Добавьте meta robots noindex для всего сайта

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

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

    // Подставьте свой признак staging-сайта.
    if ( defined( 'WP_ENVIRONMENT_TYPE' ) && WP_ENVIRONMENT_TYPE === 'staging' ) {
        echo '<meta name="robots" content="noindex, nofollow" />' . "\n";
    }
}, 1 );

Этот код лучше размещать в дочерней теме или в небольшом mu-plugin, а не в основной теме. Тогда он не исчезнет после обновления шаблона.

3. Закройте robots.txt от обхода

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

User-agent: *
Disallow: /

Если на тестовом домене нужно оставить доступ к отдельным файлам для проверки, например к картинкам или статике, запрет придется настраивать аккуратнее. Но для большинства staging-сайтов проще закрыть всё целиком.

4. Если есть доступ к серверу — добавьте HTTP-авторизацию

Это самый надежный слой. Поисковый робот не сможет даже получить HTML, а значит, не увидит ни контент, ни мета-теги. Для Apache это обычно делается через .htaccess и .htpasswd, для Nginx — через конфигурацию сервера.

Пример для Apache:

AuthType Basic
AuthName "Staging Area"
AuthUserFile /full/path/to/.htpasswd
Require valid-user

Важно: путь к .htpasswd должен быть абсолютным и находиться вне публичной директории, если это возможно. Иначе вы создадите новую дыру вместо защиты.

Если используете SEO-плагин: где не ошибиться

В популярных SEO-плагинах обычно есть переключатель для noindex на уровне сайта или отдельных типов записей. Это удобно, если staging нужен редактору, а не только разработчику. Но проверять нужно не только чекбокс в админке, а фактический HTML на фронтенде.

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

• главную страницу;
• одну обычную запись;
• архив рубрики;
• страницу вложения;
• /wp-json/, если он доступен публично.

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

После настройки не ограничивайтесь визуальной проверкой в браузере. Нужна быстрая техническая валидация.

1. Откройте исходный код страницы и найдите meta name="robots".
2. Проверьте, что в robots.txt действительно стоит Disallow: / или нужные правила.
3. Попробуйте открыть сайт в режиме инкогнито и убедитесь, что авторизация работает, если вы её включали.
4. Проверьте ответ сервера через curl.

Пример проверки:

curl -I https://staging.example.com/
curl https://staging.example.com/robots.txt

В ответе на страницу вы должны видеть либо защиту авторизацией, либо HTML с noindex. В robots.txt — ожидаемые директивы. Если сайт уже был в индексе, удаление может занять время; это нормальная ситуация, а не признак того, что настройка не сработала.

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

Оставили только robots.txt

Это самая частая недоработка. robots.txt не удаляет уже известные URL из поиска и не мешает поисковику хранить адрес без контента. Исправление простое: добавьте noindex или закройте сайт авторизацией.

Поставили noindex, но забыли про кэш

Если на сайте включен кэш страницы или CDN, старый HTML может продолжать отдаваться после правки. В таком случае очистите кэш плагина, серверный кэш и, если есть, кэш CDN. Иначе вы будете проверять уже не ту версию страницы.

Закрыли главную, но не закрыли вложения и архивы

WordPress может отдавать отдельные URL для медиафайлов, архивов и таксономий. Если staging-копия публична, их тоже нужно закрывать. Иначе поисковик увидит дубли и мусорные страницы.

Сделали запрет в теме, а потом обновили шаблон

Код в основной теме — плохое место для таких правок. После обновления он исчезает. Для постоянной логики используйте дочернюю тему или mu-plugin.

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

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

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

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

Что считать успешным результатом

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

Если нужен быстрый минимум без серверной настройки, используйте связку noindex + robots.txt. Если нужен нормальный staging для команды, добавьте HTTP-авторизацию. Это тот случай, когда лишний слой защиты не мешает, а экономит время на разборе случайно проиндексированных страниц.