값을 읽는 시점을 나눕니다
페이지의 원본 응답을 저장하고 초기 로딩이 끝난 DOM을 따로 읽습니다. SPA 방식의 내부 이동을 사용한다면 새로고침으로 진입했을 때와 다른 페이지에서 링크를 눌러 진입했을 때를 비교합니다. 쿼리나 해시가 있는 요청에서는 대표 주소 정책이 무엇인지 기대값을 먼저 적어 두어야 잘못된 덮어쓰기를 판정할 수 있습니다.
태그 생성 주체를 목록으로 만듭니다
서버 메타데이터, 공통 레이아웃, 페이지별 예외 코드, 클라이언트 head 관리와 외부 삽입 도구를 구분합니다. 한 곳에서 주소를 고쳤는데 다른 도구의 오래된 설정이 뒤늦게 실행되는지 확인합니다. URL 조립 함수가 현재 브라우저 주소를 그대로 사용하는 경우 추적 쿼리나 미리보기 호스트가 대표 주소에 섞이지 않는지도 봅니다.
재현 표본으로 차이를 좁힙니다
- 직접 방문과 내부 링크 이동의 결과를 각각 저장합니다.
- 쿼리가 없는 주소와 설명용 UTM이 있는 주소를 비교합니다.
- 원본과 DOM의 canonical 개수·값을 기록합니다.
- 의도한 생성 주체를 제외한 중복 삽입을 제거한 뒤 같은 표본을 다시 검사합니다.
설계 예시로 서버는 운영 apex를 출력하지만 클라이언트 코드가 window.location을 그대로 canonical에 넣으면 미리보기나 캠페인 주소에서 값이 달라질 수 있습니다. 해결은 방문 주소를 현재 문서 정책의 검토 없이 복제하는 것이 아니라 문서의 대표 URL을 결정하는 공통 기준을 사용하는 것입니다. 단, 실제로 다른 문서를 가리키는 경로 변화까지 모두 무시해서는 안 됩니다.
완료를 확인합니다
직접 방문과 내부 이동 후에도 같은 문서의 대표 주소가 유지돼야 합니다. 원본과 DOM에 의도하지 않은 중복 태그가 없고 사이트맵·내부 링크도 같은 경로 정책을 사용해야 합니다. 검사 결과에는 로딩 시점과 이동 경로를 남겨 다른 담당자가 같은 문제를 재현할 수 있게 합니다.
다른 문제와 구분합니다
브라우저 DOM의 일관성을 확인한 것은 검색엔진의 대표 URL 선택을 확인한 것과 다릅니다. 콘텐츠 중복이나 리다이렉트·내부 링크의 신호가 남아 있으면 별도 점검이 필요합니다. canonical을 반복 변경하면서 검색 결과가 따라오길 기다리기보다 충돌하는 신호를 함께 정리합니다.
자주 묻는 질문
- HTML에는 맞는 canonical이 있으니 확인이 끝난 것 아닌가요?
- 로딩 뒤 다른 코드가 덮어쓰거나 추가하는지 확인해야 합니다. 최초 문서와 최종 DOM의 값이 의도적으로 다르지 않은지, 경로 이동 뒤에도 같은 문제가 없는지 검사합니다.
- canonical 태그가 두 개여도 같은 값이면 괜찮나요?
- 운영 기준은 중복된 관리 경로를 정리해 일관된 태그 하나를 제공하는 것으로 둡니다. 지금 값이 같더라도 다음 변경에서 서로 달라질 수 있으므로 생성 주체를 추적합니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.