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

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

Эта статья — практический разбор того, как провести технический SEO-аудит интернет-магазина на 1С-Битрикс от начала до конца: с каких инструментов начинать (Яндекс Вебмастер, Google Search Console, краулеры), как аудитировать индексацию через robots.txt, meta robots и X-Robots-Tag, как проверять карту сайта, как находить и лечить дубли и настраивать канонические адреса, как разбираться с параметрами URL, слешами, www и протоколом, пагинацией и фильтром, как аудитировать ЧПУ и редиректы, ловить цепочки 301 и soft-404, как оценивать скорость и Core Web Vitals, валидность микроразметки, шаблоны метатегов, иерархию заголовков, изображения, мобильную версию, HTTPS, вложенность и crawl budget по логам бота, регионы и hreflang. И главное — как приоритизировать находки (критично / важно / мелочь) и превратить их в отчёт и план правок. Материал вырос из нашей практики SEO-аудита интернет-магазинов — по делу, без «воды» и обещаний «топа за неделю».

Зачем магазину технический SEO-аудит

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

Разложим пользу аудита на конкретные задачи, которые он решает для интернет-магазина:

• Открывает путь к индексации. Аудит находит страницы, ошибочно закрытые в robots.txt или noindex, и, наоборот, мусор, который зря попадает в индекс. Пока это не исправлено, остальное вторично.
• Убирает дубли. Магазин без управления параметрами и фильтром порождает тысячи дублей, которые размывают сигналы и съедают краулинговый бюджет. Аудит выявляет все каналы их появления.
• Чинит переадресации. Битые ссылки, цепочки редиректов, отдача 200 вместо 404 — всё это мешает роботу и пользователю. Аудит наводит порядок в кодах ответа и 301.
• Повышает скорость. Медленные страницы теряют и позиции, и конверсию. Аудит Core Web Vitals показывает, что именно тормозит типовые шаблоны магазина.
• Готовит базу для контента. Корректные метатеги, заголовки и микроразметка — фундамент, на котором работают семантика и тексты. Аудит проверяет, что фундамент в порядке.
• Делает работу измеримой. На выходе — список находок с приоритетом и планом правок, по которому видно прогресс: что исправлено, что переиндексировано, как изменились метрики.

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

Что такое технический SEO-аудит

Технический SEO-аудит интернет-магазина — это структурированная проверка технических факторов, влияющих на обход, индексацию и ранжирование сайта. В отличие от аудита контента (о чём страницы и насколько они отвечают спросу) и аудита ссылочного профиля (кто и как ссылается на сайт), технический аудит отвечает на вопрос «не мешает ли что-то техническое сайту показываться в поиске и хорошо ранжироваться». Это взгляд на сайт глазами поискового робота, а не пользователя.

Чтобы понять охват аудита, полезно разложить его на блоки — по сути, это и есть карта проверки:

• Индексация. Что робот может обойти и что попадает в индекс: robots.txt, meta robots, X-Robots-Tag, карта сайта, соотношение «в поиске / исключено».
• Дубли и канонические. Параметры URL, слеши, www и протокол, пагинация, комбинации фильтра, атрибут canonical — всё, что порождает или устраняет дубли.
• URL и редиректы. ЧПУ, коды ответа, 301, цепочки редиректов, 404 и soft-404, битые ссылки.
• Скорость и стабильность. Core Web Vitals (LCP, INP, CLS), лабораторные и полевые данные, нагрузка типовых шаблонов.
• Разметка и контентные сигналы. Микроразметка Schema.org, метатеги title и description, иерархия заголовков H1–H6, alt изображений.
• Доступность и окружение. Мобильная версия, HTTPS и безопасность, вложенность и crawl budget, регионы и hreflang.

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

Инструменты аудита

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

Разберём основные инструменты и их роль:

Порядок работы обычно такой: сначала снимают картину индексации в панелях вебмастеров (что в поиске, что исключено и почему), затем прогоняют сайт краулером и сопоставляют «что мы разрешили» с «что есть по факту», параллельно тестируют скорость типовых шаблонов и валидируют разметку, а для крупного магазина добавляют анализ логов. Важная оговорка: автоматические отчёты краулеров и сервисов — это сырьё, а не готовый аудит. Они дают сотни «предупреждений», из которых значимы единицы. Задача специалиста — отфильтровать шум, проверить находки руками, понять их причину в шаблонах 1С-Битрикс и оценить реальное влияние на трафик. Инструмент находит симптом, а диагноз и приоритет ставит человек.

Аудит индексации: robots.txt

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

robots.txt — это текстовый файл в корне сайта, который директивами Disallow и Allow указывает роботам, какие разделы обходить не нужно. Что проверяют в аудите:

