Автоматизация WordPress через REST API и Google Apps Script

WordPress часто приходится связывать с таблицами, внутренними сервисами и небольшими автоматизациями: создавать черновики, обновлять записи, собирать данные, запускать проверки по расписанию или передавать результат в другой сервис. Для таких задач не всегда нужен отдельный сервер, n8n или Make. Если логика умеренная по объёму, её можно собрать на Google Apps Script и работать с WordPress через REST API.

Этот материал полезен владельцам сайтов и разработчикам, которым нужен понятный способ связать WordPress с Google Workspace без установки дополнительного «комбайна» в админку. Разберём архитектуру, авторизацию, запросы через UrlFetchApp, безопасное хранение настроек, запуск по расписанию, обработку ошибок и защиту от повторной обработки.

Главная идея простая: WordPress остаётся источником и получателем данных, а Google Apps Script выступает внешним исполнителем. Он делает HTTP-запросы к REST API, проверяет ответы и запускается вручную или по триггеру.

Что можно автоматизировать такой связкой

WordPress REST API отдаёт JSON и предоставляет endpoint для записей, страниц, медиа, пользователей и других типов данных. После аутентификации внешнее приложение может выполнять действия, которые разрешены правами конкретного пользователя WordPress.

Если задача шире и включает CRM, Telegram, несколько API и сложные ветвления, имеет смысл сразу проектировать полноценную автоматизацию бизнес-процессов. Apps Script хорош там, где нужен небольшой контролируемый слой между WordPress и Google Workspace.

Почему REST API лучше прямой работы с базой WordPress

Подключаться к MySQL извне ради автоматизации обычно не нужно. REST API даёт стабильный HTTP-интерфейс и заставляет запрос проходить через WordPress: аутентификацию, права пользователя, валидацию endpoint и бизнес-логику CMS.

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

Шаг 1. Проверяем REST API WordPress

Для начала достаточно открыть публичный endpoint записей:

GET https://example.com/wp-json/wp/v2/posts

Для стандартных записей WordPress использует маршрут /wp/v2/posts. Публичные данные обычно можно читать без авторизации, а создание, обновление и закрытые поля требуют аутентификации и соответствующих capabilities пользователя.

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

Шаг 2. Создаём отдельный доступ для автоматизации

Для внешнего Apps Script удобно использовать Application Password WordPress поверх HTTPS. Это отдельный пароль приложения, а не основной пароль входа пользователя.

Лучше создать отдельного пользователя под автоматизацию и дать ему минимально необходимые права. Если скрипту требуется только создание и редактирование записей, полный Administrator обычно избыточен. Подробно механизм разобран в отдельном материале про Application Passwords для WordPress REST API.

В код статьи и репозиторий реальные секреты не добавляются. Для примеров используем только заглушки API_USERNAME и APPLICATION_PASSWORD.

Шаг 3. Храним настройки в Script Properties

Google Apps Script предоставляет PropertiesService для простых key-value настроек. Для параметров конкретного скрипта можно использовать Script Properties. Это удобнее, чем вписывать адрес сайта или credentials прямо в функции.

const props = PropertiesService.getScriptProperties();

const WP_URL = props.getProperty('WP_URL');
const API_USERNAME = props.getProperty('API_USERNAME');
const APPLICATION_PASSWORD = props.getProperty('APPLICATION_PASSWORD');

Script Properties не превращают секрет в универсальный менеджер секретов, но позволяют не хранить его в исходном коде. Доступ к проекту Apps Script всё равно нужно выдавать осознанно, а сам Application Password — периодически пересматривать и отзывать, если интеграция больше не нужна.

Шаг 4. Делаем GET-запрос через UrlFetchApp

UrlFetchApp — штатный сервис Apps Script для HTTP/HTTPS-запросов к внешним ресурсам. Для начала получим несколько последних записей.

function getRecentPosts() {
  const props = PropertiesService.getScriptProperties();
  const baseUrl = props.getProperty('WP_URL') || 'https://example.com';

  const url = baseUrl + '/wp-json/wp/v2/posts?per_page=5&status=publish';

  const response = UrlFetchApp.fetch(url, {
    method: 'get',
    muteHttpExceptions: true,
    headers: {
      Accept: 'application/json'
    }
  });

  const code = response.getResponseCode();

  if (code !== 200) {
    throw new Error('WordPress REST API HTTP ' + code);
  }

  return JSON.parse(response.getContentText());
}

