게시일과 수정일을 정직하게 표기하는 법

한 줄 답: 날짜는 사실을 적는 칸입니다

게시일은 글을 처음 공개한 날입니다. 수정일은 내용을 실제로 고친 날입니다. 이 두 값을 화면에 보이는 날짜, HTML의 time 요소, JSON-LD의 datePublished와 dateModified, 사이트맵의 <lastmod>에 똑같이 적고, 아직 오지 않은 날짜는 어디에도 쓰지 않습니다. 이것이 이 가이드의 전부이고, 아래 내용은 이 원칙을 실제 사이트에서 지키는 방법입니다.

날짜는 작은 메타데이터처럼 보이지만 독자와 검색엔진 양쪽에 “이 정보가 언제 기준인가”를 알려 주는 중요한 신호 중 하나입니다. 요금표, 정책 해설, 제품 사양처럼 시간이 지나면 달라지는 내용일수록 날짜가 정확해야 독자가 스스로 판단할 수 있습니다. 반대로 날짜가 틀리면 내용이 맞아도 신뢰를 잃습니다.

Google이 공개한 날짜 지침

Google은 게시 날짜 영향 안내에서 날짜 표기에 관한 원칙을 밝히고 있습니다. 핵심만 추리면 다음과 같습니다.

지침	뜻
화면 날짜와 구조화 데이터 일치	사람이 보는 날짜와 JSON-LD 등에 적은 날짜가 서로 달라서는 안 됩니다.
미래 날짜 금지	아직 오지 않은 날짜나 페이지가 설명하는 행사 날짜를 게시일로 쓰지 않습니다.
시간대 표기 권장	날짜와 시각에 시간대를 함께 적는 편이 좋습니다.

두 번째 항목은 흔히 헷갈립니다. 예를 들어 10월 15일에 열리는 세미나를 9월 20일에 안내했다면 게시일은 9월 20일입니다. 세미나 날짜는 본문에 쓰면 되고, 게시일 칸에 넣으면 안 됩니다. 예약 발행 기능을 쓰다가 공개 전 날짜가 그대로 남는 경우도 같은 문제로 이어집니다.

시간대도 가볍게 넘길 일이 아닙니다. Google의 Article 구조화 데이터 문서는 시간대 정보가 없으면 Googlebot의 시간대를 기준으로 해석한다고 설명합니다. 한국 시간 새벽에 올린 글이 시간대 없이 기록되면 다른 날짜로 읽힐 수 있다는 뜻입니다. 날짜만 적을 때는 문제가 작지만, 시각까지 적는다면 +09:00을 붙이세요.

날짜만 올리는 갱신은 왜 피해야 하나

내용은 그대로 두고 수정일만 오늘로 바꾸는 방식은 손이 덜 가고 솔깃합니다. 목록 상단에 “최근 업데이트”로 보이고, 오래된 글도 새 글처럼 보이기 때문입니다.

Google은 이 행동을 유용한 콘텐츠 만들기 안내의 자가 점검 질문으로 다룹니다. 내용이 실질적으로 바뀌지 않았는데 새로워 보이려고 페이지 날짜를 바꾸고 있지 않은지 스스로 경계하라고 묻습니다. 뉴스 게시자를 대상으로 한 Google 뉴스 게시자 안내는 이런 날짜 조작을 지침 위반으로 적고 있습니다. 일반 검색에서는 점검 질문, 뉴스에서는 지침이라는 차이가 있지만 방향은 같습니다. 날짜는 실제 변경을 따라가야 합니다.

현실적인 판단 기준을 하나 두면 편합니다.

• 수정일을 바꾸는 변경: 수치나 가격 갱신, 절차 변경, 틀린 설명 정정, 새 절이나 예시 추가, 결론이 달라지는 수정
• 수정일을 그대로 두는 변경: 오탈자, 띄어쓰기, 디자인 변경, 광고나 배너 교체, 관련 글 목록 자동 갱신

