Как автоматически публиковать статьи в WordPress и не дать AI сломать сайт

WordPress REST API позволяет создать запись одним запросом. Именно поэтому опасно начинать интеграцию с публикации. Ошибка в шаблоне, потерянная картинка или галлюцинация в тексте мгновенно становятся публичной страницей, попадают в sitemap и уходят поисковому роботу.

Надёжная автопубликация устроена скучнее: AI готовит материал, редактор утверждает неизменяемую версию, WordPress получает черновик, команда проверяет предпросмотр в теме сайта и только затем меняет статус. Скорость остаётся, а цена сбоя снижается.

Какие статусы даёт WordPress

У записей REST API есть статусы draft, pending, future, publish и private. Для автоматизации достаточно выстроить явный маршрут:

draft → pending → future → publish

draft подходит для технической сборки. pending показывает, что материал ждёт человеческого решения. future используется для публикации по расписанию. publish должен появляться только после всех проверок.

Не позволяйте генератору напрямую отправлять publish. Даже хороший текст может получить неверный slug, автора, рубрику или featured image.

Статус храните и в исходной системе. Иначе WordPress считает запись черновиком, а календарь маркетинга — запланированной.

Разделите текст и пакет публикации

Готовая статья — не один HTML-блок. Пакет содержит:

• заголовок и slug;
• основной текст;
• excerpt;
• автора;
• рубрики и теги;
• изображение и alt;
• SEO title и description;
• canonical;
• дату и часовой пояс;
• внутренние ссылки;
• исходные факты и дату проверки.

WordPress core API работает с title, content, excerpt, author, featured_media, categories и tags. SEO-поля часто принадлежат плагину и требуют отдельной интеграции или зарегистрированных meta fields.

Не предполагайте, что одинаковый ключ работает в Yoast SEO, Rank Math и самописной теме. Проверьте конкретную конфигурацию сайта.

Аутентификация без общего пароля

WordPress поддерживает Application Passwords для доступа приложений. Создайте отдельную учётную запись с минимальной ролью и отдельный пароль приложения для интеграции.

Не используйте пароль администратора. Не вставляйте секрет в prompt, текст статьи, URL или журнал ошибок. Храните его в защищённом хранилище и предусмотрите отзыв без смены доступа всей команды.

Ограничьте домен назначения. Интеграция не должна отправлять токен на URL, который пришёл из данных статьи. Проверьте HTTPS и сертификат.

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

Идемпотентность защищает от дублей

Самая частая поломка выглядит невинно: WordPress создал запись, но ответ потерялся по сети. Интеграция повторяет запрос и получает второй пост.

Присвойте материалу стабильный внешний идентификатор. До создания проверяйте, нет ли связанной записи. После успешного ответа сохраните WordPress ID.

Slug не подходит как единственный ключ: редактор может его изменить, а одинаковые заголовки встречаются. Внешний ID можно хранить в разрешённом meta field или в собственной таблице интеграции.

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

Изображения загружаются отдельно

Сначала загрузите файл в media endpoint, получите ID и только затем назначьте featured_media. Проверьте MIME-тип, размер, разрешение, имя файла и права.

AI не должен придумывать alt по одному имени файла. Alt описывает полезное содержание изображения в контексте статьи. Декоративному изображению иногда нужен пустой alt.

После загрузки откройте реальный URL файла. Бывает, что API вернул успех, а CDN, оптимизатор или права доступа не позволяют показать картинку посетителю.

Не загружайте один файл заново при каждом повторе. Связывайте внешний ID медиа с WordPress ID.

HTML нужно проверять после рендера

В редакторе и на публичной странице контент может выглядеть по-разному. Тема, Gutenberg, фильтры безопасности и плагины меняют разметку.

Проверьте:

• один H1 на странице;
• последовательность H2/H3;
• таблицы на мобильном;
• списки и code blocks;
• внешние и внутренние ссылки;
• отсутствие пустых абзацев;
• CTA и формы;
• изображение и подпись.

Не доверяйте только HTML из API. Откройте preview как пользователь. Для критических шаблонов полезна автоматическая визуальная проверка, но финальную версию статьи всё равно смотрит редактор.

SEO-проверка до смены статуса

Убедитесь, что slug читаемый и уникальный, title и description соответствуют статье, canonical указывает на правильный URL, а robots не содержит случайный noindex.

Проверьте внутренние ссылки: целевые страницы существуют и отвечают 200. Ссылка на будущую статью допустима только если порядок публикаций гарантирован.

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

После публикации проверьте sitemap и публичный ответ сервера. Сам факт создания записи в WordPress не означает доступность для поиска.

Отложенная публикация и время

Для статуса future передавайте дату осознанно. WordPress хранит локальное и GMT-представление; неправильная зона сдвигает выход.

