Как закрыть от индексации отложенные и запланированные записи в WordPress без потери черновиков

Ситуация типичная: редактор уже подготовил материал, поставил публикацию на будущее, а в поиске внезапно появляются страницы с датой, заголовком или даже фрагментами контента. Иногда это не сами future-записи, а связанные с ними архивы, предпросмотр, служебные URL или дубли в теме и плагинах. Проблема не в том, что WordPress «плохо умеет» работать с отложенными публикациями. Чаще всего сайт просто отдает поисковику то, что не должен отдавать.

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

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

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

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

Диагностика: что проверить перед правкой кода

Начните не с robots.txt, а с фактического ответа страницы. Откройте проблемный URL в браузере и проверьте:

• отдает ли он 200 OK или редирект;
• есть ли в HTML мета-тег robots с noindex;
• не попадает ли URL в XML-карту сайта;
• не кэшируется ли страница плагином кеша или CDN;
• не доступен ли предпросмотр без авторизации.

Если у вас есть доступ к консоли, полезно посмотреть заголовки ответа:

curl -I https://example.com/slug-zapisi/

Ищите X-Robots-Tag, Cache-Control и статус ответа. Если страница уже закрыта в коде, но в кеше остается старая версия без noindex, поисковик может увидеть именно ее.

Что должно насторожить

Если запланированная запись видна без входа в админку, это уже не нормальное поведение WordPress. Обычно причина в одном из трех мест: тема, SEO-плагин или кастомный код, который неправильно работает с post_status. В таком случае закрывать URL через robots.txt бессмысленно: поисковик может продолжить хранить адрес в индексе без содержимого, а сам контент останется доступным по прямой ссылке.

Рабочее решение: закрываем отложенные записи на уровне мета-тегов и sitemap

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

1. Добавляем noindex для будущих записей

Ниже пример для functions.php дочерней темы или собственного мини-плагина. Он добавляет мета-тег только для одиночных записей со статусом future:

add_action('wp_head', function () {
    if (!is_singular('post')) {
        return;
    }

    global $post;

    if (!$post instanceof WP_Post) {
        return;
    }

    if ($post->post_status === 'future') {
        echo '<meta name="robots" content="noindex, nofollow" />' . "\n";
    }
}, 1);

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

2. Исключаем будущие записи из XML-карты сайта

Если используется SEO-плагин, проверьте его настройки. Но если нужен кодовый вариант, можно отфильтровать список URL до вывода. Для стандартного WordPress sitemap это делается через фильтры ядра, но на практике чаще удобнее исключать записи на уровне запроса к sitemap-провайдеру. Пример ниже подходит как ориентир для кастомной логики:

add_filter('wp_sitemaps_posts_query_args', function ($args, $post_type) {
    if ($post_type === 'post') {
        $args['post_status'] = array('publish');
    }

    return $args;
}, 10, 2);

Так в sitemap попадут только опубликованные записи. Это особенно важно, если редакция массово ставит материалы в очередь и не хочет светить их раньше времени.

3. Защищаем предпросмотр

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

Сравнение подходов: плагин, код или robots.txt

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

Пошаговая настройка без лишних побочных эффектов

1. Найдите конкретный URL, который попал в поиск или sitemap.
2. Проверьте статус записи: future, draft, private или уже publish.
3. Убедитесь, что страница не отдается из кеша без актуального noindex.
4. Добавьте мета-тег noindex для будущих записей.
5. Исключите такие записи из sitemap.
6. Проверьте, что предпросмотр доступен только авторизованным пользователям.
7. После публикации убедитесь, что запись снова индексируема.

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

Проверка должна быть не «на глаз», а по ответу сервера и HTML. Сначала откройте страницу в режиме инкогнито и посмотрите исходный код. В нем должен быть <meta name="robots" content="noindex, nofollow" /> для будущей записи. Затем проверьте sitemap: URL отложенной записи там быть не должно.

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

curl -s https://example.com/slug-zapisi/ | grep -i robots

Если строка с noindex есть, но поисковик все равно показывает URL, проверьте кеш и наличие старых копий в CDN. Иногда проблема не в WordPress, а в том, что HTML обновился не везде.

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

Закрыли URL в robots.txt и остановились на этом

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

Поставили noindex только в теме, а кеш оставил старую версию

Если на сайте есть page cache, объектный кеш или CDN, обновление HTML может задержаться. После правки очистите кеш на всех уровнях: плагин, сервер, CDN. Иначе поисковик увидит старый ответ.

Скрыли запись, но оставили ее в sitemap

Это создает противоречивые сигналы. Поисковик видит URL в карте сайта, но на странице получает noindex или пустой контент. В итоге индексация становится нестабильной. Sitemap должен отражать только те URL, которые реально готовы к обходу.

Использовали private вместо future без понимания последствий

Статус private подходит не для всех сценариев. Он меняет доступность записи для авторизованных пользователей и может ломать рабочие процессы редакции. Если материал просто отложен до даты публикации, лучше оставлять future и управлять индексацией отдельно.

Что учесть для безопасности и производительности

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

Если у вас много кастомных типов записей, не проверяйте их через тяжелые запросы к базе на каждом хите. Используйте уже доступный объект $post и стандартные условные теги WordPress. Это дешевле по ресурсам и проще в сопровождении.

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

Если после внедрения URL все еще появляется в поиске, не спешите менять стратегию. Сначала проверьте ответ сервера, sitemap и кеш. В большинстве случаев проблема находится в одном из этих трех мест, а не в самом WordPress.