Найдите прежнюю задачу и сохранённую проверку после исправления. Затем сравните новый проблемный URL с тем, который тогда приняли. Одинаковое название замечания может относиться к другой странице или новому варианту шаблона.
Например, в сентябре названия обычных товаров исправили. В октябре замечание появилось у карточки с пустым названием варианта. Начните с сравнения этих двух карточек, а не с просьбы повторить прежнюю правку.
Проверьте, что раньше действительно работало
Начните с закрытой задачи. Были ли сохранены контрольные адреса, дата публикации и результат после нее? Если приемка состояла только из сообщения разработчика, фактически подтвержденного состояния может не быть. Это нужно обозначить до сравнения.
Проверьте, что новый отчет касается того же адреса. Страницы могут иметь похожие названия, но разные пути, параметры или версии. Одна новая карточка с ошибкой не доказывает возвращение проблемы на старой проверенной карточке.
Сохраните старый успешный результат с датой. Он нужен для сравнения и не исчезает из истории из-за нового сбоя. Порядок проверки работы есть в инструкции приёмки.
Сравните условия и страницы
Для технической ошибки важны URL, состояние страницы, дата, способ проверки и возможная авторизация. Для шаблонных замечаний — тип страницы и содержимое, влияющее на разметку. Сначала выясните, сравниваете ли вы одинаковые объекты.
Посмотрите охват аудитов. Если раньше проверялась одна выборка, а теперь другая, рост числа проявлений может отражать расширение наблюдения. Ежедневный автоматический обход ограничен 100 страницами подключенного сайта, поэтому отсутствие старого замечания не всегда означает отсутствие его на всех остальных URL.
Уточните и момент публикации. Новый отчет мог выполниться до изменения либо во время обновления. Если сайт отвечает разными версиями из кеша, ручная проверка и аудит могут расходиться. Пока условия не согласованы, не называйте различие подтвержденным откатом исправления.
Отправьте разработчику короткую историю
| Когда | Что проверили | Что получилось |
|---|---|---|
| 20 сентября после правки | /product/1, обычный товар | Название правильное |
| 4 октября | /product/2, пустое поле варианта | Название не заполнено |
| 4 октября | /product/1 повторно | Название по-прежнему правильное |
Добавьте другой товар с таким же пустым полем, если он уже есть. Не меняйте несколько публичных полей для эксперимента без согласования. Разработчик может повторить случай в тестовых условиях.
Попросите проверить обработку этого набора данных и связь с последним выпуском. Если причина неизвестна, так и напишите. Выбрать страницы для проверки шаблона можно по их структуре и содержимому.
Если ручной результат и аудит расходятся, приложите время и условия каждого. Сохранённая копия страницы, авторизация или другой адрес могут объяснять различие, но выбрать объяснение должен разбор, а не догадка.
Проверьте новый и прежний варианты после правки
После публикации повторите исходную контрольную проверку и исследуйте дополнительные варианты, на которых обнаружился повтор. Для шаблона это как минимум прежний адрес, новый проблемный пример и подходящая страница без исходной ошибки.
Для контрольных URL получите новый технический отчёт после публикации. Сохраните: старый товар работает, новый проблемный вариант исправлен, похожий вариант тоже проверен. Один успешный запуск не обещает, что ошибка больше никогда не появится.
Если разработчик нашёл причину, добавьте конкретное правило для следующей публикации: например, проверять товар с пустым необязательным полем после изменения шаблона. В задаче укажите исполнителя и способ такой проверки.
Если причина не установлена, оставьте её открытой вместе с нужными логами или сведениями о выпуске. Временное исчезновение после нескольких действий не показывает, какое из них помогло. Продолжите задачу с нового времени наблюдения, сохранив прежние подтверждения.