Технический аудит цитируемости страницы: как считается скор и что с ним делать

Почему один скор лучше, чем десять разрозненных ошибок

Когда мы работаем с GEO-оптимизацией, мы часто сталкиваемся с ситуацией: SEO-специалист получает технический аудит страницы, видит список из десяти замечаний и не понимает, с чего начать. То ли мета-описание переписать, то ли H1 исправить, то ли дату публикации добавить. Каждый пункт кажется одинаково важным, и решение принимается на основе интуиции, а не системы.

Именно для решения этой проблемы мы в агентстве разработали детерминированный инструмент — он не обращается к внешним AI/LLM API, а просто разбирает сырой HTML страницы по десяти чётким проверкам. Результат работы — не просто список «да/нет», а единый числовой скор от 0 до 100, который переводится в понятный статус: PASS, WARN или FAIL. Когда у вас есть одно число, приоритизация задач перестаёт быть гаданием: сначала вы закрываете всё, что даёт FAIL, затем переходите к WARN, и только потом полируете до идеального PASS.

В этой статье мы подробно разберём каждую из десяти проверок, объясним, почему именно эти параметры важны для цитируемости нейросетями (а не для классического SEO), и покажем на абстрактном примере, как считается итоговый скор. Если захотите прогнать свою страницу — в конце статьи будет ссылка на инструмент технического аудита цитируемости, он бесплатный и не требует регистрации.

Что такое технический аудит цитируемости и зачем он нужен

Прежде чем перейти к разбору проверок, давайте зафиксируем терминологию. Под цитируемостью мы понимаем вероятность того, что нейросеть (например, большая языковая модель, которая формирует ответы на поисковые запросы) использует содержимое вашей страницы как источник для своего ответа. Это не факториал ранжирования Google — мы не претендуем на то, что скор каким-то образом влияет на позиции в классической выдаче. Это собственная эвристика агентства, которая помогает оценить, насколько страница «готова к цитированию» с точки зрения формальных, технических признаков.

Почему вообще нужен технический аудит, если можно просто написать хороший контент? Дело в том, что нейросети при формировании ответов обращают внимание на структуру документа. Модель обучалась на миллионах страниц, и она «привыкла», что качественный источник обычно имеет чёткий H1, разбит на подзаголовки, содержит дату публикации и размеченную разметку Schema.org. Если ваша страница технически «грязная» — например, без единого H2 или с тремя H1 — модель может посчитать её менее авторитетной и предпочесть более структурированный конкурент.

Инструмент реализован как PHP-сервис, который принимает URL страницы и опциональное поле «название бренда», а затем анализирует сырой HTML. Никакого машинного обучения и «чёрных ящиков» — только детерминированные проверки, каждую из которых можно воспроизвести вручную. Это важно для прозрачности: вы всегда можете объяснить клиенту, почему его страница получила именно такой скор.

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

1. H1-заголовок: единственность и длина

Что проверяется: Инструмент ищет теги <h1> в HTML-коде страницы. Условие PASS — ровно один H1, длина которого не превышает 100 символов. WARN — на странице несколько H1. FAIL — H1 отсутствует вовсе.

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

Как достичь PASS: Убедитесь, что на странице ровно один тег <h1>, и он содержит лаконичный заголовок до 100 символов. Логотип в шапке сайта часто оборачивают в H1 — это типичная ошибка, из-за которой появляются два H1.

Типичная причина WARN/FAIL: WARN возникает на сайтах, где разработчики дублируют H1 в разных блоках (например, в мобильной и десктопной версии). FAIL — на страницах, свёрстанных с нарушением иерархии, когда вместо H1 используется просто крупный текст в <div> или <p>.

2. Структура H2/H3: наличие подзаголовков

Что проверяется: Считается количество подзаголовков второго и третьего уровня. PASS — три и более подзаголовков. WARN — один или два. FAIL — ноль.

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

Как достичь PASS: Разбейте контент на смысловые разделы и озаглавьте каждый из них. Для статьи объёмом 500+ слов трёх подзаголовков обычно недостаточно — стремитесь к пяти-семи.

Типичная причина WARN/FAIL: Чаще всего WARN получают страницы-«визитки» или описания товаров, где весь текст умещается в два коротких абзаца. FAIL — это страницы без контента или с текстом, который не разбит на логические блоки.

3. Объём текста: минимальная полнота

Что проверяется: Подсчитывается количество слов в видимом тексте страницы. PASS — 500 и более слов. WARN — от 200 до 499. FAIL — менее 200 слов.

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

