Сценарий типичный: у вас есть тестовый поддомен, временная копия сайта или включенная отладка, а в поиске внезапно появляются служебные страницы, дубли или мусорные URL. Иногда это не один файл, а сразу несколько источников проблем: robots.txt, мета-теги, HTTP-заголовки, sitemap, кэш и настройки хостинга. Если закрыть только один слой, поисковик часто находит другой.
Ниже — рабочая схема для WordPress, когда нужно именно закрыть от индексации staging, dev-окружение и отладочные страницы, не ломая продакшен и не надеясь на один «магический» чекбокс в плагине.
Что обычно попадает в индекс и почему это происходит
Проблема редко ограничивается одной страницей. На практике в индекс утекают:
- поддомены вида
staging.example.comилиdev.example.com; - копии сайта на отдельном домене, если они доступны без авторизации;
- страницы с параметрами отладки, например
?debug=1или служебные шаблоны; - архивы, теги, авторы и другие таксономии, которые не нужны в поиске;
- версии страниц из sitemap, если карта сайта не пересобрана после изменений.
Если сайт уже проиндексирован, одного Disallow в robots.txt недостаточно: поисковик может сохранить URL в индексе без контента. Для удаления из выдачи нужны правильные сигналы на уровне страницы и доступности окружения.
Диагностика: где именно течет индексация
Сначала проверьте не «что выключено», а что реально отдается наружу. Откройте проблемный URL и посмотрите ответ сервера:
curl -I https://staging.example.com/Нужны три вещи: код ответа, заголовок X-Robots-Tag и наличие редиректа на основной домен. Если staging отвечает 200 OK и отдает HTML без ограничений, поисковик может его увидеть. Если там уже стоит 401 или 403, это хороший знак: такой доступ поисковику не нужен.
Дальше проверьте, не попадает ли служебный сайт в sitemap. Если карта сайта генерируется плагином SEO, убедитесь, что staging-окружение вообще не публикует sitemap наружу. Отдельно посмотрите robots.txt и мета-тег robots в шаблоне.
Быстрая проверка через браузер и исходник
- Откройте страницу и найдите в исходнике
<meta name="robots". - Проверьте, нет ли в шапке ответа
X-Robots-Tag. - Посмотрите, не индексируется ли сайт по точному URL через поиск
site:staging.example.com. - Убедитесь, что на staging не подключены публичные XML-карты сайта.
Пошаговое решение для staging и отладочного окружения
1. Закройте доступ на уровне сервера
Самый надежный вариант — не надеяться на robots, а ограничить доступ к staging авторизацией или IP-фильтром. Для Apache можно использовать базовую авторизацию:
<FilesMatch "^(wp-login\.php|xmlrpc\.php)$">
Require all denied
</FilesMatch>Для всего staging-сайта лучше закрыть доступ целиком через конфигурацию виртуального хоста или basic auth. Это надежнее, чем пытаться «спрятать» сайт только от поисковиков.
Если staging нужен команде и должен открываться по паролю, это нормальный компромисс: поисковик не увидит контент, а разработчики смогут работать.
2. Добавьте заголовок noindex для служебного окружения
Если серверный доступ закрыть нельзя, добавьте X-Robots-Tag: noindex, nofollow для всего staging-домена. В Apache это можно сделать через .htaccess или конфигурацию сайта:
<IfModule mod_headers.c>
Header set X-Robots-Tag "noindex, nofollow, noarchive"
</IfModule>На Nginx аналогичный заголовок задается в конфиге сервера:
add_header X-Robots-Tag "noindex, nofollow, noarchive" always;Ключевой момент: заголовок должен отдаваться на все ответы, включая 404 и редиректы, поэтому в Nginx нужен параметр always.
3. Уберите staging из sitemap и внутренних ссылок
Если на тестовом сайте включен SEO-плагин, отключите генерацию sitemap или не публикуйте его наружу. Также проверьте, не вставлены ли абсолютные ссылки на staging в контент, меню, canonical и Open Graph. После переноса на продакшен такие ссылки часто остаются в базе и создают дубли.
Если нужно массово заменить домен в базе, используйте безопасный search-replace через WP-CLI на копии базы, а не ручную правку в phpMyAdmin.
wp search-replace 'https://staging.example.com' 'https://example.com' --skip-columns=guid --all-tablesПараметр --skip-columns=guid здесь важен: GUID в WordPress обычно не трогают без необходимости.
Как закрыть от индексации отдельные типы страниц в продакшене
Иногда проблема не в staging, а в том, что поисковик индексирует технические страницы на основном сайте: результаты поиска по сайту, страницы автора, архивы тегов, страницы с параметрами фильтрации. Тут уже нужен более точный подход.
Через SEO-плагин или код
Если у вас уже стоит SEO-плагин, проще всего отключить индексацию конкретных архивов в его настройках. Но если нужен контроль на уровне темы или плагина, можно поставить мета-тег и заголовок программно.
add_action('wp_head', function () {
if (is_search() || is_author() || is_tag()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
});Для части случаев этого достаточно, но лучше дублировать правило заголовком, если страница критично не должна индексироваться:
add_action('send_headers', function () {
if (is_search() || is_author() || is_tag()) {
header('X-Robots-Tag: noindex, follow', true);
}
});Такой код уместен, если вы точно понимаете, какие типы страниц хотите закрыть. Не ставьте его бездумно на весь сайт: можно случайно закрыть полезные посадочные страницы.
Сравнение подходов
| Подход | Когда подходит | Минус |
|---|---|---|
| robots.txt | Для ограничения обхода | Не гарантирует удаление из индекса |
| meta robots | Для отдельных страниц | Нужно, чтобы страница была доступна для обхода |
| X-Robots-Tag | Для серверного контроля и файлов | Требует доступа к конфигу сервера |
| 401/403 | Для staging и закрытых копий | Нужна авторизация или IP-фильтр |
Проверка результата после внедрения
После изменений не ограничивайтесь визуальной проверкой. Нужны конкретные признаки, что решение сработало:
curl -IпоказываетX-Robots-Tag: noindexна staging или служебных страницах;- в исходнике страницы есть
meta name="robots"с нужным значением; - служебный sitemap недоступен или не содержит тестовых URL;
- поиск
site:staging.example.comперестает показывать новые страницы; - в Search Console снижается число проиндексированных служебных URL после переобхода.
Если страница уже в индексе, удаление может занять время. Для ускорения используйте инструменты удаления URL в Search Console, но только после того, как на самой странице уже стоит корректный сигнал noindex или доступ закрыт.
Частые ошибки и как их исправить
Закрыли только robots.txt
Это самая частая ошибка. Disallow мешает обходу, но не всегда удаляет URL из индекса. Если страница уже известна поисковику, он может оставить ее в выдаче без сниппета. Исправление: добавьте noindex или закройте доступ на уровне сервера.
Поставили noindex, но оставили страницу в sitemap
Такой конфликтный сигнал замедляет переобход и мешает чистке индекса. Исправление: уберите URL из sitemap и убедитесь, что он не генерируется автоматически.
Оставили staging открытым без авторизации
Даже если на сайте есть noindex, поисковик может увидеть копию, если она доступна всем. Исправление: basic auth, IP allowlist или закрытие на уровне сервера.
Не проверили canonical и абсолютные ссылки
После переноса часто остается canonical на staging-домен. Это прямой сигнал поисковику, что страница «настоящая» находится там. Исправление: массово проверьте шаблоны, SEO-настройки и контентные вставки.
Безопасность и производительность: что не стоит делать
Не используйте плагины или настройки, которые просто «прячут» сайт через CSS, JavaScript или пустые страницы. Это не защита и не индексация-контроль, а имитация. Для staging это особенно опасно: служебные данные могут попасть в поиск, а иногда и в кэш внешних сервисов.
Если вам нужен более удобный контроль над дублями, архивами и служебными страницами на продакшене, посмотрите на Clearfy Pro. Но даже в этом случае серверный доступ и корректная конфигурация остаются базой: плагин не заменяет закрытый staging и не исправляет ошибки в конфиге хостинга.
Для команды полезно зафиксировать простой чек-лист перед запуском копии сайта:
- staging закрыт авторизацией или IP;
- на служебном домене стоит
X-Robots-Tag: noindex; - в sitemap нет тестовых URL;
- canonical указывает на продакшен только там, где это действительно нужно;
- поиск и архивы, которые не должны индексироваться, помечены явно.
Если сделать это один раз аккуратно, потом не придется вручную вычищать мусорные URL из индекса после каждого релиза.