/seo-audit

name: seo-audit
description: >-
  SEO-аудит сайта с перекрёстной проверкой: находки нескольких отчётов
  «топ-10 ошибок» подтверждают слепые критики на живом сайте, починка идёт
  PR с журналом изменений. Применять на «сео аудит», «проверь sitemap и
  редиректы», «почему страницы не в индексе».

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

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

Роли

| Роль | Агент | Что делает | |---|---|---| | Оркестратор | сессия, где вызван скилл | ведёт шаги, хранит таблицу «буква → автор», сводит вердикты | | Аудитор | [`seo-reviewer`](../../agents/seo-reviewer.md) | пишет отчёт «топ-10 ошибок» | | Критик | [`blind-critic`](../../agents/blind-critic.md) | проверяет находки обезличенных отчётов, выносит вердикт каждой | | Ревьюер | [`uncle-bob`](../../agents/uncle-bob.md) | ревью PR | | Редакторы | [`ilyakhov`](../../agents/ilyakhov.md), [`tufte`](../../agents/tufte.md) | `ilyakhov` — тексты страниц, `tufte` — подача данных |

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

• Адрес сайта и его исходники в 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`](../../agents/blind-critic.md).

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

| Критики | Что делать | |---|---| | оба «подтверждена» | в список находок | | оба «неверна» | снять и записать причину в ложные находки | | оба «не проверить» | закрыть выгрузкой Search Console или отдать вопросом владельцу | | расходятся или оба «частично» | перепроверить одной командой и приложить её вывод; проверить нечем — как оба «не проверить» |

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

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

7. Починить

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

| PR | Что входит | |---|---| | Индекс и редиректы | `robots.txt`, sitemap, правила редиректов в конфиге хостинга | | Шаблоны и разметка | `<head>`, canonical, Open Graph, JSON-LD, даты | | Перелинковка и содержание | ссылки, каталоги и списки, тонкие страницы |

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. Проверить после выкладки

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

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

| Класс | Что смотреть | |---|---| | Индекс | `robots.txt`, sitemap, canonical, `noindex`, служебные страницы в индексе, тонкие страницы | | Ссылки | битые внутренние ссылки и картинки, страницы без входящих ссылок, разделы вне каталога и поиска | | Разметка и даты | `title`, `description`, Open Graph, JSON-LD, хлебные крошки, `lastmod` и даты публикации | | Редиректы | цепочки из двух шагов и длиннее, постоянный или временный код, `www` и слэш в конце, старые адреса |

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

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>'

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

| В отчёте | На деле | Как отличить | |---|---|---| | «На странице два `<title>`» | второй `<title>` лежит внутри `<svg>` | последняя команда из блока выше | | «Мёртвая ссылка» | адрес отвечает 200 | `curl -sIL` н