SEO на Bitrix: настройка, частые ошибки и что не делает коробка

Почему Bitrix-сайту нужна ручная донастройка SEO

Bitrix продаётся как готовая платформа: ставишь редакцию «Бизнес», подключаешь интернет-магазин — и сайт работает. Работает он действительно из коробки, но для пользователя, а не для поисковика. SEO-механизмы в Bitrix есть почти все, только лежат выключенными или настроенными по минимуму. За десятки аудитов Bitrix-магазинов я вижу один и тот же набор: ЧПУ не включены, canonical нет, robots пустой, композит выключен. Сайт с бюджетом в миллионы при этом сидит на технических дублях и теряет позиции там, где Tilda-одностраничник давно бы вышел в топ.

Причина простая: коробку настраивает программист под задачу «чтобы работало», а SEO — отдельная зона ответственности, которую при сдаче проекта часто пропускают. Разработчик закрывает багтрекер, проверяет, что корзина оформляет заказ, и сдаёт работу. Проверять, как сайт выглядит для робота Яндекса, в чек-листе приёмки обычно нет. В выдаче по запросу «seo bitrix» лежит в основном официальная документация 1С-Битрикс — справка по компонентам и модулям, без связного практического сценария. Системного гайда «что включить и в каком порядке» нет. Этот пробел и закрываю.

Хорошая новость: всё чинится в админке и шаблоне, без переписывания ядра. Плохая — большинство настроек разбросано по разным разделам, и логика неочевидна: ЧПУ лежат в инфоблоках, robots и sitemap — в модуле «Поисковая оптимизация», композит — в общих настройках, canonical вообще нигде, его надо завести самому. Чтобы найти все рычаги, нужно знать карту админки заранее. Ниже разбираю по блокам: ЧПУ и дубли, что закрывать от индекса, скорость, типовые ошибки, плюс порядок работ и контроль результата. Базовая внутренняя оптимизация на Bitrix та же, что на любой CMS, — отличаются только места, где находятся рычаги.

Важная деталь про версии. Редакции «Старт» и «Стандарт» урезаны: в них нет SEO-настроек умного фильтра и части модулей поисковой оптимизации. Если магазину нужны SEO-страницы фильтров с уникальными Title — это редакция «Малый бизнес» и выше. Перед началом работ проверь редакцию в «Настройки» → «О продукте»: бывает, что половину задач не получается решить просто потому, что лицензия не та. Это первое, что стоит выяснить, прежде чем планировать донастройку.

Карта SEO-настроек: где что лежит в админке

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

Отдельно стоит знать про панель производительности Bitrix («Настройки» → «Производительность» → «Панель производительности»). Она прогоняет сайт по внутренним тестам и выставляет оценку конфигурации сервера, кэша и кода. Это первый диагностический инструмент: если панель показывает красное по конфигурации PHP или базы, никакой композит до конца не разгонит сайт. С неё и начинают, потому что она сразу показывает узкое место.

Чего на этой карте нет — canonical. Тег rel=canonical не лежит ни в одном из четырёх разделов, потому что коробка его не генерирует. Его место — шаблон компонента или общий шаблон сайта, то есть код. Это ключевая мысль, к которой возвращаюсь ниже: всё, что есть в админке, настраивается галочками, а canonical приходится заводить руками в шаблоне.

ЧПУ и дубли: главная боль Bitrix

Из коробки Bitrix отдаёт ссылки с параметрами: /catalog/index.php?IBLOCK_ID=5&SECTION_ID=42. Это рабочий, но мёртвый для SEO URL — поисковик не понимает структуру, а одна и та же страница доступна по десятку адресов с разным порядком параметров. ЧПУ (человекопонятные URL) в Bitrix включаются не одним тумблером, а в три приёма.

Третий шаг проваливают чаще всего. Включить транслит в свойствах инфоблока недостаточно: автогенерация работает только для НОВЫХ элементов, а у тысяч уже созданных товаров символьный код пустой. По пустому коду ЧПУ-ссылка не собирается — карточка отдаёт 404 или редиректит на адрес с параметром. Лечится массовой генерацией кодов: в Bitrix это делается скриптом перебора элементов инфоблока с вызовом CIBlockElement::Update и установкой CODE из транслита названия, либо штатной кнопкой пересохранения раздела. После генерации обязательно проверь уникальность кодов — два товара «Чехол» в одном разделе дадут конфликт и второй уедет в 404.