Как достичь PASS: Если страница содержит менее 500 слов, расширьте её: добавьте примеры, раскройте смежные вопросы, опишите типичные ошибки. Главное — без «воды», текст должен нести смысловую нагрузку.

Типичная причина WARN/FAIL: WARN получают короткие новости или описания категорий. FAIL — страницы-заглушки, страницы с ошибками валидации, когда текст подгружается скриптами и не виден в сыром HTML.

4. FAQ-структура: маркер вопросов и ответов

Что проверяется: Инструмент ищет тег <dl> (список определений) или заголовки, заканчивающиеся вопросительным знаком. PASS — есть тег <dl> или три и более заголовков с вопросительным знаком. WARN — один или два таких заголовка. FAIL — ни одного.

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

Как достичь PASS: Добавьте в конец статьи блок из 3-5 вопросов, которые пользователи чаще всего задают по теме, и дайте на них краткие ответы. Вопросы должны быть сформулированы так, как их задают живые люди — с вопросительными словами «как», «что», «почему», «сколько».

Типичная причина WARN/FAIL: WARN — когда вопрос задан в заголовке, но ответа на него нет (чисто риторический заголовок). FAIL — на страницах, где нет ни одного вопроса, даже если контент сам по себе хороший.

5. Schema JSON-LD: разметка для поисковых систем

Что проверяется: Инструмент ищет в коде страницы блоки <script type="application/ld+json">. PASS — найден JSON-LD с типом FAQPage, Organization или Product. WARN — JSON-LD есть, но тип другой (например, Article или BreadcrumbList). FAIL — JSON-LD нет вообще.

Почему это важно: Разметка Schema.org — это прямой способ сообщить машинам, что находится на странице. Нейросети, которые получают доступ к структурированным данным, могут точнее интерпретировать контент. Особенно ценны типы FAQPage (вопросы и ответы), Organization (данные о компании-авторе) и Product (коммерческие страницы).

Как достичь PASS: Добавьте на страницу JSON-LD разметку соответствующего типа. Для статьи подойдёт FAQPage в связке с Article. Для корпоративного сайта — Organization с логотипом и контактами.

Типичная причина WARN/FAIL: WARN возникает, когда разработчики подключили разметку, но ошиблись в типе (например, использовали WebSite вместо Product на карточке товара). FAIL — на старых сайтах, где разметка вообще не использовалась.

6. Meta Description: длина и наличие

Что проверяется: Проверяется тег <meta name="description">. PASS — длина от 100 до 180 символов. WARN — тег есть, но длина вне диапазона. FAIL — тега нет.

Почему это важно: Хотя нейросети не видят сниппет в поисковой выдаче, они анализируют HTML-код страницы. Meta Description даёт краткое резюме содержимого. Если он отсутствует или слишком короткий, модель может не понять, о чём страница, и пропустить её при формировании ответа. Диапазон 100-180 символов — это оптимум, который позволяет уместить суть без обрезания.

Как достичь PASS: Напишите описание страницы длиной 120-160 символов, которое содержит ключевую тему и призыв к действию. Избегайте перечисления ключевых слов через запятую — это выглядит неестественно для модели.

Типичная причина WARN/FAIL: WARN — когда CMS генерирует описание автоматически из первых слов текста (часто получается слишком короткое или обрывочное). FAIL — на страницах, где мета-теги не заполнены вовсе.

7. Дата публикации: свежесть и точность

Что проверяется: Инструмент ищет тег <time datetime>, мета-тег article:published_time или поле datePublished в JSON-LD. PASS — дата найдена любым из трёх способов. FAIL — дата не найдена. Промежуточного WARN для этого пункта нет.

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

Как достичь PASS: Убедитесь, что в HTML-коде страницы присутствует машиночитаемая дата. Лучший способ — тег <time datetime="2025-01-15">15 января 2025</time> или разметка JSON-LD с полем datePublished.

Типичная причина FAIL: Дата публикации часто отображается визуально на странице, но не выделена тегом <time>. Инструмент анализирует сырой HTML, поэтому «просто текст» в <div> не будет распознан как дата.

8. Упоминание бренда: частота и контекст

Что проверяется: Считается количество вхождений названия бренда в текст страницы. Название передаётся пользователем в отдельном опциональном поле. Если поле не заполнено, инструмент автоматически берёт название из тега <title>. PASS — три и более упоминаний. WARN — одно или два. FAIL — ноль упоминаний.

