После публикации правки добавляйте одну строку: когда выпустили, что изменили, какие страницы затронули и что получилось при проверке. Такой журнал можно вести в вашей таблице или задачнике.
Допустим, 4 октября в 11:00 МСК разработчик изменил меню, в 11:20 владелец нашёл неверную ссылку, в 12:00 её исправили. Эти времена помогут восстановить ход работы. Момент обнаружения ошибки записывайте отдельно от времени её возникновения, если последнее неизвестно.
Заполните запись сразу после публикации
| Поле | Пример |
|---|---|
| Публикация | 04.10, 11:00 МСК, основной example.ru |
| Изменение | Новый пункт «Доставка» в общем меню |
| Адреса для проверки | Главная, /catalog, /product/1 |
| Исполнитель | Сергей, задача №17 |
| Результат | В 11:20 ссылка ведёт на /old-delivery; передано исправление |
| Повтор | В 12:10 на трёх страницах открывается /delivery |
Для обычного текста может хватить даты. Для серверной настройки или короткого сбоя укажите время и часовой пояс. Записывайте выпуск на основном сайте, а не завершение разработки на компьютере исполнителя.
Отмечайте изменения, которые влияют на проверку
В журнал стоит включать публикацию новой версии, смену основного адреса, изменение редиректов, массовую редактуру и настройки кеша. Отдельно отмечайте изменения региона, набора поисковых запросов и вопросов для ИИ. Они влияют на то, какие данные вы сравниваете.
Не превращайте журнал в полный пересказ рабочего чата. Обсуждение дизайна, которое не привело к публикации, можно оставить в задаче. Для контроля важен момент, когда измененное состояние стало доступно посетителю или проверяющему сервису.
Например, запишите «с 5 октября смотрим Тулу вместо Москвы». Без этой записи изменение позиций можно ошибочно связать с правкой страницы.
Проверьте адреса из записи
Фраза «исправили SEO» бесполезна для приемки. Нужен наблюдаемый результат: изменен заголовок страницы, исправлен ответ адреса, удалена неправильная ссылка. Для массовой работы запишите правило и несколько контрольных URL.
После релиза откройте эти адреса вручную. Затем сверьте их с подходящим новым аудитом. Если страница не попала в его охват, отсутствие ошибки в списке не подтверждает исправление именно на ней. При необходимости выберите отдельную проверку с подходящим объемом.
Последовательность подробнее в инструкции после релиза. Для каждого повторного результата сохраните дату и адрес. В кабинете мониторинга уточните, завершился ли отчёт после публикации и исследовал ли эти страницы.
Используйте журнал при разборе повторной ошибки
Найдите последний выпуск перед обнаружением проблемы и откройте записанные URL. Сравните условия: тот же адрес, состояние авторизации, вариант страницы и дата. Затем попросите разработчика проверить соответствующее изменение и нужный интервал логов.
Совпадение по времени ещё не устанавливает причину. Например, новый аудит мог впервые обойти старую страницу с ошибкой. В задаче пишите «замечено после обновления меню», пока исполнитель не подтвердил связь. Разбор такого факта есть в руководстве по проверке замечания.
Раз в неделю найдите записи, где публикация есть, а повторного результата нет. Назначьте проверку или запишите, что ей мешает. Завершённые строки оставьте со ссылками в архиве своего документа.
При передаче сайта коллеге попросите его восстановить одну работу по журналу: найти первоначальную проблему, публикацию и проверку. Если нужное время или URL приходится выяснять в чате, дополните именно это поле. Не увеличивайте таблицу сведениями, которые никто не будет заполнять.