오래된 글을 고칠 때 발행일과 수정일을 어떻게 다뤄야 할까

블로그 글이 20개, 30개를 넘어가면 새 글을 쓰는 일만큼 오래된 글을 고치는 일이 중요해집니다. 그런데 막상 고치려고 하면 의외로 자주 멈칫하게 됩니다. 오탈자 하나를 고쳤는데 updatedAt을 바꿔야 할까요? 예전 스크린샷을 새 화면으로 교체하면 수정일을 바꿔야 할까요? 글 구조를 크게 바꿨다면 발행일도 새 날짜로 바꾸는 게 맞을까요?

날짜는 화면에 작게 보이지만, 독자와 검색엔진에게 모두 신호가 됩니다. 독자는 날짜를 보고 “이 글을 지금 믿어도 되나”를 판단하고, 검색엔진은 구조화 데이터와 sitemap의 lastModified, 페이지 본문, 메타데이터를 함께 읽습니다. 그래서 날짜를 아무렇게나 바꾸면 글은 최신처럼 보이지만 실제 신뢰는 떨어질 수 있습니다. 반대로 의미 있는 업데이트를 했는데 날짜를 전혀 바꾸지 않으면, 고친 내용을 독자에게 제대로 알려주지 못합니다.

이 글은 작은 기술 블로그에서 publishedAt과 updatedAt을 다루는 기준을 정리한 글입니다. 법칙처럼 외워야 하는 규칙이라기보다, 나중에 글이 늘어도 일관되게 판단하기 위한 운영 기준에 가깝습니다.

검색/신뢰콘텐츠 갱신

오래된 글을 고칠 때 발행일과 수정일을 어떻게 다뤄야 할까

기술 블로그 글을 고칠 때 발행일을 바꿀지, 수정일만 갱신할지 헷갈리기 쉽습니다. 작은 수정과 의미 있는 업데이트를 나누고 날짜 신호를 정직하게 관리하는 기준을 정리했습니다.

핵심 1

publishedAt과 updatedAt은 역할이 다릅니다

핵심 2

작은 수정은 날짜를 바꾸지 않아도 됩니다

핵심 3

updatedAt은 독자 판단이 달라질 때 바꿉니다

콘텐츠 갱신검색/신뢰published updated date rules

publishedAt과 updatedAt은 역할이 다릅니다

먼저 두 날짜의 역할을 나누는 게 중요합니다.

publishedAt은 글의 출생일에 가깝습니다. 글이 언제 처음 공개됐는지를 말합니다. 그래서 일반적인 수정으로는 바꾸지 않는 편이 좋습니다. 기술 글은 시간이 지나면서 고치는 일이 많기 때문에, 매번 발행일을 새 날짜로 바꾸면 실제 발행 이력이 흐려집니다.

반면 updatedAt은 글의 현재성을 설명하는 날짜입니다. 이 글이 언제 마지막으로 의미 있게 손봤는지를 알려줍니다. 예를 들어 Next.js 버전 변화 때문에 코드 예시를 바꿨거나, Search Console 화면 흐름이 달라져 설명을 수정했거나, 개인정보처리방침 문구를 실제 구현과 맞게 고쳤다면 updatedAt을 바꾸는 편이 자연스럽습니다.

이 구분은 Article과 Breadcrumb 구조화 데이터를 넣어야 하는 이유와 구현법에서 다룬 datePublished, dateModified와도 이어집니다. 구조화 데이터에 날짜를 넣는다면 화면, frontmatter, JSON-LD, sitemap이 같은 이야기를 해야 합니다.

작은 수정은 날짜를 바꾸지 않아도 됩니다

모든 수정이 업데이트는 아닙니다. 글을 오래 운영하다 보면 작은 오탈자, 띄어쓰기, 어색한 조사, 문장 순서 같은 것을 자주 고칩니다. 이런 수정마다 updatedAt을 바꾸면 독자는 글이 크게 바뀐 것으로 오해할 수 있습니다. 검색엔진에게도 “이 페이지가 자주 의미 있게 바뀐다”는 신호처럼 보일 수 있는데, 실제 내용은 그대로라면 좋은 습관이라고 보기 어렵습니다.

