병원 칼럼의 작성일·수정일·출처 확인일, 한 날짜로 덮어쓰지 않습니다

오래된 병원 칼럼을 다시 읽고 날짜만 오늘로 바꾸면 독자는 내용까지 새로 검토됐다고 받아들일 수 있습니다. 처음 공개한 날, 내용을 고친 날, 출처를 다시 확인한 날을 구분해 기록하는 것이 관리의 출발점입니다. 무엇을 했는지 설명하지 못하는 최신 날짜는 검토 이력을 대신하지 못합니다.

독자에게 보이는 날짜는 실제 작업을 설명해야 합니다

Google은 페이지의 게시일과 수정일을 표시할 수 있으며, 그 날짜는 글에서 다루는 사건의 날짜가 아니라 페이지의 게시 또는 수정 날짜여야 한다고 안내합니다. 화면과 구조화된 데이터의 날짜도 서로 일관되게 제공하는 것이 좋습니다. Google의 페이지 날짜 안내

예를 들어 제도가 시행되는 날짜를 글의 발행일로 넣으면 문서의 시점과 제도의 시점이 섞입니다. 본문에는 적용 시점을 설명하고, 글 자체의 작성·수정 기록은 따로 남겨야 합니다.

출처 확인일은 내부 편집 관리에도 필요합니다. 다만 출처 링크가 열린다는 사실만 확인한 것과 내용의 기준이 여전히 유효한지 대조한 것은 다릅니다. 확인 범위를 적어야 다음 검토자가 같은 일을 다시 추측하지 않습니다.

같은 날 수행한 세 가지 작업을 구분하는 예시

10월 1일 발행한 글을 10월 26일 검토했다고 가정하겠습니다. 첫 작업은 출처 페이지가 열리는지 확인하는 일, 두 번째는 출처의 설명과 본문이 일치하는지 대조하는 일, 세 번째는 달라진 절차를 본문에 반영하는 일입니다. 이는 설명용 일정입니다.

링크만 열어봤다면 '링크 접속 확인'으로 기록합니다. 내용까지 대조했고 바뀐 부분이 없다면 '출처 내용 재확인, 본문 변경 없음'으로 남길 수 있습니다. 실제 절차를 고쳤다면 어떤 절차가 바뀌었는지와 수정일을 기록합니다.

세 작업의 결과를 모두 '2026년 10월 26일 최신화'라는 한 줄로 덮으면 검토 깊이를 알 수 없습니다. 특히 본문에 여러 출처가 있다면 한 출처를 확인한 날짜를 글 전체 근거의 확인일처럼 쓰지 않습니다.

사이트맵의 수정일도 자동 실행일과 구분합니다

사이트를 다시 빌드한 날짜와 글 내용이 실질적으로 바뀐 날짜는 같지 않을 수 있습니다. 모든 칼럼의 수정일을 배포 시각으로 바꾸면 실제로 어떤 글이 갱신됐는지 구분하기 어렵습니다.

Google은 사이트맵의 lastmod 값을 정확하고 검증 가능하게 유지하며 페이지의 마지막 중요한 변경 시점을 반영하도록 안내합니다. 단순한 실행 시각을 넣는 습관보다 콘텐츠 변경 기록에서 날짜를 가져오는 방식이 관리 목적에 맞습니다. Google 사이트맵 작성 안내

오탈자 수정과 결론을 바꾸는 내용 수정을 같은 방식으로 취급할지는 편집 기준으로 정할 수 있습니다. 다만 실제로 하지 않은 검토나 변경을 했다고 표시해서는 안 됩니다. 날짜 표시를 바꾼다고 검색 순위 상승이 보장되는 것도 아닙니다.

변경 이력에는 수정한 문장보다 판단 이유를 남깁니다

대장에는 글 주소, 확인한 근거, 확인 범위, 변경 내용, 수정 담당자, 다음 검토 조건을 기록합니다. '수정 완료'만 적기보다 '신청 절차가 바뀌어 세 번째 단계를 교체'처럼 독자에게 미치는 영향을 설명하는 편이 좋습니다.

출처가 없어졌다면 새 근거를 확보할 때까지 해당 문장의 확정적인 표현을 재검토합니다. 과거 기준을 소개하는 글이라면 당시 기준이라는 표시를 유지하고 현재 기준처럼 읽히지 않게 해야 합니다. 중복 글 통합과 기존 글 수정의 구분도 갱신 대장을 정리할 때 함께 사용할 수 있습니다.

출처 확인일: 2026-10-26. 날짜 관리표는 편집 운영 제안이며, 법령의 적용 시점 자체를 판정하는 설명은 아닙니다.