TL;DR
사이트맵 제출 다음 작업은 제출한 주소가 실제로 검색에 보여 주고 싶은 페이지인지 확인하는 일이다. 수집 요청을 많이 보내는 것보다 제출 목록과 공개 페이지의 상태를 맞추는 것이 먼저다. 대표 주소, 응답, 공개 목적을 한 줄씩 대조하면 남길 주소와 고칠 주소를 구분할 수 있다.
제출 성공은 목록 검수의 시작이다
사이트맵은 사이트의 중요한 페이지와 파일 및 그 관계를 검색엔진에 전달하는 파일이다. 제출 결과에 오류가 없더라도 목록 안의 페이지가 모두 적절한 것은 아니다. 끝난 행사, 임시 확인 화면, 다른 주소로 이동하는 페이지가 자동으로 들어갈 수 있다. 관리자가 작성한 페이지 목록과 실제 사이트맵을 함께 준비하고 각 주소가 왜 들어갔는지부터 묻는다.
Google은 사이트맵 안의 모든 URL을 크롤링하거나 색인한다고 약속하지 않는다. 따라서 제출 건수와 색인 건수를 동일한 목표로 놓지 않는다. 공개할 가치가 없는 주소까지 목록을 늘리면 점검할 대상만 많아진다. 서비스 안내와 상담 완료 화면은 목적이 다르며, 완료 화면은 검색에서 독립적으로 읽을 이유가 있는지 따로 판단해야 한다.
포함·제외·수정으로 나눈다
검수표에는 제출 주소, 원하는 대표 주소, 페이지 제목, 현재 도착점, 공개 목적, 판단, 담당자를 둔다. 처음부터 잘못된 주소를 지우기보다 현재 목록을 보존한 상태에서 판단을 붙이면 변경 이유를 설명하기 쉽다. 정상적인 안내 페이지라면 포함, 공개 목적이 없는 임시 페이지라면 제외 검토, 옛 주소나 잘못된 목적지라면 수정으로 분류한다.
Google의 대표 URL 안내는 사이트맵과 다른 대표 URL 신호에서 서로 다른 주소를 지정하지 말라고 권고한다. 예를 들어 같은 서비스의 추적 주소가 사이트맵에 있고 페이지는 일반 주소를 대표로 선언한다면 두 주소를 나란히 적는다. 추적 기능을 끄라는 뜻은 아니다. 검색용 목록에서 어떤 주소를 제시할지 정하고 실제 페이지의 선언과 맞추려는 작업이다.
주소가 열리는지만 보지 말고 도착한 본문도 읽는다. 정상 응답을 보냈지만 서비스 설명 대신 오류 안내나 로그인 화면이 나올 수 있다. 이 경우 포함 여부를 즉시 확정하지 말고 공개 접근 문제로 담당자에게 돌린다. 관리 권한이 있는 브라우저에서만 정상인 결과를 공개 접근의 증거로 사용해서는 안 된다.
자동 생성 목록의 예외를 찾아본다
사이트맵이 관리 도구에서 자동 생성된다면 최근 새로 만든 페이지와 오래된 주소를 함께 표본으로 고른다. 새 페이지만 보면 과거 삭제·통합 기록이 목록에 남은 문제를 놓칠 수 있다. 여러 언어 버전을 운영한다면 각 버전의 실제 주소도 분리해 확인한다. 한 언어의 성공을 전체 버전의 성공으로 넓혀 쓰지 않는다.
최종 산출물에는 제외한 이유를 짧게 남긴다. 검색 가치가 없는 확인 화면인지, 미공개 상태인지, 다른 페이지로 통합됐는지가 서로 달라야 다음 운영자가 되돌리지 않는다. 검수표의 분류는 운영을 위한 권장 절차이며 Google이 정한 제출 양식은 아니다. 목록이 길면 핵심 서비스와 최근 변경 페이지부터 처리하되 미검수 항목을 정상으로 표시하지 않는다.
수정 후에는 생성 규칙과 실제 배포 결과를 구분한다. 규칙을 고쳤다고 말한 날짜와 공개 파일이 바뀐 날짜가 다를 수 있다. 공개된 사이트맵을 다시 확인하고, 고친 주소가 올바르게 반영됐는지 이전 목록과 대조한다. 운영 보고에는 전체 주소 수보다 검수 완료·보류·수정 항목이 무엇인지 쓰는 편이 원인 파악에 유용하다.
복수의 사이트맵이 있다면 소유 담당자를 정해 같은 주소가 어디에서 생성되는지도 기록한다. 파일 하나에서 지웠는데 다른 자동 목록에 다시 생기면 수정 완료로 보기 어렵다. 생성 경로가 확인되지 않은 주소는 임시 삭제보다 원인 확인 대상으로 남긴다.
마무리
사이트맵의 품질은 제출 버튼이 눌렸는지가 아니라 제출 목록이 현재 공개 목적과 일치하는지로 검수한다. 포함·제외·수정 표와 실제 배포 확인을 남기고, 이후 수집과 색인 관찰은 별도 단계로 기록한다. 이 구분이 있어야 제출 성공을 검색 반영 완료로 잘못 보고하는 일을 줄일 수 있다.