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

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

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

Когда проблема уже есть

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

Что проверить в первую очередь

• доступен ли сайт без авторизации;
• есть ли в <head> мета-тег noindex;
• не открыт ли robots.txt для индексации;
• не подключены ли sitemap.xml и канонические URL, ведущие на staging;
• не стоит ли на тестовом домене копия боевого сайта с теми же метаданными.

Если сайт уже виден в поиске, полезно проверить конкретные URL через оператор site: и посмотреть, какие страницы попали в индекс. Это даст понимание, достаточно ли закрыть весь сайт или нужно отдельно убрать несколько разделов.

Рабочая схема: закрываем сайт на трех уровнях

Надежнее всего использовать не один, а три слоя защиты: WordPress-настройку, HTTP-заголовок или мета-тег, а также запрет на уровне сервера. Тогда даже если один слой отключат при обновлении темы или плагина, сайт останется закрытым.

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

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

Если вы ведете staging через отдельную тему или плагин, проверьте, не переопределяет ли он вывод <meta name="robots" content="index, follow">. На тестовых стендах такое встречается после импорта готовых шаблонов.

2. Добавить явный noindex на уровне темы или плагина

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

<?php
add_action( 'wp_head', function () {
    if ( defined( 'WP_ENVIRONMENT_TYPE' ) && WP_ENVIRONMENT_TYPE === 'staging' ) {
        echo '<meta name="robots" content="noindex, nofollow, noarchive">' . "\n";
    }
} );

Этот вариант удобен, если у вас один и тот же код разворачивается в разных окружениях. В production мета-тег не выводится, а на staging закрывает страницы от индексации.

3. Закрыть доступ на уровне сервера

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

Для Apache можно использовать базовую авторизацию через .htaccess:

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

Для Nginx чаще используют ограничение по IP или basic auth на уровне конфигурации виртуального хоста. Если доступ нужен только команде, это лучший вариант: он не зависит от WordPress и не ломается при смене темы.

Что делать с robots.txt и sitemap

Robots.txt полезен, но его роль часто переоценивают. Он подсказывает роботам, что обходить не нужно, но сам по себе не убирает URL из индекса, если они уже известны поисковику.

На тестовом сайте обычно достаточно такого файла:

User-agent: *
Disallow: /

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

Но если цель — именно закрыть staging, sitemap лучше вообще не публиковать. Иначе вы сами подаете поисковику список страниц, которые хотите скрыть. Если sitemap уже был отправлен в Search Console, его нужно удалить из свойства тестового домена.

Когда robots.txt мешает

Иногда разработчики закрывают весь сайт через Disallow: /, а потом удивляются, что поисковик продолжает показывать URL без сниппета. Это нормальное поведение: адрес может остаться в индексе как найденный, даже если обход запрещен. Поэтому robots.txt — только часть решения, а не финальный барьер.

Сравнение подходов

Подход	Когда подходит	Минус
Настройка в WordPress	Быстро закрыть сайт от индексации	Не защищает от прямого доступа и не всегда перекрывает тему/плагин
noindex в wp_head	Нужно закрыть только staging или часть окружений	Работает только если страница отдается поисковику
HTTP-auth / IP restriction	Тестовый сайт не должен быть публичным	Требует доступа к серверу или хостингу

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

Пошаговая настройка без лишних рисков

1. Проверьте, что тестовый сайт действительно на отдельном домене или поддомене.
2. Включите запрет индексации в Настройки → Чтение.
3. Добавьте noindex, nofollow для staging через wp_head или через SEO-плагин, если он уже используется.
4. Закройте сайт HTTP-авторизацией или IP-фильтром на сервере.
5. Уберите sitemap из Search Console для тестового свойства, если он уже был отправлен.
6. Проверьте, что в шаблоне не осталось боевых canonical-URL, ведущих на основной домен.

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

Проверка должна быть не только визуальной. Откройте исходный код главной страницы и убедитесь, что в <head> есть мета-тег robots с noindex. Затем проверьте ответ сервера через curl:

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

Если включена HTTP-авторизация, в ответе должен быть статус 401 Unauthorized до ввода логина и пароля. Если сайт закрыт только через WordPress, статус будет 200 OK, но в HTML должен присутствовать noindex.

Дальше откройте Search Console для тестового свойства и посмотрите, не остались ли в отчете URL со статусом «Проиндексировано». Если остались, отправьте их на удаление или дождитесь повторного обхода после закрытия доступа.

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

Оставили открытым sitemap

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

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

Это самая частая ошибка. Robots.txt не удаляет уже известные URL из индекса. Нужен noindex и, если возможно, ограничение доступа на сервере.

Забыли про canonical

На копиях сайта иногда остаются canonical-ссылки на боевой домен. В итоге тестовые страницы не индексируются, но поисковик получает смешанные сигналы. Проверьте шаблоны, SEO-плагин и генерацию мета-тегов.

Закрыли сайт, но оставили доступ к медиафайлам

Если изображения и документы лежат в открытом /uploads, они могут продолжать индексироваться отдельно. Для staging лучше закрывать весь хост целиком, а не только HTML-страницы.

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

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

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

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

В итоге рабочая схема для тестового WordPress-сайта выглядит просто: закрыть доступ, явно поставить noindex, не публиковать sitemap и проверить, что в HTML и ответах сервера нет противоречий. Тогда staging не будет мешать индексации боевого сайта и не всплывет в поиске случайно.