Проверьте часовой пояс сайта и сервера на тестовой записи. Учтите перевод времени, если проект работает не только по Москве.

Отдельно проверьте запуск WP-Cron. По умолчанию он проверяет задачи при загрузке страниц, поэтому на малопосещаемом сайте запись может выйти позже указанного времени. Для строгого расписания настройте системный планировщик или механизм хостинга и проверьте фактический выпуск тестовой записи. Это описано в документации WordPress о WP-Cron.

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

При изменении уже запланированного материала сохраняйте версию и автора правки.

Как Система управляет WordPress

Система готовит статью в контексте проекта и после подтверждения передаёт её в подключённый WordPress как draft. Это сокращает ручной перенос, но не заменяет проверку страницы в конкретной теме и конфигурации CMS.

Описанный в этой статье маршрут draft → pending → future → publish — схема для настройки редакционного процесса WordPress. Не считайте, что подключение Системы автоматически реализует все эти переходы. Предпросмотр, расписание и финальный выпуск настройте и проверьте на стороне WordPress; поддержку медиа, рубрик и полей SEO-плагина проверьте отдельно.

Начните с одной тестовой записи и минимальных прав. После смены темы, плагина или доступа повторите проверку передачи черновика.

Безопасный пилот из пяти записей

Первая запись остаётся draft. Проверьте все поля и preview. Вторую верните на редактуру, чтобы убедиться, что статус не публикует её случайно. Третью запланируйте на ближайшее время и проверьте часовой пояс.

Четвёртая содержит таблицу, изображение, код и внутренние ссылки. Пятая имитирует сетевой таймаут: повтор не должен создать дубль.

Для каждой сохраните запрос без секретов, ответ, ID, время, итоговый URL и результат проверки. После пилота зафиксируйте условия остановки.

Не начинайте с переноса архива из сотни материалов. Массовая операция умножает незаметную ошибку.

Что делать после выхода

Откройте публичную страницу без авторизации. Проверьте HTTP 200, canonical, robots, изображение, ссылки и Метрику. Убедитесь, что статья появилась в нужной рубрике и sitemap.

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

Связку поисковых и поведенческих данных мы разбираем в статье про Вебмастер и Метрику. Для российской CMS используйте отдельный процесс публикации в 1С‑Битрикс, а общую архитектуру — в материале о едином процессе маркетинга.

Обновление и откат опубликованной статьи

Автоматизация нужна не только для первого выхода. Цены, интерфейсы и ссылки меняются, поэтому запись должна обновляться без потери URL и истории.

Перед PUT или POST к существующей записи получите текущую версию и сохраните контрольные поля. Проверьте, что WordPress ID относится к нужному внешнему материалу. Не ищите запись только по похожему заголовку.

Обновление проходит тем же маршрутом, что публикация: новая версия создаётся в Системе, редактор сравнивает изменения, интеграция обновляет draft или запланированную запись. Для уже публичной статьи полезно сначала открыть preview новой ревизии, если конфигурация сайта это поддерживает.

Сохраняйте:

• автора и причину изменения;
• старые и новые факты;
• дату проверки источников;
• прежние SEO-поля;
• WordPress revision или собственный снимок;
• результат публичной проверки.

Откат не должен означать удаление записи и создание новой. Это изменит ID, может сломать URL, комментарии и внешние связи. Восстановите последнюю проверенную ревизию и повторно проверьте страницу.

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

После исправления проверьте кеш и CDN. Успешный ответ API ещё не означает, что посетители видят новую версию. Для существенного исправления добавьте прозрачную редакционную пометку, если прежняя информация успела повлиять на читателя.

Наблюдение за интеграцией

Минимальный мониторинг отслеживает ошибки авторизации, рост ответов 4xx/5xx, повторные попытки, дубли, задержку очереди и расхождение статусов.

Оповещение должно содержать ID материала и безопасное описание этапа. Не отправляйте в общий чат пароль приложения или полный текст закрытого черновика.

Раз в месяц проверяйте технического пользователя, активные Application Passwords и последние операции. Неиспользуемый секрет отзывается. После смены домена, темы или SEO-плагина проведите сокращённый пилот заново.

Итог

Безопасная автопубликация в WordPress начинается с draft, минимальных прав и стабильного внешнего ID. Медиа загружаются отдельно, preview проверяется после рендера, а статус меняется только для утверждённой версии.

API экономит ручной перенос, но не отменяет редактора. Автоматизируйте повторяемые проверки и доставку; факты, спорные обещания и необратимую массовую публикацию оставляйте под контролем человека.

Источники

• WordPress REST API: Posts
• WordPress REST API: Media
• WordPress Application Passwords
• WordPress REST API Handbook