Пропустишь любой шаг — получишь либо параметры в адресах, либо 404 на части карточек. Второй типовой источник дублей на Bitrix — регистр URL. Сервер на Linux считает /Catalog/ и /catalog/ разными страницами, и обе попадают в индекс. Правило приведения к нижнему регистру и единому слешу собери в генераторе 301-редиректов. То же с завершающим слешем: /catalog/obuv и /catalog/obuv/ — для робота два разных адреса. Лечится приведением URL к нижнему регистру и единому формату слеша правилами редиректа в .htaccess и единым форматом ссылок в шаблоне, чтобы внутренняя перелинковка не плодила варианты сама.

Как проверить, что ЧПУ отработали везде: открой «Вебмастер Яндекса» → «Индексирование» → «Страницы в поиске» и отсортируй по URL. Если в списке мелькают адреса с ?IBLOCK_ID, index.php или заглавными буквами — где-то остался незакрытый инфоблок или нет редиректа. В Search Console то же смотрят в отчёте «Индексирование страниц» → «Просканированные, но не проиндексированные». Если хочешь разобрать дубли глубже — отдельный гайд про canonical и дубли страниц объясняет механику на примерах любой CMS.

Что закрывать от индекса: фильтры, сортировки, параметры

Умный фильтр в каталоге Bitrix — главный генератор мусора в индексе. Каждая комбинация чекбоксов (цвет, бренд, размер) отдаёт URL вида /catalog/filter/brand-bosch/color-white/ или с GET-параметрами. Комбинаций — тысячи, и Bitrix по умолчанию отдаёт их все с кодом 200, без запрета на индексацию. Поисковик радостно загребает десятки тысяч почти одинаковых страниц фильтра и сжигает на них краулинговый бюджет, до нужных карточек не доходя. Математика жёсткая: каталог с пятью свойствами по четыре значения даёт более тысячи комбинаций даже без учёта порядка, а реальные магазины с десятком свойств — сотни тысяч теоретических URL.

Правильная схема — разделить страницы фильтра на две группы: полезные SEO-страницы и технический мусор.

Какие фильтры открывать решает не вкус, а спрос. Прогоняешь свойства каталога через Wordstat: если «купить холодильник bosch» собирает тысячи показов в месяц — это посадочная страница, делаешь ей ЧПУ-адрес, уникальный Title и H1, отдельный SEO-текст. Если «холодильник bosch белый двухкамерный no frost 200 см» спрашивают три человека в год — комбинацию закрываешь, она ничего не приведёт, а бюджет обхода съест. Практическое правило: открываешь одно-двусоставные фильтры по частотным брендам и категориям, всё трёх- и более составное закрываешь по умолчанию.

Bitrix умеет генерировать robots.txt сам: в модуле «Поисковая оптимизация» («Маркетинг» → «Поисковая оптимизация» → «Настройка robots.txt») есть генератор с готовыми запретами для служебных разделов /bitrix/, /personal/, /auth/. Собрать и проверить итоговый файл под свой каталог удобно и в генераторе robots.txt. Базовый набор он закрывает, но фильтры и сортировки твоего каталога нужно дописать руками — генератор их не знает. Для Яндекса добавляешь директиву Clean-param, чтобы склеить адреса с UTM и сортировками: Clean-param: sort&utm_source&utm_medium /catalog/. Google Clean-param не понимает — для него те же параметры закрываешь через canonical и при необходимости Disallow.

Поверх robots ставишь rel=canonical. Из коробки Bitrix его не проставляет — это и есть то, что коробка не делает. Тег прописываешь в шаблоне компонента каталога или включаешь в SEO-настройках инфоблока, чтобы страница фильтра и сортировки ссылалась на чистый URL раздела. Важный нюанс про пагинацию: на вторую и далее страницы списка canonical должен указывать на саму страницу пагинации, а не схлопывать всё на первую — иначе товары со второй страницы теряют шанс попасть в индекс. Подробно логику canonical разбираю в отдельной статье про дубли — на Bitrix она работает так же, просто тег надо завести руками.

