Как закрыть от индексации отладку WordPress-сайта, staging и тестовые страницы

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

На практике проблема обычно не в одном теге noindex, а в том, что часть URL закрыта в мета-тегах, часть — в robots.txt, а часть вообще доступна по прямой ссылке и отдается как обычная HTML-страница. Ниже — рабочая схема, которая помогает закрыть staging и тестовые страницы без лишних побочных эффектов.

Когда это действительно проблема

Сценарий узнается быстро: в поиске появляются адреса вида staging.example.com, dev.example.com, /test/, /demo/, /preview/, а иногда и страницы с параметрами, которые используются только для отладки. Это не всегда критично для локальной разработки, но для публичного staging-сервера — уже риск.

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

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

• Доступен ли staging по HTTP без логина.
• Есть ли на копии корректный noindex в HTML.
• Не закрыт ли сайт только через robots.txt без реального запрета индексации.
• Не отдаются ли тестовые страницы с каноническим URL на продакшен.
• Не попадают ли служебные разделы в XML-карту сайта.

Диагностика: где именно ломается защита от индексации

Сначала проверьте ответ сервера и HTML. Это быстрее, чем гадать по настройкам плагина. Для staging-версии откройте страницу в браузере и посмотрите исходный код: нужен либо <meta name="robots" content="noindex, nofollow">, либо HTTP-заголовок X-Robots-Tag, либо оба варианта сразу.

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

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

В ответе ищите заголовок X-Robots-Tag. Если его нет, а HTML доступен, значит закрытие сделано не до конца. Для WordPress это особенно важно, когда staging собирается на том же коде, что и продакшен, но с другой базой и другим доменом.

Рабочая схема: что закрывать и чем

Для практики лучше разделить задачи на три уровня: доступ, индексация и ссылки внутри сайта. Это дает предсказуемый результат и не ломает разработку.

1. Закройте staging паролем, если он публичный

Если копия сайта не нужна внешним пользователям, самый надежный вариант — базовая HTTP-авторизация на уровне сервера. Тогда поисковик вообще не увидит контент. Для Apache это обычно делается через .htaccess и .htpasswd, для Nginx — через auth_basic.

Это лучше, чем надеяться только на плагины. Плагин может отключиться, тема может смениться, а серверная защита останется.

2. Добавьте noindex для staging и тестовых URL

Если закрыть доступ нельзя, добавьте noindex на уровне WordPress. Для этого можно использовать фильтр wp_robots, который корректно работает в современных версиях WordPress.

<?php
add_filter( 'wp_robots', function( $robots ) {
    if ( is_admin() ) {
        return $robots;
    }

    $host = wp_parse_url( home_url(), PHP_URL_HOST );

    if ( $host && preg_match( '/^(staging|dev|test)\./i', $host ) ) {
        $robots['noindex']  = true;
        $robots['nofollow'] = true;
    }

    if ( is_page( array( 'test', 'demo', 'preview' ) ) ) {
        $robots['noindex']  = true;
        $robots['nofollow'] = true;
    }

    return $robots;
} );

Этот вариант полезен, если staging и продакшен живут на одном коде, но на разных доменах или поддоменах. Логика простая: если хост похож на тестовый, страницы получают запрет на индексацию автоматически.

3. Для отдельных служебных страниц используйте заголовок X-Robots-Tag

Если нужно закрыть не весь сайт, а только конкретные файлы или шаблоны, удобнее отдать заголовок X-Robots-Tag. Это особенно полезно для PDF, выгрузок, страниц предпросмотра или технических эндпоинтов.

<?php
add_action( 'send_headers', function() {
    if ( is_page( array( 'preview', 'demo' ) ) ) {
        header( 'X-Robots-Tag: noindex, nofollow', true );
    }
} );

Важно не дублировать конфликтующие правила. Если в HTML стоит index, follow, а в заголовке — noindex, поисковик обычно ориентируется на более строгий сигнал, но лучше не создавать двусмысленность.

Как закрыть staging через WordPress и не сломать продакшен

Если у вас несколько окружений, не хардкодьте домен прямо в шаблоне. Лучше завести проверку по хосту или константе окружения. В идеале staging должен определяться на уровне конфигурации, а не по случайной странице в админке.

Например, в wp-config.php можно задать собственную константу для тестовой среды:

<?php
define( 'WP_ENVIRONMENT_TYPE', 'staging' );

После этого в коде можно опираться на штатную функцию wp_get_environment_type() и не привязываться к названию домена:

<?php
add_filter( 'wp_robots', function( $robots ) {
    if ( function_exists( 'wp_get_environment_type' ) && wp_get_environment_type() !== 'production' ) {
        $robots['noindex']  = true;
        $robots['nofollow'] = true;
    }

    return $robots;
} );

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

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

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

• Откройте исходный код страницы и убедитесь, что есть noindex.
• Проверьте заголовки через curl -I или инструменты разработчика.
• Посмотрите, не попадает ли URL в XML-карту сайта.
• Проверьте, не ведут ли внутренние ссылки на staging из продакшена.
• Если URL уже был в индексе, отправьте его на удаление в панели вебмастера после исправления причины.

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

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

Закрыли только robots.txt

Это самая распространенная ошибка. Если URL уже известен поисковику, он может остаться в индексе без сниппета. Добавьте noindex или закройте доступ паролем.

Поставили noindex, но оставили страницу в sitemap

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

Использовали canonical на продакшен вместо noindex

Canonical помогает подсказать основной URL, но не заменяет запрет индексации. Для staging это слабое решение: копия все равно может быть обработана как отдельная страница.

Скрыли staging только на уровне темы

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

Оставили открытым wp-admin и XML-RPC на тестовой копии

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

Безопасность и производительность: что не стоит делать

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

Если нужен более широкий набор функций для чистки дублей, управления мета-тегами и техническими настройками, можно посмотреть в сторону решений вроде Clearfy Pro, но только если они реально закрывают ваши задачи и не конфликтуют с текущей конфигурацией сайта: https://wpshop.ru/plugins/clearfy.

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

Короткий чек-лист перед публикацией

• Staging закрыт паролем или хотя бы помечен noindex.
• Тестовые страницы не попадают в sitemap.
• На страницах есть только один понятный сигнал для робота, без конфликтов.
• Проверены HTML и заголовки ответа сервера.
• Удалены внутренние ссылки на тестовую копию с продакшена.
• Если URL уже индексировался, отправлен запрос на переобход или удаление.

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