Подрядчик прислал сорок страниц отчёта и отметил задачу «метатеги категорий» выполненной. Заказчику всё равно приходится выяснять, какие URL менялись, что было согласовано и как проверить результат. Объём отчёта не сокращает эту работу.
Удобный формат приёмки помещается на одной странице. Он связывает договорённость, фактическую поставку, независимую выборку и решение. Приложения могут быть большими; на основном листе остаются данные, без которых решение нельзя воспроизвести.
Зафиксируйте исходную договорённость
Первая строка листа повторяет ожидаемый результат из задачи. Формулировка «оптимизировать категории» слишком широка. Проверяемый вариант выглядит так: «Для 320 индексируемых категорий сформировать уникальный Title по шаблону {категория} — купить в {городе}, сохранить текущие URL и self-referencing canonical».
Рядом укажите:
- идентификатор задачи и дату согласования;
- список URL либо правило формирования охвата;
- исходное состояние с датой;
- ограничения, которые нельзя нарушать;
- способ проверки и критерий готовности;
- представителя заказчика, принимающего решение.
Требование, появившееся после поставки, помечается как новое пожелание. Если в задаче отсутствовал критерий уникальности, стороны сначала согласуют дополнение и его стоимость. Такой статус защищает обе стороны от ретроспективного изменения объёма.
Заполните одностраничный лист
Шаблон ниже можно перенести в трекер, документ или таблицу. Ссылки ведут в приложения, поэтому сам лист остаётся коротким.
ЛИСТ ПРИЁМКИ SEO-РАБОТЫ
Задача / версия: __________________________________________
Ожидаемый результат: ______________________________________
Охват: ____________________________________________________
Ограничения: ______________________________________________
Поставка подрядчика
Дата и среда: _____________________________________________
Что изменено: _____________________________________________
Доказательства: [список URL] [diff] [релиз] [отчёт]
Непроверенные области: ____________________________________
Независимая проверка заказчика
Выборка и метод: __________________________________________
Пройдено: ___ из ___ URL
Найденные отклонения: _____________________________________
Побочные эффекты: _________________________________________
Поисковое наблюдение
Сегмент / метрика / база: _________________________________
Окно оценки: ______________________________________________
Решение: принять / принять с ограничениями / вернуть
Новое пожелание отдельной задачей: да / нет
Владелец следующего действия и срок: ______________________К листу прикладывают старые и новые значения, команды запросов, выгрузки и скриншоты. В лист не помещают пароли, токены и персональные данные. Доступ к рабочей среде выдаётся на минимально необходимый срок, а его отзыв становится отдельной проверяемой строкой.
Разделите поставку, реализацию и эффект
В одном статусе нельзя смешивать три разных результата.
Поставка подтверждает, что файл, настройка, контент или код появились в согласованной среде. Ссылка на pull request без выкладки не подтверждает рабочий сайт.
Корректность реализации показывает, что изменение выполняет критерий на заявленном охвате и не создаёт побочных дефектов. Canonical проверяется в HTML сейчас, редирект — по всей цепочке, новый шаблон — на разных вариантах данных.
Поисковый эффект оценивается после повторного обхода. Появление правильного canonical не гарантирует немедленный выбор той же версии поисковой системой. Рост трафика зависит от спроса, конкурентов и других изменений. Для эффекта заранее фиксируют сегмент, базовый период, метрику и окно наблюдения.
В решении можно принять техническую реализацию и оставить поисковый эффект открытым до указанной даты. Это две строки статуса, поэтому отсутствие мгновенного роста не превращает корректную поставку в дефект.
Постройте независимую выборку
Подрядчик должен передать полный заявленный охват и несколько примеров. Заказчик выбирает собственные URL внутри каждого изменённого шаблона: обычный, новый, старый, с граничными данными и с допустимыми параметрами. Выборка только из презентации проверяет демонстрационные примеры.
Для массовых индексирующих директив, миграций и редиректов разумна полная автоматическая перепроверка. При изменении редиректов сохраните старый адрес, каждый переход, конечный статус и соответствие конечной страницы; последовательность есть в статье как проверять редиректы.
Если один URL из шаблона не проходит, увеличьте выборку в этой группе и найдите механизм. Ошибка данных одной записи и дефект общего генератора требуют разного решения. В листе фиксируются размер выборки, способ выбора и число отклонений, например «2 из 12 карточек; обе без бренда в исходных данных».
Побочные эффекты проверяются рядом с целевой функцией. Новый Title не должен дублироваться на всём разделе, смена URL — создавать цепочки, удаление параметров — ломать фильтры, ускорение шаблона — скрывать основной текст. Подсказки для проверки метода собраны в статье про ошибки SEO-аудита.
Уточните границу технического аудита
Независимый технический срез включает конечный HTTP-статус, исходный HTML, Title, meta robots, canonical, H1, основной текст, внутренние ссылки и структурированные данные в пределах задачи. Для JavaScript-сайта отдельно проверяют DOM после выполнения сценариев. Аудитор сохраняет URL, время, user-agent и фактический ответ.
Технический аудит может стать одним приложением к листу, поскольку фиксирует публичное состояние на момент запуска. Договорные требования, исходную версию, закрытый стенд и заявленный подрядчиком охват всё равно проверяет заказчик.
Недоступная проверка остаётся в статусе «не проверено» с причиной: нет прав, закрыт стенд, истёк доступ, ответ нестабилен. Пустую ячейку нельзя трактовать как отсутствие дефекта. Если подрядчик использовал иной инструмент, в приложении нужны версия правил и дата выгрузки.
Оформите замечание как воспроизводимый факт
Фраза «метатеги сделаны плохо» не даёт исполнителю точку исправления. Строка замечания содержит URL, ожидаемое и фактическое состояние, метод, время, влияние и приоритет:
URL: https://example.ru/catalog/chairs/model-7
Ожидалось: canonical на чистый URL карточки
Получено: canonical на /catalog/chairs
Проверка: исходный HTML, 2026-08-14 12:40 MSK
Выборка: тот же дефект на 3 из 5 карточек без бренда
Влияние: поисковый сигнал объединяет карточки с категорией
Повтор: после исправления проверить все карточки без брендаОтдельно классифицируйте расхождение. Дефект нарушает согласованный критерий. Недопоставка оставляет часть согласованного охвата без изменения. Ограничение было известно и явно принято. Новое пожелание расширяет прежнюю задачу. Для повторной проверки укажите версию исправления и срок.
Регулярную отчётность можно строить по схеме еженедельного SEO-отчёта, добавляя связь каждой строки с задачей и листом приёмки.
Зафиксируйте решение одной строкой
На листе остаётся одно из трёх решений по исходной работе: принять, принять с перечисленными ограничениями или вернуть на исправление. Новые пожелания выносятся отдельно. Подпись подтверждает факты и границы решения; она не обещает будущий поисковый рост.
Заполненный блок может выглядеть так:
Решение: вернуть на исправление
Основание: canonical неверен на 3 из 5 карточек без бренда
Охват повторной проверки: все 46 карточек без бренда + 5 соседних
Исполнитель: подрядчик, версия fix-2
Срок выкладки: 16 августа, 14:00 MSK
Повторная проверка: заказчик, 16 августа, 16:00 MSK
Поисковое наблюдение: выбранный Google canonical и показы сегмента,
контрольная дата 30 августа