Образец документа
Реестр технических проблем: находки, превращённые в задачи для разработчика
Каждая строка реестра написана так, чтобы разработчик, который не читал аудит, взял её, воспроизвёл проблему, починил и доказал, что задача закрыта. В этом и разница между отчётом и работой, которая доходит до релиза.
Пример, а не данные клиента
Обстановка вымышленная: контентный сайт на распространённой системе управления, недавно переехавший на новую платформу, одна общая среда для тестов и команда разработки, которая выкатывает раз в неделю. Все адреса ведут на example.com. Реального клиента и реального бэклога здесь нет.
Из чего собрана строка
Задача, с которой можно спорить, это задача, которую делают. Каждая колонка убирает одну из причин, по которым работа застревает между аудитом и релизом.
- ID: устойчивая метка, чтобы одна и та же проблема сохраняла имя в бэклоге, в описании релиза и в контрольном обходе после него.
- Серьёзность: критическая означает, что проблема блокирует обход, отрисовку или индексацию. Высокая ухудшает то, как страницу читают. Средняя это гигиена, которая может подождать планового релиза.
- Доказательство: самый короткий путь увидеть проблему своими глазами, написанный для того, кто не читал аудит.
- Критерий приёмки: наблюдаемое состояние, а не намерение. Либо критерий выполнен на боевом сайте, либо задача остаётся открытой.
- Владелец: кто выкатывает. Часть строк мы закрываем сами в рамках выданного доступа, часть принадлежит команде разработки, а часть требует участия обеих сторон.
Реестр
| ID | Проблема | Серьёзность | Доказательство | Критерий приёмки | Владелец |
|---|---|---|---|---|---|
| T-01 | Директива, закрывающая обход на тестовой среде, живёт на боевом хосте | Критическая | Открыть файл robots на example.com и поискать правило, которое запрещает весь сайт | Боевой robots открывает публичные разделы, а запрещающее правило есть только на тестовой среде | Мы, хостинг подтверждает |
| T-02 | Текст на шаблоне услуги появляется только после гидратации | Критическая | Запросить страницу с выключенным JavaScript и поискать первый абзац в исходном ответе | Первый абзац есть в исходном HTML ответе на каждой странице услуги | Разработчик клиента, задание наше |
| T-03 | После части релизов на индекс блога возвращается тег noindex | Критическая | Сравнить содержимое head на индексе блога между двумя последними выкладками | Два релиза подряд проходят без этого тега, и за ним следит правило отслеживания изменений | Мы вместе с разработчиком клиента |
| T-04 | Страницы пагинации категорий канонизируются на первую страницу | Высокая | Открыть вторую страницу любой категории и прочитать элемент canonical | Каждая страница пагинации канонизируется сама на себя, а ссылки пагинации остаются доступны обходу | Разработчик клиента, задание наше |
| T-05 | Старые адреса товаров доходят до цели через два перехода редиректа | Высокая | Запросить старый адрес товара и пройти цепочку до конца | Каждый старый адрес доходит до цели одним постоянным редиректом | Мы |
| T-06 | У одного языка нет обратных ссылок в наборе hreflang | Высокая | Сравнить блок hreflang на паре страниц в обоих языках | Каждая языковая пара ссылается друг на друга и на себя, а набор проходит проверку | Мы |
| T-07 | Удалённая страница отвечает обычным статусом и оформленным шаблоном | Высокая | Запросить адрес удалённого товара и прочитать код ответа | Удалённые адреса отвечают статусом «не найдено» или «удалено», а шаблон не индексируется | Разработчик клиента |
| T-08 | Параметры фильтров создают доступные обходу адреса, которые никто не ищет | Высокая | Обойти одну категорию и выписать варианты параметров, до которых можно дойти по ссылкам | Доступными обходу и индексации остаются только комбинации, названные в согласованной политике параметров | Мы вместе с разработчиком клиента |
| T-09 | Разметка хлебных крошек подставляется после загрузки страницы | Средняя | Поискать тип разметки хлебных крошек в исходном ответе страницы товара | Разметка есть в исходном HTML и проходит проверку без предупреждений | Разработчик клиента, задание наше |
| T-10 | В карте сайта есть адреса, которые редиректят или закрыты от индексации | Средняя | Взять выборку адресов из карты сайта и проверить статус каждого | Карта сайта собирается из живого индексируемого набора и пересобирается при публикации | Разработчик клиента, задание наше |
| T-11 | Запросы робота концентрируются на адресах с параметрами, а не на страницах категорий | Средняя | Прочитать логи доступа за неделю и сгруппировать запросы по шаблону адреса | Политика параметров работает, и то же окно логов читают повторно, чтобы увидеть, как сместилось распределение | Мы |
Порядок работ
Порядок задаёт то, что разблокирует остальное, а не то, как быстро строку можно закрыть. Быстрая починка, которая зависит от неисправленного блокера, теряется дважды.
- Сначала всё, что мешает странице быть обойденной, отрисованной или отданной правильно. Пока это открыто, остальное нечем измерить.
- Затем правила, которые решают, что попадает в индекс: canonical, пагинация, параметры, коды ответа.
- Затем разметка и детали доставки, которые меняют подачу страницы, когда её уже читают правильно.
- В последнюю очередь мониторинг, который не даёт первым трём тихо вернуться на очередном релизе.
Правила безопасного внедрения
- Каждая правка сначала уезжает на тестовую среду, и её обходят до того, как кто-то трогает боевой сайт.
- Один класс изменений на релиз. Правило canonical и карта редиректов, выехавшие вместе, потом неразделимы, если что-то сдвинулось.
- У каждой задачи есть откат: прежнее правило, файл или шаблон, положенные туда, откуда ваша команда восстановит их без нас.
- Изменения, которые влияют на состав индекса, клиент подтверждает письменно, в самой задаче, до релиза.
- Доступ выдаётся под задачу и отзывается по закрытии спринта. Мы не просим прав администратора, которые нам ни для чего не нужны.
- После релиза мы делаем контрольный обход и сравниваем его с тем, что снят до, чтобы починка, сломавшая соседнее, стала видна сразу.
Что проверяем после каждого релиза
- Сам критерий задачи, причём на боевом сайте, а не на тестовой среде.
- Исходный HTML затронутых шаблонов, потому что правка, которая видна только после выполнения JavaScript, по сути ещё не доехала.
- Коды ответа и редиректы для тех наборов адресов, которые релиз затронул.
- Покрытие и сигналы обхода в Search Console в следующие недели, потому что платформа отражает изменение по своему расписанию.
Вымышленный пример, не данные клиента
- Реестр здесь короткий и аккуратный. Настоящий длиннее и хранит ещё и строки, которые оказались не проблемой, с пометкой почему.
- Серьёзность назначают относительно того сайта, которому строка принадлежит. Одна и та же строка бывает критичной на одном проекте и средней на другом.
- Ничего в этом образце не измерено. В настоящей задаче в колонке доказательства названы файлы, адреса и окна логов.
- Колонка владельца следует модели доступа, согласованной на старте. Там, где всё выкатывает ваша команда, значения читаются иначе.
Настоящий реестр отдают как рабочий бэклог: задачи, которые ваша команда импортирует к себе, техническое задание на каждую строку и обход после релиза, закрывающий каждую задачу по её собственному критерию. Состав спринта описан на странице услуги.
Technical SEOГотовы отдать настройку нам?
Расскажите, что у вас есть сейчас. Объём и фиксированную цену подтверждаем до начала работ, все доступы остаются у вас.
Начать настройкуБез обязательств. Ответ в течение одного рабочего дня.