TL;DR
사이트맵에 새 서비스 페이지를 넣었다면, 다음에는 사용자가 사이트 안에서 그 페이지까지 갈 수 있는지 확인한다. 사이트맵 제출과 내부 연결은 서로 다른 작업이다. 메뉴에 모든 상세 페이지를 늘어놓을 필요는 없지만, 그 서비스를 찾을 이유가 있는 상위 페이지에서 자연스러운 진입 경로는 제공해야 한다.
제출 목록과 탐색 경로를 구분한다
Google은 사이트맵이 URL 발견을 돕지만 모든 항목의 수집과 색인을 보장하지는 않는다고 설명한다. 제출이 성공했다는 화면만으로 새 서비스가 검색에 반영됐다고 판단하면 상태를 잘못 전달하게 된다. 먼저 페이지를 공개하려는 목적과 고객이 찾는 상황을 적는다. 예를 들어 기존 사이트를 고치는 서비스라면 신규 제작 안내보다 개편 안내에서 연결할 이유가 더 명확하다. 실제 제공하지 않는 서비스를 연결 명목으로 새로 만들지는 않는다.
Google은 중요하게 여기는 각 페이지가 사이트의 다른 페이지 하나 이상에서 연결되도록 권장한다. 이 안내를 실제 작업으로 바꾸려면 연결 출발점이 필요하다. 첫 화면, 서비스 목록, 관련 설명 글에서 새 페이지로 가는 길을 직접 따라가 본다. 주소를 알고 직접 입력한 결과와 사이트에서 발견한 결과는 별도 칸에 남긴다. 전자는 페이지 존재를, 후자는 탐색 경로를 보여 주기 때문이다.
고립 페이지 연결표를 만든다
표에는 대상 페이지, 독자 상황, 연결 출발점, 현재 링크, 수정 문구, 검수 결과를 둔다. 현재 링크가 없다면 추측해서 채우지 말고 없음으로 적는다. 상위 서비스 소개가 이미 있다면 해당 서비스가 언급되는 문단을 먼저 살핀다. 문맥이 맞지 않으면 무리하게 끼우기보다 서비스 목록의 분류를 조정하는 편이 읽기 쉽다.
설명적인 내부 링크 문구는 사용자와 Google이 연결될 페이지의 내용을 이해하는 데 도움이 된다. 따라서 새 서비스의 이름만 반복하기보다 도착 후 무엇을 확인할 수 있는지 알려 준다. 가령 상세 보기보다 개편 전 확인할 작업 범위가 더 분명할 수 있다. 다만 도착 페이지가 그 범위를 실제로 설명하는지 먼저 읽어야 한다. 링크 문구가 본문보다 넓은 약속을 해서는 안 된다.
검수자는 편집 화면에서 저장 여부만 확인하지 않는다. 공개된 출발 페이지에서 링크를 눌러 원하는 주소로 도착하는지, 모바일에서도 그 연결이 있는지 확인한다. 메뉴와 본문 연결을 함께 바꿨다면 두 경로를 각각 남긴다. 어느 한 경로의 성공으로 다른 경로까지 정상이라고 처리하지 않는다. 이 연결표는 Google이 요구하는 고정 양식이 아니라 운영자가 누락을 줄이기 위한 편집 절차다.
연결이 생긴 뒤에도 남겨 둘 확인
연결 완료 날짜와 실제 배포 날짜를 구분한다. 사이트맵은 갱신됐지만 본문 링크가 아직 배포되지 않았을 수도 있다. 반대로 링크는 살아 있는데 사이트맵에는 옛 주소가 남을 수 있다. 두 목록에서 같은 대표 주소를 사용하는지 대조하면 다음 점검에서 원인을 좁히기 쉽다. 링크를 추가한 직후 검색 화면에 보이지 않는다는 이유로 문구를 계속 바꾸면 무엇이 바뀌었는지 추적하기 어렵다.
관련 글이 여러 개라면 모두 연결하는 것을 목표로 삼지 않는다. 방문자가 다음 판단을 위해 실제로 필요로 하는 연결인지 묻는다. 서비스 신청 전에 준비 자료를 알아야 하는 글과 신청 후 관리 방법을 설명하는 글은 독자의 단계가 다르다. 단계가 다른 연결을 한꺼번에 넣으면 새 서비스의 위치보다 탐색 부담이 커질 수 있다.
외부에 이미 공유한 주소가 있다면 그 주소도 연결표의 비고에 남긴다. 내부에서 사용하는 주소와 다른 경우 담당자가 선호 주소를 확인할 수 있어야 한다. 페이지를 숨기려는 의도가 있었는지도 함께 묻는다. 실수로 빠진 연결과 승인된 비공개 운영을 같은 오류로 처리하지 않기 위해서다.
마무리
완료 산출물은 제출 성공 화면 한 장이 아니라 고립 페이지 연결표다. 대상마다 유효한 출발점과 설명 문구, 실제 도착 확인이 있어야 한다. 이후 검색 수집과 색인 상태는 별도로 관찰한다. 내부 연결을 고쳤다는 사실과 Google에서 반영을 확인했다는 사실을 나눠 남겨야 작업 결과를 정확하게 설명할 수 있다.