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. Пише про автоматизацію контенту, системи публікації та процеси, що перетворюють ШІ-агентів на надійні операції зростання.