애매할 때는 “독자가 이 변경을 알아야 하는가”를 물어보면 됩니다. 알아야 한다면 수정일을 바꾸고, 무엇이 바뀌었는지 한 줄 남기세요. 이 부분은 아래 변경 이력 절에서 다시 다룹니다.

날짜를 적는 네 곳

날짜는 한 페이지 안에서도 여러 곳에 들어갑니다. 한 곳만 고치면 나머지와 어긋나기 때문에, 네 위치를 모두 같은 원본 값에서 만들어야 합니다.

위치	읽는 대상	예시 값
화면에 보이는 날짜	독자	2026년 9월 23일
time 요소의 속성	브라우저, 크롤러	datetime="2026-09-23"
JSON-LD 날짜 속성	검색엔진	"dateModified": "2026-09-23"
사이트맵 <lastmod>	크롤러	<lastmod>2026-09-23</lastmod>

화면과 time 요소

독자가 읽는 날짜는 한국어 표기 그대로 두고, 기계가 읽을 값은 datetime 속성에 ISO 8601 형식으로 넣습니다.

<p class="article-dates">
  게시 <time datetime="2026-09-03">2026년 9월 3일</time> · 수정
  <time datetime="2026-09-23">2026년 9월 23일</time>
</p>

“게시”와 “수정”이라는 이름표를 함께 붙이는 것이 좋습니다. 날짜만 두 개 나열하면 독자는 어느 쪽이 무엇인지 모릅니다. 수정한 적이 없는 글이라면 수정일 줄을 빼거나 게시일과 같은 값을 두면 됩니다.

JSON-LD

Article 계열 타입에는 datePublished와 dateModified를 씁니다. 화면에 적은 날짜와 같은 값이어야 합니다.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "게시일과 수정일을 정직하게 표기하는 법",
  "datePublished": "2026-09-03T09:00:00+09:00",
  "dateModified": "2026-09-23T14:30:00+09:00"
}

시각까지 넣는다면 위처럼 +09:00을 붙이세요. 날짜만 넣어도 형식상 문제는 없습니다. 구조화 데이터의 다른 속성은 구조화 데이터 가이드에서 자세히 다룹니다.

사이트맵 lastmod

Google의 사이트맵 안내에 따르면 Google은 <lastmod> 값이 일관되고 확인 가능할 만큼 정확할 때 이를 사용합니다. 형식은 W3C Datetime이고, changefreq와 priority는 사용하지 않습니다.

<url>
  <loc>https://example.com/guides/publication-dates</loc>
  <lastmod>2026-09-23</lastmod>
</url>

여기서 중요한 단어는 “일관되고”입니다. 모든 URL의 lastmod가 매번 배포 시각으로 바뀐다면 이 값은 아무 정보도 주지 않습니다. 정확한 값을 모르는 페이지라면 차라리 <lastmod>를 빼는 편이 낫습니다. 애드브랜치도 가이드와 규칙 해설에는 본문의 수정일을 넣고, 정확한 수정일을 갖고 있지 않은 페이지에는 넣지 않는 방식을 씁니다. 사이트맵 전반은 sitemap.xml 가이드를 참고하세요.

자주 생기는 날짜 오류

날짜 오류는 대부분 사람이 아니라 시스템에서 생깁니다. CMS 설정, 빌드 스크립트, 서버 시간대가 조용히 잘못된 값을 만들어 냅니다.

수정일이 게시일보다 앞섬

데이터를 옮기거나 글을 복제할 때 자주 생깁니다. 옛 글을 새 주소로 다시 올리면서 게시일은 오늘로 바뀌고 수정일은 원래 값이 남는 식입니다. 수정일은 게시일과 같거나 그 뒤여야 합니다. 데이터 이전 작업 뒤에는 두 값을 나란히 놓고 한 번 훑어보세요.

서버 시간대가 다름

