Почему ваш SEO-аудит бесполезен (и как это проверить)

Клиент пришёл с аудитом за 30 тысяч. Там было 47 задач. Все - «критичные». Он потратил ещё 80 на доработки. Через три месяца трафик - ноль.

Потом пришёл я. Второй аудит. Три задачи. Ни одной критичной.

Это реальная история, которая повторилась у меня три раза за последний год. Люди платят агентствам за аудиты, потом платят разработчикам за «критичные исправления», а трафик не растёт. Потому что аудит был бесполезен.

Не потому что аудитор некомпетентен. А потому что инструмент, которым он пользовался, не умеет отличать реальную проблему от ложного срабатывания.

Что такое автоматический SEO-аудит на самом деле

Большинство бесплатных и дешёвых аудитов - это не работа эксперта. Это автоматический сканер. Он делает HTTP-запрос к странице, парсит HTML, сверяет с набором правил и выдаёт список.

47 пунктов. Все красные. Все - «критичные».

Сканер не знает контекста. Он не видит, что сайт за Cloudflare. Он не знает, что canonical с www на non-www - осознанный выбор владельца. Он не умеет запускать JavaScript, чтобы проверить, как рендерится SPA.

Он просто запрашивает страницу и пишет, что видит. Или, точнее, что не видит.

Я уже писал про как читать robots.txt - не только Disallow. Та же история: сканер видит строку Disallow и пишет «критично». А человек, который читает файл, понимает: там закрыты каталоги админки, и это правильно. Закрыть админку от поисковых роботов - не ошибка, а стандартная практика.

Проблема в том, что сканер не всегда отличает Disallow: /admin/ от Disallow: /. Первый - защита. Второй - закрытие всего сайта от индексации. Сканер видит Disallow и пишет «критично», не вникая.

Сканер не задаёт вопросов. Он не спрашивает: «А зачем здесь Disallow?», «А за CDN ли стоит сайт?», «А использует ли сайт JavaScript?». Он просто проверяет и выдаёт результат.

И вы, получив этот результат, платите за исправление того, что не сломано.

Почему сканер не видит контекст

Сканер - это инструмент. Он умеет проверять правила. Но он не умеет думать.

Пример. Сканер проверяет robots.txt и видит:

Disallow: /admin/
Disallow: /wp-admin/
Disallow: /cgi-bin/

Десятки таких строк. Сканер пишет: «много правил Disallow - критично, слишком много закрытых директорий».

Аудитор, который не разбирается, берёт это и пишет клиенту: «У вас десятки закрытых директорий, это критично, нужно срочно исправить».

Клиент «исправляет». Открывает админку для роботов. И что? Трафик не вырос. Потому что админка и так не должна индексироваться.

Сканер не понимает разницы между «нужно закрыть» и «нужно открыть». Он видит правило и пишет «критично». Не потому что аудитор плохой. А потому что инструмент не умеет думать.

Пять признаков того, что аудит - фейк

1. «Битые ссылки» на YouTube, VK и Telegram

Сканер нашёл ссылку, которая не открывается, и написал «критическая ошибка: битая ссылка». Вы открываете ссылку - а это YouTube, VK или Telegram.

Это внешняя ссылка. Сайт ссылается на чужой ресурс. Если YouTube недоступен - это не проблема вашего сайта. Вы не можете исправить чужой сайт.

Внутренние битые ссылки - да, это проблема. Страница 404, пользователь попадает в никуда, поисковик видит мёртвую ссылку. Но внешние? Если упал чужой сервис - вы ничего не исправите у себя. И это нормально.

Важно: сканер часто не различает внутренние и внешние ссылки. Или различает, но пишет «битая ссылка» без уточнения. А в заголовке - «критично». И вы бежите чинить то, что чинить не нужно.

Случай из практики: аудитор нашёл 23 «битые ссылки» на сайте интернет-магазина. Оказалось, 21 из них - ссылки на YouTube-обзоры и VK-группу. Два реальных битых внутренних URL - и то страницы закрытой распродажи.

2. «Отсутствует gzip-сжатие» на сайте за CDN

Сканер делает запрос к origin-серверу, не видит заголовка content-encoding: gzip и пишет «критично: отсутствует gzip-сжатие».

Но сайт стоит за Cloudflare. CDN сжимает ответ на своём конце, перед тем как отправить его пользователю. Origin может не сжимать - потому что не обязан.

Сканер стучится напрямую в origin. Origin не отдаёт gzip. Сканер пишет «критично». Пользователь получает сжатый ответ от Cloudflare. Всё работает.

Подробнее: gzip и кэширование. Если есть CDN - gzip на origin часто не нужен. Прокси сделает. Если CDN нет - gzip на origin нужен.

3. «Нет JSON-LD разметки» на JavaScript-сайте

Современные сайты - React, Vue, Nuxt, Next.js. Контент часто рендерится в браузере. Сканер делает простой HTTP-запрос, получает «пустой» HTML и пишет «нет микроразметки».

А в браузере - полная JSON-LD: Schema.org, Product, BreadcrumbList, FAQPage. Проблема не в сайте. Проблема в том, что сканер не умеет запускать JavaScript.

Про микроразметку Schema.org я писал отдельно: как правильно проверить JSON-LD. Не через «голый» запрос, а открыв страницу в браузере и посмотрев исходный код. Или через DevTools - Elements - найти <script type="application/ld+json">.

Если сканер ругается на отсутствие JSON-LD, а в браузере разметка есть - это ложное срабатывание. Сканер не видит JavaScript-рендеринг. Это не ошибка сайта.

