SEO чек-лист: 100 пунктов проверки сайта

Чек-лист — это не список «сделай красиво», а способ за несколько часов понять, где именно сайт теряет деньги. Мы собрали 100 пунктов, через которые проходим на каждом проекте: от кодов ответа сервера и robots.txt до коммерческих факторов, ссылочного профиля и настройки целей в аналитике. Каждый блок идёт с приоритетом: что чинить в первый день, что можно отложить на месяц, а что вообще не трогать, пока не закрыты базовые вещи. Порядок здесь важнее полноты — половина сайтов проваливается не из-за экзотики, а потому что робот банально не может обойти каталог. Если разбирать проблемы некогда, мы возьмём это на себя в рамках SEO-продвижения.

Как работать с чек-листом: приоритеты и критичность

Главная ошибка при работе с любым чек-листом — идти по нему подряд и одинаково усердно. В реальности пункты имеют разный вес и, что важнее, разную зависимость друг от друга. Пока страница не в индексе, её title не имеет значения. Пока каталог отдаёт 500 на каждый десятый запрос, нет смысла обсуждать перелинковку. Пока сайт не открывается на телефоне, коммерческие факторы никого не спасут.

Поэтому мы делим все 100 пунктов на три уровня критичности. Блокирующие — те, что физически не дают сайту ранжироваться: закрытая индексация, неверные коды ответа, массовые дубли, отсутствие мобильной версии, аффилиат или фильтр. Значимые — те, что определяют разницу между десятым и третьим местом: качество контента, структура, коммерческие факторы, скорость, ссылочный профиль. Улучшающие — те, что дают проценты: alt у изображений, микроразметка расширенных сниппетов, тонкая настройка внутренних анкоров.

Правило простое: не переходите к следующему уровню, пока не закрыт предыдущий. Оно звучит банально, но нарушается постоянно — подрядчики любят показывать работу там, где её видно (тексты, ссылки), а не там, где она нужна (сервер, дубли, коды ответа). Если вы разбираете сайт после предыдущего исполнителя, начните с этого разделения: часто оказывается, что за год работы блокирующие пункты так и не закрыты. Подробную методику полной диагностики мы разбирали в материале про SEO-аудит сайта.

Блок 1. Индексация и доступность (пункты 1–14)

Это фундамент. Если робот не может обойти сайт или ему запрещено это делать, всё остальное не имеет смысла. Проверять нужно отдельно в Яндексе и Google — расхождения между системами нормальны и информативны.

1. Сайт добавлен и подтверждён в Яндекс Вебмастере и Google Search Console. Без этого вы работаете вслепую — нет данных ни по индексу, ни по ошибкам, ни по запросам.
2. Количество страниц в индексе сопоставимо с количеством нужных страниц. Считаем: сколько страниц должно быть в поиске и сколько есть по факту. Разрыв в разы — красный флаг в обе стороны: недобор означает проблемы обхода, перебор — мусор и дубли.
3. Главная страница в индексе и находится по названию компании. Если нет — это признак фильтра, склейки или недавнего переезда.
4. В robots.txt нет случайного Disallow: / — классика после переноса с тестового домена. Проверяйте после каждого релиза.
5. Служебные разделы закрыты, а нужные — открыты. Корзина, личный кабинет, результаты поиска по сайту, UTM-мусор — закрыты. Каталог, карточки, статьи, услуги — открыты.
6. JS и CSS не заблокированы для робота. Иначе поисковик не отрендерит страницу и увидит сломанный макет.
7. Нет ошибочных meta name="robots" content="noindex". Особенно на шаблонах: один noindex в шаблоне карточки убирает из поиска весь каталог.
8. Нет запрещающего X-Robots-Tag в заголовках ответа. Этот запрет невидим в коде страницы, ищите его в HTTP-заголовках.
9. Sitemap.xml существует, отдаёт 200 и содержит только канонические URL с кодом 200. Мусор в карте сайта тратит краулинговый бюджет и подрывает доверие к файлу.
10. Sitemap указан в robots.txt и загружен в оба вебмастера. Даты lastmod обновляются честно, а не «сегодня» у всех страниц.
11. Важные страницы доступны в 3 клика от главной. Глубина вложенности напрямую влияет на частоту обхода.
12. Нет страниц-сирот — тех, на которые не ведёт ни одна внутренняя ссылка. Они попадают в индекс медленно и ранжируются плохо.
13. Новые страницы индексируются за разумный срок. Для живого сайта это дни, а не месяцы. Если новая карточка не в индексе через две недели — проблема с обходом.
14. Настроен переобход важных страниц через инструменты вебмастера после значимых правок.

Разбор типовых причин, по которым страницы не попадают в поиск, и способы ускорить обход — в отдельном материале про индексацию сайта в Яндексе. Если сайт крупный, параллельно читайте про краулинговый бюджет: на каталогах от 10 000 страниц именно он определяет, дойдёт ли робот до ваших товаров.

