Технический SEO-аудит сайта в 2026 году перестал быть проверкой «есть ли на странице теги title и h1». Сегодня сайт одновременно обходят три разных класса роботов: классические поисковые краулеры (YandexBot, Googlebot), рендер-боты на базе безголового Chromium, оценивающие Core Web Vitals и визуальную стабильность, и краулеры нейросетей (GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot), которые вообще не выполняют клиентский JavaScript. Ошибка в конфигурации nginx, порядке загрузки шрифтов или настройках антибот-фильтра приводит к тому, что в браузере владельца сайт выглядит безупречно, а для поиска и ИИ-ответов его просто не существует.
Перед каждым клиентским проектом мы прогоняем сайт через собственный бесплатный SEO-аудитор ДАКОД (203 детерминированные проверки в 18 категориях). Осенью 2026 года мы провели такую же жёсткую ревизию и на собственном сайте dacod.ru, подняв технический балл с 76 до 95 из 100. Ниже разбираем 12 самых частых и дорогих технических ошибок, которые мы находим на сайтах малого и среднего бизнеса, с готовыми рецептами исправления.
Почему обычного обхода ссылок мало: сырой HTML против рендера в браузере
Главное правило современного технического аудита — сравнивать то, что сервер отдаёт в сыром HTTP-ответе без выполнения скриптов, с тем, что реально отрисовывается в DOM-дереве браузера (headless Chromium), а также сверять ответы сервера на запросы с разными заголовками User-Agent. Если проверять сайт только одним способом, половина критических проблем индексации остаётся невидимой1.
В нашем SEO-аудиторе каждая ключевая страница проходит тройную сверку:
| Слой проверки | Что именно проверяет робот | Какие критические сбои находит |
|---|---|---|
| 1. Сырой HTTP-ответ (без JS) | Код ответа, заголовки Cache-Control, X-Robots-Tag, HSTS, наличие всего текста, H1–H3 и мета-тегов в исходном HTML | Пустой <div id="app"></div> у SPA-приложений (невидим для ИИ-ботов и медленно индексируется Яндексом), подмена canonical на клиенте |
| 2. Рендер в headless Chromium | Фактические метрики отрисовки, блокирующие ресурсы, сдвиги макета (CLS), видимость первого экрана, ошибки консоли и гидратации | Вечный прелоадер при отключённом или упавшем скрипте, блокировка рендера внешними шрифтами, невидимый контент за opacity: 0 |
| 3. Сравнение ответов разным ботам (Cloaking check) | Поочерёдный запрос страницы с User-Agent обычного браузера, Googlebot, YandexBot, GPTBot, ClaudeBot и PerplexityBot | Случайный клоакинг: когда WAF, CDN или плагин «защиты от парсинга» отдаёт поисковому или ИИ-боту заглушку на 500 байт или код 403 Forbidden |
Ошибки 1–3: дубли адресов, петли редиректов и ловушки серверных маршрутов
Даже у небольшого сайта на 40–50 страниц в индексе легко оказывается 100–120 технических дублей, которые размывают краулинговый бюджет и мешают поисковику выбрать каноническую страницу. Вот три самые частые ошибки маршрутизации, которые мы вычищали в том числе на гибридной архитектуре (статика + SSR):
- Дубли со слэшем и без слэша на SSR-маршрутах (
/blog/statyaи/blog/statya/). Для статических папок веб-сервер nginx сам добавляет закрывающий слэш редиректом 301. Но когда часть маршрутов проксируется на Node.js или PHP-бэкенд, оба адреса начинают отдавать статус200 OK, а еслиrel="canonical"формируется из текущегоpathnameбез нормализации, каждая статья объявляет канонической саму себя в двух экземплярах. Лечится принудительным 301-редиректом на адрес со слэшем до рендера страницы и жёсткой нормализациейcanonicalв базовом шаблоне. - Дубль главной страницы по адресу
/index.htmlили/index.php. Типичная ошибка — написать в конфиге nginxlocation = /index.html { return 301 /; }. Поскольку директиваindex index.html;делает внутренний редирект с корня/на/index.html, такая конструкция мгновенно создаёт бесконечную петлю переадресацииERR_TOO_MANY_REDIRECTS. Правильное решение в nginx — проверять внешний URI запроса на уровнеserver:if ($request_uri ~* "^/index\.html$") { return 301 /; }. - Многошаговые цепочки редиректов (
http://www→https://www→https://) и старые адреса в404. Каждый лишний шаг в цепочке редиректов замедляет обход и снижает передаваемый вес. Любой переезд с протокола или домена сwwwдолжен вести сразу в конечную точку за один шаг 301, а скрытые или переименованные статьи блога должны перенаправляться на актуальные материалы по теме, а не отдавать 404 поисковым роботам.
Ошибки 4–6: случайный клоакинг, закрытые ИИ-краулеры и «чёрный экран» интро-заставки
Клоакинг — это ситуация, когда поисковому роботу и живому посетителю отдаётся разный контент. По правилам Яндекса и Google это прямое основание для пессимизации или исключения сайта из поиска2. На практике в 9 из 10 случаев владельцы бизнеса устраивают клоакинг случайно, даже не подозревая об этом:
- Агрессивная антибот-заглушка на хостинге или в плагине безопасности. На одном из клиентских интернет-магазинов мы обнаружили в аудиторе провал по проверке
CL-01: в браузере страница товара отдавала полноценный каталог на 65 КБ, а при запросе от имени бота возвращала страницу-заглушку размером 518 байт с JS-проверкой куки. Для любого краулера без выполнения стороннего челленджа сайт выглядел полностью пустым. - Блокировка ИИ-краулеров в
robots.txtи отсутствие/llms.txt. Многие шаблонные конфиги до сих пор блокируютGPTBot,OAI-SearchBot,ClaudeBotиPerplexityBot. Между тем по логам нашего собственного сервера за последние 16 днейGPTBotсовершил 1 005 обращений к страницам сайта,ClaudeBot— 859,OAI-SearchBot— 116, а живой агентChatGPT-Userзапрашивал страницы по прямым вопросам пользователей 82 раза. Чтобы нейросети безошибочно считывали структуру услуг, цен и реквизитов компании, мы держим всех ИИ-ботов открытыми и отдаём в корне сайта сводный паспорт/llms.txtс явным заголовкомcharset utf-8(подробнее — в гайде «Как попасть в ответы Алисы AI и ChatGPT»). - Полноэкранная интро-заставка без фолбэка
<noscript>. Если на сайте есть стартовая анимация (#intro) сposition: fixed; inset: 0; z-index: 9999, которая убирается скриптом через 2–3 секунды, то при сбое JS или у роботов снятия скриншотов весь первый экран навсегда остаётся перекрыт тёмным полотном. Заставка обязана сниматься в<noscript>и отключаться при системной настройкеprefers-reduced-motion: reduce.
Ошибки 7–9: почему Google Fonts обрушивает мобильный LCP и как ускорить сайт в два раза
В мобильной выдаче главным узким местом скорости почти всегда оказывается метрика LCP (Largest Contentful Paint) — время отрисовки самого крупного элемента первого экрана. По стандарту Core Web Vitals хороший LCP не должен превышать 2,5 секунды3.
Во время сентябрьского аудита dacod.ru мы увидели показательную картину: на десктопе сайт набирал 97 баллов Performance в Lighthouse при LCP 0,9 с, а на мобильном — всего 77 баллов при LCP 3,9 с. Единственной причиной такого разрыва оказался внешний CSS-файл fonts.googleapis.com:
| Показатель страницы | До исправления (внешний Google Fonts) | После переноса шрифтов локально на свой сервер |
|---|---|---|
| Lighthouse Performance (Mobile) | 77 / 100 (главная), 76 / 100 (кейс) | 98 / 100 (главная), 100 / 100 (кейс) |
| Мобильный LCP (Largest Contentful Paint) | 3,9 с (главная), 3,9 с (кейс) | 2,2 с (главная), 1,5 с (кейс) |
| Сдвиг макета (CLS) и TBT | CLS 0, TBT 20 мс | CLS 0, TBT 0 мс |
| Соответствие 152-ФЗ (ст. 12 — трансграничная передача) | Критическое нарушение: передача IP посетителей на серверы Google LLC (США) при каждом открытии | 0 нарушений: все файлы .woff2 отдаются со своего российского VPS (подробнее в разборе зарубежных сервисов на сайте) |
Помимо локализации шрифтов с font-display: swap и <link rel="preload" as="font" type="font/woff2" crossorigin>, в блок скорости и HTTP-протокола входят ещё две обязательные правки:
- Включение HTTP/2 и годового кэша для хэшированных ассетов. В современных версиях nginx (1.25+) директива
http2 on;задаётся отдельно внутри блокаserver. Без неё браузер выкачивает таблицы стилей, скрипты и картинки первого экрана без мультиплексирования, а без длинного кэша (Cache-Control: public, max-age=31536000, immutableна папку сборки/_astro/) повторно тянет неизменные файлы при каждом переходе. - Приоритет загрузки обложки первого экрана и явные размеры
width/height. Главная иллюстрация первого экрана не должна иметьloading="lazy"и скрываться анимацией появления: ей ставитсяloading="eager" fetchpriority="high", а всем остальным картинкам ниже сгиба —loading="lazy", адаптивныйsrcsetи точные атрибутыwidthиheightиз заголовка WebP-файла, чтобы CLS всегда равнялся нулю.
Ошибки 10–12: потеря веса из-за nofollow в редакторе, разрозненная микроразметка и тонкая индексация в Яндексе
Даже технически быстрый сайт может месяцами висеть на 5–6-й странице выдачи из-за трёх скрытых ошибок внутренней перелинковки и семантической разметки:
- Автоматический
rel="nofollow"на внутренних ссылках из визуальных редакторов. Популярные headless-редакторы (например, расширениеLinkв Tiptap) по умолчанию добавляют ко всем вставленным ссылкам атрибутыtarget="_blank" rel="noopener noreferrer nofollow". В результате статьи блога, которые приводят информационный трафик и стоят на 1-м месте в поиске, вообще не передают ссылочный вес коммерческим страницам услуг и кейсов! Мы решили это на уровне серверного пост-процессора статей: любая ссылка на собственный домен автоматически очищается отnofollowиtarget="_blank"и приводится к конечному относительному адресу со слэшем на конце, без промежуточных 301-редиректов. - Разрозненные куски JSON-LD вместо единого графа сущностей через
@id. Когда на странице лежат несвязанные блокиOrganization,ServiceиFAQPage, поисковик и нейросеть видят отдельные фрагменты текста, а не единую компанию. Правильная архитектура Schema.org строится вокруг устойчивых идентификаторов: компания размечается какOrganization/ProfessionalServiceс"@id": "https://dacod.ru/#org", основатель — какPerson, а каждая услуга (Serviceс корректнымOffers), статья (BlogPosting), веб-инструмент (WebApplication) и цепочка хлебных крошек (BreadcrumbList) ссылаются на организацию по этому@id. - Ожидание «самостоятельного» обхода Яндекса вместо связки Метрики, Sitemap с
lastmodи переобхода. В отличие от Googlebot, который активно сканирует новые ссылки из карты сайта, YandexBot на молодых или недавно обновившихся доменах может обходить по 1 странице раз в 2–3 дня. Чтобы страницы попадали в поиск за дни, а не месяцы, необходимо: (а) привязать счётчик Яндекс Метрики к кабинету Вебмастера и включить «Обход по счётчику»; (б) отдавать вsitemap.xmlреальную дату модификации каждого документа; (в) подавать новые и обновлённые URL на переобход через API Вебмастера и протокол IndexNow.
Как проверить свой сайт бесплатно за 3 минуты и что делать с отчётом
Мы открыли наш внутренний инструмент для всех владельцев сайтов и маркетологов: зайдите в бесплатный SEO-аудитор ДАКОД и введите домен вашего сайта. Регистрация и привязка карты не требуются — робот обойдёт страницы, отрендерит их в браузере, проверит ответы разным поисковым и ИИ-краулерам и отсортирует найденные проблемы по степени влияния на трафик (критические HIGH, средние MEDIUM и рекомендации LOW).
Если вы хотите передать исправление ошибок или системный рост органического трафика нам — посмотрите условия на страницах SEO-продвижения (от 35 000 ₽/мес), GEO-продвижения в ответах нейросетей (от 35 000 ₽/мес) или разовых технических доработок в рамках поддержки сайта (от 5 000 ₽/мес) и напишите нам в Telegram со ссылкой на отчёт аудитора.
