Headless WordPress: вебхуки деплоя и инкрементальная публикация для Next.js

Ночь, офис пустеет, редактор жмёт «Опубликовать» и идёт пить чай. Вы, как человек ответственный, смотрите на сайт, а там старый заголовок и тишина. До деплоя 20 минут, на Vercel очередь, маркетинг уже в Телеграме шипит, что трафик «горит». Знакомо? Я это пережил слишком много раз и в какой-то момент понял простую вещь: сайт не обязан пересобираться целиком ради одного поста. Если у вас headless WordPress, а на фронте Next.js, то ISR и вебхуки решают 80% болей, а Make.com закрывает оставшиеся 20% автоматизацией, логами и спокойным сном. Почти спокойным.

Тут важно не геройствовать, а выстроить нормальный конвейер: публикация в WordPress — вебхук — Make.com — целевая регенерация нужных страниц в Next.js. Без шаманства и ночных деплоев ради одной запятой. Да, иногда всё равно сломается что-нибудь экзотическое, но вы хотя бы знаете, где чинить и кто виноват. Спойлер: виноваты обычно мы же, потому что забыли фильтр по статусу или секрет к руту положили в открытый репозиторий. Но это уже другая история.

По-человечески про headless WordPress и зачем он нам

Headless WordPress — это когда WordPress отвечает за контент и API, а отрисовку страницы и весь фронт вы ведёте в Next.js. Никаких тем, только админка, записи, медиабиблиотека, привычные роли в редакции и внятные права. Данные можно отдавать через REST API или GraphQL, кому что удобнее, а фронт сам решает, что и когда рисовать. Плюс производительность и SEO у Next.js ощущаются на глаз, особенно если работает ISR — инкрементальная статическая регенерация. Там, где раньше вы делали полный rebuild, теперь можно обновить ровно те страницы, которые изменились, и не трогать остальной сайт. Это экономит минуты и нервные клетки. А ещё это идеальный сетап под нормальную автоматизацию через Make.com, где у нас и сценарии, и уведомления, и аккуратное логирование.

К слову о поиске. Часто мне пишут: мол, я искал «wordpress headless download», где скачать готовое, а там какая-то мешанина. Скачивать тут нечего. Headless — это архитектура, не архив с темой. Бэкенд остаётся WordPress, а фронт вы собираете на Next.js и подключаете к API. Всё остальное — вопрос дисциплины и пары аккуратных вебхуков.

ISR без фанатизма: как заставить Next.js обновлять только нужное

Если совсем коротко, в Next.js можно статически сгенерировать страницу, а затем указывать для неё срок актуальности. После истечения revalidate страница перестроится по первому заходу, почти незаметно для посетителя. Но настоящий кайф начинается с on-demand ISR: вы создаёте у себя в Next.js API-роут, например /api/revalidate, защищаете его секретом и дергаете при изменениях в WordPress. В ответ Next.js точечно регенерирует путь или набор путей. Технически это одна POST ручка и список путей для обновления, но эффект на проекте прямо драматический — меньше сборок, меньше простоя, меньше криков в чатике с редакторами. Тем более когда у вас много трафика из поиска и не хочется гонять rebuild из-за двух новых тегов на одной записи.

Создание страницы сайта на автомате — Страницы генерируются, а мы экономим нервы. Автоматическая публикация плюс ISR — рабочая связка.

Куда жать в WordPress, чтобы оно само

Нужно дать WordPress голос. При публикации или обновлении запись должна отправлять событие наружу. Вариантов несколько. Самый простой — плагин типа WP Webhooks или аналогичный, который на post_published, post_updated, media_added стучится по вашему URL и передаёт JSON с ID, типом, слагом и статусом. Чуть сложнее — написать маленький мув в functions.php, но чаще нет смысла, готовые плагины уже умеют ретраи и заголовки. Авторизоваться удобно через Application Passwords — это штатный механизм, выдаёте сервису отдельный пароль и не храните личные. С точки зрения безопасности всё сводится к двум правилам: отдавайте минимум данных и подписывайте запросы секретом. Если уж решили дергать Next.js напрямую, не забудьте проверять подпись и IP, а лучше прокиньте всё через Make.com, он и фильтры сделает, и повисшие очереди пережует.

