충돌을 재현할 URL 묶음 만들기
주소창에 보이는 한 URL만 적으면 www, 쿼리 또는 끝 슬래시 변형을 놓칠 수 있습니다. 문제가 보고된 주소와 운영팀이 의도한 대표 주소를 먼저 두 열에 적습니다. 각각의 최초 상태 코드, 최종 도착 주소, 원본 HTML의 canonical, 사이트맵 포함 여부를 별도 열로 남깁니다. 로그인 세션이나 로컬 개발 서버의 결과를 운영 응답과 섞지 않습니다.
태그보다 먼저 대표 문서를 결정하기
대표 문서는 서버가 정상 본문을 제공하고 방문자가 실제로 사용할 주소여야 합니다. 임시 미리보기나 리다이렉트 경유 주소를 선택하면 태그 수정 뒤에도 다른 신호가 계속 엇갈립니다. 콘텐츠 담당자는 어느 문서가 최신 답을 담는지, 개발 담당자는 어느 경로를 장기 유지할지 확인합니다. 비슷한 두 페이지의 대상 독자와 제공 정보가 다르면 중복이라는 이유만으로 무조건 합치지 않습니다.
배포 결과에서 네 신호를 대조하기
- 원본 응답의 head에서 canonical이 하나이며 절대 URL인지 확인합니다.
- 해당 페이지로 들어오는 메뉴·관련 글 링크가 대표 경로를 사용하는지 찾습니다.
- 사이트맵에 대표 주소가 들어 있고 폐기한 복사본이 빠졌는지 검사합니다.
- 영구 폐기하기로 한 변형 주소는 적절한 최종 문서로 이동하는지 확인합니다. 별개의 답을 가진 페이지까지 같은 곳으로 보내지 않습니다.
예를 들어 대표 문서를 /guides/example/로 정했는데 사이트맵에는 /guides/example?view=full이 남아 있다면 사이트맵 생성 원본도 수정 대상입니다. HTML만 수동으로 고치면 다음 빌드에서 다시 충돌할 수 있습니다. 이 주소는 구조를 설명하기 위한 가정이며 현랩의 실제 문서 경로를 의미하지 않습니다.
완료 판정과 변경 기록
원본 HTML, 렌더링 후 DOM, 사이트맵, 주요 내부 링크가 같은 대표 주소를 사용하는 결과를 저장합니다. 새 대표 주소가 200을 반환하고 본문이 누락되지 않았는지도 함께 확인합니다. 변경 전후 비교표에는 날짜·배포 식별자·검사 도구·담당자를 남깁니다. 검색 결과에 아직 이전 주소가 보인다는 이유만으로 며칠 간격으로 대표 주소 정책을 다시 뒤집지 않습니다.
이 점검으로 설명하지 못하는 문제
신호가 일치해도 내용이 충분하지 않거나 접근이 차단되면 별도 문제가 남습니다. canonical은 부족한 본문을 보완하는 기능이 아닙니다. 다른 언어, 별도 상품, 로그인 후 개인 화면처럼 목적이 다른 URL은 문서 성격부터 판단해야 합니다. 완료 보고는 대표 주소 신호 정리와 실제 색인 상태를 나눠 적습니다.
자주 묻는 질문
- canonical을 바꾸면 검색 결과 주소도 즉시 바뀌나요?
- 그렇게 판단하지 않습니다. 변경한 신호의 일치 여부는 바로 검증할 수 있지만 검색엔진의 재수집과 대표 주소 선택은 별도 과정입니다. 변경일과 검사한 URL을 기록하고 같은 조건으로 다시 확인합니다.
- 검색어가 다른데 본문이 같은 페이지는 어떻게 하나요?
- 검색어만 바꾼 복사본을 늘리기보다 방문자가 실제로 다른 답을 필요로 하는지 검토합니다. 답과 다음 행동이 같으면 대표 문서로 통합하고 내부 링크도 그 문서로 모읍니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.
