<b>Sanity хорош там, где контент — это данные, а не просто “страницы”</b>

<b>Sanity хорош там, где контент — это данные, а не просто “страницы”</b>

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

Что обычно работает в проде:
• отдельный документ под сущность, а не одну “универсальную” страницу;
• slug, title, canonical, noindex — как обязательные поля;
• блоки контента с ограничениями, чтобы редактор не ломал верстку;
• связки “категория → подкатегория → листинг” для pSEO-структуры.

Где Sanity режет ногу: если вы пытаетесь сделать из него “админку для всего”, быстро получаете хаос в schema-файлах и сложную логику в клиентах. Ещё одна типовая ошибка — отдавать редакторам слишком много свободы в Portable Text без правил для заголовков, ссылок и вставок. Тогда SEO и дизайн начинают спорить между собой.

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

Если строите медиа-сайт или pSEO-ферму, Sanity берите не “за удобный редактор”, а за дисциплину в контент-модели. Именно она потом экономит часы на правках, дублях и хаосе в выдаче.