Технический SEO-аудит сайта самостоятельно: чек-лист из 45 критических ошибок

Введение: зачем владельцу сайта самостоятельно проводить технический SEO-аудит и как использовать чек-лист из 45 ошибок для быстрого выявления критических проблем

Представьте: вы запустили рекламу, потратили бюджет на контент, а позиции в выдаче стоят на месте. При этом конкуренты с более слабым текстом обгоняют вас. Причина часто не в маркетинге, а в технике — робот просто не может полноценно проиндексировать страницы. Один забытый Disallow: / в robots.txt способен обнулить месяцы работы: краулинг блокируется, страницы выпадают из индекса, трафик падает в ноль. Такие ошибки не видны в интерфейсе сайта, но их видит поисковик — и наказывает за них бизнес.

Почему технический аудит нельзя откладывать «на потом»

Технические ошибки делятся на два типа по цене. Первые бьют по видимости: закрытые в robots.txt разделы, noindex на важных страницах, битые канонические URL — всё это напрямую выключает страницы из индексации. Вторые бьют по конверсии и бюджету: медленный сервер, неоптимизированные изображения, «прыгающий» layout с высоким CLS — пользователь уходит до того, как увидит оффер, а поисковик занижает позиции из-за плохих Core Web Vitals.

Проблема в том, что владелец бизнеса обычно узнаёт о таких сбоях последним — из отчёта подрядчика или после резкого проседания трафика. К этому моменту потери уже накоплены: недополученные заявки, слитый рекламный бюджет, упущенные сезонные пики.

Технический SEO-аудит — это не разовая проверка «для галочки», а регулярная диагностика здоровья сайта, которая дешевле любого простоя в выдаче.

Что даёт чек-лист из 45 ошибок: скорость и приоритеты

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

Чек-лист закрывает семь ключевых зон:

• Индексация — robots.txt, sitemap.xml, мета-теги robots, канонические URL;
• Краулинг и дубли — битые ссылки, редиректы, зеркала, параметры, пагинация;
• Скорость и Core Web Vitals — LCP, INP, CLS, кэширование, сжатие;
• Архитектура и перелинковка — структура URL, навигация, хлебные крошки;
• Мобильность и юзабилити — вьюпорт, тач-элементы, шрифты, попапы;
• Алгоритмические сигналы — разметка, HTTPS, коды ответов сервера;
• Действия по исправлению — приоритизация и порядок работ.

Каждый пункт сформулирован как конкретная проверяемая ошибка, а не абстрактная рекомендация. Это важно: такой формат позволяет владельцу или его маркетологу пройти по списку за один-два вечера, не имея глубокой технической подготовки, и получить не «диагноз вообще», а точный список правок с понятным эффектом.

Как читать эту статью и использовать чек-лист

Дальше мы идём по зонам последовательно: от индексации к краулингу, затем к скорости, архитектуре, мобильности и сигналам безопасности. В каждом разделе — конкретные примеры ошибок, способы их обнаружить бесплатными инструментами (Search Console, Яндекс Вебмастер, Lighthouse, Screaming Frog в базовой версии) и рабочие решения.

Практический приём: заведите таблицу с колонками «Пункт чек-листа — Статус — Приоритет — Ответственный — Срок». Проходя раздел за разделом, вы сразу фиксируете найденные проблемы и не теряете их. Критичные сбои индексации (пункты первой зоны) закрывайте в первую очередь — они дают максимальный прирост видимости при минимальных трудозатратах.

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

Логика статьи построена так, чтобы вы могли идти строго по списку сверху вниз или выборочно проверить подозрительную зону. В любом случае к концу у вас будет рабочий чек-лист и приоритизированный план действий — без мистики и «магии» вокруг SEO.

Начните с самого дорогого риска

Если времени мало, начните с первой зоны — индексации. Именно там ошибки стоят дороже всего: одна строка в robots.txt или неверный canonical способны убрать из выдачи десятки страниц, а восстановление позиций после возврата в индекс занимает недели. Остальные ошибки важны, но редко обнуляют трафик так быстро.

Проверка индексации: ошибки в robots.txt, sitemap.xml, мета-тегах robots и канонических URL, которые блокируют попадание страниц в поиск

Индексация — это фундамент, на котором держится вся видимость сайта в поиске. Если страница не попала в индекс, никакой контент, скорость загрузки или перелинковка уже не имеют значения: её просто нет в выдаче. Проверку индексации удобно вести в четыре шага — от самого «грубого» инструмента (robots.txt) к самому точечному (canonical). Разберём каждый с типичными ошибками и способами их обнаружить.

Шаг 1. robots.txt: проверяем, что вы не запретили лишнего