서버가 UTC로 돌고 있는데 시간대 없이 날짜만 저장하면, 한국 시간 오전 9시 이전에 저장한 글은 하루 전 날짜로 기록됩니다. 저장할 때 시간대를 포함하거나, 날짜를 만들 때 기준 시간대를 한 곳에서 명시하세요.

// 한국 시간 기준 날짜 문자열 만들기
const kstDate = new Intl.DateTimeFormat("sv-SE", {
  timeZone: "Asia/Seoul",
}).format(new Date());
// "2026-09-23"

빌드 시각을 수정일로 씀

정적 사이트에서 가장 흔한 실수입니다. 파일의 수정 시각이나 빌드 시각을 dateModified와 <lastmod>에 넣으면, 사이트를 다시 배포할 때마다 모든 페이지의 수정일이 바뀝니다. 내용은 그대로인데 날짜만 올라가는 셈이라 앞 절에서 본 문제와 결과가 같습니다. 수정일은 본문 데이터(예: 마크다운 frontmatter의 updatedAt)에 사람이 적은 값을 쓰세요.

미래 날짜가 남음

예약 발행 날짜가 그대로 들어가거나, 시간대 계산이 반대로 되어 하루 뒤 날짜가 찍히는 경우입니다. 템플릿에서 현재 시각보다 뒤의 날짜가 나오면 빌드를 멈추게 하는 검사를 하나 넣어 두면 안전합니다.

형식이 제각각

2026.9.23, 23/09/2026, 9월 23일 같은 값은 사람에게는 읽혀도 기계가 해석하지 못할 수 있습니다. 화면 표기는 자유롭게 두되, datetime 속성과 JSON-LD, <lastmod>에는 2026-09-23 같은 ISO 형식만 쓰세요.

변경 이력을 한 줄로 남기기

수정일만 바뀌어 있으면 독자는 무엇이 달라졌는지 알 수 없습니다. 본문 끝이나 날짜 옆에 변경 이력을 짧게 남기면 수정일의 근거가 함께 보입니다. 거창할 필요는 없습니다. 날짜와 한 줄 설명이면 충분합니다.

애드브랜치 가이드는 frontmatter에 변경 이력을 적고, 그 값으로 화면의 이력 목록을 만드는 방식을 씁니다.

updatedAt: "2026-09-23"
revisions:
  - date: "2026-09-23"
    note: "사이트맵 lastmod 사용 조건과 예시를 추가했습니다."
  - date: "2026-09-13"
    note: "sitemap index 처리 설명을 고쳤습니다."

좋은 변경 이력 한 줄에는 세 가지가 들어갑니다.

1. 무엇을 바꿨는지(절 이름이나 항목)
2. 어떻게 바꿨는지(추가, 정정, 삭제)
3. 필요하면 왜 바꿨는지(정책 변경, 오류 제보)

“내용 업데이트”처럼 아무 말도 하지 않는 문장은 피하세요. 이력의 가장 최근 날짜와 updatedAt이 같은지도 확인하면 좋습니다. 둘이 다르면 어느 한쪽이 틀린 것입니다. 오래된 글을 다시 다듬는 절차는 콘텐츠 갱신 가이드에서 다룹니다.

애드브랜치 검사기가 보는 날짜 항목

애드브랜치 검사기는 공개 HTML과 사이트맵을 읽어 날짜와 관련된 세 가지 항목을 확인합니다. 각 항목은 표기의 형식과 일관성을 보는 것이며, 날짜가 실제 변경을 반영하는지까지 판단하지는 않습니다.

규칙 ID	영역	배점	확인 내용
geo-c03-dates	GEO 엔티티 명확성	2	ISO 형식의 게시 또는 수정 날짜가 있는지
geo-c07-date-integrity	GEO 엔티티 명확성	1	날짜가 해석 가능하고, 미래가 아니며, 역전되지 않았는지
sitemap-lastmod	SEO 검색 접근성	1	사이트맵에서 현재 URL의 <lastmod>가 올바른지

geo-c03-dates

