DeepSeek Harness (dsh) запускает агентов, которые делают реальную работу — и мало какая SEO-задача подходит лучше, чем пайплайн неиндексированных URL: прочитать список, проверить каждый URL, классифицировать, дождаться утверждения, отправить, верифицировать. Каждый этап — команда или файл, ровно та территория, где живут харнесс-агенты.
Два вопроса определяют вашу конфигурацию. Нужна разовая партия, которую можно скриптовать и поставить в cron? Идите в headless. Хотите видеть, как всё работает, отвечать на вопросы агента и утверждать партию за партией в чате? Используйте Web UI. Этот гайд показывает оба пути; лежащий в основе пайплайн одинаков для обоих. Глубокое объяснение двух статусов (включая то, почему Google обходит одни страницы и не обходит другие) подробно разобрано в версии Hermes Agent этого процесса. Здесь мы фокусируемся на исполнении через dsh.
Выбор пути
Разовая партия headless | Web UI + расписание | |
|---|---|---|
Идеально для | Скриптованные партии, cron, запуски в стиле CI, тесты | Интерактивный триаж, первый сетап, изучение суждений агента |
Старт |
|
|
Утверждение | Предварительно утверждённый список в файле; если правила требуют человека, агент спрашивает своим инструментом вопросов | Спрашивает в чате в реальном времени, утверждаете партию за партией |
Расписание | cron (или инструмент расписания dsh, если ваш профиль загружает плагин Schedule) | То же, но каждый запуск виден |
Вывод | Файлы отчётов в папке проекта | Файлы отчётов плюс транскрипт чата |
Партии — headless, первый сетап — Web UI. Пайплайн ниже одинаков.
Оба пути разделяют одно правило: этап записи (отправка в Google) остаётся за шлюзом человеческого утверждения. В headless-режиме это значит, что вы просматриваете файлы, созданные агентом, прежде чем позволить ему выполнить команды отправки. В web-режиме вы утверждаете в чате.
Что вы получаете
Папку проекта indexing/ с: инвентарём URL, классифицированными списками (to-submit.txt, skip.txt, needs-fix.txt), утверждённой очередью отправки и журналами запусков. На каждом запуске dsh выдаёт краткий отчёт: сколько отправлено, сколько пропущено и почему, что изменилось с прошлого раза. Первый сетап 60–90 минут (в основном учётные данные Google), еженедельный запуск 15 минут.
Перед началом
- dsh установлен и настроен. Обновите через
npx @deepseek-ai/dsh@latest web, если нужно. Ваш API-ключ и настройки в~/.dsh/(profiles, sessions,settings.yaml);dsh webзапускается или headless-задача успешна = установка подтверждена. - Свойство GSC, владельцем которого вы являетесь, в формате
sc-domain:example.com. - Учётные данные для чтения: OAuth-клиент для Search Console API (client ID + секрет).
- Учётные данные для записи: проект Google Cloud с включённой Indexing API, JSON-ключ сервисного аккаунта, и e-mail сервисного аккаунта, добавленный как владелец в GSC → Настройки → Пользователи и права. 403 при отправке = этот шаг провален.
- Две папки скриптов GSC в workspace: скилл чтения (sitemap, Search Analytics, проверка URL) и скилл индексации (
index_submit.py). Python 3 иpip install google-auth google-api-python-client. - Папка проекта, например
~/gsc-indexing-projectсdata/,scripts/,logs/.
Google-часть сетапа идентична для любого агента; документация скилла gsc-indexing проведёт вас по консоли Cloud: включить Indexing API, создать сервисный аккаунт, скачать ключ, добавить его владельцем.
Путь A: headless-запуск партии
Headless-режим — это dsh --profile headless "задача": одна задача, один ответ, конец. Вы кладёте весь пайплайн в один промпт или разбиваете на несколько запусков, пока отлаживаете.
Первый запуск (из папки проекта):
dsh --profile headless "Выполни этап 1 пайплайна индексации GSC. Скриптом gsc_query.py перечисли sitemap для sc-domain:example.com, извлеки все URL с lastmod, дедуплицируй и запиши в data/url-inventory.csv. Сообщи итог."Хороший результат: настоящий CSV с итогом, согласующимся с отчётом sitemap в GSC, и без выдуманных колонок. Контроль качества: откройте файл и проверьте пять случайных URL. Если агент сообщает об ошибке аутентификации, повторите OAuth-поток GSC и попробуйте снова; скрипту чтения нужен свежий токен.
Этап 2:
dsh --profile headless "Проверь URL из data/url-inventory.csv через URL Inspection API и раздели на data/to-submit.txt, data/skip.txt (с причиной в каждой строке) и data/needs-fix.txt. Включи только URL с lastmod за последние 90 дней."Агент выполняет скрипты проверки партиями (у API есть лимиты частоты на свойство; актуальная квота в Google Cloud Console). Проверьте разделение: в списке пропущенных должны доминировать noindex, отклонения canonical и дубликаты. Если needs-fix пуст на сайте с тысячами URL, расширьте входное окно.
Этап 3 — шлюз утверждения, никогда не выполняется без надзора:
dsh --profile headless "Прочитай data/needs-fix.txt и data/skip.txt. Подготовь очередь исправлений и отправок таблицей: URL, предполагаемая причина (нет внутренних ссылок, дубликат, canonical, noindex, слабый, soft 404), доказательство, предлагаемое действие, уровень риска. Ничего не отправляй."Просмотрите таблицу в отчёте, сократите data/to-submit.txt до URL, которые вы утверждаете, и выполните этап 4:
dsh --profile headless "Отправь URL из data/approved-urls.txt скриптом индексации (index_submit.py submit --urls-file data/approved-urls.txt). Сначала выполни check-auth. Запиши каждый результат в logs/submissions.log."Ожидаемый вывод: строка результата уведомления на каждый URL, без 403. Восстановление: 403 означает, что сервисный аккаунт не владелец свойства; 429 — вы упёрлись в квоту 200/день или 600/минуту — разнесите список по дням. Если запуск умер на середине, возобновите через dsh --profile headless --resume <session>.
Путь B: Web UI и еженедельное расписание
dsh web открывает браузерный интерфейс на 127.0.0.1:3080. Те же этапы, но через чат и интерактивно: агент просит подтвердить классификационные списки и ещё раз перед каждой командой отправки. Этот поток утверждения в реальном времени — главная причина выбрать этот путь на первом сетапе: вы видите, что агент собирается сделать с вашим Google-свойством, до того как он это сделает.
Когда пайплайн налажен, добавьте ритм. Плагин Schedule в dsh регистрирует schedule_create и повторяет задачи по таймеру внутри живой сессии:
schedule_create: every 7 days, run "Inspect data/url-inventory.csv, classify new and changed URLs, and draft the submission queue. Do not submit."
Если ваш профиль не загружает плагин Schedule, строка cron вокруг headless-команды даёт тот же результат:
0 9 * * 1 cd ~/gsc-indexing-project && dsh --profile headless "Выполни еженедельный обзор индексации GSC и подготовь очередь отправки." >> logs/weekly.log 2>&1
Расписание гоняет первые три станции; отправка остаётся за человеческим шлюзом.
Не кладите этап отправки в расписание. Еженедельный обзор, классификация и подготовка очереди могут идти без надзора; отправка ждёт человека.
Правила триажа, которые применяет агент
Классификация и очередь опираются на небольшую таблицу. Положите её в папку проекта, чтобы каждый запуск использовал одни и те же правила:
Причина | Исправление | Отправлять после исправления? |
|---|---|---|
Нет внутренних ссылок | Добавить контекстные ссылки с индексированных страниц | Да |
Совершенно новая страница | Исправлять нечего; отправить один раз и ждать 1–2 недели | Да, один раз |
Блокировка robots.txt | Снять блокировку пути | Да |
Дублированный или слабый контент | Переписать, объединить или удалить | Только после реального изменения |
canonical указывает в другую сторону | Исправить, если ошибка; намеренно — оставить URL | Только после исправления |
noindex на момент обхода | Убрать noindex | Да, после удаления |
Soft 404, архивы, бесполезные facets | Исправить или удалить; постоянный пропуск | Нет |
Глубокое чтение двух статусов (включая то, почему Google обходит одни страницы и не обходит другие) — в гайде Hermes Agent. Причины одни и те же, независимо от того, какой харнесс исполняет пайплайн.
Верификация, затем ожидание
После каждой партии проверьте уведомление через status: это доказывает лишь наличие метаданных URL у Google, а не индексацию страницы. Перепроверьте отправленные URL через 3–7 дней и сравните статусы. Здоровая схема — discovered → crawled → indexed за 1–2 недели. Данные GSC приходят с задержкой в несколько дней, и Google переобходит по своему расписанию — URL, остающийся в «Crawled – currently not indexed» 10–14 дней после реальных исправлений, это вердикт о качестве контента, а не проблема отправки. Файл журнала делает это видимым: дата, URL, тип уведомления, статус проверки на следующем запуске. Вот метрика: список неиндексированных, сжимающийся со временем, а не количество уведомлений.
Честные ограничения
- Indexing API официально документирована для страниц
JobPostingиBroadcastEvent. Отправка обычных страниц — распространённая практика, но Google не даёт гарантий и не обещает поддержку для типа страниц. - Кнопка «Запросить индексацию» в Search Console не имеет публичного API. Indexing API — ближайший скриптуемый канал, но не клон кнопки.
- Автоматизация не создаёт приоритет. Если страница так и не индексируется после исправления и отправки, следующий шаг — работа над контентом, а не очередной запланированный запуск.
Частые вопросы
Можно ли работать только в headless, без Web UI? Да. dsh --profile headless "задача" выполняет задачу и завершается. Учётные данные остаются в ~/.dsh/, и скрипты чтения работают так же. Проверьте пайплайн от начала до конца один раз в Web UI, прежде чем скриптовать.
Если запуск умер, я теряю работу? Нет. Возобновите через dsh --profile headless --resume <session> и снова выполните скрипт отправки; он дедуплицирует URL, так что повторная отправка уже уведомлённых URL из той же партии безвредна.
Я управляю несколькими свойствами GSC. Придётся всё переделывать для каждого сайта? Скрипты принимают аргумент --site sc-domain:..., поэтому один workspace может содержать инвентари и журналы нескольких свойств. Держите файл утверждённой очереди и команду отправки на каждое свойство; ошибка квоты на одном сайте не блокирует остальные.
Авторка: Камилла Родс, архитектор более 300 ИИ-контентных воркфлоу в Auspia. Пишет об автоматизации контента, системах публикации и процессах, превращающих ИИ-агентов в надёжные операции роста.
