On-page SEO: чек-лист с реальным весом каждого пункта

Откройте любой чек-лист on-page SEO. Сорок пунктов в столбик, каждый со своей галочкой – title, description, alt у картинок, H1, внутренняя перелинковка, микроразметка, скорость. Поданы они как одинаково важные: сделал всё – молодец, пропустил один – недоработал.

Это неправда, и разница в весе между пунктами такого списка – не в процентах, а в разы. Дальше – какие элементы реально участвуют в ранжировании, какие двигают только CTR при неизменной позиции, а какие можно закрыть за один вечер и забыть навсегда.

Текст для тех, кому нужно решить, с чего начинать on-page работу на реальном сайте с ограниченным временем, а не для тех, кто ищет полный список всего, что вообще можно сделать со страницей.

Чего здесь нет – инструкций «как заполнить title» построчно. Это опорная статья: она задаёт вес и порядок, а по каждому элементу ниже будет отдельный подробный материал.

И оговорка. Всё ниже – про коммерческие сайты и блоги при них, где элемент можно поменять и посмотреть на реакцию. Для крупных каталогов с десятками тысяч карточек порядок приоритетов немного другой – там на первое место выходит шаблонизация, а не ручная правка одной страницы.

Почему список из сорока пунктов не работает

Классический on-page чек-лист собран из корреляционных исследований конца двухтысячных – взяли топ-10 по тысяче запросов, посчитали, что у них общего, получили список из мета-тегов, длины текста и плотности слов. С тех пор список почти не менялся, а поиск изменился весь.

Проблема не в том, что пункты списка неверны сами по себе. Проблема в том, что он их уравнивает. Alt-текст картинки и внутренняя перелинковка сайта стоят в одном столбике с одной галочкой на каждый, будто весят одинаково. Не весят.

Разница объясняется просто, если вспомнить, на каком этапе пути документа – от обнаружения до сборки выдачи – работает каждый элемент. Часть пунктов чек-листа влияет на то, попадёт ли документ в пул кандидатов вообще. Часть – на то, как он отсортирован внутри пула. Часть – только на то, кликнут ли по нему в выдаче при равной позиции. А часть не влияет ни на что из перечисленного и существует в чек-листах по инерции.

Уравнивать эти четыре группы – значит тратить одинаковое время на разное по отдаче. Именно это происходит, когда в смете на «SEO-оптимизацию страницы» ускорение сайта и заполнение alt-текстов стоят рядом как два одинаковых пункта.

Три уровня веса

Дальше в статье каждый элемент разбирается по одной и той же рамке из трёх уровней.

Правило чтения этой таблицы простое. Если элемент уровня 1 сломан, время на уровень 2 и 3 потрачено раньше срока – переписанный title не поможет странице, которая не проходит отбор кандидатов. Если всё на уровне 1 в порядке, работа с уровнем 2 даёт трафик быстрее, чем что-либо ещё, потому что не требует роста позиций – он конвертирует уже имеющиеся показы. Уровень 3 закрывается один раз шаблоном и больше к нему возвращаться не нужно.

Title — сигнал и то, что его переписывает

Title – единственный элемент из классического списка, который работает сразу на двух уровнях: слабый лексический сигнал для ранжирования и сильный визуальный сигнал для CTR.

Как сигнал ранжирования он слабее, чем принято думать. Title – один из множества мест, где встречаются слова запроса, и без остального контента страницы он ничего не решает. Переписать title на сайте, у которого проблема с индексируемостью или отбором кандидатов, – ничего не изменит.

Как элемент CTR он весомее, чем кажется, именно потому, что поисковик title переписывает часто – под запрос, под длину, под то, что сочтёт более понятным пользователю. Ваша версия – это заявка, а не гарантия того, что покажут в выдаче.

Практический вывод из этого один. Писать title нужно не «под алгоритм», а под читателя в выдаче – коротко, по делу, с тем, что реально отличает эту страницу от девяти соседних. Обрезается заголовок примерно на границе видимой строки в интерфейсе выдачи – ориентир, а не жёсткий лимит в знаках, потому что ширина зависит от букв, а не от их количества.

