# Заполнение WT LLMs через Joomla REST API

Настрой компонент WT LLMs для сайта:

**Сайт:** {{SITE_URL}}

**Точка входа и актуальная схема WT LLMs:**

{{SCHEMA_URL}}

**Публичные результаты:**

* llms.txt: {{LLMS_TXT_URL}}
* llms.json: {{LLMS_JSON_URL}}

{{OWNER_INSTRUCTIONS}}

## Цель

Исследуй публичное содержимое сайта и заполни WT LLMs через REST API так, чтобы файлы `llms.txt` и `llms.json`:

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

Не создавай `llms.txt` и `llms.json` локально вместо работы с компонентом. Все данные должны быть сохранены через REST API WT LLMs, после чего необходимо вызвать REST-метод генерации файлов.

## Авторизация

Используй Joomla REST API от имени авторизованного пользователя Joomla.

Для API должен использоваться токен Joomla, принадлежащий пользователю с необходимыми разрешениями. Токен или другие данные авторизации предоставляются отдельно от этого промта.

Обычно токен Joomla передаётся в заголовке:

```http
X-Joomla-Token: <JOOMLA_API_TOKEN>
```

Не выводи токен:

* в итоговом отчёте;
* в журнале выполненных запросов;
* в примерах команд;
* в сообщениях об ошибках;
* в сохранённых данных WT LLMs.

Для выполнения задачи пользователь Joomla должен иметь разрешения:

* просмотр и управление компонентом;
* создание записей;
* редактирование записей;
* генерация файлов WT LLMs.

По умолчанию не удаляй записи. Удаление или снятие с публикации допускается только при явном указании владельца сайта.

Если авторизация отсутствует или прав недостаточно, прекрати операции записи и точно сообщи, какого разрешения или способа авторизации не хватает.

## Схема является источником истины

Первым запросом получи схему:

```http
GET {{SCHEMA_URL}}
```

Изучи содержащиеся в ней:

* доступные REST-маршруты;
* HTTP-методы;
* поля профиля;
* поля интентов;
* поля канонических страниц;
* правила заполнения `llms.txt`;
* правила генерации;
* допустимые значения;
* обязательные поля;
* формат связей между страницами и интентами;
* REST-метод генерации файлов.

Не полагайся на заранее известную структуру компонента, если она отличается от полученной схемы.

Не отправляй поля, которых нет в актуальной схеме.

Если схема и этот промт противоречат друг другу в технических деталях, используй актуальную схему. Смысловой порядок работы из этого промта сохраняется.

## Основные правила достоверности

Исследуй сайт с нуля.

Не используй:

* память из предыдущих разговоров;
* сведения о компании или владельце, которых нет на сайте;
* неподтверждённые данные из поисковых сниппетов;
* предположения на основании доменного имени;
* рекламные формулировки, не подтверждённые содержимым сайта.

Не придумывай:

* услуги;
* товары;
* характеристики;
* цены;
* сроки;
* гарантии;
* клиентов;
* кейсы;
* адреса;
* географию работы;
* технологии;
* сертификаты;
* награды;
* партнёрства;
* версии программного обеспечения;
* юридические условия.

Неизвестные поля оставляй пустыми.

Каждое существенное утверждение должно подтверждаться одной или несколькими публичными страницами сайта.

## Порядок выполнения

Строго соблюдай следующий порядок:

1. Получить схему WT LLMs.
2. Авторизоваться в Joomla REST API.
3. Получить уже сохранённые данные компонента.
4. Просканировать публичные страницы сайта.
5. Сформировать смысловую модель сайта.
6. Обновить профиль.
7. Создать или обновить интенты.
8. Повторно получить интенты и их числовые ID.
9. Создать или обновить канонические страницы и привязать их к интентам.
10. Вручную составить и сохранить содержательную часть `llms.txt`.
11. Проверить сохранённые данные.
12. Вызвать REST-метод генерации.
13. Проверить созданные `/llms.txt` и `/llms.json`.
14. Выдать итоговый отчёт.

