Статья согласована, время назначено, но утром она всё ещё не опубликована. Ручное нажатие «Опубликовать» решит один случай, однако не объяснит, почему расписание сорвалось. Для стабильного редакционного календаря нужно разделить настройки записи, работу фоновых задач и отображение сайта из кэша. Начинайте с безопасных проверок, не меняя сервер наугад.
Как работает отложенная публикация
WordPress использует WP-Cron для задач по времени, в том числе публикации запланированных записей. В стандартном механизме проверка запускается при загрузках страниц, а не непрерывно как отдельные часы. Поэтому на малопосещаемом сайте назначенное время может пройти до следующего подходящего запуска. На работу также могут влиять ограничения хостинга и конфигурация сайта.
Это не означает, что любой пропуск вызван отсутствием посетителей. Ошибка часового пояса, неправильный статус записи и неработающий фоновый запрос выглядят для редактора похоже, но требуют разных решений.
Шаг 1. Проверьте статус и назначенную дату
Откройте запись в редакторе. Убедитесь, что она действительно запланирована, а не сохранена как черновик или отправлена на утверждение. Сравните день, месяц, год и время. Ошибка на один месяц иногда незаметна, если смотреть только на часы.
Если время указано в будущем, проверьте часовой пояс сайта. Если время уже прошло, зафиксируйте состояние до ручной публикации: название, назначенный момент и статус. Это поможет разработчику отличить ошибку ввода от сбоя планировщика.
На скриншотах ниже используется реальный интерфейс действующего сайта только для показа расположения настроек. Состояние уже опубликованной статьи не является примером пропущенной публикации. В рамках подготовки этого материала её статус и дата не изменялись.
Шаг 2. Сверьте часовой пояс
Откройте «Настройки» → «Общие» и найдите часовой пояс. Для работы по Москве важен согласованный режим: редактор, календарь и серверный контроль должны одинаково понимать назначенное время. Не меняйте настройку только потому, что на компьютере сотрудника другие часы.
Пример: редактор планирует публикацию на 10:00, считая время московским, а сайт использует UTC. Получается другой момент выхода. Исправлять нужно договорённость и настройку расписания, а не ежедневно вручную сдвигать статьи.
Перед изменением часового пояса проверьте уже назначенные публикации и зависимые процессы. На сайте могут работать формы, магазин, рассылки и интеграции. Для статьи достаточно показать, где проверить значение; изменение рабочего проекта — отдельная техническая задача.
Шаг 3. Исключите проблему кэша
Запись может быть опубликована в WordPress, но не появиться сразу в закэшированном списке блога. Откройте её публичный адрес в приватном окне и сравните со статусом в админке. Если материал доступен по прямой ссылке, а карточки в блоге нет, расследование нужно начинать с обновления списка и правил кэширования.
Не очищайте все кэши каждые пять минут без понимания причины. Это может увеличить нагрузку и временно ухудшить скорость. Нужно проверить, инвалидируется ли страница блога при публикации новой записи и не хранится ли устаревшая версия на промежуточном уровне.
Полезно разделить два времени: когда WordPress изменил статус и когда посетитель увидел материал. Разница между ними объясняет, почему редактор считает публикацию успешной, а маркетолог ещё не видит карточку на главной.
Шаг 4. Посмотрите «Здоровье сайта»
Перейдите в «Инструменты» → «Здоровье сайта». Изучите сообщения о запланированных событиях и фоновых запросах. Формулировки зависят от версии WordPress и установленных компонентов. Запишите точный текст, а не только цвет индикатора.
При предупреждении о пропущенном событии нужно определить, какое именно событие не выполнено. Это может быть публикация, проверка обновлений или задача плагина. Отсутствие предупреждения тоже не доказывает исправность любого расписания: проверка отражает доступные ей условия в конкретный момент.
Не устанавливайте случайный плагин «исправления cron», не отключайте защиту и не запускайте все фоновые задачи вручную. Некоторые события могут отправлять письма, выполнять импорт или менять состояние заказов. Сначала нужна диагностика влияния.
Когда нужен системный планировщик
Если сайт должен публиковать материалы независимо от посещаемости, разработчик может организовать регулярный запуск задач средствами хостинга. Это техническая настройка, а не обязательный шаг для каждого блога. Способ зависит от доступа к серверу, окружения и уже работающего расписания.
Опасный порядок: сначала отключить обычный WP-Cron, а потом пытаться настроить замену. Если второй шаг не выполнен или команда не работает, фоновые задачи останутся без запуска. Безопасный порядок — подготовить и проверить новый механизм, определить защиту от параллельных запусков и только после этого согласованно менять конфигурацию.
Не копируйте чужую команду с неизвестным путём к PHP или WordPress. На другом хостинге она может обращаться к несуществующей папке или другой версии интерпретатора. Разработчик должен проверить запуск, журнал ошибок и поведение очереди в вашем окружении.
Как провести контрольный тест
На тестовой копии сайта создайте нейтральную запись и назначьте публикацию через небольшой понятный интервал. Зафиксируйте часовой пояс и время. Проверьте, изменила ли запись статус и появилась ли публичная страница. Затем убедитесь, что она видна в списке и не требует авторизации.
Если тест возможен только на рабочем сайте, сначала согласуйте сам факт появления тестового материала. Не публикуйте мусорную статью без разрешения. Для реального редакционного календаря можно использовать ближайшую уже согласованную публикацию, заранее предусмотрев ручной контроль.
После исправления проверьте несколько последовательных событий. Один успешный выход не исключает периодический сбой. Для недельного графика полезен журнал: назначено, фактически опубликовано, публичный URL, результат проверки. Не подменяйте проверку обещанием «теперь точно всегда будет вовремя».
FAQ
Если открыть сайт вручную, публикация запустится?
В стандартной схеме загрузка страницы может инициировать проверку задач, но это не универсальное решение. При блокировке фоновых запросов или ошибке задачи нужен разбор причины.
Можно ли просто нажать «Опубликовать»?
Для согласованной статьи — да, если требуется срочный выход. Но сначала сохраните сведения о сбое, иначе следующая запланированная запись может столкнуться с той же проблемой.
Какой интервал запуска выбрать?
Он зависит от нагрузки и требуемой точности. Универсальное расписание без знания хостинга и задач рекомендовать нельзя.
Достаточно настроить отложенный постинг один раз?
Нет. Нужен контроль выхода материалов, особенно после смены хостинга, защиты, кэширования или плагинов.