Почему это важно: Нейросети при ответе на вопрос пользователя часто указывают источник: «Согласно данным компании X». Если бренд не упоминается на странице, модель не может установить авторство и, скорее всего, не будет ссылаться на неё. Для GEO-оптимизации важно, чтобы бренд был не только в шапке сайта, но и в тексте контента — это создаёт ассоциацию «этот контент принадлежит этой компании».

Как достичь PASS: Встраивайте упоминания бренда естественно: в первом абзаце («Компания X, лидер на рынке...»), в середине статьи («Эксперты X рекомендуют...») и в выводах («X продолжает развивать...»). Избегайте «набивки» — упоминания должны быть уместными.

Типичная причина WARN/FAIL: FAIL — на страницах, где бренд упоминается только в подвале сайта или в логотипе (который является картинкой, а не текстом). Инструмент считает только текстовые вхождения. WARN — когда бренд встречается один-два раза, чаще всего в первом и последнем абзаце.

9. Читаемость: длина предложений

Что проверяется: Весь текст страницы разбивается на предложения, и вычисляется среднее количество слов в одном предложении. PASS — 20 слов или меньше. WARN — от 21 до 30 слов. FAIL — более 30 слов в среднем.

Почему это важно: Нейросети лучше обрабатывают текст, который разбит на короткие предложения. Длинные предложения с множеством придаточных конструкций сложны для парсинга — модель может неправильно определить субъект и объект действия, что приведёт к искажению смысла при цитировании. Средняя длина в 15-18 слов считается оптимальной для технических текстов.

Как достичь PASS: Переписывайте слишком длинные предложения, разбивая их на два-три коротких. Используйте простые синтаксические конструкции: подлежащее, сказуемое, дополнение. Убирайте лишние деепричастные обороты.

Типичная причина WARN/FAIL: WARN часто получают юридические тексты и инструкции, написанные канцеляритом. FAIL — если автор злоупотребляет сложноподчинёнными предложениями и вводными конструкциями.

10. Внешние ссылки: наличие авторитетных источников

Что проверяется: Инструмент анализирует все ссылки на странице и определяет, есть ли среди них ссылки на другие домены (не на тот, где расположена сама страница). PASS — одна и более внешняя ссылка. WARN — ноль внешних ссылок. FAIL для этого пункта не предусмотрен.

Почему это важно: Наличие внешних ссылок показывает, что автор опирается на другие источники и не боится отсылать читателя к ним. Для нейросети это сигнал, что контент создан на основе исследования, а не является «водой». Однако здесь важно качество: ссылки на авторитетные домены (Wikipedia, государственные сайты, отраслевые лидеры) ценятся выше, чем ссылки на случайные блоги.

Как достичь PASS: Добавьте в текст две-три ссылки на авторитетные источники: исследования, официальную документацию, крупные отраслевые порталы. Ссылки должны быть релевантны контексту и открываться в новой вкладке.

Типичная причина WARN: WARN получают страницы, которые ссылаются только на внутренние материалы сайта. Это не ошибка, но для GEO-цитируемости лучше иметь хотя бы одну внешнюю ссылку.

Сводная таблица проверок

Проверка	PASS	WARN	FAIL
H1-заголовок	Ровно один H1, длина ≤ 100 символов	Несколько H1	H1 отсутствует
Структура H2/H3	≥ 3 подзаголовков	1–2 подзаголовка	0 подзаголовков
Объём текста	≥ 500 слов	200–499 слов	< 200 слов
FAQ-структура	Тег <dl> или ≥ 3 заголовков с вопросом	1–2 заголовка с вопросом	0 вопросов
Schema JSON-LD	FAQPage/Organization/Product	JSON-LD другого типа	JSON-LD нет
Meta Description	Длина 100–180 символов	Длина вне диапазона	Тега нет
Дата публикации	Найден <time> или datePublished	—	Дата не найдена
Упоминание бренда	≥ 3 вхождений	1–2 вхождения	0 вхождений
Читаемость	≤ 20 слов/предложение	21–30 слов/предложение	> 30 слов/предложение
Внешние ссылки	≥ 1 внешней ссылки	0 внешних ссылок	—

Пример расчёта скора на абстрактном сайте

Давайте рассмотрим гипотетический пример. Предположим, мы анализируем страницу Y на сайте X — статью о том, как выбрать CRM-систему для малого бизнеса. Владелец сайта передал в инструмент название бренда «БизнесКонсалт». Вот какие результаты показал аудит по десяти пунктам:

