Архитектура сайта на Astro и Sanity разделяет код и контент на два независимых слоя: Astro собирает статические страницы на этапе сборки, а Sanity хранит контент в собственном облачном хранилище и отдаёт его через API. Маркетинг-команда правит тексты, изображения и структуру страниц в визуальном редакторе Sanity Studio, не трогая код и не дожидаясь релиза. Разработчик получает типизированные схемы контента, версионирование правок и скорость статического сайта.
В проектах мы регулярно видим одну и ту же картину: сайт построен на современном стеке, но любое изменение текста на лендинге превращается в тикет разработчику и ожидание релиза. Маркетинг-команда физически не может опубликовать акцию в пятницу вечером, если для этого нужен пул-реквест и деплой.
Дело не в Astro как фреймворке - он прекрасно справляется со статической генерацией. Дело в том, где живёт контент: в .md-файлах репозитория или захардкожен прямо в компонентах. Разделение через headless CMS снимает эту проблему, но не любая CMS одинаково хорошо стыкуется со статическим генератором.
Дальше - как устроена связка Astro и Sanity, что она даёт команде и когда она не нужна.
Для агентства или стартапа, где маркетинг работает быстрее, чем цикл разработки, разрыв между контентом и кодом - это конкретная потеря денег. Кампания срывает сроки, потому что лендинг под неё не обновить без разработчика, а разработчик занят другой задачей в текущем спринте.
Headless CMS: система управления контентом без встроенного отображения страниц - она хранит данные и отдаёт их через API, а то, как их показывать, решает фронтенд.
Почему разделение контента и кода решает конкретную проблему
Классический сайт на статическом генераторе хранит контент вместе с кодом: в Markdown-файлах репозитория или прямо в разметке компонентов. Любая правка текста проходит тот же путь, что и правка кода - коммит, ревью, деплой.
Для команды из одного-двух разработчиков это терпимо. Для агентства с несколькими клиентами или стартапа, где маркетинг выкатывает лендинги каждую неделю, это узкое место. Каждая правка текста конкурирует за внимание разработчика с багами и фичами.
Headless CMS решает эту проблему буквально - убирает контент из репозитория. Sanity хранит контент отдельно, в облаке, и отдаёт его через API на этапе сборки сайта. Код и контент версионируются и деплоятся независимо друг от друга.
Разработчик описывает схему полей один раз - что такое статья, что такое страница услуги, какие поля обязательны. Дальше маркетинг заполняет и меняет контент в рамках этой схемы сам, без участия разработчика на каждой правке.
Это не абстрактное архитектурное решение ради красоты. Это конкретный ответ на вопрос “почему обновление текста на сайте занимает три дня вместо десяти минут”.
Если сайт уже существует и стоит на связке с контентом внутри кода, переход на такую архитектуру - это доработка существующего сайта, а не проект с нуля. Схему можно вводить постепенно, начиная с самых часто редактируемых разделов - блога, лендингов кампаний, страниц услуг.
Как устроена связка Astro и Sanity архитектурно
Технически связка строится на трёх компонентах: хранилище контента, механизм запроса данных и стратегия обновления собранного сайта.
Content Lake: облачное хранилище контента Sanity, где данные лежат в виде структурированных JSON-документов, а не файлов. Это не база данных в привычном смысле - это управляемый сервис, к которому Astro обращается через API на этапе сборки.
Схема контента описывается в Sanity Studio - отдельном редакторском приложении, которое разворачивается рядом с сайтом или отдельно. Разработчик задаёт типы документов и полей в коде схемы: заголовок, изображение, связанные документы, вложенные блоки текста.
Чтение данных на стороне Astro идёт через GROQ - собственный язык запросов Sanity, спроектированный для выборки вложенных и связанных документов одним запросом, без пачки отдельных обращений к API. Официальный плагин @sanity/astro подключает клиент Sanity к проекту и упрощает типизацию результатов запроса; синтаксис GROQ и текущая версия API описаны в документации Sanity, а работа с источниками данных на стороне Astro - в Astro Content Layer.
Дальше вступает стратегия генерации. Astro по умолчанию собирает страницы статически: HTML генерируется на этапе сборки и раздаётся как обычные файлы, без обращения к API на каждый визит посетителя. Это даёт скорость статики, но создаёт вопрос - как быстро изменение в Sanity Studio попадёт на живой сайт.
Здесь работает инкрементальная ревалидация (ISR) или запрос по требованию (on-demand revalidation): вместо пересборки всего сайта заново обновляется только страница, контент которой изменился, через webhook от Sanity к хостингу. На практике это означает, что правка в Studio доходит до продакшена за секунды, а не после полного цикла сборки.
Что получает маркетинг-команда
Маркетинг-команда получает интерфейс, где правки контента не зависят от очереди задач разработки.
Sanity Studio - это визуальный редактор с настраиваемыми полями под конкретный тип контента: не голое текстовое поле, а форма с превью изображения, выбором связанных статей, проверкой обязательных полей. Ошибиться в структуре сложнее, чем в сыром Markdown.
Ключевые возможности для маркетинга:
- Редактирование текста, изображений и метаданных без доступа к коду и репозиторию.
- Превью изменений до публикации - можно посмотреть, как будет выглядеть страница, прежде чем она станет видна посетителям.
- История версий документа: любую правку можно откатить, увидеть, кто и когда её внёс.
- Совместное редактирование в реальном времени, если над контентом работают несколько человек.
- Публикация без деплоя разработчика - контент уходит на сайт через webhook и ревалидацию, а не через
git push.
На практике это закрывает конкретный сценарий: маркетолог готовит лендинг под кампанию вечером в пятницу и публикует его сам, не дожидаясь понедельника и свободного окна у разработчика.
Что получает разработчик
Разработчик получает предсказуемую типизацию и меньше ручной работы на рутинных правках контента.
Схема в Sanity Studio описывается кодом - это значит, что структура контента версионируется в git вместе с остальным проектом, а не живёт только в голове у того, кто её придумал. Типы документов можно превратить в TypeScript-типы для запросов, и ошибка в структуре данных проявится на этапе сборки, а не у пользователя в браузере.
Практические преимущества для разработки:
- Контент отделён от деплоя кода: правка текста не требует прогона CI/CD ради опечатки.
- GROQ-запросы выбирают ровно те поля и связи, которые нужны конкретной странице, без лишней нагрузки на API.
- Статическая генерация Astro даёт высокий базовый результат по Core Web Vitals без ручной оптимизации.
- Версионирование контента в Content Lake упрощает откат при ошибке редактора.
Издержка - дополнительный слой инфраструктуры и необходимость поддерживать схему в актуальном состоянии. Это не бесплатно, но обычно дешевле, чем ручные правки кода на каждую опечатку.
Пошаговая настройка
Порядок работ типовой для большинства проектов на Astro, но объём каждого шага зависит от количества типов контента на сайте.
1. Схема контента в Sanity Studio
Сначала описываются типы документов: страница, статья блога, карточка услуги, элемент меню. Для каждого типа задаются поля - текст, изображение, ссылка на другой документ, массив вложенных блоков.
Схему стоит проектировать от реальных страниц сайта, а не абстрактно. Если на сайте есть страницы услуг с одинаковой структурой, у них должен быть один тип документа с одинаковым набором полей, а не отдельная схема под каждую страницу.
2. Интеграция через официальный плагин
Официальный плагин @sanity/astro подключает клиент Sanity к проекту и настраивает базовую конфигурацию - идентификатор проекта, набор данных (продакшен, стейджинг) и версию API. После установки Astro получает доступ к клиенту для GROQ-запросов и, при необходимости, к визуальному редактированию через Sanity Studio, встроенную в тот же проект.
3. GROQ-запросы на этапе сборки
Каждая страница или коллекция страниц Astro формирует свой GROQ-запрос: какие поля документа нужны, какие связанные документы подтянуть, в каком порядке отсортировать результат. Запрос выполняется в статических функциях генерации путей (getStaticPaths) на этапе сборки, и результат превращается в готовый HTML.
4. ISR и ревалидация по запросу
Финальный шаг - подключить webhook от Sanity к хостингу, чтобы изменение контента запускало ревалидацию нужной страницы, а не пересборку всего сайта. Конкретный механизм зависит от хостинга: часть провайдеров поддерживает встроенный on-demand revalidation, часть требует отдельной serverless-функции, которая принимает webhook и инициирует точечную пересборку.
Ограничения и когда это избыточно
Связка Astro и Sanity не универсальное решение для любого сайта - у неё есть цена, и иногда эта цена не окупается.
Ограничения, которые стоит учитывать:
- Дополнительный слой инфраструктуры: Content Lake, схема, плагин, webhook-ревалидация - больше движущихся частей, чем контент прямо в файлах репозитория.
- Задержка между правкой в Studio и появлением на сайте без настроенной ревалидации по запросу - контент обновляется только при следующей полной пересборке.
- Бесплатный тариф Sanity ограничен по числу пользователей и объёму запросов к API; крупной команде редакторов понадобится платный план.
- Сложность обратной миграции: контент хранится в проприетарном формате Sanity, и перенос на другую CMS - отдельный проект, а не разовый экспорт.
Для сайта из 5-10 статических страниц, которые правит один и тот же разработчик раз в квартал, headless CMS - это избыточная сложность. Здесь достаточно content collections прямо в коде Astro - контент в Markdown, без отдельной облачной платформы и её издержек.
Связка оправдана, когда контент меняется чаще, чем код, и его редактирует не разработчик. Если это условие не выполняется, дополнительный слой инфраструктуры просто добавляет затраты без выгоды.
Реальный кейс в цифрах
В проектах с блогом и регулярными лендингами кампаний разница до и после перехода на такую архитектуру заметна в первую очередь по циклу публикации.
До: правка текста на лендинге проходила через тикет разработчику, ветку, ревью и деплой. По нашим наблюдениям на похожих проектах, типовой цикл занимал от одного до трёх рабочих дней - в зависимости от загрузки разработчика и очереди задач.
После: публикация правки маркетологом в Sanity Studio с ревалидацией по webhook занимает от нескольких секунд до пары минут - время, которое нужно на пересборку и раздачу конкретной страницы, а не всего сайта.
По скорости сборки: для сайта на 200-500 страниц полная пересборка Astro обычно укладывается в 1-3 минуты. Точечная ревалидация одной страницы занимает секунды, потому что пересобирается не весь сайт, а один маршрут.
Числа - ориентир по типовым проектам такого масштаба, а не гарантированный результат: фактическая скорость зависит от хостинга, объёма контента и сложности запросов.
Для кого подходит эта архитектура
Связка Astro и Sanity подходит командам, где маркетинг публикует контент чаще, чем разработчик готов деплоить код: агентствам с несколькими проектами, стартапам с активным блогом и регулярными лендингами кампаний, компаниям, где сайт - основной канал привлечения лидов. Если вы строите такой сайт с нуля, разумно сразу закладывать архитектуру на headless CMS, а не переносить контент из кода позже.
Часто задаваемые вопросы
Чем Sanity отличается от Contentful или Strapi для связки с Astro?
Ключевое отличие - модель размещения и язык запросов. Sanity - полностью управляемый SaaS с собственным языком запросов GROQ и визуальным редактором Sanity Studio, который можно кастомизировать кодом. Strapi можно развернуть self-hosted на своей инфраструктуре, а Contentful ближе к Sanity по SaaS-модели, но использует REST и GraphQL вместо GROQ. Разбор различий между этими вариантами есть в статье Sanity vs Contentful vs Strapi.
Нужен ли отдельный сервер для Sanity Studio?
Нет для хранения контента - Content Lake полностью управляется Sanity. Сама Studio - это React-приложение, которое можно развернуть как статический сайт на любом хостинге или встроить прямо в проект Astro как отдельный маршрут. Отдельный бэкенд-сервер не требуется, в отличие от self-hosted CMS вроде Strapi.
Что произойдёт с сайтом, если Sanity станет недоступен?
Уже собранные статические страницы продолжат отдаваться как обычные файлы независимо от доступности Sanity - в этом преимущество статической генерации перед связкой, где рендеринг страницы происходит на каждый запрос. Пострадает только публикация новых правок: пока Content Lake недоступен, GROQ-запросы на этапе следующей сборки не выполнятся.
Можно ли использовать Sanity с другими фреймворками, кроме Astro?
Да, Sanity не привязана к конкретному фронтенду и работает с Next.js, Remix, SvelteKit и другими фреймворками через официальные или сторонние клиенты. Официальный плагин @sanity/astro - лишь один из интеграционных пакетов; сама модель Content Lake и GROQ не зависит от конкретного фреймворка.
Сколько времени занимает миграция существующего сайта на Astro и Sanity?
Зависит от объёма контента и числа уникальных типов страниц. Для сайта с блогом и десятком типовых страниц услуг перенос схемы, контента и настройка ревалидации обычно укладываются в несколько недель. Более точная оценка требует разбора текущей структуры контента и целевой схемы.
Если у вас сайт на Astro, где каждая правка текста упирается в очередь разработчика - опишите задачу команде Exceltic.dev. Разберём текущую архитектуру и оценим объём работ по переходу на Sanity.