구글 검색 날짜 표시가 실제 발행일과 다르거나 아예 보이지 않는다면 먼저 날짜를 강제로 노출하는 기능이 없다는 점부터 이해해야 합니다. Google은 페이지에 보이는 날짜와 구조화 데이터 등 여러 신호를 종합해 검색결과의 날짜를 판단합니다. 따라서 목표는 특정 날짜를 보장하는 것이 아니라 독자와 검색엔진이 같은 의미로 해석하도록 신호를 정리하는 것입니다.
구글 검색 날짜 표시는 여러 신호로 결정된다는 점부터 확인한다
Google 공식 문서는 눈에 잘 보이는 날짜, datePublished·dateModified 구조화 데이터와 페이지의 다른 날짜 단서를 함께 사용한다고 설명합니다. 어느 하나만 넣는다고 결과가 정해지지는 않습니다. 먼저 공개 페이지에서 제목 가까이에 발행일과 수정일이 있는지, HTML 소스의 BlogPosting 값이 같은 시점을 가리키는지 확인합니다. 날짜가 정확해도 검색결과에 표시되지 않을 수 있다는 예외도 운영 판단에 포함해야 합니다.
발행일과 수정일의 역할을 분리한다
발행일은 글이 처음 공개된 시점, 수정일은 내용이 실질적으로 달라진 시점으로 나눕니다. 예를 들어 9월 1일 공개한 글에서 9월 3일 오탈자 한 글자만 고쳤다면 발행일을 유지하는 편이 자연스럽습니다. 반면 9월 10일에 요금, 신청 조건, 실행 절차를 다시 확인해 본문을 크게 고쳤다면 수정일을 9월 10일로 갱신할 근거가 생깁니다. 사소한 저장마다 수정일을 바꾸면 독자가 최신성의 의미를 판단하기 어려워집니다.
화면에 보이는 날짜와 구조화 데이터를 일치시킨다
실행 순서는 단순합니다. 첫째, 본문 상단에 ‘발행’과 ‘수정’이라는 라벨을 붙여 날짜 목적을 분명히 합니다. 둘째, JSON-LD의 datePublished와 dateModified를 ISO 8601 형식과 정확한 시간대로 기록합니다. 셋째, 화면의 날짜와 구조화 데이터가 같은 날을 가리키는지 비교합니다. 넷째, 사이트맵 lastmod를 쓴다면 실제 본문 변경 시점과 맞춥니다. ‘소상공인 웹사이트 구조화 데이터 점검법’과 ‘오래된 블로그 글 업데이트 방법’도 함께 보면 기술 신호와 편집 기준을 연결하기 쉽습니다.
실제 변경이 있을 때만 수정일을 갱신한다
수정일 갱신 기준을 팀 문서로 남기면 자동화가 날짜만 새것처럼 만드는 일을 막을 수 있습니다. 핵심 답변 변경, 공식 근거 교체, 가격·운영시간·신청 조건 수정, 오래된 화면이나 절차 전면 교체는 갱신 대상입니다. 맞춤법 교정, 공백 정리, 버튼 색 변경처럼 검색 의도에 대한 답이 달라지지 않은 작업은 보통 제외합니다. 변경 내역에 ‘무엇을 왜 바꿨는지’ 한 줄을 남기면 나중에 판단을 재현하기도 쉽습니다.
다른 날짜와 미래 날짜가 혼동을 만들지 않게 한다
행사일, 후기 작성일, 댓글일, 저작권 연도처럼 기사 날짜가 아닌 값이 제목 근처에 많으면 의미가 섞일 수 있습니다. 행사 날짜는 ‘행사 일정’처럼 별도 라벨과 영역으로 분리하고, 기사 발행일보다 앞세우지 않습니다. 아직 공개하지 않은 예약 글의 미래 날짜를 화면과 구조화 데이터에 미리 노출하는 것도 피합니다. 페이지를 열 때마다 dateModified가 현재 시각으로 바뀌는 구현, 화면은 9월 1일인데 JSON-LD는 9월 10일인 상태, 월·일만 적어 연도를 알 수 없는 표기는 대표적인 실패 조건입니다.
배포 후 소스·리치 결과·Search Console로 점검한다
배포 뒤에는 ① 페이지에 발행·수정 라벨이 보이는지 ② 소스의 datePublished·dateModified가 같은 날짜와 시간대를 쓰는지 ③ 대표 URL이 하나인지 ④ 리치 결과 테스트에서 Article 항목이 읽히는지 ⑤ 사이트맵 lastmod가 실제 변경과 맞는지 확인합니다. 그다음 Search Console URL 검사로 Google이 선택한 표준 URL과 최근 크롤링 상태를 살핍니다. ‘구글 검색어 페이지 불일치 점검법’처럼 검색어별 노출 URL도 함께 비교하면 날짜 문제가 아니라 대표 페이지 선택 문제인지 구분할 수 있습니다. 변경 후에는 즉시 결론을 내리지 말고 재크롤링과 검색결과 반영 시간을 두고 기록합니다.