Аудит сайта туристической компании: в каком порядке проверять и как понять, что правки дают заявки

Если сайт агентства не продаёт туры напрямую, оценивать его по интернет-магазинным метрикам неверно. Опрос Ассоциации Туроператоров России показал, что 60% путешественников предпочитают покупать туры у турагентов (54% из них — у проверенных), 15% — на сайтах туроператоров, 6% — на агрегаторах. Опрос проводили в Telegram-канале ассоциации, он нерепрезентативен и не заменяет официальную статистику. Но он подсказывает роль сайта: убедить, что агентству можно доверять, и довести человека до обращения.

Второй ориентир — мобильный путь. Директор Sletat.ru на конференции «Цифровой туризм — 2026» сказал, что около половины бронирований делается через мобильные приложения, а около 70% дистанционных продаж перешло в мессенджеры. Это позиция докладчика в пересказе отраслевого СМИ, а не официальные данные. Но если она близка к вашей реальности, сайт нужно проверять с телефона, а финальным шагом часто окажется переход в мессенджер.

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

Слой 1. Формы заявок и персональные данные

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

• Согласие в отдельном документе. По обзору CISOCLUB, с 1 сентября 2025 года согласие на обработку персональных данных должно быть отдельным документом, а не частью пользовательского соглашения. Проверьте формы заявки, подписки и обратной связи.
• Чекбокс согласия. По тому же обзору, он не может быть проставлен по умолчанию. Откройте каждую форму и посмотрите, нет ли галочки заранее.
• Куда уходят данные. По разъяснению Б1, с 1 июля 2025 года действует уточнённая часть 5 статьи 18 152-ФЗ: оператор обязан записывать, хранить и обновлять персональные данные граждан РФ в базах на территории России, в том числе при сборе через интернет. Типичная точка проверки — форма, которая отправляет заявку напрямую в зарубежный сервис. Спросите у разработчика, куда физически попадают данные.
• Статус оператора. Компания, которая собирает заявки на сайте, обычно является оператором персональных данных. Электронные формы уведомления о начале обработки размещены на портале Роскомнадзора по персональным данным. Нужно ли уведомление именно вам, решает юрист.

О штрафах: по обзорам, за нарушение локализации они доходят до 6 млн ₽ за первое и 18 млн ₽ за повторное нарушение (КоАП, закон 420-ФЗ от 30.11.2024). Это оценка из обзоров, а не готовая цифра для расчёта рисков. Часть проверок неактуальна, если сайт не собирает данные граждан РФ, но для российского агентства это редкий случай.

Закрывайте этот слой первым. Юридические правки обычно не требуют редизайна, а риск не зависит от трафика.

Слой 2. Скорость: какие данные брать для замера

Техническая проверка строится на трёх метриках Core Web Vitals. По документации web.dev, «хорошими» считаются значения:

• LCP (скорость загрузки основного контента) — не более 2,5 с;
• INP (отклик на действие) — не более 200 мс;
• CLS (визуальная стабильность) — не более 0,1.

Диапазон «требует улучшения»: LCP 2,5–4 с, INP 200–500 мс, CLS 0,1–0,25. Всё, что хуже, считается «плохим». Сайт засчитывается как «хороший» по метрике, если в пороге «хорошо» укладываются не менее 75% просмотров страниц (описание порогов). Одна быстрая загрузка на вашем ноутбуке ничего не доказывает.

Чаще всего путаются в отчёте PageSpeed Insights, потому что в нём два блока данных. Полевые данные (Chrome User Experience Report) — анонимизированный опыт реальных пользователей. Лабораторные (Lighthouse) — симуляция загрузки на одном устройстве в фиксированных условиях сети. Цифры в блоках могут расходиться, и это не сбой инструмента. Из описания следует практическое правило: причины ищите в лабораторных данных, а результат правок оценивайте по полевым.

Для конкретных страниц удобнее PageSpeed Insights: полевые данные в нём обновляются ежедневно. Набор CrUX в BigQuery обновляется ежемесячно и только на уровне origin, поэтому годится для динамики по всему сайту. Отчёт Core Web Vitals в Search Console группирует URL по реальным данным пользователей.

