1. Что проверяет аудит
Одностраничный технический аудит объединяет 28 проверок. В зависимости от доступности сайта в отчёт входят HTTP-ответы и редиректы, SSL, мета-теги, canonical, robots.txt, sitemap, заголовки, контент, изображения, ссылки, Schema.org, Open Graph, производительность, доступность и заголовки безопасности.
Полный аудит запускает постраничные SEO- и HTML-проверки для каждого выбранного URL и дополнительно агрегирует дубли, отсутствующие метаданные, статусы, битые ссылки и изображения на уровне сайта. Доменные сигналы вроде robots.txt и sitemap измеряются один раз и переиспользуются с указанием URL-источника.
2. Как находятся страницы
reChecker ищет директиву Sitemap в robots.txt, затем стандартные адреса sitemap. Индексы sitemap и вложенные карты разбираются рекурсивно в пределах времени и лимита.
Параллельно строится граф внутренних HTML-ссылок от введённого URL. Результаты объединяются: сначала в выборку входят реально достижимые по ссылкам страницы, затем свободный лимит заполняется URL из sitemap. Если один источник недоступен, используется второй.
Удаляются дубли, фрагменты, известные рекламные параметры и URL бинарных файлов. Внешние домены в очередь страниц не добавляются.
Источник, число найденных URL и факт ограничения выборки сохраняются в отчёте. Текущие пакеты: 25 страниц, 100 страниц, 500 страниц, 1000 страниц.
3. Получение и интерпретация данных
Большинство проверок анализирует HTTP-ответ и исходный HTML, доступный серверному краулеру. Для пустых Next.js, Nuxt и SPA-оболочек выполняется целевой Chromium fallback. Отчёт сохраняет измеримые различия source HTML и rendered DOM по title, H1, объёму текста, ссылкам и изображениям, но не хранит две полные копии HTML.
Редиректы, коды ответа и заголовки фиксируются на момент запуска. Ссылки и изображения проверяются с дедупликацией целей; для проблемной ссылки сохраняются исходные страницы и цепочка переходов.
Лабораторные Web Vitals выполняются для каждого URL в аудитах до 100 страниц. В более крупных аудитах используется равномерная выборка: до 25 страниц при размере до 1 000 URL и до 50 страниц при большем размере. На остальных URL отчёт явно показывает, с какой репрезентативной страницы переиспользовано последнее успешное измерение; мета-теги, контент, canonical, Schema.org и ссылки при этом не семплируются.
Часть метрик может зависеть от сети, географии, защиты от ботов и сторонних API. Недоступная проверка должна помечаться как пропущенная или ошибка получения данных, а не автоматически считаться дефектом сайта.
4. Балл и приоритеты
Балл 0–100 — диагностическая сводка, а не оценка поисковой системы и не прогноз позиции. Разные проверки имеют разный вес; критичные технические сигналы влияют сильнее рекомендательных. Средний балл полного аудита — среднее по успешно проверенным страницам.
При планировании работ важнее конкретный URL, подтверждающий сигнал и динамика между запусками. Поэтому повторный аудит отдельно показывает новые, исправленные и оставшиеся проблемы.
5. Ограничения и ложные срабатывания
- JavaScript-рендер может не завершиться за отведённое время или потребовать действий пользователя.
- Cloudflare, CAPTCHA, rate limit и блокировка user-agent распознаются как ограничение доступа, но новые защитные страницы требуют пополнения корпуса.
- Нетипичный корректный title, description, canonical или структура заголовков могут нарушать общие эвристики.
- Страница вне sitemap и без внутренних ссылок не будет найдена автоматически.
- Core Web Vitals в лабораторной проверке не заменяют полевые данные CrUX, Search Console или Яндекс Вебмастера.
- В аудитах свыше 100 URL лабораторные Web Vitals являются выборочным измерением, а не отдельным Lighthouse-прогоном каждой страницы.
Критичные изменения рекомендуется подтвердить вручную в браузере и в панелях поисковых систем до выпуска задачи в продакшен.
6. Воспроизводимость и исправления
Отчёт содержит дату, проверенные URL и доступные исходные показатели. CSV- и XLSX-выгрузки позволяют сохранить снимок и доказательства по ссылкам и редиректам. Методика и проверки меняются вместе с продуктом; дата этой страницы показывает актуальность описания.
Если результат выглядит неверным, отправьте URL, дату аудита и название проверки через форму обратной связи. Такие примеры используются для регрессионных тестов после удаления персональных данных.
7. Контрольный корпус качества
Версия корпуса: 2026-07-15.1. Дата измерения: 15 июля 2026 года. В корпусе 12 детерминированных HTML-сценариев для двух особенно чувствительных решений: нужен ли Chromium для пустой JS-оболочки и является ли полученная страница защитной заглушкой.
Область применимости: это показатель только для размеченного контрольного корпуса, а не заявление об общей точности SEO-аудита. Он не измеряет все CMS, сетевые условия и эвристики. Следующая ступень — обезличенные реальные снимки и отдельно опубликованный production-набор.
8. Публичные отчёты и кейсы
Ссылка на публичный отчёт по умолчанию закрыта от индексации. Для включения в витрину кейсов требуется отдельное версионированное согласие уполномоченного пользователя, повторный аудит с базовой версией и ручная редакционная проверка.
Кейс пересказывает только наблюдаемые изменения отчёта и ведёт на датированный источник. Рост позиций, трафика или выручки не приписывается техническим исправлениям без отдельно подтверждённых данных поисковых систем.
Открыть проверяемые кейсы →