Headless-подход к WordPress обычно ассоциируется с Next.js или Gatsby, но для небольших и средних проектов полноценный JS-фреймворк — избыточный вес: лишняя точка отказа, более сложный деплой и порог входа для последующей поддержки. WordPress REST API отдаёт данные в чистом JSON из коробки, и для многих задач его достаточно использовать напрямую, без прослойки фреймворка.
Headless означает разделение: WordPress остаётся источником данных и админ-панелью для редактирования контента, но не отвечает за финальный рендеринг HTML, который отдаётся посетителю. Это даёт гибкость фронтенда (любой стек, любая скорость обновления интерфейса) ценой того, что часть стандартной функциональности темы WordPress — виджеты, шорткоды, автоматический вывод стилей — перестаёт работать «из коробки» и требует ручной реализации на стороне фронтенда.
У любой стандартной установки WordPress эндпоинты REST API доступны по умолчанию:
fetch('https://it-gig.ru/wp-json/wp/v2/posts?per_page=10').then(r => r.json()).then(posts => { posts.forEach(p => console.log(p.title.rendered)); });
Без всякой дополнительной настройки это уже отдаёт список последних записей со всеми основными полями — заголовком, контентом, датой, featured image ID. Для кастомных полей (как мета-поля услуг на этом сайте) их нужно явно зарегистрировать с флагом show_in_rest через register_post_meta, иначе REST API их не отдаст.
«Без фреймворка» не означает «без JavaScript» — обычно это означает рендеринг через vanilla JS и шаблонизацию на стороне клиента, либо серверный рендеринг через лёгкий бэкенд (например, на том же PHP, но без обращения к базе данных WordPress напрямую — только через REST API как к внешнему сервису). Такой подход оправдан, когда интерфейс не настолько сложен, чтобы требовать state management, свойственный React или Vue — типичный пример: блог или витрина услуг с умеренной интерактивностью.
Ключевое ограничение headless без серверного рендеринга — если контент собирается в браузере через JavaScript после загрузки пустого HTML-каркаса, поисковому роботу нужно выполнить этот JavaScript, чтобы увидеть реальный контент. Google в целом справляется с этим, но с задержкой и не всегда полностью, а часть других поисковых систем — хуже. Для headless-проектов, где SEO критичен, нужен либо серверный рендеринг (SSR), либо предварительная статическая генерация HTML на этапе сборки — чистый client-side fetch для публичных, индексируемых страниц рискован.
Для операций, которые не просто читают, а изменяют данные (отправка формы, создание записи), REST API требует аутентификации. Простейший встроенный механизм — Application Passwords, добавленные в ядро WordPress: отдельный пароль для конкретного внешнего приложения, который можно отозвать независимо от основного пароля администратора, без необходимости поднимать полноценный OAuth-сервер для простых сценариев.
Headless-подход оправдан не всегда. Для сайта-визитки или блога с простой структурой без высокой посещаемости классическая монолитная тема WordPress работает быстрее по времени разработки и дешевле по поддержке, чем content-API плюс отдельный фронтенд с собственным деплоем. Переход на headless имеет смысл там, где фронтенд должен обновляться и масштабироваться независимо от бэкенда, либо когда один и тот же контент нужно отдавать сразу в несколько разных интерфейсов — на сайт, в мобильное приложение и во внешние виджеты.
Полный переход на headless без предварительной проверки, какие именно плагины и функциональность сайта завязаны на классический рендеринг темы WordPress, — распространённая причина, когда после перехода часть функций (поиск по сайту, комментарии, формы некоторых плагинов) просто перестаёт работать, потому что была реализована через PHP-шаблоны, а не через API. Вторая ошибка — открытый без ограничений REST API, отдающий черновики или приватные поля по умолчанию: доступ к чувствительным данным нужно явно ограничивать правами, а не полагаться на то, что «никто не найдёт эндпоинт». Третья — игнорирование кэширования запросов к REST API на фронтенде, из-за чего каждый визит страницы порождает повторный поход в WordPress за одними и теми же данными. Четвёртая — вывод в REST API избыточных полей по умолчанию (например, полного HTML-контента черновиков или служебных мета-полей), которые разработчик не заблокировал явно через register_post_meta с флагом show_in_rest => false, рассчитывая, что «это и так никто не найдёт».
