TL;DR
Google이 페이지를 가져갔다는 사실과 검색 색인에 포함했다는 사실은 다르다. 발견, 응답 수신, 렌더링, 색인의 증거를 나누어 기록하면 어디까지 확인됐는지 설명할 수 있다. 수집 기록 하나만으로 검색 반영 완료를 보고하지 않는 것이 진단의 출발점이다.
확인한 단계만 말한다
주소가 존재한다는 사실, 브라우저에서 본문을 봤다는 사실, Google이 그 페이지를 처리했다는 사실은 서로 다른 증거다. 운영 기록에 수집됨이라고만 적으면 담당자마다 의미가 달라진다. 먼저 문제가 된 정확한 주소와 원하는 공개 목적을 고정하고 어떤 도구에서 어떤 상태를 보았는지 원문 표현대로 남긴다.
Google은 자바스크립트 웹페이지를 크롤링, 렌더링, 색인 단계로 처리한다고 설명한다. 크롤링은 요청과 응답의 단계이고, 스크립트 실행으로 본문을 구성하는 페이지는 렌더링 결과도 중요하다. 처리 단계를 구분하지 않으면 정상 응답을 받았지만 실제 설명이 비어 있는 문제를 놓칠 수 있다. 웹페이지가 눈으로 열렸다는 관찰도 누가 어떤 조건에서 열었는지 적어야 한다.
Google은 렌더링된 HTML을 페이지 색인에 사용한다고 안내한다. 초기 응답에 본문이 없는 사이트라면 렌더링 결과에서 핵심 설명이 실제로 보이는지 확인한다. 원본 HTML에 없다는 이유만으로 실패라고 단정하거나, 내 브라우저에서 나왔다는 이유만으로 Google이 똑같이 봤다고 단정하지 않는다. Google의 확인 결과와 일반 브라우저의 결과를 나란히 두는 편이 정확하다.
상태 기록지의 네 칸
기록지는 발견 경로, 현재 응답, 본문 확인, 색인 확인으로 나눈다. 발견 경로에는 내부 연결이나 사이트맵의 존재를 적고, 응답에는 실제 주소와 도착점·접근 조건을 적는다. 본문 확인에는 초기 응답과 렌더링 결과를 구분한다. 색인 확인에는 확인한 도구, 결과, 확인일을 남긴다. 어느 단계의 정보가 없으면 미확인으로 표시한다.
Google은 사이트맵 제출이 모든 URL의 수집과 색인을 보장하지 않는다고 설명한다. 사이트맵에 들어갔다는 증거를 색인 칸으로 옮기면 안 되는 이유다. 제출 성공은 발견 경로의 증거에 가깝다. 상태 기록지의 칸이 독립적이면 개발 담당자가 해결한 접근 문제와 검색 운영자가 추후 확인할 색인 문제를 나누어 볼 수 있다.
예를 들어 서비스 페이지가 정상 응답을 보내지만 설명은 스크립트 데이터 요청 뒤에만 나온다면 응답 확인은 통과하고 본문 확인은 추가 조사가 필요할 수 있다. 이 경우 사이트맵을 여러 번 제출하는 것보다 실제 본문 전달 단계의 증거를 모으는 것이 문제에 가깝다. 다만 조사 전부터 자바스크립트가 원인이라고 확정하지 않는다. 실패한 데이터 요청이나 접근 제한 등 실제 증거가 필요하다.
아직 모르는 원인을 보존한다
검색창에서 특정 문구로 보이지 않는다고 전체 색인 부재라고 결론 내리지 않는다. 확인한 검색어와 시점, 실제 도착 주소를 기록하고 관리 도구의 상태와 함께 본다. 주소가 대표 URL과 다르다면 어느 버전을 확인한 것인지도 적는다. 서로 다른 주소의 증거를 한 페이지의 이력처럼 합치면 판단이 어긋날 수 있다.
조치 후에는 무엇이 바뀌었는지 기록지를 갱신한다. 공개 응답이 바뀌었다면 그 사실부터 적고, 다음 수집 결과가 아직 없다면 이전 상태를 새 결과처럼 복사하지 않는다. 시간차가 있는 관찰을 한 날짜의 완료 결과로 묶지 않으면 담당자 사이의 잘못된 기대를 줄일 수 있다. 미확인은 실패와도 다르므로 분리 표시한다.
상태 기록지는 검색엔진이 요구한 고정 양식이 아니라 진단을 위한 운영 제안이다. 중요한 것은 단계 이름보다 증거의 범위를 넘어서 말하지 않는 태도다. 문서상 가능한 처리와 해당 페이지에서 실제로 확인된 처리를 구분해야 다음 조치가 구체적으로 정해진다.
마무리
수집 완료와 색인 완료를 분리해 적으면 재제출이나 반복 수정 전에 확인할 지점을 찾을 수 있다. 발견·응답·본문·색인의 상태 기록지를 만들고, 누락된 증거부터 채운다. 각 단계의 확인일과 주소가 맞아야 검색 반영 상태를 과장하지 않고 전달할 수 있다.