muteHttpExceptions: true полезен для интеграции, потому что позволяет получить тело ответа и HTTP-код даже при 4xx/5xx, а затем решить, что делать дальше. Без этого сценарий часто заканчивается исключением раньше, чем код успевает записать понятную диагностику.

Шаг 5. Создаём черновик в WordPress

Для изменения данных потребуется авторизация. Application Password можно передать через HTTP Basic Auth по HTTPS. В Apps Script заголовок формируется из пары «логин:пароль».

function createDraft() {
  const props = PropertiesService.getScriptProperties();

  const baseUrl = props.getProperty('WP_URL') || 'https://example.com';
  const username = props.getProperty('API_USERNAME') || 'API_USERNAME';
  const password = props.getProperty('APPLICATION_PASSWORD') || 'APPLICATION_PASSWORD';

  const auth = Utilities.base64Encode(username + ':' + password);

  const payload = {
    title: 'Черновик из Google Apps Script',
    content: '<p>Тестовый текст без секретов.</p>',
    status: 'draft'
  };

  const response = UrlFetchApp.fetch(
    baseUrl + '/wp-json/wp/v2/posts',
    {
      method: 'post',
      contentType: 'application/json',
      payload: JSON.stringify(payload),
      muteHttpExceptions: true,
      headers: {
        Authorization: 'Basic ' + auth,
        Accept: 'application/json'
      }
    }
  );

  const code = response.getResponseCode();
  const body = response.getContentText();

  if (code !== 201) {
    throw new Error('Create post failed: HTTP ' + code + ' ' + body);
  }

  return JSON.parse(body);
}

Здесь base64 используется только как часть стандарта HTTP Basic Authentication внутри выполняемого кода. Это не способ хранения файла или секрета. Сама передача credentials должна идти по HTTPS, а реальные значения остаются вне исходника.

Шаг 6. Обновляем запись по ID, а не создаём новую каждый раз

Главная ошибка автоматизации — выполнять POST на создание при каждом запуске. Если сценарий может повториться, нужно хранить постоянный WordPress ID или другой однозначный ключ.

Например, если Apps Script создаёт запись из строки Google Sheets, в таблице можно сохранить wp_post_id. Следующий запуск сначала проверяет это поле: если ID есть — отправляет обновление в /wp/v2/posts/<id>, если нет — создаёт новую запись.

function updatePost(postId, title) {
  const props = PropertiesService.getScriptProperties();
  const baseUrl = props.getProperty('WP_URL') || 'https://example.com';

  const username = props.getProperty('API_USERNAME') || 'API_USERNAME';
  const password = props.getProperty('APPLICATION_PASSWORD') || 'APPLICATION_PASSWORD';
  const auth = Utilities.base64Encode(username + ':' + password);

  const response = UrlFetchApp.fetch(
    baseUrl + '/wp-json/wp/v2/posts/' + postId,
    {
      method: 'post',
      contentType: 'application/json',
      payload: JSON.stringify({ title }),
      muteHttpExceptions: true,
      headers: {
        Authorization: 'Basic ' + auth
      }
    }
  );

  const code = response.getResponseCode();

  if (code !== 200) {
    throw new Error('Update failed: HTTP ' + code);
  }

  return JSON.parse(response.getContentText());
}

Когда нужен дополнительный hash

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

Шаг 7. Запускаем автоматизацию по расписанию

Apps Script поддерживает installable triggers, включая time-driven trigger. Такой запуск подходит для периодической синхронизации: например, раз в час проверить таблицу и обновить WordPress, либо раз в день собрать данные сайта.

function createHourlyTrigger() {
  ScriptApp.newTrigger('syncWordPress')
    .timeBased()
    .everyHours(1)
    .create();
}

Триггер выполняется с авторизацией пользователя, который его создал. Это важно учитывать, если проект Apps Script редактируют несколько человек. Также нужно помнить о квотах Apps Script: для частых или больших синхронизаций лучше выбрать серверный процесс, очередь задач или n8n на VPS.

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

Apps Script не должен превращаться в вторую CMS. Достаточно хранить минимальные данные, которые нужны для безопасного повторного запуска.

Если нужна доработка endpoint, ролей, метаполей или логики WordPress, это уже задача для доработки WordPress или отдельного плагина.

Обработка ошибок: что делать с 400, 401, 403 и 5xx

400 Bad Request

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

401 Unauthorized