• Не закрыто ли лишнее. Классическая катастрофа — Disallow: / или закрытый по ошибке раздел каталога, оставшийся с этапа разработки. Проверяют, что все коммерчески важные разделы открыты для обхода.
• Закрыт ли служебный мусор. Административная часть, корзина, оформление заказа, сравнение, результаты внутреннего поиска, технические скрипты — то, что не должно попадать в индекс, обычно закрывают от обхода.
• Обработаны ли параметры. Для Яндекса дубли с параметрами (сортировки, метки) удобно убирать директивой Clean-param, которая указывает роботу игнорировать перечисленные параметры.
• Указана ли карта сайта. В robots.txt должна быть строка Sitemap: с адресом актуального sitemap.xml.
• Не закрыты ли ресурсы отрисовки. CSS и JS, нужные для корректного рендеринга страницы, закрывать нельзя — иначе робот увидит «сломанную» страницу.

Ключевой нюанс, который часто понимают неверно: robots.txt запрещает обход, но не гарантирует исключение из индекса. Если на закрытую в robots страницу ведут внешние или внутренние ссылки, поисковая система может показать её в выдаче без сниппета — «страница закрыта в robots.txt». Поэтому robots.txt — инструмент управления обходом и краулинговым бюджетом, а не надёжный способ убрать страницу из поиска. Чтобы гарантированно исключить страницу, используют meta robots noindex (о нём дальше), причём страница при этом должна быть открыта для обхода, иначе робот не увидит директиву. Эта связка robots.txt и noindex — одно из самых частых мест ошибок в магазинах, и её мы подробно разбираем в отдельной статье про robots.txt и карту сайта на 1С-Битрикс.

Meta robots, noindex и X-Robots-Tag

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

Разберём три механизма и их назначение:

• meta name="robots". Тег в <head> страницы. Значение noindex убирает страницу из индекса, nofollow запрещает передавать вес по ссылкам с неё. Комбинациями index/noindex и follow/nofollow задают поведение точечно.
• X-Robots-Tag. Тот же смысл, но передаётся HTTP-заголовком ответа сервера. Незаменим для нетекстовых файлов (PDF, изображения) и для массового управления через настройки сервера.
• Связка с robots.txt. Чтобы noindex сработал, страница должна быть открыта для обхода в robots.txt — иначе робот просто не дойдёт до тега и не узнает о запрете.

Что именно аудитируют по этому блоку в магазине. Во-первых, что noindex стоит там, где надо: служебные страницы, личный кабинет, корзина и оформление, страницы результатов внутреннего поиска, технические и «пустые» страницы фильтра без спроса. Во-вторых, и это важнее, что noindex НЕ стоит там, где не надо: печальная, но частая находка — важные категории или весь каталог случайно получили noindex из шаблона или из настроек, оставшихся с разработки. В-третьих, что meta robots не противоречит canonical и robots.txt: например, страница закрыта в robots и одновременно имеет noindex — противоречие, потому что робот не увидит noindex. Такие конфликты директив — типичный источник проблем индексации, и аудит должен свести все управляющие сигналы (robots.txt, meta robots, canonical, sitemap) в непротиворечивую систему.

Карта сайта sitemap.xml

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

Что проверяет аудит карты сайта:

• Актуальность. Карта должна отражать текущее состояние сайта: новые товары и категории добавлены, удалённые — убраны. Устаревшая карта с несуществующими URL вводит робота в заблуждение.
• Только индексируемые URL. В sitemap должны попадать страницы с кодом 200, открытые для индексации, канонические. Наличие в карте закрытых в robots, редиректов, 404 или неканонических URL — ошибка, которую находят в аудите.
• Автогенерация и обновление. Для магазина карту генерируют автоматически (штатными средствами 1С-Битрикс) и регулярно обновляют, а не ведут руками. Проверяют, что генерация настроена и работает.
• Разбивка и лимиты. Крупный каталог не помещается в один файл — используют индексный sitemap со ссылками на отдельные карты (товары, разделы, статьи), соблюдая ограничения на число URL и размер файла.
• Ссылка из robots.txt. Адрес карты указан в robots.txt и добавлен в панели вебмастеров.

Отдельно смотрят на согласованность карты с реальной индексацией. Полезный приём аудита — сопоставить число URL в sitemap, число страниц в индексе и число реально существующих страниц по данным краулера. Большие расхождения — сигнал проблемы: если в карте 50 тысяч URL, а в индексе 5 тысяч — часть каталога не индексируется, и нужно искать причину; если в индексе URL кратно больше, чем в карте, — вероятно, в поиск попали дубли и мусор, которых в карте нет. Карта сайта, таким образом, не только помогает индексации, но и служит инструментом диагностики: её сравнение с фактом подсвечивает и «слепые зоны», и лишнее в индексе. Настройку и типовые ошибки sitemap для магазина мы подробно разбираем в статье про robots.txt и карту сайта.

