Торговый сайт на Битриксе имеет двойственную репутацию. С одной стороны, платформа годами держит заметную долю российского рынка онлайн-торговли и закрывает базовые потребности продвижения силами штатных модулей. С другой, почти каждый второй проект приносит SEO-специалисту одинаковый набор находок: пустые мета-теги на двадцати тысячах карточек, индексированные страницы сортировок и следы служебных параметров в адресах. Причина почти всегда одна, возможности платформы есть, но при сборке магазина их включают по остаточному принципу.
Работа строится в два слоя. Первый слой, настройка штатных механизмов: SEO-поля инфоблоков, ЧПУ каталога, генератор карты сайта, композитный кэш. Второй слой, доработки, без которых крупному магазину становится тесно: автоматические канонические адреса, товарные фиды, посадочные страницы под частотные комбинации фильтров. Ниже оба слоя по порядку, с конкретикой и типовыми граблями.
Штатные возможности SEO модуля Битрикса от которых отталкивается вся работа
Базовый набор у платформы солидный. Генератор sitemap.xml собирает карту из статических страниц, разделов и элементов инфоблоков, с настройкой частоты и приоритета для каждого типа. robots.txt редактируется прямо в панели или файловым менеджером в корне сайта, для каждого домена отдельно. Микроразметка Schema.org для хлебных крошек включается в настройках главного модуля, а счётчики аналитики вставляются один раз на весь сайт.
Мета-теги управляются на трёх уровнях. Свойства конкретной страницы правятся в публичной части через параметры страницы, свойства раздела задаются в настройках папки, и для всего остального работают шаблоны SEO-полей инфоблоков. Ключевой момент, который упускают почти все: настройки на уровне страниц работают точечно, а для тысяч однотипных карточек нужен именно третий уровень, шаблонный.
Чего в штатном наборе нет. Платформа не подставляет канонические адреса для страниц с параметрами, не показывает, какие адреса уже закрыты от индексации, и не имеет встроенного трекинга позиций. Всё это либо настраивается руками на этапе запуска, либо закрывается доработками, и грань между "настроить" и "дописать" проходит ровно по объёму каталога.
Шаблоны SEO полей инфоблоков и подстановка переменных в заголовки страниц
Вкладка SEO в настройках инфоблока заслуженно считается главным экономическим аргументом Битрикса. Шаблоны заголовка, описания и ключевых фраз задаются для элементов и для разделов, с наследованием и переопределением на любом уровне. Подстановка переменных выглядит так: {=this.Name} выводит название карточки, {=this.Code} её символьный код, {=parent.Name} название родительского раздела, {=this.property_BRAND} значение свойства, {=iblock.Name} имя самого инфоблока.
Практический пример. Для инфоблока "Обувь" шаблон заголовка вида "Купить {=this.Name} {=this.property_BRAND} в Москве" разворачивается в готовые title для всех карточек сразу. Шаблоны применяются и к уже существующим записям, поэтому магазин с десятью тысячами пустых мета-тегов лечится за вечер без программиста и без массовых правок в базе.
Дисциплина здесь важнее самих шаблонов. Свойства с кодами вроде BRAND или MODEL должны быть заполнены на всех карточках, иначе переменная останется пустой и заголовок потеряет смысл. Перед развёртыванием шаблонов выгружают сводку заполненности свойств и сначала закрывают дыры в контенте, потом настраивают подстановку. Обратный порядок даёт типичную картину: магазин с идеальными шаблонами и тысячами заголовков вида "Купить в Москве".
Длина заголовков ограничивается здравым смыслом. В выдаче отображается примерно 60-70 символов title, длинные хвосты просто обрезаются. Название товара ставят переменной в начало, суффикс магазина переносят в конец, а проверку делают на самой длинной и самой короткой карточке: крайние значения вскрывают дыры шаблона быстрее любой выборочной сверки.
ЧПУ каталога и канонические адреса при параметрах сортировки
Адресная часть собирается движком перезаписи. Комплексный компонент каталога работает в режиме ЧПУ с масками вида /catalog/#SECTION_CODE#/#ELEMENT_CODE#/, при этом физический путь в файловой системе остаётся прежним. Схема гибкая, но она же и главный источник дублей: один товар нередко доступен и как /catalog/obuv/krossovki/, и как /catalog/obuv/krossovki-x/, если на карточку ведут ссылки из разных мест.
Соответствия адресов хранятся в файле urlrewrite.php в корне сайта, типовая запись выглядит так:
array(
"CONDITION" => "#^/catalog/(.*)#",
"RULE" => "SECTION_CODE=$1",
"PATH" => "/catalog/index.php",
"SORT" => 100,
),Записи срабатывают по порядку сортировки, поэтому специфичные правила ставят выше общих. Важная граница: перезапись не делает HTTP-редирект, она лишь подсказывает ядру, какой скрипт обработать адрес. Настоящие 301-е ответы для переезжающих страниц настраивают на уровне веб-сервера, nginx для этого подходит лучше всего.
Сортировки множат адреса быстрее всего. Каждая пара параметров sort и order создаёт новую страницу с тем же контентом, и комбинации множатся в геометрической прогрессии. Правильная схема одна: такие адреса закрывают в robots.txt, а на самой странице выводят канонический адрес на базовую категорию. Канонический адрес в Битриксе задаётся свойством страницы canonical и попадает в HEAD автоматически.
Пагинация требует кропотливости. Страницы с PAGEN_1=2 или /page-2/ в режиме ЧПУ остаются в индексе, поэтому для них оставляют собственный канонический адрес, а в карту сайта включают только первые страницы разделов. Символические ссылки на элементы из нескольких разделов закрывают либо каноническим адресом на основной раздел, либо правилом перезаписи, которое отдаёт единственный правильный вариант адреса.
SEO настройки страниц умного фильтра и их рабочие границы
Умный фильтр каталога умеет строить человекопонятные адреса вида /filter/brend-is-nike/tsvet-is-siniy/apply/ и с версии каталога 17.5 обзавёлся собственной вкладкой SEO. На ней задаются заголовок, мета-теги и канонический адрес для страниц фильтрации, отдельно от базовых разделов.
Границы понятны из практики. Страницы фильтров приносят трафик только там, где комбинации свойств реально ищут люди: "кроссовки nike синие" это частотный запрос, а "кроссовки nike синие 42 с беговками" никто не вводит. Холодные комбинации отдают канонический адрес на раздел, тёплые оставляют в индексе с собственными мета-тегами. Без этого отбора магазин за пару месяцев получает в индексе десятки тысяч страниц фильтра с одинаковым контентом, и робот просто перестаёт заходить глубже второй страницы обхода.
Если ЧПУ у фильтра выключен, адреса выглядят как строки с параметрами вида arrFilter и для посадочных страниц непригодны: такой путь не читается ни людьми, ни поисковыми системами как осмысленный. Включение человекопонятных адресов фильтра это первый шаг, без которого вся вкладка SEO просто не работает.
Ещё одна ловушка - связанность страниц. Страницы фильтра не должны висеть в воздухе: на них ведут ссылки из текстов и подборок разделов, иначе робот находит их только через сам фильтр и относится к ним как к служебным. Хорошая проверка - поиск по логам обхода: если робот пришёл на страницу фильтра, но не пришёл на карточку, ссылки внутри фильтра не работают на индексацию каталога.
Композитный кэш и серверная скорость как основа технического SEO
Скорость у Битрикса решается штатными средствами. Композитный сайт собирает готовый HTML в каталог /bitrix/html_pages/ и отдаёт анонимному посетителю за десятки миллисекунд, минуя полную инициализацию ядра. Динамические области вроде корзины в шапке вырезаются атомарными блоками и подгружаются отдельно, режим называется авто-композитом и включается в настройках продукта.
Дальше идёт стандартный набор любого профессионального хостинга. PHP ветки 8.1 и выше с включённым OPcache, Redis или Memcached для кэша и сессий, перенос периодических агентов на cron вместо срабатывания на хитах посетителей. В настройках главного модуля отдельно включаются отложенная загрузка изображений и конвертация картинок в WebP, а модуль интеграции с CDN раздаёт статику с ближайших серверов.
Остаётся самое человеческое, картинки из товарных выгрузок. Клиенты загружают фото шириной 4000 пикселей, и никакой WebP не спасает, если карточка тащит мегабайты. Правильное место сжатия - обработчик при загрузке, а не надежда на настройки кэша.
Результат проверяют дважды. Встроенная страница производительности в панели показывает время генерации страниц и счётчики запросов к базе, она находит медленные компоненты ещё до жалоб роботов. Полевые отчёты Core Web Vitals показывают, как магазин ведёт себя у реальных посетителей, и именно эти цифры поисковые системы видят в ранжировании. С гигиеническим минимумом магазин проходит порог LCP в 2.5 секунды даже на недорогом виртуальном хостинге.
robots.txt sitemap.xml и служебные параметры которые нельзя отдавать роботам
Файл robots.txt для магазина на Битриксе заслуживает отдельного разговора, потому что именно через параметры платформа генерирует больше всего мусорных адресов. Типовая рабочая конфигурация выглядит так:
User-agent: *
Disallow: /bitrix/
Disallow: /auth/
Disallow: /personal/
Disallow: /cart/
Disallow: /search/
Disallow: /*?sort=
Disallow: /*&order=
Disallow: /*?print=
Disallow: /*?bitrix_include_areas=
Disallow: /*?clear_cache=
Sitemap: https://example.com/sitemap.xmlПроверка строится по логам обхода. Роботы приходят на адреса с clear_cache, отладочными ключами и идентификаторами сессий, и каждый такой ответ тратит краулинговый бюджет. Идентификаторы сессии убираются из ссылок включением хранения сессии в cookies, отладочные параметры отключаются на боевом контуре. Минимальный регламент контроля служебных адресов выглядит так:
- Логи обхода за двухнедельную выборку не содержат адресов с сортировками и отладочными ключами;
- Страницы сортировок и фильтров отдают канонический адрес на базовую категорию;
- Копии для печати и служебные параметры закрыты в robots.txt по всем доменам магазина;
- Карта сайта собрана только из чистых адресов и пересобирается по расписанию;
- Каждая карточка имеет уникальные заголовок и описание из шаблонов инфоблока;
- Товарная микроразметка главной страницы и разделов проходит валидацию без ошибок.
Доработки разработчика без которых крупному магазину тесно
Когда штатный слой вычищен, список доработок становится коротким и конкретным. Автоматический канонический адрес для страниц с параметрами, чтобы не закрывать каждую комбинацию руками. Массовые перенаправления через карту правил на уровне веб-сервера, потому что переезды разделов в каталоге случаются каждый сезон. Товарный фид в формате торговых площадок с пересборкой по расписанию, если штатной выгрузки не хватает по составу полей.
Про контент забывать нельзя. Разделы с абзацем осмысленного описания над списком карточек отрабатывают заметно лучше пустых категорий, текст задаётся в описании раздела инфоблока или включаемой областью. Робот получает сигнал, что страницу курирует человек, а не генератор, и обходит такие категории охотнее.
Отдельный пласт работы - посадочные страницы под частотные комбинации свойств. Их собирают не через фильтр, а отдельным инфоблоком с собственным контентом, уникальными текстами и ручными мета-тегами, чтобы не зависеть от ограничений фильтра и не получать страницы без текста в индексе. Сюда же относятся отзывы с рейтингом и разметкой, живой поиск с подсказками и мониторинг битых ссылок через логи 404.
Экономика вопроса простая. Час работы разработчика над шаблоном канонических адресов закрывает целый класс проблем, который иначе съедает недели ручной чистки. На каталоге в пятьдесят тысяч карточек доработки окупаются за первые месяцы, а магазину из трёхсот товаров хватает аккуратно настроенных штатных возможностей, и заказывать код там чаще всего не нужно.