SEO-аудит помогает найти технические препятствия и составить очередь исправлений. Начните с области проверки: одна страница, несколько шаблонов или список URL. Отчёт по главной не описывает весь каталог, а отсутствие технических ошибок не гарантирует индексирование и рост трафика.
В этом руководстве разберём путь от выбора URL до приёмки исправлений. Условия reChecker приведены на 7 октября 2026 года; перед запуском сверяйте их с формой аудита и тарифами.
Определите результат и охват
Запишите задачу: принять новый шаблон, проверить переезд, разобрать недоступность или найти причины проблем с индексированием. Затем подготовьте выборку: главная, категория, карточка, страница услуги, статья, пагинация и другие типы, относящиеся к задаче. Если проблема массовая, нужны несколько URL каждого затронутого шаблона.
Сохраните исходные адреса, дату, окружение и способ проверки. Для повторного измерения понадобятся те же URL. Ограничение объёма обхода должно быть видно в выводах: «проверено 25 страниц из выбранного списка» точнее, чем «сайт полностью исправен».
| Задача | Что проверять | Чего этот результат не доказывает |
|---|---|---|
| Быстро проверить URL | Ответ и технические признаки одной страницы | Состояние всех остальных страниц |
| Проверить несколько шаблонов | Заданный список, sitemap или найденные внутренние URL | Все адреса сайта, если достигнут лимит |
| Подтвердить индексирование | Проверка URL в Search Console и Яндекс.Вебмастере | Будущее место в выдаче |
| Проверить удобство и скорость | Браузерный сценарий, лабораторные и доступные полевые данные | Успешность заказа без отдельного теста |
| Подтвердить исправление | Повтор исходного теста после релиза | Причинную связь с последующим ростом трафика |
Как выбрать запуск reChecker
Технический аудит выполняет 29 типовых проверок. Можно проверить одну страницу или несколько URL, собранных из sitemap, внутренних ссылок либо заданного списка. Доступность, метатеги, директивы и ссылки — технические наблюдения; факт присутствия страниц в поиске устанавливают панели вебмастеров.
Бесплатный вход — экспресс-проверка одной страницы: гостю доступен один запуск раз в семь дней с кратким результатом. Бесплатная регистрация открывает подробности; бесплатному аккаунту доступны 10 экспресс-проверок в месяц. Эти условия не означают бесплатный обход сайта любого размера.
Разовые пакеты полного аудита:
| Максимальный объём одного задания | Стоимость |
|---|---|
| 25 страниц | 49 ₽ |
| 100 страниц | 149 ₽ |
| 500 страниц | 499 ₽ |
| 1 000 страниц | 899 ₽ |
В активной оплаченной подписке включённые ручные локальные проверки и аудиты доступны без месячного лимита запусков. Предел страниц одного задания сохраняется; тестовый и бесплатный доступ имеют другие условия. Платные генераторы ИИ и внешний API не входят автоматически в это обещание.
Подписка стоит от 990 ₽ в месяц за один сайт и включает ежедневный аудит до 100 страниц, контроль доступности каждые пять минут и историю 90 дней. Позиции и ежемесячные вопросы ИИ — отдельные процессы внутри подписки. Для текущего дефекта начните с разового аудита; для риска повторения сравните регулярный контроль.
Обычный PDF отчёта доступен бесплатно после входа. Оформление логотипом и своими данными относится к активной оплаченной подписке. Автоматический PDF сохраняет результаты проверок и не заменяет индивидуальное заключение о стратегии продвижения.
Подготовьте доступы и исходные данные
В Search Console и Вебмастере соберите сведения о затронутых страницах, поисковых запросах и датах обхода. В аналитике — посещения и завершённые целевые действия. Для серверных проблем понадобятся логи, настройки CDN и данные о релизах. Отсутствующий доступ запишите как ограничение, а не заменяйте догадкой.
Рабочая таблица: URL, время, способ проверки, факт, ожидаемое состояние, последствие, охват, владелец, приоритет, действие, критерий приёмки. В ней отдельно храните исходный результат и повторный тест.
Проверьте доступность, обход и индексирование
Сначала получите конечный HTTP-ответ без авторизации. 200 должен сопровождаться нужным документом: форма входа, антибот-заглушка или пустой каркас с таким кодом не подтверждают успешную загрузку содержания. Для редиректа сохраните всю цепочку и конечный URL; при 5xx повторите запрос и изучите журнал вокруг времени сбоя.
curl -sS -L -D /tmp/audit-headers.txt \
-o /tmp/audit-page.html https://example.com/pageЭто локальные файлы ответа выбранного URL. Перед передачей другим людям проверьте, нет ли в них cookies и иных служебных данных. Команда проверяет сетевой ответ; она не выполняет JavaScript и не имитирует запрос реального Googlebot с его IP.
Проверьте применимые правила robots.txt, meta robots и X-Robots-Tag. Disallow ограничивает обход, noindex — индексирование. При запрете загрузки робот может не увидеть noindex; robots.txt также не заменяет авторизацию приватных разделов. Не снимайте запрет со служебных URL ради устранения предупреждения сканера.
Для конкретной страницы в Google откройте проверку URL: индексированная версия и live-тест отвечают на разные вопросы. Проверка текущей доступности не доказывает включение в индекс. Для Яндекса используйте проверку страницы в Вебмастере. Полный ход диагностики приведён в руководстве по URL вне индекса.
Согласуйте URL, canonical, sitemap и ссылки
Для основной версии сопоставьте конечный адрес, canonical, запись sitemap и внутренние ссылки. Цель canonical должна соответствовать документу; ссылка на главную у всех карточек не становится правильной только потому, что она отвечает 200.
Проверьте несколько вариантов URL: протокол, www, слеш, параметры. Для самостоятельных страниц пагинации с разными элементами нужен собственный адрес и согласованный canonical, а также обычные ссылки с href. Не закрывайте их массово по одному наличию ?page=. Подробнее — правила пагинации Google.
Sitemap содержит выбранные канонические адреса и достоверный lastmod. Он помогает обнаружению, но не гарантирует индексирование. Ищите страницы-сироты и внутренние ссылки через ненужные редиректы. Для удалённого URL перенаправление уместно, когда есть соответствующая замена; при её отсутствии нормальным результатом может быть 404 или 410.
Для отдельной находки пригодятся проверка canonical, анализ robots.txt, валидатор sitemap и проверка ссылок.
Для подробного прохода по шаблонам используйте чек-лист технического SEO. Этот гайд задаёт рабочую последовательность; чек-лист помогает не пропустить отдельные проверки.
Сопоставьте исходный HTML, DOM и экран
Сохраните исходный ответ и сравните его с DOM после JavaScript и видимым экраном. Проверьте основной текст, заголовки, товарные свойства, ссылки и canonical. Если данные приходят через API, убедитесь, что запрос работает без клиентской сессии и основной контент не требует действия, которое робот не выполнит.
JavaScript сам по себе не является запретом для Google. Ошибки ресурсов, API и рендеринга требуют проверки результата, а не универсального вывода «нужен SSR». Используйте официальное руководство Google по JavaScript SEO и просмотр результата в проверке URL.
Title и description должны отражать задачу страницы. Формальные пороги длины удобны как редакторская подсказка, но не являются гарантией показанного сниппета. Google может сформировать другую ссылку-заголовок: см. документацию о title links. H1 и следующие заголовки проверяйте по смыслу и структуре, а не только по числу элементов.
Разметка описывает видимое содержимое и реального автора. Не добавляйте вымышленные оценки, отзывы и биографии. FAQ может помогать читателю, но Google прекратил FAQ rich results с 7 мая 2026 года — журнал изменений. Не обещайте CTR от самого наличия FAQPage.
Проверьте содержание и структуру каждого шаблона
Для карточки, категории, услуги и статьи выберите отдельные контрольные URL. Сопоставьте заголовок, title и основной текст с задачей посетителя. Ищите пустые описания, устаревшие условия и почти одинаковые документы, в которых меняется только город. Достаточность текста оценивайте по полезным сведениям, а не по универсальному числу слов или плотности ключей.
Проверьте изображения: у значимых есть описательный alt, у декоративных допустим пустой; размеры или aspect-ratio помогают резервировать место. Отложенная загрузка подходит содержимому ниже первого экрана, но её влияние на главный элемент нужно измерить. Для товарных и других подходящих типов разметки используйте только реальные видимые свойства.
Проверьте путь от категории к карточке и следующий шаг посетителя. Важные URL должны иметь доступные внутренние ссылки; ошибка ссылки на заказ не равна ошибке метатега. Работоспособность формы, заказа и оплаты принимайте отдельным сценарием с подтверждением результата, а не только загрузкой страницы. Если такой тест не проводился, отразите ограничение отчёта.
Разделите лабораторную скорость и полевой опыт
Для Core Web Vitals смотрите LCP, INP и CLS. Хорошие пороги — LCP до 2,5 секунды, INP до 200 мс, CLS до 0,1; полевой результат оценивается на 75-м процентиле. Описание метрик — в Web Vitals. TTFB и лабораторный TBT помогают диагностике, но не заменяют INP реальных пользователей.
Для конкретной страницы используйте проверку Web Vitals, а для доступных полевых данных — Search Console и PageSpeed Insights. Если данных о реальных пользователях нет, так и запишите. Один Lighthouse-запуск не является доказательством полевого состояния всего сайта.
На мобильном устройстве проверьте чтение, меню, форму и основные действия. Для TLS и заголовков безопасности используйте SSL-проверку и анализ заголовков. Настройку HSTS/CSP принимайте с учётом поддоменов и ресурсов приложения; универсальная строка заголовков может сломать работающий сайт. Проверки сертификата и headers не заменяют расследование взлома или malware.
Прочитайте реальный отчёт и задайте границы вывода
Откройте публичный отчёт rechecker.ru и методику проверок. Это существующий разрешённый пример. Перед выводом смотрите дату и указанный охват: отчёт по одному URL не превращается в аудит всех страниц домена. Снимок также не описывает состояние сайта после его даты.
В доступном 7 октября примере сохранён аудит одной страницы https://rechecker.ru/ от 3 октября 2026 года, 15:27 мск. Один из пунктов — лабораторный CLS 0,401. Это конкретная исходная находка для разбора сдвигов макета; она не доказывает текущий полевой CLS, причину сдвига или уже выполненное исправление.
Выберите один фактический пункт отчёта. Сохраните проверенный адрес, результат и способ наблюдения, затем воспроизведите его. Если текущий ответ отличается от снимка, зафиксируйте оба состояния: причина могла измениться после запуска. Не добавляйте отсутствующую историю исправления и не приписывайте примеру рост трафика.
Дальнейший маршрут: приоритизация находки → задача разработчику → перепроверка после изменения. Это один проверяемый рабочий процесс, даже когда разрешённого кейса «до/после» ещё нет.
Приоритизируйте и примите исправления
Сначала подтверждённые блокеры важных страниц: недоступность, случайный noindex, закрытый обход, неправильный редирект или отсутствующий основной контент. Затем нарушения шаблонов и пользовательского сценария. Косметические предупреждения и гипотезы оставляйте в отдельной очереди до подтверждения.
У каждого пункта должны быть владелец и критерий приёмки. «Убрать ошибку» замените на точное ожидаемое состояние: конечный код, фрагмент HTML, canonical или доступный текст. После выкладки повторите исходный тест на тех же URL и проверьте соседние страницы шаблона. Для поисковой индексации дождитесь соответствующих сведений панели вебмастера; опубликованный код не является подтверждением переобхода.
Выберите следующую проверку
После релиза повторяйте приёмку затронутых шаблонов. При регулярных изменениях настройте контроль с интервалом по риску: доступность нужна чаще, чем содержательная ревизия структуры. Не каждая задача требует постоянного сигнала; выбор разобран в статье «Аудит или мониторинг».
Если нужен результат по текущему набору URL, запустите технический аудит. Если проблема может повторяться, сравните состав подписки и актуальные тарифы. Итог аудита — подтверждённая находка и проверенное действие в заданной области, а не обещание позиции или трафика к определённой дате.