4. «Canonical не совпадает с доменом»

Сканер видит, что canonical ведёт с www на non-www (или наоборот), и пишет «критично: canonical не совпадает с доменом».

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

Если canonical с www на non-www - владелец выбрал non-www. Если наоборот - выбрал www. Оба варианта нормальны, если сделаны осознанно.

Про каноникализацию и дубли - разобрано отдельно. Canonical - не баг сам по себе. Это инструмент. Ошибочно его используют люди, а не «сайт сломан по умолчанию».

5. «Нет Cache-Control» на сайте за Cloudflare

Cloudflare часто ставит свои Cache-Control на ответ. Origin может не ставить - не обязан. Сканер делает запрос к origin, не видит Cache-Control и пишет «критично».

Для пользователя ответ приходит с CDN, и там Cache-Control есть. Опять: проблема не в сайте, а в том, что сканер не учитывает архитектуру.

Кэш - это не просто заголовок на origin. Это цепочка: origin - CDN - пользователь. Если на звеньях всё настроено правильно - работает. Сканер проверяет одно звено и судит о всей цепочке.

А теперь - реальный аудит

Реальный аудит - не список из 47 пунктов. Это анализ того, как сайт видят поисковые системы и пользователи.

Вот что я делаю:

1. Смотрю сайт глазами робота. Не через «голый» запрос, а через то, что реально видят Яндекс и Google. Как проверить сайт глазами робота - про инструменты и методы. Это браузер с JavaScript, эмуляция робота, то, что получает поисковик.

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

3. Сверяю с реальностью. Не с чек-листом, а с тем, как сайт работает на самом деле. Canonical - осознанный выбор? OK. Нет gzip на origin за CDN? OK. Нет JSON-LD в «голом» HTML у SPA? Нужно проверить рендеринг.

4. Выделяю реальные проблемы. Не 47, а 3-5. Те, которые реально влияют на обход, индексацию и опыт пользователя.

5. Даю понятные рекомендации. Не «исправьте критичные ошибки», а «вот эти три вещи - сделайте в первую очередь», с пояснением почему.

Как проверить аудит самостоятельно

Не обязательно нанимать второго аудитора. Пять шагов, которые можно сделать за 15 минут:

Шаг 1. Откройте каждую «критичную» задачу. Не верьте на слово. Если написали «битая ссылка» - откройте ссылку в браузере. Если это YouTube, VK, Telegram, Google Maps или любой внешний ресурс - это не ваша проблема.

Шаг 2. Проверьте gzip через браузер. DevTools - Network - обновите страницу - выберите HTML-запрос - Response Headers. Если есть content-encoding: gzip (или br) - сжатие есть. Неважно, откуда оно: origin или CDN.

Шаг 3. Проверьте JSON-LD в браузере. Правая кнопка - «Просмотреть код» - консоль:

JSON.parse(document.querySelector('script[type="application/ld+json"]').textContent)

Если разметка есть - её не увидел сканер, а не сайт. Если разметки нет - тогда да, это проблема. Но сначала убедитесь, что проверка шла не только через «голый» HTTP без JS.

Шаг 4. Проверьте canonical. В исходном коде страницы найдите в <head> тег <link rel="canonical">. Canonical с www на non-www - норма. И наоборот тоже. Важно, чтобы он указывал на главную версию страницы. Если canonical ведёт на другую страницу без причины - это уже повод разбираться.

Шаг 5. Проверьте Cache-Control через браузер. DevTools - Network - любой запрос - Response Headers. Если есть Cache-Control - кэширование для пользователя есть. Если нет - проверьте, стоит ли сайт за CDN: CDN часто ставит свой заголовок.

Когда аудит всё-таки нужен

Да, автоматические сканеры часто врут. Но это не значит, что аудит не нужен.

Аудит нужен. Но он должен быть с контекстом: эксперт, который понимает, что делает.

Хороший аудитор не просто запускает сканер. Он смотрит на сайт глазами пользователя и робота. Он понимает, почему canonical ведёт именно так. Он знает, что CDN может сжимать за вас. Он проверяет JSON-LD в браузере, а не только через «голый» запрос.

Если хотите понять, что реально нужно исправить на сайте - начните с бесплатной проверки Health Score или разберите снимок на странице «Второе мнение». Не 47 пунктов ради галочки, а приоритеты с пояснением.

Итог

SEO-аудит - это не чек-лист из 47 пунктов. Это анализ, который должен отвечать на вопрос: «почему сайт не растёт в поиске?»

Если аудит говорит «у вас 47 критичных проблем», а сайт при этом работает, трафик есть, конкуренты не жалуются - скорее всего, это не аудит. Это чек-лист, который кто-то сгенерировал автоматически.

Не тратьте деньги на исправление того, что не сломано. Проверьте аудит сами по этим пяти шагам. Или откройте второе мнение и сравните, что реально влияет на сайт.

Помните: если кто-то говорит, что у вас 47 критичных проблем, а вы не видите ни одной - проблема не всегда в сайте. Часто проблема в методе аудита.

Проверьте свой сайт и аудит

Уже получили SEO-аудит и сомневаетесь? Сначала прогоните сайт через бесплатную проверку на SEO Quest - увидите технический снимок без «всех задач критичны».

Нужен разбор чужого аудита или приоритетов - напишите через контакты или откройте воронку «Второе мнение». Пришлите аудит в удобном формате (PDF, текст, скриншот): разберём, что делать, а что можно игнорировать.