• H1-заголовок: на странице ровно один H1 «Как выбрать CRM для малого бизнеса в 2025 году» (длина 51 символ) — PASS.
• Структура H2/H3: найдено 5 подзаголовков H2 и 3 H3 — PASS.
• Объём текста: в тексте 1 240 слов — PASS.
• FAQ-структура: в конце статьи есть блок с 4 вопросами («Какая CRM лучше для 10 сотрудников?», «Сколько стоит внедрение?» и т.д.) — PASS.
• Schema JSON-LD: в коде найден JSON-LD с типом FAQPage — PASS.
• Meta Description: длина описания 145 символов — PASS.
• Дата публикации: тег <time datetime="2025-02-10"> присутствует — PASS.
• Упоминание бренда: «БизнесКонсалт» упоминается 4 раза: в первом абзаце, в разделе об опыте, в примере из практики и в заключении — PASS.
• Читаемость: средняя длина предложения составила 17 слов — PASS.
• Внешние ссылки: страница содержит 2 ссылки на внешние источники (исследование рынка и статью на отраслевом портале) — PASS.

Теперь посчитаем скор. У нас 10 оценок PASS, ни одного WARN и ни одного FAIL. Подставляем в формулу:

(число PASS * 2 + число WARN) / (10 * 2) * 100 = (10 * 2 + 0) / 20 * 100 = 20 / 20 * 100 = 100

Скор равен 100 — это отличный результат. Статус PASS (хорошо), страница готова к цитированию.

Теперь рассмотрим второй абстрактный пример — страницу Z на том же сайте X, но это карточка услуги «Внедрение CRM под ключ». Результаты:

• H1: один H1 «Внедрение CRM под ключ» — PASS.
• Структура H2/H3: всего 2 подзаголовка — WARN.
• Объём текста: 380 слов — WARN.
• FAQ: ни одного вопросительного заголовка, тега <dl> нет — FAIL.
• Schema JSON-LD: есть JSON-LD с типом Service (не входит в список PASS) — WARN.
• Meta Description: длина 85 символов — WARN.
• Дата публикации: не найдена — FAIL.
• Упоминание бренда: «БизнесКонсалт» встречается 1 раз в конце текста — WARN.
• Читаемость: средняя длина предложения 24 слова — WARN.
• Внешние ссылки: ссылок на другие домены нет — WARN.

Считаем скор: у нас 1 PASS, 7 WARN, 2 FAIL.

(1 * 2 + 7) / (10 * 2) * 100 = (2 + 7) / 20 * 100 = 9 / 20 * 100 = 45

Скор равен 45. Это статус FAIL (критично). Странице требуются серьёзные доработки. Обратите внимание, как формула наказывает за FAIL: всего два «критических» пункта обнулили даже хороший H1 и снизили результат до 45 баллов.

Ещё один пример — страница W, статья-гайд из 800 слов. Результаты:

• H1: два H1 (один в шапке от логотипа, второй — заголовок статьи) — WARN.
• Структура H2/H3: 6 подзаголовков — PASS.
• Объём: 800 слов — PASS.
• FAQ: 2 вопроса в конце — WARN.
• Schema: JSON-LD типа Article (не подходит) — WARN.
• Meta Description: 160 символов — PASS.
• Дата: meta article:published_time найден — PASS.
• Бренд: не указан пользователем, взят из title «БизнесКонсалт — блог», в тексте 2 упоминания — WARN.
• Читаемость: 19 слов на предложение — PASS.
• Внешние ссылки: 1 ссылка на Wikipedia — PASS.

Скор: 5 PASS, 5 WARN, 0 FAIL.

(5 * 2 + 5) / 20 * 100 = (10 + 5) / 20 * 100 = 15 / 20 * 100 = 75

Скор 75 — статус WARN (нужны доработки). Страница не провальная, но до «хорошо» не дотягивает. Убрав дублирующий H1 и добавив третий вопрос в FAQ, можно поднять скор до 85.

Что делать с результатом: приоритизация по статусам

Получив числовой скор и статус, важно правильно расставить приоритеты. Наша рекомендация — работать в два этапа.

Этап 1: Устранить все FAIL. Пункты со статусом FAIL — это критические проблемы, которые существенно снижают вероятность цитирования. Например, отсутствие даты публикации на странице — это автоматический минус к доверию со стороны нейросети, потому что модель не может проверить актуальность. Отсутствие FAQ-структуры — это потерянный шанс быть процитированным по конкретному вопросу пользователя. Начните с FAIL, даже если их всего один-два. Каждый устранённый FAIL даёт существенный прирост к скору — на 10 процентных пунктов (так как один FAIL «стоит» 0 баллов, а после исправления до PASS приносит 2 балла из 20, то есть 10%).

