Все статьи

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

Безопасный процесс через draft, минимальные права, идемпотентность, preview, SEO-проверку, расписание и контролируемый откат.

Как автоматически публиковать статьи в 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-представление; неправильная зона сдвигает выход.

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

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

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

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

«Система» хранит исследование, бренд-войс, редакторские статусы и пакет публикации. Большая статья проходит Humanizer, Slop Check и SEO/E‑E‑A‑T, предметный эксперт утверждает факты, после чего интеграция создаёт WordPress draft.

Отдельный агент проверяет поля, ссылки, медиа и preview. Только утверждённая версия получает future или publish. WordPress ID и публичный URL возвращаются в карточку, а дальнейшая правка не теряет связь с исходником.

Преимущество Системы находится до кнопки публикации: она связывает замысел, проверки, CMS и последующую аналитику. Обычный генератор плюс API видит лишь текущий текст.

Ограничение: Система не знает поведение неизвестного плагина и не должна обновлять production без теста. Первый запуск проводится на staging или ограниченной рубрике. Изменения темы, SEO-плагина и прав WordPress требуют повторной проверки сценария.

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

Первая запись остаётся 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 экономит ручной перенос, но не отменяет редактора. Автоматизируйте повторяемые проверки и доставку; факты, спорные обещания и необратимую массовую публикацию оставляйте под контролем человека.

Источники