SEO-аудит с перекрёстной проверкой

В SEO-аудите модель ошибается двумя способами: выдумывает находку, которой на сайте нет, и раздувает мелочь до «критично». Скилл ставит между отчётом и починкой проверку: каждую находку подтверждает или снимает критик, который смотрит на живой сайт и не знает автора отчёта.

Роли

Что нужно до начала

• Адрес сайта и его исходники в git.
• Сеть у агентов: проверка идёт запросами curl к живому сайту.
• Выгрузка Search Console за три месяца, если у владельца есть доступ. Владелец экспортирует её сам.

Ход

1. Зафиксировать снимок

Записать адрес сайта, коммит исходников и дату. Все аудиторы и критики работают по одному снимку. Без него находку «устарела» нельзя отличить от находки «неверна».

2. Собрать отчёты

Запустить параллельно от двух до пяти аудиторов seo-reviewer; когда аудит сравнивает модели — по одному на модель, сколько бы их ни было. Задание одно на всех, слово в слово:

Проведи SEO-аудит сайта <адрес> и найди топ-10 ошибок.
Исходники: этот репозиторий, коммит <sha>.
Проект не меняй: без файлов, коммитов, пушей и PR.

Независимость дают разные модели или отдельные сессии: аудиторы отчётов друг друга не видят. Одинаковое задание важнее хитрого промпта, потому что только так отчёты можно сравнить.

Оркестратор сохраняет каждый отчёт файлом во временной папке вне репозитория сайта.

3. Обезличить

Переименовать отчёты в A.md, B.md и дальше. Убрать из текста имя модели и подписи. Таблицу «буква → автор» оставить у оркестратора: критикам она не нужна.

4. Слепая проверка

Запустить двух критиков blind-critic независимо друг от друга. Каждый получает все отчёты, текст задания из шага 2, адрес сайта, коммит и выгрузку Search Console, если она есть. Критик сводит находки в один список без повторов, проверяет каждую и ставит ей вердикт и вред. Значения вердикта и вреда стоят в blind-critic.

5. Свести вердикты

6. Показать владельцу

Один список находок: суть, класс и предложенная правка из отчёта аудитора, вред и доказательство от критиков. Вред у критиков разный: стоят оба значения. Ложные находки идут отдельной короткой таблицей с причиной. Перед показом список находок проходит tufte. Что из него чинить, решает владелец.

7. Починить

Три PR; кроме журнала, их файлы не пересекаются, поэтому их можно вести параллельно:

PR собраны по файлам, которые они трогают, поэтому с классами находок совпадают частично: canonical из класса «Индекс» чинится в PR шаблонов, тонкие страницы — в PR содержания, lastmod из класса «Разметка и даты» — в PR индекса вместе с sitemap.

Каждый PR дописывает журнал docs/seo-changelog.md: дата, что изменили, по какой находке, чем проверить. Конфликт в журнале решают так: остаются обе записи.

## 2026-11-09

- Добавили canonical на страницы раздела `/guides/`. Находка 3.
  Проверка: `curl -s https://example.com/guides/first/ | grep -io '<link rel="canonical"[^>]*>'`

Через месяц журнал сопоставляют с графиком Search Console: видно, какая правка что дала. Каждый PR проходит ревью uncle-bob, новые и переписанные тексты страниц проходят ilyakhov.

8. Проверить после выкладки

Повторить проверку из доказательства каждой починенной находки. Результат записать в журнал рядом с правкой.

Четыре класса находок

Команды проверки:

curl -sI https://example.com/page/
curl -sIL https://example.com/old/ | grep -Ei '^(HTTP|location)'
curl -s https://example.com/robots.txt
curl -s https://example.com/sitemap.xml | grep -c '<loc>'
curl -s https://example.com/page/ | grep -Eio '<link rel="canonical"[^>]*>|<meta name="robots"[^>]*>'
curl -s https://example.com/page/ | sed -n '/<head>/,/<\/head>/p' | grep -Eio '<title>[^<]*</title>'

Типовые ложные находки

Сравнить модели

Когда аудит сравнивает модели, оркестратор после шага 5 раскрывает буквы и сводит рейтинги двух критиков: место отчёта — среднее его мест у двух критиков, при равном среднем отчёты делят место. Мерила рейтинга стоят в blind-critic. Рядом с местом пишут время и цену прогона.

Пример сравнения на двадцати моделях: Какая из 20 моделей лучше всех делает SEO-аудит.

Правила

• Запрет менять проект из задания шага 2 не убирать: без него модель на задаче аудита может запушить ветку.
• Находка без доказательства в список находок не попадает. Что считается доказательством, стоит в seo-reviewer.
• Выгрузку Search Console и таблицу «буква → автор» в репозиторий не кладут: ни в приватный, ни в публичный.
• Один PR закрывает одну строку таблицы шага 7.