Влияет ли CMS на продвижение сайта — Какую CMS выбрать

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

Что именно оценивает поиск, а что — нет

Поисковая система работает с тем, что отдаёт сервер: HTML-код страницы, ответ сервера, скорость загрузки, содержимое текста, ссылки, изображения. Робот не запрашивает у сайта паспорт движка и не хранит список «хороших» и «плохих» систем. Две страницы с одинаковым кодом, одинаковой скоростью и одинаковым текстом будут оценены одинаково, даже если одна собрана на популярной бесплатной системе, а вторая написана программистом с нуля.

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

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

Где движок всё-таки решает исход

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

• Полнота возможностей. Если движок не умеет канонические адреса, вы не почините дубли фильтров штатно — придётся дописывать код или мириться с потерями.
• Скорость работы команды. Правка метатегов на 400 страницах руками — это две недели работы. Через шаблон с подстановкой — двадцать минут. Разница в две недели на каждой итерации складывается в год отставания от конкурента.
• Скорость отдачи страницы. Тяжёлый шаблон с двадцатью подключаемыми модулями отдаёт первый экран за четыре секунды. Пользователь уходит, поведенческие сигналы падают, конверсия падает вместе с ними.

Получается парадокс: движок не влияет на ранжирование, но влияет почти на всё, что влияет на ранжирование. Именно поэтому спор «какая CMS лучше для SEO» бесконечен — обе стороны говорят о разном.

Обязательный набор: что система должна уметь

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

Требование к движку	Зачем нужно	Как проверить
Ручное управление адресом страницы	Адрес отражает структуру и запрос, при переименовании раздела ссылки не ломаются	Создать страницу на демо, задать адрес вручную, затем изменить его и проверить, появился ли редирект
Метатеги для каждой страницы отдельно	Уникальные title и description для всех типов страниц, включая карточки и фильтры	Открыть карточку товара и страницу фильтра, найти поля title, description, H1
Шаблоны метатегов с подстановкой переменных	Тысяча карточек получает осмысленные заголовки без ручной работы	Задать шаблон вида «Название — Категория — Город» и посмотреть результат на десяти карточках
Управление структурой заголовков	Один H1 на странице, логичная вложенность H2 и H3 в тексте	Посмотреть исходный код: сколько H1 выдаёт шаблон, не завёрнуты ли в заголовки элементы меню
Автоматическая карта сайта	Робот быстрее находит новые и изменённые страницы	Открыть адрес карты, проверить обновление после публикации новой страницы
Канонические адреса	Склейка дублей сортировок, пагинации и параметров	Открыть страницу сортировки, найти в коде тег canonical и проверить, куда он ведёт
Постоянные редиректы 301	Смена адресов и склейка версий сайта без потери накопленного веса	Изменить адрес страницы и проверить код ответа на старом адресе
Микроразметка	Расширенные сниппеты: цена, наличие, рейтинг, хлебные крошки	Прогнать карточку через валидатор структурированных данных
Управление индексацией	Служебные и мусорные страницы не попадают в индекс	Проверить редактируемость robots.txt и наличие переключателя noindex у страницы
Кэширование готовых страниц	Сервер отдаёт страницу без пересборки, время ответа падает в разы	Замерить время ответа при первом и повторном запросе
Обработка изображений	Автоматические размеры, современные форматы, отложенная загрузка	Загрузить фотографию на 3 МБ и посмотреть, что окажется в коде страницы
Массовые операции	Изменение сотен страниц одной операцией, а не по одной	Попробовать выделить пятьдесят страниц и заменить в них общий фрагмент

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

Адреса страниц: главная точка риска

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

На что смотреть предметно:

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

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

Метатеги: шаблоны, подстановка, массовые правки

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

Проверять надо не саму возможность, а её глубину. Часто шаблон работает для карточек, но не работает для категорий. Или работает для категорий, но не работает для страниц фильтра — а именно фильтры дают магазину основную массу низкочастотного трафика. Спросите прямо: можно ли задать отдельный title и текст для комбинации «категория плюс два выбранных фильтра». Если ответ «нет» — половина потенциала магазина закрыта.

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

Подробнее об этом — в статье «Как влияет Яндекс рейтинг и Яндекс отзывы на продвижение сайта».

Дубли из фильтров, пагинации и параметров

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

Источники дублей по частоте:

• Сортировки: по цене, по популярности, по новизне — каждая даёт отдельный адрес с тем же набором товаров.
• Пагинация: вторая, третья, сороковая страница списка с одинаковыми метатегами.
• Комбинации фильтров: три фильтра по пять значений дают сто двадцать пять адресов, из которых полезны пять.
• Метки рекламных кампаний и идентификаторы переходов, попадающие в индекс.
• Печатные версии страниц и служебные варианты вывода.
• Один товар, привязанный к нескольким категориям, доступный по нескольким адресам.

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