Дубли и канонические адреса

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

URL с параметрами

Самый массовый источник дублей — GET-параметры: сортировки (?sort=price), показ по N товаров, метки рекламных кампаний (?utm_source=), пагинация внутри фильтра, идентификаторы сессий. Каждый параметр даёт новый URL с тем же или почти тем же содержимым. Лечат это связкой инструментов: rel="canonical" с параметрической страницы на чистую, для Яндекса — директива Clean-param в robots.txt, для меток — их отсечение на уровне канонического адреса. Аудит проверяет, что параметрические URL не плодятся в индексе бесконтрольно.

Слеш, регистр и index.php

Одна страница часто доступна в нескольких написаниях: со слешем на конце и без, с /index.php и без него, в разном регистре букв. Для поиска это разные URL с одинаковым контентом — дубли. Решение: выбрать единый канонический формат (обычно со слешем на конце для разделов) и настроить 301-редирект со всех прочих вариантов на него, а также следить за единообразием внутренних ссылок.

www и протокол

Сайт должен быть доступен строго в одном варианте: либо www, либо без, только по https. Если открываются одновременно http и https, www и без-www без склейки — это четыре копии сайта в глазах поиска. Аудит проверяет, что настроен 301-редирект на единое «главное зеркало», а в панелях вебмастеров указан основной адрес.

Пагинация и страницы фильтра

Страницы пагинации категории (2-я, 3-я страница списка) и комбинации умного фильтра — отдельная большая тема. Пагинацию нельзя бездумно закрывать или канонизировать на первую страницу: так можно потерять из индекса товары с глубоких страниц. Комбинации фильтра, наоборот, порождают бесконечное число URL, и без управления индексацией сайт тонет в дублях. Здесь работает принцип: полезные, востребованные спросом агрегатные страницы фильтра открывают и оптимизируют как посадочные, а бесконечные мусорные комбинации закрывают. Это тонкая настройка, которой посвящена отдельная статья про агрегатные страницы фильтра и управление индексацией.

Главный рабочий инструмент против дублей — атрибут rel="canonical": он не перенаправляет, но подсказывает поиску, какую из похожих версий считать главной. Его ставят на страницах, которые должны оставаться доступными пользователю (сортировки, фильтры, метки), указывая на чистый канонический URL. А там, где старый адрес должен исчезнуть навсегда (сменился ЧПУ, склейка зеркал, слешей), применяют не canonical, а 301-редирект. Разница принципиальна: canonical для «полезных дублей», редирект для «переехало навсегда». Задача аудита — по каждому каналу дублей назначить корректное решение и убедиться, что оно единообразно применено в шаблонах.

ЧПУ и структура URL

ЧПУ (человекопонятные URL) — это адреса вида /smartfony/samsung/ вместо технических /catalog/index.php?SECTION_ID=42. Они лучше воспринимаются пользователями, могут содержать ключевые слова и формируют понятную, логичную структуру сайта. Аудит URL проверяет не столько «красоту», сколько системность и отсутствие проблем.

Что смотрят в аудите структуры URL:

• Включены и работают ли ЧПУ. Все ключевые страницы (разделы, карточки, страницы фильтра) должны быть на человекопонятных адресах, а не на технических с параметрами.
• Логичность и вложенность. URL отражает структуру каталога: раздел → подраздел → товар. Без избыточной глубины и без «плоской» свалки всего в корне.
• Транслитерация и читаемость. ЧПУ формируются корректной транслитерацией названий, без случайных символов, пробелов, лишних дефисов и «мусорных хвостов».
• Стабильность адресов. URL не должны меняться без нужды: каждая смена адреса требует 301-редиректа, иначе теряются позиции и накопленный вес страницы.
• Единый формат. Один регистр, единое правило по слешу на конце, отсутствие дублирующих технических параметров в канонических адресах.

Особое внимание — к последствиям смены ЧПУ. В магазинах структуру каталога периодически переделывают, и если при этом не настроить переадресацию со старых адресов на новые, сайт получает массу 404 на месте проиндексированных страниц и теряет их вес. Поэтому аудит ЧПУ всегда идёт в связке с аудитом редиректов: любое изменение адреса должно сопровождаться корректным 301. Как правильно настраивать человекопонятные адреса на платформе, формировать их из свойств товара и избегать типовых ошибок — мы разбираем в статье про ЧПУ для интернет-магазина на 1С-Битрикс.

Редиректы, 404 и soft-404

Коды ответа сервера и переадресации — то, как сайт «общается» с роботом и браузером. Ошибки в этом блоке напрямую бьют по индексации и по пользовательскому опыту, поэтому аудит редиректов и кодов ответа обязателен для любого магазина.

Что аудитируют по этому блоку:

