В первом аудите было больше замечаний, чем во втором. На первый взгляд сайт улучшился. Но второй запуск мог проверить другой набор URL, остановиться на меньшем объёме или не получить проблемный раздел. Снижение общего числа замечаний в таком случае не доказывает исправления.
Сначала сопоставьте состав страниц, затем конкретные проверки. Для этого полезна отдельная рабочая таблица. Она не является обещанием специальной кнопки или встроенного экспорта reChecker: подготовьте её вручную по доступным результатам. Ниже разобран учебный пример двух обходов каталога после изменения меню.
Сохраните условия обоих запусков
Для каждого аудита запишите дату, объект, тип проверки, фактически обработанные страницы и известные ограничения. Название пакета отдельно от результата: пакет до 100 страниц не подтверждает успешное получение всех адресов. Необнаруженные URL и страницы с ошибкой обработки требуют своих отметок.
Уточните способ проверки: исходный ответ или доступное состояние после рендеринга, режим устройства, если он относится к измерению, и применённые настройки. Результаты разных методов нельзя механически вычитать. Изменение способа чтения страницы способно изменить набор замечаний без правки самого сайта.
Если между запусками изменился состав инструмента или методика оценки, сохраните это как ограничение сравнения. Можно сопоставить отдельный HTTP-ответ, но общие баллы уже могут отвечать на разные наборы вопросов. Не называйте такие оценки полностью совместимыми без подтверждения условий.
Соберите адреса без потери различий
Перенесите URL двух запусков в две колонки. Сохраняйте исходные значения рядом с рабочими: при расследовании понадобится установить, какой адрес действительно запросили. Исправляйте очевидные ошибки копирования, но не удаляйте все параметры или языковые префиксы ради одинаковых строк.
В учебном каталоге /chairs/?color=blue и /chairs/?color=red могут показывать разные наборы товаров. Их объединение без проверки сделает сравнение ложным. Аналогично мобильный поддомен, региональный раздел или URL варианта товара нельзя считать прежней страницей только по похожему названию.
Для действительно переехавших документов заведите явное соответствие «старый адрес → новый адрес» и основание решения. Проверка редиректа помогает подтвердить маршрут, а чтение конечной страницы — назначение. Сходство пути без проверки содержания ещё не устанавливает преемственность.
Разделите пересечение и изменение выборки
Пусть первый учебный обход обработал десять URL, второй — двенадцать. В обоих присутствуют восемь адресов. Два прежних не вошли во второй запуск, а четыре появились впервые. Сравнимые наблюдения находятся прежде всего на восьми общих страницах.
Это не означает, что остальные адреса не важны. Новые страницы требуют первичной проверки, а исчезнувшие — выяснения причины отсутствия. Просто их состояния нельзя использовать как доказательство исправления прежнего замечания без дополнительных данных.
| Группа учебного примера | Допустимый вывод | Следующее действие |
|---|---|---|
| Восемь общих URL | Можно сравнивать доступные одинаковые проверки | Сопоставить замечания по странице и условию |
| Два URL только в первом запуске | Повторное состояние неизвестно | Проверить обнаружение, лимит и текущий ответ |
| Четыре URL только во втором | Получены новые наблюдения | Оценить отдельно от прежних исправлений |
Числа здесь условные. В реальном документе подставляют фактические списки, а не ожидаемое количество из настроек пакета.
Сравнивайте замечание вместе с конкретной страницей
Ключ рабочей строки — URL и проверяемое условие. Например: «на карточке A ссылка изображения отвечает 404». Если во втором запуске на карточке A получен доступный файл по исправленному адресу, есть основание подтвердить результат для этой карточки.
Однако исчезновение общего раздела «битые изображения» может означать другое: страница не получена, изображения не извлечены или проверка не выполнялась. Посмотрите детали и ограничения. Пустой список после сбоя не равен положительному результату.
Условие тоже должно совпадать. Ответ изображения и наличие корректного alt — разные проверки; исправление одного не подтверждает другое. Для постановки и приёмки тематических задач пригодится руководство по техническому аудиту, но решение принимают по конкретным наблюдениям пары запусков.
Используйте «не проверено» как полноценное состояние
В таблице заведите отдельные значения: подтверждённая проблема, подтверждённое выполнение условия, ошибка получения и отсутствие проверки. Не сводите всё к двум цветам. Иначе неизмеренная страница попадёт в колонку исправленных только потому, что в новом документе нет прежней строки.
Для двух исключённых URL учебного примера сначала выясните, доступны ли они сейчас. Один мог быть удалён по согласованному решению, другой — остаться действующим, но не обнаружиться из нового меню. Это разные события: первое требует проверки судьбы адреса, второе показывает пробел повторной выборки.
Если задача предусматривала исправление действующей карточки, её исчезновение из обхода не закрывает задачу. Запустите подходящую повторную проверку этого адреса и сохраните результат. Не заменяйте доказательство словами «инструмент больше не жалуется».
Учитывайте предел пакета и границы обнаружения
Смена меню, sitemap или структуры ссылок способна изменить порядок обнаружения страниц. При ограниченном пакете в выборку попадут другие URL. Поэтому два запуска с одинаковым максимальным объёмом могут иметь разный состав даже без изменения настроек.
Ежедневный аудит подписки reChecker рассчитан на объём до 100 страниц сайта. Ручные полные аудиты предлагают пакеты до 25, 100, 500 и 1 000 страниц. Ни один из этих пределов не подтверждает полного покрытия произвольного каталога.
Для важного исправления заранее сохраните контрольные URL во внешнем листе приёмки. Повторите доступные проверки выбранных объектов после релиза. Активная оплаченная подписка снимает месячный лимит числа включённых ручных локальных запусков, но сохраняет объём пакета и максимум трёх одновременных активных полных заданий.
Представьте итог без ложной арифметики
В сводке отдельно покажите подтверждённые исправления на общих страницах, новые проблемы на общих страницах, новые URL и неизвестное повторное состояние. Такая запись полезнее одной разницы суммарных замечаний. Она объясняет, какая часть изменения связана с составом обхода.
Учебная формулировка может звучать так: «На восьми общих страницах сопоставили одинаковые условия. По двум прежним URL повторных данных нет; четыре новые страницы рассмотрены отдельно». Затем перечислите фактические подтверждения без выдуманного числа успешных исправлений.
Если показываете общий балл, поясните его ограниченную роль. Рост оценки не доказывает рост трафика, удобства всех пользовательских сценариев или качества непроверенных разделов. Разделение выводов помогает выбрать приоритеты аудита на следующий цикл.
Подготовьте следующую пару запусков заранее
После сравнения сохраните согласованную контрольную выборку и условия. Добавьте представительные страницы изменённого шаблона, действующие соседние URL и нужные пограничные состояния. Не ограничивайтесь одной удачной карточкой, если исправление затрагивает весь импорт.
Назначьте повторный запуск после фактической публикации изменений и обновления соответствующего кеша. При новом расширении каталога добавляйте отдельную группу первичных наблюдений, сохраняя прежнюю группу для сравнения. Так рост проекта не будет маскироваться под улучшение или ухудшение старых страниц.
Для регулярного процесса используйте контроль сайта. Сопоставимость создаётся сохранёнными условиями и доказательствами, а не одинаковым названием отчёта. Она позволяет честно закрывать исправления и одновременно видеть, где данных пока недостаточно.