사이트맵 lastmod, 부정확하면 안 쓰는 게 낫다

결론부터 말하면 이렇다. lastmod(최종 수정일) 값이 정확하지 않다면, 아예 빼는 편이 낫다. 구글의 게리 일리예스가 2026년 7월 SNS에서 깨진 lastmod 값을 두고 있는 그대로 남긴 말이 바로 이 취지였다. 틀린 날짜는 안 쓰느니만 못하다는 것이 구글의 일관된 입장이다.

구글이 최근 정확히 뭐라고 했나?

2026년 7월, 한 SEO 담당자가 손상된 lastmod 값이 섞인 사이트맵을 두고 구글 게리 일리예스에게 질문하자 그는 "lastmod 없이 가는 편이 아마 나을 것이다. 최소한 용량이라도 아낄 수 있으니"라는 취지로 답했다.

이는 새로운 규칙이 아니라 기존 공식 문서의 재확인이다. 구글 서치 센트럴 문서는 오래전부터 "구글은 lastmod 값이 지속적이고 검증 가능하게 정확할 때 이를 참고한다"고 명시해 왔다. 여기서 "검증 가능"이란 구글이 사이트맵에 적힌 날짜를 실제 페이지 내용 변화와 대조해 사실 여부를 확인한다는 뜻이다.

구글 공식 문서: "값은 페이지의 주요 콘텐츠·구조화 데이터·링크 같은 중대한 변경 사항을 반영해야 하며, 저작권 연도 갱신 같은 사소한 변경은 해당하지 않는다."

부정확한 lastmod, 왜 손해로 이어지나?

핵심은 구글의 신뢰 판단이 URL 하나하나가 아니라 사이트맵 파일 전체 단위로 이뤄진다는 점이다. 몇 개 URL의 lastmod가 실제와 다르다는 것이 확인되면, 구글은 그 파일 전체의 lastmod 열을 통째로 불신하고 무시할 수 있다.

즉 40개 페이지 중 진짜 최근 수정된 것이 5개뿐이어도, 나머지 35개의 날짜가 부정확하면 그 5개의 진짜 정보까지 함께 신뢰를 잃는 셈이다. 정확한 날짜 몇 개보다, 전체가 일관되게 믿을 만한지가 더 중요하다.

흔한 실수 세 가지: 사이트맵을 재생성(빌드)할 때마다 날짜를 오늘로 찍는 것, 오탈자 수정에도 날짜를 갱신하는 것, 전체 페이지를 한 번에 오늘 날짜로 일괄 변경하는 것.

실제 수정일과 빌드 시점, 어떻게 구분하나?

핵심 원칙 하나뿐이다. "콘텐츠가 실제로 바뀌었는가?"에만 답하고, "지금 사이트맵을 다시 만드는 중인가?"는 무시한다. 아래 표로 구분한다.

상황	lastmod 처리
본문·구조화 데이터·주요 링크를 실제로 고침	그 날짜로 갱신
오탈자·사소한 문구만 손봄	기존 날짜 유지
배포·빌드만 다시 돌림(내용 변경 없음)	기존 날짜 유지
전체 페이지를 이유 없이 오늘 날짜로 일괄 변경	절대 하지 않음

이 사이트처럼 Next.js 같은 프레임워크로 블로그를 운영한다면, 글 파일의 frontmatter에 적힌 날짜를 그대로 lastmod로 쓰고, 빌드 시각과는 분리하는 방식이 안전하다. 워드프레스라면 Yoast SEO 같은 플러그인이 "게시물 수정" 이벤트에만 반응하도록 기본 설정돼 있어, 별도 손질 없이도 이 원칙을 따른다.

수동으로 사이트맵을 관리하는 경우가 문제다. 배포 스크립트에서 무조건 new Date()를 찍어 넣는 코드가 섞여 있다면, 겉보기엔 "매번 최신화되는 것"처럼 보여도 실제로는 구글의 신뢰만 깎아 먹는 함정이다.

지금 무엇부터 점검해야 하나?

세 가지만 확인하면 충분하다. 첫째, 사이트맵 안의 lastmod가 실제 페이지 수정일과 일치하는지 서너 개 페이지만 무작위로 대조해 본다. 둘째, 배포 파이프라인에서 lastmod를 빌드 시각이 아니라 콘텐츠 수정 시각에 연결했는지 코드를 확인한다. 셋째, 이미 값이 뒤죽박죽이라면 차라리 lastmod 태그 자체를 당분간 빼두는 선택도 고려한다.

lastmod가 없어도 사이트맵의 다른 기능(URL 발견)에는 지장이 없다. 다만 손상된 값을 그대로 두는 것보다는 확실히 낫다는 것이 구글의 일관된 메시지다.

사이트맵의 기본 구조와 만드는 법 자체가 궁금하다면 사이트맵(sitemap.xml)이란 글을 먼저 참고해 주시기 바랍니다. lastmod를 포함한 사이트맵 점검과 서치 콘솔 관리가 부담스러우시다면, 이루웹의 검색엔진최적화 서비스에서 함께 살펴봐 드리고 있습니다. 이루웹의 다른 서비스도 확인해 보시고, 궁금하신 점은 언제든 문의 남겨 주시기 바랍니다.