• Корректность 301. Постоянные переезды (смена ЧПУ, склейка зеркал и слешей) должны отдавать код 301, а не 302 (временный) — только 301 передаёт вес и сообщает о постоянном переезде.
• Цепочки редиректов. Когда URL A ведёт на B, B на C, а C на D — это цепочка. Она замедляет обход, теряет часть веса и создаёт лишнюю нагрузку. Цепочки «схлопывают» в один прямой редирект A → D.
• Битые ссылки и 404. Несуществующие страницы должны честно отдавать код 404 с оформленной страницей ошибки и навигацией. Аудит находит внутренние ссылки, ведущие на 404, и устраняет их.
• Soft-404. Опасная ошибка: страница выглядит как «ничего не найдено», но отдаёт код 200. Робот считает её нормальной и индексирует пустышки. Такие страницы должны отдавать 404 или 410.
• Ошибки 5xx. Серверные ошибки на страницах — сигнал проблем хостинга или кода; их отслеживают и по краулеру, и по логам.
• Циклы и петли. Редирект, ведущий сам на себя или по кругу, полностью ломает доступ к странице.

Отдельно про soft-404, потому что это частая и коварная находка в магазинах. Когда товар заканчивается или категория пустеет, система нередко показывает страницу «нет товаров» или редиректит на главную, отдавая при этом код 200. Робот видит рабочую страницу без полезного контента и либо индексирует мусор, либо считает главную «ответом» на несуществующий запрос. Правильное поведение зависит от ситуации: временно отсутствующий товар — оставить страницу с кодом 200 и предложить аналоги; удалённый навсегда — отдать 404/410 или сделать 301 на релевантный раздел. Как грамотно организовать эту логику, разобраться с цепочками, склейкой URL и битыми ссылками на 1С-Битрикс — подробно в статье про редиректы, 404 и склейку URL.

Скорость и Core Web Vitals

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

Ключевые метрики Core Web Vitals, которые аудитируют:

Данные о скорости берут из двух источников. Лабораторные (PageSpeed Insights, Lighthouse) — синтетический прогон в контролируемых условиях: удобны для поиска причин и проверки правок, дают конкретные рекомендации. Полевые (реальные пользователи) — в Google Search Console и отчёте CrUX: показывают фактический опыт посетителей, по ним поиск и оценивает сайт. В аудите смотрят оба: лабораторные подсказывают, что чинить, полевые — насколько это реально ощущают люди.

Типовые находки по скорости в магазинах на 1С-Битрикс предсказуемы: неоптимизированные и слишком тяжёлые изображения без современных форматов и ленивой загрузки, включённый в продакшене режим отладки, отсутствие кеширования составных компонентов, избыточные или дублирующиеся подключения CSS/JS, тяжёлые сторонние скрипты (виджеты, аналитика, чаты), отсутствие сжатия и HTTP-кеширования статики. Хорошая новость в том, что большинство этих проблем решается на уровне настроек и шаблонов, а не переписыванием сайта. Детальный разбор каждой метрики, инструментов измерения и конкретных способов ускорения каталога мы вынесли в отдельную статью про Core Web Vitals интернет-магазина.

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

Микроразметка (Schema.org) — это дополнительная семантическая разметка HTML, которая объясняет поиску, что именно на странице: товар, цена, наличие, рейтинг, отзывы, хлебные крошки, организация. Она не влияет напрямую на позиции, но даёт расширенные сниппеты в выдаче (цена и рейтинг под ссылкой, «звёзды», карусели), а это повышает кликабельность. Для магазина корректная разметка товаров — почти обязательный элемент.

Что проверяет аудит микроразметки:

• Наличие ключевых типов. Для карточек — Product с ценой, валютой, наличием (Offer); для отзывов — Review и AggregateRating; для навигации — BreadcrumbList; для сайта — Organization.
• Валидность. Разметку прогоняют через валидаторы структурированных данных: они показывают ошибки и предупреждения — отсутствующие обязательные поля, некорректные значения.
• Соответствие контенту. Разметка должна отражать то, что реально видит пользователь. Цена и наличие в разметке обязаны совпадать с ценой и наличием на странице — расхождение считается нарушением.
• Полнота обязательных полей. Частая находка — разметка есть, но без обязательных свойств (цена без валюты, товар без наличия), из-за чего расширенный сниппет не показывается.
• Отсутствие спама разметкой. Нельзя размечать то, чего нет на странице, или завышать рейтинги — за это можно получить санкции.

Практический смысл аудита разметки — не просто «есть или нет», а «работает ли она на сниппет». Часто разметка формально присутствует, но с ошибками, из-за которых расширенный сниппет не появляется, — и потенциал кликабельности теряется. Аудит выявляет такие «молчащие» ошибки и переводит их в задачи на исправление шаблонов. Как правильно внедрять Schema.org для товаров, категорий, отзывов и организации на 1С-Битрикс, какие типы и поля использовать и как проверять валидность — подробно в статье про микроразметку Schema.org для магазина.

