В Search Console много URL, но органический трафик получает только часть из них. Среди остальных могут быть фильтры, дубли и служебные страницы, которые конкурируют за обход и усложняют анализ индекса. Я классифицирую URL, проверяю фактический crawl и отдельно тестирую рендеринг JavaScript.
С чем обычно приходят
Типичные ситуации, когда стандартные решения уже не справляются.
- В индексе непропорционально много фильтров, сортировок и версий с параметрами относительно целевых страниц
- Новые страницы индексируются дольше целевого срока, а причины нужно разделить между обходом, качеством и техническими сигналами
- SPA-сайт: Google Search Console показывает «Страница просканирована, но не проиндексирована»
- Robots.txt и noindex стоят на нужных страницах — или наоборот, отсутствуют на дублях
Как я работаю
Пошаговый процесс — от диагностики до передачи в эксплуатацию.
- 01
Инвентаризация индекса
Сверяю sitemap, индекс Search Console и фактический crawl (логи сервера или Screaming Frog). Классифицирую URL: полезные, дубли, фильтры, служебные, мусор. Считаю соотношение.
- 02
Аудит crawl-бюджета
Анализирую, куда робот тратит обходы: какие URL сканируются чаще, какие — игнорируются. Нахожу «пожирателей» бюджета: бесконечные фильтры, pagination без canonical, битые ссылки.
- 03
Проверка JS-рендеринга
Сравниваю, что видит Googlebot и пользователь: SSR vs CSR, hydration, lazy loading. Тестирую через Search Console URL Inspection и headless browser. Нахожу страницы, где контент не доходит до индекса.
- 04
План оптимизации
Собираю рекомендации: robots.txt, noindex, canonical, consolidation дублей, улучшение SSR. Приоритизирую по impact: что даст быстрый эффект на индексацию полезных страниц.
Что вы получаете
- Понимание, что реально в индексе — и что из этого приносит трафик
- Доля обходов по целевым и нецелевым классам URL измерена до и после изменений
- Ключевые JS-шаблоны проверены по source HTML, rendered DOM и live test
- Динамика обхода и индексации отслеживается после изменений без гарантии срока попадания в индекс
Что входит в проект
- Отчёт инвентаризации: классификация URL в индексе
- Анализ crawl-бюджета: куда уходят обходы, «пожиратели»
- Отчёт JS-рендеринга: что видит Googlebot vs пользователь
- Рекомендации: robots.txt, noindex, canonical, consolidation
- Приоритизированный план оптимизации с оценкой impact
- Техническое задание для разработки на критичные пункты
Почему мне доверяют такие задачи
Проводил аудиты индексации для SPA на React/Next.js, Vue/Nuxt и Astro — знаю, где Googlebot получает пустую страницу вместо контента. Оптимизировал crawl-бюджет для каталогов с фильтрами: canonical, noindex, robots.txt. Работаю как разработчик, а не только как SEO — могу не только найти проблему, но и поставить задачу dev-команде.
Частые вопросы
Чем это отличается от обычного SEO-аудита?
Фокус на технической индексации: что в индексе, куда уходит crawl, как рендерится JS. Не тексты, не ссылки — а «видит ли Google ваш сайт так, как вы думаете».
Нужен ли доступ к логам сервера?
Логи показывают фактические запросы известных роботов, но не состояние индекса. Без логов использую Search Console, Screaming Frog и URL Inspection; границы каждого источника фиксирую в отчёте.
Как проверяете JS-рендеринг?
Google Search Console URL Inspection (live test), headless Chrome, сравнение HTML source vs rendered DOM. Знаю особенности Next.js, Nuxt, Astro — где SSR работает, а где нет.
Сколько времени занимает аудит?
Срок оцениваю после инвентаризации числа классов URL, доступности логов, размера выборки и числа JS-шаблонов. Объём crawl и сценарии рендеринга фиксируются до начала проверки.
