사이트맵에 주소 34개를 올렸는데, 구글 서치콘솔이 색인으로 인정한 주소는 홈 화면 1개뿐이었습니다. 나머지 중 27개에는 제가 만든 점검 스크립트가 경고를 표시했고(서치콘솔이 낸 경고가 아닙니다), 저는 그 27건이 색인을 막는 진짜 원인이라고 생각했습니다. 결론부터 말씀드리면 27건은 전부 오탐이었습니다. 같은 경고를 보고 문제 없는 글을 고치는 헛수고를 하지 않으시도록, 점검 스크립트와 그 경고가 나오기까지의 과정을 순서대로 적겠습니다.
손으로 34개를 확인하다 스크립트를 만들었습니다
색인 여부만 보려면 서치콘솔의 페이지 색인 생성 보고서에서 목록으로 확인할 수 있습니다. 다만 주소별 대표 주소와 마지막 크롤링 시각까지 보려면 URL 검사 기능에 주소를 하나씩 입력해야 합니다. 주소가 34개면 34번을 반복해야 하고, 다음 주에 같은 목록을 다시 보려면 또 34번입니다. 매주 반복할 방식이 아니었습니다.
그래서 파이썬으로 gsc_index_monitor.py라는 점검 스크립트를 작성했습니다. 256줄짜리 도구이고 하는 일은 단순합니다. 사이트맵 XML을 읽어 주소 목록을 추출하고, 각 주소를 구글 서치콘솔의 URL 검사 API로 조회합니다. 그다음 결과를 마크다운 표와 JSON 두 가지로 저장하고, 직전 실행 결과와 대조해 새로 색인된 주소와 색인에서 빠진 주소를 따로 표시합니다. 한 번 실행하면 전체 상태가 표 한 장으로 정리됩니다. 9월 12일과 18일, 24일 세 번의 측정은 모두 이 스크립트로 했습니다.
다만 이 스크립트가 못 하는 일도 있습니다. 제가 자동화한 것은 조회와 비교, 다시 말해 관측뿐입니다. 글 28편에 색인 1개, 애드센스 속설 5가지를 걸러낸 기록에서 쓴 숫자도 이 도구로 모은 것입니다.
점검 결과가 경고 27건을 표시했습니다
9월 24일 측정 결과는 이랬습니다. 사이트맵에 올라간 주소 34개 가운데 색인된 주소는 홈 화면 1개였습니다. 27개는 “크롤링됨 – 현재 색인이 생성되지 않음” 상태였고, 나머지 6개는 구글이 아직 알지 못하는 주소로 표시됐습니다. 세 번의 측정 내내 색인 수는 1에서 움직이지 않았습니다. 신규 색인 0건, 색인 이탈 0건입니다.
그리고 점검표에서 한 항목이 눈에 들어왔습니다. 구글이 판단한 대표 주소, 즉 canonical 항목이 27건 전부 불일치로 표시돼 있었습니다. 대표 주소가 어긋나면 색인에서 밀려난다고 알고 있었기에, 색인이 1에서 멈춘 이유를 찾았다고 생각했고 27건을 하나씩 열어 확인하기 시작했습니다. 미리 적어 두면 이 생각은 두 번 틀렸습니다. 값은 애초에 어긋나 있지 않았고, 이 27건이 받은 상태 표시도 대표 주소 문제를 가리키는 것이 아니었습니다.
서치콘솔 URL 검사 API가 반환하는 값
주소 하나를 넣으면 구글이 그 주소를 어떻게 처리하고 있는지를 항목별로 반환합니다. 제가 점검에 사용한 값은 여섯 가지입니다.
| 항목 | API 필드 | 무엇을 알 수 있나 |
|---|---|---|
| 색인 상태 | coverageState | 색인됨, 크롤링됨-색인 안 됨 등 현재 처리 단계 |
| 구글이 인식한 대표 주소 | googleCanonical | 구글이 이 페이지의 정식 주소로 고른 값 |
| 사이트가 선언한 대표 주소 | userCanonical | 내 페이지가 스스로 정식이라고 밝힌 값 |
| robots.txt 허용 여부 | robotsTxtState | 크롤링이 차단된 주소인지 |
| 마지막 크롤링 시각 | lastCrawlTime | 구글이 마지막으로 방문한 시점 |
| 색인 판정 | verdict | 이 주소가 색인 기준을 통과했는지 |
제 점검 스크립트는 구글이 고른 대표 주소와 사이트가 선언한 대표 주소가 같은지를 확인해서, 다르면 경고로 표시하도록 만들어 두었습니다. 사이트가 대표 주소를 선언하지 않았으면 조회에 사용한 주소와 비교합니다.
27건 경고의 정체는 한글 주소였습니다
로그를 열어 보니 참·거짓만 적혀 있었습니다. 비교 결과만 저장하고 원본 값은 버리도록 만들어 둔 탓에, 무엇과 무엇이 어긋났는지 알 방법이 없었습니다. 그래서 소개 페이지 하나를 골라 API를 직접 한 번 더 호출하고, 돌아온 두 값을 나란히 놓고 봤습니다.
- googleCanonical:
https://jaydenreview.com/소개/ - userCanonical:
https://jaydenreview.com/%EC%86%8C%EA%B0%9C/
같은 페이지인데 한쪽은 한글 그대로이고, 다른 쪽은 퍼센트 인코딩(한글 같은 글자를 % 기호와 영문·숫자로 바꿔 적는 주소 표기 방식)으로 적혀 있었습니다. 사람 눈에는 같은 주소인데, 문자열을 그대로 맞대어 보는 비교에서는 거짓이 나옵니다.
이 블로그는 주소에 한글 슬러그를 씁니다. 그래서 한글이 들어간 주소는 전부 같은 이유로 불일치로 기록됐습니다. 경고 27건은 사이트의 문제가 아니라 제 비교 방식의 문제, 즉 오탐이었습니다. 실제로 경고가 붙은 27개는 “크롤링됨 – 색인 안 됨” 27개와 같은 주소들이었습니다. 대표 주소 값이 들어 있던 주소는 홈 1개와 크롤링된 27개였는데, 한글이 들어간 27개가 전부 불일치로 찍혔습니다. 홈은 주소에 한글이 없어 두 값이 문자 그대로 같았고, 구글이 아직 모르는 6개는 비교할 값 자체가 비어 있었습니다. 덧붙이면 이 값이 어긋났다고 해서 주소를 영문으로 바꿀 이유는 없습니다.
비교 한 줄을 고쳤습니다
고친 부분은 비교 함수 하나입니다. 양쪽을 먼저 디코딩하고 끝의 빗금을 떼어 낸 다음 맞대어 봅니다.
def _same_url(a: str, b: str) -> bool:
"""퍼센트 인코딩 차이를 무시하고 URL 비교 (한글 슬러그 오탐 방지)."""
from urllib.parse import unquote
norm = lambda u: unquote(u or "").rstrip("/")
return norm(a) == norm(b)구글이 대표 주소를 아직 정하지 않은 주소는 비교할 대상 자체가 없습니다. 이 경우를 걸러 내는 처리는 수정 전부터 들어 있었고, 실제로 아직 알려지지 않은 주소 6개는 수정 전에도 경고가 붙지 않았습니다. 검증은 인코딩된 주소와 디코딩된 주소를 넣으면 참, 서로 다른 주소를 넣으면 거짓, 값이 비어 있으면 비교 전에 걸러져 경고가 나지 않는지 세 가지로 했고, 모두 의도대로 동작했습니다.
같은 날 저녁 수정판으로 전체를 다시 조회했습니다. 그사이 새 글 하나가 올라가 주소는 35개가 됐고, 색인 1개·크롤링됨 색인 안 됨 27개·아직 알려지지 않음 7개였습니다. 대표 주소 불일치 경고는 0건이었습니다. 이 수정으로 달라진 것은 점검 도구의 경고뿐이고, 색인이 생성되지 않은 27건은 그대로입니다. 적어도 대표 주소 불일치는 그 원인이 아니었습니다.
자동 점검에서 실제로 볼 값
매주 확인하는 값은 세 가지입니다. 첫째는 색인된 주소 수의 변화로, 신규와 이탈을 나눠서 봅니다. 숫자가 움직이지 않는다는 사실 자체가 상태 보고입니다.
둘째는 “크롤링됨 – 현재 색인이 생성되지 않음” 상태의 비중입니다. 8할 가까이가 한 상태에 몰려 있으면 개별 글보다 사이트 전체를 봐야 한다는 신호로 읽습니다. 셋째는 주소별 마지막 크롤링 시각입니다. 크롤링이 멈췄는지, 방문은 하는데 색인만 안 되는지가 여기서 갈립니다.
기록 방식에서도 하나 배웠습니다. 판정에 쓴 원본 값을 함께 저장해야 다음 주에 추적이 가능합니다. 스킬 60개 삭제해도 0.1k, 클로드코드 토큰 실측 6가지를 쓸 때도 측정값을 원본 그대로 남겨 둔 덕분에 나중에 수치를 다시 확인할 수 있었습니다.
이 방식의 한계
첫째, 색인 요청은 자동화할 수 없습니다. 구글은 일반 페이지의 색인 요청 API를 제공하지 않습니다. 공개된 Indexing API는 채용공고와 라이브 스트리밍 페이지용입니다. 색인 요청만큼은 서치콘솔 화면에서 사람이 직접 해야 합니다.
둘째, 조회 수에 상한이 있습니다. URL 검사 API에는 일일 조회 한도가 있어서 주소가 많은 사이트는 전체를 한 번에 확인하기 어렵습니다. 제 사이트는 34개라 전수 조회가 가능했지만, 수백 개 규모라면 우선순위를 정해 나눠 조회하는 설계가 필요합니다.
셋째, 점검은 관측일 뿐입니다. 상태를 정확히 읽어 준다고 해서 색인이 늘어나지는 않습니다. 서치콘솔 도움말도 이 상태에 대해 앞으로 색인될 수도 있고 아닐 수도 있으며 재제출은 필요하지 않다고 안내합니다(페이지 색인 생성 보고서). 측정 도구를 수정하는 동안에도 색인 수는 1에서 그대로였습니다. 제가 바꿀 수 있는 것은 요청 횟수가 아니라 다음에 올릴 글의 내용이라, 같은 엑셀 정리, 코덱스 198초 vs 클로드코드 131초처럼 직접 측정한 기록을 쌓는 쪽으로 방향을 잡았습니다.
한글 주소를 쓰는 블로그라면 점검 도구를 만들 때 두 가지를 먼저 정하시기 바랍니다. 조회에 쓰는 주소 형태를 서치콘솔이 돌려주는 형태와 맞추고, 변환 전후 주소와 상태 문자열을 원본 그대로 함께 저장하는 것입니다. 이 두 가지가 없으면 경고가 표시됐을 때 도구 문제인지 사이트 문제인지 구분할 수 없습니다. 그리고 “크롤링됨 – 현재 색인이 생성되지 않음”이 쌓여 있다면, 같은 주소를 반복해서 요청하는 대신 숫자를 기록해 두고 다음 주와 비교하시기 바랍니다.