robots.txt — первая точка, где робот решает, стоит ли вообще заходить на страницу. Главная ошибка здесь — «слепой» запрет через Disallow: /, который остаётся после переноса сайта с тестового домена или закрытия dev-копии. Робот послушно не обходит ни одной страницы, а владелец месяцами не понимает, почему новые материалы не появляются в поиске.

Что проверить в файле:

• Директивы для боевого робота. Убедитесь, что в User-agent: * нет запретов на разделы, которые должны индексироваться: каталог, статьи, карточки товаров.
• Закрытые служебные зоны. Корректно закрывать /cart, /checkout, /search?, /admin, а не весь сайт.
• Синтаксис. Опечатка вроде Disallow: /catalog / (лишний пробел) или неверный регистр директивы превращает правило в мусор, и робот игнорирует строку.
• Директива Sitemap. В конце файла должен быть указан актуальный адрес карты сайта: Sitemap: https://site.ru/sitemap.xml.

Проверять файл удобно в панели Яндекс Вебмастера и Google Search Console — обе показывают, как робот прочитал конкретные строки, и подсвечивают конфликты правил.

Шаг 2. sitemap.xml: карта, которая ведёт в никуда

Sitemap — это заявка «вот мои важные страницы, обойдите их». Ошибка номер один — карта, которая генерируется автоматически, но не обновляется, и содержит URL удалённых товаров, старых акций и страниц-редиректов. Робот переходит по таким адресам, получает 404 или 301, и доверие к карте падает.

Типичные проблемы и их симптомы:

• Битые и редиректные URL. В карте должны быть только страницы с кодом 200. Проверяется выгрузкой URL и массовым прогоном через сканер (Screaming Frog, Sitebulb).
• Страницы, закрытые в robots.txt. Парадокс: вы просите обойти страницу в sitemap и одновременно запрещаете её в robots.txt. Search Console покажет это как «Проиндексировано, несмотря на запрет» или «Исключено».
• Превышение лимита. В одном файле — не более 50 000 URL и 50 МБ; при большей маске нужен sitemap-индекс, ссылающийся на несколько файлов.
• Noindex-страницы в карте. Страницы пагинации, фильтров и служебные разделы не должны попадать в sitemap.

После правок карту заново отправляйте в обе панели вебмастера — статус обработки покажет, сколько URL принято, а сколько отклонено.

Шаг 3. Мета-тег robots и canonical: точечные «выключатели»

Мета-тег <meta name="robots" content="..."> управляет индексацией конкретной страницы. Самая дорогая ошибка — noindex, который остался в шаблоне после тестирования нового раздела или рассылки. При этом страница может быть открыта в sitemap и не закрыта в robots.txt: робот заходит, видит noindex, и страница выпадает из выдачи.

Ошибка в одном шаблоне meta robots способна убрать из поиска целый раздел — тысячи карточек или статей, — и вы заметите это только по просевшему трафику через несколько недель.

Смежная ловушка — конфликт noindex и canonical. Если страница одновременно помечена как «не индексировать» и имеет canonical на другой URL, роботы трактуют сигналы по-разному: Google в этом случае игнорирует canonical, а поведение Яндекса зависит от приоритета. Правило простое: не смешивайте noindex и canonical на одной странице.

Отдельно про canonical: неверный канонический URL — частая причина, по которой нужные страницы не индексируются, а вес уходит на дубль. Проверьте:

• canonical указывает на саму страницу, а не на её копию с параметрами (?utm_source=...);
• протокол и хост совпадают (http vs https, www vs без www) — расхождение размывает сигнал;
• canonical не ведёт на 404, редирект или на другую страницу того же раздела;
• для страниц пагинации canonical настроен осознанно, а не ошибочно склеивает все страницы в первую.

Наглядная сводка ошибок индексации

После каждой правки дайте роботам время: переобход занимает от нескольких дней до пары недель. Отслеживайте динамику по отчётам «Индексирование страниц» в Search Console и «Индексирование» в Яндекс Вебмастере — именно они показывают, сколько URL реально попало в индекс, а сколько застряло на этапе обнаружения.

Диагностика краулинга и дублей: битые ссылки, редиректы, зеркала, параметры URL и пагинация, мешающие поисковым роботам обходить сайт

Индексация настроена, карта сайта отдаётся корректно — но робот всё равно обходит лишь часть страниц и возвращается ни с чем. Причина обычно в краулинге: бюджете запросов, который поисковик тратит на ваш сайт. Каждая битая ссылка, цепочка редиректов или дубль съедают этот бюджет впустую, и до действительно важных URL робот просто не доходит.

Краулинговый бюджет — это как пропускная способность платной дороги: неважно, сколько машин вы поставите в очередь, если половина полос ведёт в тупик.

