Что доказывает проверка исходного HTML
  1. Выборка

    Три сайта из наших кейсов

  2. Снимок

    Один GET главной страницы

  3. Признаки

    Title, H1, canonical и формы

  4. Граница

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

15 октября 2026 года мы проверили исходный HTML главных страниц трёх сайтов из наших кейсов: SPECO, TourAudio и 40REF. Все три страницы ответили HTTP 200, содержали по одному Title и canonical на собственный адрес. При этом в HTML SPECO не нашлось H1. Такой короткий срез показывает, почему технический чек-лист полезен, но не заменяет проверку пути заявки.

Как проводили проверку

Выборка составлена из трёх известных нам проектов с оборудованием и технической продукцией. Это не случайная выборка рынка. Для каждого сайта выполнили один публичный GET-запрос главной страницы с обработкой серверных редиректов. Зафиксировали HTTP, Title, H1, canonical, meta robots, элементы form и ссылки tel/mailto.

Проверка выполнена 15 октября в 13:42 по МСК. JavaScript не исполняли, заявки не отправляли, авторизацию и частную аналитику не использовали. Количество элементов в HTML не равно количеству видимых пользователю форм: шаблон может содержать скрытые окна и повторения для разных экранов.

Что получили

Срез исходного HTML главных страниц, 15 октября 2026 года
СайтHTTPTitleH1Canonical на свой URLЭлементы form
SPECO20010Да3
TourAudio20011Да3
40REF20011Да3

На всех трёх страницах нашлись ссылки для звонка и email. В полученном meta robots не обнаружен noindex. В этом срезе не проверялись X-Robots-Tag, правила robots.txt и фактическая индексация, поэтому таблица не является вердиктом о доступности страниц поисковым роботам.

Что означает отсутствие H1

На SPECO в исходном HTML не найден элемент H1. Это повод проверить семантическую разметку главного заголовка: видимый текст первого экрана может быть оформлен другим тегом. Исправление должно сохранить понятную структуру страницы, а не добавить скрытый заголовок ради галочки.

Из этого наблюдения нельзя вычислить потерянные позиции или заявки. Чтобы оценить влияние, нужны данные поиска, изменения страницы и сопоставимый период. Техническая находка определяет следующую проверку, но не доказывает причину роста или падения трафика.

Чего не видно в таком отчёте

Три элемента form не доказывают, что хотя бы одно письмо доставляется менеджеру. Кнопка может открывать неправильное окно, CAPTCHA — не проходить на мобильном устройстве, а сервер — показывать успех до сохранения заявки. Эти проблемы обнаруживаются только при проверке сценария с согласованным тестовым контактом.

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

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

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

  1. Возьмите главную, категорию и одну важную карточку.
  2. Проверьте исходный HTML и ответ сервера через бесплатный инструмент.
  3. Сравните найденный Title, H1 и canonical с назначением страницы.
  4. Пройдите путь обращения с телефона и компьютера, предварительно согласовав тест.
  5. Сверьте сохранённую заявку, письмо и CRM, а не только сообщение браузера.

Для фиксации результата подойдёт таблица приёмки интеграции. Для работы с точным товарным спросом — руководство по артикулам и моделям. Такой подход связывает техническую проверку с покупательской задачей.

Документация