И не забудь про sitemap.xml: Bitrix генерирует карту сайта в том же модуле «Поисковая оптимизация», но по расписанию на агентах. Проверить, что в карте нет мусорных URL, поможет анализ sitemap, а собрать её заново — генератор sitemap. Если агенты в коробке настроены лениво или висят на хитах (а не на cron), карта обновляется раз в сутки или реже — для живого магазина с ежедневным добавлением товаров это мало. Переведи агенты на cron и проверь, что в sitemap не попадают закрытые в robots страницы фильтров: противоречие «в карте есть, в robots закрыто» — частая ошибка, которая путает робота. Настройку robots и sitemap разбирал в гайде про robots.txt и sitemap.xml.

Метатеги и заголовки по шаблонам

Магазин на 4 000 товаров не получится размечать вручную: руками не пропишешь Title и Description к каждой карточке и разделу, а без них Bitrix подставит название элемента и обрежет — получишь тысячи одинаковых и неинформативных заголовков. Решение — шаблоны метатегов, и они в Bitrix есть, но снова не из коробки: их надо настроить.

Шаблоны живут в двух местах. Первое — модуль «Поисковая оптимизация» → «Управление метаданными»: задаёшь правила для типов страниц по маске URL. Второе и основное для каталога — вкладка «SEO» инфоблока, поля для шаблонов разделов и элементов. Там доступны подстановки: #NAME# (название), #ELEMENT_NAME#, #SECTION_NAME#, свойства элемента вида #PROPERTY_BRAND#, цена. Это даёт осмысленные заголовки на весь каталог одной настройкой.

Главный приоритет — уникальность H1. По умолчанию Bitrix часто делает H1 равным Title или просто названию раздела, и заголовок дублирует тайтл слово в слово. Поисковику нужен сигнал, что H1 и Title разные: Title затачиваешь под клик в выдаче (с ценой, городом, брендом магазина), H1 — под чистый ключ без коммерческих хвостов. На карточке выводи H1 из отдельного SEO-поля элемента, а не из #NAME#, чтобы можно было поправить точечно у важных товаров.

Проверяешь результат массово: выгружаешь список URL и тянешь Title с Description парсером (Screaming Frog, Netpeak Spider или встроенный «Проверка индексации» в Топвизоре). А как один Title и Description будут смотреться в выдаче — прикинь в превью сниппета. Сортируешь по дублям — если в выгрузке два одинаковых Title, шаблон где-то не подхватился или у элемента не заполнено свойство-подстановка. Это разовая чистка, после которой весь каталог получает осмысленные и непохожие заголовки.

Скорость: композит и чистка модулей

Bitrix тяжёлый: ядро, инфоблоки, компоненты, обработчики событий — на каждый запрос поднимается много кода. Из коробки сайт на «Бизнесе» легко отдаёт первый байт за 800–1500 мс, и это бьёт по позициям, потому что скорость — фактор ранжирования в Яндексе и Google. В Google это закреплено метриками Core Web Vitals (LCP, INP, CLS), которые видны в Search Console и PageSpeed Insights; в Яндексе скорость влияет на поведенческие через отказы. Главный инструмент ускорения у Bitrix свой и мощный — технология «Композит» (композитный кэш), но в свежей установке она выключена.

Композит работает так: первый посетитель собирает страницу полностью, Bitrix сохраняет её статическую копию, и все следующие получают эту копию из кэша мгновенно. Динамику — корзину, авторизацию, блок «вы смотрели» — браузер дозагружает отдельным AJAX-запросом поверх статики. Для робота и большинства посетителей это значит отдачу готового HTML за 100–200 мс вместо полутора секунд сборки. Включается в «Настройки» → «Композитный сайт», отдельно отмечаешь, какие страницы кэшировать (каталог и карточки — да, личный кабинет — нет).