Для российской аудитории добавьте показатель из Яндекс Вебмастера. Достижение «скорость сайта» лежит в разделе «Качество сайта → Достижения и статистика». Оно считается по данным Яндекс Браузера о скорости открытия страниц при переходе из мобильной выдачи Яндекса и обновляется не реже раза в месяц. У сайтов с недостаточным трафиком индекс не определяется. С отчётом Google его напрямую не сравнить: данные разные.

Небольшому агентскому сайту полевых данных может не хватить ни в Google, ни в Яндексе. Тогда остаются лабораторные замеры. Используйте их как ориентир для сравнения «до и после» на тех же страницах, а не как приговор.

Мобильная версия: проверка на реальном телефоне

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

• текст читается без увеличения;
• кнопки и ссылки достаточно крупные;
• страница не требует горизонтальной прокрутки;
• элементы интерфейса не перекрывают контент;
• навигация простая.

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

Слой 3. Что делают посетители: вопросы к странице

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

• Что принимают за кнопку? Карта кликов показывает клики по всем элементам страницы, в том числе не являющимся ссылками. Если посетители кликают по картинке или подписи, которые ничего не открывают, это кандидат на исправление.
• Доходят ли до формы и цены? Карта скроллинга показывает, как распределяется внимание по участкам страницы, например сколько людей добирается до формы заявки или блока с ценой.
• Что происходит на самом деле? Вебвизор записывает действия отдельных посетителей: движения курсора, клики, прокрутку, переходы. Карты дают агрегат за период, Вебвизор — конкретные сессии.
• Где теряются на форме? Для этого в Метрике есть аналитика форм.

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

Слой 4. Путь до обращения

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

Отдельных норм по навигации туристических сайтов в исходных данных нет, поэтому здесь описан способ проверки, а не эталонная структура. Эталон придётся искать на собственных данных: по записям сессий и динамике обращений.

Чего ждать от ускорения: порядок величины

Российских кейсов с измеренным ростом конверсии именно туристических сайтов в исходных данных нет. Есть зарубежные оценки. Ими можно обосновать проект, но не спрогнозировать результат.

• Исследование Google и Deloitte «Milliseconds Make Millions» охватило 37 брендов из ретейла, туризма и лидогенерации за 30 дней. Ускорение мобильного сайта на 0,1 с давало в туризме рост конверсий на 10,1% и среднего чека на 1,9%.
• Renault, оптимизируя LCP, получила снижение показателя отказов на 14% и рост конверсии на 13% на каждую сэкономленную секунду LCP. Это автомобильная отрасль.
• Японский e-commerce-проект Rakuten 24 после инвестиций в Core Web Vitals увеличил выручку на посетителя на 53,37% и конверсию на 33,13%. Это интернет-торговля, не туризм.

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

Границы метода и типичные ошибки

Это выводы из ограничений выше, а не найденные факты.

• Начинать с оформления, не проверив формы. Юридический слой дешевле по трудозатратам и опаснее по последствиям.
• Считать результатом балл вместо заявок. Балл Lighthouse — лабораторная симуляция, а заявки — то, ради чего сайт существует.
• Сравнивать индекс Яндекса с отчётом Google. Данные у них разные, совпадения ждать не стоит.
• Менять несколько вещей сразу. Тогда непонятно, что сработало.
• Ждать полевых данных у сайта с малым трафиком. Их может не быть, и с этим придётся жить.

Порядок работ: авторская приоритизация

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

1. Формы и персональные данные: отдельное согласие, пустой чекбокс, место хранения данных, уведомление оператора. Инструмент — вопросы разработчику и юристу. Приоритет первый: цена ошибки выше любой конверсионной оптимизации.
2. Быстрые исправления по данным Метрики: нерабочие «кнопки» на карте кликов, потери на форме по аналитике форм, проверка гипотез в Вебвизоре. Приоритет второй: обычно это точечные правки с заметным эффектом.
3. Мобильная версия и скорость: LCP, INP и CLS в PageSpeed Insights, «скорость сайта» в Вебмастере, проверка мобильных страниц. Приоритет третий: правки чаще требуют разработчика, но для мобильной аудитории они важны.
4. Эксперименты с путём до обращения: число шагов, видимость способа связи, переход в мессенджер, положение формы и цены. Приоритет четвёртый: опираться придётся на собственные данные.

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