갱신일과 낡은 글 — 최신성을 관리하는 기준 만들기

갱신일 표시를 스크립트로 매일 바꾸는 방식은 최신성 관리가 아닙니다. 내용이 그대로인데 날짜만 바뀌면, 나중에 어떤 글이 실제로 손봐야 하는 글인지 판단할 근거가 사라집니다.

관리해야 하는 것은 날짜 문자열이 아니라 내용이 지금도 맞는지입니다.

갱신이 필요하다는 네 가지 신호

1. 인용한 정책이나 공식 문서가 개정됐습니다. 플랫폼 정책, 법령, 요금 체계를 인용한 글은 원본이 바뀌면 그 즉시 틀린 글이 됩니다. 이 경우는 주기와 무관하게 바로 고칩니다.
2. 수치의 기준 시점이 1년 이상 지났습니다. "2025년 기준"이 적힌 문장은 지금 읽는 사람에게 판단 근거가 되지 못합니다.
3. 제품 화면이나 기능 이름이 바뀌었습니다. 안내 문서에서 가장 자주 어긋나는 항목입니다. 화면에 없는 버튼 이름이 적힌 문서는 고객 문의를 만듭니다.
4. 그 주제로 들어오는 질문이 달라졌습니다. 같은 주제인데 사람들이 묻는 지점이 옮겨간 경우입니다. 이때는 날짜가 아니라 헤딩 구성을 고쳐야 합니다.

갱신·통합·보관 중 어디로 보내는가

가장 자주 필요한 처리는 통합입니다. 같은 주제로 2~3년에 걸쳐 세 편을 쓴 경우, 세 주소가 각자 부분적인 답을 담고 있어 어느 것도 완결된 문서가 아닙니다. 하나로 합치면 그 주소가 그 주제의 문서가 됩니다.

주의할 점은 주소를 지우지 않는 것입니다. 합친 뒤 나머지를 삭제하면 외부 링크와 공유된 주소가 404가 됩니다. 301로 넘겨야 합니다.

날짜를 표시하는 세 자리

• 본문 상단 표시. 사람이 보는 자리입니다. 게시일과 수정일을 함께 적습니다.
• 구조화 데이터. 기사 유형 페이지의 datePublished, dateModified입니다.
• sitemap의 lastmod. 파일이 자동 생성되면 실제 수정 시점과 맞는지 확인합니다.

세 자리 값이 서로 다른 경우가 흔합니다. 본문에는 지난달로 적혀 있고 구조화 데이터에는 3년 전 날짜가 남아 있는 상태입니다. 셋을 같은 값으로 맞추는 것이 이 항목의 실제 작업입니다.

운영 주기

주기는 콘텐츠 종류에 따라 다르게 잡습니다. 아래는 일반적인 운영 기준이며, 검색 성과가 보장되는 수치는 아닙니다.

• 정책·요금·기능 안내: 변경 시점에 즉시. 별도 주기를 두지 않습니다.
• 실무 가이드: 6개월마다 확인. 인용 문서와 화면 이름을 봅니다.
• 개념 설명: 12개월마다 확인. 대개 수치와 예시만 손보면 됩니다.
• 사례·발표 자료: 갱신하지 않고 시점을 명시합니다. "2026년 3월 기준"

오늘 할 일

블로그나 자료실 목록을 수정일 기준으로 정렬해 오래된 순서로 열 개만 열어 보십시오. 위의 네 가지 신호 중 하나라도 걸리는 글을 표시하고, 각 글에 갱신·통합·보관 중 하나를 적습니다. 이 목록이 다음 달 콘텐츠 작업 계획이 됩니다.