Почему CMS влияет на SEO меньше, чем принято думать
Поисковик не знает, на каком движке собран сайт, и не имеет способа это учитывать. Он видит страницу: как быстро она открылась, что на ней написано, как она связана с другими, удобно ли ей пользоваться с телефона, что делают на ней люди.
Движок в этой цепочке стоит на шаг раньше. Он не участвует в оценке — он определяет, сможете ли вы вообще сделать то, что оценивается. Это принципиально разные роли, и их постоянно путают.
Отсюда правильная формулировка вопроса. Не «какая CMS лучше для SEO», а «даёт ли эта CMS настроить всё, что нужно, и не мешает ли она делать это быстро». На первый вопрос честного ответа нет, на второй — есть, и проверяется он за двадцать минут.
Практический вывод для владельца: если вам продают смену движка как способ вырасти в поиске, попросите показать, какие именно настройки недоступны на текущем. Часто выясняется, что доступны все, а проблема в другом — в приоритетах технической работы, которую просто не делали.
Чек-лист: 10 технических возможностей, которые должна давать CMS
Это тот самый список, по которому платформа проверяется. Первые пять — обязательный минимум: без них сайт продвигать нельзя.
- Свои title и description на каждой странице — включая страницы каталога, фильтров и пагинации.
- Человекопонятные адреса — которые вы задаёте сами, а не
?id=1732, и которые можно менять. - Canonical — чтобы указать основную версию страницы, когда их получилось несколько.
- Управляемые robots.txt и sitemap.xml — карта обновляется сама, а в robots можно закрыть служебные разделы.
- 301-редиректы — поштучно и группой, потому что структура сайта меняется всегда.
Вторые пять понадобятся, как только сайт вырастет. Отсутствие любого из них — не приговор, но повод спросить подрядчика, как это обходится.
- Микроразметка — Article, FAQPage, Organization, для магазина — Product и Offer.
- Контроль над скоростью — кэширование, сжатие картинок, возможность убрать лишние скрипты.
- Свои заголовки H1–H3 в теле страницы — без жёсткой привязки к оформлению.
- Управление служебными страницами — 404, пагинация, страницы фильтров и результатов поиска.
- Выгрузка и перенос данных — чтобы через три года уйти на другую платформу без потери страниц.
WordPress: что из коробки, что плагинами, где грабли
WordPress — самая распространённая CMS и в мире, и в рунете: по сводным оценкам 2026 года на нём работает порядка 42–43% всех сайтов в интернете. Это значит две вещи: под любую задачу есть готовое решение и под любую дыру есть готовый эксплойт.
Из коробки WordPress даёт адреса страниц, заголовки, управление robots и картой сайта на уровне настроек. Метатеги, микроразметка, редиректы и работа с canonical закрываются SEO-плагинами — это норма для платформы, а не костыль.
Грабли лежат в двух местах, и ни одни из них не про SEO напрямую. Первое — универсальная тема с конструктором страниц: она удобна в редактировании и тяжела на загрузку, потому что тянет код всех своих возможностей. Второе — плагины: в 2026 году WordPress.org ввёл обязательную проверку каждого обновления перед публикацией, а уязвимости в популярных плагинах регулярно затрагивают миллионы сайтов. Вывод простой: чем меньше плагинов и чем чище шаблон, тем спокойнее живёт сайт.
Поэтому сайты на WordPress мы собираем на своём шаблоне, а не на универсальной теме: админка остаётся понятной, а на страницу не приезжает код функций, которыми вы не пользуетесь.
Tilda и конструкторы: реальные ограничения
Конструкторы давно перестали быть «непродвигаемыми», и разговор пора вести предметно. В Tilda есть свои title и description, человекопонятные адреса, canonical, автоматически формируемые robots.txt и sitemap.xml, 301-редиректы в настройках — включая групповые, по шаблону вида /old-section/* на /new-section/*. Микроразметка добавляется кодом в настройках.
Ограничения тоже конкретные. Не настраиваются редиректы для карточек товаров из Каталога и для кириллических адресов. Нет полного доступа к коду страницы: часть вещей платформа делает по-своему, и повлиять на это нельзя. Страница собирается из готовых блоков, каждый со своим скриптом, поэтому длинные страницы легко набирают лишний вес.
Практический критерий такой. Сайт услуг на два-три десятка страниц с разными текстами конструктор вытянет, и упереться в потолок вы не успеете. Проект, который растёт из каталога и фильтров в сотни однотипных страниц, упрётся обязательно — и это тот случай, когда платформу лучше выбрать заранее, а не менять потом.
Подробное сравнение по деньгам, срокам и развитию — в отдельной статье про Tilda и WordPress.
1С-Битрикс: сильные стороны для каталогов и типовые проблемы
Битрикс силён там, где нужны каталог, учёт и обмен с 1С. Для SEO это значит важную вещь: платформа умеет массово генерировать страницы под спрос — разделы, подразделы, фильтры, — и управлять их метатегами по шаблонам. На магазине с тысячами позиций это не удобство, а единственный способ вообще закрыть спрос.
Технический минимум из чек-листа закрыт целиком: адреса, метатеги по шаблонам, canonical, редиректы, карта сайта, микроразметка в шаблонах компонентов, штатное кэширование.
Типовые проблемы тоже известны и повторяются из проекта в проект. Первая — скорость: тяжёлые шаблоны и некэшируемые компоненты дают медленные страницы, и лечится это настройкой кэширования и переработкой шаблона, а не сменой хостинга. Вторая — бесконтрольные страницы фильтров: платформа умеет плодить комбинации параметров, и без настройки индексации в поиск уезжают тысячи почти одинаковых адресов.
Третья особенность — денежная, и её стоит знать до выбора: лицензии в 2026 году стоят от 7 100 ₽ за «Старт» до 96 500 ₽ за «Бизнес», а продление — 25% от стоимости лицензии в год. Что за это получаете и когда оно оправдано — в статье про интернет-магазин на 1С-Битрикс.
Самописные и headless-решения: свобода и её цена
Сюда относятся сайты на фреймворках и статические сборки, где содержимое хранится отдельно, а страницы собираются заранее. С точки зрения SEO это самый управляемый вариант: вы контролируете каждый байт разметки, каждую строчку адреса и скорость отдачи страницы.
Наш пример — Единый Контур: статическая сборка, каждая страница отдаётся готовым HTML, у каждой услуги своя посадочная с расчётом и формой, а в блоге больше сотни статей, разложенных по разделам.
Цена свободы — зависимость от разработчика. Добавить новый тип страницы, перестроить блок, поменять логику вывода без него нельзя. Для компании, которая правит сайт раз в квартал, это нормально. Для маркетолога, собирающего новую посадочную каждую неделю, — тормоз.
Правило выбора: свобода нужна там, где сайт — рабочий инструмент с нестандартной логикой. Если сайт живёт в режиме «текст поправить, фото заменить», за неё вы переплатите.
Что нельзя исправить после выбора платформы
Большинство ошибок обратимы: метатеги переписываются, скорость чинится, разметка добавляется. Необратимого мало, и вот оно.
- Структура адресов, если она не заложена. Когда платформа диктует вид URL и вложенность, менять их потом можно только переездом с редиректами — с просадкой и риском.
- Массовая генерация страниц. Если движок не собирает страницы по шаблону из данных, каждую посадочную придётся делать руками. На двадцати незаметно, на двухстах — отдельная работа.
- Скорость, заложенная архитектурой. Не картинки и не плагины, а сама схема сборки страницы при каждом обращении. Кэширование помогает до предела, дальше — только переработка.
- Выгрузка содержимого. Проверьте заранее, как забрать тексты, товары и страницы: где серверная часть не выгружается, переезд означает ручной перенос.
Спросите подрядчика ровно об этих четырёх вещах — и о них же стоит спросить при аудите уже работающего сайта, если вы не знаете, что досталось от прошлой команды.
Как проверить CMS на SEO-пригодность за 20 минут
Не по описаниям и не по отзывам, а руками в демо-доступе. Порядок такой.
- Создайте тестовую страницу и задайте ей свой адрес, title и description. Получилось за минуту — хороший знак.
- Смените адрес этой страницы и посмотрите, предложит ли платформа поставить 301-редирект. Не предложит — редиректы придётся делать отдельно, спросите как.
- Откройте robots.txt и sitemap.xml по прямым адресам. Карта должна существовать и обновляться сама.
- Посмотрите исходный код страницы: один ли H1, есть ли canonical, не превращены ли заголовки в картинки.
- Загрузите большую фотографию и проверьте, сжимает ли её платформа сама и отдаёт ли в современном формате.
Если все пять пунктов прошли — платформа для продвижения подходит, и дальше решают структура и тексты, а не движок. Если споткнулись на двух и больше — это не запрет, но повод заранее понять, чем вы будете закрывать эти дыры и сколько это стоит.
Что сделать самостоятельно: пройдите по чек-листу из второго раздела на своём текущем сайте и отметьте пункты, которые не получается выполнить из админки. Это и есть реальный список ограничений вашей платформы, а не тот, который вам называют. Обычно он оказывается коротким.
Если хочется разобраться в чужом наследстве до начала работ, техническая база сайта — как раз то, с чего мы начинаем, а сами сайты собираем так, чтобы этот чек-лист закрывался на этапе сборки, а не через год. Проверим, подходим ли мы друг другу.
Обсудить проект