Скорость, кэш, вес шаблона и изображения

Помогу с продвижением: SEO-продвижение от Анатолия Кузнецова — вывожу сайты в топ Яндекса белыми методами.

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

Что смотреть:

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

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

Микроразметка и управление индексацией

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

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

Классы решений и их потолок

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

Класс решения	Что даёт	Чем ограничивает	Кому подходит
Универсальные системы с открытым кодом	Огромная экосистема дополнений, любые задачи продвижения закрываются готовыми модулями, много специалистов на рынке	Легко перегрузить лишними расширениями, требуется регулярное обновление и внимание к безопасности	Сайты услуг, контентные проекты, небольшие и средние магазины
Коммерческие системы для магазинов	Готовая товарная логика, склад, обмен с учётной системой, встроенные инструменты для адресов и метатегов	Ежегодные платежи за лицензию, тяжёлое ядро, дорогая доработка нестандартных вещей	Магазины с большим ассортиментом и обменом с бухгалтерией
Конструкторы сайтов	Запуск за считанные дни без разработчика, хостинг и обновления входят в подписку	Жёсткие рамки по адресам, коду, разметке и скорости, перенос на другую платформу почти невозможен	Лендинги, тесты гипотез, совсем небольшие сайты услуг
Статические генераторы	Максимальная скорость отдачи, минимум уязвимостей, дешёвый хостинг	Нет привычной админки, публикация через сборку, сложная динамика вроде корзины требует отдельных сервисов	Документация, блоги, справочные и контентные проекты
Самописные системы	Ровно та логика, которая нужна бизнесу, ничего лишнего в коде	Зависимость от автора, отсутствие обновлений и сообщества, каждая функция для продвижения пишется с нуля и оплачивается отдельно	Проекты с нестандартными процессами и постоянной командой разработки

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

Конструкторы: где удобство упирается в потолок

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

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

• Адреса. Часто нельзя задать произвольную структуру, вложенность фиксирована платформой, редиректы настраиваются ограниченно или не настраиваются вовсе.
• Код страницы. Шаблон генерируется платформой, вмешаться в него нельзя. Лишние заголовки, дублирующиеся H1, тяжёлые скрипты остаются как есть.
• Скорость. Общий для всех клиентов набор скриптов грузится независимо от того, используете вы эти блоки или нет.
• Разметка. Микроразметка либо есть в фиксированном виде, либо её нет, добавить свою нельзя.
• Перенос. Забрать сайт с платформы обычно нельзя. Уходя, вы уходите без страниц, а значит, переносить придётся вручную, с полным перезапуском адресов.

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

Тему разбирал отдельно: «Влияет ли возраст домена на продвижение сайта».

Самописные системы: зависимость от одного человека

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

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

Сопутствующие сложности:

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

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

Как оценить движок до выбора

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

Что сделать на демо:

• Создать страницу, задать ей адрес вручную, затем изменить адрес и проверить, появился ли редирект.
• Найти поля title, description и H1 у карточки, категории и страницы фильтра.
• Настроить шаблон метатегов с подстановкой и посмотреть результат на нескольких страницах.
• Открыть исходный код страницы и посчитать заголовки H1, подключаемые файлы и вес первого экрана.
• Загрузить тяжёлую фотографию и посмотреть, что попало в код.
• Проверить карту сайта: обновилась ли после публикации.
• Попробовать массовую операцию над списком страниц.

Что спросить у разработчика, не принимая ответ «конечно, всё это есть»:

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

Последний вопрос обязателен. Ответ на него часто определяет выбор сильнее, чем все технические характеристики вместе взятые.

Миграция: когда переезжать, а когда чинить

Если нужна помощь по теме — обучение SEO-продвижению.

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

Ситуация	Переезжать или чинить	Почему
Нельзя редактировать метатеги, адреса и заголовки без программиста	Переезжать	Базовая работа заблокирована, каждая правка стоит денег и недель ожидания
Движок не обновлялся годами, автор недоступен	Переезжать	Риск взлома и полной потери сайта выше стоимости переноса
Сайт на конструкторе упёрся в потолок по адресам и разметке	Переезжать	Ограничения платформы не обходятся, дальше расти некуда
Медленная загрузка из-за тяжёлого шаблона и лишних модулей	Чинить	Чистка шаблона, кэш и оптимизация картинок дают эффект дешевле переезда
Много дублей из фильтров и сортировок	Чинить	Решается каноническими адресами и правилами индексации в текущей системе
Сайт не растёт, но технически всё настраивается	Чинить	Проблема в структуре, текстах или спросе, движок ни при чём
Не нравится внешний вид админки	Чинить или терпеть	Удобство редактора не влияет на выдачу, переезд ради него не окупается
Магазину нужен обмен со складом, которого нет	Считать	Иногда дешевле написать обмен, чем переносить десять тысяч карточек

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

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