Не создавай канонические страницы раньше интентов: страницы связываются с уже существующими числовыми ID интентов.

## Шаг 1. Получение текущих данных

После авторизации получи через маршруты, указанные в схеме:

* текущий профиль;
* ручную часть `llms.txt`;
* состояние импорта или raw JSON override;
* существующие интенты;
* существующие канонические страницы.

Сохрани соответствия:

```text
intent_key → numeric intent ID
page_key → numeric page ID
```

Обновляй данные идемпотентно:

* найди существующий интент по `intent_key`;
* найди существующую страницу по `page_key`;
* обновляй найденную запись через `PATCH`;
* создавай запись через `POST`, только если соответствующего ключа нет;
* не создавай дубликаты;
* не меняй стабильные ключи существующих записей без необходимости;
* при `PATCH` передавай только изменяемые поля, чтобы не стереть неизвестные значения.

Если включён полный raw JSON override, отключи его перед структурированным заполнением, если владелец сайта явно не потребовал обратного.

## Шаг 2. Сканирование сайта

Начни с главной страницы сайта.

Затем проверь:

* `robots.txt`;
* sitemap и все связанные sitemap-файлы;
* основное меню;
* ссылки с главной страницы;
* страницы услуг;
* страницы товаров;
* категории и каталоги;
* страницы о компании или авторе;
* контакты;
* портфолио и кейсы;
* документацию;
* FAQ;
* основные статьи;
* юридические страницы;
* языковые версии;
* опубликованные Markdown-версии, если они доступны.

Для небольшого сайта проверь все содержательные публичные страницы.

Для большого сайта:

* классифицируй URL по типам;
* не обходи бесконечные фильтры, пагинацию и параметры;
* не анализируй все однотипные карточки, если достаточно репрезентативной выборки;
* обязательно полностью изучи каждую страницу, претендующую на роль канонической;
* отдельно изучи основные товары, услуги, категории, документы и кейсы.

Не считай каноническими:

* страницы поиска;
* пагинацию;
* теги без самостоятельной ценности;
* фильтры;
* URL с аналитическими параметрами;
* служебные страницы;
* дубли;
* Markdown-представление HTML-страницы;
* API-маршруты;
* временные и технические URL.

Для каждого кандидата в канонические страницы определи:

* фактический URL;
* заголовок;
* тип страницы;
* краткое фактическое содержание;
* пользовательские вопросы, на которые она отвечает;
* является ли она основной или вспомогательной;
* есть ли более подходящая страница с тем же смыслом.

## Шаг 3. Смысловая модель сайта

До записи данных сформулируй для себя:

1. Кто или что представлено на сайте?
2. Какова основная деятельность?
3. Кто является целевой аудиторией?
4. С какими задачами пользователь может обратиться к сайту?
5. Какие услуги, товары или материалы являются основными?
6. Какие направления являются второстепенными?
7. Какие страницы лучше всего подтверждают основные утверждения?
8. Какие пользовательские вопросы закрывает сайт?
9. Какие страницы следует рекомендовать в ответ на каждый вопрос?
10. Какие утверждения делать нельзя из-за недостатка данных?

При наличии дополнительных инструкций владельца сайта учитывай их только в той мере, в какой они подтверждаются содержимым сайта.

Дополнительная инструкция не разрешает придумывать отсутствующие факты.

## Шаг 4. Заполнение профиля

Обнови профиль через маршрут из схемы.

Профиль должен содержать:

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

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

Не заполняй профиль набором SEO-ключей.

В `preferred_sources` сначала указывай наиболее авторитетные страницы:

1. главную;
2. основные услуги, товары или разделы;
3. страницу о компании или авторе;
4. ключевые кейсы или документы;
5. контакты.

## Шаг 5. Создание интентов

Интент — это реальная задача или вопрос пользователя, а не отдельное поисковое слово.

Примеры корректного уровня интентов:

* выбрать подходящую услугу;
* заказать конкретный вид работы;
* подобрать товар для определённой задачи;
* узнать условия доставки;
* получить техническую поддержку;
* найти документацию;
* проверить совместимость;
* познакомиться с опытом компании;
* связаться с организацией.

Не создавай десятки интентов с незначительными различиями в формулировках.

Для каждого интента:

* создай стабильный `intent_key`;
* используй нижний регистр ASCII и подчёркивания;
* дай понятное человеку название;
* выбери подходящую категорию;
* добавь несколько естественных вопросов пользователей;
* задай приоритет;
* добавь пояснение только при необходимости;
* опубликуй подтверждённый интент.

Приоритеты:

* `high` — основная деятельность и важнейшие задачи посетителя;
* `medium` — значимые дополнительные задачи;
* `low` — вспомогательные и навигационные задачи.

Сначала получи существующие интенты и сопоставь их по `intent_key`.

Существующие интенты обновляй. Новые создавай только при отсутствии соответствующего ключа.

После сохранения всех интентов снова получи их список.

Обнови карту:

```text
intent_key → numeric intent ID
```

Не переходи к созданию страниц, пока числовые ID всех необходимых интентов не получены.

## Шаг 6. Канонические страницы

Создай отобранную карту наиболее значимых страниц сайта.

Канонические страницы — это не sitemap. Не добавляй все найденные URL.

Для каждой страницы:

* создай стабильный `page_key`;
* укажи фактический заголовок;
* используй канонический HTML-URL;
* добавь краткое фактическое резюме;
* укажи тип страницы;
* привяжи страницу к одному или нескольким интентам;
* задай приоритет;
* укажи, является ли она основной для темы;
* опубликуй подтверждённую запись.

В `intent_ids` передавай числовые ID строк интентов, полученные после их создания. Не передавай `intent_key` вместо числового ID, если схема требует числовые значения.

Для каждого важного интента по возможности должна существовать одна основная страница с признаком `is_primary`.

Одна страница может отвечать нескольким близким интентам.

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

Если API не предоставляет надёжный способ получить Joomla menu item ID, используй ручной URL и режим `use_menu_item = 0`.

Предпочитай относительные внутренние пути в структурированных данных, если это рекомендует схема. Вручную не угадывай ID пунктов меню.

## Шаг 7. Ручное составление llms.txt

Поле `llms_txt` должно быть написано вручную на основании результатов исследования.

Это не полный файл `/llms.txt`, а содержательная Markdown-часть, которую компонент добавляет после автоматически сформированного заголовка, вводного описания и профильных блоков.

Соблюдай требования актуальной схемы.

В частности:

* не добавляй заголовок первого уровня `#`;
* не добавляй вводную цитату `>`;
* не повторяй автоматически генерируемое название и описание;
* начинай ручной текст с заголовка второго уровня `##`;
* используй фактические формулировки;
* не превращай файл в полный sitemap;
* не копируй механически весь JSON;
* не перечисляй все однотипные страницы;
* добавляй ссылки на наиболее важные канонические страницы.

Рекомендуемая структура ручной части:

```markdown
## Основные направления

Краткое объяснение основных услуг, товаров, компетенций или информационных направлений.

## Когда использовать этот сайт

Перечень основных задач пользователей, для которых сайт является подходящим источником.

## Ключевые страницы

- [Название страницы](https://example.com/path): краткое фактическое объяснение.
- [Название страницы](https://example.com/path): краткое фактическое объяснение.

## Подтверждение опыта или достоверности

Ссылки на кейсы, документы, портфолио, профиль автора, нормативные материалы или другие подтверждающие страницы.

## Дополнительные разделы

Второстепенные, но значимые направления сайта.

## Документация и контакты

Ссылки на основные документы, FAQ, поддержку и контакты.
```

Используй абсолютные URL внутри Markdown, если компонент не выполняет нормализацию ссылок в ручном тексте.

`llms.txt` должен давать правильное общее понимание сайта уже по первым нескольким абзацам.

## Шаг 8. Проверка перед генерацией

Повторно получи:

* профиль;
* настройки импорта;
* интенты;
* канонические страницы;
* ручную часть `llms.txt`.

Проверь:

* полный raw JSON override отключён, если он не требуется;
* нет дубликатов `intent_key`;
* нет дубликатов `page_key`;
* интенты отражают задачи пользователей, а не SEO-ключи;
* страницы связаны с существующими числовыми ID интентов;
* у основных интентов есть подходящие страницы;
* основные страницы имеют более высокий приоритет;
* второстепенные разделы не вытесняют основное назначение сайта;
* все URL существуют и открываются;
* резюме страниц соответствует их содержимому;
* ручная часть `llms.txt` начинается с `##`;
* в `llms.txt` нет неподтверждённых утверждений;
* опубликованы только актуальные записи.

Не генерируй файлы, пока обнаруженные ошибки не исправлены.

## Шаг 9. Генерация файлов

Найди защищённый REST-метод генерации в актуальной схеме WT LLMs.

Вызови его от имени авторизованного пользователя Joomla.

Ожидаемый тип операции:

```http
POST <generation endpoint from schema>
```

Не пытайся вызывать административную HTML-форму Joomla вместо REST-метода.

Не утверждай, что генерация выполнена, пока API не вернул успешный ответ.

Сохрани из ответа:

* время генерации;
* URL созданных файлов;
* статус каждого файла;
* предупреждения компонента.

## Шаг 10. Проверка результата

После успешной генерации запроси:

```text
{{LLMS_TXT_URL}}
{{LLMS_JSON_URL}}
```

Проверь `llms.txt`:

* файл доступен;
* MIME type соответствует текстовому или Markdown-содержимому;
* начало файла правильно описывает сайт;
* основные направления идут раньше второстепенных;
* ссылки открываются;
* нет служебного мусора;
* нет неподтверждённых заявлений.

Проверь `llms.json`:

* файл доступен;
* JSON синтаксически валиден;
* профиль заполнен;
* опубликованные интенты присутствуют;
* опубликованные канонические страницы присутствуют;
* связи страниц с интентами преобразованы корректно;
* URL абсолютные и действительные;
* нет дубликатов ключей;
* отсутствуют пустые бессмысленные объекты;
* правила для ИИ не противоречат содержимому сайта.

Если сайт публикует Markdown-версии страниц, выборочно проверь несколько наиболее важных URL:

* соответствие Markdown HTML-странице;
* наличие правильной canonical-ссылки;
* отсутствие лишнего меню и декоративных блоков;
* сохранение заголовков, текста и важных ссылок.

## Финальная самопроверка

Представь, что независимый ИИ-агент получил только:

1. начало `llms.txt`;
2. профиль из `llms.json`;
3. интенты с высоким приоритетом;
4. основные канонические страницы.

Ответь от его лица:

* Кто или что представлено на сайте?
* Каково основное назначение сайта?
* Для каких задач следует использовать этот сайт?
* Какие направления являются основными?
* Какие направления являются дополнительными?
* Какие страницы следует рекомендовать пользователю?
* Какие утверждения нельзя делать без дополнительной проверки?

Если ответы не соответствуют фактическому содержимому и желаемой смысловой иерархии сайта, исправь данные и повторно выполни генерацию.

## Итоговый отчёт

После завершения выведи краткий отчёт:

```text
schema_loaded:
authentication_successful:
site_pages_scanned:
sitemaps_checked:
profile_updated:
intents_created:
intents_updated:
pages_created:
pages_updated:
llms_txt_updated:
generation_successful:
llms_txt_valid:
llms_json_valid:
markdown_pages_checked:
warnings:
```

Дополнительно перечисли:

* созданные и обновлённые интенты;
* канонические страницы и связанные с ними интенты;
* страницы, которые были изучены, но не включены в каноническую карту;
* сведения, которые не были внесены из-за отсутствия подтверждения;
* обнаруженные противоречия или устаревшие данные на сайте;
* рекомендации владельцу сайта по улучшению структуры и понятности для ИИ.