Этап 2: Перейти к WARN. Когда критических ошибок нет, займитесь предупреждениями. Здесь важно оценить, какие WARN легче всего превратить в PASS. Например, добавить третье упоминание бренда в текст — это 15 минут работы, а вот переписывание всех предложений для улучшения читаемости с 25 до 19 слов — это несколько часов. Начните с «быстрых» пунктов: упоминание бренда, внешние ссылки, FAQ-структура. Они дают по 5 процентных пунктов за каждый исправленный WARN (1 балл из 20).

Если вы устранили все FAIL и хотя бы половину WARN, скор обычно поднимается выше 80, что соответствует статусу PASS. Дальнейшая полировка до 100 баллов не всегда обязательна — но если вы работаете в высококонкурентной нише, где нейросети цитируют только идеально структурированные страницы, стремитесь к максимуму.

Важно помнить: скор — это не самоцель. Это ориентир. Если у вас скор 75 (WARN), но страница уже приносит цитирования — не спешите её переделывать. Сначала зафиксируйте текущий уровень цитируемости, внесите изменения, затем снова прогоните аудит и сравните динамику. Только так можно понять, что именно влияет на результат.

Ограничения методологии: что скор не показывает

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

Первое: скор не гарантирует попадание в ответ ИИ. Формула оценивает формальные признаки, которые коррелируют с цитируемостью, но не являются её причиной. Нейросеть может процитировать страницу со скором 30, если контент уникален и точно отвечает на вопрос пользователя. И наоборот — страница со скором 100 может быть проигнорирована, если в выдаче есть более авторитетный источник. Скор — это подготовка почвы, а не гарантия урожая.

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

Третье: скор не равен EEAT. EEAT (опыт, экспертность, авторитетность, доверие) — это комплексная оценка, которую поисковые системы применяют к целому сайту, а не к отдельной странице. Наш инструмент проверяет только технические признаки одной страницы. Даже если скор 100, но сайт принадлежит неизвестной компании без контактов и информации об авторах, нейросеть может предпочесть страницу конкурента со скором 70, но с явными сигналами экспертности (биографии авторов, список публикаций, отзывы клиентов).

Четвёртое: инструмент не анализирует качество контента. Он считает слова и заголовки, но не понимает смысла. Страница может быть набрана бессмысленным текстом со скором 100 — но она не будет цитироваться, потому что нейросеть определяет бессмысленность по семантике. Поэтому воспринимайте скор как технический фильтр: сначала вы проходите фильтр (скор ≥ 80), а потом уже конкурируете за цитирование качеством контента.

Пятое: детерминированность — это осознанный выбор. Мы не используем AI-модели внутри аудита, потому что это сделало бы результаты непредсказуемыми и сложными для объяснения клиенту. Детерминированный алгоритм означает, что один и тот же URL всегда даст один и тот же результат — это позволяет отслеживать динамику изменений и точно знать, какой пункт повлиял на скор.

FAQ: частые вопросы о техническом аудите цитируемости

1. Чем этот скор отличается от классического SEO-аудита?

Классический SEO-аудит ориентирован на поисковые системы: индексирование, скорость загрузки, перелинковку, коммерческие факторы. Наш скор нацелен на цитируемость нейросетями: структура заголовков, наличие разметки JSON-LD, даты публикации, упоминание бренда в тексте. Это разные наборы параметров, хотя они частично пересекаются (например, H1 и мета-описание важны и для SEO, и для GEO).

2. Обязательно ли указывать название бренда при аудите?

Нет, поле опциональное. Если оставить его пустым, инструмент возьмёт название бренда из тега <title> страницы автоматически — это менее точно, но избавляет от лишнего шага, если бренд и так фигурирует в заголовке.

3. Можно ли получить скор 100, если страница на самом деле слабая по содержанию?

Технически да — инструмент считает формальные признаки, а не оценивает смысл текста. Скор 100 говорит «страница технически готова к тому, чтобы её процитировали», а не «контент гарантированно уникален и полезен». Это фильтр на входе, а не замена редактуре.

4. Почему у проверки «Внешние ссылки» нет статуса FAIL?

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

5. Как часто стоит перепроверять одну и ту же страницу?

После каждого заметного обновления содержания — новой версии текста, добавления FAQ-блока, правки схемы. Для страниц без изменений достаточно разовой проверки: скор не меняется сам по себе, если не менялся HTML.