DeepSeek Harness (dsh) uruchamia agentów, którzy wykonują realną pracę — a niewiele zadań SEO pasuje lepiej niż pipeline nieindeksowanych URL: odczytaj listę, sprawdź każdy URL, sklasyfikuj, poczekaj na zatwierdzenie, wyślij, zweryfikuj. Każdy etap to polecenie lub plik — dokładnie terytorium, na którym żyją agenci harnessu.
Dwa pytania determinują Twoją konfigurację. Potrzebujesz jednorazowej partii, którą można zeskryptować i wstawić do crona? Wybierz headless. Chcesz widzieć, jak wszystko działa, odpowiadać na pytania agenta i zatwierdzać partię po partii w czacie? Użyj Web UI. Ten przewodnik pokazuje obie ścieżki; leżący u podstaw pipeline jest identyczny. Głębokie wyjaśnienie dwóch statusów (w tym tego, dlaczego Google przeszukuje jedne strony, a inne nie) znajdziesz w wersji tego procesu dla agenta Hermes. Tutaj skupiamy się na wykonaniu przez dsh.
Wybór ścieżki
Jednorazowa partia headless | Web UI + harmonogram | |
|---|---|---|
Idealne do | Zeskryptowane partie, cron, uruchomienia w stylu CI, testy | Interaktywny triaż, pierwsza konfiguracja, poznawanie decyzji agenta |
Start |
|
|
Zatwierdzanie | Lista wstępnie zatwierdzona w pliku; jeśli reguły wymagają człowieka, agent pyta swoim narzędziem pytań | Pyta na żywo w czacie, zatwierdzasz partia po partii |
Harmonogram | cron (lub narzędzie harmonogramu dsh, jeśli Twój profil ładuje wtyczkę Schedule) | To samo, ale każde uruchomienie jest widoczne |
Wynik | Pliki raportów w folderze projektu | Pliki raportów plus transkrypt czatu |
Partie — headless, pierwsza konfiguracja — Web UI. Pipeline poniżej jest identyczny.
Obie ścieżki dzielą jedną zasadę: etap zapisu (wysyłka do Google) pozostaje za bramą ludzkiego zatwierdzenia. W trybie headless oznacza to, że przeglądasz pliki utworzone przez agenta, zanim pozwolisz mu wykonać polecenia wysyłki. W trybie web zatwierdzasz w czacie.
Co otrzymujesz
Folder projektu indexing/ ze: spisem URL, sklasyfikowanymi listami (to-submit.txt, skip.txt, needs-fix.txt), zatwierdzoną kolejką wysyłki i dziennikami uruchomień. Przy każdym uruchomieniu dsh wydaje krótki raport: ile wysłano, ile pominięto i dlaczego, co się zmieniło od poprzedniego razu. Pierwsza konfiguracja 60–90 minut (głównie dane uwierzytelniające Google), cotygodniowe uruchomienie 15 minut.
Przed rozpoczęciem
- dsh zainstalowany i skonfigurowany. Zaktualizuj przez
npx @deepseek-ai/dsh@latest web, jeśli trzeba. Twój klucz API i ustawienia w~/.dsh/(profiles, sessions,settings.yaml);dsh websię uruchamia lub zadanie headless kończy się sukcesem = instalacja potwierdzona. - Właściwość GSC, której jesteś właścicielem, w formacie
sc-domain:example.com. - Dane do odczytu: klient OAuth dla Search Console API (client ID + secret).
- Dane do zapisu: projekt Google Cloud z włączonym Indexing API, klucz JSON konta usługi, a e-mail konta usługi dodany jako właściciel w GSC → Ustawienia → Użytkownicy i uprawnienia. 403 przy wysyłce = ten krok nieudany.
- Dwa foldery skryptów GSC w workspace: skill odczytu (sitemap, Search Analytics, sprawdzanie URL) i skill indeksacji (
index_submit.py). Python 3 ipip install google-auth google-api-python-client. - Folder projektu, np.
~/gsc-indexing-projectzdata/,scripts/,logs/.
Część Google jest identyczna dla każdego agenta; dokumentacja skilla gsc-indexing przeprowadzi Cię przez konsolę Cloud: włącz Indexing API, utwórz konto usługi, pobierz klucz, dodaj je jako właściciela.
Ścieżka A: partia headless
Tryb headless to dsh --profile headless "zadanie": jedno zadanie, jedna odpowiedź, koniec. Umieszczasz cały pipeline w jednym prompcie albo dzielisz na kilka uruchomień podczas debugowania.
Pierwsze uruchomienie (z folderu projektu):
dsh --profile headless "Wykonaj etap 1 pipeline'u indeksacji GSC. Skryptem gsc_query.py wypisz sitemap dla sc-domain:example.com, pobierz wszystkie URL z lastmod, zdeduplikuj i zapisz do data/url-inventory.csv. Podaj podsumowanie."Dobry wynik: prawdziwy CSV z podsumowaniem zgodnym z raportem sitemap w GSC i bez wymyślonych kolumn. Kontrola jakości: otwórz plik i sprawdź pięć losowych URL. Jeśli agent zgłasza błąd uwierzytelniania, powtórz przepływ OAuth GSC i spróbuj ponownie; skrypt odczytu potrzebuje świeżego tokena.
Etap 2:
dsh --profile headless "Sprawdź URL z data/url-inventory.csv przez URL Inspection API i podziel na data/to-submit.txt, data/skip.txt (z powodem w każdym wierszu) i data/needs-fix.txt. Uwzględnij tylko URL z lastmod z ostatnich 90 dni."Agent wykonuje skrypty sprawdzania partiami (API ma limity częstotliwości na właściwość; aktualny limit w Google Cloud Console). Sprawdź podział: w liście pominiętych powinny dominować noindex, odrzucenia canonical i duplikaty. Jeśli needs-fix jest pusty na stronie z tysiącami URL, rozszerz okno wejściowe.
Etap 3 — brama zatwierdzenia, nigdy bez nadzoru:
dsh --profile headless "Przeczytaj data/needs-fix.txt i data/skip.txt. Przygotuj kolejkę poprawek i wysyłek w formie tabeli: URL, prawdopodobna przyczyna (brak linków wewnętrznych, duplikat, canonical, noindex, słaba treść, soft 404), dowód, proponowane działanie, poziom ryzyka. Nic nie wysyłaj."Przejrzyj tabelę w raporcie, przytnij data/to-submit.txt do URL, które zatwierdzasz, i wykonaj etap 4:
dsh --profile headless "Wyślij URL z data/approved-urls.txt skryptem indeksacji (index_submit.py submit --urls-file data/approved-urls.txt). Najpierw wykonaj check-auth. Zapisz każdy wynik w logs/submissions.log."Oczekiwany wynik: wiersz wyniku powiadomienia dla każdego URL, bez 403. Odzyskiwanie: 403 oznacza, że konto usługi nie jest właścicielem właściwości; 429 — trafiłeś w limit 200/dzień lub 600/minutę — rozłóż listę na dni. Jeśli uruchomienie umarło w połowie, wznowij przez dsh --profile headless --resume <session>.
Ścieżka B: Web UI i cotygodniowy harmonogram
dsh web otwiera interfejs przeglądarkowy na 127.0.0.1:3080. Te same etapy, ale przez czat i interaktywnie: agent prosi o potwierdzenie list klasyfikacji i jeszcze raz przed każdym poleceniem wysyłki. Ten przepływ zatwierdzania na żywo to główny powód, by wybrać tę ścieżkę przy pierwszej konfiguracji: widzisz, co agent zamierza zrobić z Twoją właściwością Google, zanim to zrobi.
Gdy pipeline jest dopracowany, dodaj rytm. Wtyczka Schedule w dsh rejestruje schedule_create i powtarza zadania według timera w żywej sesji:
schedule_create: every 7 days, run "Inspect data/url-inventory.csv, classify new and changed URLs, and draft the submission queue. Do not submit."
Jeśli Twój profil nie ładuje wtyczki Schedule, wiersz crona wokół polecenia headless daje ten sam efekt:
0 9 * * 1 cd ~/gsc-indexing-project && dsh --profile headless "Wykonaj cotygodniowy przegląd indeksacji GSC i przygotuj kolejkę wysyłki." >> logs/weekly.log 2>&1
Harmonogram puszcza pierwsze trzy stacje; wysyłka pozostaje za ludzką bramą.
Nie umieszczaj etapu wysyłki w harmonogramie. Cotygodniowy przegląd, klasyfikacja i przygotowanie kolejki mogą działać bez nadzoru; wysyłka czeka na człowieka.
Zasady triażu, których używa agent
Klasyfikacja i kolejka opierają się na małej tabeli. Umieść ją w folderze projektu, aby każde uruchomienie używało tych samych reguł:
Przyczyna | Naprawa | Wysyłać po naprawie? |
|---|---|---|
Brak linków wewnętrznych | Dodać kontekstowe linki ze zindeksowanych stron | Tak |
Całkiem nowa strona | Nie ma czego naprawiać; wysłać raz i czekać 1–2 tygodnie | Tak, raz |
Blokada w robots.txt | Usunąć blokadę ścieżki | Tak |
Zduplikowana lub słaba treść | Przepisać, połączyć lub usunąć | Tylko po realnej zmianie |
canonical wskazuje gdzie indziej | Poprawić, jeśli błąd; celowo — zostawić URL | Tylko po naprawie |
noindex w momencie crawl'u | Usunąć noindex | Tak, po usunięciu |
Soft 404, archiwa, bezużyteczne facety | Naprawić lub usunąć; stałe pominięcie | Nie |
Głębsze czytanie dwóch statusów (w tym tego, dlaczego Google przeszukuje jedne strony, a inne nie) znajdziesz w przewodniku agenta Hermes. Przyczyny są takie same niezależnie od tego, który harness wykonuje pipeline.
Weryfikacja, potem cierpliwość
Po każdej partii sprawdź powiadomienie przez status: dowodzi to jedynie, że Google ma metadane URL, a nie że strona jest zindeksowana. Ponownie sprawdź wysłane URL po 3–7 dniach i porównaj statusy. Zdrowy wzorzec to discovered → crawled → indexed w ciągu 1–2 tygodni. Dane GSC przychodzą z kilkudniowym opóźnieniem, a Google ponownie przeszukuje według własnego harmonogramu — URL pozostający w „Crawled – currently not indexed" przez 10–14 dni po realnych poprawkach to werdykt o jakości treści, a nie problem z wysyłką. Plik dziennika czyni to widocznym: data, URL, typ powiadomienia, status sprawdzenia przy następnym uruchomieniu. Oto metryka: kurcząca się lista nieindeksowanych, a nie liczba powiadomień.
Uczciwe ograniczenia
- Indexing API jest oficjalnie dokumentowane dla stron
JobPostingiBroadcastEvent. Wysyłka zwykłych stron to powszechna praktyka, ale Google nie daje gwarancji i nie obiecuje wsparcia dla żadnego typu stron. - Przycisk „Poproś o zindeksowanie" w Search Console nie ma publicznego API. Indexing API to najbliższy skryptowalny kanał, ale nie klon przycisku.
- Automatyzacja nie tworzy priorytetu. Jeśli strona nadal nie jest indeksowana po naprawie i wysyłce, następny krok to praca nad treścią, a nie kolejne zaplanowane uruchomienie.
Często zadawane pytania
Czy mogę pracować tylko w headless, bez Web UI? Tak. dsh --profile headless "zadanie" wykonuje zadanie i kończy. Dane uwierzytelniające pozostają w ~/.dsh/, a skrypty odczytu działają tak samo. Przejdź pipeline od początku do końca raz w Web UI, zanim zaczniesz skryptować.
Jeśli uruchomienie umarło, tracę pracę? Nie. Wznów przez dsh --profile headless --resume <session> i ponownie uruchom skrypt wysyłki; deduplikuje on URL, więc ponowne wysłanie już zawiadomionych URL z tej samej partii jest bezpieczne.
Zarządzam wieloma właściwościami GSC. Czy muszę wszystko przerabiać dla każdej strony? Skrypty przyjmują argument --site sc-domain:..., więc jeden workspace może zawierać spisy i dzienniki wielu właściwości. Trzymaj plik zatwierdzonej kolejki i polecenie wysyłki dla każdej właściwości; błąd limitu na jednej stronie nie blokuje pozostałych.
Autorka: Camille Rhodes, architektka ponad 300 przepływów pracy z AI w Auspia. Pisze o automatyzacji treści, systemach publikacji i procesach, które zamieniają agentów AI w niezawodne operacje wzrostu.