Блок 2. Техническая база: коды ответа, дубли, протокол (пункты 15–34)

Техническая часть — это то, что почти не видно пользователю, но полностью определяет, как поисковик понимает сайт. Здесь работают краулеры вроде Screaming Frog, Netpeak Spider или встроенных инструментов вебмастеров: без обхода всего сайта эти пункты не закрыть.

Коды ответа и редиректы

15. Все продвигаемые страницы отдают 200. Не 200 с текстом «страница не найдена», а честный 200 с контентом.
16. Несуществующие URL отдают 404, а не 200. Soft 404 засоряют индекс пустышками и размывают релевантность.
17. Страница 404 оформлена: шапка, меню, поиск, ссылки на популярные разделы. Пользователь не должен упираться в тупик.
18. Нет цепочек редиректов длиннее одного шага. Каждое звено — потеря веса и времени обхода.
19. Нет циклических редиректов и редиректов на 404.
20. Используется 301, а не 302, там, где переезд постоянный. Временный редирект не передаёт вес так же надёжно.
21. Нет массовых битых ссылок. Внутренние 404 — прямой сигнал заброшенности.
22. Сервер стабилен: нет 5xx при обходе. Регулярные 500 при краулинге означают, что робот будет заходить реже.
23. Время ответа сервера (TTFB) в пределах 200–500 мс. Секунда и больше — тормоз для обхода всего сайта.

Дубли и канонизация

24. Одна страница — один URL. Версии со слешем и без, с index.php и без, в разном регистре склеены редиректом.
25. Выбрано главное зеркало (с www или без), остальное — 301 на него.
26. Canonical проставлен корректно и указывает на существующую каноническую страницу с кодом 200, а не на главную «на всякий случай».
27. Страницы с UTM и другими параметрами не плодят дубли — закрыты через canonical или Clean-param.
28. Нет дублей по контенту: одинаковые описания товаров разных размеров, копии услуг под каждый район.
29. Пагинация настроена корректно: страницы 2, 3, N доступны роботу, но не конкурируют с первой.
30. Фильтры каталога не генерируют бесконечность. Открыты только те комбинации, под которые есть спрос, остальные — закрыты.

Протокол, домен, хостинг

31. Сайт работает по HTTPS, сертификат валиден и не истекает через неделю.
32. Весь HTTP жёстко редиректит на HTTPS, нет смешанного контента.
33. Хостинг выдерживает нагрузку и расположен в регионе основной аудитории.
34. Регион сайта задан в Вебмастере и соответствует реальной географии бизнеса.

Детально механику склейки разбираем в статье про canonical и дубли страниц, а правила настройки переадресаций — в материале про 301 редиректы. Если сайт на 1С-Битрикс, отдельно проверьте типовые дубли этой CMS — их там больше, чем кажется.

Блок 3. Скорость и Core Web Vitals (пункты 35–44)

Скорость — это и фактор ранжирования, и фактор конверсии. Причём второе важнее: пользователь, ушедший до загрузки, портит поведенческие метрики, а они в Яндексе весят много.

35. LCP (отрисовка основного контента) укладывается в 2,5 секунды на мобильных при реальных условиях, а не в лабораторном тесте на десктопе.
36. CLS (сдвиг макета) ниже 0,1. Основная причина превышения — картинки и баннеры без заданных размеров.
37. INP (отклик на действие) ниже 200 мс. Тяжёлые скрипты и чаты-виджеты — главные виновники.
38. Изображения в WebP или AVIF, сжаты и отдаются в нужном разрешении, а не масштабируются браузером с 3000 px до 300 px.
39. Lazy loading включён для картинок ниже первого экрана и выключен для LCP-изображения.
40. Включено сжатие Gzip или Brotli на сервере.
41. Настроено кеширование статики заголовками Cache-Control на длительный срок.
42. CSS и JS минифицированы, неиспользуемый код вырезан, критический CSS вынесен.
43. Сторонние скрипты под контролем. Каждый счётчик, чат и пиксель — это плюс к времени загрузки. Их должно быть ровно столько, сколько реально используется.
44. Шрифты подгружаются с font-display: swap и не блокируют отрисовку текста.

Пороговые значения и способы дожать метрики до зелёной зоны собраны в разборе Core Web Vitals, там же — пороги и способы дожать метрики до зелёной зоны.

Блок 4. Мобильная версия (пункты 45–52)

В большинстве коммерческих ниш мобильный трафик преобладает над десктопным — точную долю по своему проекту смотрите в Яндекс Метрике, отчёт «Устройства». Проверять сайт нужно с телефона руками, а не только через эмулятор в браузере.

