Сколько знаков должно быть в статье: что важно поисковикам и ИИ-ассистентам

Нормы в знаках для статьи не существует. Объём определяется тем, на сколько вопросов читателя статья должна ответить: закрыты все — статья готова, при 4 000 знаков или при 20 000. Это не только наш опыт, но и официальная позиция Google: в руководстве по генеративному поиску 2026 года прямо сказано, что идеальной длины страницы нет. Для ИИ-ассистентов — ChatGPT, Perplexity, ИИ-ответов Google и Яндекса — отдельной нормы тоже нет. Разница между ними и обычным поисковым роботом в другом, и она в основном техническая. Ниже — что говорит Google, как определить объём без числа знаков и что проверить на сайте, чтобы статью видели и поисковики, и ИИ.

Что говорит Google о длине статьи

Google никогда не называл число слов или знаков фактором ранжирования. В 2020 году Джон Мюллер из Google отвечал на вопросы о длине текста, что количество слов не говорит о том, насколько полно раскрыта тема, и поиск его не использует как метрику.

В 2026 году эта позиция закреплена в официальном документе. В руководстве Google по оптимизации сайта для генеративных ИИ-функций поиска (опубликовано в мае 2026, обновлено в июле) сказано:

• идеальной длины страницы нет — короткие и длинные страницы работают в зависимости от аудитории и темы;
• ИИ-ответы Google (AI Overviews и AI Mode) построены на тех же системах ранжирования, что и обычный поиск;
• специальных требований, файлов или разметки для попадания в ИИ-ответы нет;
• переписывать существующие тексты «под ИИ» не нужно.

Главное, что Google ценит и в обычной выдаче, и в ИИ-ответах, — уникальное содержание: собственный опыт автора, данные компании, то, чего нет на десятке похожих страниц.

Откуда взялись нормы в знаках

Если нормы нет, почему в ТЗ копирайтеру до сих пор пишут «8 000–15 000 знаков»? Причина практическая: текст заказывают и оплачивают по знакам, поэтому число нужно для сметы. Чтобы его обосновать, берут среднюю длину страниц в топ-10 выдачи.

У этого метода две проблемы.

1. Корреляция — не причина. Страницы в топе длинные, потому что подробно отвечают на вопрос, а не потому что набрали объём. Если добить текст до средней длины повторами и общими словами, позиция не вырастет.
2. Число знаков становится критерием приёмки. Текст принимают, потому что в нём 12 000 знаков, а не потому что он отвечает на вопросы клиента. Так в блоге появляются статьи, где первые три абзаца — вступление ни о чём.

Ориентир по объёму в смете можно оставить — но как оценку трудозатрат, а не как требование к тексту.

Как определить объём статьи без нормы в знаках

Вместо числа знаков мы используем четыре критерия.

1. Список вопросов вместо объёма. Основной запрос разбирается на вопросы, которые задают люди: подсказки поиска, блок «Похожие вопросы», запросы из Search Console и Яндекс Вебмастера, вопросы из заявок и звонков. Каждый вопрос — свой раздел. Раздел без вопроса — лишний текст. Вопрос без раздела — статья неполная, сколько бы в ней ни было знаков.
2. Ответ в начале. Сначала прямой ответ, потом подробности и оговорки. Это правило работает для всей статьи — первый абзац отвечает на главный вопрос — и для каждого раздела.
3. Раздел понятен сам по себе. Читатель часто попадает в середину статьи по ссылке или из оглавления. Раздел должен отвечать на свой заголовок без опоры на предыдущие: без «как мы писали выше», с прямым названием термина вместо «это».
4. Реальные ограничения. Время на вычитку специалистом — для юридических, медицинских и финансовых тем она обязательна — и на перевод, если сайт на нескольких языках. Часто именно это, а не поиск, определяет разумный объём статьи.

Если тема не помещается в одну статью, её делят по разным запросам, а не по длине. Две статьи под один и тот же запрос конкурируют друг с другом в выдаче.

Нужно ли писать статьи отдельно для ИИ-ассистентов

Нет. По содержанию требования поисковика и ИИ-системы почти совпадают: полезный, понятный, хорошо структурированный текст.

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

Отсюда спор о «чанкинге» — дроблении текста на короткие самостоятельные куски специально под ИИ.

• Google против. Представители Google в начале 2026 года прямо сказали, что дробить контент на мелкие части под языковые модели не нужно, и это вошло в официальное руководство.
• Microsoft за понятную структуру. В рекомендациях Microsoft для ИИ-поиска Bing (октябрь 2025) советуют чёткие заголовки H2 и H3, формат «вопрос — ответ», списки, таблицы и формулировки, понятные вне контекста. И предупреждают против «стен текста».

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

Чем ИИ-боты отличаются от поискового робота

Главное отличие — техническое, и оно важнее любого объёма. Если ИИ-бот не видит текст, неважно, сколько в нём знаков.

Отдельно про защиту сервера от ботов. Файрволы и сервисы защиты часто блокируют ИИ-ботов по умолчанию, и владелец сайта об этом не знает. Если заблокирован OAI-SearchBot, сайт не попадает в ответы ChatGPT. Блокировать ли ботов, которые собирают данные для обучения моделей, — отдельное решение владельца, на попадание в поисковые ответы оно не влияет (справка OpenAI).

Что не помогает попасть в ИИ-ответы

• Файл llms.txt как способ продвижения. Google Search его не использует, доказательств влияния на цитирование в других ИИ-сервисах нет. Платить за него как за «ИИ-оптимизацию» не стоит.
• Две версии контента — «для людей» и «для ИИ». Google прямо пишет, что отдельные тексты под ИИ не нужны.
• Дробление текста ради ИИ. Короткие абзацы без связи между собой хуже читаются и не дают устойчивого эффекта.
• Отдельная страница под каждую формулировку запроса. Модели понимают смысл, а массовое производство однотипных страниц Google относит к нарушению своих правил.

Как мы готовим статьи в блоге Пантеры

Эти правила мы применяем в блоге pantera.kz и в блогах клиентских сайтов.

• В ТЗ — вопросы, а не знаки. Перед написанием собираем вопросы из поиска и из заявок. Статья принимается, когда закрыт каждый вопрос, нет разделов без вопроса и нет повторов между разделами.
• Ответ в первом абзаце. Тот, кто открыл статью из поиска или из ИИ-ответа, сразу видит ответ на свой вопрос.
• Автор и дата на странице. Указан автор с должностью и дата публикации. При содержательной правке появляется дата обновления.
• Текст в исходном HTML. Panther CMS отдаёт статью целиком в коде страницы, без подгрузки скриптами. Вопросы и ответы в конце статьи и их микроразметка тоже есть в исходном HTML. Проверка простая: открыть страницу с отключённым JavaScript.
• Ссылки на первоисточники. Цифры без источника не публикуем.
• Измеряем результат, а не объём. В Search Console есть отчёт по генеративным ИИ-функциям, в Яндекс Вебмастере — «Видимость сайта в Алисе AI». Переходы из ChatGPT приходят с меткой utm_source=chatgpt.com, их можно выделить в отдельный сегмент в Метрике и GA4. Статью оцениваем по заявкам, дочитываниям и переходам на страницы услуг.

Если блог на вашем сайте не приносит обращений или вы не уверены, видят ли его ИИ-боты, — начните с проверки трёх вещей: есть ли текст в исходном HTML, открыт ли доступ ботам в robots.txt и защите сервера, отвечает ли первый абзац на вопрос из заголовка. Ведение и развитие блога входит в поддержку и развитие сайта, а новый корпоративный сайт мы сразу собираем с учётом этих правил.

Обсудить задачу →