Полная статистика переписывания, паттерны для шаблонных title и работа с длиной в пикселях – в отдельном материале кластера.

Description — ноль в ранжировании, всё в CTR

Тут проще всего. Description не читается алгоритмом ранжирования как фактор – это данные много раз подтверждались и много раз опровергались форумными спорами, но механически description не участвует в сопоставлении запроса с документом тем же образом, что основной текст.

Всё, что он делает, – влияет на клик. Поисковик его тоже может проигнорировать и собрать сниппет из текста страницы сам, особенно если description не отвечает точно на запрос, по которому показывается страница.

Отсюда практика, которая на уровне работы важнее теории. Писать description стоит не один универсальный, а под конкретный кластер запросов, если страница отвечает на несколько интентов разом. Один текст на все случаи почти гарантированно будет переписан хотя бы для части запросов.

Подход к написанию под кликабельность и разбор в Search Console, какие description реально доживают до выдачи, – в отдельном материале кластера.

H1–H6 — не про факторы, а про структуру

Здесь живёт больше всего мифов на квадратный метр. Разберём по одному.

Миф первый – несколько H1 на странице ломают SEO. Не ломают. Спецификация HTML давно разрешает несколько H1 в разных секциях документа, и поисковик к этому относится спокойно. Реальная проблема не в числе тегов, а в том, что если на странице три H1 и все про разное, у поиска нет ясного сигнала, о чём вообще документ.

Миф второй – заголовки нужно «оптимизировать под ключи» на каждом уровне. H1–H6 – это иерархия смысла для читателя и для парсера, который через неё понимает структуру документа. Она либо помогает сегментировать контент правильно, либо мешает – если заголовки не отражают реальные блоки текста.

Что реально стоит проверять – это соответствие иерархии логике текста. H3 без родительского H2 перед ним, два H1 подряд без раздела между, заголовок, который не описывает то, что идёт после него, – вот это реальные проблемы, потому что они сбивают сегментацию, а не потому что нарушают какое-то правило SEO.

URL — что можно трогать, а что нет

URL как лексический сигнал слабый – примерно там же, где и остальные второстепенные текстовые поля. Изменение URL ради «ключа в адресе» почти никогда не окупает риск.

А риск реальный. Смена URL – это редирект, потеря части накопленного веса на переходе, разрыв внешних ссылок, которые вели на старый адрес, и период неопределённости, пока индекс не пересчитает канонический адрес заново. Для страницы без истории это не страшно. Для страницы с трафиком и ссылками – ощутимая цена ради сигнала, которого почти не существует.

Правило простое. Новый URL проектируется читаемым и коротким с самого начала. Существующий URL с историей не трогается ради вхождения ключевого слова – только ради реальной проблемы: дублей, кириллицы, случайной вложенности на пять уровней.

Что можно менять безопасно, а что нельзя трогать никогда, разница транслита и английского – в отдельном материале кластера.

Изображения — отдельный канал, а не буст основной страницы

Alt-текст в чек-листах подаётся как строчка «SEO для картинок», и от неё почему-то ждут влияния на позиции основной страницы. Это подмена задачи.

Alt решает две другие задачи, обе важные, но не эту. Первая – доступность: без alt страницу не может понять человек, использующий скринридер. Вторая – image search, отдельный источник трафика, у которого свои правила ранжирования, отдельные от основного веб-поиска.

Если задача – трафик с картинок конкретно, тогда имя файла, alt, контекст вокруг изображения и формат имеют значение и дают измеримый результат. Если задача – продвинуть основную страницу по основному запросу, накачивание alt-текстов ключевыми словами почти ничего не даст, а с большой плотностью может выглядеть как переспам.

Разбор image search как отдельного трафикового канала, форматы без потери индексации при lazy-load – в отдельном материале кластера.

Внутренняя перелинковка — самый тяжёлый пункт списка

Вот пункт, который в типовом чек-листе стоит одной строкой между «alt-текстами» и «длиной URL», а по весу перевешивает большую часть остального списка вместе взятого.

