SEO для сайта на заказ: техническая база, которую нужно заложить до релиза

1. SEO начинается с архитектуры, а не с мета-тегов

В кастомном проекте поисковая оптимизация должна быть зафиксирована в техническом задании вместе с бизнес-целями. Нужно заранее понять, какие типы страниц будут жить в системе: услуги, кейсы, статьи, категории, карточки продуктов, страницы городов, сравнения, FAQ, документация, личный кабинет, закрытые разделы. Для каждого типа страницы нужны правила генерации URL, title, description, H1, хлебных крошек, open graph, schema.org, канонического адреса, индексации и внутренних ссылок. Тогда SEO становится воспроизводимой системой, а не ручной правкой отдельных страниц.

Практический ориентир простой: если редактор завтра добавит новую услугу или статью, страница должна автоматически получить корректную SEO-обвязку. Разработчик не должен каждый раз вспоминать, где формируется canonical, а контент-менеджер не должен вручную собирать карту ссылок. Хорошая архитектура задаёт инварианты: один источник данных для slug, единая функция формирования мета-тегов, понятная модель локализации, проверяемые шаблоны JSON-LD, правила robots и sitemap, которые обновляются вместе с контентом.

• Опишите все индексируемые типы страниц и отдельно перечислите страницы, которые должны быть закрыты от индексации.
• Зафиксируйте правила URL: язык, транслитерация, trailing slash, вложенность, редиректы и поведение при изменении slug.
• Сделайте SEO-поля частью модели данных, но не превращайте их в хаотичный набор ручных override без валидации.
• Проверьте, что staging не индексируется, а production не закрыт случайным noindex после релиза.

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

2. Core Web Vitals: скорость как инженерное требование

Core Web Vitals нельзя стабильно улучшить одной минификацией. LCP зависит от того, как отдаётся главный контент, какие изображения попадают в первый экран, когда загружаются шрифты, насколько тяжёлый JavaScript блокирует main thread и как CDN обслуживает статику. INP показывает, насколько интерфейс реагирует на действия пользователя в реальных условиях, а CLS выявляет небрежную работу с размерами изображений, баннерами, виджетами, формами, sticky-блоками и рекламными вставками. Если эти метрики не обсуждаются на этапе дизайна и фронтенд-архитектуры, потом оптимизация превращается в дорогое вскрытие.

Для сайта на заказ важно задать performance budget. Например: критический CSS минимален, первый экран не ждёт необязательных виджетов, изображения имеют размеры и современные форматы, шрифты ограничены по начертаниям, аналитика грузится отложенно, тяжёлые интерактивные компоненты разбиваются на чанки, а серверная часть отвечает быстро и предсказуемо. Это не борьба за абстрактные баллы Lighthouse, а защита конверсии, индексации и бюджета разработки.

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

3. Crawl budget и индексируемая структура

Crawl budget особенно важен для сайтов, где контент генерируется шаблонами: каталоги, фильтры, теги, пагинация, архивы, многоязычные версии, параметры сортировки. Поисковый робот не обязан бесконечно обходить все комбинации фильтров и дублей. Если разработка не ограничивает индексируемые состояния, сайт быстро производит тысячи слабых URL: одинаковые списки с разной сортировкой, пустые страницы, параметры UTM, внутренний поиск, технические preview, старые slug и дубли языковых версий.

На уровне архитектуры нужно решить, какие страницы имеют самостоятельную поисковую ценность. Для фильтров это обычно ограниченный набор посадочных страниц с текстом, мета-шаблоном и внутренними ссылками. Для пагинации — корректная canonical-стратегия и понятная навигация. Для старых адресов — карта 301-редиректов. Для временных страниц — запрет индексации и отсутствие ссылок из публичной структуры. Чем раньше эти правила появляются в коде, тем меньше технического долга в SEO.

• Не индексируйте внутренний поиск, параметры сортировки, служебные preview и комбинации фильтров без уникального спроса.
• Генерируйте sitemap только из канонических и доступных страниц, а не из всех записей базы данных подряд.
• Проверяйте коды ответов: 200 для живых страниц, 301 для постоянных переносов, 404 или 410 для удалённых материалов.
• Следите, чтобы robots.txt не был единственным способом скрыть мусорные URL: роботы могут знать о них из внешних ссылок.

4. Schema.org и JSON-LD: разметка, которая совпадает с контентом

Структурированные данные помогают поисковым системам понять, что находится на странице: организация, услуга, статья, FAQ, хлебные крошки, продукт, отзывы, события. Для кастомной разработки преимущество в том, что JSON-LD можно генерировать из тех же данных, которые выводятся пользователю. Это снижает риск рассинхронизации, когда на странице написана одна цена или дата, а в разметке осталась старая. Разметка должна быть честной: нельзя добавлять FAQ, которого нет на странице, выдумывать рейтинг или скрывать обязательную информацию.