Make.com как диспетчер: ловим вебхук и раздаём команды

Сценарий в Make.com собирается за 10 минут, если не отвлекаться на кофе. Сначала модуль Webhooks — Catch hook, получаем JSON с WordPress. Сразу ставим фильтры, чтобы черновики и автосейвы не летели в прод, а обновления категорий мы не путали с новыми публикациями. Дальше модуль HTTP для запроса в WordPress API, чтобы подтянуть полные данные по записи, или модуль WordPress из каталога Make — выбирайте, честно, без разницы. Потом разветвление: если изменился пост типa post — шлём POST на /api/revalidate вашего Next.js, передаём список путей, например /blog/slug и страницу категории. Если поменялась таксономия — регенерируем архивы и главную. Если обновили глобальные блоки или меню — шлём хук в Vercel Deploy Hook для быстрой пересборки, она обычно занимает 1-2 минуты и не мешает. И ещё маленький бонус — модуль Telegram в Make отправляет сообщение редакторам: «Пост такой-то обновлён, регенерация прошла, статус 200». Логи идут в Google Sheets, а ошибки улетают мне в личку, чтобы ночью не будить всех.

Техническая мелочь, но важная: ставьте ретраи на запрос к вашему API Next.js и ограничивайте частоту. Если редактор 7 раз подряд нажал «обновить», нет нужды дергать ревайдейт 7 раз. Ставим группировку по ID записи и окно в минуту. Это звучит занудно, зато экономит лимиты и нервы, особенно на больших проектах.

Пример на салфетке: что дергать у Next.js

В самом Next.js создайте файл pages/api/revalidate.js и внутри проверяйте секрет, затем вызывайте res.revalidate(‘/нужный-путь’). Обычно я передаю массив путей, а на стороне API просто иду циклом. Хороший тон — возвращать JSON с перечнем обновлённых страниц и временем. Потом этот ответ уходит в Make и аккуратно складывается в лог. Если используете App Router, названия там будут другие, но логика та же. В большинстве случаев этого достаточно, чтобы обновить карточку, архив и главную, а rebuild оставить в покое до ночи, когда никто не смотрит. Впрочем, если у вас меняется схема данных или пакет с компонентами, полноценный деплой всё равно нужен — тогда Make дергает специальный Deploy Hook на Vercel или Netlify и шлёт вам чашку чая в Телеграм. Ну почти.

Make AI агент, инструменты — Make в роли спокойного диспетчера: ловит вебхуки, решает, что пересобрать, и не спорит.

Хостинг и российские реалии: что выбрать, чтобы не страдать

Для Next.js чаще всего берут Vercel, у него ISR работает из коробки и on-demand ревайдейт как дома. Netlify тоже ок и предсказуем. Если хочется ближе и с привычной бухгалтерией, берут Timeweb Cloud, Selectel или VK Cloud, поднимают Docker и запускают Node с reverse proxy. ISR останется ISR, просто revalidate будет крутиться на вашей машине. Медиа из WordPress лучше отдать на CDN, у кого-то это Cloudflare, у кого-то локальный CDN от хостера. Главное — не забыть чистить кэш после ревайдейта. Делается либо отдельным шагом в Make.com через HTTP в API CDN, либо через маленький воркер. В России это особенно важно, потому что дальние регионы иногда видят старые картинки дольше положенного и начинают писать гневные письма. Справедливо, кстати.

Инкрементальная публикация по уму: какие пути обновлять

