Технический фундамент сайта для роста в поиске

Почему «прогон через Screaming Frog» — это не аудит

Главная ошибка большинства SEO-агентств — выдавать сырой отчёт сканера за технический аудит. Screaming Frog (или Sitebulb, Ahrefs) даёт массив данных: списки страниц с 404, мета-тегами без описаний, дублями title. Но интерпретация этого массива и есть работа SEO-специалиста.

На реальном сайте из 5000 страниц инструмент находит ~300 проблем. Половина из них несущественные (например, ALT на декоративном изображении). Четверть — последствия других проблем (404 на удалённых товарах, которых давно нет в каталоге). И только оставшаяся часть — это действительно работа: исправить, расставить приоритеты, согласовать с разработчиками.

Хороший аудит — это документ с 30 конкретными действиями, отсортированными по влиянию × затратам. Не «по всем страницам исправить ALT» (это бесконечно), а «исправить ALT на 50 коммерческих посадочных, остальное — по мере правок дизайна».

Core Web Vitals: что реально влияет на ранжирование

С июня 2021 Google ввёл Page Experience как фактор ранжирования. С тех пор обновления алгоритма (в т.ч. Helpful Content Update и его наследники) усилили вес метрик. Сегодня LCP > 4 секунд на мобильном — это почти гарантированная потеря позиций по конкурентным запросам.

Три метрики, которые считают и Google, и Яндекс. LCP (Largest Contentful Paint) — за сколько грузится самый крупный элемент видимой области, цель < 2.5s. INP (Interaction to Next Paint) — задержка отклика на действие пользователя, цель < 200ms. CLS (Cumulative Layout Shift) — насколько прыгает вёрстка при загрузке, цель < 0.1.

Типичные виновники медленной LCP: огромное hero-изображение без WebP/AVIF и lazy loading, синхронные сторонние скрипты в head, не оптимизированные шрифты. INP ломают тяжёлые обработчики кликов (особенно у виджетов аналитики) и Long Tasks в JS. CLS — изображения и баннеры без явных размеров.

Замеряем не на «лабораторных» данных Lighthouse, а на реальном поле в Search Console (Field Data) — это то, что видит Google. Расхождение между лабораторными и реальными метриками — частое явление, особенно для мобильного трафика 3G/4G.

Микроразметка Schema.org: чек-лист для большинства сайтов

Schema.org — структурированные данные, которые объясняют поисковику, что именно находится на странице: товар это или статья, кто автор, сколько отзывов, какая цена. Грамотная разметка даёт расширенные сниппеты (звёзды отзывов, цена, FAQ-блоки прямо в выдаче), что повышает CTR на 15–30%.

Для коммерческого сайта обязательны: Organization (главная), BreadcrumbList (все внутренние), Product + Offer + AggregateRating (карточки товаров), Service (страницы услуг), FAQPage (страницы с FAQ), LocalBusiness (для локальных бизнесов). Для блога — Article + Person + ImageObject.

Проверяем разметку через Schema Markup Validator от Schema.org и Rich Results Test от Google. После внедрения отслеживаем в Search Console раздел «Улучшения» — там видно, сколько страниц получили rich results и какие ошибки. Яндекс использует свой валидатор и не всю разметку Schema.org понимает — кое-где приходится дополнять микроформатами.

Индексация: главный «невидимый» провал большинства сайтов

Сайт может выглядеть здоровым, но из 1500 страниц в индексе у Google — только 200. Остальные либо проигнорированы (Crawled — currently not indexed), либо помечены как дубли. По данным Search Console раздел «Покрытие» показывает реальную картину — её первым делом и смотрим в аудите.

Основные причины плохой индексации: тонкий или дублированный контент (особенно в каталогах с множеством фильтров), отсутствие или сломанный sitemap.xml, медленная скорость сайта (Googlebot имеет лимит по времени на сканирование — crawl budget), отсутствие внутренних ссылок на страницу (orphan pages).

Решение зависит от причины. Иногда достаточно обновить sitemap и запросить переобход. Чаще приходится бороться с тонким контентом: либо удалять/объединять страницы (caталоги-фильтры), либо наращивать уникальный контент. Для крупных сайтов важна оптимизация crawl budget — это отдельная техническая задача.