Как закрыть от индексации старые черновики и автосохранения в WordPress

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

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

Когда черновики вообще могут попасть в индекс

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

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

Важно не путать это с обычными дублями категорий, тегов или UTM-параметров. Здесь речь именно о служебных версиях контента, которые не должны участвовать в поиске вообще.

Диагностика: что именно индексируется

Сначала нужно понять, какие URL реально видит поисковик. Не гадайте по одному скриншоту из выдачи — проверьте источник.

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

• Google Search Console: отчет по индексированию страниц и ручной поиск конкретного URL;
• серверные логи, если есть доступ: какие служебные адреса запрашивает бот;
• исходный HTML проблемной страницы: есть ли там noindex, canonical и мета-robots;
• ответ сервера на URL черновика или предпросмотра: код 200, 301, 404 или 403.

Если URL отдает 200 OK и полноценную страницу, поисковик может ее проиндексировать, даже если она выглядит как временная. Если же страница закрыта корректно, в индексе она либо не появляется, либо постепенно выпадает.

Проверка через браузер и curl

Для быстрой диагностики удобно посмотреть заголовки ответа. Это не заменяет Search Console, но сразу показывает, что происходит на уровне сервера.

curl -I https://example.com/?p=123&preview=true

Смотрите на три вещи: код ответа, наличие X-Robots-Tag и редиректы. Если предпросмотр отдает 200 и без ограничений, это уже повод разбираться с настройкой темы, плагина или кастомного кода.

Как закрыть служебные версии страниц: рабочие варианты

Универсального решения нет: зависит от того, откуда именно берется URL. Ниже — три подхода, которые реально применяются на WordPress-проектах.

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

Вариант 1. Закрыть предпросмотр и служебные URL через wp_robots

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

add_filter('wp_robots', function ($robots) {
    if (is_preview() || isset($_GET['preview'])) {
        $robots['noindex'] = true;
        $robots['nofollow'] = true;
    }

    return $robots;
});

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

Вариант 2. Отдавать X-Robots-Tag для служебных URL

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

add_action('send_headers', function () {
    if (is_preview() || isset($_GET['preview'])) {
        header('X-Robots-Tag: noindex, nofollow', true);
    }
});

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

Вариант 3. Убрать доступ к старым ревизиям и автосохранениям

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

Проверьте, не выводит ли ваша тема ссылки на ревизии в блоках «последние изменения», «история» или в кастомных метабоксах. Если да — уберите их из публичной части интерфейса. Для автосохранений лучше вообще не создавать публичных ссылок.

Пошаговое решение без лишнего риска

1. Найдите конкретный URL, который попал в индекс или в отчет Search Console.
2. Проверьте, отдает ли он 200 OK и есть ли на странице noindex.
3. Определите источник: стандартный предпросмотр, кастомный параметр, плагин, тема, sitemap.
4. Добавьте точечное ограничение через wp_robots или X-Robots-Tag.
5. Уберите внутренние ссылки на служебные URL, если они есть.
6. Переобойдите страницу в Search Console и дождитесь повторной проверки.

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

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

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

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

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

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

Закрывают все через robots.txt

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

Ставят noindex только в визуальном шаблоне

Если тег добавляется только в одной теме, а на мобильной версии или в другом шаблоне его нет, результат будет нестабильным. Лучше вешать логику на WordPress-хуки, а не на случайный кусок шаблона.

Ломают предпросмотр редакторов

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

Оставляют ссылку в sitemap

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

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

Служебные страницы — это не только SEO-вопрос. Чем меньше лишних URL отдает сайт, тем меньше мусора видят боты и тем меньше нагрузки на сервер. На небольших хостингах это особенно заметно, если бот регулярно ходит по предпросмотрам и ревизиям.

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

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

Когда лучше не закрывать, а исправить источник

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

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