45. Сайт адаптивен и корректно отображается на экранах от 320 px.
46. Нет горизонтальной прокрутки ни на одной странице.
47. Контент мобильной версии совпадает с десктопной. Урезанный мобильный текст — прямая потеря релевантности.
48. Кликабельные элементы не меньше 44×44 px и не липнут друг к другу.
49. Шрифт основного текста не мельче 16 px, контраст достаточный.
50. Телефон кликабелен и открывает звонилку по tel:.
51. Нет всплывающих окон, перекрывающих контент сразу после загрузки — это и раздражение, и риск понижения.
52. Формы удобны на телефоне: правильные типы полей, автозаполнение, минимум обязательных значений.

Полный разбор адаптива и типовых мобильных ошибок — в статье про мобильную оптимизацию сайта.

Блок 5. Семантика и структура (пункты 53–66)

Здесь заканчивается техника и начинается маркетинг. Ошибки в семантике не видны в краулере — они видны только в деньгах: сайт технически безупречен, а трафик идёт по запросам, которые не приносят заявок.

53. Собрано полное семантическое ядро из Вордстата, поисковых подсказок, счётчиков и семантики конкурентов, а не «десять запросов, которые вспомнил директор».
54. Ядро очищено от мусора: чужие бренды, информационные запросы там, где нужен коммерческий интент, нерелевантные регионы.
55. Запросы кластеризованы по выдаче, а не «по смыслу на глаз». Два запроса ставятся на одну страницу, только если в ТОПе по ним пересекаются одни и те же URL.
56. Каждый кластер имеет свою посадочную страницу. Нет кластеров без страниц и страниц без кластеров.
57. Нет каннибализации: два URL не борются за один и тот же запрос.
58. Разделены коммерческий и информационный интенты. Под «купить» — каталог, под «как выбрать» — статья в блоге.
59. Структура сайта построена от спроса, а не от внутренней логики компании и не от структуры прайса 1С.
60. Есть посадочные под все значимые фильтры и подкатегории, у которых есть частотность.
61. Есть страницы под регионы, если бизнес работает в нескольких городах, и они не являются копиями друг друга.
62. URL человекопонятные, латиницей, без длинных идентификаторов и без кириллицы в адресе.
63. URL отражают вложенность и не меняются при переносе товара между категориями.
64. Хлебные крошки есть на всех вложенных страницах и размечены Schema.org.
65. Меню содержит все ключевые разделы и реализовано обычными ссылками с href.
66. Перелинковка работает на приоритеты: чем важнее страница, тем больше внутренних ссылок на неё.

Методику сбора ядра разбираем в материале про семантическое ядро сайта, а проектирование разделов — в разборе структуры сайта для SEO.

Блок 6. Контент и метатеги (пункты 67–82)

Контент проверяется не «уникальностью по антиплагиату», а способностью закрыть задачу пользователя лучше, чем это делают сайты из ТОПа. Всё остальное — производные.

Метатеги и заголовки

67. Title уникален на каждой странице, содержит главный запрос ближе к началу и укладывается примерно в 60 символов видимой части.
68. Title читаем и продающий, а не «Купить окна окна пластиковые окна Москва недорого».
69. Description уникален, 150–180 символов, содержит выгоду и призыв — он влияет на CTR, а CTR влияет на позиции.
70. Один H1 на страницу, он не дублирует title слово в слово.
71. Заголовки H2–H3 выстроены иерархично и используются по смыслу, а не для увеличения шрифта.
72. У всех изображений заполнен alt, осмысленно и без перечисления ключей.
73. Имена файлов картинок транслитерированы и описывают содержимое.
74. Настроена микроразметка Schema.org под тип страницы: Organization, Product, Article, FAQPage, BreadcrumbList.
75. Разметка проходит валидацию в инструментах Яндекса и Google без ошибок.

Качество текстов

76. Текст отвечает на запрос в первом экране, а не после трёх абзацев про «динамично развивающуюся компанию».
77. Объём соответствует ТОПу по запросу: не больше и не меньше, а сопоставимо с тем, что уже ранжируется.
78. Нет переспама: плотность ключей естественная, точных вхождений — минимум необходимого.
79. Тошнота и водность в норме, текст не наполнен канцеляритом ради объёма.
80. Есть LSI-лексика — слова, которые обязаны встречаться в экспертном тексте по теме.
81. Контент уникален по смыслу, а не только по проценту шингла. Рерайт чужой статьи технически уникален и бесполезен.
82. Текст оформлен для чтения: списки, таблицы, подзаголовки каждые 2–3 абзаца, изображения по делу.

Как писать так, чтобы не попасть под Баден-Баден и при этом ранжироваться, — в материале про SEO-тексты без переспама.

Блок 7. Коммерческие факторы и доверие (пункты 83–90)

