Вопрос «какая CMS лучше для SEO» задают так, будто существует движок с встроенным ускорителем позиций, — а на деле поисковая система не знает и не спрашивает, на чём собран сайт. Она видит HTML, скорость ответа сервера и ссылки. Отсюда единственный честный критерий выбора: не «какой движок продвигается лучше», а «даёт ли движок делать то, что нужно для продвижения, без боли и без программиста на каждую мелочь». Ниже — список этих самых «нужных вещей», сравнение популярных систем по каждому пункту и разбор ситуаций, когда движок действительно становится тормозом.
Почему сам движок на позиции не влияет
Поисковый робот получает от сервера ответ: код состояния, заголовки, HTML-документ. Внутри документа — заголовок вкладки, описание, разметка, тексты, ссылки, пути к картинкам. Что сгенерировало эту строку байтов — PHP-шаблон WordPress, компонент Битрикса, чанк MODX или самописный класс — за пределами ответа не существует. Нет поля «движок» в индексе, нет коэффициента для «правильных» CMS.
Подтверждение видно на любой конкурентной выдаче: в одном топ-10 соседствуют сайты на четырёх-пяти разных системах, и порядок между ними объясняется тематикой, ассортиментом, ссылками и коммерческими факторами, а не платформой. Если бы движок был фактором, выдача бы расслаивалась по платформам — она не расслаивается.
При этом сказать «CMS не важна» тоже неправильно. Она важна косвенно: определяет, сколько усилий стоит каждое изменение. На одной системе смена шаблона заголовков для раздела — десять минут в админке, на другой — задача программисту на несколько часов, на третьей — невозможна вовсе. Разница накапливается: там, где оптимизатор делает двадцать правок в неделю, конкурент на неудобном движке делает две.
| Утверждение | Что на самом деле |
|---|---|
| «Битрикс продвигается лучше, он же российский» | Роботу всё равно, чей движок; влияет то, что на Битриксе обычно делают крупные магазины с большим ассортиментом |
| «WordPress любят поисковики» | Просто на нём много блогов с текстами, а тексты дают трафик |
| «Самописная CMS — минус к доверию» | Минус не к доверию, а к скорости работы: часто нет базовых полей |
| «Конструктор нельзя продвинуть» | Можно, но потолок ниже и часть работ недоступна |
Что вообще требуется от движка
Перед сравнением полезно зафиксировать список требований. Это не абстрактный «SEO-функционал» из рекламных буклетов, а конкретные операции, которые оптимизатор выполняет регулярно.
- Индивидуальные title и description на каждой странице плюс шаблоны для типовых.
- Человекопонятные адреса с возможностью отредактировать вручную.
- Канонический адрес, задаваемый и автоматически, и руками.
- Управление robots.txt и метатегом noindex поштучно и по правилам.
- Карта сайта с реальными датами изменения.
- Микроразметка: хлебные крошки, товар, организация, статья, вопросы.
- Кэширование и приемлемая скорость под нагрузкой.
- Работа с изображениями: размеры, форматы, alt.
- Постраничные 301-редиректы без правки конфигов сервера.
- Свободная структура разделов и вложенности.
- Корректная пагинация и обработка параметров фильтров.
- Один адрес для мобильных и десктопа.
- Доступ к шаблонам и к коду страницы.
- Полный экспорт контента на случай переезда.
Управление title и description
Это первое, что нужно проверять. Минимум — поле для ручного ввода на каждой странице, включая карточки товаров, категории, теги и страницы пагинации. Максимум, который экономит месяцы, — шаблонизатор с переменными: название товара, категория, цена, город, номер страницы.
Плохой признак: title жёстко склеен из названия страницы и названия сайта, поменять нельзя. Тогда на каждый заголовок нужен программист либо плагин-костыль. Второй плохой признак: поле есть только у «страниц», а у товаров или новостей — нет.
Отдельно смотрите пагинацию. Если вторая страница категории отдаёт тот же title, что и первая, в индексе появляются дубли; движок должен позволять добавить в шаблон номер страницы.
| Система | Ручной ввод | Шаблоны с переменными | Пагинация в title |
|---|---|---|---|
| WordPress | Да, через плагин | Да, в плагине | Да |
| 1С-Битрикс | Да, штатно | Да, шаблоны свойств разделов | Да, настраивается |
| MODX | Да, штатно поля | Да, через чанки и сниппеты | Да, руками в шаблоне |
| OpenCart | Да, штатно | Через модуль | Через модуль |
| Tilda и конструкторы | Да | Обычно нет | Пагинации почти нет |
| Самописная | Как повезёт | Редко | Редко |
ЧПУ-адреса и 301-редиректы
Адрес должен быть читаемым, коротким и, главное, изменяемым. Автоматическая транслитерация — удобство, но она регулярно рождает длинные адреса из полного названия товара со всеми характеристиками. Нужна возможность переписать вручную.
Второй важный момент — что происходит при смене адреса. Хороший движок сам ставит 301 со старого пути на новый. Средний — просто меняет адрес, старый отдаёт 404. Плохой — не даёт менять вовсе.
Третий момент — вложенность. Некоторые системы жёстко зашивают путь вида /catalog/element/id, и вынести карточку в структуру категорий нельзя без переписывания маршрутизатора.
Постраничные редиректы
Переезды, смена структуры, объединение похожих страниц, удаление товаров — всё это требует редиректов. Хороший вариант: раздел в админке, где видно список правил, можно добавить редирект по маске и посмотреть, какие адреса дают 404.
Плохой вариант: редиректы только через .htaccess или конфиг nginx, к которому у вас нет доступа. Тогда каждая правка — письмо администратору, а список правил быстро превращается в нечитаемую простыню, где новые строки конфликтуют со старыми.
Канонические адреса, robots и noindex
Канонический адрес нужен там, где один и тот же контент доступен по нескольким путям: сортировки, utm-метки, версии для печати, товар в двух категориях. Требование к движку простое: тег canonical должен подставляться автоматически на весь сайт и переопределяться вручную на конкретной странице.
Типичная ошибка неудачных систем — canonical, указывающий на главную со всех страниц, либо canonical на самого себя вместе со всеми параметрами в адресе. Оба варианта вредят: первый выбивает страницы из индекса, второй не решает задачу дублей.
Подробнее об этом — в статье «Всплывающее окно на весь экран: Яндекс за него понижает, а вы теряете людей».
Управление индексацией
Нужны три уровня контроля: файл robots.txt редактируется из админки или по FTP; метатег noindex ставится на отдельную страницу галочкой; есть правило для целых типов страниц — например, закрыть все результаты поиска по сайту и корзину.
Отдельная головная боль — служебные разделы, которые движок создаёт сам: архивы по авторам, по датам, по меткам, версии для печати, страницы вложений. В WordPress таких страниц много, но все они управляются. В самописных системах их обычно меньше, зато нет интерфейса, чтобы их закрыть.
| Что нужно закрыть | Обычно есть на | Чем закрывают |
|---|---|---|
| Результаты внутреннего поиска | Всех системах | robots.txt плюс noindex |
| Корзина, оформление, личный кабинет | Магазинах | robots.txt |
| Архивы меток и авторов | WordPress | Плагин, отключение архивов |
| Сортировки и фильтры в параметрах | Магазинах | canonical, robots, иногда noindex |
| Страницы вложений | WordPress | Плагин, редирект на файл |
Карта сайта и микроразметка
Карта нужна автоматическая, обновляемая при публикации, разбитая на части при больших объёмах и с честным полем даты последнего изменения. Именно честность даты имеет значение: если движок пишет туда текущий день для всех адресов подряд, поле теряет смысл, и робот перестаёт на него ориентироваться.
Для магазинов с десятками тысяч товаров важна разбивка: один файл-индекс и несколько файлов по разделам. Иначе карта разрастается и обходится медленно.
Разметка данных
Помогу с продвижением: комплексное продвижение сайта — вывожу сайты в топ Яндекса белыми методами.
Разметка не поднимает позиции сама по себе, но влияет на то, как выглядит сниппет и попадает ли карточка в товарные блоки. Минимальный набор: хлебные крошки, организация с контактами, товар с ценой и наличием, статья, вопросы и ответы.
Требование к движку: разметка должна выводиться из тех же данных, что и содержимое страницы. Если цена меняется в карточке, а в разметке остаётся старая, это хуже отсутствия разметки. Плагины, которые заполняют разметку отдельными полями руками, на большом каталоге неработоспособны.
Скорость, кэширование и изображения
Здесь разница между системами реальная, но не такая, как принято думать. Тяжёлым сайт делают не движок, а количество запросов к базе на страницу, размер шаблона, десятки подключённых скриптов и невыжатые картинки. Любую популярную CMS можно довести до полусекундного ответа и любую же — уронить до пяти секунд набором плагинов.
Что действительно должно быть в движке: кэш готовых страниц, кэш фрагментов (меню, блоки товаров), кэш запросов к базе, возможность отложить загрузку второстепенных скриптов и стилей. И механизм сброса кэша, иначе правки не видны, а вы полдня ищете несуществующую ошибку.
| Система | Штатный кэш | Типичная проблема со скоростью |
|---|---|---|
| WordPress | Нет, только плагины | Плагины и тяжёлые конструкторы страниц |
| 1С-Битрикс | Многоуровневый, есть композит | Кастомные компоненты без кэша, обмен с 1С в часы пик |
| MODX | Да, кэш ресурсов и чанков | Некэшируемые вызовы сниппетов в цикле |
| OpenCart | Слабый | Каталог без кэша, много модулей |
| Конструкторы | Есть, на стороне платформы | Общий объём скриптов платформы, не убирается |
Изображения
Картинки — самая частая причина медленной загрузки. От движка нужно: генерация нескольких размеров под разные экраны, отдача в современном формате вроде webp, отложенная загрузка того, что ниже первого экрана, поле alt у каждой картинки и возможность массово его заполнить.
Отдельно проверьте, что происходит, когда контент-менеджер загружает фотографию прямо с камеры. Если движок кладёт её как есть и отдаёт в таком виде посетителю, каждая новая страница будет весить лишние мегабайты, и никакие настройки кэша это не исправят.
Структура, пагинация и фильтры
Структура важнее почти всего остального в этом списке, потому что определяет, под какие группы запросов вообще существуют страницы. От движка нужна свобода: любое число уровней, возможность создать страницу под срез ассортимента, привязать товар к нескольким категориям без дублирования адреса, менять родителя без потери адреса.
Ограничение, которое встречается у простых систем и конструкторов: только один уровень вложенности или фиксированный шаблон каталога. Для магазина с широким ассортиментом это означает, что под запросы вида «материал плюс тип плюс назначение» страниц не будет, а конкуренты их сделают.
Пагинация и фильтры
Каталог с фильтрами — главный источник мусора в индексе. Комбинации параметров плодят тысячи адресов с почти одинаковым содержимым. Задача движка — дать инструменты, а не запретить фильтры.
- Возможность выбрать, какие комбинации фильтров превращаются в отдельные страницы с собственным адресом, заголовком и текстом.
- Для остальных комбинаций — параметры в адресе плюс canonical на чистую категорию.
- Пагинация со сквозными ссылками, доступными без скриптов; кнопка «показать ещё» не должна быть единственным способом добраться до второй страницы.
- Отдельные title и description для страниц пагинации.
- Отсутствие сортировок, порождающих новые адреса без canonical.
| Ситуация | Правильное поведение | Что делают плохие движки |
|---|---|---|
| Выбран один фильтр с высоким спросом | Отдельная страница с ЧПУ и текстом | Параметр в адресе, дубль категории |
| Выбраны три фильтра сразу | Параметры плюс canonical | Индексируемая страница-дубль |
| Сортировка по цене | canonical на категорию | Новый адрес в индексе |
| Вторая страница списка | Свой title, ссылка в HTML | Тот же title, только скрипт |
Мобильная версия
Сегодня приемлем один вариант: адаптивная вёрстка, один адрес, одинаковое содержимое. Отдельный мобильный поддомен — наследие, которое создаёт две версии контента и требует перекрёстных указаний. Если движок предлагает только такой режим, это минус.
Тему разбирал отдельно: «Хлебные крошки — это не украшение, а карта сайта для робота Яндекса».
Проверять надо не факт «сайт открывается на телефоне», а то, что на мобильной версии присутствуют все тексты, все ссылки перелинковки и все элементы разметки. Скрытые на мобильном блоки текста — распространённая ситуация в шаблонах, собранных визуальными конструкторами.
Доступ к коду и экспорт данных
Рано или поздно понадобится вставить код в head, поменять порядок загрузки скриптов, добавить блок перелинковки в шаблон карточки, вывести хлебные крошки иначе. Если доступа к шаблонам нет, список доступных работ обрывается на настройках админки.
Минимальный набор: возможность править файлы шаблона, добавлять произвольный код в head и перед закрытием body, менять порядок вывода блоков. Желательно — доступ по FTP и к базе данных.
Экспорт данных
Об этом думают в последнюю очередь, а зря: невозможность забрать свои данные превращает любой недостаток движка в пожизненный. Проверяйте заранее, можно ли выгрузить тексты страниц с адресами, карточки товаров с характеристиками, картинки в исходных размерах, список заказов и клиентов.
У закрытых платформ экспорт бывает урезанным: выгружается товарная таблица, но не тексты страниц и не блог. Это и есть привязка к платформе в чистом виде.
Сравнение популярных систем
Ниже — сводка по тем же критериям. Оценки описательные, а не баллы: универсального победителя нет, есть соответствие задаче.
| Критерий | WordPress | 1С-Битрикс | MODX | OpenCart | Конструкторы |
|---|---|---|---|---|---|
| Метатеги и шаблоны | Через плагин, гибко | Штатно, гибко | Штатно, гибко | Базово, модули | Ручной ввод |
| ЧПУ и редактирование | Полное | Полное | Полное | Полное | Ограниченное |
| Редиректы из админки | Плагин | Штатно | Дополнение | Модуль | Часто нет или список |
| Фильтры без дублей | Зависит от магазина | Штатный умный фильтр | Настраивается вручную | Слабое место | Фильтров почти нет |
| Скорость из коробки | Средняя | Требует настройки | Высокая | Средняя | Средняя, не управляется |
| Доступ к коду | Полный | Полный | Полный | Полный | Минимальный |
| Стоимость доработок | Низкая | Высокая | Средняя | Низкая | Не применимо |
| Экспорт данных | Полный | Полный | Полный | Полный | Частичный |
WordPress. Лучший выбор для контентных проектов и сайтов услуг. Всё, что нужно оптимизатору, закрывается двумя-тремя плагинами, специалистов много, доработки дешёвые. Слабые места: производительность при обрастании плагинами, магазин на нём тяжелеет быстрее, безопасность требует внимания.
1С-Битрикс. Сильная сторона — крупный каталог, интеграция с учётной системой, штатный фильтр, умеющий делать индексируемые страницы под сочетания свойств. Слабая — стоимость лицензии и работ, тяжёлые шаблоны у подрядчиков, необходимость следить за кэшированием в кастомных компонентах.
Если нужна помощь по теме — создание сайтов.
MODX. Гибкий и лёгкий движок с полным контролем над HTML: шаблон пишется вручную, лишнего кода нет. Хорош для сайтов услуг, каталогов средних размеров, региональных поддоменов. Слабое место — меньше готовых решений, больше зависимость от разработчика, знакомого именно с этой системой.
OpenCart. Дешёвый старт для небольшого магазина. Базовые поля есть, но всё интересное — редиректы, разметка, фильтры без дублей — докупается модулями, а модули конфликтуют. При росте ассортимента упирается в производительность.
Tilda и конструкторы. Быстрый запуск, аккуратный дизайн, приемлемая техническая база для одностраничников и небольших сайтов. Потолок наступает там, где нужны каталог, фильтры, много типовых страниц и вмешательство в код.
Смежный материал по теме — «Как заблокировать накрутку поведенческих через .htaccess: реальный кейс, 6 подсетей и −95% ботов за час».
Самописные CMS. Диапазон от отличных до безнадёжных. Если систему писали под конкретный бизнес и поддерживает её живая команда — вопросов нет, недостающие поля добавляются. Если разработчик исчез, а исходники не документированы, каждая правка становится раскопками.
Чем плохи конструкторы для продвижения
Конструкторы не «запрещены поисковиками» — сайты на них индексируются и ранжируются. Проблемы носят практический характер и проявляются на конкурентных тематиках.
- Ограниченный доступ к коду. Вставить блок в шаблон, изменить порядок загрузки скриптов, поправить разметку в существующем блоке чаще всего нельзя.
- Скорость определяется платформой. Общий объём скриптов конструктора грузится на каждой странице, и убрать лишнее нельзя.
- Мало типов страниц. Каталог с фильтрами, вложенные категории, теговые страницы делаются вручную или не делаются.
- Слабая работа с редиректами. Постраничные правила либо ограничены по количеству, либо отсутствуют.
- Привязка к платформе. Уйти можно, но верстку придётся собирать заново; экспорт даёт данные, а не сайт.
- Ограничения по числу страниц и по тарифу. Контентный проект на сотни материалов упирается в тариф.
Практический вывод: конструктор уместен для лендинга, визитки, небольшого сайта услуг в некокурентном регионе и для проверки спроса. Если задача — собирать трафик по широкому семантическому ядру, конструктор придётся менять, и лучше сделать это до того, как накопится ссылочная масса и история страниц.
Когда движок действительно мешает
Смена CMS оправдана не потому, что она «плохая», а потому что конкретные, нужные вам работы на ней недоступны или стоят неадекватно дорого. Перечислю признаки, каждый из которых уже повод считать деньги.
- Нельзя задать индивидуальный title у части страниц — например, у карточек товаров.
- Адреса страниц не редактируются, при смене названия адрес меняется сам и старый отдаёт 404.
- Нет способа поставить постраничный 301-редирект.
- Каталог не поддерживает больше одного уровня вложенности.
- Фильтры порождают индексируемые дубли, и закрыть их нечем.
- Сайт отвечает дольше двух секунд, кэша нет, и добавить его некуда.
- Мобильная версия — отдельный поддомен с урезанным контентом.
- Нет доступа к шаблонам, любая правка — задача внешнему разработчику.
- Разработчик недоступен, исходники не передаются, обновлений нет.
Один пункт из списка — обычно повод для доработки. Четыре и больше, особенно если среди них недоступность кода и разработчика, — повод для переезда.
Что дороже: переезд или доработка
Сравнивать нужно не цену работ, а цену вместе с рисками и потерями времени. Доработка почти всегда дешевле в деньгах и безопаснее по последствиям, но она бессмысленна, если упирается в архитектуру.
| Параметр | Доработка текущей CMS | Переезд на другую |
|---|---|---|
| Стоимость | Ниже, работы точечные | Выше: перенос данных, вёрстка, настройка |
| Сроки | Дни-недели | Недели-месяцы |
| Риск потерять трафик | Минимальный | Реальный: адреса, редиректы, шаблоны |
| Когда оправдано | Не хватает отдельных функций | Ограничения в самой архитектуре |
| Что мешает | Недоступность разработчика, закрытый код | Большой объём страниц и накопленная история |
Правило, которым пользуюсь сам: если недостающие возможности можно добавить, не переписывая маршрутизацию адресов и не ломая структуру каталога, — дорабатываем. Если требуется менять сами адреса, схему категорий или движок не позволяет вмешаться в вывод HTML — считаем переезд.
При переезде критичны три вещи: сохранить адреса страниц один в один либо составить полную карту 301-редиректов; сохранить тексты и заголовки; не менять одновременно с движком ещё и структуру с дизайном. Каждое изменение отдельно — иначе при проседании не понять, что именно сработало.
Как проверить чужую CMS перед покупкой сайта
Покупая готовый сайт или принимая проект от подрядчика, движок проверяют до сделки. Порядок действий такой.
- Запросите доступ в админку и пройдите по списку требований из начала статьи: попробуйте изменить title у карточки, поменять адрес страницы, поставить редирект, закрыть страницу от индексации.
- Посмотрите исходный код страницы: есть ли canonical, корректны ли заголовки уровней, нет ли дублирования h1.
- Проверьте наличие доступа по FTP и к базе данных, спросите, передаются ли исходники шаблона.
- Выясните, кто автор системы и поддерживается ли она сейчас. Для самописных — есть ли документация и живой контакт разработчика.
- Проверьте лицензию: для платных систем нужна действующая, иначе обновления недоступны.
- Оцените скорость ответа сервера и вес страницы, посмотрите, включён ли кэш.
- Попробуйте выгрузить контент: товары, страницы, картинки. Если экспорта нет, торгуйтесь.
- Проверьте историю сайта: какие адреса были в индексе, нет ли массы мусорных страниц и следов фильтров.
- Посмотрите на количество и качество плагинов и модулей: чем больше сторонних расширений, тем выше риск конфликтов и уязвимостей.
Отдельно уточните, на чьё имя оформлены домен и хостинг. Технически это не про CMS, но чаще всего именно здесь возникает настоящая привязка, а не в движке.
Как выбрать движок под задачу
| Тип проекта | Разумный выбор | Почему |
|---|---|---|
| Блог, медиа, контент-проект | WordPress | Быстрая публикация, всё для текстов, дешёвая поддержка |
| Сайт услуг, региональная сеть | WordPress или MODX | Гибкие шаблоны, лёгкий HTML, простое масштабирование страниц |
| Магазин до нескольких тысяч товаров | WordPress с магазином, OpenCart, MODX | Достаточно возможностей при умеренной цене |
| Магазин с большим каталогом и учётной системой | 1С-Битрикс | Штатный фильтр, обмен данными, выдерживает объём |
| Лендинг, проверка спроса | Конструктор | Скорость запуска важнее потолка |
| Сложный сервис с личным кабинетом | Своя разработка | Логика важнее контента, но SEO-поля закладывать сразу |
И последнее по порядку, первое по важности: выбор движка занимает один день, а работа с содержимым сайта — годы. Проект на «неидеальной» CMS с живым контентом, продуманной структурой и внятными коммерческими условиями обгоняет технически безупречный сайт без текстов и без предложения. Движок задаёт удобство, а не результат.
Разобрать, мешает ли ваш движок продвижению, помогу на SEO-консультации.
Частые вопросы
Правда ли, что сайты на WordPress продвигаются легче?
Легче не продвигаются, а обслуживаются. Нужные оптимизатору настройки закрываются готовыми плагинами, специалистов много, правки стоят дёшево. Это ускоряет работу, но преимущества в ранжировании не даёт.
Стоит ли переезжать с самописной CMS?
Только если она блокирует конкретные работы: нельзя задавать метатеги, менять адреса, ставить редиректы, нет доступа к шаблонам. Если разработчик на связи и готов добавить недостающие поля, доработка дешевле и безопаснее переезда.
Можно ли продвигать сайт на Tilda?
Небольшой сайт услуг или лендинг — да, при условии нормальных текстов и корректных метатегов. Проект под широкое семантическое ядро с каталогом и фильтрами упрётся в ограничения платформы, и рано или поздно понадобится другой движок.
Насколько сильно скорость сайта зависит от CMS?
Меньше, чем от реализации. Определяющее — число запросов к базе на страницу, вес картинок, количество скриптов и наличие кэша. Любую популярную систему можно настроить на быстрый ответ и любую же утяжелить до нескольких секунд.
Потеряю ли позиции при смене движка?
Просадка вероятна, её глубина зависит от подготовки. Если адреса сохранены или закрыты полной картой 301-редиректов, тексты перенесены без потерь и структура не менялась одновременно, показатели восстанавливаются за несколько недель.
Коротко
- Поисковые системы не учитывают движок: они видят HTML, ответ сервера и ссылки, а не платформу.
- CMS важна косвенно — она определяет, насколько дёшево и быстро выполняются нужные для продвижения работы.
- Проверять надо конкретный список: метатеги, ЧПУ, canonical, noindex, карту сайта, разметку, скорость, картинки, редиректы, структуру, фильтры, мобильную версию, доступ к коду, экспорт.
- Конструкторы годятся для лендингов и небольших сайтов; каталог, фильтры и вмешательство в код на них недоступны.
- Переезд оправдан только при архитектурных ограничениях; во всех остальных случаях дешевле и безопаснее доработка.
Увеличьте позиции и продажи вашего сайта
Профессиональное SEO-продвижение с гарантией результата. Выберите подходящую услугу:
Остались вопросы по продвижению?
Меня зовут Анатолий Кузнецов, я SEO-оптимизатор с 20-летним стажем. Разберу ваш сайт, отвечу на вопросы и подскажу, что улучшить для роста позиций в Яндексе и Google.
Связаться со мной →Разобрать ситуацию на вашем сайте помогу на SEO-консультации.
Старт 
Стандарт 
Премиум 
Комментарии
Сергей Малышев
Наконец-то без рекламы конкретного движка. Пришёл сюда с мыслью «переезжаем на Битрикс, потому что все так делают», ухожу с мыслью посмотреть, что мне мешает на текущем сайте.
Марина Дьяченко
У нас магазин на OpenCart, в индекс попало огромное количество адресов с параметрами сортировки. Модуль canonical поставили, но часть страниц всё равно висит. Это лечится или только переезд?
Анатолий Кузнецов автор
Лечится, переезд тут ни при чём. Сначала проверьте, что canonical действительно проставляется на страницах с параметрами, а не только на чистых категориях — часто модуль работает лишь на части шаблонов. Дальше закройте параметры сортировки в robots.txt и уберите ссылки на них из HTML, чтобы робот перестал их находить. Выпадение из индекса занимает недели, поэтому не ждите результата на следующий день.
Игорь Пантелеев
Пункт про честные даты в карте сайта попал в цель. У нас плагин ставил текущую дату всем страницам сразу, полгода никто не замечал.
Ольга Тарасенко
Сайт на Tilda, около сорока страниц, услуги в регионе. Пока трафик растёт. В какой момент понимать, что упёрлись в потолок?
Анатолий Кузнецов автор
Ориентир простой: когда очередная задача из плана работ становится невыполнимой, а не просто неудобной. Например, нужны страницы под сочетания «услуга плюс район» с общей структурой и перелинковкой, или требуется вынести тяжёлые скрипты, чтобы вытянуть скорость. Пока задачи решаются в интерфейсе платформы, менять ничего не нужно. Как только две-три задачи подряд упираются в ограничения — считайте стоимость переноса.
Денис Ковригин
Добавлю про самописные системы. У нас была именно такая: разработчик пропал, исходники частично утеряны, добавить поле description было невозможно. Три года мучились, потом всё равно переехали.
Анна Ремизова
Покупаем готовый сайт на Битриксе. Продавец говорит, что лицензия есть, но подтверждать отказывается. Насколько это критично?
Анатолий Кузнецов автор
Критично, потому что без действующей лицензии вы не получите обновлений и техподдержки, а старые версии со временем становятся дырявыми. Проверить просто: попросите зайти в админку и показать раздел с информацией о лицензии и датой окончания обновлений. Если продавец не показывает экран даже при демонстрации, считайте, что лицензии нет, и закладывайте её стоимость в цену сделки. Заодно уточните, на кого оформлены домен и хостинг.
Владимир Стеценко
Хорошо, что разделили «движок плохой» и «работы на нём дорогие». У нас Битрикс, всё технически можно, но каждая мелочь превращается в оплаченные часы подрядчика.
Екатерина Лаврова
Планируем переезд с самописной на WordPress, около полутора тысяч страниц. Адреса придётся менять, старая структура нелогичная. Что делать в первую очередь?
Анатолий Кузнецов автор
Сначала соберите полный список текущих адресов из карты сайта, панелей вебмастеров и логов сервера, включая те, что уже не отдаются с сайта, но живут в индексе. Затем сделайте таблицу соответствия старый адрес — новый адрес, вручную для важных разделов и по маске для остального. Переезжайте со старой структурой, а перестройку разделов делайте отдельным этапом через месяц, когда убедитесь, что редиректы отработали. Совмещать смену движка и смену структуры — верный способ не понять, что именно просело.
Роман Гладков
Про пагинацию в title согласен. Обнаружил у себя пятьдесят страниц каталога с одинаковым заголовком, поправил шаблон за час.
Наталья Бекетова
Подрядчик убеждает поставить конструктор страниц в WordPress, говорит, будет удобнее наполнять. Не убьёт ли это скорость?
Анатолий Кузнецов автор
Риск реальный: такие конструкторы тянут собственные стили и скрипты на каждую страницу и оборачивают текст в лишние слои разметки. Если решаете ставить, договоритесь заранее, что типовые страницы собираются на шаблонах, а конструктор используется только там, где действительно нужен нестандартный блок. Обязательно замерьте скорость и вес страницы до и после на одном и том же материале. И проверьте, что весь текст виден на мобильных — часть блоков такие конструкторы любят прятать.
Павел Устинов
Список для проверки перед покупкой сайта забрал целиком. Особенно про экспорт: раньше смотрел только на трафик и возраст домена.
Юлия Северина
MODX недооценён, у нас на нём сайт услуг с двумя десятками региональных разделов. HTML чистый, скорость отличная. Минус один — искать специалиста дольше, чем по WordPress.