Причина в математике, а не в мнении. Внутренняя перелинковка распределяет вес по сайту так же, как внешние ссылки распределяют его между доменами – по той же логике, что стояла за исходным PageRank. Каждая ссылка со страницы – это доля веса, переданная получателю. Страница, на которую не ведёт ни одна внутренняя ссылка, кроме меню, получает наименьшую возможную долю веса сайта, сколько бы работы ни было вложено в её title и текст.

Отсюда прямое следствие для приоритетов. Разбор «повисших» страниц – тех, на которые не ведёт ни одна контекстная ссылка изнутри контента, – обычно даёт больше эффекта, чем правка мета-тегов на этих же страницах. Причина в том, что вторая работа чинит уровень 2 и 3, а первая – уровень 1.

Практический порядок работы с перелинковкой:

1. Найти страницы без входящих контекстных ссылок – это не то же самое, что ссылки из меню и подвала, они считаются иначе.
2. Найти страницы-хабы – те, что естественным образом собирают много входящих ссылок, и убедиться, что именно там стоят ссылки на коммерчески значимые страницы.
3. Проверить анкоры – не разнообразие ради разнообразия, а соответствие анкора теме страницы назначения.
4. Проверить, не размывает ли вес меню – если в шапке сто ссылок на каждой странице сайта, каждая отдельная ссылка передаёт исчезающе маленькую долю.

Полный расчёт распределения веса, работа с висячими узлами и sculpting – в отдельном материале кластера.

Schema.org и сущности — не ранжирование, а видимость и доверие

Микроразметка – ещё один элемент, у которого репутация выше прямого эффекта на позиции. Schema.org сама по себе не поднимает документ в ранжировании. Она даёт две другие вещи.

Первая – видимость в выдаче через расширенные результаты: рейтинги, цена, хлебные крошки, FAQ-блок. Это снова уровень 2 – CTR при той же позиции, иногда с существенным приростом клика, потому что расширенный сниппет физически крупнее соседних.

Вторая – понимание сущностей. Разметка помогает поисковику однозначно связать страницу, автора и компанию с конкретной сущностью в графе знаний, а не с набором текста. Это работает медленнее и тоньше, но именно оно поддерживает сигналы вроде авторства и связи с брендом.

Практический вывод – внедрять разметку стоит там, где она физически меняет вид сниппета: товары, отзывы, FAQ, хлебные крошки, статьи с автором. Разметка ради разметки, без валидных типов и без реального соответствия контенту, риск получить ручные меры за вводящую в заблуждение семантику, а не буст.

Полный справочник по типам с примерами кода и продвинутая работа со связыванием сущностей и Wikidata – в отдельных материалах кластера.

Скрытый контент за табами и аккордеонами

Вопрос, который каждый раз всплывает на конкретном проекте: если контент спрятан за кликом – в табе, аккордеоне, «показать ещё», – его вообще читает поисковик?

Технически – да, если контент есть в HTML при загрузке страницы, а визуально скрыт только CSS. Мобильные интерфейсы годами прячут контент за раскрывающимися блоками, и поисковые системы официально ставят такой контент вровень с видимым сразу после загрузки, а не после клика.

Разница на практике в другом. Контент, до которого пользователь должен кликнуть, реже дочитывается, реже цитируется, хуже конвертирует – метрики поведения на это реагируют, даже если сама индексация не страдает. И отдельная опасность – контент, который подгружается только по клику через отдельный запрос, а не лежит в исходном HTML сразу. Тогда это уже не вопрос табов, а вопрос рендеринга, и здесь индексация действительно может пострадать.

Практическая проверка на пятнадцать минут – открыть исходный код страницы (не отрендеренный DOM, а именно view-source) и найти в нём текст, спрятанный за табом. Если текст там есть – контент индексируется. Если там пусто, а текст появляется только после клика через сетевой запрос, – это уже техническая проблема рендеринга, а не аккордеона.

Актуальный разбор с проверками на реальных примерах – в отдельном материале кластера.

Пагинация — коротко, потому что это уже не on-page

Пагинация исторически входит в on-page чек-листы, хотя по сути это вопрос архитектуры краулинга и распределения веса между страницами листинга, а не оформления одной страницы.