Вторая по эффекту вещь — чистка модулей. В типовой сборке Bitrix включён десяток модулей, которыми сайт не пользуется: внутренняя соцсеть, форум, блог, реклама, опросы. Каждый висит обработчиками на событиях и тормозит. Отключаешь неиспользуемые в «Marketplace» → «Установленные решения» (или через настройки модулей) — каждый снятый модуль убирает лишние запросы к базе на каждой загрузке. Перед отключением сделай резервную копию: некоторые модули завязаны на данные, и снос с потерей таблиц откатить сложно.

Третий слой, до которого доходят реже, — где Bitrix хранит кэш. По умолчанию это файлы на диске, и на каталоге с тысячами компонентов диск становится узким местом. Перевод кэша в Memcached или Redis (настраивается в .settings.php) разгружает диск и заметно ускоряет сборку при сбросе кэша. Это уже работа на стороне сервера, но эффект на нагруженном магазине ощутимый.

Частые ошибки на Bitrix

Девятая ошибка живёт в режиме разработки. Если в .settings.php остался включённым exception_handling с выводом отладки или включена правка через визуальный редактор у анонимов, в код страниц утекают служебные комментарии и лишние скрипты. Перед сдачей проверь, что сайт работает в боевом режиме, отладка выключена, а технический поддомен разработки закрыт от индексации паролем или noindex на уровне сервера — копии dev-стенда в индексе встречаются чаще, чем кажется.

Порядок работ: с чего начать и в какой последовательности

Технических задач на Bitrix много, и хаотичная правка («сначала robots, потом передумал, полез в композит») растягивает работу и оставляет дыры. Если некогда разбираться в коробке — настрою SEO на Битрикс под ключ: ЧПУ, дубли, canonical, скорость. Последовательность важна, потому что одни шаги опираются на другие: бессмысленно закрывать фильтры в robots, пока не включены ЧПУ — адреса фильтров ещё параметрические, и правила не сработают. Ниже порядок, который снимает основную массу проблем за один заход.

На что закладывать время. Аудит и проверка редакции — час. ЧПУ и генерация кодов на каталоге в тысячи позиций — день с учётом проверки 404. Дубли по регистру и слешу — пара часов на правила и тесты. Фильтр, robots, canonical, sitemap — самый ёмкий блок, день-два, потому что нужно собрать частотные фильтры через Wordstat и аккуратно прописать правила. Метатеги и скорость — день. Итого разовый заход — рабочая неделя на средний магазин, после чего сайт держит настройки сам, а дальше только контроль.

Главное правило приоритизации: сначала то, что чинит индексацию (ЧПУ, дубли, фильтр), потом то, что улучшает отдачу (метатеги, скорость). Битый индекс с дублями обнуляет любые улучшения сниппетов — нет смысла полировать Title на страницах, которые конкурируют сами с собой за счёт дублей. Сначала наводишь чистоту в индексе, затем повышаешь кликабельность и скорость.

Как проверить результат: Вебмастер, Метрика, парсеры

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

Первое, что делаешь после правки ЧПУ и редиректов, — прогон сайта парсером. Точечно проверить код ответа и цепочку редиректов по списку адресов можно в проверке ответа сервера. Screaming Frog в режиме обхода покажет всю карту: где остались параметрические URL, где цепочки 301 → 301 → 200 (их схлопываешь в один редирект), где canonical указывает сам на себя, а где отсутствует. Цепочки редиректов — частый побочный эффект правки .htaccess: правило на нижний регистр и правило на слеш могут срабатывать последовательно, и робот идёт через два прыжка вместо одного.

Сроки ожидания. Дубли выпадают из индекса не мгновенно: Яндексу нужно 3–6 недель на переобход и склейку, Google быстрее реагирует на canonical, но тоже не за день. Не паникуй, если через неделю количество страниц в поиске не упало — отправь ключевые URL на переобход в Вебмастере, добавь правки в IndexNow и жди следующего цикла обхода. Контроль держишь 4–6 недель: смотришь, как кривая «страниц в поиске» сходится к числу реальных товаров плюс полезных SEO-страниц, а TTFB в Метрике держится в зелёной зоне.

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

Главное