저는 아래 수정은 보통 날짜를 바꾸지 않습니다.

• 오탈자 수정
• 띄어쓰기와 맞춤법 수정
• 문장 어미를 자연스럽게 고침
• 깨진 내부 링크 하나를 정상 링크로 교체
• 이미지 alt text의 표현을 조금 다듬음
• 코드 블록 들여쓰기나 줄바꿈을 보기 좋게 정리

물론 깨진 링크가 글의 핵심 자료였거나, 이미지 alt text가 잘못된 정보를 전달하고 있었다면 이야기가 달라질 수 있습니다. 기준은 “독자가 이 글에서 얻는 정보가 달라졌는가”입니다. 정보가 달라지지 않았다면 날짜는 그대로 두어도 됩니다.

이렇게 하면 운영자도 마음이 편합니다. 작은 교정까지 날짜 관리 업무로 만들지 않아도 되고, updatedAt은 정말 의미 있는 수정의 기록으로 남습니다.

updatedAt은 독자 판단이 달라질 때 바꿉니다

updatedAt을 바꾸는 가장 좋은 기준은 독자의 판단입니다. 수정 후 독자가 이전과 다른 행동을 하게 되거나, 더 정확한 결정을 할 수 있게 되었다면 수정일을 바꾸는 편이 좋습니다.

예를 들어 아래는 updatedAt을 바꾸는 쪽이 자연스럽습니다.

기술 글에서는 특히 코드와 화면이 중요합니다. 코드 예시가 바뀌었는데 날짜가 오래된 채로 있으면 독자는 “이 정보가 지금도 유효한가”를 다시 의심해야 합니다. 반대로 수정일이 최근이면, 최소한 운영자가 이 글을 다시 확인했다는 신호가 됩니다.

다만 updatedAt을 바꿨다면 본문도 그에 맞게 정리해야 합니다. 날짜만 최신으로 바꾸고 본문은 예전 표현을 그대로 두면 오히려 신뢰가 떨어집니다. “최근 업데이트”는 날짜 장식이 아니라 글의 상태 설명이어야 합니다.

publishedAt을 바꾸는 일은 거의 없습니다

가장 조심해야 할 날짜는 publishedAt입니다. 검색 노출을 기대하고 오래된 글의 발행일만 새 날짜로 바꾸고 싶은 유혹이 생길 수 있습니다. 하지만 저는 작은 블로그일수록 이 습관을 피하는 편이 좋다고 봅니다.

발행일을 자주 바꾸면 몇 가지 문제가 생깁니다.

• 실제 발행 이력이 흐려집니다.
• 아카이브 정렬이 운영자의 기록과 어긋납니다.
• 독자가 오래된 글인지 새 글인지 판단하기 어려워집니다.
• 구조화 데이터의 datePublished가 사실과 달라질 수 있습니다.
• 내부 링크 흐름에서 오래된 기둥 글과 새 글의 구분이 약해집니다.

그렇다고 publishedAt을 절대 바꾸면 안 된다는 뜻은 아닙니다. 예외는 있습니다. 예전 글을 사실상 폐기하고, 같은 slug로 완전히 다른 글을 다시 발행하는 수준이라면 고민할 수 있습니다. 하지만 이 경우에도 저는 대체로 새 글로 분리하거나, 기존 글의 updatedAt을 갱신하고 본문 상단에서 변경 내용을 설명하는 쪽을 선호합니다.

날짜는 독자에게 보여주는 약속입니다. “이 글은 2026년 1월에 처음 썼고, 2026년 4월에 다시 확인했다”라는 정보가 “2026년 4월 글처럼 보이게 만들었다”보다 훨씬 믿을 만합니다.

수정 범위를 네 단계로 나누면 판단이 쉬워집니다

