기술 운영
사이트맵, 캐노니컬, lastmod를 함께 관리하는 법
세 신호는 하나의 대표 URL에 맞춥니다
사이트맵, 캐노니컬, lastmod를 함께 관리하는 핵심은 동일한 콘텐츠에 대해 하나의 대표 HTTPS URL과 실제 변경일을 일관되게 가리키는 것입니다. 사이트맵은 발견할 URL 목록을 제공하고, rel canonical은 중복·유사 페이지 중 선호 URL을 알리며, lastmod는 그 URL의 의미 있는 최종 변경 시점을 전달합니다.
세 값을 별도 도구에서 수동 관리하면 쉽게 충돌합니다. 콘텐츠 레코드의 대표 URL과 수정일을 단일 원본으로 두고 페이지 head와 사이트맵을 같은 배포에서 생성하는 방식이 안전합니다.
먼저 대표 URL을 결정합니다
프로토콜, 호스트, 경로 끝 슬래시, 추적 매개변수처럼 같은 본문에 여러 URL이 생기는 지점을 목록화합니다. 그중 사용자에게 지속적으로 제공할 URL을 고르고 내부 링크, 리디렉션, 페이지의 self-referential canonical을 같은 방향으로 맞춥니다.
Google의 캐노니컬 지정 공식 안내는 리디렉션과 rel canonical, 사이트맵 포함을 서로 강도가 다른 신호로 설명하며, 사이트 소유자의 선호가 절대 명령은 아니라고 밝힙니다. 따라서 충돌하는 신호를 쌓지 않는 것이 우선입니다.
사이트맵에는 대표 URL만 담습니다
사이트맵에는 검색에서 다루기를 원하는 대표 절대 URL을 담고, 리디렉션 대상이나 매개변수 중복 URL은 제외합니다. Google의 사이트맵 작성 공식 문서도 완전한 절대 URL 사용과 대표 URL 중심의 구성을 안내합니다.
- 콘텐츠 원본에서 공개 상태와 대표 URL을 읽습니다.
- 페이지가 성공 응답하고 canonical과 일치하는지 검사합니다.
- 사이트맵을 생성한 뒤 중복 URL과 다른 호스트를 탐지합니다.
- 배포된 파일을 다시 요청해 캐시된 이전 버전이 아닌지 확인합니다.
실제 본문 변경에만 lastmod를 갱신합니다
lastmod는 빌드 시간이나 사이트맵 생성 시간을 매번 넣는 칸이 아닙니다. 핵심 본문, 정책, 가격, 구조화된 사실처럼 페이지 의미가 바뀐 날짜를 기록하고, 단순 배포나 주변 레이아웃 변경은 조직의 명확한 기준에 따라 제외합니다.
공식 사이트맵 문서는 lastmod 값이 지속적으로 정확하고 검증 가능할 때 사용된다고 설명합니다. 수정 이유와 승인자를 변경 이력에 남기면 날짜가 실제 페이지 변경과 맞는지 나중에 검증할 수 있습니다.
신호는 수집과 노출을 보장하지 않습니다
사이트맵 제출은 크롤링이나 색인을 보장하지 않으며, 지정한 canonical도 검색 시스템이 반드시 선택해야 하는 명령은 아닙니다. lastmod 역시 콘텐츠 품질이나 최신성을 자동으로 증명하지 않습니다.
목표는 세 신호를 조작해 노출을 보장하는 것이 아니라, 공개한 URL과 변경 사실을 모순 없이 설명하는 것입니다.
성과 평가는 제출 성공만 보지 말고 대표 URL의 실제 응답, 내부 링크, 색인 보고서와 콘텐츠 품질을 별도로 검토합니다.
URL 신호 체크리스트
- 콘텐츠마다 하나의 대표 HTTPS URL이 정해졌나요?
- 내부 링크, 리디렉션, canonical과 사이트맵이 같은 URL을 가리키나요?
- 사이트맵에서 중복·오류·비공개 URL을 제외했나요?
- lastmod가 실제 의미 있는 변경일과 일치하나요?
- 배포 후 페이지 head와 사이트맵 응답을 함께 검사했나요?