Боль начинающих в том, что они ревайдают только сам пост. Но страницы с тегами, категориями, главная, RSS и sitemap тоже завязаны на контент. Я обычно собираю матрицу зависимостей: пост — его слаг, архив категории, архив тега, главная, лента. В Make это превращается в один шаг с вычислением массива путей. Нужна картинка? Проверяем, менялось ли featured image — тогда отдельно чистим кэш на CDN по её URL. И ещё маленький трюк: если у вас next js wordpress проект с динамическими страницами и вы генерируете мета через getStaticProps, после ревайдейта мета обновится сама, а вот OpenGraph для соцсетей иногда тянет старое. Решается повторным запросом от Make к вашему рендеру, пусть прогреет страницу заранее. На это уходит смешные 200 миллисекунд, но экономит репутацию в соцсетях.

Автоматизация введения соцсетей — Обновили пост — прогрели OG — отдали соцсетям свежую карточку. Иначе придётся перепостить, а это боль.

Безопасность и предсказуемость: мелочи, на которых держится проект

Секреты только в переменных окружения, никакой заливки ключей в репозиторий. Подписанные вебхуки, проверка заголовков и IP, ограничение по частоте, и самое главное — идемпотентность. Если Make получил два одинаковых события, он должен сделать одно действие. Помогают уникальные ключи на основе post_id плюс штамп времени. Логи лучше хранить минимум месяц, я обычно складываю в базу и дублирую в таблицу, чтобы продукт-менеджер мог смотреть без доступа к серверу. На ошибки ставим алерты в Телеграм, а уже потом в почту, иначе писем будет как в новогоднюю ночь. И ещё момент, который часто забывают: бэкапы. Headless не спасает от того, что кто-то удалил таксономию или переименовал слаг. Пусть Make по вечерам выгружает список постов и схем в архив. Никто не заметит, пока не понадобится, а потом будут вспоминать добрым словом.

Небольшая история, почему автоматизация окупается

У нас был новостной проект на next js wordpress связке, у редакции пульс 120 каждую пятницу. Публикаций много, каждую минуту что-то обновляется, а rebuild при трафике ночевал по 10 минут. Поставили вебхуки из WordPress, завернули всё в Make и включили on-demand ISR. В первую неделю время между «Опубликовать» и обновлением на сайте сжалось до 1-3 секунд, а общий билд ушёл на ночь и стал занимать вдвое меньше. Редакция перестала писать «не обновляется», а разработчики начали спать. Кажется, один фронтендер пересел с кофе на чай, но это не точно. И да, рекламный отдел заметил рост CTR из поиска, потому что страницы стали быстрее. Не магия, просто архитектура без лишних перекосов.

Хочется повторить? Пара опорных шагов

Стартовый набор одинаковый почти для всех. Вы определяете список страниц, которые нужно ревайдать при разных событиях, и закладываете это в сценарий Make. Настраиваете вебхуки в WordPress, включаете Application Passwords для сервисного пользователя и добавляете проверку подписи. В Next.js поднимаете /api/revalidate с секретом и логируете входящие запросы. Для деплоя создаёте Deploy Hook на Vercel или аналог на вашей платформе. Плюс канал в Телеграм для уведомлений и простая табличка для логов. Всё, дальше вы только подкручиваете мелочи. Если хочется ускорить процесс, берите готовые пресеты и блюпринты, они экономят недели проб и ошибок. Да, я слегка рекламирую, но только потому что сам эти ошибки уже набил.

Хотите научиться автоматизации рабочих процессов с помощью сервиса make.com и нейросетей ? Подпишитесь на наш Telegram-канал. Если нужен быстрый старт с практикой, вот наши материалы: Обучение по make.com и библиотека готовых сценариев Блюпринты по make.com. Регистрация в Make — по ссылке партнера, чтобы получить бонусы и не потеряться в меню: make.com.

Под капотом для тех, кто любит конкретику

