TL;DR
사이트맵, canonical 선언, 리디렉션 목적지가 서로 다른 주소를 제시하면 신호를 한곳에 모아 비교한다. 어떤 설정이 더 강한지만 보고 나머지를 방치하지 않는다. 운영자가 선호하는 최종 주소와 실제 공개 본문을 먼저 정하고, 각 신호가 같은 목적지를 가리키도록 정합성을 검수한다.
충돌은 설정값을 함께 놓아야 보인다
사이트맵 담당자와 템플릿 담당자가 다르면 같은 글의 선호 주소가 달라질 수 있다. 한 팀은 새 주소를 제출했는데 페이지는 옛 주소를 대표로 선언하고, 이동 규칙은 또 다른 경로를 거칠 수 있다. 개별 설정 화면에서는 모두 값이 있어 정상처럼 보이므로 한 행에 모아 읽어야 한다. 처음에는 수정하지 말고 실제 배포 상태를 보존해 기록한다.
Google은 같은 페이지에 대해 서로 다른 canonical 방법에서 다른 URL을 지정하지 말라고 권고한다. 사이트맵과 페이지 선언이 다르면 단순한 취향 차이로 남겨 둘 문제가 아니다. 어떤 주소를 공개 대표로 운영하려는지 결정하고 어긋난 설정의 출처를 찾는다. 다만 Google이 현재 무엇을 선택했는지 확인하지 않았다면 선택 오류라고 단정하지 않는다. 설정 충돌과 관찰된 선택은 다른 증거다.
Google은 사이트맵 포함을 대표 URL 선택에 도움이 되는 상대적으로 약한 신호로 설명한다. 사이트맵에 올바른 주소를 넣었다고 해서 다른 강한 신호의 충돌을 무시할 수는 없다. 운영자에게는 제출 주소가 맞다는 사실보다 어떤 항목이 다른 주소를 제시하는지 설명하는 편이 유용하다. 약한 신호라는 표현을 해당 파일이 불필요하다는 뜻으로 바꾸지 않는다.
신호 대조표의 열 구성
표에는 현재 확인 주소, 원하는 대표 주소, 페이지 선언값, 사이트맵 포함 주소, 이동 목적지, 내부 연결, 실제 본문을 둔다. 중간에 이동이 있으면 최초 목적지와 최종 도착점을 구분한다. 같은 주소처럼 보여도 호스트나 보안 방식이 다른지 확인한다. 비슷하게 보인다는 인상 대신 실제 값을 대조해야 수정 대상을 좁힐 수 있다.
Google은 여러 대표 URL 방법을 일관되게 조합하면 선호 주소를 알리는 데 도움이 된다고 설명한다. 이 안내를 실행하기 위한 권장 절차는 선호 주소 결정, 현재 신호 수집, 충돌 표시, 수정 담당자 배정, 공개 결과 재확인이다. 검색엔진이 요구하는 고정 순서라고 주장할 필요는 없다. 중요한 것은 각 담당자가 같은 기준 주소를 사용하도록 만드는 일이다.
예를 들어 새 서비스 주소를 쓰기로 했지만 사이트맵은 새 주소, canonical은 이전 주소라면 먼저 새 주소가 실제 최종 본문인지 확인한다. 새 주소가 임시 미리보기라면 사이트맵을 고쳐야 할 수도 있다. 반대로 이미 새 주소가 정식이라면 옛 선언을 남긴 템플릿이 수정 대상일 수 있다. 값이 다르다는 이유만으로 항상 어느 한 항목을 자동 우선하지 않는다.
생성 경로를 따라가 수정한다
충돌이 많은 경우 개별 페이지를 손으로 고치기 전에 값을 만드는 규칙을 확인한다. 기본 도메인 설정, 콘텐츠 주소 필드, 이전 규칙처럼 서로 다른 생성 경로가 있을 수 있다. 같은 원인으로 여러 페이지가 어긋난다면 관련 묶음을 기술 담당자에게 전달한다. 운영자는 확인한 범위만 보고하고 사이트 전체가 같은 원인이라고 추측해 확장하지 않는다.
수정 후에는 각 신호를 다시 공개 상태에서 확인한다. 설정 파일의 값이 바뀌었어도 캐시되거나 다른 템플릿이 사용되면 실제 페이지에는 옛 값이 남을 수 있다. 전체 점검을 끝냈다고 표시하기 전에 원래 충돌했던 주소를 재검수한다. 새 값과 확인일을 남기고 이전 값은 변경 이력으로 보존한다.
대표 선언이 정리됐다는 사실과 실제 검색 주소가 바뀌었다는 사실은 분리한다. 선언 정합성은 운영자가 확인할 수 있는 배포 결과이고, Google의 선택은 별도 관찰이 필요하다. 검색 결과에서 옛 주소가 한 번 보였다는 이유로 기준 주소를 계속 바꾸면 신호가 다시 불안정해질 수 있다. 다음 판단에 필요한 증거부터 확보한다.
마무리
대표 URL 충돌의 산출물은 원하는 주소와 각 신호의 값을 함께 담은 대조표다. 실제 본문을 기준으로 선호 주소를 정하고 생성 경로까지 찾아 수정한다. 배포된 신호가 일치했는지와 Google의 실제 선택이 확인됐는지를 나누어 보고해야 작업 상태가 명확하다.