CMS-архитектура для SEO: что важно заложить заранее

SEO начинается с модели контента

Мета-теги важны, но они не спасают сайт, если контентная модель не поддерживает понятные URL, локализации, связи и шаблоны страниц.

Для агентского сайта заранее нужны сущности услуг, кейсов, сегментов, FAQ и статей. Они должны быть связаны между собой, чтобы пользователь и поисковая система видели контекст.

Проверить модель можно одним вопросом: сколько кода нужно написать, чтобы добавить ещё одну страницу того же типа. Если ответ «нисколько» — модель есть. Если «поправить компонент и выкатить релиз» — модели нет, есть набор свёрстанных страниц.

Сущности, которые стоит завести сразу

Соблазн начать с одной сущности «страница» и складывать в неё всё подряд понятен, но заканчивается одинаково: через полгода в CMS лежит сто разнородных записей, у которых нет ни общих полей, ни общей логики.

Минимальный набор для сайта, который должен расти:

• услуга — что вы продаёте, с ценностью, составом работ и результатом;
• кейс — доказательство того, что услуга работает;
• сегмент или отрасль — переупаковка тех же услуг под язык конкретной аудитории;
• статья — информационный трафик и внутренние ссылки;
• FAQ — короткие ответы, которые встраиваются в страницы и в разметку.

Каждая сущность отвечает за свой тип запроса. Смешивать их в одном шаблоне — это не экономия, а будущая каннибализация: две страницы начинают конкурировать за один и тот же запрос, и поисковик выбирает между ними сам.

Базовый контракт

• локализованный slug для каждого языка;
• canonical и hreflang на уровне страниц;
• SEO title и description в CMS;
• связи статей с услугами или кейсами, если они появляются;
• fallback-данные для разработки и безопасная серверная прослойка API.

Разберём, почему каждый пункт стоит закладывать до того, как страниц станет много.

Локализованный slug

Перевод заголовка не должен автоматически превращаться в адрес: у языков разные правила транслитерации, а адрес — это то, что нельзя менять без потерь. Slug стоит хранить отдельным полем для каждой локали и менять только осознанно.

Canonical и hreflang

Canonical нужен не только при дублях: он фиксирует одно каноническое написание адреса — со слэшем или без, с параметрами или без. Hreflang имеет смысл объявлять только тогда, когда все версии языкового кластера действительно отвечают. Ссылка на страницу, которой нет, вредит сильнее, чем её отсутствие.

SEO-поля в CMS

Title и description должны редактироваться без разработчика, но и без него не должны оставаться пустыми: у каждого поля нужен осмысленный фолбэк от заголовка и лида. Иначе первая же страница, добавленная в спешке, уйдёт в индекс без описания.

Туда же относятся управляемые флаги индексации. Возможность закрыть отдельную страницу от индексации из админки экономит релиз, но требует аккуратности: закрытая по ошибке страница выпадает из выдачи тихо.

Связи между сущностями

Связи — это то, ради чего вообще заводится модель. Статья, привязанная к услуге, даёт естественную внутреннюю ссылку; кейс, привязанный к услуге, показывает доказательство там, где оно нужно. Такая перелинковка не требует ручного труда и не ломается при переименовании.

Fallback-данные и серверная прослойка

Фронтенду не стоит ходить в CMS напрямую: между ними нужен серверный слой, который нормализует ответ, прячет токен и умеет отдавать заранее заготовленные данные, когда CMS недоступна. Это не про SEO напрямую, но именно это отличает сайт, который переживает падение админки, от сайта, который в этот момент отдаёт пустые страницы поисковому роботу.

Что ломается чаще всего

Ошибки в контентной модели проявляются не сразу: сначала всё работает, а через год выясняется, что часть страниц выпала из индекса.

Slug меняется вместе с заголовком

Редактор поправил заголовок, CMS автоматически пересобрала адрес, старый URL отдал 404. Внешние ссылки и накопленные позиции при этом теряются. Лечится тем, что slug генерируется один раз при создании и дальше меняется только вручную.

Черновик уезжает в прод

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

Дата изменения врёт

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

Одна запись живёт в двух местах

Классика: часть текста услуги лежит в CMS, а часть зашита в компоненте, потому что «так было быстрее». Редактор правит CMS, на странице ничего не меняется, и дальше в документ дописывают ещё один абзац — уже третий по счёту вариант одного и того же.

Правило простое: у каждого куска контента должен быть ровно один владелец. Если поле есть в CMS, во фронтенде его быть не должно даже как запасной вариант, кроме честного фолбэка на случай недоступности CMS.

Картинки без размеров и альтернативного текста

Медиа — часть контентной модели, а не украшение. Если у изображения нет alternativeText в CMS, он не появится и на странице; если у изображения нет заданных пропорций, страница будет прыгать при загрузке. И то и другое влияет на оценку страницы.

Локализация: решения, которые принимаются один раз

Второй язык почти всегда добавляют позже, а закладывать его нужно раньше — переезд многоязычного сайта стоит дороже, чем изначально верная схема.

Три решения определяют всё остальное.

Первое — как разделяются языки: отдельным доменом, поддоменом или префиксом в пути. Вариант влияет и на инфраструктуру, и на то, как поисковик группирует версии; менять его после запуска больно.

Второе — что считается связанным документом. Русская и английская версии одной услуги должны быть двумя локализациями одной записи, а не двумя независимыми записями с похожими заголовками. Иначе связь между ними придётся поддерживать вручную, и она рассыплется на первой же правке.

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

Почему это окупается

Правильная CMS-архитектура снижает стоимость каждой следующей страницы. Команда может добавлять статьи, кейсы и услуги без переписывания фронтенда, а разработка остаётся предсказуемой.

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

Что важно не усложнить

На первом этапе лучше не строить универсальный конструктор всех страниц. Уникальные ключевые страницы стоит оставлять на стороне фронтенда, а повторяемый контент отдавать в CMS.

Граница проходит по повторяемости. Если сущность встречается в одном экземпляре и её вёрстка уникальна — это страница фронтенда, а из CMS ей достаточно забирать тексты и SEO-поля. Если сущностей будет десятки и они однотипны — это коллекция.

Ещё одна разумная граница — язык контента. Требования к нему определяются не только редполитикой: что именно на сайте обязано быть на русском языке, разбираем в материале про русский язык на сайте и 168-ФЗ. А если в модели появляются формы и заявки, вместе с ними появляются обязанности оператора персональных данных — см. разбор политики обработки персональных данных для сайта.

Частые вопросы

Что заложить в CMS до старта разработки?

Локализованные slug'и, canonical и hreflang на уровне страниц, SEO-поля с осмысленными фолбэками, связи между сущностями и безопасную серверную прослойку API с заранее заготовленными данными.

Стоит ли делать универсальный конструктор страниц?

На первом этапе — нет. Уникальные ключевые страницы дешевле держать во фронтенде, а в CMS отдавать повторяемый контент: услуги, кейсы, статьи, FAQ.

Можно ли менять адрес страницы после публикации?

Технически можно, но каждый переезд стоит накопленных сигналов и внешних ссылок. Если менять всё-таки нужно, старый адрес должен отдавать постоянное перенаправление на новый, а не 404.

Нужно ли хранить в CMS дату изменения?

Нужна честная дата, а не автоматическая. Для коллекций её разумно вычислять по самой свежей записи, а для уникальных страниц вести вручную и обновлять вместе с текстом.