DeepSeek Harness(dsh)는 실제 작업을 할 수 있는 에이전트를 실행합니다. 그리고 미인덱스 URL 파이프라인만큼 여기에 어울리는 SEO 작업은 거의 없습니다: 목록을 읽고, 각 URL을 검사하고, 분류하고, 승인을 기다리고, 제출하고, 검증합니다. 모든 단계가 명령이거나 파일이며, 바로 하니스 에이전트가 잘하는 것입니다.
설정을 좌우하는 질문은 두 가지입니다. 스크립트화해서 cron에 넣을 수 있는 원샷 배치를 원하면 헤드리스로 실행합니다. 작동하는 모습을 보면서 질문에 답하고 배치마다 채팅에서 승인하고 싶으면 Web UI를 사용합니다. 이 가이드는 두 경로를 모두 보여줍니다. 그 아래의 파이프라인은 어느 쪽이든 같습니다. 두 상태의 깊이 있는 설명(Google이 왜 어떤 페이지는 크롤하고 다른 페이지는 크롤하지 않는지 포함)은 이 워크플로의 Hermes Agent 버전에서 다뤘습니다. 여기서는 dsh 실행에 집중합니다.
경로 선택
헤드리스 원샷 | Web UI + 스케줄 | |
|---|---|---|
적합한 용도 | 스크립트화 배치, cron, CI 방식 실행, 테스트 | 대화형 트리아지, 첫 설정, 에이전트의 판단 배우기 |
시작 |
|
|
승인 | 파일의 사전 승인 목록. 규칙에 사람이 필요하면 에이전트가 질문 도구로 물어봄 | 채팅에서 인라인으로 질문하고 배치마다 승인 |
스케줄링 | cron(또는 프로필이 Schedule 플러그인을 로드하면 dsh의 스케줄 도구) | 동일하지만 매 실행이 보임 |
출력 | 프로젝트 폴더의 보고서 파일 | 보고서 파일 + 채팅 기록 |
배치에는 헤드리스, 첫 실행에는 Web UI. 아래 파이프라인은 동일합니다.
두 경로 모두 한 가지 규칙을 공유합니다: 쓰기 단계(Google에 제출)는 인간 승인 게이트 뒤에 남습니다. 헤드리스 모드에서는 에이전트가 만든 파일을 검토한 뒤 submit 명령을 실행하게 하는 방식입니다. 웹 모드에서는 채팅에서 승인합니다.
마치면 갖게 되는 것
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이 작동하거나 헤드리스 작업이 성공하면 설치 확인이 됩니다. - 소유한 GSC 속성.
sc-domain:example.com형식. - 읽기 자격 증명: Search Console API용 OAuth 클라이언트(클라이언트 ID + 시크릿).
- 쓰기 자격 증명: Indexing API가 활성화된 Google Cloud 프로젝트, 서비스 계정 JSON 키, 그리고 서비스 계정 이메일을 GSC → 설정 → 사용자 및 권한에서 소유자로 추가. 제출 시 403이면 이 단계가 실패한 것입니다.
- 워크스페이스의 GSC 스크립트 폴더 두 개: 읽기 스킬(사이트맵, 검색 분석, URL 검사)과 인덱싱 스킬(
index_submit.py). Python 3와pip install google-auth google-api-python-client. - 프로젝트 폴더. 예:
~/gsc-indexing-project에data/,scripts/,logs/.
Google 쪽 설정은 어떤 에이전트든 동일하며, gsc-indexing 스킬 문서가 Cloud Console 절차를 안내합니다: Indexing API 활성화, 서비스 계정 생성, 키 다운로드, 소유자로 추가.
경로 A: 원샷 헤드리스 실행
헤드리스 모드는 dsh --profile headless "작업": 작업 하나, 답 하나, 종료. 전체 파이프라인을 한 프롬프트에 담거나, 디버깅하면서 몇 번의 실행으로 나눕니다.
첫 실행(프로젝트 폴더에서):
dsh --profile headless "GSC 인덱싱 파이프라인의 1단계를 실행하세요. gsc_query.py 스크립트로 sc-domain:example.com의 사이트맵을 나열하고 lastmod가 있는 모든 URL을 가져와 중복을 제거한 뒤 data/url-inventory.csv로 작성하세요. 총수를 보고하세요."좋은 출력의 기준: 실제 CSV에 GSC 사이트맵 보고서와 일치하는 개수가 있고, 지어낸 열이 없을 것. 품질 확인: 파일을 열고 URL 5개를 스팟 체크합니다. 에이전트가 인증 오류를 보고하면 GSC OAuth 흐름을 다시 실행하고 재시도하세요. 읽기 스크립트에는 새 토큰이 필요합니다.
2단계:
dsh --profile headless "data/url-inventory.csv의 URL을 URL Inspection API로 검사하고 data/to-submit.txt, data/skip.txt(한 줄 이유 포함), data/needs-fix.txt로 나누세요. lastmod가 최근 90일 이내인 URL만 포함하세요."에이전트는 검사 스크립트를 배치로 실행합니다(API는 속성별 속도 제한이 있으며 현재 할당량은 Google Cloud Console에서 확인). 분할 결과를 확인하세요: 건너뛴 목록은 noindex, canonical 이탈, 중복 페이지가 지배적이어야 합니다. 수천 개 URL 사이트에서 needs-fix가 비어 있으면 입력 창을 넓히세요.
3단계는 승인 게이트이며 절대 무인 실행하지 않습니다:
dsh --profile headless "data/needs-fix.txt와 data/skip.txt를 읽으세요. 수정·제출 큐를 표로 드래프트하세요: URL, 추정 원인(내부 링크 없음, 중복, canonical, noindex, 얇음, 소프트 404), 증거, 제안 조치, 위험 수준. 아무것도 제출하지 마세요."보고서에 표시된 표를 검토하고 data/to-submit.txt를 승인한 URL만 남도록 편집한 뒤 4단계를 실행합니다:
dsh --profile headless "data/approved-urls.txt의 URL을 인덱싱 스크립트로 제출하세요(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은 브라우저 UI를 127.0.0.1:3080에 엽니다. 같은 단계를 채팅으로, 단 대화형으로 진행합니다: 에이전트가 분류 목록 확인을 요청하고 submit 명령을 실행하기 전에 다시 확인합니다. 이 라이브 승인 흐름이 첫 설정에서 이 경로를 고르는 주된 이유입니다. 여러분의 Google 속성에 에이전트가 무엇을 하려는지, 실행 전에 보이기 때문입니다.
파이프라인이 작동하면 주기를 추가합니다. dsh의 Schedule 플러그인은 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 한 줄로 같은 결과를 얻습니다. 헤드리스 명령을 감싸는 방식입니다:
0 9 * * 1 cd ~/gsc-indexing-project && dsh --profile headless "주간 GSC 인덱싱 검사를 실행하고 제출 큐를 드래프트하세요." >> logs/weekly.log 2>&1
스케줄은 처음 세 정거장을 돌리고, 제출은 인간 게이트 안에 남습니다.
제출 단계는 스케줄에 넣지 마세요. 주간 검사, 분류, 큐 드래프트는 무인으로 실행할 수 있지만, 제출은 사람을 기다립니다.
에이전트가 적용하는 트리아지 규칙
분류와 큐는 작은 표에 의존합니다. 모든 실행이 같은 규칙을 쓰도록 프로젝트 폴더에 넣으세요:
원인 | 수정 | 수정 후 제출? |
|---|---|---|
내부 링크가 하나도 없다 | 인덱스된 페이지에서 맥락 있는 링크 추가 | 예 |
아주 새로운 페이지 | 수정할 것 없음. 한 번 제출하고 1–2주 대기 | 예, 한 번만 |
robots.txt로 차단 | 경로 차단 해제 | 예 |
중복 또는 얇은 콘텐츠 | 다시 쓰기, 통합, 또는 삭제 | 실제 변경 후에만 |
canonical이 다른 곳을 가리킴 | 잘못됐다면 수정. 의도적이라면 URL 제외 | 수정한 경우에만 |
크롤 시점에 noindex | noindex 제거 | 제거 후, 예 |
소프트 404, 아카이브, 가치 없는 패싯 | 수정 또는 삭제. 영구적으로 건너뜀 | 아니요 |
두 상태의 깊이 있는 해석(Google이 왜 어떤 페이지는 크롤하고 다른 페이지는 크롤하지 않는지 포함)은 Hermes Agent 가이드에 있습니다. 어떤 하니스가 파이프라인을 실행해도 원인은 같습니다.
검증하고 기다리기
각 배치 후 status로 알림을 확인합니다. 그것은 Google이 URL의 메타데이터를 갖고 있다는 것만 증명하지, 페이지가 인덱스됐다는 것을 증명하지 않습니다. 3–7일 후 제출한 URL을 다시 검사해 상태를 비교하세요. 건강한 패턴은 1–2주에 걸쳐 discovered → crawled → indexed입니다. GSC 데이터는 며칠 지연되고 Google은 자체 일정으로 재크롤하므로, 실제 수정이 있는데도 10–14일 후 'Crawled – currently not indexed'에 머문 URL은 제출 문제가 아니라 콘텐츠 품질 판정입니다. 로그 파일에서 이것이 보입니다: 날짜, URL, 알림 유형, 다음 실행 시 검사 상태. 그것이 측정입니다: 알림 수가 늘어나는 게 아니라 미인덱스 목록이 시간이 지나며 줄어드는 것.
정직한 한계
- Indexing API는 공식적으로
JobPosting과BroadcastEvent페이지용으로 문서화됩니다. 일반 페이지를 보내는 것은 흔한 관행이지만, Google은 모든 페이지 유형에 보장도 지원 약속도 하지 않습니다. - Search Console '색인 생성 요청' 버튼에는 공개 API가 없습니다. Indexing API는 가장 가까운 스크립트 가능한 채널이지, 버튼의 복제품이 아닙니다.
- 자동화는 우선순위를 만들지 않습니다. 고치고 제출해도 미인덱스라면 다음 수는 콘텐츠 작업이지, 또 한 번의 스케줄 실행이 아닙니다.
FAQ
Web UI 없이 헤드리스 모드만으로 실행할 수 있나요? 예. dsh --profile headless "작업"은 작업 하나를 실행하고 종료합니다. 자격 증명은 계속 ~/.dsh/에 있고 읽기 스크립트도 똑같이 작동합니다. 파이프라인을 한 번 Web UI로 끝까지 확인한 뒤 스크립트화하세요.
실행이 도중에 죽으면 작업을 잃나요? 아니요. dsh --profile headless --resume <session>으로 재개하고 제출 스크립트를 다시 실행하세요. 중복 URL은 걸러지므로 같은 배치에서 이미 알림을 보낸 URL을 다시 보내도 해가 없습니다.
GSC 속성이 여러 개입니다. 사이트마다 전부 반복해야 하나요? 스크립트는 --site sc-domain:... 인수를 받으므로 한 워크스페이스에서 여러 속성의 인벤토리와 로그를 관리할 수 있습니다. 속성별로 승인 큐 파일 하나, 제출 명령 하나를 유지하세요. 한 사이트의 할당량 오류가 다른 사이트를 막지 않습니다.
저자: Camille Rhodes, Auspia에서 300개 이상의 AI 콘텐츠 워크플로를 설계해 온 아키텍트. 콘텐츠 자동화, 퍼블리싱 시스템, AI 에이전트를 신뢰할 수 있는 성장 운영으로 바꾸는 워크플로에 대해 씁니다.