Метатеги: шаблоны и уникальность

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

Что проверяют по метатегам:

• Заполненность. У каждой значимой страницы должны быть title и description. Пустые метатеги — прямая потеря: поиск сам формирует сниппет как попало.
• Уникальность. Одинаковые title на разных страницах — сигнал дублей и потеря релевантности. Аудит через краулер находит все повторяющиеся и пустые метатеги массово.
• Длина. Слишком длинные title и description обрезаются в выдаче, слишком короткие не используют потенциал. Проверяют соответствие разумным лимитам.
• Осмысленность шаблонов. Шаблон должен давать читаемый, релевантный метатег с подстановкой нужных свойств (категория, бренд, характеристика), а не механическое «купить {товар} {товар} {товар}».
• Вхождение ключа и коммерческих маркеров. В title попадает главный запрос страницы и, где уместно, коммерческие слова — но без переспама.
• Отсутствие конфликтов с H1. Title и H1 связаны по смыслу, но не обязаны совпадать дословно; аудит проверяет, что оба осмысленны.

Главная ценность аудита метатегов для магазина — увидеть проблему на уровне шаблона и починить её разом для тысяч страниц. Если краулер показывает 8 тысяч страниц с одинаковым title «Интернет-магазин» — это не 8 тысяч отдельных задач, а одна ошибка в шаблоне карточки. Правильно построенные шаблоны генерируют уникальные и осмысленные метатеги автоматически, включая страницы умного фильтра, где комбинация фасетов подставляется в title и description. Как строить такие шаблоны для категорий, карточек и агрегатных страниц фильтра — в отдельном материале про агрегатные страницы фильтра и метатеги.

Заголовки H1–H6 и иерархия

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

Что аудитируют по заголовкам:

• Единственный H1. На странице должен быть ровно один заголовок H1, отражающий её главную тему. Ни ноль, ни два-три — частая ошибка шаблонов, когда H1 дублируется или отсутствует.
• Правильная иерархия. Заголовки идут по уровням без «перескоков»: H1 → H2 → H3, а не H1 → H4. Уровень отражает вложенность смысла, а не размер шрифта.
• Заголовки — это смысл, а не оформление. Теги H не должны использоваться ради крупного шрифта в меню, футере или баннерах. Аудит находит «декоративные» заголовки, засоряющие структуру.
• Осмысленность и релевантность. H1 категории и карточки отражает содержание и содержит главный запрос страницы, а не абстрактное «Каталог».
• Согласованность с шаблоном. Как и метатеги, заголовки в магазине генерируются шаблоном — проверяют, что шаблон даёт корректный H1 для всех типов страниц.

Практический подход тот же, что с метатегами: заголовки аудитируют через краулер массово (он показывает страницы без H1, с несколькими H1, с пустыми заголовками) и чинят на уровне шаблонов. Частая находка в магазинах на 1С-Битрикс — H1, зашитый в шаблон как логотип или название сайта в шапке, из-за чего на всех страницах формально два H1; или, наоборот, отсутствие H1 на страницах фильтра, где заголовок должен собираться из выбранной комбинации фасетов. Это несложные, но важные правки: они наводят порядок в смысловой структуре тысяч страниц одним изменением шаблона.

Изображения: alt и вес

Изображения в магазине — это и трафик из поиска по картинкам, и одна из главных причин медленной загрузки. Аудит изображений закрывает две задачи сразу: доступность и семантику (alt) и производительность (вес и формат).

Что проверяют по изображениям:

• Атрибут alt. У изображений товаров должен быть осмысленный alt, описывающий, что на картинке. Это и доступность (для незрячих пользователей), и сигнал для поиска по картинкам, и подстраховка, если изображение не загрузилось.
• Вес и сжатие. Тяжёлые несжатые фото — главный тормоз LCP. Проверяют, что изображения сжаты без потери приемлемого качества и не отдаются в разрешении больше нужного.
• Современные форматы. Использование WebP/AVIF вместо тяжёлых JPEG/PNG заметно снижает вес без потери качества.
• Ленивая загрузка. Изображения вне первого экрана должны подгружаться лениво (loading="lazy"), чтобы не тормозить первичную отрисовку.
• Заданные размеры. У картинок указаны width и height (или заданы через CSS), чтобы избежать сдвигов вёрстки (CLS).
• Адаптивность. Разные размеры под разные экраны (srcset), чтобы мобильные не грузили десктопные «тяжёлые» версии.

