날짜가 생성되는 지점을 찾습니다
사이트맵 함수, CMS의 수정 필드, 파일 변경 시각과 Git 커밋 시각 중 무엇을 쓰는지 확인합니다. 현재 시간을 생성하는 코드가 있으면 해당 값이 모든 URL에 들어가는지 봅니다. 서버나 빌드 도구가 파일을 복사하면서 변경 시각을 다시 만드는 경우도 있으므로 원본 콘텐츠와 산출물의 파일 시각을 혼동하지 않습니다.
같은 내용의 두 빌드를 비교합니다
콘텐츠를 수정하지 않은 상태로 두 번 빌드하고 URL별 lastmod를 대조합니다. 임시 산출물을 지우고 다시 생성했을 때 날짜가 달라지는지도 확인합니다. 비교표에는 URL, 원본 콘텐츠 식별자, 본문 변경 여부, 이전 날짜와 새 날짜를 적습니다. 파일 전체의 순서가 바뀐 차이와 날짜 값의 차이를 구분해서 읽습니다.
갱신의 기준을 정합니다
- 문서의 고유 설명·조건·예시를 바꾸는 변경을 식별합니다.
- CMS나 소스 데이터에서 해당 변경의 날짜를 안정적으로 가져옵니다.
- 공통 템플릿·푸터·빌드 환경 변경을 어떻게 처리할지 정합니다.
- 화면에 보이는 수정일과 사이트맵의 날짜가 서로 다른 의미를 갖지 않게 설명합니다.
설명용으로 콘텐츠 데이터가 unchanged이고 배포 도구만 바뀌었다면 문서 전체를 오늘 수정한 것으로 표시하지 않는 기준을 사용할 수 있습니다. 반대로 서비스 조건의 핵심 부분이 바뀌면 관련 문서의 설명도 검토하고 그 변경을 반영합니다. 단순히 Git 저장소의 마지막 커밋 하나를 모든 문서에 넣으면 두 상황을 구분하기 어렵습니다.
완료를 검증합니다
변경 없는 재빌드에서는 날짜가 안정적으로 유지되고, 실제 문서 한 편을 고치면 의도한 대상만 갱신되는지 확인합니다. 삭제·통합한 문서의 URL이 날짜만 바뀐 채 사이트맵에 남지 않는지도 봅니다. 날짜 필드가 없을 때 임의의 과거·미래 값을 채우기보다 운영 기준에 맞는 처리 방식을 선택합니다.
운영자가 함께 남길 기록
수정일 기준, 데이터 출처, 예외 처리와 검증 도구를 문서화합니다. 날짜의 정확성만으로 페이지가 색인되거나 재수집된다고 보고하지 않습니다. 콘텐츠가 실제로 유용해졌는지는 변경 내용과 사용자 질문 해결 여부로 검토하고 검색 처리 결과는 별도 관찰 항목으로 둡니다.
자주 묻는 질문
- 새로운 날짜일수록 검색에 유리한가요?
- 날짜만 새로 적는 것을 콘텐츠 개선으로 취급하지 않습니다. 방문자가 확인할 수 있는 변경과 날짜의 관계를 유지하고, 재배포를 내용 갱신으로 표시하는 관행은 피합니다.
- 푸터를 고치면 모든 문서의 날짜도 바꿔야 하나요?
- 공통 UI 변경과 문서의 핵심 답변 변경을 구분하는 운영 기준을 세웁니다. 무엇을 lastmod에 반영할지 문서화하고 같은 종류의 변경에 일관되게 적용합니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.