Инструмент не проводит аудит вместо специалиста. Он собирает данные, проверяет формальное правило или помогает воспроизвести проблему. Вывод появляется только после сопоставления нескольких сигналов с устройством конкретного сайта.
Мой набор устроен слоями: сначала браузер и HTTP, затем обход сайта, поисковые данные, производительность и только после этого платные конкурентные базы.
Браузер и DevTools
Chrome DevTools или аналогичный набор в Firefox — первая точка для большинства технических вопросов.
Network
Панель Network показывает:
- последовательность запросов;
- статусы и редиректы;
- размеры ресурсов;
- кеширование;
- приоритет загрузки;
- блокирующие запросы;
- заголовки ответа;
- момент обнаружения LCP-ресурса.
Перед запуском специализированного краулера я часто открываю здесь один проблемный URL. Это быстро отделяет ошибку сайта от ошибки отчёта.
Elements и Accessibility
В Elements проверяются итоговый DOM, заголовки, ссылки, атрибуты изображений и доступные имена элементов. Accessibility tree помогает увидеть страницу так, как её представляют вспомогательные технологии.
Performance
Performance нужен для долгих задач, задержек взаимодействия, layout shift и анализа основного потока. Это диагностический инструмент, а не просто красивый график.
Разбор метрик и порядок записи профиля описаны в материале про Core Web Vitals.
Командная строка
Несколько простых команд часто полезнее очередного расширения.
curl -I https://example.com/page/Так можно проверить статус, location, кеширование и другие HTTP-заголовки без влияния интерфейса браузера.
curl -L -o /dev/null -w "%{url_effective} %{http_code}\n" https://example.com/old-urlКоманда показывает конечный URL после редиректов.
Для поиска по проекту удобно использовать rg, а для проверки собранного статического сайта — небольшой скрипт, который извлекает ссылки из HTML и сопоставляет их с файлами сборки.
Краулер
Screaming Frog
Screaming Frog полезен для:
- статусов и редиректов;
- canonical;
- title и description;
- структуры заголовков;
- глубины URL;
- внутренних ссылок;
- изображений;
- поиска страниц-сирот после подключения внешних списков URL.
Главная ошибка — экспортировать все вкладки и назвать это аудитом. Перед обходом задайте вопрос: например, «какие индексируемые страницы не имеют self-canonical» или «где внутренние ссылки ведут на редирект».
Sitebulb и альтернативы
Sitebulb сильнее визуализирует структуру и объясняет многие проверки. Для регулярного командного обхода удобны также CLI-краулеры и собственные скрипты.
Выбор зависит от размера сайта и процесса команды. Для небольшого статического блога можно обойтись простой проверкой собранного каталога.
Поисковые запросы и видимость
Данные о показах и переходах берутся из панелей самих поисковых систем. Сторонние сервисы оценивают видимость по своей выборке запросов и не заменяют реальные данные сайта.
При работе с запросами важно хранить:
- формулировку запроса;
- страницу;
- намерение пользователя;
- устройство и регион, если они значимы;
- показы, клики и среднюю позицию;
- дату изменения страницы.
Без истории легко принять сезонность или изменение выдачи за эффект последней правки.
Семантика и кластеризация
Key Collector и похожие программы полезны для больших русскоязычных ядер, частотностей и группировки. Но автоматическая кластеризация не определяет редакционную стратегию.
Перед созданием страницы я проверяю:
- Один ли тип результата ожидает пользователь.
- Можно ли полноценно ответить на вопрос в существующей статье.
- Не появится ли ещё одна почти пустая рубрика.
- Есть ли у автора собственный опыт, пример или способ проверки.
Если два запроса требуют одного ответа, лучше одна сильная страница, а не две версии текста с переставленными словами.
Анализ конкурентов
Ahrefs, Semrush, Serpstat и похожие базы помогают находить:
- страницы, которые получают ссылки;
- темы и запросы конкурентов;
- динамику видимости;
- упоминания домена;
- потенциально сломанные внешние ссылки.
Цифры таких сервисов являются оценкой. Особенно осторожно нужно относиться к трафику отдельной страницы и полноте ссылочного профиля.
Я использую конкурентный анализ как способ найти вопросы и форматы, а не как инструкцию «переписать первые десять результатов».
Производительность
PageSpeed Insights
Показывает полевые данные Chrome UX Report, если они доступны, и лабораторный запуск Lighthouse. Эти два блока отвечают на разные вопросы и не должны смешиваться.
WebPageTest
Полезен для:
- повторяемых запусков;
- выбора устройства и региона;
- видео загрузки;
- waterfall;
- сравнения первого и повторного посещения;
- экспериментов с блокировкой сторонних ресурсов.
Lighthouse
Lighthouse удобен для быстрой проверки и CI. Он помогает ловить регрессии, но общий балл не является бизнес-метрикой и не гарантирует хороший опыт у реальных пользователей.
Доступность
Для автоматической первичной проверки подходят axe и Lighthouse Accessibility. Они обнаруживают часть проблем: контраст, отсутствующие имена, некоторые ошибки ARIA.
После автоматики обязательна ручная проверка:
- пройти страницу клавишей
Tab; - открыть и закрыть меню;
- проверить порядок фокуса;
- увеличить масштаб;
- включить уменьшение движения;
- прочитать структуру заголовков;
- проверить страницу без мыши.
Автоматический тест не заметит, что анкор «сюда» непонятен вне контекста или что логичный визуально порядок отличается от порядка в DOM.
Редактор и репозиторий
VS Code, Git и обычный Markdown составляют важную часть SEO-процесса:
- схема frontmatter не даёт опубликовать некорректную категорию;
- diff показывает, что именно изменилось;
- история объясняет дату обновления;
- code review ловит сломанные ссылки и спорные формулировки;
- сборка проверяет шаблоны до релиза.
Для контентного сайта это одна из причин выбрать файловую архитектуру, описанную в сравнении Astro и Next.js.
Минимальный набор для небольшого сайта
Если бюджет ограничен, я бы начал так:
- DevTools.
curlи проверка DNS.- Краулер с бесплатным лимитом.
- PageSpeed Insights.
- Lighthouse или axe.
- Таблица проблем с приоритетами.
- Git и автоматическая сборка.
Платный сервис имеет смысл добавлять, когда понятно, какое регулярное решение он ускоряет. Подписка «на всякий случай» быстро превращается в ещё одну панель, которую никто не открывает.
Как не утонуть в отчётах
Каждый инструмент должен отвечать на вопрос. Мой рабочий цикл выглядит так:
гипотеза
→ подходящий источник данных
→ воспроизводимый пример
→ изменение
→ повторная проверка
→ наблюдение после релизаФормальный список технических проверок находится в чек-листе SEO-аудита. Он помогает выбрать инструмент под проблему, а не проблему под уже купленный инструмент.