Хорошая схема начинается с матрицы типов страниц. Для главной и страниц услуг часто нужны Organization, WebSite, Service, BreadcrumbList и FAQPage. Для блога — Article или BlogPosting, автор, дата публикации и дата изменения. Для кейсов — CreativeWork или Article, если материал информационный. Для карточек с тарифами — Product или Offer, но только если данные соответствуют требованиям. Важно валидировать JSON-LD на сборке или в тестах, потому что одна синтаксическая ошибка может отключить весь блок разметки.

• Храните разметку рядом с шаблоном страницы, но формируйте её из общей модели данных.
• Проверяйте обязательные поля для каждого типа schema.org до релиза.
• Не размечайте то, что пользователь не видит на странице.
• Добавьте BreadcrumbList на все вложенные страницы, где есть понятная иерархия.

JSON-LD должен быть частью шаблона, а не фрагментом, который копируют вручную. Тогда новая статья, услуга или кейс получает правильную разметку автоматически.

5. i18n и hreflang: мультиязычность без дублей

Для ru/en сайта локализация — это не только перевод интерфейса. Нужно спроектировать языковые URL, связи между альтернативными версиями, fallback, карту sitemap и canonical. Если русская и английская страницы имеют разные slug, система должна знать, что это альтернативы одной сущности. Если у части материалов нет перевода, нужно решить, показывать ли fallback, закрывать страницу от индексации или отдавать 404 для отсутствующей локали. Случайный fallback часто создаёт дубли: английский URL с русским контентом или наоборот.

Hreflang должен быть симметричным: русская версия ссылается на английскую, английская — на русскую, и обе могут указывать x-default, если есть нейтральная версия или логика выбора языка. В sitemap можно включать alternate-ссылки, чтобы поисковику было проще понимать карту локалей. На уровне интерфейса переключатель языка должен вести на эквивалентную страницу, а не всегда на главную. Это улучшает UX и снижает риск того, что робот увидит разорванную языковую структуру.

• Выберите одну URL-стратегию: префиксы /ru и /en, поддомены или отдельные домены, и не смешивайте подходы без причины.
• Для каждой индексируемой страницы храните связи с альтернативными локалями.
• Проверяйте, что canonical указывает на страницу в той же локали, а hreflang — на альтернативы.
• Не отдавайте автоматический машинный перевод как полноценную SEO-страницу без редакторской проверки.

6. Внутренняя перелинковка как архитектура навигации

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

Нужно различать навигационные ссылки, контекстные ссылки и блоки рекомендаций. Меню отвечает за основные разделы. Хлебные крошки показывают иерархию. Контекстные ссылки внутри текста уточняют смысл. Рекомендательные блоки помогают открыть соседний контент. Если все ссылки называются одинаково — подробнее, читать, открыть — поисковик и пользователь получают меньше контекста. Анкор должен быть естественным, но достаточно конкретным: разработка корпоративного сайта, аудит безопасности, интеграция с CRM.

• Создайте матрицу связей между услугами, кейсами, статьями, FAQ и страницами конверсии.
• Используйте осмысленные анкоры, а не одинаковые CTA для всех внутренних ссылок.
• Проверяйте сиротские страницы: если URL есть в sitemap, но на него никто не ссылается, это сигнал проблемы.
• Следите за глубиной: важные страницы должны быть доступны за два-три клика от главной или раздела.

7. Контентные шаблоны: SEO, редактура и масштабирование

Контентный шаблон — это не ограничение для автора, а способ сохранить качество при росте сайта. Для услуги шаблон может включать проблему клиента, решение, этапы работ, стек, сроки, результаты, FAQ и форму заявки. Для кейса — контекст, вызов, архитектуру, интеграции, метрики, скриншоты и выводы. Для статьи — тезис, структуру разделов, практические чек-листы, внутренние ссылки и callout. Когда такие блоки описаны в модели данных, страницы выглядят цельно, а SEO-поля формируются последовательно.

Важно не превращать шаблон в набор пустых блоков. Если у страницы нет FAQ, не нужно показывать пустой раздел. Если у кейса нет метрик из-за NDA, лучше честно объяснить ограничение. Если услуга новая, можно добавить редакционный статус и не выпускать страницу в индекс до заполнения обязательных полей. Кастомная CMS или data-файлы должны помогать редактору: подсвечивать пропущенный title, слишком длинный description, отсутствие intro, дублирующий slug, неправильную локаль.

