블로그 운영에서 작성일은 모든 글 상단에 둡니다. 수정일 표시는 본문 내용·근거·링크를 실제로 고친 글에만 더합니다.

오탈자나 저작권 연도만 고쳤다면 수정일을 바꾸지 않습니다. 화면 날짜, 구조화 데이터(검색엔진이 읽는 페이지 정보 표기) 날짜, 사이트맵(사이트의 페이지 목록 파일) 날짜는 같은 값으로 맞춥니다.

Google이 보는 글 상단 날짜는 무엇인가요?

Google 문서는 바이라인 날짜(글 제목이나 작성자 근처에 보이는 날짜)를 설명합니다. 이 날짜는 페이지가 게시되거나 업데이트된 날짜를 Google이 추정한 값이라고 합니다.

Google은 이 날짜를 한 가지 요소로만 정하지 않고 여러 요소를 함께 본다고 밝힙니다. 화면 날짜든 구조화 데이터 날짜든 검색 결과에 반드시 표시되지는 않는다는 설명도 있습니다.

같은 문서는 사용자가 볼 수 있는 날짜를 페이지에 눈에 띄게 두라고 안내합니다. 날짜에는 「게시」「최종 업데이트」 같은 이름을 붙이라고 설명합니다.

화면 날짜를 다루는 단계에서 문서는 게시일과 최종 업데이트일 중 하나만 써도 되고 둘 다 써도 된다고 설명합니다. 구조화 데이터 단계에서도 datePublished와 dateModified 중 하나 또는 둘 다를 지정하라고 안내합니다. 따라서 수정일 표시 여부는 운영자가 정하는 항목입니다.

날짜를 바꾸는 행위에도 기준이 있습니다. Google의 유용한 콘텐츠 작성 문서는 검색엔진 우선 콘텐츠를 가려내는 자가 점검 질문을 둡니다. 그중 하나는 내용이 크게 바뀌지 않았는데 최신처럼 보이려고 페이지 날짜를 바꾸는지 묻는 질문입니다.

문서는 사이트를 최신처럼 보이게 하려는 목적으로 새 콘텐츠를 대량으로 추가하거나 오래된 콘텐츠를 대량으로 삭제하는지도 묻습니다. 이런 질문에 해당하면 콘텐츠를 만드는 방식을 다시 검토하라는 경고 신호로 봅니다.

한편 Google 순위 시스템 안내에는 최신성 시스템이 나옵니다. 최신 정보가 기대되는 검색어에서 더 새로운 콘텐츠를 보여 주는 시스템입니다. 두 설명을 함께 보면, 실무에서는 실제로 고친 내용이 있을 때만 수정일을 바꾸는 방법을 권합니다.

글 유형별로 상단에 둘 날짜는 무엇인가요?

먼저 글이 다루는 정보가 시간이 지나며 바뀌는지 봅니다. 특정 시점을 기록한 글은 작성일이 곧 정보의 기준일입니다. 절차·설정·정책처럼 바뀌는 정보라면, 독자는 수정일을 보고 지금도 맞는 내용인지 판단합니다.

아래 표는 Google 문서의 원칙을 글 유형에 적용한 실무 기준입니다.

글 유형예시표시 방식이유
시점 기록 글행사 후기, 인터뷰, 사내 소식, 발표 정리작성일만나중에 고치지 않는 글이라 작성 시점이 기준일입니다
개념·원칙 설명 글용어 풀이, 글쓰기 원칙작성일 기본, 고친 경우에만 수정일 추가바뀌는 일이 드물어, 고쳤을 때만 수정일이 의미를 가집니다
절차·설정 안내 글도구 설정 방법, 신청 절차, 화면 사용법작성일 + 수정일화면과 메뉴가 바뀌므로 독자가 최신 여부를 판단해야 합니다
수치·정책 인용 글요금, 규정, 공식 정책 요약작성일 + 수정일 + 본문 기준일 문장인용한 값이 언제 기준인지 따로 밝혀야 합니다
정기 갱신 글해마다 고쳐 쓰는 안내서작성일 + 수정일처음 쓴 날과 최근 고친 날을 함께 보여 이력을 전합니다

작성일을 지우고 수정일만 남기면 독자가 판단하기 어려워집니다. 오래 관리해 온 글인지 새로 쓴 글인지 구분되지 않기 때문입니다. 그래서 수정일은 작성일 옆에 함께 둡니다.

수치·정책 인용 글은 상단 날짜만으로 부족합니다. 해당 문단에 「요금 정보는 2026년 10월 기준입니다」처럼 기준일 문장을 함께 둡니다. 수정일은 글 전체가 마지막으로 바뀐 날이고, 기준일은 특정 정보가 유효한 시점입니다.

수정일을 바꾸는 수정은 어디까지인가요?

Google 사이트맵 문서는 lastmod 값을 설명합니다. lastmod는 사이트맵에 적는 마지막 수정 시각이며, 페이지의 마지막 중요한 업데이트를 반영해야 합니다. Google은 이 값이 일관되고 검증 가능하게 정확할 때만 사용한다고 밝힙니다.

문서가 드는 중요한 변경의 예는 주요 콘텐츠, 구조화 데이터, 링크의 변경입니다. 저작권 연도 변경은 중요한 변경이 아니라고 설명합니다. 화면의 수정일도 같은 선을 따르면 사이트 전체의 기준이 하나로 정리됩니다.

아래 표에서 1~3행과 마지막 행의 저작권 연도는 Google 문서가 드는 예입니다. 나머지는 같은 원리를 적용한 실무 판단입니다.

