Аудит сайта-каталога перед рекламой: HTTPS, mobile и SEO

Как работающий на компьютере каталог оказался не готов к рекламе из-за недоступного HTTPS, фиксированной ширины и отсутствия технической базы SEO.

Устаревший каталог может выглядеть рабочим на компьютере и быстро отдавать HTML, но одновременно разрывать путь мобильного посетителя, не открываться по HTTPS и оставаться без управляемой карты для поисковиков. Ниже — обезличенный аудит производственного сайта-каталога перед рекламой.

Критические проблемы оказались не в дизайне

Главным подтверждённым риском стала недоступность HTTPS: HTTP-версия отвечала, а защищённое соединение не устанавливалось. Для клиента это может проявляться как небезопасный адрес или неоткрывающаяся ссылка, если реклама, каталог или внешний сервис ведут на HTTPS.

Второй разрыв был виден только на телефоне. Страница использовала фиксированную ширину около 1100 пикселей. На экране 390 пикселей меню, контакты и кнопка обратного звонка уходили далеко вправо, а каталог требовал горизонтальной прокрутки. Это не косметика: посетителю сложнее понять предложение и перейти к обращению.

Почему каталог не равен посадочной странице

На сайте были категории, фильтры, поиск и карточки с характеристиками. Это сильная база, но рекламному посетителю дополнительно нужны ясный оффер, минимальная партия или условия расчёта, срок ответа, заметный CTA и форма, сохраняющая выбранную модель.

В карточке товара полезно размещать действие «Получить расчёт по этой модели» и передавать в обращение артикул, URL и UTM-метки. Затем маршрут проверяют до фактического получателя по инструкции как проверить доставку заявок с сайта. Без доступа к почте или CRM нельзя утверждать, что обращения терялись; можно подтвердить только наличие риска.

Robots, sitemap и слабые сигналы страниц

Оба стандартных файла — robots.txt и sitemap.xml — возвращали HTTP 404. При этом каталог имел десятки карточек, категории, фильтры и пагинацию. Без XML-карты и ясной стратегии canonical сложнее управлять обходом и дублями URL.

У главной был коммерческий title, но H1 рассказывал о компании, а у выборки внутренних страниц отсутствовали descriptions. Все проверенные изображения имели пустой alt; canonical и JSON-LD не обнаружены. Для SEO и продвижения сайта сначала нужны уникальные страницы спроса, фактические условия, FAQ и технически однозначные URL, а затем разметка Organization, Product, BreadcrumbList и FAQ.

Доверие и безопасность, которые владелец может не видеть

Публичные заголовки раскрывали старую версию веб-сервера, а HTML подключал устаревшую библиотеку по HTTP. Это не доказывает взлом или уязвимость конкретной установки, но требует инвентаризации и обновления с резервной копией и тестом совместимости.

Формы не показывали рядом с отправкой явную ссылку на политику или согласие. Юридическую оценку должен давать профильный специалист, но с точки зрения конверсии посетителю важно понимать, как используются его данные. На сайте также не были видны цели аналитики, привязанные к подтверждённой доставке обращения.

Быстрый HTML не отменяет остальных рисков

Ответ сервера по HTTP был быстрым: TTFB выборки основных страниц составлял примерно 0,11–0,26 секунды, а HTML весил около 5–23 КБ. Однако первый экран содержал крупные изображения, а мобильная геометрия была сломана. Поэтому скорость нужно оценивать вместе с ресурсами, LCP и реальным пользовательским сценарием, а не только по времени получения HTML.

Правильный порядок исправлений

1. Настроить HTTPS, единый домен и постоянные редиректы; убрать HTTP-зависимости.
2. Сделать адаптивными шапку, каталог, карточку и формы; вернуть CTA и контакты в мобильный первый экран.
3. Проверить формы до почты или CRM и считать целью только подтверждённый успех.
4. Опубликовать robots.txt и sitemap.xml, настроить canonical и правила фильтров/пагинации.
5. Усилить карточки и посадочные коммерческими фактами, примерами, FAQ, alt и структурированными данными.

Начинать стоит с технического и конверсионного аудита, а развитие каталога связывать с хабом сайт-каталог и интернет-магазин. Такой порядок сначала закрывает риски доступности и заявок, затем создаёт основу для рекламы, SEO и AI-поиска.