После сообщения «Всё исправили» вернитесь к адресу и действию, на которых возникла проблема. Если не открывалась запись на приём, работающая главная ещё не подтверждает восстановление. Если форма не доставляла заявку, нужно получить подтверждение её адресата.
Проверяйте основной домен после публикации исправления. Затем сопоставьте ручной результат с новыми проверками reChecker и запишите, что именно подтвердили. Необязательно ждать полного объяснения причины, чтобы подтвердить, что страница сейчас работает.
Сформулируйте, что должно снова работать
Возьмите исходное обращение. В нём должны быть адрес, действие и ожидаемый результат. Если там только «сайт сломан», уточните, что видел посетитель, прежде чем закрывать работу.
Пример: страница /appointment открывалась, но отправка заявки заканчивалась ошибкой. Для восстановления нужно, чтобы поля приняли данные, отправка прошла и сотрудник получил заявку по реальному маршруту сайта. Успешное открытие /appointment подтверждает лишь первый шаг.
Другой случай — вместо каталога показывалась техническая заглушка. Даже нормальный ответ сервера здесь недостаточен: посетитель должен увидеть каталог. Проверяйте содержание и переходы, относящиеся к исходной проблеме. Состав ручного пути описан в статье о работающем сайте и неработающем заказе.
Проверьте опубликованную версию в прежних условиях
Уточните у исполнителя время исправления и выполненное действие. Если вернули старую версию, это тоже нужно записать. Ответ «исправили на тестовом сайте» ещё не относится к основному домену.
Откройте исходный адрес с теми же условиями, где ошибка повторялась: устройство, сеть, вход в аккаунт. Если условия неизвестны, укажите свои. Не делайте по одной попытке вывод о работе для всех посетителей.
Для формы или заказа подготовьте согласованные тестовые данные и предупредите получателя. После сообщения об успехе проверьте итог там, где компания принимает обращения. Если этот этап может увидеть только менеджер, попросите его подтвердить конкретную запись.
Если у вас всё работает, а посетитель всё ещё получает ошибку, сохраните обе попытки с временем и условиями. Передайте расхождение исполнителю. Не называйте его автоматически проблемой кеша — сохранённой старой копии страницы — без проверки.
Сверьте результаты с новыми проверками reChecker
В кабинете контроля сайта посмотрите ответы после исправления. Проверьте дату: старый успешный результат до публикации не подтверждает новую версию.
Доступность проверяется по пятиминутному плану. Несколько успешных запросов показывают ответы в эти моменты, а не гарантируют непрерывную работу. Если ошибка возвращается, добавьте новый случай; прежняя успешная попытка остаётся полезным фактом.
Контроль важной страницы по адресу и ожидаемому тексту не проходит весь путь клиента. Используйте его для ответа страницы, а отправку заявки проверяйте отдельно. Если мониторинг и браузер расходятся, сначала сравните точный адрес и время, затем передайте сведения исполнителю.
Запишите проверенное и оставшееся открытым
Вместо «всё протестировали» сохраните короткую таблицу. Ниже учебный пример для формы записи:
| Проверка после исправления | Результат |
|---|---|
| /appointment на телефоне, 04.10 в 16:20 МСК | Открывается, поля доступны |
| Отправка согласованной тестовой заявки | Показано подтверждение |
| Получение сотрудником, 16:23 | Менеджер нашёл заявку с нужными данными |
| Следующая проверка доступности | Нормальный ответ |
| Причина прежнего отказа | Разработчик ещё проверяет логи |
Здесь восстановление проверено, а исследование причины продолжается. Это два отдельных результата. Если получение сотрудником неизвестно, не ставьте в строке «успешно»: назначьте человека и время проверки.
Сохраните выполненное изменение и номер обращения. Для повторного случая пригодится именно эта запись, а не вся переписка. Порядок проверки технических правок есть в статье об исправленных ошибках.