Важно расставить приоритеты внутри блока. Массовые пустые alt на тысячах карточек — это, как правило, «важно», но не «критично»: их правят на уровне шаблона (генерация alt из названия товара, бренда, категории). А вот неоптимизированный вес изображений часто попадает в «критично», потому что напрямую роняет Core Web Vitals и конверсию. Поэтому аудит изображений всегда пересекается с аудитом скорости. Как настроить сжатие, форматы, ленивую загрузку и автогенерацию alt на 1С-Битрикс — в отдельной статье про оптимизацию изображений для магазина.

Мобильная версия

Большая часть трафика магазинов идёт с мобильных, и поиск оценивает сайт в первую очередь по мобильной версии (mobile-first). Поэтому аудит мобильной версии — не формальность, а проверка того, как выглядит и работает сайт для основной массы посетителей и для робота.

Что аудитируют по мобильной версии:

• Адаптивность вёрстки. Контент помещается в экран без горизонтальной прокрутки, элементы не наезжают друг на друга, изображения масштабируются.
• Удобство касаний. Кнопки и ссылки достаточно крупные и разнесены, чтобы по ним было удобно попадать пальцем; поля форм пригодны для мобильного ввода.
• Читаемость. Шрифт достаточного размера без необходимости масштабировать страницу вручную.
• Паритет контента. Мобильная версия содержит тот же основной контент, метатеги и разметку, что и десктопная, — при mobile-first именно она попадает в индекс.
• Скорость на мобильных. Мобильные устройства и сети медленнее, поэтому CWV на мобильных проверяют отдельно и обычно они строже, чем на десктопе.
• Корректный viewport. Задан meta viewport, страница не заблокирована от масштабирования.

Ключевой принцип mobile-first, который проверяет аудит: то, чего нет в мобильной версии, для поиска может не существовать. Если на мобильной версии по недосмотру скрыт важный текст, свёрнуты характеристики без возможности раскрыть, отсутствует часть перелинковки или разметки — это прямая потеря сигналов, потому что именно мобильную версию поиск берёт за основу. Поэтому паритет контента между десктопом и мобильным — одна из важных проверок аудита, наряду с удобством и скоростью. Инструменты вроде Search Console показывают отчёт об удобстве для мобильных и подсвечивают конкретные проблемы шаблонов.

HTTPS и безопасность

HTTPS — базовое требование: без защищённого соединения браузеры помечают сайт как небезопасный, а поиск учитывает наличие HTTPS как фактор. Для магазина, где вводят личные данные и оформляют заказы, это тем более обязательно. Аудит проверяет не только «есть ли замочек», но и корректность настройки.

Что смотрят по HTTPS и безопасности:

• Валидность сертификата. SSL-сертификат действителен, не просрочен, выдан на правильный домен и поддомены, без ошибок в цепочке.
• Полный перевод на HTTPS. Весь сайт работает по https, а http-версия отдаёт 301-редирект на https — без исключений и «забытых» разделов.
• Отсутствие смешанного контента. На https-страницах нет ресурсов (картинок, скриптов, стилей), подгружаемых по http, — иначе браузер ругается на «mixed content».
• Согласованность зеркал. HTTPS-версия склеена с http, www и без-www сведены к одному главному зеркалу через 301 (пересекается с блоком дублей).
• Базовая гигиена безопасности. Актуальные обновления платформы и модулей, отсутствие открытых служебных путей в индексе, защита административной части.
• Заголовки безопасности. Наличие разумных HTTP-заголовков (HSTS и подобных) — как дополнительный уровень.

С точки зрения приоритизации отсутствие или поломка HTTPS — это почти всегда «критично»: браузерное предупреждение о небезопасности отпугивает покупателей и бьёт по доверию и конверсии напрямую, а незакрытая http-версия создаёт полный дубль сайта. Смешанный контент — распространённая находка после перевода на https: часть картинок или скриптов остаётся на http-ссылках, и это нужно вычищать. В целом блок HTTPS тесно связан с блоком зеркал и дублей: корректная безопасность и корректная склейка адресов решаются вместе, единым набором 301-редиректов и настроек.

Вложенность, crawl budget и логи бота

Crawl budget (краулинговый бюджет) — это объём ресурсов, который поиск готов тратить на обход вашего сайта. Для небольшого сайта он не проблема, но для магазина с десятками тысяч страниц становится критичным: если робот тратит бюджет на мусорные URL, до важных страниц он доходит реже, и они медленнее индексируются и обновляются. Аудит этого блока — про то, чтобы робот обходил в первую очередь то, что приносит деньги.

Что проверяют по вложенности и crawl budget:

• Глубина вложенности. Важные страницы должны быть доступны за небольшое число кликов от главной. Товары и категории, «зарытые» глубоко и без ссылок, робот навещает редко — их поднимают в структуре и перелинковке.
• Наличие ссылок на страницы. Страница без внутренних ссылок («сирота») плохо обходится и индексируется. Аудит находит такие изолированные URL.
• Расход бюджета на мусор. Комбинации фильтра, сортировки, параметры, дубли — если они открыты, робот тратит на них бюджет. Их закрывают, чтобы освободить ресурс под важное.
• Скорость ответа сервера. Медленный сервер снижает число страниц, которые робот успевает обойти за визит; это тоже влияет на бюджет.
• Согласованность внутренней перелинковки. Логичная перелинковка распределяет вес и «ведёт» робота к приоритетным страницам.

Анализ логов сервера — самый точный инструмент этого блока. Логи фиксируют каждое обращение робота: какие URL он запрашивал, как часто, с какими кодами ответа. Из них видно то, чего не покажет ни одна панель: реальное распределение краулингового бюджета. Частая картина в магазинах — бот десятки тысяч раз в сутки обходит URL с параметрами сортировки и фильтрации, отдавая им ресурс вместо категорий и карточек. По логам находят страницы, которые робот вообще не посещает, разделы, которые он обходит избыточно, всплески 404 и 5xx, обращения к тому, что давно должно быть закрыто. Для небольшого сайта логи можно не трогать, но для крупного каталога это способ увидеть и перераспределить бюджет в пользу коммерчески важных страниц. Внутреннюю перелинковку, которая помогает распределять вес и вести робота, мы разбираем в статье про перелинковку и структуру ссылок.

Регионы и hreflang

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

Что проверяют по регионам и языкам:

• Региональность в панелях. В Яндекс Вебмастере назначен корректный регион сайта (или регионы поддоменов/папок), что влияет на ранжирование по геозависимым запросам.
• Атрибут hreflang. Для многоязычных и мультирегиональных сайтов hreflang указывает поиску, какая версия для какого языка/региона. Аудит проверяет корректность и взаимность ссылок hreflang, наличие self-ссылки и x-default.
• Модель мультирегиональности. Проверяют, что выбранная модель (поддомены, папки городов или один домен с геопривязкой) реализована последовательно и без дублей между регионами.
• Отсутствие конфликтов с canonical. Региональные и языковые версии не должны схлопываться каноническим адресом на одну — иначе теряется смысл разделения.
• Уникальность региональных страниц. Версии для разных городов отличаются контактами, доставкой, географией в текстах, а не являются полными копиями.

Для однорегионального магазина этот блок сводится к корректной привязке региона в вебмастере и проработке геозапросов на ключевых страницах — hreflang не нужен. Для мультирегионального или многоязычного сайта hreflang и модель разделения версий становятся отдельной большой темой, где ошибки (невзаимные ссылки, отсутствие x-default, конфликт с canonical) — частые находки аудита. Как выстроить мультирегиональность на поддоменах или в папках, настроить региональность и не создать дублей между городами — подробно в статье про мультирегиональность и поддомены.

Приоритизация находок

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

Логика приоритизации простая: сначала снимаем то, что мешает индексации и роняет трафик прямо сейчас, потом — то, что ограничивает потенциал, и лишь затем — косметику. Правильный порядок работ обычно такой: сначала открыть ошибочно закрытые страницы и убрать «стопы» индексации, затем разобраться с дублями и наладить редиректы и зеркала, потом заняться скоростью и Core Web Vitals, следом — метатегами, заголовками и микроразметкой, и в конце — точечными улучшениями. Начинать со шлифовки alt-атрибутов, когда половина каталога в noindex, — потеря времени.

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

Отчёт и план правок

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

Что содержит хороший отчёт по техническому аудиту:

• Находка и её суть. Что не так, где именно (какой шаблон или раздел), сколько страниц затронуто.
• Приоритет. Критично / важно / мелочь — чтобы был понятен порядок работ.
• Причина. Почему так вышло (ошибка шаблона, настройка, оставшаяся с разработки, особенность платформы) — это помогает исправить системно, а не точечно.
• Решение. Конкретная рекомендация, что и как изменить, — в терминах, понятных разработчику и SEO-специалисту.
• Ответственный. Кто внедряет — разработчик, контент-менеджер или SEO-специалист.
• Проверка результата. Как убедиться, что правка сработала: переиндексация, уход дублей из индекса, изменение метрик, повторный прогон краулером.

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

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

Эти промахи встречаются в аудите и его внедрении чаще всего — в упущенном трафике и потраченном времени:

• Аудит ради простыни предупреждений. Выгрузили сотни автопредупреждений из сервиса и отдали как есть — без фильтрации шума, приоритетов и решений. Работать с таким «аудитом» невозможно.
• Путаница robots.txt и noindex. Закрывают страницу в robots, ожидая, что она выпадет из индекса, — а робот не доходит до noindex, и страница застревает в поиске «вслепую».
• Case «весь сайт в noindex». Настройка запрета индексации, оставшаяся с этапа разработки, забыта на боевом сайте — трафика нет, а причину ищут месяцами.
• Дубли пущены на самотёк. Параметры, сортировки, слеши, зеркала и комбинации фильтра не обработаны — сайт тонет в дублях, сигналы размазаны, бюджет робота потрачен на копии.
• Canonical вместо 301 и наоборот. Для «переехавшего навсегда» адреса ставят canonical (а он не перенаправляет), для полезного дубля — жёсткий редирект (и теряют нужную пользователю страницу).
• Цепочки и soft-404 без внимания. Многоступенчатые редиректы и «пустышки» с кодом 200 не находят и не чинят — робот тратит ресурс и индексирует мусор.
• Смена ЧПУ без редиректов. Переделали структуру каталога и не настроили 301 со старых адресов — получили массу 404 на месте проиндексированных страниц и потерю их веса.
• Скорость проверяют на одной странице. Тестируют только главную и делают вывод по всему сайту, тогда как у категории, карточки и фильтра совсем другая нагрузка и другие проблемы.
• Разметка есть, но «молчит». Микроразметка присутствует, но с ошибками в обязательных полях — расширенный сниппет не показывается, а это считают «сделанным».
• Метатеги и заголовки чинят поштучно. Правят отдельные страницы вместо шаблона, из которого проблема тиражируется на тысячи URL, — бесконечная и бессмысленная работа.
• Игнор мобильной версии и HTTPS. Аудитируют десктоп при mobile-first индексации; оставляют смешанный контент или незакрытую http-версию после перевода на https.
• Аудит без внедрения и контроля. Отчёт сдали — и на этом всё. Находки не исправлены, результат не проверен; аудит не дал ничего, кроме файла в папке.

Чек-лист аудита

Практический список для технического SEO-аудита интернет-магазина на 1С-Битрикс:

1. Индексация проверена. robots.txt не закрывает лишнего и закрывает служебное; meta robots и X-Robots-Tag стоят где надо и не стоят где не надо; директивы не конфликтуют между собой.
2. Карта сайта в порядке. sitemap.xml актуален, содержит только индексируемые канонические URL с кодом 200, автогенерируется, указан в robots.txt; число URL согласуется с индексом.
3. Дубли взяты под контроль. Параметры, сортировки, метки — через canonical и Clean-param; слеши, регистр, www и протокол — через 301 на единое зеркало; комбинации фильтра управляются.
4. ЧПУ и редиректы аудированы. Человекопонятные адреса работают и стабильны; 301 корректны, без цепочек и петель; 404 честные, soft-404 устранены, битые ссылки убраны.
5. Скорость и CWV измерены. LCP, INP, CLS проверены по типовым шаблонам, лабораторно и по полевым данным; найдены и назначены к правке тормозящие факторы.
6. Разметка и метатеги проверены. Микроразметка валидна и полна; title и description заполнены, уникальны и осмысленны на уровне шаблонов; иерархия H1–H6 корректна.
7. Изображения и мобильная версия оценены. alt заполнены, вес и форматы оптимизированы, ленивая загрузка включена; мобильная версия адаптивна и содержит паритетный контент.
8. Безопасность и зеркала. HTTPS настроен полностью, без смешанного контента; зеркала склеены; базовая гигиена безопасности соблюдена.
9. Crawl budget и логи. Вложенность и перелинковка обеспечивают доступность важных страниц; для крупного сайта проанализированы логи и перераспределён бюджет робота; региональность и hreflang настроены, где нужно.
10. Отчёт и внедрение. Находки приоритизированы (критично/важно/мелочь), оформлены с решением и ответственным; правки внедрены и результат проверен переиндексацией и метриками.

Вывод

Технический SEO-аудит интернет-магазина на 1С-Битрикс — это не «прогон через сервис», а системная проверка «инженерной» стороны сайта: как его обходят роботы, что попадает в индекс, нет ли дублей и битых ссылок, быстро ли грузятся страницы, корректны ли метатеги, заголовки, микроразметка и мобильная версия. Для магазина ядро аудита — индексация и дубли: robots.txt и noindex, canonical и sitemap, параметры URL, слеши, зеркала, пагинация и бесконечные комбинации фильтра. Вокруг них — ЧПУ и редиректы (301, цепочки, 404 и soft-404), скорость и Core Web Vitals, валидность разметки, шаблоны метатегов и заголовков, изображения, HTTPS, вложенность и crawl budget по логам бота, регионы и hreflang. Аудитируют не страницы поштучно, а типовые шаблоны и правила их формирования — потому что одна ошибка в шаблоне тиражируется на тысячи URL.

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

Другие разборы по техническому и контентному продвижению магазина на 1С-Битрикс — в рубрике SEO и продвижение: от robots.txt, ЧПУ и редиректов до микроразметки, Core Web Vitals и агрегатных страниц фильтра.