Проверяйте логин, Application Password, HTTPS и передачу заголовка Authorization. На некоторых конфигурациях Apache/Nginx или прокси заголовок авторизации может не доходить до WordPress, что отдельно описано в документации REST API.

403 Forbidden

Аутентификация может быть успешной, но у пользователя недостаточно capabilities для конкретного действия. Это не повод сразу назначать Administrator: сначала определите, какое право требуется endpoint.

404 Not Found

Проверяйте маршрут, ID объекта и permalink/серверную конфигурацию. Для собственного endpoint убедитесь, что он зарегистрирован и доступен в текущем окружении.

429 и 5xx

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

Защита от дублей и повторных запусков

В автоматизации нужно исходить из того, что один и тот же сценарий может выполниться повторно: пользователь нажал «Run» ещё раз, trigger запустился после временной ошибки или HTTP-ответ потерялся.

1. Используйте постоянный внешний source_id.
2. После создания WordPress-объекта сохраняйте его ID.
3. Перед новым POST проверяйте, нет ли уже соответствия source_id → wp_post_id.
4. Для обновлений сравнивайте hash или дату изменения.
5. Не помечайте строку как успешно обработанную до проверки HTTP-кода и JSON-ответа.
6. Не повторяйте автоматически ошибки 400/401/403 без изменения причины.

Безопасность интеграции

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

• Используйте только HTTPS.
• Создавайте отдельного пользователя для интеграции.
• Выдавайте минимально необходимые capabilities.
• Создавайте отдельный Application Password для каждого сценария.
• Не храните секреты в Google Sheets и коде.
• Не выводите Authorization header и пароль в логи.
• Проверяйте HTTP-коды до обработки ответа.
• Отзывайте пароль приложения после отключения интеграции.

Если REST API нужно расширить собственным маршрутом, обязательно задавайте permission_callback и валидируйте входные данные. Открытый custom endpoint без проверки прав быстро превращается в уязвимость.

Практический сценарий: таблица контент-плана создаёт черновики

Представим обычный контент-план в Google Sheets. В строке есть заголовок, дата, статус подготовки и поле wp_post_id. После перевода строки в состояние «готово» Apps Script должен создать в WordPress черновик.

1. Скрипт читает строки со статусом «готово».
2. Проверяет, что wp_post_id пустой.
3. Формирует JSON с title, content и статусом draft.
4. Отправляет POST в /wp-json/wp/v2/posts.
5. Проверяет HTTP 201 и валидность JSON.
6. Записывает полученный WordPress ID обратно в строку.
7. Следующий запуск уже не создаёт эту запись повторно.

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

Когда это решение подходит

• Нужно связать WordPress с Google Sheets или другими сервисами Google Workspace.
• Автоматизация состоит из нескольких понятных HTTP-запросов.
• Объём данных умеренный и укладывается в квоты Apps Script.
• Не требуется постоянно работающий процесс или очередь высокой нагрузки.
• Нужно быстро сделать управляемый внутренний инструмент без отдельного VPS.

Когда лучше выбрать другой вариант

• Сценарий обрабатывает большой поток заказов или событий в реальном времени.
• Нужна сложная очередь, гарантированные ретраи и долгие фоновые задачи.
• Интеграция объединяет много систем и ветвлений — тогда удобнее n8n, Make или собственный backend.
• Требуется низкая задержка и постоянный webhook endpoint.
• Нужны сложные секреты, аудит, централизованный мониторинг и несколько окружений.

Для более сложного проекта можно отдельно спроектировать WordPress-интеграцию и серверную логику, а Apps Script оставить только для части, связанной с Google Workspace.

Вывод

Google Apps Script может быть удобным внешним слоем для автоматизации WordPress, если задача не требует отдельной серверной платформы. WordPress REST API даёт стандартный интерфейс, UrlFetchApp выполняет HTTP-запросы, Script Properties убирают настройки из кода, а installable triggers позволяют запускать сценарий по расписанию.

Надёжность такой схемы определяется не количеством кода, а несколькими правилами: минимальные права пользователя, отдельный секрет, проверка HTTP-кодов, сохранение WordPress ID и безопасный повторный запуск без дублей. Если связка начинает разрастаться в полноценную интеграционную систему, её лучше вовремя перенести в инструмент, рассчитанный на очереди и сложные процессы.

Официальные источники

• WordPress REST API Handbook
• WordPress REST API: Authentication
• WordPress REST API: Posts endpoint
• Google Apps Script: UrlFetchApp
• Google Apps Script: PropertiesService
• Google Apps Script: Installable Triggers