Технический SEO-аудит интернет-магазина на 1С-Битрикс

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

Технический SEO-аудит помогает проверить, какие страницы доступны роботам, что они видят и где сайт создаёт лишние адреса. Ниже практический порядок проверки магазина на 1С-Битрикс: Управление сайтом. Это материал о CMS для сайта, а не об облачной CRM Битрикс24.

Начните с выборки страниц и цели проверки

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

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

Понадобятся доступы к Яндекс Вебмастеру, Google Search Console и аналитике. Для диагностики полезны логи сервера и административная панель Битрикса. Перед изменением шаблонов, маршрутизации и кэша подготовьте резервную копию и тестовую среду.

Как расставить приоритеты аудита

Приоритет	Пример	Что делать
Критичный	Каталог отдаёт 5xx или закрыт от индексации	Восстановить доступность и проверить затронутые шаблоны
Высокий	У важных категорий неверный canonical, фильтр создаёт множество дублей	Согласовать схему URL и исправить правила для всего типа страниц
Плановый	Неудачные описания, тяжёлые изображения, неполная разметка	Оценить охват, исправлять группами и проверять результат

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

Доступность и индексация: первые четыре проверки

1. HTTP-ответ соответствует содержимому

Рабочая категория или товар должны возвращать 200. Постоянный переезд адреса оформляют постоянным перенаправлением, обычно 301. Несуществующая страница должна отдавать 404, а не 200 с надписью «Ничего не найдено».

Проверьте не только браузерную картинку, но и HTTP-статус. Случайный адрес вроде /catalog/ne-sushchestvuet/ не должен открывать главную или пустую категорию с успешным ответом. Для важных URL запишите конечный адрес и всю цепочку перенаправлений. Это удобнее проверять сканером или вкладкой Network в инструментах разработчика.

2. Robots.txt и noindex не противоречат задаче

robots.txt управляет обходом, а noindex в метатеге или HTTP-заголовке управляет индексированием. Запрет обхода сам по себе не равен удалению адреса из поиска. Если робот не может загрузить страницу из-за запрета, он не прочитает размещённый на ней noindex. Это различие описано в документации Google.

На рабочих категориях проверьте HTML и заголовок X-Robots-Tag. Частая зона риска после переноса: тестовое ограничение осталось в шаблоне или на сервере. Не копируйте универсальный robots.txt целиком: список запретов должен учитывать именно ваши URL, фильтры и ресурсы, необходимые для отображения страницы.

3. Canonical указывает на нужную версию страницы

Проверьте, что rel="canonical" содержит абсолютный адрес нужной страницы: с правильным доменом, протоколом и формой URL. Каноническая страница должна быть доступна. Для варианта с UTM-метками обычно подходит адрес того же документа без рекламных параметров.

Пример: /catalog/kresla/?utm_source=newsletter может указывать на /catalog/kresla/. А вот отдельную полезную категорию «Офисные кресла» нельзя автоматически склеивать с общим каталогом, если вы хотите продвигать её самостоятельно. Canonical является сигналом предпочтения, а не безусловной командой поисковику. Ссылки, редиректы и sitemap должны поддерживать выбранный адрес, а не противоречить ему.

4. У сайта одна основная версия адресов

Сравните HTTP и HTTPS, домен с www и без него, варианты со слешем и технические адреса index.php, если они доступны. Уберите ненужные цепочки: желательно, чтобы устаревшая версия сразу переводила на конечную.

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

Каталог: где Битрикс чаще всего создаёт лишние URL

5. Для умного фильтра есть понятные правила

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

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

Google отдельно описывает управление обходом фасетной навигации: множество URL расходует ресурсы обхода. Одна каноническая ссылка не всегда решает проблему такого пространства адресов. Не закрывайте весь путь /filter/, пока не проверите, нет ли в нём нужных посадочных.

6. Пагинация доступна по обычным ссылкам

Товары со второй и следующих страниц должны оставаться доступными роботу. У «Показать ещё» и бесконечной прокрутки проверьте наличие отдельных URL и обычных ссылок <a href="...">. Если ассортимент виден только после клика по JavaScript-кнопке, проверьте, каким другим путём поисковик находит товары.

У страниц пагинации с разным набором товаров не следует автоматически ставить canonical на первую страницу. Проверьте собственный адрес каждой страницы и отсутствие бесконечного перебора: заведомо несуществующий номер не должен генерировать ещё один успешный пустой документ.

7. Для товаров без остатка выбрана осмысленная стратегия

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

При окончательном удалении товара решение зависит от содержания и замены. Постоянный редирект уместен на действительно близкую замену, а не автоматически на главную. Если подходящего документа нет, корректный 404 или 410 лучше фиктивной карточки. Ссылки и sitemap после удаления тоже требуют обновления.

Метаданные и структура: ещё четыре проверки

8. Title, description и H1 описывают конкретную страницу

В Битриксе можно задавать SEO-шаблоны инфоблоков, разделов и элементов. Но наличие настроек в админке ещё не доказывает, что шаблон сайта выводит их правильно. Сопоставьте значение в административной панели с исходным HTML и итоговым состоянием страницы после загрузки.