time 요소의 datetime, article 날짜 메타, JSON-LD의 datePublished, dateModified, dateCreated에서 ISO 형식 날짜를 찾습니다. 하나라도 있으면 통과, 없으면 경고입니다. time 요소가 있어도 속성 값이 ISO 형식이 아니면 날짜를 찾지 못한 것으로 봅니다.

geo-c07-date-integrity

찾은 날짜의 정합성을 봅니다. 다음 중 하나에 해당하면 경고입니다.

• 해석할 수 없는 날짜 값이 있음
• 검사 시각에서 24시간을 더한 시점보다 뒤의 날짜가 있음
• dateModified가 datePublished보다 24시간 넘게 앞섬

24시간 여유는 시간대 차이로 생기는 정상적인 하루 어긋남을 경고로 잡지 않기 위한 값입니다. 날짜가 전혀 없으면 이 항목은 판정하지 않고(해당 없음), 날짜가 없다는 사실은 geo-c03-dates가 다룹니다.

sitemap-lastmod

검사기가 읽은 사이트맵에서 현재 URL 항목의 <lastmod>를 봅니다. 값이 없거나, W3C Datetime 형식이 아니거나, 미래 날짜이면 경고입니다. 사이트맵을 읽지 못했으면 판단 불가로, 읽은 파일이 sitemap index이거나 현재 URL이 목록에 없으면 해당 없음으로 처리합니다. 검사기는 index의 하위 파일까지 따라가지 않기 때문입니다.

각 규칙의 판정 기준은 규칙 목록에서, 점수 계산 방식은 검사 방법론에서 확인할 수 있습니다.

점검 순서

처음 정리한다면 이 순서로 보세요.

1. 날짜의 원본을 하나로 정합니다. CMS 필드든 frontmatter든, 화면과 JSON-LD와 사이트맵이 모두 여기서 값을 가져오게 합니다.
2. 빌드 시각이나 파일 수정 시각이 수정일로 쓰이는 곳을 찾아 없앱니다.
3. 시간대 기준을 Asia/Seoul 또는 +09:00으로 명시합니다.
4. 수정일이 게시일보다 앞서는 글과 미래 날짜가 들어간 글을 찾아 고칩니다.
5. 실제로 내용을 고칠 때만 수정일을 바꾸고, 변경 이력을 한 줄 남깁니다.
6. 대표 페이지 몇 개를 검사기로 돌려 세 규칙의 결과를 확인합니다.

자주 묻는 질문

수정일을 화면에 꼭 보여 줘야 하나요

필수는 아니지만 권합니다. 구조화 데이터에만 수정일이 있고 화면에는 게시일만 있으면, 독자가 보는 날짜와 기계가 읽는 날짜가 달라집니다. Google도 화면 날짜와 구조화 데이터 날짜를 맞추라고 안내합니다. 두 날짜를 모두 보여 주고 이름표를 붙이는 방식이 가장 오해가 적습니다.

오탈자만 고쳤는데 수정일을 바꿔도 되나요

바꾸지 않는 편이 맞습니다. 수정일은 독자가 알아야 할 내용 변경을 알리는 값입니다. 오탈자나 디자인 변경까지 수정일에 반영하면, 정말 중요한 변경이 있을 때 수정일이 주는 신호가 약해집니다. 판단이 어렵다면 변경 이력에 적을 만한 일인지 생각해 보세요.

게시일을 모르는 오래된 글은 어떻게 하나요

확인할 수 있는 가장 이른 기록을 찾아 쓰세요. 백업, 배포 기록, 저장소 이력 같은 근거가 있으면 그 날짜를 씁니다. 근거가 전혀 없다면 게시일을 추측해서 채우기보다, 내용을 다시 검토한 날을 수정일로 두고 게시일 표기는 확인될 때까지 비워 두는 편이 정직합니다.

관련 가이드

• 구조화 데이터 가이드
• sitemap.xml 만들기와 제출하기
• 오래된 콘텐츠를 갱신하는 법
• GEO 점검 체크리스트