Для коммерческих запросов в Яндексе это часто решающий блок. Два сайта с одинаковыми текстами и ссылками ранжируются по-разному именно из-за того, насколько полно закрыты вопросы покупателя: сколько стоит, как доставят, кому платить, можно ли вернуть.

Полный перечень того, что оценивает Яндекс в коммерческой выдаче, мы разбирали в статье про коммерческие факторы, а требования к экспертности и доверию — в материале про E-E-A-T. Отдельно отметим: коммерческие факторы — самый недооценённый блок чек-листа. Их правка обычно стоит дёшево (это работа контент-менеджера, а не разработчика), а эффект на коммерческих запросах бывает заметнее, чем от ссылочного бюджета в сотни тысяч рублей.

Блок 8. Поведенческие факторы и юзабилити (пункты 91–94)

91. Первый экран отвечает на вопрос «куда я попал и что здесь можно сделать». Оффер, а не абстрактный слайдер.
92. Путь до целевого действия короткий: заявка, звонок или заказ — в 1–2 клика с любой страницы.
93. Нет агрессивных элементов, которые выталкивают пользователя обратно в выдачу: автозвук, всплывашки через 3 секунды, требование регистрации до просмотра цен.
94. Показатель отказов и глубина просмотра сопоставимы со средними по нише — их видно в Метрике по срезу поискового трафика.

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

Блок 9. Ссылочный профиль (пункты 95–97)

95. Ссылочная масса растёт плавно и сопоставима с профилями сайтов из ТОПа по нише. Резкий скачок в сотни доменов за месяц — сигнал для Минусинска.
96. Анкор-лист естественный: преобладают безанкорные, брендовые и url-анкоры, коммерческих точных вхождений — небольшая доля.
97. Доноры живые и тематические, без следов сеток: реальный трафик, история, разумное количество исходящих ссылок. Токсичные доноры отклонены.

Безопасные схемы наращивания массы разобраны в статье про ссылочное продвижение — там же правила составления безопасного анкор-листа.

Блок 10. Аналитика и контроль (пункты 98–100)

98. Метрика и Google Analytics установлены корректно, без дублей счётчика, с включённым вебвизором и картами кликов.
99. Настроены цели на все конверсии: отправка формы, клик по телефону, клик в мессенджер, оформление заказа. Без целей SEO нельзя оценить — только «посмотреть графики трафика».
100. Настроен регулярный контроль: съём позиций, отслеживание индекса, уведомления вебмастера, ежемесячный отчёт с привязкой трафика к заявкам и выручке.

Как связать позиции с деньгами и не утонуть в отчётах — в материале про оценку эффективности SEO.

Как пройти чек-лист за один рабочий цикл

Ниже — последовательность, по которой мы проходим сайт на старте проекта. Она рассчитана примерно на 20–40 часов работы для сайта на 500–5000 страниц.

Чем проверять: инструменты по блокам

Чек-лист не заменяет мышления. Сто галочек, проставленных без понимания причин, дают ноль. Одна закрытая блокирующая проблема, найденная осознанно, — рост.

Что делать после того, как чек-лист пройден

Пройденный чек-лист — это список задач, а не результат. Дальше начинается работа, у которой есть свой ритм. Блокирующие проблемы закрываются сразу, в первые одну-две недели, и обычно дают первый видимый эффект уже через месяц-полтора — после того, как робот переобойдёт исправленные страницы. Значимые пункты — семантика, структура, контент, коммерческие факторы — растягиваются на месяцы, и здесь важна регулярность: 10–15 доработанных страниц в месяц дают больше, чем героический рывок раз в полгода.

Второй момент: чек-лист нужно проходить повторно. Сайт живёт — программисты выкатывают релизы, контент-менеджеры добавляют товары, маркетологи вешают новые скрипты. Мы возвращаемся к техническому блоку раз в квартал и после каждого крупного релиза. Типичный сценарий провала выглядит так: полгода растём, потом разработчики обновляют шаблон карточки — и вместе с обновлением прилетает noindex или ломается canonical. Без регулярной проверки это выясняется через два месяца, когда трафик уже просел. О том, как диагностировать такие провалы, мы писали в материале про то, почему сайт упал в выдаче.

Третий момент — честная оценка ресурсов. Если в компании нет разработчика, готового править техничку, и контент-менеджера, готового писать по ТЗ, чек-лист останется красивым документом. Именно поэтому в наших проектах приоритеты расставляются с учётом того, что заказчик реально может внедрить. Понимание бюджета помогает планировать: ориентиры по рынку мы разбирали в статье про стоимость SEO-продвижения, а актуальные тарифы всегда есть на странице цен. Пока техническая база приводится в порядок и идёт переиндексация, спрос можно снимать контекстной рекламой — это стандартная схема для первых двух-трёх месяцев проекта. Примеры того, что получалось у наших клиентов после такой работы, собраны в портфолио.

Частые вопросы