Разберём пять категорий ошибок, которые чаще всего «съедают» обход.

Битые ссылки и редиректы: куда утекает бюджет робота

Битая ссылка (404 или 500) на первый взгляд безобидна, но каждая из них — это отдельный запрос, который робот потратил зря. На крупном каталоге из 30 000 страниц со устаревшими фильтрами можно набрать тысячи таких запросов, и обход новых товаров затормозится на недели.

Рабочая последовательность проверки:

• Соберите все 404 из отчётов «Индексирование страниц» (Search Console) и «Диагностика сайта» (Яндекс Вебмастер). Отдельно выгрузите коды 5xx: они говорят о нестабильности сервера, а не об удалённых страницах.
• Для каждой 404-страницы решите судьбу: отдать 301 на актуальный аналог, если контент логично переехал, или оставить 404/410, если страница удалена безвозвратно. Массовый редирект «всех 404 на главную» — типичная ошибка: она плодит мягкие 404 и сбивает сигналы релевантности.
• Найдите источники битых ссылок — внутренние страницы, меню, старые посты, внешние профили. Без этого вы лечите симптом, а не болезнь.

Отдельно проверьте редиректы. Цепочка вида /a → /b → /c → /d тратит несколько запросов вместо одного, а робот не любит длинные переходы. Сведите все цепочки к одному 301-хопу. Исключение — редиректы со старых доменов и http-версий, их лучше сохранять, но возвращать прямой ответ.

Зеркала и параметры URL: где робот видит дубли вместо страниц

Зеркалами называют несколько адресов одного и того же контента: site.ru и www.site.ru, http и https, версии с index.html и без, с заглавной буквой в URL и строчной, с передачей ?utm_source= из рекламы. Для робота это разные URL с одинаковым содержимым — он тратит обход, а вы получаете склейку или выпадение нужной версии.

Практические шаги:

