Тестовый сайт на том же хостинге, что и боевой WordPress, — нормальная практика. Проблема начинается, когда staging случайно открывается поисковикам, дублирует контент или получает ссылки из служебных страниц. На shared-хостинге и на VDS это особенно легко пропустить: домен уже доступен, сайт отвечает, а защита от индексации настроена частично или вообще не настроена.
Ниже — рабочая схема, которая закрывает тестовый сайт от индексации без лишней магии: сначала диагностика, потом пошаговая настройка, затем проверка результата. Подход подойдет и для поддомена вроде staging.example.ru, и для отдельного домена на том же сервере.
Как понять, что тестовый сайт уже светится в поиске
Сначала проверьте не настройки в админке, а фактическое поведение сайта. На практике чаще всего находят одну из трех проблем: в robots.txt есть запрет, но страницы уже в индексе; в админке включен noindex, но доступ к сайту открыт без пароля; или тестовый сайт копирует боевой контент и отдает одинаковые метатеги.
Что смотреть в первую очередь
- откройте главную тестового сайта в браузере и проверьте исходный код на наличие
meta name="robots" content="noindex"; - посмотрите заголовки ответа через
curl -I https://staging.example.ru/; - проверьте
robots.txtпо адресу/robots.txt; - выполните поиск по домену в Google или Яндексе, если сайт уже был доступен публично;
- сравните title и description тестового и боевого сайта — одинаковые метатеги часто выдают дубли.
Если сайт уже попал в индекс, одного robots.txt недостаточно. Поисковик может оставить URL в выдаче без обхода страницы, если он уже знает адрес. В этом случае нужен именно noindex и, лучше, ограничение доступа на уровне сервера.
Рабочая схема: закрыть тестовый WordPress в три слоя
Надежнее всего не полагаться на один механизм. Для staging-сайта я обычно использую три уровня: HTTP-авторизация или IP-ограничение, запрет индексации в WordPress и корректный robots.txt. Это не дублирование ради дублирования: каждый слой закрывает свой сценарий.
1. Ограничьте доступ к сайту на уровне сервера
Если тестовый сайт не должен быть публичным, лучше закрыть его паролем. На Apache это можно сделать через .htaccess и .htpasswd. На Nginx удобнее использовать basic auth в конфиге виртуального хоста.
Пример для Apache:
AuthType Basic
AuthName "Staging Area"
AuthUserFile /var/www/.htpasswd
Require valid-userТакой способ полезнее, чем только noindex: поисковый робот не сможет даже открыть страницы, а случайный посетитель не увидит админку и тестовые данные. Если у вас VDS и есть доступ к конфигам, это самый чистый вариант.
Пример для Nginx:
location / {
auth_basic "Staging Area";
auth_basic_user_file /etc/nginx/.htpasswd;
}Если staging нужен только с вашего IP, можно ограничить доступ по адресу. Но на мобильных сетях и при удаленной работе это неудобно, поэтому basic auth обычно практичнее.
2. Включите запрет индексации в WordPress
В админке откройте Настройки → Чтение и включите опцию Попросить поисковые системы не индексировать сайт. WordPress добавит соответствующий сигнал для поисковиков, но это не гарантирует мгновенного удаления уже проиндексированных URL.
Если нужно зафиксировать noindex на уровне темы или плагина, можно добавить заголовок и метатег вручную. Например, для тестового сайта, который не должен индексироваться вообще:
add_action('wp_head', function () {
if (!is_admin()) {
echo '<meta name="robots" content="noindex, nofollow">' . "\n";
}
}, 1);
add_filter('wp_robots', function ($robots) {
$robots['noindex'] = true;
$robots['nofollow'] = true;
return $robots;
});Фильтр wp_robots — более правильный путь для современных версий WordPress, чем вставка метатега только в wp_head. Но если у вас уже есть SEO-плагин, который управляет robots-метками, не дублируйте логику без необходимости: проверьте, кто именно выводит noindex.
3. Сделайте robots.txt коротким и предсказуемым
Для staging-сайта не нужен сложный robots.txt. Достаточно запретить обход, но не рассчитывать на него как на единственную защиту.
User-agent: *
Disallow: /Если сайт уже закрыт паролем, этого достаточно. Если доступ открыт, robots.txt лишь подскажет роботам не ходить по страницам, но не уберет уже известные URL из индекса. Поэтому не путайте запрет обхода с запретом индексации.
Когда лучше использовать плагин, а когда код
Если staging-сайт живет временно и его настраивает не разработчик, удобнее использовать плагин для технической чистки и SEO-ограничений. Если у вас VDS, несколько окружений и деплой через Git, надежнее держать правила в конфиге сервера и в коде темы или mu-plugin.
| Подход | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Плагин | Быстро, без доступа к серверу, удобно для редактора | Зависимость от настроек и обновлений | Если сайт на shared-хостинге и нужен быстрый контроль |
| Код | Прозрачно, переносимо, легко версионировать | Нужен доступ к файлам и аккуратность | Если есть staging на VDS или CI/CD |
| Серверная защита | Самая надежная блокировка доступа | Нужен доступ к конфигам | Если сайт вообще не должен быть публичным |
Если используете плагин для SEO-очистки и управления дублями, проверьте, не конфликтует ли он с вашей темой и SEO-плагином. Например, решения класса Clearfy Pro часто помогают убрать технический шум, но на staging-сайте все равно нужно отдельно проверить, что именно выводится в head и какие страницы доступны без авторизации.
Пошаговая настройка без лишних рисков
Ниже — последовательность, которая обычно работает без сюрпризов.
- Сделайте staging-сайт на отдельном поддомене или отдельном домене.
- Закройте доступ basic auth или IP-ограничением.
- Включите
noindexв WordPress. - Проверьте
robots.txt. - Убедитесь, что sitemap не публикуется или не отдается поисковикам.
- Проверьте, что canonical указывает на тестовый домен, а не на боевой сайт, если это отдельное окружение.
- Удалите из тестовой базы реальные формы, платежные ключи, SMTP и вебхуки.
Последний пункт часто забывают. Даже если сайт закрыт от индексации, он может отправлять письма, дергать внешние API или принимать заявки. Для staging это уже не SEO-проблема, а вопрос безопасности и целостности данных.
Как проверить, что решение сработало
Проверка должна быть не визуальной, а технической. Откройте сайт в режиме инкогнито и убедитесь, что без логина он не доступен. Затем проверьте заголовки ответа:
curl -I https://staging.example.ru/В идеале вы увидите либо 401 Unauthorized при basic auth, либо как минимум заголовки и HTML с noindex. Если сайт отвечает 200 OK без защиты, это сигнал, что закрытие неполное.
Дальше проверьте исходный код страницы:
curl -s https://staging.example.ru/ | grep -i robotsИщите:
noindexв метатеге или заголовке;- отсутствие публичного sitemap, если он не нужен;
- отсутствие ссылок на боевой домен в canonical;
- отсутствие открытых feed-адресов, если они не нужны для теста.
Если сайт уже был в индексе, дополнительно проверьте Search Console или Яндекс Вебмастер для этого домена. Иногда URL остается в отчете еще некоторое время после исправления, и это нормально. Важно, чтобы новые обходы уже видели запрет на индексацию и закрытый доступ.
Частые ошибки и почему они возникают
Только robots.txt без noindex
Это самая распространенная ошибка. robots.txt запрещает обход, но не гарантирует удаление из индекса. Если URL уже известен поисковику, он может остаться в выдаче как «страница без описания».
Пароль стоит только на главной странице
Иногда закрывают только корень сайта, а /wp-login.php, /wp-admin/ или отдельные URL остаются открытыми. Для staging это плохая идея: робот или случайный пользователь может найти обходной путь.
Дублируется canonical на боевой домен
Если тестовый сайт копирует боевой шаблон и canonical ведет на основной домен, поисковик может интерпретировать staging как зеркало. Это особенно опасно при массовом клонировании сайта для тестов.
Оставлен публичный sitemap.xml
Даже при закрытом контенте sitemap может подсказать поисковику структуру сайта. Если окружение тестовое, sitemap лучше отключить или закрыть вместе с сайтом.
Не отключены внешние интеграции
Формы, CRM, вебхуки, SMTP и аналитика часто продолжают работать на staging. Это приводит к мусорным лидам, лишним письмам и путанице в статистике. Перед запуском тестового окружения проверьте, что все внешние ключи заменены на безопасные.
Практические советы для хостинга и VDS
На shared-хостинге не всегда есть доступ к Nginx или Apache-конфигу, поэтому там чаще используют комбинацию: пароль на уровне панели хостинга, noindex в WordPress и короткий robots.txt. На VDS лучше не ограничиваться только WordPress-настройками: серверная защита надежнее и не зависит от плагинов.
Если у вас несколько окружений, держите отдельные конфиги для production и staging. Не копируйте wp-config.php без проверки констант вроде WP_DEBUG, WP_ENVIRONMENT_TYPE и параметров почты. Для тестового сайта нормально включить WP_DEBUG, но не нормально оставлять боевые SMTP-данные и ключи API.
Если нужно быстро убрать технический шум на боевом сайте после переноса со staging, полезно пройтись по дублям, архивам и служебным страницам. Здесь уже уместны инструменты вроде Clearfy Pro, но только как дополнение к нормальной серверной и редакционной гигиене, а не как замена закрытию окружения.