Коротко о состоянии на сегодня: связка rel=next/prev официально не используется Google уже несколько лет, хотя часть студий продолжает её проставлять по инерции. Рабочих паттернов для листинга сейчас три – классическая постраничная навигация с уникальным контентом на каждой странице, view-all для не слишком длинных списков и бесконечная прокрутка с поддержкой через History API, чтобы у каждой порции контента был свой доступный URL.

Здесь важно не спутать две разные проблемы. Пагинация не про on-page вес отдельной страницы – она про то, доходит ли робот вообще до последних страниц списка и не размывается ли вес между дублирующими друг друга страницами листинга. Три рабочих паттерна, view-all и бесконечная прокрутка с History API разобраны отдельно, в материале кластера про пагинацию.

Итоговый чек-лист с приоритетами

Собираем всё выше в один порядок работы – по убыванию отдачи на час вложенного времени.

Практическое правило по этой таблице – если время ограничено, пункты 1–3 закрываются в первую очередь всегда, даже если это значит отложить всё остальное на следующий спринт.

Как это выглядит на реальном проекте

Ритейлер outdoor-снаряжения – больше 400 SKU, выручка около $3,5 млн в год. Работа была именно on-page: без переписывания структуры каталога и без внешнего линкбилдинга, чтобы эффект можно было честно приписать конкретно этому блоку.

Что было на старте. 12 категорийных страниц вообще без единой входящей контекстной ссылки, кроме меню. Средняя позиция по ключевому кластеру – 28-я, третья страница выдачи. Точных данных по показам и кликам за месяц до начала работ не сохранилось – ориентиром на старте служили именно позиция и число повисших страниц, а не воронка в Search Console.

Что сделали. Проставили контекстные ссылки на эти 12 категорий с 186 товарных карточек – с тех разделов, где категория упоминается по смыслу, а не случайным блоком. Переписали сами описания категорий: было 250 слов формального текста, стало 650 слов с ответом на реальные подвопросы кластера. Добавили FAQ-микроразметку под частые вопросы по каждой категории. Заодно убрали 2 400 параметризованных URL, которые размывали краулинговый бюджет и вес на дубли фильтров и сортировок – формально это уже смежная техническая задача, но без неё эффект от перелинковки было бы сложнее выделить в чистом виде.

Результат.

Срок – 4 недели от внедрения до этих цифр.

Где мы ошиблись. На похожем по типу, но другом проекте – сайте с примерно 350 тысячами сессий в месяц – включили автоматические блоки «похожие материалы» сразу на полутысяче постов. Блок генерировал 30–60 новых внутренних ссылок на каждой странице, до 80–100 ссылок суммарно, и почти все – с одинаковыми точными анкорами.

Эффект увидели не сразу – через 6–8 недель трафик просел на 40%, позиции по ключевым запросам ушли с третьего места на девятое. В Rank Tracker обнаружилась каннибализация: по одному и тому же запросу в выдаче конкурировали 3–5 своих же URL.

Откатили 70–80% новых автоматических ссылок, поставили жёсткий лимит на число внутренних ссылок с одной страницы – около 40, переписали анкоры на смешанные формулировки вместо точных вхождений, а конкурирующие между собой URL объединили через 301-редирект. До частичного восстановления ушло 10–12 недель – заметно дольше, чем заняла сама ошибка.

Вывод из обоих случаев один и тот же, хоть и с разных сторон: перелинковка – самый тяжёлый рычаг в этом чек-листе именно потому, что двигает и вверх, и вниз сильнее остальных пунктов. Автоматизировать её без лимита на плотность ссылок и без контроля за анкорами – значит получить второй кейс вместо первого.

Сколько это занимает по времени

Цену не называю, часы – да, потому что по ним сравниваются предложения.

On-page аудит и правки для сайта на 30–50 страниц:

Что обычно удивляет в этой таблице – аудит перелинковки, самый весомый по эффекту пункт, редко занимает больше рабочего дня. Дольше всего идёт не работа руками, а ожидание, пока изменения переобойдутся и пересчитается вес.

Это я всё к чему – когда on-page аудит продают за час звонка, пропущен именно шаг с поиском повисших страниц. Без него всё остальное – косметика поверх той же структуры весов.

