오래된 글을 AI 검색용으로 되살리는 리프레시 전략

Google AI Overviews·Perplexity·ChatGPT Search가 RAG 파이프라인으로 인용 후보를 선택할 때, 콘텐츠 신선도는 두 경로로 평가된다: 크롤러가 수집하는 lastmod·Last-Modified 시그널과, LLM이 임베딩·파인튜닝 시점에 반영한 게시 맥락. 오래된 글이 AI 검색에서 밀려나는 이유는 단순히 "낡았기 때문"이 아니라 이 두 경로에서 모두 낮은 점수를 받기 때문이다. 리프레시 전략은 본문 수정만으로는 불충분하며, 구조 데이터·HTTP 헤더·사이트맵 세 계층을 동기화해야 실질적인 재인덱싱이 유발된다.

AI 검색 엔진이 신선도를 처리하는 메커니즘

크롤러의 신선도 신호

• sitemap <lastmod>: 크롤러에게 "이 URL이 언제 바뀌었다"고 명시적으로 알리는 유일한 채널. 왜: 갱신 없이 방치하면 크롤 주기가 낮게 책정돼 실제 수정이 반영되지 않는다. 어떻게: CMS 빌드 훅 또는 CI/CD 파이프라인에서 콘텐츠 수정과 연동해 자동 갱신한다.
• HTTP Last-Modified / ETag: 조건부 GET(If-Modified-Since)에 대해 304 Not Modified가 반복되면 크롤러는 해당 URL을 낮은 우선순위로 분류한다. 왜: 크롤 예산이 제한된 대형 사이트에서 변경 없는 URL이 버젓이 크롤 슬롯을 차지하면 실제 수정 URL의 재수집이 지연된다. 어떻게: 정적 파일이라면 파일 mtime 갱신, 동적 렌더링이라면 응답 헤더에 정확한 수정 타임스탬프를 주입한다.
• JSON-LD dateModified: Article·BlogPosting 스키마의 수정일. 왜: Google 리치 결과 테스트에서 datePublished와 dateModified 불일치가 경고로 표시되며, AI Overviews가 출처 신선도를 평가하는 간접 신호로 작동한다. 어떻게: 본문 업데이트와 동일 트랜잭션으로 값을 갱신한다.

RAG 파이프라인의 신선도 처리

• 임베딩 벡터 재계산 시점: Perplexity·ChatGPT Search는 크롤된 최신 버전을 청크 단위로 임베딩한다. 콘텐츠가 변하지 않으면 벡터 거리도 변하지 않아 새 쿼리의 상위 k에 진입하기 어렵다.
• 엔티티 밀도 감쇠: 최신 용어("MCP", "AI Overviews" 등)가 없는 오래된 글은 새 쿼리와의 의미 근접도가 낮게 계산된다. 본문에 최신 엔티티를 추가해 임베딩 공간의 쿼리 근접도를 갱신해야 한다.

리프레시 우선순위 선정

1. Search Console에서 클릭·노출이 6개월간 30% 이상 하락한 URL — 왜: AI 검색 전환 영향이 이미 반영된 URL은 리프레시 효과 측정도 명확하다. 어떻게: SC "성과" 탭에서 비교 기간 필터 적용, CSV 추출 후 delta_clicks / clicks_prev < -0.3 조건으로 필터링.
2. 내부 링크가 3개 이상 연결된 스포크 페이지 — 왜: 허브에서 권위가 유입되는 URL은 재인덱싱 후 신호 반영이 빠르다. 어떻게: Screaming Frog 내부 링크 보고서에서 inlinks ≥ 3 필터.
3. 본문에 연도·통계·버전이 명시된 글 — 왜: "2022년 기준" 같은 표현이 있으면 LLM이 인용을 회피하는 경향이 있다. 어떻게: 본문에서 \d{4}년.*기준|조사|발표 패턴을 grep해 목록 추출.

3계층 동기화 구현

1계층 — 콘텐츠 본문

• 통계·날짜 최신화: 수치가 변하지 않더라도 "2025년 6월 기준"처럼 조사 시점을 명시한다.
• FAQ 블록 추가: PAA 박스·AI Overview에서 반복되는 질문을 H3 + 답변 단락으로 삽입한다. LLM은 질의응답 쌍이 명시된 청크를 우선순위로 처리하는 경향이 있다.
• 신규 엔티티 연결: 최신 개념 1~2개를 추가하고 권위 있는 외부 출처에 링크한다.

2계층 — JSON-LD + 사이트맵

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "오래된 글을 AI 검색용으로 되살리는 리프레시 전략",
  "datePublished": "2022-09-15T09:00:00+09:00",
  "dateModified": "2025-06-18T10:30:00+09:00",
  "author": {
    "@type": "Person",
    "name": "정유진"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Citeon",
    "logo": {
      "@type": "ImageObject",
      "url": "https://citeon.io/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://citeon.io/blog/content-refresh-ai-search"
  }
}

<!-- sitemap.xml 해당 URL 엔트리 -->
<url>
  <loc>https://citeon.io/blog/content-refresh-ai-search</loc>
  <lastmod>2025-06-18</lastmod>
  <changefreq>monthly</changefreq>
  <priority>0.8</priority>
</url>

3계층 — llms.txt 순서 조정

• 리프레시된 글을 llms.txt 상단 섹션에 재배치한다. 일부 LLM 크롤러가 파일 내 순서를 우선도 힌트로 처리한다는 공식 근거는 없으나, 상단 배치가 크롤러 파싱 중 조기 종료 시 누락 위험을 낮춘다.
• URL과 함께 한 줄 요약(: 리프레시 날짜 + 주요 변경 내용)을 추가하면 LLM 파서가 콘텐츠 맥락을 인식하는 데 도움이 된다.

신호별 처리 방식 비교

흔한 함정 — "본문만 수정하면 된다"는 착각

본문을 수정하고 퍼블리시해도 JSON-LD의 dateModified가 갱신되지 않거나 sitemap의 lastmod가 자동 업데이트되지 않으면, 크롤러는 조건부 GET으로 304 Not Modified를 수신하고 해당 URL을 "변경 없음"으로 분류한다. 특히 Hugo·Jekyll 같은 정적 사이트 생성기는 빌드 시 파일 mtime을 빌드 타임스탬프로 초기화하므로, 실제 콘텐츠 수정 날짜와 lastmod가 분리되는 문제가 발생한다.

올바른 처리: "콘텐츠 수정 → dateModified 갱신 → sitemap lastmod 갱신 → HTTP ETag 재생성"을 단일 파이프라인으로 묶는다. Hugo라면 front matter에 lastmod 필드를 명시하거나 enableGitInfo = true로 Git 커밋 타임스탬프를 자동 반영한다. Next.js라면 ISR 재생성(revalidate) 후 응답 헤더에 실제 수정 시각을 주입하는 미들웨어를 추가한다.

참고 자료

이 글의 권고는 아래 공식 문서·연구를 근거로 합니다.

• Google 검색 센터 — SEO 기본 가이드
• Google — 구조화 데이터 마크업 & 리치 결과
• Schema.org — 구조화 데이터 시작하기