수정 내용수정일함께 할 일
설명·절차·결론 등 본문 내용 추가나 변경바꿈수정 기록에 바꾼 소제목을 적습니다
깨진 링크 교체, 내부 링크 추가바꿈바뀐 링크의 연결 대상을 확인합니다
구조화 데이터 수정바꿈화면 날짜와 값이 같은지 대조합니다
인용한 수치·정책·근거 문서 교체바꿈본문 기준일 문장도 함께 고칩니다
오탈자, 띄어쓰기, 문장 다듬기그대로 둠뜻이 달라지는 수정이면 바꿈으로 판단합니다
저작권 연도, 스킨·디자인 변경그대로 둠본문 정보와 관계없는 변경입니다

판단이 애매하면 하나만 묻습니다. 이전 내용을 읽은 독자가 지금 내용을 보고 다르게 행동할 수 있는지입니다. 그렇다면 수정일을 바꾸고, 아니라면 그대로 둡니다.

화면 날짜와 구조화 데이터·사이트맵 날짜를 맞추는 순서는 무엇인가요?

Article 구조화 데이터 문서는 두 날짜 항목을 정의합니다. datePublished는 글을 처음 게시한 날짜와 시각이고, dateModified는 가장 최근에 수정한 날짜와 시각입니다. 둘 다 ISO 8601(국제 표준 날짜 표기) 형식입니다.

이 문서에는 필수 속성이 없으며, 콘텐츠에 해당하는 속성을 넣으라고 안내합니다. 두 날짜 항목도 같은 안내를 따릅니다. 실무에서는 작성일만 두는 시점 기록 글에 dateModified를 넣지 않는 방식을 권합니다.

아래 순서로 대조합니다.

  1. 화면 날짜와 구조화 데이터 날짜가 같은지 봅니다. 바이라인 날짜 문서는 화면 값과 구조화 데이터 값의 날짜를 일치시키라고 안내합니다.
  2. 시각과 시간대를 확인합니다. 시각을 넣는다면 올바른 시간대를 함께 적으라는 것이 Google 문서의 안내입니다. 국내 블로그라면 +09:00입니다.
  3. 날짜가 글의 게시·수정을 뜻하는지 봅니다. Google 문서는 미래 날짜나 글이 다루는 사건·행사의 날짜를 쓰지 말라고 설명합니다.
  4. 상단의 다른 날짜를 줄입니다. 의도와 다른 날짜가 선택된다면 페이지의 다른 날짜를 일부 또는 모두 지우는 방안을 검토하라고 문서는 안내합니다.
  5. 사이트맵 lastmod를 확인합니다. Bing 웹마스터 블로그는 이 값이 사이트맵을 만든 날이 아니라 페이지를 마지막으로 수정한 날이어야 한다고 설명합니다. 날짜가 계속 오늘 날짜로 기록되면 Bing은 그 값의 타당성을 의심하고 무시할 수 있다고 밝힙니다.

블로그 도구가 저장할 때마다 수정일을 자동으로 바꾸는지도 확인합니다. 오탈자 하나에도 수정일이 바뀐다면, 위 표에서 「그대로 둠」으로 정한 수정과 실제 화면이 어긋납니다.

이 경우 수정일 칸을 직접 입력하게 바꿉니다. 직접 입력이 어렵다면 간단한 수정과 내용 수정을 저장 방식으로 구분합니다.

수정 내용을 남기는 기록 양식은 무엇인가요?

수정일만 바뀌고 무엇을 고쳤는지 보이지 않으면, 독자는 그 변경이 자기와 관계있는지 판단하기 어렵습니다. 실무에서는 상단 날짜와 함께 본문 끝에 짧은 수정 기록을 두는 방법을 권합니다.

상단 날짜 문안

  • 작성일만 둘 때: 「작성일 2026년 3월 10일」
  • 함께 둘 때: 「작성일 2026년 3월 10일 · 최종 수정일 2026년 10월 22일」

본문 끝 수정 기록 문안

예를 들어 가상의 ○○ 기업 블로그가 메일 발송 도구 설정 안내 글을 고쳤다면 다음처럼 적을 수 있습니다.

  • 「2026년 10월 22일 수정: 설정 화면의 메뉴 이름이 바뀌어 세 번째 소제목의 절차를 고쳤습니다.」
  • 「2026년 6월 2일 수정: 참고한 공식 도움말이 개정되어 요금 기준일을 바꿨습니다.」

내부 관리 대장 항목

항목적을 내용예시
글제목과 주소메일 발송 도구 설정 안내 / 글 주소
수정한 날실제로 고친 날짜2026-10-22
바꾼 부분소제목이나 문단 위치세 번째 소제목 절차 2~4번
바꾼 이유변경을 부른 사실설정 화면 메뉴 이름 변경
근거 문서확인한 공식 문서 이름과 확인일해당 서비스 공식 도움말, 2026-10-22 확인
수정일 갱신바꿈 또는 그대로 둠, 그 사유바꿈(본문 절차 변경)
확인자날짜 일치를 대조한 담당자웹 담당

여러 명이 함께 관리하는 블로그라면 이 대장이 기준 역할을 합니다. 담당자가 바뀌어도 같은 수정에 같은 판단이 나옵니다.

정리

  1. 발행한 글을 시점 기록 글과 바뀌는 정보를 다루는 글로 나누고, 유형별 표시 방식을 정합니다.
  2. 블로그 도구가 저장할 때 수정일을 자동으로 바꾸는지 확인하고, 직접 입력하는 방식으로 맞춥니다.
  3. 수정일을 바꾸는 기준(본문·근거·링크·구조화 데이터 변경)을 운영 기준 문서에 적습니다.
  4. 대표 글 다섯 편을 골라 화면 날짜, datePublished·dateModified, 사이트맵 lastmod가 같은 값인지 대조합니다.
  5. 다음 수정부터 본문 끝 수정 기록과 내부 관리 대장을 함께 채웁니다.

참고 자료