Смежный материал по теме — «Влияет ли скорость сайта на продвижение».

Почему «переедем на другой движок и вырастем» — ложная надежда

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

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

Переезд оправдан только как способ снять конкретное ограничение, которое вы можете назвать одним предложением. «Мы не можем сделать посадочные страницы под фильтры, а это восемьдесят процентов нашего низкочастотного спроса» — оправдан. «Хотим более современный движок» — не оправдан.

Что тянет сайт вниз независимо от движка

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

• Структура собрана не под спрос. Разделы придуманы из головы или скопированы у конкурента, а не собраны из реальных запросов. Пользователь ищет одно, на сайте написано другое.
• Слабые тексты. Общие формулировки, отсутствие конкретики, цен, сроков и условий. Такая страница не отвечает на вопрос и не убеждает.
• Медленный хостинг. Дешёвый тариф с перегруженным сервером даёт секунду задержки ещё до того, как движок начал собирать страницу.
• Нет коммерческих блоков. Не указаны цены, нет форм заявки, контактов в шапке, условий доставки и оплаты, отзывов, гарантий. Для коммерческих запросов это важнее любой технической оптимизации.
• Нет внутренней перелинковки. Страницы висят по отдельности, вес не передаётся, часть материалов вообще недостижима из меню.
• Работа рывками. Три месяца активности, полгода тишины. Поиск любит регулярность, конкурент с постоянным темпом обгоняет за год.

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

Чек-лист выбора под тип бизнеса

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

Тип проекта	Что критично	Что можно не требовать	Типичная ошибка
Сайт услуг	Быстрое создание посадочных страниц под услуги и города, гибкие адреса, формы заявки, шаблоны метатегов	Складской учёт, сложная товарная логика, обмен с бухгалтерией	Берут тяжёлое магазинное решение и год платят за неиспользуемые возможности
Интернет-магазин	Управление фильтрами и их посадочными страницами, канонические адреса, микроразметка товара, обмен с учётной системой, скорость на больших списках	Развитый блоговый функционал, сложные форматы публикаций	Запускают на облегчённом решении и упираются в потолок на пятой тысяче товаров
Контентный проект	Удобный редактор, рубрики и метки, скорость отдачи, перелинковка, массовые правки, разметка статей	Корзина, оплата, интеграции с логистикой	Перегружают сайт визуальными конструкторами и теряют скорость
Лендинг	Скорость запуска, быстрая загрузка, аналитика и цели, простая правка текстов	Многоуровневая структура, каталоги, сложное управление индексацией	Рассчитывают собрать на лендинге поисковый трафик по широкому спросу

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

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

Правда ли, что поисковики любят какую-то одну систему управления?
Нет. В официальных справках нет ни списка рекомендованных систем, ни каких-либо преференций. Робот работает с готовым HTML и ответом сервера. Ощущение «эта система лучше ранжируется» обычно возникает потому, что на популярных решениях чаще работают опытные специалисты и чаще доступны нужные инструменты.

Мы на конструкторе, трафика мало. Переезд поможет?
Только если вы упёрлись в конкретные ограничения платформы: нельзя задать адреса, нельзя добавить разметку, нельзя ускорить загрузку. Сначала проверьте структуру и тексты. Если проблема в них, переезд принесёт только счёт от разработчика и просадку на месяц.

Сколько длится просадка после переезда?
При аккуратном переносе с сохранением адресов и корректными редиректами — от двух до четырёх недель. При смене всей структуры адресов — до трёх месяцев. Если через три месяца показатели не вернулись, значит, в переносе была ошибка: потерянные страницы, цепочки редиректов, недоехавшие тексты.

У нас самописный сайт и разработчик пропал. Что делать в первую очередь?
Получить полный доступ к хостингу и домену, сделать резервную копию файлов и базы, зафиксировать, что именно нельзя изменить без программиста. Дальше решать: если базовые вещи настраиваются, живите и чините точечно. Если заблокировано управление адресами и метатегами — планируйте переезд.

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

Разбор сайта, у которого нет ни посещаемости, ни просмотров:

5:49

Коротко

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

Оценить, тянет ли ваш движок продвижение, помогу на SEO-консультации.