Один разработчик прогнал 20 промптов через Perplexity API по три повтора, собрал 60 ответов и вручную связал каждую цитату с её источником. Итог: из 85 абзацев на странице модель берёт медианно два. Если вы пишете контент в расчёте на AI-поиск, это меняет всё — не «оптимизируйте страницу», а «напишите два правильных абзаца».

Что Perplexity реально делает с вашей страницей

Perplexity работает по схеме RAG (retrieval-augmented generation): находит страницы, извлекает из них фрагменты, отдаёт фрагменты в модель, модель пишет ответ со ссылками. Ключевое слово — «фрагменты».

В Search API есть параметр search_context_size со значениями low / medium / high, который управляет глубиной извлечения, и max_tokens_per_page — жёсткий лимит токенов с одной страницы. Как именно система нарезает страницу на куски и какой кусок выбирает — в документации не описано.

Из 1355 проанализированных отсылок 948 вели на живые страницы. На 448 из них нашёлся пассаж, покрывающий хотя бы треть слов утверждения из ответа. Медианный результат: два задействованных фрагмента из 85 на странице, каждый длиной около 49 слов. По словам это 6,4% текста при среднем 11,6% — сработавшие куски длиннее типичного абзаца.

Как Perplexity режет страницу: логика, которую можно использовать

Система делит HTML не по переносам строк, а по смысловым тегам: </p>, </li>, </h1>–</h6>, </td>, </blockquote>. Именно они — границы единицы смысла. </div> в счёт не идёт: он оборачивает и обёртку, и содержимое, поэтому один текст попадал бы в выборку дважды.

Вот как это выглядит в коде, который использовал автор исследования:

python
import re
import html as htmllib

TAG_SPLIT = re.compile(r"</(?:p|li|h[1-6]|td|blockquote)>", re.I)
WORD = re.compile(r"[а-яёa-z0-9]+", re.I)

def passages(html):
    """Страница → список видимых кусков: абзац, пункт списка, заголовок, ячейка."""
    body = re.sub(r"<(script|style|noscript|svg)\b.*?</\1>", " ", html, flags=re.S | re.I)
    head = re.search(r"<body\b.*", body, flags=re.S | re.I)
    body = head.group(0) if head else body
    out = []
    for chunk in TAG_SPLIT.split(body):
        txt = htmllib.unescape(re.sub(r"<[^>]+>", " ", chunk))
        txt = re.sub(r"\s+", " ", txt).strip()
        if len(txt.split()) >= 5:
            out.append(txt)
    return out

Куски короче 5 слов на этапе парсинга и короче 8 слов на этапе сравнения отбрасываются — это пункты меню, хлебные крошки, одиночные кнопки.

Практический вывод: чистый семантический HTML напрямую влияет на то, попадёте ли вы в ответ. Страница с кашей из <div> без <p> и <li> хуже парсится — не поисковиком, а самой моделью на этапе извлечения.

Как писать абзацы, которые вытащат

Данные исследования и логика RAG-систем дают конкретные правила:

Один абзац — одно утверждение. Модель ищет кусок, который покрывает конкретный факт из запроса. Абзац на 200 слов с тремя мыслями проиграет абзацу на 50 слов с одной чёткой.

Оптимальная длина — 40–60 слов. Медианный сработавший фрагмент в исследовании — около 49 слов. Это не случайно: слишком короткий кусок не несёт контекста, слишком длинный размывает сигнал.

Факт в начале предложения. Perplexity взвешивает релевантность по совпадению основ слов между запросом и пассажем. Если ключевое утверждение стоит в первом предложении абзаца — совпадение выше.

Структура важнее красоты. Иерархия <h2> / <h3>, списки <ul> / <ol>, таблицы с <td> — всё это создаёт границы пассажей, по которым система режет страницу. Сплошной текст без разметки даёт системе меньше точек входа.

ЭлементСоздаёт границу пассажаРекомендация
`<p>`ДаОсновной контейнер для фактов
`<li>`ДаДля перечислений и определений
`<h2>`–`<h6>`ДаСтруктурируйте каждые 200–300 слов
`<td>`ДаТаблицы работают как источники фактов
`<div>`НетНе используйте как замену `<p>`

Что влияет на попадание в источники помимо текста

Perplexity использует два краулера: PerplexityBot строит поисковый индекс, Perplexity-User забирает страницу в реальном времени при запросе. Страница должна быть доступна обоим.

Система классифицирует запрос до поиска — в стриме виден classifier_results с шестнадцатью intent-головами и их вероятностями. Это значит, что страница конкурирует не со всем вебом, а с узкой категорией источников по теме запроса.

Четыре фактора ранжирования, которые подтверждают и данные исследования, и внешние наблюдения:

  • Релевантность — страница отвечает на конкретный вопрос, а не на тему в целом
  • Свежесть — дата публикации и обновления весят много; устаревший контент проигрывает даже при высоком качестве
  • Авторитет — указанный автор, редакционная ответственность, внешние ссылки
  • Структура — чистый парсируемый HTML, иерархия заголовков, минимум JavaScript-рендеринга

Где ломается

JavaScript-рендеринг. Если контент появляется только после выполнения JS, PerplexityBot может не дождаться — и страница попадёт в индекс пустой или частичной.

Дублирование через `<div>`. Вёрстка, где один и тот же текст обёрнут в несколько вложенных <div>, раздувает счётчик пассажей и снижает вес каждого отдельного фрагмента при сравнении.

Длинные «простыни» без структуры. Страница из одного <p> на 3000 слов даёт системе один пассаж. Шансы, что именно он покроет запрос, минимальны.

Слишком короткие пункты списка. Фрагменты короче 8 слов отбрасываются как шум. Пункты вида «Быстро. Удобно. Надёжно.» не участвуют в сравнении.

Закрытый `robots.txt` для PerplexityBot. Очевидно, но часто упускается: если бот заблокирован, страница не попадёт в индекс вне зависимости от качества контента.

Что попробовать дальше

Запустите собственный анализ через Perplexity Search API с sonar-pro и search_context_size: high — посмотрите, какие ваши страницы попадают в search_results, и сравните их структуру с теми, что не попадают. Код для парсинга пассажей выше — рабочая отправная точка.

FAQ

Сколько текста Perplexity берёт с одной страницы?

По данным исследования на 60 ответах: медианно два фрагмента из 85 на странице, каждый около 49 слов. В сумме это примерно 6,4% текста страницы, хотя среднее значение выше — 11,6%, потому что сработавшие куски длиннее типичного абзаца.

Нужно ли писать точные фразы из поисковых запросов?

Нет. Perplexity пересказывает источники, а не копирует. Совпадение ищется по основам слов (стеммингу), а не по точным фразам. Важнее, чтобы абзац содержал ключевые термины темы, а не дословные формулировки запроса.

Как узнать, цитирует ли Perplexity мою страницу?

Через Perplexity Search API: в ответе приходят поля search_results и citations с URL источников. Поля с полным извлечённым текстом нет — видны только title, url, date, last_updated и snippet.

Помогает ли разметка FAQ и таблицы попасть в ответы?

Да. Теги <td> создают границы пассажей, по которым система режет страницу. Таблицы с фактами и списки определений — хорошие кандидаты для извлечения: компактные, структурированные, с высокой плотностью информации.

Влияет ли дата публикации на попадание в источники Perplexity?

Влияет существенно. Perplexity взвешивает свежесть как один из ключевых факторов ранжирования. Устаревший материал проигрывает более свежему даже при сопоставимом качестве и структуре.

Источники