Если хочется «рецепт», то он такой. На стороне WordPress подключаете плагин вебхуков и добавляете события на post_published, post_updated, term_updated, menu_updated. Пэйлоад короткий: id, type, slug, status, changed_paths по-минимуму. В Make сценарий принимает вебхук, тянет из WP или GraphQL точные пути, строит массив: сам пост, архивы, главная, RSS, sitemap. Затем HTTP модулем шлёт POST на ваш Next.js /api/revalidate с заголовком Authorization: Bearer ваш_секрет. Внутри Next.js вы проходите по массиву и вызываете revalidate для каждого пути. Если событие из блока шаблонов или меню — дополнительно дергаете Deploy Hook и шлёте в CDN чистку кэша по маске. И да, ставьте метки времени, чтобы не гонять одну и ту же страницу чаще раза в минуту. Всё это звучит громоздко, но в интерфейсе Make получается из 6-8 модулей, выглядит аккуратно и чинится быстро, если вдруг что.

Про интеграции, которые пригодятся завтра

В next js wordpress проектах часто всплывают мелкие задачи: синк медиа с S3 или российским облаком, уведомления в рабочий чат, пересборка PDF каталога ночью, публикация анонса в соцсетях. Всё это отлично выносится в Make рядом со сценарием ревайдета, никаких лишних серверов. И ещё одна полезная штука для редакции — кнопка «обновить кеш» в админке WordPress, которая просто дергает ваш Make вебхук и инициирует ревайдейт страниц без публикации. Сколько нервов это экономит, словами не описать.

Если вы сейчас гуглите next js wordpress и тонете в гайдах, не переживайте. Начните с малого: один вебхук, один сценарий в Make, один API роут в Next.js. Дальше появится вкус к аккуратной автоматизации, и сайт перестанет жить по законам лотереи. И да, если нужен быстрый разгон, я собрал серию практических уроков и готовых пресетов с русскими кейсами и интеграциями, там без эзотерики, только рабочие штуки: Обучение по make.com и готовые схемы Блюпринты по make.com. Регистрация тут, вдруг пригодится прямо сегодня: make.com.

FAQ

Чем headless WordPress отличается от обычного? В headless wordpress вы используете WP как CMS и API, а фронт собираете на отдельном приложении, например Next.js. Это даёт скорость, контроль и гибкость, но требует настроить обмен событиями и деплой отдельно.

Как настроить on-demand ISR в Next.js? Создайте API маршрут, проверьте секрет, вызывайте revalidate для нужных путей. Триггерите его из WordPress через Make.com. Для App Router API метод аналогичный, просто структура другая.

Когда нужен полный деплой, а когда хватает ревайдейта? Ревайдейт для контента и таксономий. Полный деплой — при изменении зависимостей, компонентов, схемы данных или глобальных конфигов. В сценарии Make можно развести это по условиям, чтобы не трогать сборку без необходимости.

GraphQL или REST для next js wordpress? Если нужен гибкий выбор полей — ставьте WPGraphQL. Если API простой и у вас мало типов, REST тоже ок. На ISR это никак не влияет, важнее стабильность ответа и кэширование.

Как быть с кэшем CDN и соцсетей? После ревайдейта чистите CDN по списку путей. Для соцсетей прогрейте OpenGraph несколькими GET запросами из Make, чтобы Telegram, VK и другие схватили свежие мета.

Make.com платный? Есть бесплатный уровень на старт. На прод обычно берут платный тариф из-за лимитов и логов. Регистрация по ссылке партнёра здесь: make.com.

Что за запрос «wordpress headless download», его реально нужно что-то скачивать? Нет. Это архитектурный подход. Вы не скачиваете «headless версию» WordPress, вы просто используете его как CMS и подключаетесь к API, а фронт реализуете отдельно.

Какие хостинги выбрать в России? Для Next.js подойдут Timeweb Cloud, Selectel, VK Cloud, если хочется ближе и без лишних блокировок. Для ISR важно, чтобы Node приложение могло хранить кэш и отдавать revalidate, остальное дело привычки.

Где подсмотреть готовые сценарии и учебные материалы? Здесь собраны практические курсы и пресеты: Обучение по make.com и Блюпринты по make.com. И не забудьте подписаться на наш канал с кейсами и разборами: Telegram.