Технический SEO-аудит: 20 проверок сканирования, индексации, рендеринга и производительности
Почему технический аудит делят на четыре квадранта
Многие проводят технический аудит так: прогоняют PageSpeed Insights и смотрят на число ошибок в GSC. На деле в техническом SEO четыре уровня: может ли Google добраться до страницы (сканирование), попадёт ли она в индекс (индексация), тот ли это контент (рендеринг) и быстро ли всё работает (производительность). Если хоть один уровень сломан, вся работа выше — впустую.
Контринтуитивный вывод: 100% индексации — не цель. Если на сайте 1000 страниц и 900 из них — тонкий контент, страницы параметров и результаты поиска, их полная индексация только занижает общую оценку качества. Правильно — самому закрывать noindex низкокачественные страницы и направлять краулинговый бюджет на 100 действительно ценных страниц.
| Квадрант | Ключевой вопрос | Если есть проблема | Вес |
|---|---|---|---|
| Сканирование Crawling | Может ли Googlebot добраться до ваших страниц | Страницы вообще не посещаются | Базовый уровень, без права на ошибку |
| Индексация Indexing | Попадёт ли страница в индекс после сканирования | Страница не попадает в базу Google | Базовый уровень, без права на ошибку |
| Рендеринг Rendering | Содержит ли полученный HTML полный контент | Контент верный, но Google его не понимает | Частая проблема современных сайтов |
| Производительность Performance | Быстро ли работает страница | Понижение в рейтинге или отток пользователей | Один из факторов ранжирования |
Квадранты связаны последовательно: сначала убедитесь, что страницу можно просканировать, затем — что её можно проиндексировать, потом — что она рендерится правильно, и только в конце оптимизируйте производительность. Порядок не перевернуть: если robots.txt закрывает важные страницы, никакая оптимизация LCP не поможет. И Google SEO Связь с другими модулями: технический аудит — это фундамент,Структурированные данные Schema— это дом на фундаменте,Оптимизация Core Web Vitals— это глубокое раскрытие квадранта производительности.
2. Квадрант сканирования: 5 проверок
Проблемы с обходом — это фундамент. Если Googlebot не может добраться до ваших страниц, всё остальное не имеет значения.
| # | Что проверить | Критерий нормы | Инструмент | Частая проблема |
|---|---|---|---|---|
| 1 | robots.txt не блокирует по ошибке | Важные страницы не закрыты через Disallow | Инструмент проверки robots в GSC | При редизайне случайно оставили Disallow: / |
| 2 | XML Sitemap доступен | Отдаёт 200, без ошибок | Отчёт по Sitemap в GSC | Неверный путь к Sitemap или он не отправлен |
| 3 | Ошибки обхода 4xx/5xx < 1% | Доля ошибок 404/500 ниже 1% | Статистика обхода в GSC | После редизайна много 404 без 301 |
| 4 | Краулинговый бюджет не расходуется впустую | Страницы с параметрами и дубли не тратят краулинговый бюджет | Статистика обхода в GSC + анализ логов | Страницы результатов поиска бесконечно обходятся |
| 5 | Во внутренних ссылках нет битых | Все внутренние ссылки отдают 200 | Обход через Screaming Frog | Старые статьи ссылаются на удалённые страницы |
Пример из практики: после редизайна сайта техническая команда прописала в robots.txt Disallow: / и забыла вернуть как было. Через три недели в GSC число страниц «Просканировано, но не проиндексировано» выросло с 200 до 2000. Как обнаружить: при аномальном росте «Просканировано, но не проиндексировано» в отчёте о покрытии первым делом проверьте robots.txt. После исправления вручную запросите индексирование через инструмент проверки URL — восстановление занимает от 1 до 3 дней.
Краулинговый бюджет: Google ограничивает частоту обхода каждого сайта. Если на сайте много URL с параметрами (например, /products?sort=price&filter=red), Googlebot тратит много времени на эти дубли, а действительно важные страницы товаров остаются в стороне. Решение — закрыть URL с параметрами через robots.txt или указать canonical на основную версию.
III. Квадрант индексации: 5 проверок
То, что Google обошёл вашу страницу, не значит, что он добавит её в индекс. Проверки квадранта индексации отвечают на вопрос: всё нужное проиндексировано, а лишнее — нет?
| # | Что проверить | Критерий нормы | Инструмент | Частая проблема |
|---|---|---|---|---|
| 6 | Все важные страницы проиндексированы | Доля индексации ключевых страниц товаров и статей > 95% | Отчёт о покрытии в GSC | Новые страницы товаров не добавлены в Sitemap |
| 7 | Нет ошибочно выставленного noindex | На рабочих страницах нет тега noindex | Screaming Frog + GSC | Забыли убрать noindex из среды разработки |
| 8 | Нет дублированного контента | Один и тот же контент на нескольких URL < 5% | Siteliner + Screaming Frog | Дубли HTTP/HTTPS и с www без www |
| 9 | Тег canonical указан верно | На каждой странице canonical ссылается на саму себя | GSC + инструмент проверки URL | canonical указывает на неверную страницу |
| 10 | Покрытие индекса разумное | Число проиндексированных страниц соответствует числу ценных страниц | Отчёт о покрытии в GSC | Тонкие страницы массово попали в индекс |
Пример из практики: на сайте B2B страница списка товаров имеет 50 комбинаций фильтров, каждая создаёт отдельный URL (/products?category=valve&material=steel). Google проиндексировал их все, и общее число страниц в индексе выросло с 200 до 2000. Итог: сайт признали содержащим много дублированного тонкого контента, общая оценка качества упала, а позиции страниц товаров, наоборот, снизились. Как исправить: поставить noindex на URL с параметрами фильтров или закрыть их напрямую через robots.txt.
noindex, выставленный по ошибке, — самая частая и самая губительная проблема. На этапе разработки, чтобы не показывать тестовый сайт Google, команда добавила noindex в head всех страниц, а после запуска забыла его убрать. Сайт работает уже 3 месяца, но по брендовым запросам официальный сайт в Google не находится. Как проверить: просканируйте сайт в Screaming Frog и отфильтруйте «Meta robots contains noindex» — на рабочих страницах таких записей должно быть 0.
IV. Квадрант рендеринга: 5 проверок
Современные сайты активно используют JS-рендеринг (React, Vue, клиентский рендеринг Next.js). Googlebot умеет выполнять JS, но не в реальном времени: сначала он забирает исходный HTML и ставит его в очередь, а через несколько дней выполняет его в очереди рендеринга Chrome. Эта задержка и сбои рендеринга — главная ловушка SEO для SPA-сайтов.
| # | Что проверить | Критерий нормы | Инструмент | Частая проблема |
|---|---|---|---|---|
| 11 | Googlebot умеет рендерить JS | Инструмент проверки URL показывает «отрендерено» | Инструмент проверки URL в GSC | Ошибка JS приводит к сбою рендеринга |
| 12 | Основной контент есть в HTML-коде | title, H1 и первый абзац текста — в исходном HTML | Смотрим исходный код страницы (не F12) | Чисто клиентский рендеринг, исходный код пустой |
| 13 | В консоли нет ошибок рендеринга | В Chrome DevTools Console нет ошибок | Chrome DevTools | Сбой вызова API приводит к пустому контенту |
| 14 | Структурированные данные считываются | Rich Results Test не показывает ошибок | Тест расширенных результатов | JSON-LD внедряется динамически через JS |
| 15 | Разметка hreflang корректна | Многоязычные страницы правильно ссылаются друг на друга | GSC + инструмент проверки hreflang | Цикл hreflang или ссылка на неверный язык |
Ключевой момент: откройте «Просмотр кода страницы» (Ctrl+U, а не F12) и посмотрите исходный HTML. Если title, H1 и первый абзац текста видны уже в исходном HTML — значит, используется SSR или SSG, и Google прочитает контент при первом же сканировании. Если в исходном HTML только div#app и куча тегов script — значит, это чисто клиентский рендеринг (CSR), и Google прочитает контент только после очереди рендеринга Chrome.
На многоязычных сайтах ошибки hreflang встречаются очень часто: немецкая страница ссылается на английскую, английская — на саму себя, отсутствует x-default. Как настроить — см.Перенос Hreflang для мультиязычности. Структурированные данные, внедрённые динамически через JS, Google в итоге отрендерит, но очередь сканирования часто их пропускает, поэтому JSON-LD лучше размещать в исходном HTML.Структурированные данные Schema Процесс проверки здесь сочетается с описанным выше.
V. Квадрант производительности: 5 проверок
Производительность — это три ключевых показателя Core Web Vitals плюс удобство для мобильных и HTTPS. Производительность — это не просто «быстро работает»: это фактор ранжирования Google. С 2021 года Core Web Vitals официально стал сигналом ранжирования.
| # | Что проверить | Критерий нормы | Инструмент | Частая проблема |
|---|---|---|---|---|
| 16 | LCP (отрисовка самого крупного элемента) | ≤ 2,5 с | PageSpeed Insights + CrUX | Изображения первого экрана не сжаты, шрифты блокируют загрузку |
| 17 | INP (взаимодействие до следующей отрисовки) | ≤ 200 мс | PageSpeed Insights + CrUX | Сторонние скрипты блокируют основной поток |
| 18 | CLS (совокупное смещение макета) | ≤ 0,1 | PageSpeed Insights + CrUX | У изображений нет размеров, не зарезервировано место под рекламу |
| 19 | Удобство для мобильных | Нет критичных ошибок макета | Отчёт об удобстве для мобильных в GSC | Слишком маленькие кликабельные элементы, горизонтальная прокрутка |
| 20 | HTTPS на всём сайте, без смешанного контента | Все ресурсы загружаются по HTTPS | Консоль браузера + GSC | Изображения/CSS всё ещё ссылаются на HTTP |
Пример 3: у B2B-сайта PageSpeed показывает LCP 4,2 с и INP 350 мс. Диагностика выявила: баннер первого экрана — несжатый PNG на 3 МБ, а на главной загружается 8 сторонних скриптов аналитики. Оптимизация: картинку перевели в WebP и сжали до 200 КБ, скрипты отложили через Tag Manager. Через две недели LCP упал до 1,8 с, INP — до 120 мс. Как это делается — читайте Оптимизация Core Web Vitals.
Приоритет метрик: сначала LCP, потом INP, затем CLS. Если LCP не проходит, сначала проверьте изображения первого экрана (сжатие, ленивая загрузка, preload) и TTFB, а затем ресурсы, блокирующие рендеринг.Глобальное ускорение через CDN Напрямую улучшает TTFB и LCP для зарубежных сайтов.
FAQ: частые вопросы
Как часто нужно проводить технический SEO-аудит?
Чем выше доля проиндексированных страниц, тем лучше?
Как сделать SEO для SPA на React/Vue?
Что такое бюджет сканирования и как понять, что он тратится впустую?
Как быстро исправить неудовлетворительный LCP?
Как найти и исправить случайно выставленный noindex?
В заключение
Технический SEO-аудит — фундамент всей SEO-работы: как бы хорошо ни был написан контент и как бы дорого ни стоили ссылки, если Google не может обойти страницы или получает пустую JS-оболочку, всё это напрасно. 20 проверок — не разовая задача, а обязательный этап каждый квартал.
Три шага на практике. На этой неделе выгрузите данные из отчёта о покрытии GSC и статистики сканирования и пройдитесь по всем 20 проверкам. На следующей неделе расставьте провалы по приоритету: сначала исправьте сканирование и индексацию (это критично), затем рендеринг, и только потом оптимизируйте производительность. На третьей неделе после исправлений перепроверьте всё через инструмент проверки URL и PageSpeed.
Вот фраза, которую стоит запомнить: технический SEO — это не про сложность, а про чистоту. Googlebot быстро сканирует, точно собирает, правильно рендерит и стабильно работает — сделайте эти четыре вещи, а остальное оставьте контенту и ссылкам.