글을 고쳤는데 사이트맵에는 예전 날짜가 남아 있습니다. 어느 쪽을 오늘로 바꿔야 할까요? 먼저 실제로 무엇을 언제 수정했는지 확인해야 합니다. 페이지를 다시 저장하거나 사이트맵을 생성한 시간이 곧 콘텐츠의 수정 시각은 아닙니다.
lastmod는 파일을 만든 날이 아니라 페이지를 고친 날입니다
Sitemaps 프로토콜의 URL 항목에서 lastmod는 해당 페이지의 마지막 수정 시점을 나타내며 선택 항목입니다. Google은 사이트맵 작성 안내에서 일관되고 확인 가능한 값일 때 이를 사용한다고 설명합니다. 본문·구조화 데이터·링크의 중요한 변경은 포함될 수 있지만, 푸터 저작권 연도만 바뀐 경우는 같은 의미의 변경이 아닙니다.
수정일을 정확히 만들 수 없다면 매일 현재 날짜를 넣기보다 생성 근거를 먼저 정리합니다. 검색로봇의 방문을 유도하려고 내용과 무관하게 날짜만 바꾸는 방식은 독자에게도 실제 변경 시점을 알려 주지 못합니다.
한 URL에서 날짜가 나오는 곳을 나란히 놓습니다
다음은 9월 26일 발행한 가상 안내문에 10월 4일 배송 조건을 보강한 예입니다. 날짜를 비교할 때 최초 발행일과 수정일을 같은 칸에 놓지 않습니다.
| 출력 위치 | 예시 값 | 뜻 |
|---|---|---|
| 화면의 발행일 | 2026-09-26 | 최초 공개일 유지 |
| 화면의 수정일 | 2026-10-04 | 배송 조건을 보강한 날 |
| BlogPosting dateModified | 2026-10-04T11:30:00+09:00 | 같은 변경 시각을 한국 시간으로 표현 |
| XML URL의 lastmod | 2026-10-04T02:30:00Z | 같은 시각을 UTC로 표현 |
마지막 두 문자열은 다르지만 같은 순간입니다. +09:00과 Z를 제거한 뒤 날짜 글자만 비교하면 자정 근처의 정상 데이터를 오류로 잡을 수 있습니다. 시각을 포함한 값은 시간대를 적용해 비교하고, 날짜만 제공한 값은 그 사이트가 쓰는 날짜 기준도 확인합니다.
Google의 발행일 표시 안내는 화면의 날짜와 대응되는 구조화 데이터 값이 일관되도록 권고합니다. 기사에 등장하는 행사 날짜를 글의 발행일로 넣거나, 본문은 그대로인데 발행일을 최신으로 바꾸는 것은 피해야 합니다.
모든 URL이 같은 날짜라면 생성 경로를 확인합니다
글마다 수정 시점이 다른데 XML 값이 모두 같다면 사이트맵 생성 코드에 날짜가 고정됐거나 배포 시간을 모든 URL에 넣는지 살펴봅니다. 반면 특정 글 하나만 예전 날짜라면 해당 글이 다른 데이터 원본에 연결되어 있거나 캐시에 이전 응답이 남은 경우부터 확인할 수 있습니다. 이 구분은 조사 순서를 정하는 단서이지, 화면만 보고 원인을 확정하는 규칙은 아닙니다.
- 문제를 재현할 URL 하나와 실제 내용 변경 기록을 고릅니다.
- 화면 수정일과 JSON-LD의
dateModified를 읽습니다. - XML에서 정확히 같은
loc에 붙은lastmod를 찾습니다. - 각 값을 만드는 데이터 필드와 캐시 적용 구간을 확인합니다.
- 하나를 고친 뒤 다른 날짜의 URL도 비교해 전체가 같은 값으로 덮이지 않았는지 봅니다.
사이트맵이 여러 파일로 나뉘어 있으면 한 단계 더 내려가야 합니다. 사이트맵 인덱스의 lastmod는 하위 사이트맵 파일의 수정 시점이고, 그 안의 URL별 lastmod와 대상이 다릅니다. 인덱스만 보고 개별 글 날짜가 맞다고 판단하지 않습니다.
날짜의 원본을 하나로 정하고 표시를 파생합니다
화면, 구조화 데이터, XML에 날짜를 각각 손으로 적으면 한 곳만 바꾸기 쉽습니다. 콘텐츠 관리 계층에서 의미 있는 변경 시각을 정하고 세 출력이 그 값을 읽도록 설계하는 편이 관리하기 쉽습니다. 모든 CMS의 기본 수정 필드가 곧 이 의미를 갖는 것은 아니므로, 단순 저장·자동 처리에서도 바뀌는 필드인지 확인해야 합니다.
아래 XML은 위 가상 안내문의 예입니다. 날짜를 직접 입력하는 코드 조각을 모든 페이지에 복사하라는 뜻이 아니라, 생성 결과에서 무엇이 연결되어야 하는지 보여 줍니다.
<url>
<loc>https://example.com/guides/delivery/</loc>
<lastmod>2026-10-04T11:30:00+09:00</lastmod>
</url>정확한 시각을 보존하지 않았다면 추측한 시간을 채우지 말고 확인 가능한 날짜 범위와 운영 기록을 사용합니다. 발행일을 수정일로 덮지 않고, 수정 내용의 성격은 오류·보강·정책 변경의 정정 기록과 함께 관리합니다.
캐시를 지우기 전에 어느 응답이 오래됐는지 봅니다
원본에서는 바뀌었는데 CDN이나 페이지 캐시가 이전 XML을 제공할 수 있습니다. HTML과 XML의 응답을 같은 시각에 저장하고 캐시 관련 응답 헤더와 내용을 비교합니다. 질의 문자열을 붙였다고 항상 캐시를 우회하는 것은 아니므로 해당 캐시 설정도 확인합니다. 원인을 모른 채 글을 다시 저장하면 최초 문제를 추적하기 어려워질 수 있습니다.
날짜가 정리되어도 사이트맵에 없는 예약 글, 삭제된 주소, 대표 주소가 다른 글은 별도로 다뤄야 합니다. 예약 시각과 실제 공개 상태 확인에서 다루듯 공개 여부와 발견 경로는 서로 다른 확인입니다. 정확한 lastmod는 변경 정보를 전달하는 방법이며, 그 자체로 색인이나 검색 노출을 보장하지 않습니다.
프로토콜과 Google 원문은 2026년 10월 4일 확인했습니다. 날짜 표와 example.com URL은 설명용 예제입니다.