매번 감으로 판단하면 글마다 날짜 기준이 달라집니다. 그래서 저는 수정 범위를 네 단계로 나눕니다.

2단계가 가장 애매합니다. 예를 들어 내부 링크 하나를 추가한 것은 날짜를 바꾸지 않아도 됩니다. 하지만 관련 글을 여러 개 묶고, 독자가 따라갈 순서를 새로 만든 수준이라면 updatedAt을 바꿔도 됩니다. 내부링크 구조를 먼저 설계해야 작은 블로그가 강해지는 이유에서 말한 것처럼 내부 링크는 단순 장식이 아니라 글의 탐색 흐름을 바꿀 수 있기 때문입니다.

핵심은 수정 작업량이 아니라 정보 변화량입니다. 오래 걸린 교정이어도 정보가 그대로면 날짜를 유지할 수 있고, 짧은 수정이어도 결론이 바뀌었다면 날짜를 갱신해야 합니다.

날짜를 바꿨다면 메타데이터도 같이 봅니다

수정일을 바꾸는 정도의 업데이트를 했다면, frontmatter만 고치고 끝내지 않는 편이 좋습니다. 날짜가 바뀔 만큼 의미 있는 수정이라면 제목, 설명, 내부 링크, 구조화 데이터, sitemap에 들어가는 값도 함께 확인해야 합니다.

이 블로그 구조에서는 최소한 아래를 같이 봅니다.

• frontmatter의 updatedAt
• 글 페이지에 보이는 날짜 표시
• Article 또는 BlogPosting 구조화 데이터의 dateModified
• sitemap의 lastModified
• seoTitle과 seoDescription
• 본문 첫 문단과 마무리 요약
• 관련 글 내부 링크

특히 seoDescription은 자주 놓칩니다. 본문을 크게 바꿨는데 검색 결과용 설명은 예전 문제를 말하고 있으면, 검색 결과와 실제 글 사이에 어긋남이 생깁니다. 이 문제는 meta title과 description이 검색 결과에서 어긋날 때 수정법에서 다룬 것처럼, Google이 다른 본문 문장을 snippet으로 선택하게 되는 원인 중 하나가 될 수 있습니다.

날짜 변경은 작은 버튼이 아니라 주변 신호를 함께 맞추는 작업입니다. 그래서 수정일을 바꾸는 날에는 “날짜만 바꾸기”보다 “문서 상태를 다시 맞추기”로 생각하는 편이 좋습니다.

오래된 정보는 지우기보다 상태를 분명히 합니다

기술 글을 운영하다 보면 예전 정보가 완전히 틀리지는 않았지만, 지금 기준으로는 첫 번째 선택지가 아닌 경우가 있습니다. 이때 무조건 삭제하는 것보다 상태를 분명히 쓰는 편이 좋을 때가 많습니다.

예를 들어 이런 식입니다.

예전에는 이 방식으로도 충분했지만, 현재 이 프로젝트에서는 sitemap.ts와 robots.ts를
사용해 자동 생성하는 쪽을 기본값으로 두고 있습니다.

이 문장은 단순히 과거 내용을 지우는 것보다 독자에게 더 도움이 됩니다. 왜냐하면 독자는 “왜 이 방식이 바뀌었는지”를 알 수 있기 때문입니다. 날짜도 마찬가지입니다. publishedAt을 유지하고 updatedAt을 갱신하면, 글이 시간 속에서 어떻게 관리됐는지 자연스럽게 드러납니다.

단, 너무 오래되어 더 이상 추천하면 안 되는 내용은 과감히 정리해야 합니다. “기록으로 남겨두기”와 “독자에게 여전히 권장하기”는 다릅니다. 본문에서 예전 방식을 설명하더라도, 현재 추천 흐름은 분명하게 표시해야 합니다.

글 목록 정렬과 발행 리듬도 함께 생각합니다

날짜는 개별 글만의 문제가 아닙니다. 블로그 목록, 카테고리 페이지, sitemap, 관련 글 카드에도 영향을 줍니다. 특히 작은 블로그는 글 수가 적기 때문에 날짜 하나가 전체 흐름을 크게 바꿀 수 있습니다.

