CDN 캐시로 인해 검색 크롤러가 이전 페이지를 가져갈 수 있나요?

검색 크롤러가 액세스하는 CDN 노드에 이전 버전의 HTML이 여전히 저장되어 있고 캐시 규칙에 따라 해당 사본을 계속 사용할 수 있다면, 크롤러는 이전 페이지를 받게 됩니다. 원본 서버 업데이트가 성공했다고 해서 엣지 노드까지 업데이트되었다는 뜻은 아닙니다. 다만 검색 결과에 이전 제목이나 설명이 표시된다는 사실만으로 CDN 캐시 이상을 단정할 수도 없습니다. 크롤링, 색인 처리, 검색 결과 표시는 서로 다른 단계이기 때문입니다.

cdn caching for search crawlers 문제를 판단하려면 먼저 크롤러가 실제로 받은 응답 내용을 확인한 다음, 캐시가 업데이트되지 않은 이유를 추적해야 합니다. 브라우저에서 새 버전이 보이거나 검색 결과에 이전 버전이 표시된다는 사실만으로는 원인을 파악하기에 충분하지 않습니다.

이전 페이지가 계속 사용되는 계층

한 번의 요청은 엣지 노드, 상위 캐시, 원본 서버 애플리케이션 캐시를 거칠 수 있습니다. 가장 바깥쪽 노드의 캐시를 비워도 상위 계층에 이전 사본이 남아 있다면 엣지 노드는 다시 이전 콘텐츠를 가져옵니다. 따라서 ‘새로고침 성공’ 여부는 새로고침 범위를 고려해 판단해야 합니다. 지정 URL, 전체 디렉터리, 캐시 태그, 서로 다른 호스트명이 대상으로 하는 객체는 모두 다를 수 있습니다.

캐시 키도 판단 결과에 영향을 줍니다. 같은 글이라도 매개변수가 있는 주소와 없는 주소, 서로 다른 언어 경로 또는 호스트명은 각각 다른 사본에 대응할 수 있습니다. 캐시 규칙에서 기기, 지역 또는 요청 헤더를 캐시 키에 포함하면 브라우저와 크롤러가 서로 다른 버전을 가져갈 수도 있습니다. 반대로 요청 헤더에 따라 다국어 콘텐츠를 전환하면서 캐시를 올바르게 구분하지 않으면 언어가 뒤섞인 페이지가 표시될 수 있습니다.

일부 설정에서는 백그라운드에서 업데이트하는 동안 이전 콘텐츠를 먼저 반환하거나, 원본 서버에 장애가 발생했을 때 만료된 사본을 사용하도록 허용합니다. 이 경우 캐시 유효 기간이 끝났더라도 이전 페이지가 계속 전송될 수 있습니다. ‘만료됨’이 ‘절대로 다시 반환되지 않음’을 의미하지는 않습니다.

판단에 실제로 영향을 주는 응답 헤더

이미지, 스크립트 또는 스타일시트만 확인하지 말고 HTML 문서 요청을 먼저 살펴보세요. 정적 리소스가 오랫동안 캐시된다고 해서 글 본문에도 같은 유효 기간이 적용되는 것은 아닙니다. 다음 필드는 CDN의 실제 규칙과 함께 해석해야 합니다.

• Cache-Control: max-age는 응답의 신선도 유효 기간을 나타냅니다. 공유 캐시에 s-maxage가 있다면 후자를 중점적으로 확인해야 합니다. CDN 콘솔에서 원본 서버의 응답 헤더를 덮어쓰는 엣지 캐시 규칙을 설정했을 수도 있습니다.
• no-cache는 응답 저장을 허용하지만 재사용하기 전에 검증이 필요합니다. no-store는 응답을 저장하지 않도록 합니다. 이 둘을 같은 의미로 취급하면 설정과 예상 동작이 달라질 수 있습니다.
• Age는 캐시 응답의 경과 시간을 판단하는 데 참고할 수 있지만, 본문이 이전 버전이라는 사실을 단독으로 입증하지는 못합니다. 캐시 적중 표시는 적중 여부만 보여주므로 본문의 버전 정보와 함께 확인해야 합니다.
• ETag, Last-Modified는 조건부 요청에 사용됩니다. 본문이 변경되었는데 검증자가 올바르게 갱신되지 않으면 304가 잘못 반환되어 요청자가 기존 사본을 계속 사용할 수 있습니다.

stale-while-revalidate는 지정된 기간 동안 만료된 콘텐츠를 먼저 반환한 뒤 백그라운드에서 검증하도록 허용합니다. stale-if-error는 특정 오류 조건에서 이전 사본을 사용하도록 허용합니다. 업데이트 시점을 엄격하게 관리해야 하는 페이지는 캐시 유효 기간만 조정하지 말고 이러한 기간을 허용할 수 있는지 명확히 판단해야 합니다.

