Как проверить и исправить очередь отправки писем в WordPress

Когда SMTP уже настроен, а письма всё равно приходят с задержкой или часть уведомлений зависает в очереди, проблема часто не в самом сервере отправки, а в том, как WordPress и плагин доставки обрабатывают события. Типичный сценарий: письмо создаётся, лог показывает попытку отправки, но фактическая отправка откладывается из-за фоновой очереди, WP-Cron, лимитов сервиса или конфликта плагинов.

Ниже разберём, как быстро понять, где именно ломается цепочка, и что исправлять в первую очередь. Это не про «настроить SMTP с нуля», а про рабочую диагностику уже действующей отправки.

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

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

Признаки, что дело именно в очереди:

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

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

Начните с простого списка. Он экономит время и помогает не копать в код раньше срока:

• есть ли в плагине журнал отправки;
• не отключён ли DISABLE_WP_CRON в wp-config.php без реального системного cron;
• не стоит ли ограничение на отправку у SMTP-провайдера;
• не конфликтует ли плагин почты с плагином кэширования или security-плагином;
• не отправляются ли письма через несколько разных механизмов одновременно.

Как найти узкое место в цепочке отправки

Если у вас есть доступ к серверу и к логам плагина, диагностика идёт в два слоя: WordPress-уровень и уровень SMTP-сервиса. На WordPress-уровне важно понять, создаётся ли задача на отправку и вызывается ли обработчик. На уровне сервиса — принимает ли он письмо и не отклоняет ли его из-за лимита, аутентификации или политики домена.

Проверка WP-Cron и фоновой обработки

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

Если вы используете DISABLE_WP_CRON, убедитесь, что на сервере есть реальный cron-запуск. Иначе очередь не будет обрабатываться вообще.

define('DISABLE_WP_CRON', true);

После этого на сервере должен быть отдельный cron, который обращается к wp-cron.php. Без него отключение WP-Cron только усугубит задержки.

Проверка очереди через лог плагина

У большинства SMTP-плагинов есть журнал событий: время создания письма, адрес получателя, статус отправки, ответ сервера. Ищите не только ошибки, но и повторные попытки. Если письмо сначала помечено как «queued», а потом долго не меняет статус, значит проблема в обработчике очереди, а не в SMTP-авторизации.

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

Пошаговое решение без лишних изменений

Ниже порядок, который обычно даёт быстрый результат. Он не требует переписывать плагин и подходит для большинства типовых установок WordPress.

Шаг 1. Уберите двойную отправку

Проверьте, не остались ли активными сразу два решения для почты. Например, один плагин перехватывает wp_mail(), а другой добавляет свою очередь или логирование. В результате письмо может создаваться дважды или зависать в ожидании ответа от разных обработчиков.

Оставьте один основной SMTP-плагин и отключите лишние плагины, которые тоже работают с почтой, если они не нужны для конкретной задачи.

Шаг 2. Настройте нормальный запуск cron

Если сайт небольшой и письма критичны по времени, лучше не полагаться только на посещения пользователей. Настройте системный cron, который будет дергать WordPress по расписанию. Это снимает зависимость от трафика и делает обработку очереди предсказуемой.

* * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Команда выше — базовый пример. На практике лучше использовать серверный вызов через php или wget, если это рекомендовано вашим хостингом. Главное — чтобы cron реально выполнялся, а не просто был записан в панели.

Шаг 3. Проверьте лимиты SMTP-сервиса

Даже хороший сервис может временно ограничивать отправку, если сайт шлёт слишком много писем за короткий промежуток. Это часто проявляется после массовой регистрации, импорта пользователей или всплеска уведомлений из форм. В таком случае очередь копится, а плагин повторяет попытки.

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

Шаг 4. Упростите цепочку отправки

Если письма идут через несколько промежуточных слоёв — например, форма отправляет в плагин, плагин ставит в очередь, очередь идёт через внешний API, а потом ещё через внутренний логгер, — отладка становится сложнее. На время диагностики уберите всё лишнее: оставьте один путь от wp_mail() до SMTP.

Это особенно полезно, если сайт недавно мигрировал или на нём тестировали разные сервисы доставки.

Сравнение подходов: плагин, код, серверный cron

Пример кода для проверки, что письма вообще доходят до wp_mail()

Если нужно быстро понять, вызывается ли стандартная отправка WordPress, можно временно добавить фильтр в functions.php дочерней темы или в небольшой mu-plugin. Он не отправляет письмо сам, а только логирует факт вызова.

add_filter('wp_mail', function ($args) {
    error_log('wp_mail called: ' . print_r($args, true));
    return $args;
});

Если в логах нет записи, значит проблема выше по цепочке: форма не вызывает отправку, уведомление не формируется или код вообще не доходит до wp_mail(). Если запись есть, но письмо не уходит, смотрите уже SMTP-плагин и очередь.

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

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

• отправьте письмо из формы на сайте и засеките время до получения;
• проверьте, нет ли дубликатов в почтовом ящике;
• посмотрите лог плагина: статус должен быть sent или эквивалентный ему без повторных попыток;
• проверьте, что очередь очищается, а не растёт после каждой отправки;
• убедитесь, что cron срабатывает по расписанию, а не только при ручном заходе в админку.

Если письма всё ещё приходят с задержкой, сравните время создания события и время фактической отправки. Это помогает понять, где именно застревает задача: в WordPress, в очереди плагина или на стороне SMTP-провайдера.

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

Отключили WP-Cron, но не поставили системный cron

Это самая частая причина «тихих» задержек. WordPress перестаёт сам запускать фоновые задачи, а очередь писем не обрабатывается. Решение простое: либо верните штатный WP-Cron, либо настройте серверный cron.

Оставили два плагина для почты одновременно

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

Смотрят только на тестовое письмо

Тест из настроек SMTP не проверяет все сценарии сайта. Он не показывает, как ведут себя формы, уведомления, массовые письма и повторные попытки. Проверяйте именно те события, которые важны для проекта.

Игнорируют лимиты сервиса

Даже надёжный SMTP-сервис может временно ограничить отправку при всплеске активности. Если очередь растёт после массовых действий пользователей, проверьте квоты и политику rate limit у провайдера. Иногда проще перейти на сервис с более прозрачной обработкой очереди и понятными логами.

Практические советы по безопасности и производительности

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

Не используйте для почты общий ящик без двухфакторной защиты, если сервис это поддерживает. Для SMTP-авторизации лучше отдельный технический аккаунт с минимально необходимыми правами. Это снижает риск, если доступ к учётке утечёт.

Если проекту важна стабильность, смотрите в сторону сервисов с нормальной репутацией отправителя, API и понятными логами доставки. Для WordPress это обычно надёжнее, чем случайный SMTP на хостинге, который может ограничивать исходящую почту без предупреждения.

В некоторых случаях удобнее использовать специализированный плагин с хорошим логированием и поддержкой современных SMTP/API-сервисов. Например, если нужен понятный контроль очереди и диагностика отправки, имеет смысл смотреть на решения уровня WP Mail SMTP или на дополнительные инструменты экосистемы WPShop, если они закрывают вашу задачу без лишнего кода.