Сменили версию ПХП на хостинге — форма заявок молча перестала отправляться

Эта история началась с самого безобидного письма от хостинг-провайдера: «Рекомендуем перейти на более новую версию ПХП, это ускорит сайт и повысит безопасность». Владелец небольшой компании по ремонту и отделке нажал кнопку в панели управления, увидел «Готово» и вернулся к работе. Версия ПХП на хостинге сменилась за минуту, сайт открывался, страницы выглядели как прежде. Только форма заявок молча перестала отправлять письма, и никто этого не заметил. Расскажем, как это выглядело, сколько обращений было потеряно и что мы изменили, чтобы такое не повторилось.

С чего всё началось

Компания занималась отделкой квартир и небольших коммерческих помещений. Сайт работал на ХостСМС около четырёх лет, обращения шли из трёх источников: из поиска, из карточек в Яндекс Бизнесе на Яндекс Картах и из 2ГИС. Заявки с сайта приходили на почту и дублировались в Битрикс24, откуда менеджер звонил клиентам. Звонки с карточек шли напрямую на офисный телефон, и их учитывала система с подменой номеров.

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

После смены версии он открыл главную страницу, пролистал, убедился, что фотографии на месте, и закрыл вкладку. Форму не проверял: зачем, если она «просто форма». Это и стало первой ошибкой, самой человеческой и самой дорогой.

Как ошибка осталась незамеченной

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

Дальше сработала «маскировка» естественными причинами. Обращения с сайта упали, но звонки с карточек на картах продолжали идти, и общая картина выглядела просто как небольшой спад. Руководитель решил, что в этот период люди берут паузу. Менеджер удивлялся, что давно не было ни одной новой сделки в Битрикс24, но уверенно объяснял это сезонностью. Подрядчик не заходил на сайт, потому что его никто не просил.

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

Как нашли причину

Тревогу поднял клиент, а не система. Женщина, которая планировала ремонт, позвонила в офис и сказала: «Я оставила заявку на сайте три недели назад, мне никто не перезвонил, вы вообще работаете?» Менеджер ответил, что заявки не было. Клиентка прислала скриншот письма-подтверждения, которое выводил сайт. Вот тут у менеджера возникло неприятное подозрение, и он позвонил нашему специалисту.

Проверка заняла полчаса. Мы отправили тестовую заявку со своего телефона: сообщение на экране появилось, письма на почте нет, в Битрикс24 тоже ничего. Заглянули в журнал ошибок хостинга и увидели целую простыню одинаковых строк, начинавшихся примерно в день смены версии ПХП. Каждая отправка формы заканчивалась сбоем в одном и том же месте обработчика.

Причина оказалась типичной: устаревшая функция в старой самописной вставке, которую когда-то добавили для красивого сообщения об успехе. В новой версии она больше не поддерживалась. Основное ядро ХостСМС и стандартные компоненты работали без нареканий, они обновляются вместе с системой. Но в сайте накопились «личные доработки» разных лет, и именно одна из них сломалась. Чинить пришлось недолго: код переписали на современный, а в качестве запасного пути добавили запись заявки в базу данных до отправки письма.

Что потеряли

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

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

Ущерб состоял не только из денег. Часть людей, получивших звонок «через три недели», были раздражены и недоверчивы. Для компании, у которой в карточках на картах стоят хорошие отзывы, потеря репутации оказалась дороже потерянных заявок. Если бы форма дублировалась письмом и записью в базу данных, а контроль срабатывал в тот же день, потери удалось бы удержать в пределах одного-двух обращений.

Почему это произошло: разбор причин

Первая причина — отсутствие проверки после работ на хостинге. Смена версии ПХП, переезд на другой тариф, обновление системы управления сайтом или плагинов считаются техническим действием, а не изменением, влияющим на заявки. Хотя именно оно может задеть форму быстрее, чем любое изменение дизайна. Никто не поставил себе правило «после любой работы отправлять тестовую заявку».

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

Третья причина — единственный путь доставки. Заявка шла только письмом, без дубля в базу данных или резервного канала. Когда письмо не уходит, заявка исчезает навсегда. Четвёртая — цель в Метрике, настроенная на нажатие кнопки. Она показывает намерение, а не результат, и потому не заметила разрыва. Пятая — никто не отвечал за контроль. Подрядчик решал вопросы по мере обращения, менеджер полагался на то, что «если что, скажут», владелец доверял кнопке «Готово».

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

