색인이 안 된 게 아니라 방문 자체를 안 하고 있었다

전날 세운 가설이 왜 틀렸나

전날에는 ‘발견됐지만 색인되지 않음’ 상태라고 가정했다. 그런데 실제로 도구를 열어 직접 확인하니 상태 값이 그게 아니라 ‘발견됐지만 크롤되지 않음’이었다. 이 둘은 다른 단계다 — 크롤이 안 되면 색인 판단 자체가 시작되지도 않는다. 가정이 아니라 실측이 한 단계 더 정확한 그림을 보여줬다.

사이트맵에는 문제가 없었나

사이트맵 자체는 정상으로 확인됐다 — 오류나 경고 없이 정상 처리 상태였다. 다만 실제로 발견된 URL 수가 우리 사이트맵에 있는 URL 수보다 훨씬 적었다. 신규 도메인에 크롤 예산을 거의 배정하지 않는 상태로 보는 것이 가장 자연스러운 해석이었다.

자사 로그와 어긋난 것은 무엇인가

자체 방문 기록에는 해당 크롤러가 홈페이지를 여러 차례 방문한 것으로 남아 있는데, 검색엔진 쪽은 한 번도 방문한 적이 없다고 답했다. 사이트맵 마지막 확인 날짜도 양쪽이 하루씩 어긋났다.

이 모순을 어떻게 처리했나

확정하지 않았다. 방문 기록은 정체를 자처하는 문자열(UA)만으로 판정하고 있어서, 실제로 그 크롤러인 것처럼 위장한 요청일 가능성을 배제할 근거가 없다. IP 주소 같은 부가 정보를 남기지 않기로 한 것은 개인정보 설계상 옳은 결정이지만, 그 대가로 이런 상황에서 진위를 가릴 수단이 없어진다는 것도 함께 확인됐다. ‘검증된 방문’이라고 쓰지 않고 있는 기존 원칙이 정확히 이런 상황을 위한 것이었다.

다음에 무엇을 확인해야 하나

방문자의 정체를 UA 문자열이 아니라 인프라 제공사가 검증한 값으로 함께 기록하는 방법을 개선안으로 남겼다. 이 데이터를 다른 곳의 근거로도 쓰고 공개까지 하는 만큼, 확인되지 않은 상태로 오래 두면 안 되는 항목이라고 판단했다.