Как работает поиск и зачем нужно SEO

Разбираемся, как поисковик находит и ранжирует страницы — и почему позиции это следствие, а не цель.

08:24 видео ~4 мин конспект

Видео урока

08:24

00:0008:24

Расшифровка видеотекстом, с таймкодами

Чему научитесь в этом уроке

Что такое Core Web Vitals и почему это важно
Три ключевые метрики: LCP, INP, CLS
Как измерять: PageSpeed Insights, Search Console
Что и как чинить

Core Web Vitals — три метрики скорости и стабильности сайта от Google, которые с 2021 года официально влияют на ранжирование. Яндекс с 2023 тоже учитывает скорость напрямую (через ИКС и «скоростные» сигналы Метрики). Игнорировать нельзя.

Простыми словами: пользователь не должен страдать на сайте. Долго грузится? Тыкает кнопку, а сайт не реагирует? Контент прыгает при загрузке? Всё это — минус позиции.

Три метрики Core Web Vitals

Зелёная зона — цель; красная — поиск понижает

LCP — Largest Contentful Paint. Сколько секунд проходит от клика по ссылке до момента, когда показалась самая большая видимая часть страницы (обычно — главное изображение или заголовок).

до 2,5 секХорошо

2,5–4 секТерпимо

>4 секПлохо

INP — Interaction to Next Paint. С марта 2024 заменил FID. Замеряет: пользователь нажал кнопку — сколько прошло до видимой реакции сайта.

до 200 мсХорошо

200–500 мсТерпимо

>500 мсПлохо

CLS — Cumulative Layout Shift. Насколько сильно «прыгает» контент при загрузке. Когда вы читаете заголовок — а сверху подгрузилась реклама и заголовок улетел вниз. Это плохой CLS.

до 0,1Хорошо

0,1–0,25Терпимо

>0,25Плохо

Чем измерять — три бесплатных инструмента

1. PageSpeed Insights (pagespeed.web.dev). Главный инструмент. Вставили URL — за 30 секунд получили оценку Mobile/Desktop, цифры по LCP/INP/CLS, и список конкретных проблем с приоритетами. Используйте Mobile (большая часть трафика — мобильный).

PageSpeed Insights · Mobile · ваш-сайт.ru

Performance — требует улучшений
Данные реальных пользователей (CrUX)

LCP — отрисовка3,8 с · плохо

INP — отклик240 мс · плохо

CLS — сдвиги0,18 · плохо

Так выглядит «красный» отчёт: круг оценки и три метрики с вердиктом. Цель — увести каждую цифру в зелёное

2. Google Search Console → Core Web Vitals. Реальные данные с пользователей вашего сайта (не лабораторные). Показывает, какие URL «хорошие», какие «требуют улучшений», какие «плохие». Эти же группы видит и поиск.

Search Console · Основные интернет-показатели · Mobile

Плохо214 URL

Требуют улучшений389 URL

Хорошо1 642 URL

Причина «Плохо»: CLS > 0,25 на 214 URL → шаблон карточки товара

Полевые данные по сайту: одна общая проблема в шаблоне роняет сразу сотни URL — чинишь шаблон, чинятся все

3. Lighthouse в Chrome DevTools. F12 → вкладка Lighthouse → Generate report. Локальный аудит, тот же движок что у PageSpeed Insights.

Lighthouse даёт четыре круга оценки сразу. Зелёные не трогаем — работаем по красному

Что чинить: топ-7 проблем и решения

Тяжёлые изображения. Самая частая проблема LCP. Решение: WebP/AVIF вместо JPEG (вес меньше в 2–3 раза), loading="lazy" на изображения ниже первого экрана, <picture> с разными разрешениями.
Изображения без размеров. Главная причина плохого CLS. <img> без атрибутов width и height — браузер не знает место, контент после неё подпрыгивает. Решение: всегда указывайте размеры или aspect-ratio в CSS.
Шрифты без font-display: swap. Текст не виден, пока не загрузился шрифт — это удар по LCP. Решение: в @font-face добавить font-display: swap;
Тяжёлый JS на главном потоке. Виджеты соцсетей, чаты, аналитика — всё в одном потоке. Решение: defer или async на скриптах, не блокирующих рендер.
Render-blocking CSS. Огромный CSS-файл в <head>, не оптимизирован. Решение: вынести критический CSS inline, остальное — preload+defer.
Нет CDN или плохой хостинг. TTFB > 600 мс — сайт медленный ещё до того, как начал грузиться. Решение: Cloudflare (бесплатно), нормальный хостинг.
Лишние редиректы. Цепочка http → https → www → non-www съедает 500 мс. Решение: оставить один редирект, остальные — прямые ссылки.

Пример: что покажет PageSpeed Insights

Загружаете сайт на pagespeed.web.dev → получаете отчёт вида:

Performance: 67 (Mobile)
 LCP: 3.8s ← медленно
 INP: 240ms ← медленно
 CLS: 0.18 ← медленно

Opportunities (приоритет):
 - Properly size images → save 1.4s
 - Defer offscreen images → save 0.6s
 - Eliminate render-blocking → save 0.4s
 - Reduce unused CSS → save 0.2s

Diagnostics:
 - Image elements have explicit width and height: 12/47 missing
 - Avoid an excessive DOM size: 1832 nodes

Это рабочий список. Идёте сверху по приоритету — обычно первые 2-3 пункта дают 80% улучшения.

Так

Обложка первого экрана — WebP до 200 КБ
У каждого <img> прописаны width и height
Картинки ниже экрана — loading="lazy"
Чат и счётчики — через defer/async после загрузки

Не так

JPEG-обложка 4 МБ — главный убийца LCP
<img> без размеров — вёрстка прыгает, CLS в красном
Все картинки грузятся сразу при открытии
Виджет соцсетей в <head> блокирует рендер

Симптом	Бьёт по	Что делать первым
Обложка-картинка 4 МБ на первом экране	LCP	Пересохранить в WebP, ужать до 200 КБ
Картинки без width/height	CLS	Прописать размеры или aspect-ratio
Чат и виджеты грузятся сразу	INP	Подключать через defer/async
Шрифт без font-display: swap	LCP	Добавить swap в @font-face
Цепочка редиректов http→https→www	TTFB / LCP	Оставить один прямой редирект

Важно: PageSpeed Insights показывает 2 цифры — лабораторную (полученную в эмуляторе) и полевую (CrUX — реальные пользователи). Поиск смотрит на CrUX. Если у вас лабораторная 95, а CrUX «плохо» — реальный сайт медленный, и позиции будут страдать.

Чек-лист скорости

Все картинки в WebP/AVIF, не больше 200 КБ каждая.
У всех <img> прописаны width и height.
Lazy-loading на изображениях ниже первого экрана.
font-display: swap в @font-face.
Тяжёлый JS — с defer или async.
Метрика, чаты, виджеты — асинхронно или после загрузки страницы.
TTFB до 600 мс (проверить на webpagetest.org).
В Search Console раздел Core Web Vitals — нет URL в «плохо».

Материалы урока

Скачать все материалы урока (.zip)