Три частых вопроса

С чего начинать, если руки доходят только до одного пункта в месяц?

С перелинковки. Это единственный пункт списка, который сам по себе двигает распределение веса на сайте без единой правки текста.

Правда ли, что переспам ключевыми словами в H1 наказывается отдельным фильтром?

Отдельного фильтра именно за это нет, но переспам обычно идёт в комплекте с другими проблемами текста – раздутостью, отсутствием пользы, неестественностью формулировок, – и наказывается уже общая слабость документа, а не конкретно повтор в заголовке.

Стоит ли переписывать title и description раз в квартал ради эксперимента?

Стоит, но только если есть данные для сравнения – CTR по этой странице до и после в Search Console за сопоставимые периоды. Без замера это не эксперимент, а смена текста наугад.

Ошибки, которые видно чаще других

• Правка title без разбора перелинковки. Самая частая последовательность: заметили низкий CTR, переписали title, эффекта нет, потому что позиция и так была на третьей странице выдачи из-за отсутствия внутреннего веса.
• Alt-тексты как замена нормальной работы с картинками. Ключевые слова в alt при отсутствующем сжатии и медленной загрузке изображений не меняют ничего в скорости страницы, а скорость влияет сильнее.
• Одинаковый description на весь раздел каталога. Шаблон вида «Купить [название] в [город] недорого» на тысячу карточек – это не description, а строка данных, и поиск закономерно её игнорирует и собирает сниппет сам.
• Смена URL ради вхождения ключевого слова на странице с историей. Разобрано выше – цена в редиректе и временной просадке обычно выше эффекта.
• Микроразметка без соответствия видимому контенту. Разметили рейтинг 4.9, которого нет на странице для пользователя, – риск ручных мер выше, чем польза от звёздочек в сниппете.
• Автоматическая перелинковка без лимита на плотность и разнообразие анкоров. Массовые блоки «похожих материалов» без ограничения числа ссылок на странице и без контроля за анкорами превращают самый сильный пункт чек-листа в источник каннибализации – разбор этого случая выше.

Где этот подход не работает

• Когда контент сам по себе не отвечает интенту. Никакая перелинковка не спасёт страницу, которая формально хороша по чек-листу, но не про то, что ищет человек.
• Когда сайт не проходит отбор кандидатов. On-page работа на этом уровне бессмысленна, пока не решена проблема на предыдущих этапах – индексации, дублей, языка и региона.
• На огромных каталогах. Ручная правка title и description постранично не масштабируется на десятки тысяч карточек. Там работают шаблоны и генерация по паттернам, а не список пунктов на одну страницу.
• И общее ограничение. On-page чинит то, что уже находят. Он не создаёт спрос там, где его нет, и не заменяет ссылочную массу там, где конкуренция строится на ней.

Выводы

• On-page чек-лист не должен быть плоским списком – элементы работают на разных этапах пути документа и весят по-разному.
• Внутренняя перелинковка – самый тяжёлый пункт классического списка, хотя обычно стоит в нём одной строкой среди второстепенных, и именно поэтому её проще всего сломать автоматизацией без лимитов.
• Title, description и микроразметка двигают CTR при той же позиции, а не саму позицию – это тоже трафик, но другого типа.
• H1–H6, alt-тексты и длина URL – гигиенический минимум: критично не облажаться, бессмысленно полировать сверх нормы.
• Приоритет всегда один и тот же – сначала уровень 1, потом 2, потом 3. Обратный порядок – самая частая причина, почему «сделали всё по чек-листу», а трафик не вырос.

Следующий шаг

Дальше по кластеру логично читать разбор внутренней перелинковки с математикой распределения веса и материал про то, как поисковик на самом деле переписывает title.

Если хотите проверить свой сайт за полчаса – выгрузите список страниц без единой входящей контекстной ссылки, кроме меню и подвала. На большинстве сайтов таких страниц оказывается больше, чем кажется, и это первое, с чего стоит начинать.

Разбираем такие вещи в канале, там же шаблоны и разборы реальных проектов. Подписывайтесь, если тема рабочая.