‘이전 페이지를 크롤링했다’는 사실을 검증 가능한 증거로 만들기

문제가 발생한 전체 URL을 하나 선택하고, 새 제목이나 본문 문구 또는 버전 표시 중 예상되는 항목을 기록합니다. 일반 GET 요청으로 응답 헤더와 본문을 저장합니다. 예를 들어 curl -sS -D headers.txt -o page.html 'https://example.com/article'를 실행할 수 있습니다. HEAD 요청만으로는 본문을 확인할 수 없으며, 일부 서비스는 HEAD와 GET을 다르게 처리합니다.

그런 다음 동일한 호스트명, 경로, 매개변수, 언어 조건을 유지하면서 원본 서버의 응답과 CDN의 응답을 비교합니다. 원본 서버 IP에 직접 액세스하면 기본 사이트로 연결되어 잘못 판단할 수 있습니다. 원본 서버를 비교할 때는 올바른 호스트명과 TLS 설정을 유지하는 방법으로 접속해야 합니다. 원본 서버 자체가 이전 버전이라면 먼저 배포 상태, 애플리케이션 캐시 또는 백엔드 노드 동기화를 확인해야 합니다.

임의의 매개변수를 덧붙이는 방법만으로 검증하지 마세요. 매개변수로 인해 캐시를 우회할 수도 있고, 캐시 키에서 무시될 수도 있으며, 테스트 주소가 크롤러가 실제로 액세스하는 주소와 다를 수도 있습니다. 요청에 Cache-Control: no-cache를 추가하는 것도 서버 측 새로고침 검증을 대신할 수 없습니다. 실제 처리 방식은 CDN 설정에 따라 달라집니다.

요청의 User-Agent를 크롤러 이름으로 바꾸는 것은 해당 필드에 따라 규칙이 분기되는지 테스트할 뿐, 실제 크롤러가 같은 응답을 받았다는 사실을 입증하지는 못합니다. 엣지 액세스 로그에 기록된 시간, 전체 URL, 노드, 캐시 상태, 콘텐츠 버전이 더 유용한 증거이며, 검색 엔진이 공개한 방법에 따라 요청 출처를 검증해야 합니다. 원본 서버 로그에 기록이 없더라도 요청이 엣지 캐시에서 적중했기 때문일 수 있습니다.

새로고침 후 어떤 버전을 검증해야 하는가

배포 시 먼저 원본 서버에서 새 버전이 출력되는지 확인한 다음 해당 캐시를 새로고침해야 합니다. 순서를 거꾸로 하면 원본 서버가 업데이트되기 전에 노드가 이전 콘텐츠를 다시 가져올 수 있습니다. 상위 캐시, 페이지 별칭 또는 다국어 경로가 있다면 실제 캐시 관계에 따라 처리하고 새로고침 작업이 완료되었는지도 확인해야 합니다. API가 요청 접수를 성공적으로 반환했다고 해서 모든 노드가 업데이트된 것은 아닙니다.

새로고침 후 원래 URL로 본문을 다시 가져와 새 콘텐츠를 확인한 다음, 캐시가 다시 적중될 때도 새 버전이 반환되는지 살펴봅니다. 여러 해외 지역과 관련된 경우에는 다른 지역에서도 추가로 검증해야 합니다. 단일 노드의 결과가 모든 노드를 대표하지는 않습니다. HTML을 새로고침한 뒤에도 페이지에 이전 문구가 표시되면 본문을 다른 API에서 불러오는지 확인해야 합니다. 해당 API에는 별도의 캐시가 적용될 수 있습니다.

배포 기록에 콘텐츠 버전, 새로고침 대상, 검증 결과를 남겨 두면 이상 발생 시 배포 실패와 캐시 지연을 구분하는 데 도움이 됩니다. 이 절차는 디지털 전환이 기업 회복탄력성에 미치는 영향에 대한 분석에서 다룰 수 있는 구체적인 기술적 주제이기도 합니다. 복구 과정에서는 각 계층이 반환하는 콘텐츠를 검증할 수 있어야 합니다.

실제 크롤링에서 이미 새 버전을 가져왔는데도 검색 결과가 이전 상태라면 크롤링 시점, 표준 URL, 색인 처리 상태를 계속 확인해야 합니다. 이때 캐시를 반복해서 비워도 검색 결과가 즉시 업데이트되지는 않습니다. 또한 크롤러가 모든 캐시를 장기간 우회하도록 해서는 안 됩니다. 페이지 콘텐츠를 일관되게 유지하고, 캐시 규칙을 설명할 수 있으며, 업데이트 결과를 검증할 수 있어야 지속적인 문제 추적이 용이합니다.