С чего это началось

Я начал собирать mlllm.io как публичную поверхность своей работы: AI-новости, расширенные объяснения, проекты, блог и профиль, который можно использовать при подаче на open-source грант OpenAI.

Первое практическое решение было простым. У меня уже был Telegram-канал Look at AI News и пайплайн TG-NEWS за ним. Вместо того чтобы держать расширенные объяснения в Telegraph, я хотел перенести архив на сайт: одна короткая новость и одна связанная расширенная статья на каждую историю.

Так как сам проект связан с AI-инструментами, я хотел, чтобы сайт был понятен не только людям и Google, но и LLM-агентам, AI search системам и RAG-пайплайнам.

Это быстро оказалось намного шире, чем просто "добавить SEO".

Первый результат

После нескольких дней болезненной итерации у сайта появился базовый machine-readable слой, который мне был нужен:

  • статический HTML, который читается без JavaScript rendering;
  • robots.txt, sitemap.xml, news-sitemap.xml, RSS и llms.txt;
  • явные правила доступа для поисковых и AI-ботов;
  • структурированные страницы коротких новостей, longform-статей, topics, проектов, community и author profile;
  • JSON-LD schema для news, article, breadcrumbs, website, organization и author signals;
  • стабильная модель контента: одна короткая новость плюс одна расширенная статья, а не размножение похожих фрагментов.

Модельный аудит сайта заметно поднял оценку. Но важнее была не сама цифра, а путь к ней: каждое улучшение появлялось не случайно, а через задачу, проверку, обсуждение и regression test.

Так появилась следующая идея.

Почему одного SEO-skill недостаточно

Сначала казалось, что нужен один skill: "оптимизировать сайт под SEO и LLM-краулеры".

Это слишком широко.

Реальный рост сайта затрагивает сразу несколько дисциплин:

  • семантическое ядро и topic architecture;
  • URL-структуру и внутреннюю перелинковку;
  • technical SEO и schema.org;
  • robots.txt, llms.txt, RSS, sitemap и crawler access;
  • видимый UX и onboarding для новых читателей;
  • content quality gates и проверку редакторского мусора;
  • first-party analytics и мониторинг ботов;
  • внешние authority placements и backlinks;
  • regression validation по live HTML;
  • координацию задач так, чтобы не сломать publishing pipeline.

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

Поэтому я разделил работу на группу skills.

Что делает эта группировка

Публичный репозиторий называется SEO/LLM Skill Cluster.

Главная идея такая: сайт нужно проектировать сразу для трёх читателей:

  • человек, которому нужны ориентация, доверие и понятная навигация;
  • поисковый crawler, которому нужны стабильные URL, metadata, schema и crawlable HTML;
  • AI-агент, которому нужны machine-readable карта сайта, source trails, сущности и прямые ответы без угадывания.

Это не один огромный skill. Это группа более узких skills вокруг центрального оркестратора:

  • site growth orchestration;
  • semantic core design;
  • SEO information architecture;
  • internal link graph planning;
  • technical SEO and schema engineering;
  • LLM-friendly site architecture;
  • LLM citation monitoring;
  • server log and crawler analysis;
  • external authority placement scouting;
  • backlink quality validation;
  • UX journey architecture;
  • SEO regression validation.

У каждого skill есть ограниченная зона ответственности. Оркестратор задаёт последовательность, держит task plan актуальным и не даёт работе распасться на разрозненные советы.

Правило, которое нельзя было сломать

Самое важное правило пришло из модели сайта:

У одной истории есть одна короткая новость и одна расширенная статья.

Это звучит очевидно, но SEO и LLM-оптимизация легко толкают проект в неправильную сторону. Очень хочется создать дополнительные summaries, FAQ-фрагменты, topic-варианты, agent pages, Markdown-зеркала и переписанные версии для каждой поверхности.

Выглядит как "больше контента", но на практике может стать дублированием.

Для mlllm.io правильная модель другая:

  • brief остаётся настоящей короткой новостью;
  • longform остаётся настоящей расширенной статьёй;
  • topic pages объясняют широкие темы;
  • project pages показывают системы за сайтом;
  • blog хранит личные мысли и заметки о сборке;
  • llms.txt и schema описывают сайт, но не размножают саму историю.

LLM-friendly архитектура должна усиливать контентную модель, а не создавать неконтролируемые копии.

Почему task plan оказался не менее важен

Вторым важным инструментом стал task-plan-v2-dashboard.

Длинная агентская работа ломается, когда всё живёт только в чате. Постоянно приходится спрашивать: "что сделано?", "что дальше?", "что изменилось?", "оно не сломало сайт?".

Task plan превращает работу в видимые единицы:

  • задачи с ID и статусами;
  • implementation gates;
  • validation steps;
  • заметки о рисках и регрессиях;
  • коммиты, связанные с выполненными задачами.

Это меняет и человеческий workflow. Не нужно непрерывно смотреть на модель и каждые пять минут вытягивать из неё статус. Dashboard даёт достаточно структуры, чтобы отойти, заварить кофе и вернуться к понятному состоянию работы.

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

Что опубликовано

В репозитории лежит структура кластера, task plan, validation scripts, example artifacts и документация о том, как skills должны работать вместе.

Это не "магический промпт". Скорее это операционная модель:

  • спроектировать архитектуру сайта;
  • сделать контент machine-readable;
  • проверить live HTML;
  • мониторить crawler и LLM visibility;
  • улучшать UX, не ломая SEO;
  • фиксировать работу так, чтобы её можно было повторить.

Проект вырос из реального кейса, а не из теоретического checklist. Этим кейсом стал mlllm.io: многоязычный AI news and builder site, который получает контент из TG-NEWS, публикует короткие новости, longform explainers, source trails, project pages и публичные audit checks.

Что дальше

Следующий слой - практическая проверка на большем количестве сайтов.

Я хочу, чтобы cluster поддерживал не только задачу "сделать страницу лучше", а весь цикл:

  1. собрать semantic core;
  2. спроектировать структуру сайта и перелинковку;
  3. опубликовать crawlable pages;
  4. добавить schema, llms.txt, feeds и metadata;
  5. мониторить search и AI crawler access;
  6. проверять, цитируют ли сайт LLM-системы;
  7. находить легитимные external placements;
  8. возвращать результаты обратно в task plan.

В этом и смысл группировки skills. Серьёзный сайт не оптимизируется одной инструкцией. Он улучшается системой согласованных решений, проверок и feedback loops.

Сайт был тестовым кейсом. Skill cluster - попытка сделать метод переиспользуемым.