예를 들어 오래된 글 10개의 publishedAt을 모두 최신 날짜로 바꾸면, 블로그 목록은 갑자기 과거 글이 새 글처럼 올라옵니다. 사용자는 실제로 새 글이 많아진 것처럼 느낄 수 있지만, 사이트의 발행 리듬은 왜곡됩니다. 반대로 updatedAt을 별도로 보여주면, 발행 흐름은 유지하면서 최근 관리 여부를 전달할 수 있습니다.

저는 그래서 아래 방식이 가장 안전하다고 봅니다.

• 목록 정렬은 기본적으로 publishedAt 기준으로 유지
• 글 상세에서는 updatedAt이 있으면 함께 표시
• sitemap의 lastModified는 updatedAt을 우선 사용
• 전면 개편 수준의 글은 본문에서 업데이트 내용을 설명
• 새 주제를 다루는 경우에는 기존 글을 고치기보다 새 글로 분리

이 기준은 블로그 출시 직후 7일 동안 확인해야 할 운영 체크리스트 이후 운영 단계에서 특히 중요합니다. 출시 직후에는 기본 신호를 맞추고, 이후에는 날짜와 업데이트 기록을 통해 글의 생명력을 관리하는 흐름으로 넘어가면 됩니다.

날짜 변경 기록은 짧게라도 남겨두는 편이 좋습니다

혼자 운영하는 블로그라도 수정 기록을 간단히 남겨두면 나중에 큰 도움이 됩니다. 꼭 화면에 변경 로그를 보여줄 필요는 없습니다. 내부 메모, 커밋 메시지, 로드맵, 글 하단의 짧은 업데이트 노트 중 하나만 있어도 충분합니다.

예를 들어 커밋 메시지는 이렇게 남길 수 있습니다.

Update Search Console checklist for new sitemap flow

또는 글 하단에 아래처럼 짧게 남길 수 있습니다.

2026-04-12 업데이트: sitemap 제출 흐름과 canonical 확인 순서를 현재 배포 구조에 맞게 다시 정리했습니다.

모든 글에 업데이트 노트를 붙일 필요는 없습니다. 하지만 결론이 바뀌었거나, 독자가 따라 할 절차가 바뀌었거나, 오래된 스크린샷을 새 화면으로 교체했다면 짧은 기록이 독자에게도 도움이 됩니다. 이 기록은 운영자에게도 “왜 이 날짜를 바꿨는지”를 설명해 줍니다.

제가 쓰는 날짜 판단 체크리스트

글을 수정한 뒤 아래 질문을 순서대로 보면 대부분 결정할 수 있습니다.

이 체크리스트의 핵심은 “수정했으니 날짜를 바꾼다”가 아니라 “독자에게 의미 있는 변화가 있으면 날짜를 바꾼다”입니다. 날짜는 작업량의 표시가 아니라 문서 상태의 표시입니다.

마무리

오래된 글을 고칠 때 날짜를 어떻게 다룰지는 작은 운영 규칙처럼 보이지만, 블로그 신뢰도에는 꽤 큰 영향을 줍니다. publishedAt은 처음 공개된 기록으로 두고, updatedAt은 독자에게 의미 있는 변화가 있을 때만 갱신하는 편이 가장 단순하고 정직합니다. 오탈자와 서식 수정은 조용히 고쳐도 되고, 코드, 화면, 결론, 정책, 절차가 바뀌었다면 수정일을 바꿔 현재성을 알려주는 식입니다.

결국 좋은 날짜 관리는 검색엔진을 의식한 꼼수가 아니라 독자에게 상태를 정확히 알려주는 습관입니다. 이 글이 언제 처음 나왔고, 언제 다시 확인됐고, 지금도 따라 해도 되는지 분명하게 보여주는 것. 작은 블로그일수록 그 정직한 신호가 오래 남습니다.