Настройки cookie

Необходимые cookies держат сайт рабочим. Аналитика показывает, какие страницы полезны. Выбор можно изменить в любой момент — из футера.

Политика cookie — подробно: категории cookie, как мы храним ваш выбор в браузере и как отозвать согласие.

Необходимые

Базовые функции сайта и ваш выбор согласия. Всегда включены.

Аналитика

Помогает понять, как используют сайт. Загружается только после вашего разрешения.

GitHubСкачать ZIP

Проверка SEO-исправлений

Перепроверьте выбранные находки или URL после релиза. Каждой находке присваивается статус: исправлено, сохраняется, изменилось или не поддаётся проверке. Оценка идёт только по затронутым страницам.

Открыть на GitHubБыстрый старт

Что делает

  • Терминал: опции seohead verify-fixes

Точечная перепроверка

Выбирайте, что проверить: по ID находки, по затронутому URL, из файла со списком URL или из сохранённого представления проверки. SpiderHead заново запрашивает только эти страницы, с политикой HTTP, robots и рендеринга, записанной в базовом срезе. Проверки всего сайта не перезапускаются.

  • Выборка содержит не больше 500 целей сканирования и 5 000 находок.
  • Выборка сверх лимитов завершается ошибкой и никогда не сокращается до части URL.
  • --after использует уже существующий более поздний аудит или скан, поэтому запросы не отправляются.

Ограниченные вердикты

Частичная перепроверка не может объявить весь сайт исправленным. Проверки всего сайта и непроверенные проверки возвращаются как «не поддаётся проверке». Некорректный более поздний обход не может закрыть находки, а повторный анализ того же скана не даёт нового доказательства.

  • У каждого вердикта есть причина и доказательство.
  • Результаты записываются в новый неизменяемый JSON- и Markdown-файл.
  • Отсутствующие страницы остаются «не поддаётся проверке».

Журнал исправлений

Для длинной работы журнал исправлений, привязанный к проекту, отслеживает каждый случай по состояниям жизненного цикла. Переход задачи между состояниями опирается на данные перепроверки, поэтому задача, отмеченная как выполненная, не принимается за исправленный сайт. Перепроверки ограничены точными ожидающими случаями.

  • remediation-ingest загружает сохранённый аудит как базовый срез.
  • remediation-recheck проверяет ожидающие случаи без обхода сайта.
  • remediation-report показывает доказательства до и после в офлайн-режиме.

Три шага — один сохранённый скан

  1. Начните с базового среза

    Укажите verify-fixes на уже имеющиеся audit.json или SQLite-скан, затем выберите ID находок или затронутые URL.

  2. Перепроверьте только затронутые страницы

    Команда заново запрашивает выбранные URL с политикой HTTP, robots и рендеринга, записанной в базовом срезе. Проверки всего сайта не перезапускаются.

  3. Читайте вердикт по каждой находке

    Каждой находке присваивается статус: исправлено, сохраняется, изменилось или не поддаётся проверке. Причина и доказательство записываются в новый неизменяемый JSON- или Markdown-файл.

Проверки в этой возможности

ПроверкаЧто значитКритичностьДоказательство
BROKEN_PAGE_4XXСтраница возвращает статус 4xx; перепроверка покажет её исправленной, когда URL начнёт отдавать 2xxCriticalКод статуса до и после, по каждому URL
SERVER_ERROR_5XXСтраница возвращает статус 5xx; считается исправленной, только когда перепроверка получает 2xxCriticalКод статуса до и после, по каждому URL
TITLE_MISSINGНа странице нет элемента title; исправление отображается как «исправлено» на том же URLCriticalСтроки находок из базового среза и перепроверки для URL
H1_MISSINGНа странице нет заголовка H1ImportantСтроки находок из базового среза и перепроверки для URL
CANONICAL_MISSINGНа странице нет тега canonicalImportantСтроки находок из базового среза и перепроверки для URL
REDIRECT_CHAINРедирект проходит через два и больше переходов до конечного URLImportantСтатус каждого перехода из перепроверки
BAD_REDIRECT_TYPEИспользуются 302, 303 или 307 там, где ожидается постоянный 301TipСтатус каждого перехода из перепроверки

Одна команда

bash
seohead verify-fixes --baseline ./report/audit.json --urls https://example.com/old-page --out-dir ./verification-1

Сначала установите: руководство по установке. Каждая команда работает и как MCP-инструмент для ИИ-агентов.

Что нужно

  • Базовый срез: сохранённый audit.json или SQLite-скан
  • Выборка: ID находок, URL, файл со списком URL или сохранённое представление
  • Новая папка для файлов проверки (--out-dir)
  • Необязательно: исходный конфиг краулера, если в базовом срезе учётные данные замаскированы (--config)

Ограничения

  • Без --after команда отправляет читающие запросы на выбранные вами URL.
  • Проверяются только выбранные страницы. Сайт целиком не пересканируется.
  • Более поздний скан, который используется с --after, должен быть другим и снятым позже базового среза.
  • Проверки, которые относятся ко всему сайту, нельзя подтвердить частичной перепроверкой.

Вопросы

Меняет ли это что-нибудь на моём сайте?
Нет. Команда отправляет только читающие запросы на выбранные вами URL. Результат — новый файл проверки в папке, которую вы укажете в --out-dir.
Означает ли статус «исправлено», что весь сайт исправлен?
Нет. Проверяются только выбранные вами затронутые страницы. Проверки всего сайта и непроверенные проверки по частичной перепроверке не могут получить статус «исправлено»; они возвращаются как «не поддаётся проверке».
Нужно ли сначала сканировать сайт заново?
Нужен базовый срез: сохранённый audit.json или SQLite-скан. Чтобы проверить без сетевых запросов, передайте --after с уже существующим более поздним аудитом — тогда команда работает офлайн.
Сколько находок можно проверить за один запуск?
До 500 целей сканирования и 5 000 находок. Выборки больше лимита завершаются ошибкой, а не сокращаются, поэтому разбейте их на части.
Чем это отличается от compare-crawls?
compare-crawls сравнивает два сохранённых файла и ничего не запрашивает. verify-fixes заново запрашивает выбранные страницы и выдаёт вердикт по каждой находке. Используйте compare-crawls для обзора релиза, а verify-fixes — для закрытия конкретных задач.
Можно ли использовать из ИИ-ассистента?
Да. Та же операция доступна в локальном MCP-сервере как seo_verify_fixes с теми же аргументами, что и в CLI.

Что ещё посмотреть

Из блога и глоссария

Чек-лист SEO для сайта: 80+ пунктов для аудитаБлог

Ещё в этой группе · Импорт и сравнение

Анализатор экспортов Screaming FrogВозможностьСравнение сканирований до и послеВозможностьИстория URL между сканированиямиВозможность

Проверьте на своём сайте

Скачать ZIPВсе возможности