• Проверьте, что у каждого зеркала прописан канонический URL (<link rel="canonical">) на основную версию, а сами зеркала отдают 301.
• Убедитесь, что UTM-метки и параметры сортировки/фильтров не создают индексируемых дублей: закрывайте их в robots.txt через Disallow: /*?utm_ или отдавайте noindex на самих страницах, но не жалейте их в sitemap.xml.
• Отслеживайте «Параметры URL» в Search Console — там видно, какие параметры робот считает отдельными страницами. Для коммерческих каталогов это критично: сортировка ?sort=price&utm=... может удвоить число URL.

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

Пагинация: как не потерять последние страницы каталога

Пагинация — самая недооценённая ловушка. Две крайние ошибки: закрыть все страницы пагинации в robots.txt (тогда робот не пройдёт за первую страницу и не узнает о товарах на последующих) или отдавать на каждой странице одинаковый canonical, ведущий на первую страницу. Вторая ошибка гарантирует, что товары с 5-й страницы никогда не получат самостоятельной индексации.

Правильный подход:

1. Для «глухой» пагинации (/page/2/, где нет отдельной ценности) оставляйте self-referencing canonical на текущую страницу или на все страницы раздела — но не на первую.
2. Для фильтров с ценностью (например, «кроссовки для бега 42 размера») делайте отдельные посадочные URL с уникальным заголовком и текстом — это не дубли, а новые точки входа.
3. Убедитесь, что пагинация имеет понятные ссылки «Следующая/Предыдущая» и хлебные крошки, а счётчик страниц не уводит робота в бесконечный цикл /page/1/ → /page/2/ → ….

Для проверки обхода возьмите выборку URL из важных разделов и посмотрите отчёт «Обход страниц» в Search Console: сколько запросов в день получает раздел, что отдаётся с кодом 200, а что с 3xx. Сопоставьте с логами сервера через минимальный лог-анализатор — вплоть до команды grep -c "HTTP/1.1\" 404" access.log, если нет платного инструмента. Пагинация и битые ссылки видны там же.

Помните: часть дублей можно указать поисковику через sitemap.xml с датами lastmod и тегами hreflang для языковых версий. Это не решает проблему целиком, но помогает роботу понять, какие URL действительно самостоятельные. Дальше — скорость загрузки, без неё даже идеально вычищенный краулинг будет хромать.

Аудит скорости загрузки и Core Web Vitals: критические ошибки рендеринга, сжатия изображений, кэширования и оптимизации кода

Когда робот наконец получил доступ к страницам и не тратит бюджет на дубли, в игру вступает третий фильтр — скорость и стабильность отрисовки. С 2023 года Google официально использует Core Web Vitals как ранжирующий сигнал, а Яндекс с 2024-го учитывает аналогичный набор метрик в алгоритме «Баден-Баден». То есть медленная страница — это не «неудобно для пользователя», а формальный минус к позиции, который вы конкурируете с текстом и ссылками. Проверять метрики нужно не «на глаз», а через PageSpeed Insights, Lighthouse и отчёты в Google Search Console (раздел «Основные интернет-показатели») и Яндекс.Вебмастере.

Метрики, на которые смотрит поиск и как их ломают

Три ключевые метрики формируют оценку страницы:

• LCP (Largest Contentful Paint) — время отрисовки главного элемента (обычно первый экран или hero-баннер). Норма — до 2,5 секунд. Частая причина провала — тяжёлое изображение без srcset и loading="lazy" (но для LCP-элемента lazy грузить нельзя, иначе метрика ухудшится).
• INP (Interaction to Next Paint) — отзывчивость на клик, тап или ввод (с марта 2024 заменил FID). Норма — до 200 мс. Провал дают тяжёлые обработчики JavaScript и сторонние виджеты (чаты, аналитика, pop-up-скрипты).
• CLS (Cumulative Layout Shift) — визуальная стабильность. Норма — до 0,1. «Прыгает» контент из-за картинок без указанных width/height и баннеров, вставляемых поверх текста.

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

Отдельно проверьте рендеринг: если контент подгружается JS-скриптом без серверного пре-рендера (SPA без SSR/SSG), Googlebot и Яндексбот могут увидеть пустой <body>. В Lighthouse-отчёте это видно как расхождение «отображаемый HTML» vs «финальный HTML» в разделе про noindex/SEO.

Сжатие изображений и кэширование: где чаще всего теряется бюджет

Изображения — самая массовая причина медленного LCP. Чек-лист критических ошибок:

• Тяжёлые PNG вместо WebP/AVIF — простое переформатирование сжимает вес в 3–5 раз без видимой потери качества. Заодно убедитесь, что сервер корректно отдаёт Content-Type: image/webp и что CDN поддерживает AVIF для браузеров с поддержкой.
• Отсутствие адаптивных размеров — один файл 1920px для мобильного экрана 375px. srcset и атрибут sizes дают браузеру выбор нужного варианта.
• Нет loading="lazy" для второстепенных картинок и одновременно lazy на LCP-элементе — две противоположные ошибки в одном шаблоне.

Кэширование проверяется по заголовкам ответа (Cache-Control, Expires, ETag). Статика (CSS, JS, шрифты, изображения) должна кэшироваться на 6–12 месяцев с хэшем в имени файла (style.a1b2c3.css). HTML — наоборот, коротко (5–60 минут) или через no-cache с ревалидацией. Частая ошибка — статичные ассеты без хэша и с Cache-Control: max-age=0: пользователи при каждом заходе качают всё заново.

Оптимизация кода и рендеринга: что реально тормозит страницу

Смотрите на HTML-отчёт Lighthouse и ищите блокирующие ресурсы:

• CSS и JS в <head> без defer/async — парсинг HTML останавливается, пока браузер не скачает и не выполнит скрипт. Вынесите некритичный JS в defer.
• Избыточный CSS и неиспользуемый код — десятки килобайт фреймворка ради одного FAQ-аккордеона. Проверьте покрытие кода в DevTools.
• Сторонние скрипты — самая частая причина просадки INP: тяжёлые CRM-виджеты, чаты, карты. Загружайте их по клику или через requestIdleCallback.
• Шрифты — font-display: swap и preload основного начертания спасают от невидимого текста и скачка верстки.

Сравните типичную картину до и после исправлений:

В Search Console отчёт показывает, какие группы URL проваливают метрики, — начинайте с шаблонов, которые покрывают больше всего трафика и выручки. Если карточка товара или страница услуги с рекламным трафиком имеет плохую оценку, именно она «съедает» конверсию дважды: и через позиции, и через поведенческие сигналы (дочитывание, отказы). Отдельно зафиксируйте базовые метрики до правок — иначе через месяц вы не докажете, что скорость действительно выросла, а архитектура сайта и внутренняя перелинковка добавят к этому уже собственный вес.

Архитектура и внутренняя перелинковка: ошибки в структуре URL, навигации, хлебных крошках и силе внутренних ссылок

Скорость налажена, дубли отсечены, страницы индексируются — но позиции по коммерческим запросам продолжают топтаться на месте. Часто причина кроется не в контенте, а в том, как страницы связаны между собой. Внутренняя перелинковка — это не «SEO-магия», а система распределения веса: робот входит на сайт через главную и движется по ссылкам, выстраивая иерархию приоритетов. Если ссылочный граф хаотичен, важные карточки товара и посадочные страницы услуг получают вес по остаточному принципу, а служебные разделы и старые теги — наоборот, перетягивают его на себя.

Перелинковка — это внутренний PageRank сайта: страница, до которой робот добирается за два клика и с сотни ссылок, почти всегда обгонит страницу, спрятанную на пятом уровне вложенности и связанную одной ссылкой из футера.

Структура URL и глубина клика: где робот теряет приоритеты

Начните с проверки вложенности: чем короче путь от главной до коммерческой страницы, тем выше её шанс попасть в топ. Типовая ошибка — каталог с уровнями /catalog/tovary/dlya-doma/kuhnya/posuda/ и выше — пять кликов до карточки, при этом в меню ведёт ссылка на промежуточную категорию с пагинацией и параметрами. Робот с ограниченным краулинговым бюджетом до карточки доберётся, но вес распределится по всем промежуточным фильтрам.

Рабочее решение: сокращайте путь до трёх кликов для коммерчески значимых страниц. Вынесите популярные категории и подборки в сквозное меню, а не в динамические блоки с JS-подгрузкой — ссылка, отрендеренная только после клика, для робота часто не существует. Проверьте структуру URL через отчёт «Структура сайта» в Search Console или обходом в Screaming Frog: если категории третьего уровня получают меньше входящих внутренних ссылок, чем страницы блога, приоритеты выставлены неверно.

Отдельная ошибка — «плоские» URL без вложенности (/kupit-divan-moskva-nedorogo). Такие адреса не несут иерархии, и робот не понимает, к какой категории относится страница. Правильная структура отражает путь пользователя и подсказывает поисковику тематическую принадлежность раздела.

Навигация и хлебные крошки: каркас, который видит робот

Меню, которое работает только на JavaScript или подгружается по клику на бургер, — классическая ловушка. Даже с корректным рендерингом часть ссылок робот может не увидеть при первом проходе. Проверьте исходный HTML страницы: все ключевые разделы должны быть доступны по ссылкам <a href="..."> без событий.

Хлебные крошки (BreadcrumbList) решают две задачи сразу: дают пользователю навигацию и передают роботу иерархию. Частая ошибка — крошки реализованы графикой или div-блоками без микроразметки, а в разметке BreadcrumbList указан путь, который не совпадает с реальной структурой URL. Это создаёт противоречие: робот видит одно, а в разметке — другое. Проверяйте валидатором Google Rich Results Test и сопоставляйте путь в крошках с фактическим адресом страницы.

Ещё одна проблема — боковые меню и «похожие товары», которые генерируют сотни ссылок с одинаковым анкором («Подробнее», «Купить»). Размывайте анкоры по смыслу: вместо десяти «Подробнее» используйте «Кухонный гарнитур с фасадами из МДФ» — так робот понимает тематику целевой страницы и передаёт вес по релевантному запросу.

Сила внутренних ссылок: как направлять вес, а не размазывать

Внутренняя перелинковка без стратегии превращается в «раздачу» веса всем подряд. Практический приём — аудит входящих ссылок по отчёту «Ссылки» в Search Console или в Ahrefs/Screaming Frog: постройте таблицу, где для каждой коммерческой страницы видно число входящих ссылок. Если страница услуги получает 2-3 ссылки из футера, а статья блога 2021 года — 40 ссылок из боковых блоков, вес уходит не туда.

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

Отдельно проверьте сквозные блоки. Меню и футер на 5000 страниц дают каждому URL одинаковый вклад — это нормально для навигации, но не для продвижения. Не пытайтесь «прокачать» страницу только через футер: добавьте её в тематический блок контента, в подборку или статью. Помните, что внутренние ссылки — это ещё и инструмент управления мобильной адаптивностью: на смартфоне меню-«простыня» на 60 пунктов превращается в лабиринт, и пользователь уходит до конверсии, даже если робот прошёл по всем ссылкам без ошибок.

Проверьте перелинковку на битые внутренние ссылки — 404 внутри сайта (например, после смены структуры URL без редиректов) сливают вес в никуда и засоряют краулинговый бюджет. Один такой аудит обычно выявляет 10–15% битых внутренних ссылок в каталоге, и их исправление даёт быстрый прирост видимости без единой новой статьи.

Мобильная адаптивность и юзабилити: ошибки вьюпорта, тач-элементов, шрифтов и всплывающих окон, влияющие на ранжирование

Представьте: пользователь открывает ваш сайт с телефона в очереди за кофе, хочет быстро оформить заказ — а кнопка «Купить» уезжает за край экрана, шрифт приходится зумить двумя пальцами, а поверх контента выскакивает попап с подпиской на рассылку, который невозможно закрыть. Он уходит к конкуренту. А через неделю вы замечаете просадку позиций по мобильной выдаче. Это не совпадение: с переходом Google на mobile-first indexing именно мобильная версия страницы — эталон для оценки релевантности и юзабилити. И ошибки адаптивности бьют по ранжированию напрямую, а не только по конверсии.

Вьюпорт и тач-элементы: фундамент, который ломают чаще всего

Самая базовая, но и самая распространённая ошибка — отсутствие или некорректная настройка мета-тега viewport. Если в <head> нет строки <meta name="viewport" content="width=device-width, initial-scale=1">, браузер смартфона отрисует страницу в десктопной ширине (обычно 980px) и ужмёт её — пользователь получает микроскопический текст. Для робота это сигнал: страница не адаптирована.

Проверьте в DevTools (режим устройства) три вещи:

• Горизонтальный скролл. Если появляется полоса прокрутки вправо — контент шире вьюпорта. Причина обычно в фиксированной ширине блоков (width: 1200px вместо max-width: 100%) или в изображениях без max-width: 100%.
• Размер тач-элементов. По рекомендациям Google интерактивные элементы (кнопки, ссылки в меню) должны быть не меньше 48×48 CSS-пикселей с достаточным отступом между ними. Ссылки-«иголки» в футере, где палец попадает сразу в три соседние — классическая ошибка: пользователь злится, а поведенческие метрики падают.
• Фиксированные позиции. Прилипающая шапка высотой в треть экрана или «плавающая» кнопка звонка, перекрывающая контент, крадут полезную площадь. Особенно критично на экранах 360×640.

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

Шрифты и читаемость: то, что влияет на поведенческие факторы

Мелкий шрифт — прямой путь к отказу. Базовый размер текста на мобильном должен быть не меньше 16px: всё, что меньше, заставляет пользователя зумить, а зум ломает вёрстку и увеличивает показатель отказов.

Типичные ошибки, которые стоит вычистить:

• Относительные единицы вместо фиксированных. Задавайте размеры в rem/em, а не в px — так текст корректно масштабируется при системных настройках пользователя (крупный шрифт в настройках ОС). Фиксированные px игнорируют эти предпочтения.
• Межстрочный интервал и длина строки. Строка длиннее 50–60 символов на узком экране утомляет глаз. Проверьте line-height (оптимум 1.4–1.6) и letter-spacing.
• Контрастность. Светло-серый текст на белом фоне (#999 на #fff) не проходит по WCAG. Для робота это часть оценки юзабилити, для пользователя — реальная проблема на солнце.

Не забудьте про структурированные данные — но уже в контексте мобильной разметки: корректный Recipe, Product или FAQPage в schema.org должен одинаково читаться и в мобильной, и в десктопной версии. Рассинхрон микроразметки между версиями — частая причина потери rich-сниппетов.

Всплывающие окна: когда «маркетинг» убивает ранжирование

Интерстициальные попапы (interstitials) — отдельная боль mobile-first индексации. Google прямо предупреждает: навязчивые всплывающие окна, перекрывающие основной контент на мобильном, могут понизить страницу в выдаче, потому что они мешают пользователю добраться до сути.

Безопасные и опасные сценарии:

• Опасно: полноэкранный попап с подпиской, который выскакивает сразу при загрузке и закрывается только крестиком 10×10px в углу; модалка, блокирующая контент, без явной кнопки закрытия.
• Допустимо: баннер cookie-согласия (юридически необходимый, разумного размера), возрастная верификация, окно входа по действию пользователя (клик по «Личный кабинет»).

Решение простое: замените агрессивный интерстишл на ненавязчивый нижний баннер или отложенный триггер (по скроллу, по времени, по намерению уйти). Это сохраняет и лиды, и позиции.

Проверьте адаптивность по чек-листу: тег viewport на месте, горизонтального скролла нет, тач-элементы не меньше 48px, шрифт от 16px, интерстишлы не блокируют контент. Каждый исправленный пункт возвращает вам и мобильный трафик, и доверие робота — а суммарно по разделу это обычно 5–7 ошибок из 45, которые дают быстрый эффект без переработки контента.

Технические алгоритмические сигналы: структурированные данные, безопасность HTTPS, ошибки сервера и корректность заголовков ответа

Мобильная версия отполирована, скорость в зелёной зоне, страницы индексируются и связаны перелинковкой — но робот всё равно понижает доверие к сайту. Причина часто лежит на уровне «мета-сигналов»: того, что сервер сообщает поисковику заголовками ответа, разметкой Schema.org и состоянием защищённого соединения. Эти сигналы алгоритм считывает автоматически, без участия пользователя, — и именно поэтому их ошибки стоят дороже всего.

Структурированные данные: разметка, которая врёт или молчит

Schema.org — это язык, на котором вы объясняете поисковику, что перед ним: товар, статья, рецепт, организация, отзыв. Google и Яндекс используют её для формирования расширенных сниппетов, а AI-ответы (Google AI Overviews, Яндекс Нейро) — как источник фактов для генерации. Ошибка в разметке ломает оба сценария: и сниппет, и попадание в AI-выдачу.

Типичные провалы, которые ловятся за пять минут через валидатор Rich Results Test и Яндекс.Вебмастер:

• Несоответствие разметки контенту. В Product указана цена 990 ₽, а на странице — 1 490 ₽. Это прямое нарушение правил структурированных данных: сниппет снимается, а при систематике — санкции на весь шаблон.
• Пустые обязательные поля. Для Product критичны name, image, offers.price, offers.priceCurrency, availability. Без availability Google может показать «Нет в наличии» даже когда товар есть.
• Разметка невидимого контента. Микроразметка для отзывов, которых нет на странице, — классический чёрный приём. Робот сверяет schema с видимым текстом и при расхождении игнорирует блок.
• Дублирование форматов. Одновременно JSON-LD и Microdata на одной сущности → конфликт приоритетов. Оставьте один способ — предпочтительно JSON-LD в <head>.
• Отсутствие BreadcrumbList при живых хлебных крошках. Крошки в HTML есть, а в разметке их нет — вы теряете сигнал о структуре для расширенного сниппета.

Разметка — это не украшение сниппета, а декларация фактов. Если декларация расходится с реальностью страницы, алгоритм выбирает реальность и запоминает несоответствие.

Отдельно проверьте Organization на главной (логотип, контакты, соцпрофили — они питают Knowledge Panel) и Article для блога с корректным datePublished/dateModified. Устаревшая дата модификации при реальных правках — сигнал «контент заброшен».

HTTPS и заголовки ответа: доверие на уровне протокола

HTTPS — базовый сигнал ранжирования с 2014 года, но в 2026-м проблемы сместились с «есть ли сертификат» на «корректно ли он настроен». Проверяйте:

• Смешанный контент. Страница по HTTPS подгружает картинки или скрипты по HTTP — браузер блокирует, робот фиксирует поломку рендеринга. Ищите через консоль браузера по фильтру «Mixed Content».
• Редирект с HTTP на HTTPS. Должен быть один 301 на уровне сервера, а не цепочка http → https://www → https://. Каждое лишнее звено — потеря части краулингового бюджета.
• HSTS-заголовок (Strict-Transport-Security) — ускоряет и защищает от даунгрейд-атак, но включайте его только после полной проверки, что весь сайт отдаётся по HTTPS.
• Сертификат на все поддомены, включая www и статические ресурсы (CDN), иначе часть ассетов «отваливается».

Заголовки ответа — вторая половина этого сигнала. Частые ошибки, которые видны в отчёте «Сканирование → Заголовки ответа»:

• Мягкие 404 (Soft 404). Сервер отдаёт 200 OK на страницу «Товар не найден». Робот индексирует пустышку, раздувает индекс и размывает качество. Решение — честный 404 или 410 для удалённых товаров.
• Редиректы на 200 вместо 301. Например, Location с кодом 302 на постоянный перенос — сигнал не передаётся, старый URL остаётся в индексе.
• Ошибки 5xx при пиковых нагрузках. Если сервер отдаёт 503 в часы высокой нагрузки без заголовка Retry-After, робот воспринимает это как нестабильность и снижает частоту обхода. Настройте Retry-After и убедитесь, что 5xx не появляются из-за лимитов хостинга.
• Некорректный Content-Type и кодировка. Страница отдаётся как text/html; charset=windows-1251, а контент в UTF-8 — робот видит «кракозябры» и неверно извлекает текст для индекса.

Отдельно — X-Robots-Tag в заголовках. Он может блокировать индексацию незаметно для вас: плагин или CDN добавляет noindex на целый раздел, и в HTML его нет — только в HTTP-ответе. Проверяйте инструментами вроде Screaming Frog с включённым анализом заголовков.

Как быстро продиагностировать блок и что исправить в первую очередь

Прогоните 3–5 ключевых шаблонов (главная, категория, карточка товара/услуги, статья) через Rich Results Test и посмотрите отчёт «Структурированные данные» в Search Console и раздел «Диагностика сайта» в Яндекс.Вебмастере. Затем проверьте заголовки ответа на тех же URL — ищите цепочки редиректов, soft 404 и неожиданные X-Robots-Tag.

Приоритет исправлений: сначала критические расхождения schema с контентом (риск санкций), затем цепочки редиректов и soft 404 (прямая потеря краулингового бюджета), затем HSTS и Retry-After (стабильность и доверие). После каждой правки — повторный прогон валидатора и переобход через IndexNow, чтобы робот увидел исправления в течение часов, а не недель.

Каждый корректный сигнал — это +1 к «кредиту доверия» сайта у алгоритма. А накопленный кредит напрямую конвертируется в скорость переобхода, стабильность сниппетов и шанс попасть в AI-ответы. Дальше остаётся свести все проверенные блоки в единую систему и зафиксировать порядок действий — об этом в завершающей части.

Заключение: главные выводы и чек-лист действий для исправления 45 критических ошибок и поддержания технического здоровья сайта

Семь блоков проверки — от robots.txt до заголовков ответа — складываются в одну диагностическую картину. Технический SEO-аудит перестаёт быть «списком страхов» и превращается в приоритизированный план работ, где каждая исправленная ошибка возвращает сайту утраченную видимость. Ниже — структура выводов и пошаговый порядок действий, чтобы пройти чек-лист из 45 ошибок без хаоса и не растерять результат через месяц.

Три вывода, которые меняют подход к аудиту

Первый вывод: ошибки аудита почти никогда не равнозначны по ущербу. Заблокированный в robots.txt раздел каталога обнуляет видимость сотен коммерческих страниц — это катастрофа. Отсутствующий alt у пары изображений — мелкий недочёт. Поэтому чек-лист из 45 пунктов работает не как «сделать всё подряд», а как фильтр критичности: сначала то, что режет трафик на порядок, затем то, что улучшает его на проценты. Практическое правило приоритета: блокировка индексации → ошибки краулинга и дубли → скорость и Core Web Vitals → архитектура и перелинковка → мобильное юзабилити → мета-сигналы и безопасность.

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

Третий вывод: аудит без фиксации результата не считается выполненным. Каждая исправленная ошибка должна получить статус в трекере (найдено → в работе → исправлено → проверено). Без этого через месяц вы снова будете гадать, закрыт ли канонический URL и обновлён ли sitemap.xml.

Техническое здоровье сайта — это не разовая акция «починить и забыть», а режим обслуживания: чем раньше ошибка попадает в трекер, тем дешевле она обходится в трафике.

Чек-лист действий: от диагностики к исправлению

Этап 1. Диагностика (1–2 дня). Прогоните сайт по всем семи блокам и зафиксируйте найденные ошибки в единой таблице с полями: блок, описание ошибки, критичность (высокая/средняя/низкая), страницы-примеры, ответственный, срок. Это и есть ваш рабочий список из 45 пунктов — с реальными адресами, а не абстрактными «проверить canonical».

Этап 2. Быстрые блокеры (первая неделя). Сюда входят:

• корректность robots.txt и sitemap.xml — сверьте директивы Disallow с картой разделов, убедитесь, что карта отдаёт только канонические URL;
• точечные мета-теги robots и canonical — снимите случайные noindex и canonical на «не ту» страницу;
• цепочки редиректов и битые ссылки — сократите каждую цепочку до одного 301;
• дубли из-за параметров URL и зеркал — настройте 301 с www/без www и укажите canonical для параметрических адресов.

Эти правки чаще всего дают самый быстрый прирост видимости: страницы, которые раньше не индексировались, начинают попадать в обход.

Этап 3. Скорость и рендеринг (2–4 недели). Разберите Core Web Vitals по метрикам: сжатие изображений (WebP/AVIF), кэширование статики, отложенная загрузка некритичного JS, устранение сдвигов макета. Проверяйте результат не «на глаз», а в отчётах по реальным пользователям — лабораторные замеры и полевые данные могут расходиться.

Этап 4. Архитектура, мобильная версия и мета-сигналы. Глубина клика, хлебные крошки, корректные заголовки ответа, HTTPS без смешанного контента, валидные структурированные данные — это планомерная работа, которую удобно вести параллельно с правками контента.

Этап 5. Мониторинг. Заведите ежемесячный ритуал: проверка индексации новых разделов, отчёт по Core Web Vitals, сканирование битых ссылок, контроль новых дублей, проверка sitemap и robots.txt после любых релизов. Любое обновление сайта — повод прогнать сокращённую версию чек-листа.

Что считать успехом аудита

Не «ноль ошибок» — их не бывает у живого сайта. Успех — это управляемый список: все критические пункты закрыты, средние и низкие стоят в очереди с понятными сроками, а ключевые сигналы (индексация, скорость, канонические URL, sitemap.xml) проверяются регулярно. Начните с блокирующих индексацию ошибок уже сегодня — именно они определяют, увидит ли поиск ваш контент вообще, а всё остальное имеет смысл только после этого.