8. JavaScript SEO: рендеринг, гидратация и видимый контент

Современный фронтенд не мешает SEO сам по себе. Проблемы начинаются, когда критичный контент появляется только после клиентского запроса, meta-теги меняются после загрузки, страницы отдают пустой shell, а ошибки API превращают индексируемый URL в бесконечный skeleton. Для коммерческих страниц, статей, кейсов и категорий базовый контент должен быть доступен в HTML-ответе или через надёжный серверный рендеринг. Интерактивность можно добавлять поверх, но смысл страницы должен существовать до выполнения пользовательского JavaScript.

Нужно внимательно проектировать состояния: loading, error, empty, unauthorized, not found. Например, если карточка услуги не найдена, сервер должен вернуть 404, а не страницу с текстом ошибка загрузки и кодом 200. Если API временно недоступен, это не должно массово отдавать поисковику пустые страницы. Если часть интерфейса персонализирована, публичная SEO-часть должна оставаться стабильной. Именно поэтому техническое SEO тесно связано с backend-контрактами и обработкой ошибок.

• Отдавайте title, description, canonical, hreflang и JSON-LD до клиентской гидратации.
• Не прячьте основной текст за кликом, если без него страница теряет смысл.
• Проверяйте HTML-ответ, а не только отрисованную страницу в браузере разработчика.
• Разделяйте публичные SEO-страницы и закрытые пользовательские сценарии личного кабинета.

9. Мониторинг: SEO после релиза

Релиз не завершает техническое SEO. После запуска нужно отслеживать индексацию, ошибки сканирования, динамику Core Web Vitals, коды ответов, статус sitemap, редиректы, изменения robots, появление дублей, пустые мета-поля и аномалии трафика. Часть проверок можно автоматизировать в CI: валидировать маршруты, sitemap, JSON-LD, наличие title и canonical, отсутствие noindex на production. Часть остаётся в регулярном мониторинге: Search Console, лог-анализ, RUM-метрики, uptime, алерты по 5xx.

Особенно важно контролировать изменения. Новая интеграция может замедлить первый экран. Новый баннер может сдвинуть контент и ухудшить CLS. Новый раздел может создать сотни URL без canonical. Правка роутинга может сломать hreflang. Поэтому у проекта должен быть SEO-регламент релизов: что проверяем перед выкладкой, кто принимает изменения, какие страницы считаются критичными, как быстро реагируем на ошибку индексации и где хранится карта редиректов.

• Добавьте smoke-тесты для ключевых URL: код ответа, title, canonical, hreflang, robots, наличие основного H1.
• Настройте алерты на рост 404, 5xx, резкое падение трафика и ухудшение полевых Core Web Vitals.
• Храните карту редиректов в репозитории или управляемой таблице с владельцем и историей изменений.
• Проводите SEO-регрессию перед крупными релизами, миграциями и изменениями структуры URL.

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

10. Частые ошибки разработки и практический чек-лист

Большинство SEO-проблем на кастомных сайтах появляется не из-за сложных алгоритмов поисковиков, а из-за простых инженерных промахов. Команда забывает закрыть staging, меняет URL без редиректов, отдаёт одинаковые title на сотни страниц, генерирует sitemap из черновиков, делает фильтры индексируемыми по умолчанию, рендерит текст только на клиенте, добавляет nofollow на внутренние ссылки, не задаёт размеры изображений, публикует английские страницы с русским fallback, оставляет canonical на главную или отдаёт 200 для удалённого материала.

Хорошая новость: эти ошибки предотвращаются процессом. Нужны SEO-требования в ТЗ, review шаблонов, автоматические проверки, staging-чеклист, согласованный план миграции, мониторинг после релиза и понятная ответственность. Для бизнеса это означает меньше потерь трафика, быстрее вывод новых страниц, прозрачнее работа с контентом и ниже стоимость исправлений. Для разработчиков — меньше хаотичных задач после запуска и меньше конфликтов между продуктом, маркетингом и технической командой.

• До разработки: опишите типы страниц, URL-правила, локали, schema.org, sitemap, robots, redirects и требования к скорости.
• Во время разработки: проверяйте HTML-ответ, шаблоны мета-тегов, коды статусов, внутренние ссылки и поведение ошибок.
• Перед релизом: проверьте production robots, отсутствие noindex, карту 301, sitemap, hreflang, Core Web Vitals и аналитику.
• После релиза: мониторьте Search Console, логи, индексацию, 404/5xx, скорость, дубли и поведение новых шаблонов.

Enginx.ru закладывает техническое SEO в структуру кастомного сайта с первого дня: так проект легче масштабировать, безопаснее развивать и проще продвигать без дорогостоящих переделок.