Скрытая ошибка в коде отличается от обычного бага тем, что сайт от неё не падает: страницы открываются, формы отправляются, дизайн на месте, в консоли тишина. Ломается другое — часть посетителей не доходит до кнопки, а поисковый робот получает сигнал, что страница неудобная. Ниже — какие именно ошибки работают так, как найти их за один вечер и в каком порядке чинить, чтобы не сломать то, что работает.
Почему одна ошибка бьёт и по позициям, и по заявкам
Долгие годы в отрасли держалось удобное разделение: техническая оптимизация отдельно, конверсия отдельно. Первым занимался SEO-специалист, вторым — маркетолог, и пересекались они редко. Это разделение перестало работать примерно тогда, когда поисковые системы научились измерять не только код страницы, но и то, как с ней обращается живой человек.
Сегодня и Яндекс, и Google собирают сигналы взаимодействия: сколько человек ждал отклика после нажатия, дёрнулась ли вёрстка под пальцем, вернулся ли посетитель в выдачу через несколько секунд. Метрики Core Web Vitals — LCP, CLS, INP — это формализованная запись того же самого опыта. И получается, что любой технический дефект, который мешает человеку, автоматически превращается в отрицательный сигнал для алгоритма.
Механика простая. Кнопка заявки отрисовывается, но ещё две секунды не реагирует на нажатие, потому что обработчик события навешивается после загрузки тяжёлого скрипта. Визуально страница готова. Посетитель жмёт — ничего. Жмёт ещё раз — ничего. Уходит. В отчётах это выглядит как низкая конверсия и высокий процент коротких визитов, а в оценке качества страницы — как плохой INP. Ошибка одна, счёт по ней приходит с двух сторон, и ни один из счётов не подписан «ошибка в JavaScript».
Второй важный момент: такие дефекты почти никогда не бывают всеобщими. Они проявляются на медленном соединении, на конкретной версии мобильного браузера, на одном шаблоне страниц из пяти. Владелец сайта смотрит со своего рабочего компьютера по офисному интернету и не видит проблемы физически. Поэтому диагностика тут важнее интуиции.
Есть и третья сторона проблемы — деньги на рекламу. Технический дефект бьёт по платному трафику ровно так же, как по органическому, только счёт приходит быстрее и в явном виде. Вы платите за клик, человек попадает на страницу, которая не отвечает на нажатие, и уходит. Рекламные системы, к тому же, учитывают качество посадочной страницы при расчёте цены клика, так что медленный сайт делает дороже каждое обращение. Поэтому диагностику кода я считаю не «работой по SEO», а базовой гигиеной для любого канала привлечения.
Семь дефектов, которые встречаются чаще остальных
За двадцать лет практики список типовых «убийц» почти не менялся по сути, менялись только технологии, в которых они прячутся. Вот те, что я проверяю в первую очередь на любом незнакомом проекте.
Блокирующие скрипты и стили в head
Браузер, встретив в шапке документа синхронный скрипт, останавливает разбор страницы и ждёт, пока файл скачается и выполнится. Один такой файл на 300 килобайт при мобильном интернете — это плюс полторы-две секунды к пустому экрану. Лечится атрибутами defer и async для скриптов и разделением CSS на критический (встроенный в страницу) и остальной, загружаемый отложенно.
Сдвиг вёрстки после загрузки
Классика: изображение или рекламный блок вставляются без заданных размеров, и когда они подгружаются, весь контент прыгает вниз. Человек целился в кнопку, а нажал на баннер. Каждому изображению нужны атрибуты width и height или CSS-свойство aspect-ratio, а под динамические блоки заранее резервируется место.
Подробнее об этом — в статье «Скорость загрузки сайта — обман: настоящая метрика, которая решает позиции, прячется в другом месте».
Формы, которые молча не отправляются
Самая дорогая категория. Форма визуально работает, но заявка не уходит: сломался обработчик после обновления CMS, изменился адрес endpoint, антиспам-плагин начал резать отправки, письмо уходит в спам получателя. Проверять надо не глазами, а фактом — тестовая отправка с посторонней почты раз в неделю и запись всех обращений в базу, а не только в письмо.
Разная разметка для робота и для человека
Часть контента подставляется скриптом уже в браузере. Робот, который не выполняет тяжёлый JavaScript или обрывает его по таймауту, видит пустую заготовку. Отсюда странные ситуации: страница в индексе есть, а по своему же тексту не находится. Проверяется просмотром сохранённой копии и инструментом проверки ответа сервера в Вебмастере.
Дубли из-за параметров и вариантов адреса
Помогу с продвижением: продвижение сайта в Яндексе — вывожу сайты в топ Яндекса белыми методами.
Одна и та же страница доступна со слэшем и без, с www и без, по HTTP и HTTPS, с UTM-метками и параметрами сортировки. Для человека это одна страница, для поисковика — пять разных документов с одинаковым содержимым. Сигналы размазываются между ними, ни один не набирает достаточно веса.
Мобильная версия, которая отличается по содержимому
Часть блоков скрыта через display:none «чтобы не мешали на телефоне», часть контента вообще не выводится в мобильном шаблоне. Индексация давно ведётся по мобильной версии, и то, чего нет на телефоне, для поиска не существует. Скрывать под спойлер — можно, вырезать из разметки — нет.
Тяжёлые сторонние виджеты
Чат, карта, виджет отзывов, счётчики, пиксели рекламных систем. Каждый по отдельности выглядит безобидно, вместе они добавляют мегабайты и десятки запросов к чужим доменам. Виджет чата, который грузится сразу вместе со страницей, а не по первому касанию экрана, — очень частая причина плохого INP на мобильных.
Где ошибка проявляется и чем её измерять
| Дефект | Как бьёт по человеку | Чем виден в метриках | Где проверить |
|---|---|---|---|
| Блокирующие скрипты | Долгий белый экран | Плохой LCP, рост отказов | PageSpeed Insights, вкладка Network |
| Сдвиг вёрстки | Промахи по кнопкам | Высокий CLS | PageSpeed Insights, поле Layout Shift |
| Мёртвая форма | Заявка не доходит | Конверсия падает при том же трафике | Тестовая отправка, лог обращений |
| Контент только в JS | Не влияет | Страница не находится по своему тексту | Сохранённая копия, проверка ответа сервера |
| Дубли адресов | Не влияет | Страницы конкурируют между собой | Отчёт по страницам в Вебмастере |
| Урезанная мобильная версия | Меньше информации для решения | Позиции ниже на мобильных | Сравнение двух версий вручную |
| Тяжёлые виджеты | Задержка отклика на нажатие | Плохой INP | Профилировщик, отключение по одному |
Диагностика за один вечер: порядок проверок
Полный технический аудит занимает недели, но базовую диагностику по этому списку реально пройти за три-четыре часа. Важно идти по порядку — каждый следующий шаг опирается на результат предыдущего.
- Отправьте заявку сами. С телефона, по мобильному интернету, с почтового ящика, которого нет в вашей базе. Каждую форму на сайте: главную, страницу услуги, всплывающее окно, обратный звонок. Проверьте, дошло ли письмо и записалось ли обращение.
- Прогоните три ключевые страницы через PageSpeed Insights. Главную, посадочную под основную услугу и карточку товара. Смотрите не на общий балл, а на три числа: LCP, CLS, INP — отдельно для мобильных.
- Откройте сайт в режиме эмуляции медленной сети. В инструментах разработчика выберите профиль Slow 4G и перезагрузите страницу. Всё, что заметно дёргается и прыгает в этот момент, — ваш CLS.
- Посмотрите на страницу глазами робота. Отключите JavaScript в браузере или запросите сохранённую копию. Если текста и ссылок нет — контент подставляется скриптом, и это надо чинить на сервере.
- Проверьте варианты адреса. Откройте главную со слэшем и без, с www и без, по HTTP. Все варианты должны склеиваться одним постоянным редиректом на единственный основной адрес.
- Сравните мобильный и десктопный шаблон по тексту. Скопируйте видимый текст обеих версий в два файла и сравните объём. Расхождение больше десяти процентов — повод разбираться.
- Отключите виджеты по одному. Через настройки или через блокировку домена в инструментах разработчика. После каждого отключения — замер. Так вычисляется конкретный виновник, а не «сайт вообще тяжёлый».
Отдельно стоит завести привычку смотреть в отчёты Яндекс.Метрики по устройствам и браузерам. Если конверсия на iOS втрое ниже, чем на Android, при сопоставимом трафике — это почти всегда техническая причина, а не разница в аудитории.
Ещё одна проверка, которую часто пропускают: посмотрите, что отдаёт сервер при обращении к несуществующему адресу. Наберите после домена любую бессмыслицу. Правильный ответ — код 404 и понятная страница с навигацией. Если сервер отдаёт код 200 с пустой страницей или редиректит всё подряд на главную, поиск получает бесконечное количество «существующих» адресов с одинаковым содержимым, и бюджет обхода тратится впустую. Заодно проверьте, как ведёт себя сайт при обращении по IP-адресу и по техническому домену хостинга — эти копии тоже иногда живут в индексе.
Тему разбирал отдельно: «Как ошибка 404 влияет на позиции сайта».
Что чинить первым: порядок приоритетов
Найденных проблем обычно набирается больше, чем ресурса на их устранение. Порядок я выстраиваю по одному критерию — сколько денег теряется прямо сейчас.
- Первый приоритет — всё, что рвёт путь к заявке. Неработающая форма, недоступный номер телефона, кнопка, которая не реагирует. Здесь потери идут ежедневно и в полном объёме.
- Второй — доступность контента для робота. Если текст не индексируется или страницы конкурируют между собой из-за дублей, весь остальной труд над сайтом обесценивается.
- Третий — скорость первого экрана. LCP и блокирующие ресурсы. Это влияет и на отказы, и на оценку страницы.
- Четвёртый — стабильность вёрстки и отзывчивость. CLS и INP. Улучшения здесь заметны не сразу, но они накапливаются.
- Пятый — всё остальное: оптимизация картинок, чистка неиспользуемого CSS, современные форматы изображений.
Соблазн начать с пятого пункта велик: он самый понятный и по нему проще всего отчитаться цифрой в отчёте. Но пока форма не отправляет заявки, ускорение картинок на четверть секунды не приносит ни рубля.
Как чинить, ничего не сломав
Правка технических дефектов на живом сайте — отдельный риск. Несколько правил, которые экономят нервы.
Делайте копию перед каждым изменением — файлов и базы. Не «когда-нибудь настроим бэкапы», а прямо перед конкретной правкой. Второе: меняйте по одной вещи за раз. Если вы одновременно переписали загрузку скриптов, поменяли редиректы и обновили плагин, а трафик просел, — вы никогда не узнаете, из-за чего именно.
Если нужна помощь по теме — заказать сайт.
Третье: не трогайте директивы индексации на горячую. Строки с robots, canonical, редиректами — самая опасная зона. Ошибка в одной строке шаблона выкашивает из выдачи весь тип страниц, и восстановление занимает месяцы. Проверяйте изменения на тестовой копии, закрытой от индексации.
Четвёртое: фиксируйте состояние до правки. Замеры скорости, число страниц в индексе, позиции по десятку основных запросов, конверсия за прошлый месяц. Без этих цифр вы не сможете доказать даже самому себе, что стало лучше.
Смежный материал по теме — «Обновил WordPress — упали позиции: что ломается при обновлении ядра и плагинов».
Как убедиться, что починка сработала
Технические изменения дают отклик с разной задержкой, и это надо учитывать, чтобы не паниковать и не откатывать правильные решения.
Конверсия реагирует сразу — почти в тот же день, как только починена форма или кнопка. Лабораторные метрики скорости меняются моментально при следующем замере. А вот полевые данные, те самые, которые собираются с реальных посетителей, обновляются с задержкой в несколько недель: это скользящее окно, и старые плохие замеры выпадают из него постепенно.
Позиции реагируют ещё медленнее. Роботу нужно переобойти изменённые страницы, а алгоритму — пересчитать оценку. На среднем сайте это от двух недель до полутора месяцев. Поэтому оценивать результат технической правки через неделю бессмысленно: вы увидите шум, а не эффект.
Отдельно советую вести простой журнал изменений: дата, что именно поменяли, на каких страницах. Через полгода, когда понадобится понять, откуда взялся рост или провал, этот файл окажется ценнее любой аналитики.
Частые вопросы
Как понять, что дело именно в коде, а не в спросе или конкурентах?
Сравните динамику по сегментам. Падение спроса видно по всей нише сразу: сокращается число показов в Вордстате, проседает трафик и у конкурентов. Действия конкурентов бьют выборочно — по конкретным запросам, где кто-то усилился. А технический дефект даёт характерную картину: трафик держится примерно на прежнем уровне, а конверсия падает, либо проседает один тип устройств или один шаблон страниц при живых остальных. Если конверсия на мобильных упала вдвое, а на десктопе не изменилась, спрос тут ни при чём.
Нужен ли программист или можно справиться самому?
Диагностику по списку выше проходит любой владелец сайта — она не требует чтения кода, только внимательности. Часть исправлений тоже делается без разработчика: атрибуты размеров у картинок, отложенная загрузка виджета чата, настройка редиректов в панели хостинга. Но правки в шаблоне темы, в логике вывода контента и в обработчике формы лучше отдавать тому, кто умеет откатывать изменения. Здесь дешевле заплатить за час работы, чем потом неделю искать, что сломалось.
Сайт быстро открывается у меня — значит, со скоростью всё нормально?
Нет, и это самая частая ошибка в оценке. Вы открываете сайт с прогретым кэшем, по хорошему интернету, с мощного устройства и часто по адресу, который уже закэширован сервером. Ваш посетитель заходит впервые, с телефона, из места с неустойчивой связью. Смотреть надо на полевые данные — те, что собраны с реальных пользователей, — и отдельно на мобильный сегмент. Разница между вашим впечатлением и этими цифрами обычно двукратная.
Что делать, если сайт на конструкторе и в код доступа нет?
Возможностей меньше, но они есть. Убирайте лишние блоки и виджеты, сжимайте изображения перед загрузкой, отключайте анимации на мобильных, следите за размером шапки — на конструкторах она часто тянет за собой половину веса страницы. Проверьте, что заявки доходят и что мобильная версия не режет текст. Если после этого метрики всё равно в красной зоне, а бизнес зависит от поиска, вопрос переезда на нормальную CMS придётся ставить всерьёз.
Как часто перепроверять сайт на такие ошибки?
Формы — раз в неделю, это минута времени и самая дорогая проверка из всех. Скорость и метрики — раз в месяц. Полный проход по списку — раз в квартал и обязательно после каждого крупного события: обновления CMS, смены шаблона, установки нового плагина, переезда на другой хостинг. Именно после таких событий и появляется большинство скрытых дефектов, потому что никто не проверяет сайт целиком, когда «просто обновил плагин».
Коротко
- Технический дефект, который мешает человеку, автоматически становится отрицательным сигналом для поиска: конверсия и позиции падают от одной причины.
- Самые дорогие ошибки не видны глазом — мёртвая форма, контент только в скриптах, задержка отклика кнопки на мобильных.
- Базовая диагностика занимает вечер: тестовая заявка, замер трёх метрик, просмотр без JavaScript, проверка вариантов адреса, отключение виджетов по одному.
- Чинить в порядке потерь: сначала путь к заявке, потом доступность контента для робота, потом скорость и стабильность вёрстки.
- Правки делать по одной, с копией и с зафиксированными цифрами «до» — иначе результат нечем измерить.
- Конверсия отвечает сразу, полевые метрики через недели, позиции через месяц-полтора. Ждать эффекта на следующий день не нужно.
Если проверки показали проблему, но непонятно, за что хвататься первым и что из найденного вообще влияет на деньги, приходите на SEO-консультацию: разберём ваш сайт по этому же списку и составим порядок работ под вашу нишу и бюджет.
Увеличьте позиции и продажи вашего сайта
Профессиональное SEO-продвижение с гарантией результата. Выберите подходящую услугу:
Остались вопросы по продвижению?
Меня зовут Анатолий Кузнецов, я SEO-оптимизатор с 20-летним стажем. Разберу ваш сайт, отвечу на вопросы и подскажу, что улучшить для роста позиций в Яндексе и Google.
Связаться со мной →Комментарии
Ростислав Мамонтов
Проверил формы, как вы пишете, с чужой почты. Две из четырёх не дошли. Причём та, что на странице услуги, не работала минимум с весны — тогда обновляли плагин антиспама. Страшно даже считать, сколько заявок ушло в никуда за это время.
Анатолий Кузнецов автор
Ситуация типовая, и хорошо, что вы нашли её сейчас, а не через год. Посчитать потери всё-таки стоит, хотя бы грубо: возьмите конверсию рабочей формы на главной, умножьте на трафик проблемной страницы за период с весны — получите порядок цифры. Дальше сделайте две вещи. Первое: настройте запись всех обращений в базу или в таблицу, а не только отправку письмом — письмо может не дойти по десятку причин, а запись остаётся. Второе: заведите себе еженедельное напоминание на тестовую отправку с каждой формы, это буквально минута. И отдельно проверьте, не режет ли антиспам обращения по содержимому: часто под фильтр попадают сообщения со ссылками или с латиницей в тексте.
Аглая Верещагина
У нас сайт на конструкторе, доступа в код нет вообще. PageSpeed показывает 34 на мобильных, а сделать я толком ничего не могу — все настройки, которые есть, уже выкрутила.
Феликс Ознобишин
Не согласен с приоритетами. У меня сайт был технически идеальный, все метрики зелёные, а заявок как не было, так и нет. Дело не в коде, а в том, что предложение никому не интересно. Вы тут разбираете инструмент, а проблема обычно в продукте.
Анатолий Кузнецов автор
Спорить не буду: слабое предложение техникой не спасается, и я это регулярно вижу. Но статья не про то, что код заменяет маркетинг, а про то, что дефект в коде обнуляет даже сильное предложение. Разница видна по цифрам. Если у вас трафик идёт, страницы открываются, форма работает, а обращений нет — да, вопрос к предложению, ценам, доверию, а не к скорости загрузки. Если же трафик есть, но конверсия отличается втрое между устройствами или один шаблон страниц ведёт себя иначе, чем остальные, — это техника. Первое, что стоит сделать в вашем случае: посмотреть, доходят ли люди до формы вообще, через карту скроллинга и записи визитов. Если доходят и не заполняют — проблема в предложении, тут вы правы.
Милана Червонная
Отключала виджеты по одному, как в статье. Виновником оказался чат — грузил 900 килобайт при загрузке страницы. Перевела на загрузку по клику, INP с 480 миллисекунд упал до 180. Метод рабочий.
Тарас Овчинников
Отключил JavaScript, как советуете, — на карточках товара пусто, вообще ничего. Весь каталог подставляется скриптом. Разработчик говорит, что поисковики давно всё выполняют и волноваться не о чем. Кому верить?
Анатолий Кузнецов автор
Разработчик прав частично: роботы действительно выполняют скрипты, но делают это в отдельной очереди, с задержкой и с лимитом по времени. Для десятка страниц разницы не будет, для каталога в тысячи карточек — будет, и большая: часть страниц просто не дождётся своей очереди на отрисовку. Проверить спор можно фактом, а не мнением. Возьмите точную фразу из описания товара, которая есть только на этой карточке, и поищите её в Яндексе в кавычках с оператором site. Если страница не находится по собственному тексту — контент до индекса не доходит. Второй способ: посмотрите сохранённую копию карточки. Решение — серверный рендер или предварительная отрисовка для роботов; на большинстве современных фреймворков это включается настройкой, а не переписыванием проекта.
Севастьян Гладышев
Про журнал изменений — это то, чего мне не хватало. Полгода назад был провал трафика, до сих пор не знаю причину. Никто не записывал, что и когда меняли, а меняли много и одновременно.
Лукерья Пантелеева
Скажите, а сдвиг вёрстки правда так важен? У нас CLS 0,31, но визуально ничего страшного не происходит, просто картинки подгружаются чуть позже. Стоит ли из-за этого дёргать верстальщика.
Анатолий Кузнецов автор
0,31 — это втрое выше порога, при котором показатель считается хорошим, и «визуально ничего страшного» здесь как раз ожидаемое ощущение: вы знаете свой сайт наизусть и заранее ждёте, где что появится. Посетитель не знает. Он начинает читать первый абзац, и текст уезжает вниз; тянется к кнопке, а на её место встаёт баннер. Дело не в баллах, а в этих промахах. Работа верстальщика тут копеечная: проставить width и height всем изображениям и зарезервировать высоту под блоки, которые подгружаются позже. Это правка на пару часов, не переделка шаблона. Проверьте после этого не только CLS, но и конверсию мобильного сегмента — обычно она подрастает.
Ефим Задорожный
Сравнил текст мобильной и десктопной версии — разница почти в два раза. В мобильном шаблоне вырезаны блоки с характеристиками и таблица сравнения. Всё это время думал, что делаю удобнее.
Радмила Шапошникова
А как быть, если сайт делало агентство, договор закончился, доступов к части сервисов нет, а разработчик на связь не выходит? Технически всё в чужих руках, и я даже не знаю, где что лежит.
Игнат Селиванов
Заметил, что конверсия на iPhone втрое ниже, чем на Android, ровно как у вас написано. Полез разбираться — оказалось, маска телефона в форме на iOS не даёт ввести номер до конца. Год так работало.
Анатолий Кузнецов автор
Классический случай, и он же объясняет, почему я советую смотреть отчёты по устройствам и браузерам, а не общую цифру конверсии. Маски ввода — вообще отдельная больная тема: они ломаются на автоподстановке, конфликтуют с клавиатурой на iOS, режут номера в международном формате. Мой совет — отказаться от жёсткой маски совсем и вместо неё чистить введённое значение уже на стороне обработчика: человек вводит как ему удобно, а вы приводите к нужному виду сами. Заодно проверьте на iPhone остальные поля формы: дату, если она есть, и загрузку файла — там тоже регулярно всплывают сюрпризы. И запишите себе тестовую отправку с айфона в тот самый еженедельный ритуал.
Прасковья Гундарева
Про полевые данные и задержку — важное уточнение. Мы починили скорость, через неделю посмотрели, ничего не изменилось, и чуть не откатили правки обратно. Через месяц показатели позеленели.
Демьян Хлопонин
Вопрос про дубли адресов. У нас страницы открываются и со слэшем, и без — обе отдают код 200. Насколько это критично, если контент одинаковый и canonical везде прописан правильно?
Старт 
Стандарт 
Премиум 
Отличная тема. Иду искать скрытую ошибку, которая может резать мне и заявки, и позиции.
Добавлю: настройте цель в Метрике на отправку формы. Если кликов много, а целей нет, ищите ошибку в коде.
Спасибо. Иду проверять форму на телефоне и смотреть, нет ли ошибок в коде.
Полезно. Такую ошибку не видно глазом, а бьёт она сразу по двум фронтам. Надо проверять.
Через Вебвизор увидела, что люди кликают на кнопку, а ничего не происходит. Оказалась ошибка в коде.
Проверьте сайт на разных устройствах и загляните в консоль браузера. Ошибки там укажут на скрытую беду.
Такие тихие ошибки хуже явных: сайт работает, а деньги утекают, и никто не ищет причину в коде.
А как отследить, теряю ли я заявки из-за такой ошибки, а не из-за самого оффера или цены?
Владислав, отследить помогает аналитика на стыке кликов и заявок. Настройте в Метрике цель на отправку формы и на клик по кнопке заявки. Если по данным люди доходят до формы и кликают, а целей отправки почти нет, значит, теряете не на оффере и цене, а на технике — форма не срабатывает. Дополнительно смотрите Вебвизор: видно, как человек жмёт кнопку, а ничего не происходит. Если же люди уходят, не дойдя до формы, тогда дело в оффере или цене. Разрыв между кликами и успешными отправками и есть признак технической ошибки.
Ошибки в консоли браузера часто и есть та самая скрытая проблема. Открыл, а там куча красного.
Спасибо, что подсветили. Искала проблему где угодно, а она пряталась в коде.
Сломанный элемент ухудшает поведение людей, а поиск это видит и роняет позиции. Вот и связка.
А почему одна ошибка в коде бьёт одновременно и по конверсии, и по позициям? Это же вроде разные вещи.
Николай, связка через поведение людей. Сломанный элемент — форма, кнопка, скрипт — ухудшает опыт: человек не может оставить заявку или сталкивается с багом и уходит. Это напрямую режет конверсию. А поиск видит плохие поведенческие: короткие визиты, возвраты в выдачу, отказы — и трактует это как сигнал, что страница не решает задачу пользователя, из-за чего роняет позиции. То есть одна ошибка сначала бьёт по заявкам, а через испорченные поведенческие тянет вниз и позиции. Вот почему техническая исправность влияет сразу и на деньги, и на ранжирование.
У меня скрипт ошибался, и на телефонах не отправлялась форма. Нашли случайно, конверсия сразу выросла.
Одна ошибка в коде может ломать форму на части устройств, и вы даже не узнаете, почему нет заявок.
А как найти такую скрытую ошибку в коде, если я не программист и в этом совсем не разбираюсь?
Алина, даже без навыков программиста ошибку можно нащупать. Пройдите весь путь клиента на разных телефонах и браузерах: нажмите все кнопки, отправьте форму, проверьте, приходят ли заявки. Что не сработало — там и ошибка. Откройте консоль браузера, вкладку с ошибками: красные строки прямо укажут на проблему, даже если вы не поймёте код — их покажете разработчику. Плюс смотрите Вебвизор в Метрике: видно, как люди кликают, а действие не происходит. Так вы локализуете сбой без знания кода, а чинить его отдаёте технарю уже с конкретикой.
Коварная вещь. Скрытая ошибка в коде тихо резала мне и конверсию, и позиции, а я искал причину в контенте.