Что мы изменили, чтобы это не повторилось

Начали с надёжности самой формы. Теперь каждая заявка сначала записывается в базу данных ХостСМС и только после этого отправляется письмом и передаётся в Битрикс24. Если письмо не ушло, заявка остаётся в списке «не доставленных», и менеджер видит её в административной части с красной пометкой. Сообщение посетителю выводится после подтверждения от сервера, а не сразу при нажатии кнопки. При сбое посетитель получает честный ответ с просьбой позвонить по телефону, а не бодрое «спасибо» в пустоту.

Затем настроили дублирование каналов: помимо почты, уведомление о новой заявке приходит в рабочий чат в Телеграм или Макс. Если одно уведомление потерялось, второе покажет, что обращение есть. Для критичных случаев добавили автоматическое письмо о сбое отправки на адрес администратора: форма сама сообщает, что не смогла доставить заявку.

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

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

Правила работ на хостинге

Мы записали для клиента короткий порядок, который теперь действует при любых работах. Перед сменой версии ПХП, тарифа или переноса сайта делается резервная копия сайта и базы данных. Версия меняется на тестовой копии сайта, если хостинг даёт такую возможность (Бегет, Таймвеб и Рег.ру её дают), и только после проверки переносится на рабочий. После смены обязательно проверяются форма заявок, заказ звонка, запись на замер, чат Живосайта, подмена номера Коллтач или Каллибри.

Проверка включает отправку тестовых заявок с компьютера и с телефона, подтверждение того, что письмо пришло, а заявка появилась в Битрикс24 или амоСРМ, и просмотр журнала ошибок хостинга за последний час. Только после этого работа считается принятой. Если что-то не так, версию возвращают на прежнюю, пока доработки не будут готовы. Откат занимает минуту, а потерянные заявки не возвращаются никогда.

Отдельно договорились о плане обновления доработок. Все «личные» вставки в сайте описаны в простой таблице: что делает, когда добавлена, какие версии поддерживает. Перед каждым обновлением версии ПХП специалист просматривает этот список и проверяет код. Старый код либо обновляется, либо заменяется стандартными возможностями ХостСМС, которые разработчики системы поддерживают вместе с новыми версиями.

Как это связано с продвижением «3 в 1»

Эта история хорошо показывает, почему мы говорим об обращениях со всех каналов вместе. Звонки с карточек в Яндекс Бизнесе шли исправно, и именно поэтому поломка формы три недели оставалась незаметной: общая картина «просела, но не рухнула». Если считать отдельно каждый канал, расхождение видно сразу. Поэтому в подходе «3 в 1» мы смотрим на поиск, Яндекс Справочник с Яндекс Картами и 2ГИС как на три источника обращений и сравниваем их между собой.

Первый канал — поиск: поисковое продвижение и ГЕО. Реклама в Яндекс Директе и органический поиск приводят посетителей на сайт, и каждый из них должен получить исправную форму. Быстрая диагностика в таких случаях помогает Яндекс.Вебмастер и Метрика. Второй канал — Яндекс Карты: кроме номера телефона, в карточке стоит ссылка на сайт, и человек, пришедший оттуда, ждёт работающей кнопки. Третий — 2ГИС, где пользователь нередко звонит прямо из приложения, но часть людей идёт на сайт, чтобы посмотреть примеры работ.

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

Чему учит этот случай

Главный вывод: любое изменение на хостинге — это изменение, которое может затронуть заявки. Мы привыкли считать обновление версии ПХП чем-то вроде замены лампочки, но на самом деле это замена основы, на которой работает весь код сайта. Особенно уязвимы старые самописные вставки и подключаемые дополнения, которые давно никто не обновлял. В основной системе ХостСМС такой риск ниже, потому что разработчики сопровождают её совместно с новыми версиями ПХП, но риск остаётся там, где добавлено что-то своё.

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

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

Короткий чек-лист на каждый день и на каждую работу

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

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

Выводы и бесплатная консультация

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

Специалисты компании «Сайты Профессионально» готовы бесплатно проверить, как у вас устроена доставка заявок: пройдёт ли тестовое обращение до почты, чата и системы учёта, есть ли запасные пути, не лежат ли на сайте старые вставки, которые сломаются при следующем обновлении. Заодно посмотрим, как связаны сайт, Яндекс Бизнес и 2ГИС в подходе «3 в 1». Оставьте заявку, и мы проведём консультацию без оплаты.