Для категории «Офисные кресла» заголовок должен отличаться от общего каталога и других разделов. Не перечисляйте в каждом title все города и категории. Description должен объяснять, что посетитель найдёт на этой странице; поисковик при этом может выбрать другой текст сниппета.

Проверьте приоритет индивидуальных настроек и наследуемых SEO-шаблонов. В официальной справке по настройке инфоблока описаны поля и шаблоны. Если название товара меняется при обмене с 1С, дополнительно проверьте, как это отражается на метатегах и URL. О самом обмене есть отдельный разбор интеграции 1С и Битрикса.

9. Изображения понятны и не ломают загрузку

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

Проверьте размер изображения под реальный экран, сжатие и заданные ширину с высотой. Главное изображение первого экрана не следует бездумно откладывать через lazy loading; отложенная загрузка полезнее для контента ниже. Для товарной галереи проверьте и миниатюры, и большие фотографии.

10. В sitemap нет технических дублей

Включайте в карту рабочие канонические URL, которые планируете показывать в поиске. Уберите перенаправления, несуществующие адреса и страницы, исключённые из индексации. После обновления каталога проверьте, обновляется ли сама карта, а не только её ссылка в robots.txt.

В lastmod передавайте реальную дату существенного изменения страницы, когда она известна. Не ставьте текущую дату на весь каталог при каждой генерации. Яндекс рекомендует определить канонические URL и сообщить о карте через robots.txt или Вебмастер. Карта помогает обнаружению, но не гарантирует включение каждого адреса в поиск.

11. Микроразметка соответствует видимым данным

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

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

Скорость и кэш: проверки 12 и 13

12. Измеряйте опыт посетителя, а не только балл теста

Посмотрите мобильные данные по категориям и карточкам, а не единственный запуск главной. Для Core Web Vitals ориентиры хорошего опыта: LCP до 2,5 секунды, INP до 200 мс, CLS до 0,1. Их оценивают на 75-м процентиле посещений отдельно для мобильных и настольных устройств, как описано в документации Web Vitals.

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

13. Кэш ускоряет каталог и не смешивает данные клиентов

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

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

Мобильная версия и JavaScript: последние две проверки

14. Пройдите реальный путь покупки с телефона

Откройте категорию, примените фильтр, перейдите в товар, выберите вариант и добавьте его в корзину. Проверьте, видны ли цена, наличие, доставка и кнопка действия. Посмотрите, не перекрывает ли cookie-баннер управление и можно ли закрыть модальное окно.

Повторите сценарий на узком экране и с открытой экранной клавиатурой. Зафиксируйте горизонтальный скролл, скачки интерфейса и действия, которые срабатывают только при наведении мыши. Это конкретные задачи для разработчика, а не абстрактное замечание «улучшить адаптив».

15. После загрузки JavaScript остаётся правильный документ

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

Например, у статьи может быть правильный title в исходном HTML, но общий скрипт локализации позже меняет его на заголовок главной. Другой вариант: фильтр меняет адрес, а H1 и canonical остаются от предыдущей категории. Такой дефект не виден в проверке только серверного HTML. Для важных URL полезно сравнивать также результат проверки страницы поисковым роботом.

Что должно остаться после аудита

Хороший результат аудита можно передать в разработку без пересказа на созвоне. Для каждой проблемы нужны URL или правило выбора страниц, пример текущего ответа, ожидаемое поведение, приоритет и способ проверки после исправления. Оценку трудозатрат согласовывайте после уточнения причины.

Пример задачи: на карточках каталога canonical ведёт в общий раздел. Нужно выводить канонический URL самой карточки. Приёмка: проверить товар с обычным адресом, с UTM-меткой, после обмена с 1С и после прогрева кэша; конечный URL доступен, значение одинаково в исходном HTML и после загрузки скриптов, внутренние ссылки и sitemap используют нужный адрес.

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

Как проверить результат после внедрения

1. Повторите ту же выборку URL и сканирование. Сохраните отчёт до и после, включая статусы, robots, canonical и метатеги.
2. Проверьте, что изменения не сломали фильтр, обмен с 1С, корзину и отправку заказа.
3. Обновите sitemap, при необходимости отправьте важные страницы на переобход доступными инструментами поисковых систем.
4. Наблюдайте за повторным обходом и состоянием конкретных страниц. Техническую приёмку не откладывайте до изменения позиций.
5. Оценивайте показы, переходы и заявки по целевым посадочным с учётом сезонности, ассортимента и рекламных кампаний.

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

Нужен такой аудит? В RANT занимаемся техническим SEO и разработкой на 1С-Битрикс: можем найти проблемы, согласовать план и выполнить доработки. Пришлите адрес магазина и опишите задачу. Начнём с доступов и объёма проверки, затем определим состав работ.

Источники и дальнейшее чтение

Материал проверен 18 октября 2026 года. Технические рекомендации опираются на официальную документацию; порядок аудита и примеры задач предложены RANT.

• Google: управление индексированием через noindex
• Google: канонические адреса и дубли
• Google: обход фасетной навигации
• Яндекс Вебмастер: использование Sitemap
• 1С-Битрикс: создание и настройка инфоблока
• Web Vitals: метрики и пороговые значения