Как планировать публикации в WordPress

Чтобы запланировать публикацию в WordPress, откройте панель Настройки → Сводка записи, нажмите на дату Опубликовать: Немедленно, выберите будущую дату и время, а затем нажмите кнопку Запланировать, которая появится вместо Опубликовать.

Эта часть занимает меньше минуты. Больше времени уходит на выяснение того, почему запись, поставленная в очередь на 2 часа ночи, всё ещё оставалась там утром за завтраком с красной отметкой Пропущенное расписание.

Причина уходит корнями в то, как WordPress выполняет запланированные задачи: не по реальному таймеру, а при загрузке страниц. В этом руководстве сначала описан быстрый путь по кликам, а затем — механизм WP-Cron и постоянное решение через серверный cron, которое навсегда избавит от пропущенных расписаний.

Сначала задайте часовой пояс

WordPress планирует публикации по часовому поясу вашего сайта, который по умолчанию установлен в UTC. Задайте правильный часовой пояс в Настройки → Общие до планирования, иначе записи будут опубликованы в неверное местное время. Свежая установка хранит время во всемирном координированном времени (UTC), поэтому запись, поставленная в очередь на «8:00», выйдет в 8:00 по UTC, если вы не указали WordPress, где находитесь. Перейдите в Настройки → Общие, выберите город в своём часовом поясе (записи по городам автоматически учитывают переход на летнее время, в отличие от фиксированных смещений UTC) и сохраните. Сделайте это один раз, прежде чем что-либо планировать. Инструкция по установке плагина MWW Scheduled Post Trigger советует проверить эту настройку в первую очередь, а его FAQ отправляет вас к ней снова, если записи всё ещё не появляются.

Как запланировать запись в блочном редакторе?

Чтобы запланировать запись в блочном редакторе, откройте панель Настройки → Сводка, нажмите на дату Опубликовать: Немедленно, выберите будущую дату и время, а затем нажмите кнопку Запланировать, которая появится вместо Опубликовать. WordPress опубликует запись автоматически в указанный момент. Для проверки: если задана будущая дата, верхняя кнопка читается как Запланировать, а не Опубликовать.

Классический редактор: в метабоксе Опубликовать нажмите Изменить рядом с Опубликовать сразу, введите дату и время, нажмите OK, а затем нажмите кнопку Запланировать.

Со страницами всё работает точно так же. Элемент управления датой находится в той же панели для оба типов записей.

Управление, отмена планирования и досрочная публикация

Чтобы увидеть все записи в очереди, перейдите в Записи → Все записи и нажмите фильтр Запланированные над списком; оттуда вы можете отредактировать, опубликовать досрочно или снять с расписания любую запись.

• Опубликовать досрочно: откройте запись и нажмите Опубликовать. Она выйдет немедленно, независимо от запланированного времени.
• Снять с расписания: верните статус записи в Черновик. Это удалит её из очереди без публикации, и вы сможете продолжить редактирование и запланировать её позже. (Установка даты на «сейчас» и нажатие «Опубликовать» — это досрочная публикация, а не снятие с расписания.)
• Запланировать правки для уже опубликованной записи: по умолчанию это невозможно, поскольку любое изменение в опубликованной записи становится публичным в момент сохранения. Чтобы поставить обновление в очередь, используйте плагин вроде PublishPress Revisions, который сохраняет ревизию и публикует её по расписанию.

Почему запланированные записи в WordPress пропускаются?

WordPress не использует реальный системный таймер. Он использует WP-Cron — псевдо-cron, который проверяет наличие задач к исполнению только тогда, когда кто-то загружает страницу, поэтому на сайте с низким трафиком запись, запланированная на 2:00, может не опубликоваться до прихода следующего посетителя. Plugin Handbook прямо говорит, что это значит на практике: поставьте задачу в очередь на два часа дня, не получите посетителей до пяти — и задача будет ждать до пяти. Когда триггер наконец срабатывает, срок публикации уже истёк, и WordPress помечает запись красной отметкой Пропущенное расписание.

Два условия в продакшене усугубляют ситуацию:

• Низкий трафик или его отсутствие. Как объясняет SpinupWP, запланированные события срабатывают только тогда, когда кто-то заходит на сайт, поэтому сайт, который часами простаивает, пропустит всё, что должно было выполниться в этот период. Ночные публикации на любительском блоге — классическая жертва.
• Агрессивное полностраничное кэширование. Закэшированная страница отдаётся как статический HTML без выполнения PHP, поэтому WP-Cron вообще не запускается. Отдавайте достаточную долю трафика из кэша — и WordPress почти не выполняется, а значит даже посещаемый сайт может перестать запускать запланированные события. Это распространённая причина на сайтах, оптимизированных по производительности.

Постоянное решение: отключите псевдо-cron и настройте реальный серверный cron

Постоянное решение — настроить реальный cron с фиксированным таймером, а затем отключить триггер по загрузке страницы. Это документированный подход, а не костыль: Plugin Handbook описывает подключение WP-Cron к системному планировщику задач именно для случая, когда задача должна выполниться вовремя.

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

Шаг 1: добавьте реальную задачу cron. В модуле Cron Jobs в cPanel или в crontab вашего сервера настройте запрос к wp-cron.php с определённым интервалом. Надёжное значение по умолчанию — каждые 5–15 минут. Эта форма с wget -q -O - взята из документации Kinsta:

*/15 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

*/15 запускает задачу каждые 15 минут; замените example.com на свой домен. Каноническая форма из Handbook использует wget --delete-after http://YOUR_SITE_URL/wp-cron.php с тем же интервалом. Работает и то, и другое; выбирайте то, что поддерживает ваш хостинг.

Шаг 2: отключите триггер по загрузке страницы. После того как серверный cron настроен, добавьте эту строку в wp-config.php, выше комментария /* That's all, stop editing! */:

define('DISABLE_WP_CRON', true);

Плагин как временная мера. Плагины вроде MWW Scheduled Post Trigger или Missed Scheduled Posts Publisher публикуют пропущенные записи только после того, как они уже опоздали, и FAQ самого MWW описывает его как временное решение до того, как вы вместе с хостером выясните, почему cron не срабатывает. Реальный серверный cron предотвращает пропуск, а не реагирует на него. Не полагайтесь ни на один отдельный плагин как на гарантию — некоторые из них не работают при определённых конфигурациях хостинга.

Управляемые хостинги. Kinsta запускает cron на уровне сервера для каждого сайта каждые 15 минут, а DreamPress от DreamHost отключает WP-Cron по умолчанию и заменяет его системным cron с тем же интервалом. На таких платформах обычно ничего настраивать не нужно. Проверьте документацию своего хостинга перед отключением WP-Cron.

Проверка и принудительный запуск через WP-CLI. На сервере с доступом по SSH команда wp cron event list показывает запланированные события и время их следующего запуска, а wp cron event run --due-now немедленно принудительно выполняет все просроченные события — это самый быстрый способ убедиться, что застрявшая запись будет опубликована.

Подведём итоги

Запланировать запись в WordPress — это путь в пару кликов на одну минуту, но обеспечение надёжности этих публикаций — вопрос серверного уровня. Задайте часовой пояс в Настройки → Общие и планируйте записи из панели Сводка. Если запланированные записи когда-нибудь получат отметку Пропущенное расписание, перестаньте доверять псевдо-cron по загрузке страницы: направьте реальный серверный cron на wp-cron.php каждые 5–15 минут, а затем добавьте define('DISABLE_WP_CRON', true);. Одно это изменение превращает планирование из «по возможности» в надёжный механизм — даже на тихом или закэшированном сайте.

Часто задаваемые вопросы

Нужно ли отключать WP-Cron, если я использую управляемый WordPress-хостинг вроде Kinsta или DreamHost?

Нет, на управляемых платформах вроде Kinsta и DreamPress от DreamHost вам обычно не нужно отключать WP-Cron самостоятельно, поскольку эти платформы уже запускают cron на уровне сервера на своей стороне (как правило, каждые 15 минут), который вызывает wp-cron.php независимо от трафика. Сначала проверьте документацию своего хостинга — многие управляемые тарифы настраивают это автоматически, и дублирование не даёт никакой выгоды. Правьте wp-config.php только в том случае, если хостер подтвердил, что серверный cron не используется.

В чём разница между плагином для пропущенных расписаний и реальным серверным cron?

Плагин для пропущенных расписаний, такой как MWW Scheduled Post Trigger или Missed Scheduled Posts Publisher, публикует записи только после того, как они уже опоздали, реагируя при следующей загрузке страницы или интервале, тогда как реальный серверный cron вызывает wp-cron.php по фиксированному таймеру независимо от трафика и вовсе предотвращает пропуск. Плагины — быстрая временная мера для любительских блогов с низким трафиком; серверный cron — проактивное решение для продакшена, кэшированных сайтов и мультисайтовых установок.

Почему моя запланированная запись опубликовалась в неверное время суток?

Свежая установка WordPress хранит время во всемирном координированном времени (UTC), поэтому запись, поставленная в очередь на «8:00», выходит в 8:00 по UTC, если вы не задали часовой пояс в разделе «Настройки», а затем «Общие». Выбирайте вариант с городом, а не фиксированное смещение UTC, поскольку записи по городам автоматически учитывают переход на летнее время. Задайте этот параметр один раз, прежде чем что-либо планировать, чтобы все будущие записи выходили по вашим местным часам.

Как проверить, будут ли мои запланированные записи действительно опубликованы?

На сервере с доступом по SSH выполните wp cron event list, чтобы увидеть все запланированные события и время их следующего запуска, а затем wp cron event run --due-now, чтобы принудительно немедленно выполнить все просроченные события. Эта пара команд WP-CLI — самый быстрый способ убедиться, что застрявшая запись будет опубликована, и выяснить, срабатывает ли WP-Cron вообще. Без SSH плагин WP Crontrol показывает тот же список событий через административную панель.

Может ли полностраничное кэширование приводить к пропуску запланированных записей?

Да, агрессивное полностраничное кэширование — распространённая и часто упускаемая из виду причина пропущенных расписаний. Закэшированная страница отдаётся как статический HTML без выполнения PHP, поэтому WP-Cron не запускается при таких запросах даже при высоком трафике. Отдавайте достаточную долю трафика из кэша — и WordPress почти не выполняется, из-за чего запланированные события перестают срабатывать. Решение то же, что и для сайтов с низким трафиком: отключить триггер по загрузке страницы и настроить реальный серверный cron.