Sanity хорош не для «сайта вообще», а для команд, где контент — это продукт

Sanity хорош не для «сайта вообще», а для команд, где контент — это продукт

Sanity часто берут как headless CMS, но его сильная сторона не в модном слове, а в схеме работы: структура данных задаётся кодом, редакторский интерфейс собирается под задачу, а контент можно переиспользовать между сайтами, приложениями и витринами.

За что его обычно выбирают:
— гибкая модель контента без лишних сущностей;
— сильный визуальный редактор и поля под сложные сценарии;
— удобен там, где у одного материала есть несколько представлений;
— хорошо ложится на Jamstack и фронтенд-команды, которые хотят меньше CMS-магии.

Где Sanity начинает мешать: когда нужен «коробочный сайт» без настройки, когда редакторам важнее готовые шаблоны, чем гибкость, и когда проект живёт на типовых страницах без сложной структуры. В таких кейсах Drupal или Ghost часто дают меньше трения.

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

Если выбираете Sanity, сначала опишите 10–15 реальных типов контента и 3-4 сценария публикации. Если они укладываются в модель без костылей — CMS подходит.