'Discovered – currently not indexed'와 'Crawled – currently not indexed'는 Search Console의 페이지 색인 생성 보고서에서 가장 흔하게 보이는 두 행이면서, 가장 많이 오해받는 두 행이기도 합니다. 기술적 실패처럼 보이지만, 실제로는 Google이 여러분의 페이지에 내린 우선순위와 품질 판단입니다. 더 세게 제출한다고 바뀌지 않습니다. 원인을 고쳐야 바뀝니다.
이 가이드는 Hermes Agent에 통째로 맡길 수 있는 전체 루프입니다: URL 목록 가져오기, 각 페이지 검사, 실제 원인 트리아지, 수정 큐 승인, 그리고 색인 생성에 값어치가 있는 페이지만 Google Indexing API를 통해 제출하기. 끝나면 일회성 버튼 클릭 세션이 아니라 반복 가능한 주간 파이프라인이 생깁니다.
마치면 갖게 되는 것
- 분류된 인벤토리: discovered 상태로 멈춘 URL, 크롤됐지만 미인덱스 URL, 처음부터 제출하지 말았어야 할 URL
- Indexing API에 제출된 승인 목록과 이유가 적힌 건너뛴 목록
- 제출이 실제로 효과가 있었는지 보여주는 검증 패스
필요한 것: Hermes Agent가 설치되어 동작할 것(hermes chat으로 세션 시작. 최신 설치 방법은 공식 문서 hermes-agent.nousresearch.com/docs 참조), Search Console 속성의 소유자 권한, 그리고 두 세트의 Google 자격 증명(GSC 읽기용 하나, Indexing API용 하나). 첫 설정은 60–90분, 이후 주간 실행은 약 15분입니다. '완료'란 제출한 URL이 몇 주 안에 검사 API에서 실제 상태 변화를 보이거나, 변화하지 않는 분명한 이유의 증거가 있다는 뜻입니다.
두 상태를 올바르게 읽기
Google은 여러분의 사이트에서 막힌 것이 아닙니다. 판단을 내린 것입니다. 상태는 어떤 판단인지 알려줍니다.
상태 | 실제 의미 | 흔한 원인 | 언제 제출할까 |
|---|---|---|---|
Discovered – currently not indexed | Google이 URL의 존재를 안다(사이트맵이나 링크를 통해)지만 아직 크롤하지 않았다 | 낮은 크롤 우선순위, 약하거나 없는 내부 링크, 대형 사이트의 크롤 예산 압박, 새 사이트, 느리거나 무거운 JS 렌더링, 사이트맵 잦은 변경 | 우선순위 신호(주로 내부 링크)를 개선한 후 한 번만 |
Crawled – currently not indexed | Google이 URL을 가져왔지만 인덱스에 추가하지 않기로 했다 | 중복·유사 중복 콘텐츠, 얇은 콘텐츠, 다른 URL을 가리키는 canonical, 크롤 시점의 noindex, 소프트 404, 가치가 낮다고 판단된 페이지 | 무언가를 바꾼 경우에만: 콘텐츠, canonical, 또는 noindex |
Indexed | 인덱스에 들어 있다 | — | 제출하지 않음 |
Excluded | 크롤됐고 의도적으로 제외됨(noindex, canonical, 중복 선택, 차단) | — | 제출하지 않음. 제외가 의도적인지 확인할 것 |
한 문장으로: 실제로 변경한 URL 또는 재검토할 가치가 있는 URL만 제출하세요. Indexing API는 알림 채널이지 순위 상위 덮어쓰기가 아닙니다. 얇은 페이지를 10번 보내도 같은 판단이 10번 돌아올 뿐입니다.
왜 에이전트로 실행하는가
GSC의 '색인 생성 요청' 버튼에는 공개 API가 없어서 공식적으로 스크립트로 누를 방법이 없습니다. 가장 가까운 자동화는 Google Indexing API로, URL 알림을 직접 받습니다. 에이전트가 여기서 힘을 발휘하는 이유는 세 가지입니다:
- 루프가 기계적이고 길다: 인벤토리 → 검사 → 분류 → 수정 → 제출 → 검증. 매주 반복됩니다.
- 감사 기록이 필요하다: 어떤 URL을 언제, 왜 제출했는지 보여주는 파일이 필요합니다.
- 승인 게이트가 필요하다: Google에 쓰는 부분은 사람이 검토해야 합니다. Hermes는 스킬, 프로젝트 폴더, 승인 규칙을 갖추고 이 분리를 중심으로 설계되었습니다.
시작 전에 필요한 것
- Hermes Agent 설치. 더 나아가기 전에
hermes chat으로 확인합니다. - 소유한 GSC 속성.
sc-domain:example.com형식(전체 URL이 아님). - 읽기 액세스: Search Console API용 Google Cloud OAuth 클라이언트(클라이언트 ID + 시크릿). GSC 스킬 스크립트가 사이트맵 나열, 검색 분석, URL 검사에 사용합니다.
- 쓰기 액세스: Indexing API가 활성화된 Google Cloud 프로젝트와 서비스 계정 JSON 키. 서비스 계정 이메일을 GSC → 설정 → 사용자 및 권한에서 소유자로 추가합니다. 제출 시 403이 나오면 이 단계를 놓친 것입니다.
- Python 3와
pip install google-auth google-api-python-client. - 프로젝트 폴더. 예:
/hermes-seo-project에context/,data/,qa/를 두고, 제출 단계는 항상 사람 승인이 필요하다고 정한approval-rules.md를 작성합니다.
1단계: URL 인벤토리 구축
두 GSC 스킬을 Hermes의 스킬 디렉터리(~/.hermes/skills)에 복사합니다: 읽기 스킬(사이트맵, 검색 분석, URL 검사)과 인덱싱 스킬(제출 스크립트). 하니스가 스킬을 카탈로그화했다면 skill_view로 불러올 수도 있습니다.
그런 다음 프로젝트 폴더의 채팅 세션에서 Hermes에게 요청합니다:
sc-domain:example.com의 모든 사이트맵을 나열하고, lastmod가 포함된 모든 URL을 가져와 data/url-inventory.csv로 작성하세요. 가져오기에 실패한 사이트맵에는 플래그를 남기세요.
Hermes는 터미널 도구로 사이트맵 명령을 실행하고 CSV를 작성합니다. 좋은 출력의 기준: URL, lastmod, 출처 사이트맵이 중복 없이 담긴 CSV. 품질 확인: 5개 행을 스팟 체크하고 총수를 GSC 사이트맵 보고서와 대조합니다. 목록이 비어 있거나 인증이 실패하면 GSC 인증 흐름을 다시 실행하세요. 읽기 스크립트에는 새 OAuth 토큰이 필요합니다.
2단계: 검사하고 분류하기
이제 에이전트가 URL Inspection API로 인벤토리를 배치 검사해 각 페이지의 현재 커버리지 상태를 가져옵니다. 다음 단계를 요청합니다:
data/url-inventory.csv의 모든 URL을 검사하세요. 세 파일로 나누세요: data/to-submit.txt(미인덱스이고 제출할 가치가 있는 것), data/skip.txt(URL당 한 줄 이유 포함), data/needs-fix.txt(미인덱스이고 우리가 바꿀 수 있는 것에 막힌 것).
검사 API는 속성별로 속도 제한이 있습니다(현재 할당량은 Google Cloud Console에서 확인하세요. 하루 수천 건이지만 무제한은 아닙니다). 대형 사이트에서는 lastmod가 최신인 URL, 즉 이번 분기에 실제로 변경한 URL로 범위를 좁힙니다. 품질 확인: 건너뛴 목록을 샘플링하세요. 대부분은 noindex, 다른 URL을 가리키는 canonical, 중복 페이지여야 하며, 신경 쓰는 페이지가 아니어야 합니다. 수천 개 URL 사이트에서 needs-fix가 비어 있다면 인벤토리 단계에서 페이지를 놓친 것일 수 있습니다. 입력 범위를 넓히세요.
3단계: 제출 전에 트리아지하기
사람들이 건너뛰는 단계입니다. 막힌 URL을 원인과 수정으로 매핑합니다. 이 순서로:
원인 | 수정 | 수정 후 제출? |
|---|---|---|
내부 링크가 하나도 없다 | 관련 인덱스 페이지에서 맥락 있는 링크 추가 | 예 |
새 사이트 또는 새 페이지 | 수정할 것 없음. 한 번 제출하고 1–2주 대기 | 예, 한 번만 |
robots.txt로 차단 | 경로 차단 해제 | 예 |
크롤됐지만 중복 또는 얇음 | 다시 쓰기, 통합, 또는 삭제 | 실제 콘텐츠 변경 후에만 |
canonical이 다른 URL을 가리킴 | 잘못됐다면 canonical 수정. 의도적이라면 이 URL 제출 중단 | 수정한 경우에만 |
크롤 시점에 noindex | noindex 제거 후 재크롤 유도 | 제거 후, 예 |
소프트 404, 가치 없는 페이지네이션·아카이브 | 페이지 수정 또는 삭제 | 아니요 — 영구적으로 건너뜀 |
Hermes에게 수정 큐를 표로 드래프트하게 하세요: URL, 추정 원인, 증거(검사 결과 또는 콘텐츠 확인), 제안 조치, 위험 수준. 각 행을 채팅에서 승인하세요. approval-rules.md에 이를 의무로 정하세요: 에이전트는 준비하고, 당신은 승인하고, 낮은 위험을 넘는 것은 승인 없이 제출하지 않습니다.
승인 게이트가 에이전트의 준비 작업과 쓰기 단계를 분리합니다.
수정 자체는 일반 SEO 작업입니다: 콘텐츠 다시 쓰기, canonical 정리, 내부 링크. 이 파이프라인이 담당하는 것은 제출 절반입니다. 수정 절반은 Hermes 시리즈의 감사·리프레시 아티클이 담당합니다.
제출 목록은 '수정 가능'과 '인덱스 가치 있음'의 교집합입니다.
4단계: Indexing API로 제출하기
큐가 승인되면 URL을 data/approved-urls.txt에 넣고 Hermes가 인덱싱 스킬을 실행하게 합니다:
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py check-auth
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py submit --urls-file data/approved-urls.txt기본 알림 유형은 URL_UPDATED로, 새 페이지나 변경된 페이지에 쓰는 것입니다. 기억할 숫자 세 개: 기본 할당량은 하루 200개 URL, 분당 600건, 그리고 403은 서비스 계정이 속성의 소유자가 아니라는 뜻입니다. 승인 목록이 200개를 넘으면 날짜를 나눠 제출합니다. 남은 배치는 Hermes에 스케줄링시킬 수 있습니다.
이미 인덱스된 페이지나 건너뛴 목록은 제출하지 마세요. 낭비된 알림은 할당량과 노이즈만 소모합니다.
5단계: 검증하고 기다리기
제출 직후의 status는 Google이 알림에 대한 메타데이터를 가지고 있는지 여부만 알려주며, 페이지가 인덱스되었는지는 알려주지 않습니다. 진짜 확인은 며칠 뒤입니다.
배치 후 3–7일 뒤에 Hermes에게 요청합니다:
data/approved-urls.txt의 URL을 다시 검사하고 지난 실행과 비교해 상태 변화를 보고하세요.
건강한 이동은 discovered → crawled → indexed입니다. 몇 주 동안 그게 어떻게 보이는지: 미인덱스 목록이 줄어들고, 실제로 한 수정(새 내부 링크, 다시 쓴 카피)이 인덱스에 나타납니다. GSC 데이터는 며칠 지연되고 Google은 자체 일정으로 재크롤한다는 것을 기억하세요. 진짜 수정 후 10–14일 'Crawled – currently not indexed'에 머무는 URL은 품질 신호이지 제출 문제가 아닙니다. 콘텐츠 작업으로 에스컬레이션하세요.
루프를 계속 돌리기
파이프라인을 주간 루틴으로 만드세요: 지난 실행 이후 새로 추가되거나 업데이트된 URL → 검사 → 분류 → 트리아지 → 승인 → 제출 → 로그. Hermes는 읽기 전용 부분(인벤토리, 검사, 분류)을 스케줄로 무인 실행하고 매주 월요일 큐를 제시할 수 있습니다. 제출 단계는 승인 게이트 안에 두고, qa/indexing-log.md에 지속 로그를 남기세요: 제출 날짜, URL, 알림 유형, 결과. 6개월 분량의 로그만이 파이프라인이 작동하는지 정직하게 측정하는 방법입니다.
정직한 한계
- Google은 Indexing API를
JobPosting또는BroadcastEvent구조화 데이터가 있는 페이지용으로 문서화합니다. 일반 페이지에 쓰는 것은 널리 퍼진 SEO 관행이지만, Google은 모든 페이지 유형에 인덱스나 지원을 보장하지 않습니다. - '색인 생성 요청' 버튼에는 공개 API가 없습니다. Indexing API는 가장 가까운 자동화이지 같은 버튼이 아닙니다.
- 제출은 우선순위를 만들지 않습니다. 고치고, 제출하고, 기다려도 미인덱스인 페이지의 다음 답은 콘텐츠 품질이지, 또 한 번의 알림이 아닙니다.
FAQ
Indexing API가 일반 페이지에서도 작동하나요? 보내는 URL은 무엇이든 받아들입니다. Google 공식 문서는 JobPosting과 BroadcastEvent 페이지를 대상으로 하므로, 일반 페이지 제출은 베스트에포트로 취급하세요: 도움이 되고 흔하며, 결코 보장되지 않습니다.
제출했는데 왜 'Discovered – currently not indexed'에 머무나요? 그 상태는 보통 실패가 아니라 크롤 우선순위를 뜻합니다. 페이지로 향하는 내부 링크, robots.txt가 경로를 차단하는지, 페이지가 JavaScript 위주인지 확인하세요. 그리고 기다리세요. 새 사이트에서는 발견에서 크롤까지 1–2주가 걸릴 수 있습니다.
하루 200개면 충분한가요? 대부분 사이트에서 충분합니다. 실제로 변경한 URL만 제출해야 하기 때문입니다. 정기적으로 그보다 많다면 비즈니스 가치로 우선순위를 정하고 Google Cloud Console에서 할당량 증가를 요청하세요.
Indexing API가 순위를 더 빨리 올려주나요? 아니요. URL이 변경되었음을 Google에 알릴 뿐입니다. 순위 판단은 별개이며, 알림 횟수가 아니라 Google 시스템이 내립니다.
Search Console의 '색인 생성 요청' 클릭과 어떻게 다른가요? 의도는 같고 메커니즘이 다릅니다. 버튼은 공개 API가 없는 UI 전용이고, Indexing API는 스크립트 가능한 채널입니다. 둘 다 페이지가 인덱스에 속하는지에 대한 Google의 판단을 덮어쓰지 못합니다.
저자: Julian Mercer, Auspia의 테크니컬 SEO 실무자(14년 경력). 크롤러빌리티, 인덱싱, 스키마, 그리고 Google과 AI 시스템 모두가 사이트를 제대로 읽을 수 있게 하는 기술 기반에 대해 씁니다.
