Parsed: SEO-инструмент, который пишет прямо в кодовую базу

Большинство SEO-инструментов заканчиваются отчётом. Parsed начинает с него.

Получаешь список отсутствующих схем, пробелов в ключевых словах, неиндексированных URL. Потом закрываешь вкладку и забываешь. Работа не сделана — тебе просто сказали, что это за работа.

Я построил Parsed, чтобы пропустить этот шаг.

Проблема с SEO-инструментами

Каждый аудиторный инструмент, которым я пользовался, имеет одну форму: сканирует твой сайт, показывает, что не так, и оставляет тебя самому это исправлять. Это имело смысл, когда работа была ручной. Меньше смысла, когда агенты существуют.

Разрыв — не в информации. Я знаю, что мне нужна JSON-LD схема на страницах продукта. Знаю, что у меня есть пробелы в ключевых словах в блоге. Знаю, что половина моего sitemap ещё не проиндексирована. Я знаю это уже месяцами. Ограничение — в исполнении: сесть и сделать каждую вещь.

Parsed рассматривает это как настоящую проблему для решения.

Что делает Parsed

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

Три основных агента:

Агент автономной оптимизации — сканирует страницы, выявляет отсутствующие или слабые структурированные данные, генерирует JSON-LD схема-компоненты и пишет их прямо в проект. На следующем деплое схема живая. Никакого копипаста.

Агент публикации — находит пробелы в ключевых словах в контенте, генерирует SEO-статьи, прогоняет их через проверку human-score и пишет .md-файлы в папку с контентом. Статья существует на диске. Ты её проверяешь, коммитишь, готово.

Агент быстрой индексации — забирает твой sitemap, отправляет каждый URL в IndexNow. Google, Bing и Yandex получают пинг немедленно. Никакого ожидания, пока краулер откроет страницу, которую ты опубликовал три недели назад.

Есть также отслеживание цитирований — мониторинг того, как часто твой сайт цитируется AI-поисковиками. Реальные API-вызовы, не мок-данные.

Стек: Next.js 14, Zustand, OpenRouter с маршрутизацией между GPT-4o и Claude 3.5 Sonnet в зависимости от задачи, и IndexNow для слоя отправки.

AEO: то, что большинство SEO-инструментов игнорируют

Google — уже не единственная поисковая система, которая имеет значение.

ChatGPT, Perplexity и Claude перетягивают значительный трафик — и они цитируют источники. Когда кто-то спрашивает Perplexity «какой лучший инструмент для X», он выдаёт несколько сайтов с инлайн-цитированиями. Эти цитирования генерируют реальные клики.

Логика оптимизации отличается от традиционного SEO. Google ранжирует страницы по ссылкам, авторитету, техническим сигналам. AI-движки цитируют по ясности контента, богатству схемы, тематическому авторитету и тому, насколько хорошо твой контент отвечает на конкретный вопрос напрямую.

Parsed отслеживает оба. Работа со схемой кормит Google. Работа с контентом кормит AI-цитирования. Они пересекаются, но не идентичны, и относиться к ним одинаково — значит упускать охват.

Я начал думать об этом как об AEO — answer engine optimization. Это не ребрендинг SEO, это дополнительный слой. Твой контент должен ранжироваться в традиционном поиске и быть цитируемым AI. Это связанные, но разные цели.

Цикл гуманизации

Вот неудобная часть.

Я генерирую статьи с помощью AI, потом прогоняю через AI-детектор, потом переписываю помеченные секции, пока human score не достигает 87% или выше, потом записываю файл на диск.

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

Работает. Статьи проходят. У Google нет надёжного детектора на уровне контента — он смотрит на сигналы вроде ссылок, авторитета, поведения пользователей. Но я предпочитаю выпускать контент, который читается как написанный человеком, независимо от того, важен ли детектор. Это просто лучше как текст.

Цикл гуманизации — часть pipeline агента публикации. Это не опционально. Каждая статья, выходящая из Parsed, прошла через него.

Текущее ограничение

Parsed работает локально.

Есть прямой доступ к файловой системе, потому что нужно писать в проект. Именно это делает его полезным и что делает сложным для продуктизации. Хостинговая версия потребовала бы интеграции с репозиторием — GitHub App, права на запись, PR-воркфлоу. Это настоящий продукт, не сайд-проект.

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

Путь к SaaS — GitHub-интеграция, которая создаёт ветку, пишет файлы, открывает PR для ревью. Получаешь автономное исполнение без предоставления стороннему инструменту прямого доступа на запись в main. Это правильная архитектура. Я её ещё не построил.

Что дальше

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

Среднесрочно: GitHub-интеграция. Parsed как сервис, который работает по расписанию, открывает PR и позволяет одобрять работу, не трогая локальное окружение.

Долгосрочно: не уверен. SEO-инструменты — переполненное пространство. Но «пишет в кодовую базу» — это другая категория, чем «показывает отчёт». Ценность в разрыве исполнения, и этот разрыв реален.

Инструмент существует. Работает. Произвёл измеримый результат. Этого достаточно, чтобы продолжать строить.