HTTP 304 Not Modified

TL;DR — 304 Not Modified 응답은 서버가 “이미 가지고 있으니 다시 다운로드하지 않아도 됩니다. 사본은 여전히 유효합니다”라고 말하는 방식입니다. 오류가 아니며, 3xx “리디렉션” 계열에 속하지만 누구도 새 URL로 보내지 않습니다. 클라이언트(브라우저나 크롤러)가 먼저 “지난번 이후 변경되었나요?”라고 묻는 조건부 요청을 보낼 때만 발생합니다. SEO에서 순위를 직접 바꾸지는 않지만, 대규모 사이트에서는 검색 엔진이 자원을 더 효율적으로 사용하는 데 도움이 될 수 있습니다.

304의 실제 의미

서버가 보내는 모든 응답은 세 자리 상태 코드로 시작합니다. 200 OK는 “본문을 포함한 페이지를 여기 있습니다”라는 뜻입니다. 304 Not Modified는 더 구체적입니다. 클라이언트가 “변경된 경우에만 이 페이지를 보내 달라”는 조건부 요청을 보냈고, 서버는 변경되지 않았다고 판단했습니다. 그래서 원래 보냈을 200 대신 본문이 전혀 없는 304로 응답합니다. 실제 규칙은 이것입니다. 304는 조건이 거짓으로 평가된 조건부 GET/HEAD에 대한 응답으로만 발생합니다.

두 번째 방문은 이런 일이 일어나는 전형적인 방식이며, 이해하기 좋은 그림입니다. 브라우저나 크롤러가 처음 페이지를 가져오면 전체 콘텐츠가 포함된 정상적인 200과 작은 “지문” 헤더 몇 개를 받습니다. 다음 방문에서 클라이언트는 그 지문을 서버에 보여 주며 “아직 같은가요?”라고 묻습니다. 아무것도 바뀌지 않았다면 서버는 304를 보내고 페이지 본문은 전혀 보내지 않으며, 클라이언트는 이미 가지고 있던 사본을 재사용합니다. 하지만 “두 번째 방문”은 예시일 뿐 프로토콜 규칙은 아닙니다. 실제로 304를 발생시키는 것은 요청이 어떤 방식으로 도착했는지와 관계없이 조건부 요청 자체입니다. Evidence for this claim RFC 9110 defines 304 Not Modified as the response to a conditional GET or HEAD when the selected representation has not changed and says the response cannot contain content. Scope: HTTP semantics for 304 conditional responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.5 — 304 Not Modified

“리디렉션” 계열이지만 리디렉션은 아닌 이유

304는 HTTP가 리디렉션에 사용하는 분류인 3으로 시작합니다. 그래서 사람들이 자주 헷갈립니다. 하지만 304에는 Location 헤더가 없고 다른 주소로 보내지도 않습니다. 아무도 이동하지 않습니다. 클라이언트가 저장해 둔 자신의 사본을 다시 사용하라고 가리킬 뿐입니다. 그러므로 “리디렉션 계열”은 번호를 매기는 방식의 특이점이지, 실제 동작을 뜻하지 않습니다.

304는 문제인가요?

아닙니다. 브라우저의 네트워크 탭이나 크롤링 보고서에서 304를 보는 것은 캐싱이 작동하고 있다는 신호이며, 바로 원하는 결과입니다. 인터넷에 떠도는 “304 오류, 해결 방법” 조언 상당수는 이를 사용자 쪽의 고장으로 취급하지만 그렇지 않습니다. 잘 작동하는 캐시가 의도한 대로 내놓는 올바른 결과입니다.

SEO에 도움이 되나요?

직접적으로 순위를 높이지는 않습니다. Google은 마지막으로 페이지를 크롤링했을 때 이미 콘텐츠를 가지고 있습니다. 304는 변경되지 않았음을 확인할 뿐이므로 Google은 저장해 둔 콘텐츠를 계속 사용합니다(검색이 URL의 신호를 다시 계산할 수는 있지만, 304 자체는 순위나 색인 생성 보너스가 아닙니다). 304가 돕는 부분은 자원 효율성입니다. 검색 엔진이 변경되지 않은 페이지를 다시 다운로드하지 않으면 양쪽의 대역폭과 계산을 절약할 수 있고, Google은 이것이 크롤링을 더 효율적으로 수행하는 데 간접적으로 도움을 줄 수 있다고 말합니다. 절약된 노력이 새 페이지나 업데이트된 페이지로 자동 재배분된다는 보장은 아닙니다. 페이지가 많고 변경이 드문 대규모 사이트에서 특히 중요합니다.

ETag, If-None-Match, 강한 검증자와 약한 검증자의 차이, 구현 방법, Google이 실제로 말한 내용을 자세히 보려면 Advanced 탭으로 전환하세요.

TL;DR — 304는 조건부 GET/HEAD의 조건이 거짓으로 평가되어, 그렇지 않았다면 200이 되었을 응답입니다(RFC 9110 §15.4.5). 3xx 계열이지만 리디렉션은 아닙니다: Location도 새 URL도 없고, 규범적으로 본문도 없습니다(“콘텐츠나 트레일러를 포함할 수 없습니다”). 조건은 If-None-Match(ETag와 비교) 및/또는 If-Modified-Since(Last-Modified와 비교)로 전달됩니다. 검증자가 여전히 일치하면 서버는 304를 반환하고 클라이언트는 캐시를 재사용합니다. SEO 영향은 직접적인 순위 효과 없음입니다. Google은 이미 콘텐츠를 가지고 있지만 Search가 URL 신호를 다시 계산할 수는 있습니다. 대규모 사이트에서는 자원을 절약할 수 있고 Google은 이것이 크롤링 효율을 간접적으로 높일 수 있다고 말하지만, 크롤링 예산을 다른 URL로 자동 재배분한다고 약속하지는 않습니다. Google의 크롤링 인프라는 두 검증자를 지원하며 날짜 형식의 함정이 없는 ETag를 기본값으로 권장합니다. URL을 이동시키는 301/302/307/308과, 실제로 보낼 것이 없어서 본문이 없는 204와 구분하세요.

사양에서 말하는 304의 의미

RFC 9110(HTTP Semantics) §15.4.5는 이를 정확히 정의합니다. “The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false.” (번역) 「304(Not Modified) 상태 코드는 조건부 GET 또는 HEAD 요청을 받았으며 조건이 거짓으로 평가되지 않았다면 200(OK) 응답이 되었을 요청임을 나타냅니다.」 이것이 규범적인 실제 트리거입니다. 조건이 거짓으로 평가되어 원래 200이 되었을 조건부 GET/HEAD입니다. 쉽게 말해 클라이언트가 “변경된 경우에만 이 페이지를 보내 달라”고 요청했고, 서버가 변경되지 않았다고 판단해 본문 전송을 건너뜁니다. “두 번째 방문”은 요청이 조건부가 되는 일상적인 예(클라이언트가 이전 응답에서 저장한 검증자를 붙임)이지만, 규칙 자체는 아닙니다. 사양에는 이전 방문이 필요하다고 쓰여 있지 않고 조건부 요청만 요구합니다. Evidence for this claim RFC 9110 defines 304 Not Modified as the response to a conditional GET or HEAD when the selected representation has not changed and says the response cannot contain content. Scope: HTTP semantics for 304 conditional responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.5 — 304 Not Modified

사양은 이 절에서 “redirecting”이라는 단어까지 사용합니다. “the server is therefore redirecting the client to make use of that stored representation as if it were the content of a 200 (OK) response” (번역) 「따라서 서버는 저장된 표현을 200(OK) 응답의 콘텐츠인 것처럼 사용하도록 클라이언트를 리디렉션합니다.」라고 하지만, 주의해서 읽어야 합니다. 다른 URL이 아니라 클라이언트 자신의 캐시로 되돌리는 것입니다. Location 헤더도 새 주소도 없습니다. 304가 “리디렉션인가”라는 혼란의 대부분은 이 한 문장에서 생깁니다. HTTP 의미에서 리디렉션이 아닙니다.

두 가지 규범적 사항도 중요합니다.

• 본문은 절대 없습니다. RFC 9110은 “A 304 response is terminated by the end of the header section; it cannot contain content or trailers.” (번역) 「304 응답은 헤더 영역의 끝에서 종료되며 콘텐츠나 트레일러를 포함할 수 없습니다.」라고 합니다. 본문을 보내는 304는 사양 위반이며 일부 클라이언트는 잘못 처리할 수 있습니다. 이는 스타일 선호가 아니라 엄격한 규칙입니다.
• 200과 같은 메타데이터를 전달합니다. 서버는 같은 요청에 대한 200(OK) 응답에 보냈을 다음 헤더 필드인 Content-Location, Date, ETag, Vary를 “MUST GENERATE”해야 하며, 해당되는 경우 Cache-Control과 Expires도 보내야 합니다. 따라서 304는 페이로드를 제외한 200의 헤더입니다.

304의 실제 작동 방식: 조건부 요청

서버는 아무 예고 없이 304를 보내지 않습니다. 항상 조건부 요청, 즉 이전 응답에서 저장한 검증자를 붙여 클라이언트가 조건부로 만든 요청에 대한 응답입니다. 검증자는 두 가지입니다.

ETag와 If-None-Match

ETag(엔터티 태그)는 서버가 200 응답에 붙이는 불투명한 토큰입니다. URL의 정확한 표현에 대한 버전 지문이라고 생각하면 됩니다. 다음에 해당 URL을 요청할 때 클라이언트는 저장한 값을 If-None-Match 헤더로 돌려보냅니다. 서버가 비교했을 때 현재 ETag가 여전히 일치하면 변경되지 않은 것이므로 304를 반환합니다. 다르면 새 콘텐츠와 새 ETag가 포함된 새로운 200을 반환합니다.

Last-Modified와 If-Modified-Since

날짜 기반 대안입니다. 서버가 200에 Last-Modified 타임스탬프를 보냅니다. 다음에는 클라이언트가 이를 If-Modified-Since 헤더로 돌려보내고 서버가 날짜를 비교합니다. 해당 타임스탬프 이후 리소스가 변경되지 않았다면 304입니다. 더 단순하지만 타임스탬프의 정밀도만큼만 세밀하고, 정확한 HTTP 날짜 형식에 민감해 버그의 흔한 원인이 됩니다. 두 검증자가 모두 있으면 If-None-Match(ETag)가 If-Modified-Since보다 우선합니다.

강한 ETag와 약한 ETag

ETag는 강할 수도 있고 약할 수도 있으며, 그 차이가 중요합니다. MDN의 조건부 요청 지침에 따르면 “strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared to.” (번역) 「강한 검증은 리소스가 비교 대상과 바이트 단위로 동일함을 보장하는 것입니다.」 약한 ETag는 W/ 접두사를 붙입니다(예: ETag: W/"abc123"). 약한 ETag는 의미론적 동등성만 주장합니다. MDN의 예처럼 “a page that would differ from another only by a different date in its footer, or different advertising, would be considered identical to the other with weak validation.” (번역) 「바닥글의 날짜나 광고만 달라지는 페이지는 약한 검증에서 다른 페이지와 동일한 것으로 간주됩니다.」 강한 ETag(접두사 없음)는 바이트 단위 일치가 필요한 범위 요청 등에 필요하고, 약한 ETag는 압축·공백·사소한 비실질적 차이로 전체 재요청을 강제하고 싶지 않을 때 유용합니다. 실무적 함정은 gzip/Brotli 재압축 때마다, 또는 로드 밸런싱된 서버마다 ETag가 바뀌면 불필요한 재크롤을 일으킨다는 것입니다. 강한지 약한지 의도적으로 선택하고 실제로 변경되지 않은 콘텐츠의 값은 안정적으로 유지하세요.

전체 핸드셰이크를 단계별로 보기

1. 첫 요청 → 서버가 콘텐츠와 함께 200 OK, ETag 및/또는 Last-Modified를 반환합니다.
2. 클라이언트가 저장 → 콘텐츠와 검증자를 저장합니다.
3. 다음 요청 → 저장된 값과 함께 If-None-Match 및/또는 If-Modified-Since를 보냅니다.
4. 서버가 결정 → 변경 없음: 본문 없는 304 Not Modified, 클라이언트는 캐시 재사용. 변경됨: 새 본문과 새 검증자가 포함된 200 OK. Evidence for this claim RFC 9111 defines validation as checking whether a stored response remains current, typically with a conditional request that can receive 304 Not Modified. Scope: HTTP cache validation; it does not create a Search ranking benefit. Confidence: high · Verified: 2026-07-14 IETF: RFC 9111 §4.3 — Validation

캐싱과 검증자를 크롤링 효율의 수단으로 더 깊이 다루고 싶다면, 즉 조건부 요청 전체와 크롤링 예산의 연결을 보고 싶다면 동반 주제를 참고하세요. 이 글은 상태 코드에 초점을 둔 관점입니다.

304와 SEO: 순위 효과는 없지만 실제 크롤링 효율 효과는 있음

전체 SEO 이야기는 다음과 같으며, 많은 블로그의 상투적인 설명보다 범위가 좁습니다. 304는 직접적인 순위 효과가 없습니다. 상태 코드가 크롤링과 색인 생성에 미치는 영향에 대한 Google의 자체 지침도 색인 효과를 제한합니다. Search가 URL 신호를 다시 계산할 수는 있지만, 그 밖에는 304가 페이지 색인 방식을 바꾸지 않습니다. Google은 이전 크롤링에서 이미 콘텐츠를 가지고 있으므로 304는 아무것도 바뀌지 않았음을 확인하고 보유한 것을 계속 사용하게 합니다. 304를 반환한다고 순위 보너스가 생기지는 않습니다.

304가 실제로 제공하는 것은 크롤링 효율을 간접적으로 개선할 수 있는 자원 절약입니다. Google의 2024년 12월 HTTP 캐싱 글은 대규모 사이트에서 로컬 캐싱이 크롤링 효율에 도움을 줄 수 있다고 설명합니다.

정확한 304 메커니즘에 대해 같은 글은 빈 본문이 중요한 이유를 명시합니다. 크롤러가 보낸 ETag가 “matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body” (번역) 「서버가 생성한 현재 값과 일치하면 서버는 HTTP 본문 없이 HTTP 304(Not modified) 상태 코드를 반환해야 합니다」. 또한 “no HTTP body”가 중요한 이유는 “your server doesn’t have to spend compute resources on actually generating content” 및 “doesn’t have to transfer the HTTP body”이기 때문입니다 (번역) 「서버가 콘텐츠를 실제로 생성하는 데 계산 자원을 쓸 필요가 없고 HTTP 본문을 전송할 필요도 없습니다」. 양쪽에서 계산과 대역폭을 절약합니다. Google이 downstream 이점을 표현하는 방식은 조건부입니다. 자원 절약이 크롤링 효율을 간접적으로 개선할 수 있다는 것입니다. 절약된 노력이 새 URL이나 업데이트된 URL로 자동 재배분된다는 약속이 아닙니다. 자원 절약 메커니즘으로 이해하되, 가능성은 있지만 보장되지 않는 파급 효과로 다루세요.

대규모 사이트에서 더 중요한 이유

페이지가 수백 개뿐이라면 이는 대체로 이론적인 문제입니다. Google은 어쨌든 사이트 전체를 편하게 크롤링할 수 있습니다. 규모가 커질수록 이점이 커집니다. URL이 수십만 또는 수백만 개이고 그중 많은 URL이 드물게 변경되는 사이트에서는 크롤러가 변경되지 않은 것을 다시 가져오지 않아 실질적인 이득이 생깁니다. Google의 글이 겨냥한 대상이 바로 이런 사이트이며, 정직한 설명은 이것입니다. 304를 소규모 사이트의 전술로 과장하지 마세요.

ETag 또는 Last-Modified, 그리고 “변경”의 기준

Google은 ETag를 기본 검증자로 권장합니다. Google은 ETag를 오류가 적은 기본 검증자로 권장합니다. 둘 다 설정해도 괜찮고 권장됩니다. Last-Modified를 사용한다면 날짜는 “must be formatted according to the HTTP standard” (번역) 「HTTP 표준에 따라 형식화되어야」 하며, Google이 권장하는 형식은 “요일, 일 월 연도 시:분:초 시간대 형식”입니다. 예: “Fri, 4 Sep 1998 19:15:56 GMT”. 그렇지 않으면 조용히 무시될 수 있습니다. Google은 크롤러가 재크롤링 시점을 판단하는 데 도움이 되도록 Cache-Control의 max-age 필드도 설정하라고 제안합니다.

캐시를 무효화할 만큼 중요한 변경의 기준은 여러분이 정할 일이며, Google은 실질적인 변경에 한정하라고 조언합니다. “Our recommendation is that you require a cache refresh on significant changes to your content; if you only updated the copyright date at the bottom of your page, that’s probably not significant.” (번역) 「콘텐츠에 중대한 변경이 있을 때 캐시 새로고침을 요구하고, 페이지 하단의 저작권 날짜만 업데이트했다면 아마 중대한 변경이 아닐 것입니다.」

Googlebot과 Bingbot이 실제로 하는 일

모든 크롤러 요청이 조건부인 것은 아닙니다. Google의 크롤러 문서는 제공하는 제품에 따라 개별 Google 크롤러와 fetcher의 캐싱 지원이 다르다고 설명합니다. Googlebot은 Search를 위해 URL을 다시 크롤링할 때 캐싱을 지원하지만 일부 다른 Google fetcher는 특정 조건에서만 지원합니다. 따라서 헤더를 올바르게 구성해도 요청의 100%가 If-None-Match/If-Modified-Since를 포함할 것으로 기대하지 마세요. Bing도 마찬가지입니다. 조건부 요청은 Google만의 기능이 아닙니다. Bing 크롤러는 적어도 2008년 Live Search 블로그 글 이후 조건부 GET(If-Modified-Since와 가능한 경우 If-None-Match를 보내고 콘텐츠가 변경되지 않았을 때 304를 수락)을 지원해 왔지만, Bing은 Google의 2024년 글에 해당하는 최신 글을 발표하지 않았습니다. 메커니즘은 양쪽 엔진에 적용되는 일반적인 HTTP 동작으로 다루세요.

304 지원 구현 방법

1. 200 응답에 검증자를 보냅니다. 서버, CDN 또는 앱이 정상적인 200 응답에 ETag(권장) 및/또는 올바른 형식의 Last-Modified 헤더를 붙이도록 구성합니다. 많은 서버와 프레임워크가 정적 파일에는 ETag를 자동으로 처리하지만, 동적 응답은 보통 직접 활성화해야 합니다.
2. 돌아오는 조건부 헤더를 처리합니다. 요청에 If-None-Match/If-Modified-Since가 있으면 현재 검증자와 비교하고, 여전히 일치하면 본문 없이 304를, 일치하지 않으면 새 200을 반환합니다. 정적 파일 서버는 이를 자동 처리하는 경우가 많지만 앱 라우트와 엣지 워커는 연결하지 않으면 처리하지 않는 경우가 많습니다.
3. “변경됨”의 의미를 결정하고 실제로 변경되지 않은 콘텐츠의 ETag를 안정적으로 유지합니다. 재압축이나 서버별 차이로 불필요하게 값이 바뀌게 하지 마세요.
4. 고전적인 잘못된 설정을 살핍니다.
   • 항상 200 — 검증자를 전혀 보내지 않아 요청이 조건부가 되지 않고 효율 이점을 얻지 못합니다.
   • 불안정한 ETag — 콘텐츠가 바뀌지 않아도 값이 바뀌어 계속 다시 가져오게 합니다(로드 밸런서, 재압축).
   • 오래된 304 — 가장 위험합니다. 콘텐츠가 실제로 바뀐 뒤에도 서버가 304(또는 변경되지 않은 ETag)를 계속 반환해 크롤러와 캐시가 업데이트를 받지 못합니다. 304의 본질적 결함이 아니라 로그 분석에서 잡아야 할 버그입니다.

304와 다른 상태 코드 비교

304와 301 / 302 / 307 / 308

이들이 실제 리디렉션입니다. 301/308(영구) 또는 302/307(임시)은 Location 헤더를 포함하고 클라이언트를 다른 URL로 이동시킵니다. 또한 301/308은 정규화 신호를 전달합니다. 304에는 Location이 없고 아무도 이동시키지 않으며 순위 신호도 전달하지 않습니다. 숫자로는 같은 3xx 계열이지만 역할은 완전히 다릅니다. 코드별 리디렉션 세부 내용은 각 글에 있습니다(301 redirect 글과 리디렉션 하위 허브 참고).

304와 204 No Content

둘 다 본문이 없지만 이유는 완전히 다릅니다. 204 No Content는 서버가 실제로 보낼 것이 없기 때문에 의도적으로 빈 본문을 보내는 2xx 성공입니다. 성공적인 API DELETE/PUT나 분석 비콘이 예입니다. 304도 본문을 보내지 않지만 “이미 가지고 있고 여전히 유효하다”는 뜻이지 보낼 것이 없다는 뜻이 아닙니다. 혼동하지 마세요. 페이지 URL의 204는 색인할 콘텐츠가 없어 소프트 404처럼 취급될 수 있지만, 304는 Google이 이미 가진 콘텐츠의 유효성을 확인합니다. 204 No Content 글에서 해당 코드를 자세히 설명합니다.

304에 관한 흔한 오해

1. “304는 리디렉션이다.” Location 헤더가 없고 아무도 이동하지 않습니다. 클라이언트는 자신의 캐시 사본을 재사용합니다. RFC 9110의 “저장된 표현을 사용하도록 클라이언트를 리디렉션”한다는 말은 다른 URL이 아니라 캐시를 가리킵니다.
2. “304는 고쳐야 할 오류다.” 작동하는 조건부 요청 설정이 의도한 올바른 결과입니다. 크롤링이나 DevTools에서 304를 보는 것은 캐싱이 작동한다는 신호이며 SERP에서 가장 흔한 오해입니다.
3. “304가 순위에 도움을 준다.” 직접적인 순위 효과는 없고 Google은 색인 효과도 제한합니다. Search가 URL 신호를 다시 계산할 수는 있지만, 그 밖에는 색인 방식을 바꾸지 않습니다. 이점은 Google이 말하듯 매우 큰 사이트에서 크롤링 효율을 간접적으로 높일 수 있는 자원 절약이며 순위 신호도, 절약된 노력이 다른 URL로 이동한다는 보장도 아닙니다.
4. “서버가 304를 반환하면 Google이 오래된 콘텐츠를 영원히 사용한다.” 검증자가 일치하는 동안에만 304가 발생합니다. 콘텐츠가 실제로 바뀌는 즉시 올바른 서버는 새 검증자가 포함된 새로운 200을 반환합니다. 진짜 위험은 콘텐츠 변경 후에도 304를 반환하는 잘못 구성된 서버이며, 이는 304의 속성이 아니라 버그입니다. Evidence for this claim RFC 9111 defines validation as checking whether a stored response remains current, typically with a conditional request that can receive 304 Not Modified. Scope: HTTP cache validation; it does not create a Search ranking benefit. Confidence: high · Verified: 2026-07-14 IETF: RFC 9111 §4.3 — Validation
5. “ETag와 Last-Modified는 서로 바꿔 쓸 수 있다.” 둘 다 검증자이지만 Last-Modified는 날짜 형식에 민감하고 타임스탬프 정밀도만큼만 세밀한 반면, ETag는 불투명하고 정확합니다. 다만 부주의하게 구현하면 서버 간 또는 재압축 후 값이 어색하게 달라질 수 있습니다. Google은 ETag를 기본으로 권장하며 가능하면 둘 다 사용하라고 합니다.

자주 묻는 질문

HTTP 304는 오류인가요? 아닙니다. 캐싱이 작동한다는 성공 신호입니다. 클라이언트의 캐시 사본이 여전히 유효하다는 뜻입니다.

304 Not Modified는 리디렉션인가요? 아닙니다. 번호상 3xx 계열이지만 Location 헤더가 없고 클라이언트를 새 URL로 이동시키지 않습니다.

304가 SEO나 순위에 도움이 되나요? 직접적인 순위 효과는 없고 Google이 URL 신호를 다시 계산할 수 있는 것 외의 색인 효과도 없습니다. 크롤러가 변경되지 않은 페이지를 건너뛰게 해 대역폭과 계산을 절약하며, Google은 대규모 사이트에서 이것이 크롤링 효율을 간접적으로 높일 수 있다고 말합니다.

ETag와 Last-Modified의 차이는 무엇인가요? ETag는 If-None-Match로 비교하는 불투명한 버전 지문이고, Last-Modified는 If-Modified-Since로 비교하는 타임스탬프입니다. Google은 오류가 적은 ETag를 권장합니다.

약한 ETag와 강한 ETag는 무엇인가요? 강한 ETag는 바이트가 동일한 콘텐츠임을 주장합니다. W/가 앞에 붙은 약한 ETag는 의미론적 동등성을 주장하며 압축이나 바닥글 날짜 변경 같은 사소한 차이를 허용합니다.

로그나 크롤링 보고서에서 304가 보이는 이유는 무엇인가요? 클라이언트가 조건부 요청을 보내고 서버가 콘텐츠가 변경되지 않았음을 올바르게 확인하기 때문입니다. 예상되는 좋은 동작입니다.

서버가 304를 올바르게 반환하게 하려면 어떻게 하나요? 200에 ETag/Last-Modified를 보내고, 다음 요청에서 If-None-Match/If-Modified-Since를 처리해 검증자가 여전히 일치할 때 본문 없는 304를 반환합니다.

304와 204의 차이는 무엇인가요? 둘 다 본문이 없습니다. 204는 보낼 것이 없기 때문이고, 304는 여전히 유효한 사본을 이미 가지고 있기 때문입니다.

Googlebot은 모든 요청에 조건부 헤더를 보내나요? 아닙니다. 크롤러별 캐싱 지원이 다르므로 헤더가 구성되어 있어도 모든 요청이 조건부인 것은 아닙니다.

304 응답에 본문이 있을 수 있나요? 없습니다. RFC 9110에 따르면 “it cannot contain content or trailers.” (번역) 「콘텐츠나 트레일러를 포함할 수 없습니다.」 본문이 있는 304는 사양 위반입니다.

“Weekday, DD Mon YYYY HH:MM:SS Timezone,” (번역) 「Last-Modified에 사용할 정확한 HTTP 날짜 형식입니다.」 “If my server returns 304, Google will use stale content forever.” (번역) 「검증자가 일치하는 동안에만 304가 반환되며, 콘텐츠가 바뀌면 새 200 응답이 와야 합니다.」 “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” (번역) 「Last-Modified보다 오류와 실수가 적은 ETag를 기본 검증자로 강력히 권장한다는 뜻입니다.」

AI 요약

Advanced 버전을 압축하면 다음과 같습니다.

• 304 Not Modified는 조건부 GET/HEAD의 조건이 거짓으로 평가된 응답이며 원래라면 200이 되었을 응답입니다(RFC 9110 §15.4.5). 3xx 계열이지만 리디렉션은 아닙니다. Location 헤더와 새 URL이 없고 규범적으로 본문도 없습니다(“콘텐츠나 트레일러를 포함할 수 없습니다”). 두 번째 방문은 요청이 조건부가 되는 일반적인 예이지 프로토콜 규칙은 아닙니다.
• 조건부 요청에 대한 응답입니다. If-None-Match(ETag와 비교) 및/또는 If-Modified-Since(Last-Modified와 비교)를 담은 GET/HEAD입니다. 검증자가 여전히 일치하면 서버는 304를 반환하고 클라이언트는 캐시 사본을 재사용합니다.
• 사양의 “redirecting”은 비유입니다. 다른 URL이 아니라 클라이언트의 자체 캐시를 가리킵니다. 304가 리디렉션인지에 관한 혼란은 대부분 이 문장에서 생깁니다.
• ETag와 Last-Modified: ETag는 If-None-Match로 비교하는 불투명한 버전 토큰이고 Last-Modified는 If-Modified-Since로 비교하는 날짜이며 정확한 HTTP 날짜 형식이 필요합니다. 둘 다 있으면 If-None-Match가 우선합니다. 강한 ETag는 바이트 동일, 약한 ETag(W/ 접두사)는 의미론적 동등성입니다.
• 직접적인 순위 효과는 없고 Google이 URL 신호를 다시 계산할 수 있는 것 외의 색인 효과도 없습니다. Google은 이미 콘텐츠를 가지고 있어 304는 아무것도 바뀌지 않았음을 확인할 뿐입니다. Gary Illyes의 표현대로 캐싱은 “may help your site be crawled more efficiently” (번역) 「사이트가 더 효율적으로 크롤링되는 데 도움이 될 수 있습니다」. 이점은 대규모 사이트에서 크롤링 효율을 간접적으로 높일 수 있는 자원 절약이지, 크롤링 예산의 보장된 재배분이나 순위 신호가 아닙니다.
• Google은 ETag를 기본으로 권장합니다(“오류와 실수가 발생하기 어렵습니다”). 둘 다 설정해도 좋고, Last-Modified는 “요일, 일 월 연도 시:분:초 시간대 형식” 형식을 사용해야 합니다. 캐시는 바닥글의 저작권 날짜가 아니라 중요한 변경에만 무효화하세요.
• 크롤러마다 캐싱 지원이 다릅니다. 모든 Googlebot 요청이 조건부인 것은 아닙니다. Bing은 2008년부터 조건부 GET을 지원해 왔으며 이는 일반적인 HTTP 동작입니다.
• 301/302/307/308(URL을 이동시키는 실제 리디렉션)이나 204 No Content(실제로 보낼 것이 없어서 본문이 없음)와 혼동하지 마세요.
• 진짜 위험은 304가 아니라 콘텐츠가 바뀐 뒤에도 304를 반환하는 잘못 구성된 서버입니다. 로그 분석에서 잡아야 합니다. 일부 클라이언트 라이브러리나 플랫폼 캐싱 계층에서는 실제 문제가 없어도 유효한 304가 오류처럼 보일 수 있습니다.

“요일, 일 월 연도 시:분:초 시간대 형식” (번역) 「Last-Modified는 이 HTTP 날짜 형식을 사용해야 합니다.」 “요일, 일 월 연도 시:분:초 시간대 형식” (번역) 「Last-Modified는 이 HTTP 날짜 형식을 사용해야 합니다.」 “요일, 일 월 연도 시:분:초 시간대 형식” (번역) 「Last-Modified는 이 HTTP 날짜 형식을 사용해야 합니다.」 “Weekday, DD Mon YYYY HH:MM:SS Timezone” (번역) 「Last-Modified는 이 HTTP 날짜 형식을 사용해야 합니다.」 “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” (번역) 「Last-Modified보다 오류와 실수가 적은 ETag를 기본 검증자로 강력히 권장한다는 뜻입니다.」

공식 문서

304의 의미와 검색 엔진이 이를 사용하는 방식을 확인하는 1차 출처입니다.

HTTP 사양 및 브라우저 참고 자료

• RFC 9110 §15.4.5 — 304 Not Modified — 조건부 요청, 본문 없음, 필수 헤더라는 권위 있는 정의입니다.
• MDN — 304 Not Modified — 쉬운 설명, If-None-Match/If-Modified-Since 트리거, 304가 전달해야 하는 헤더 목록입니다.
• MDN — HTTP conditional requests — 강한 검증과 약한 검증을 설명합니다.
• MDN — ETag — 약한(W/) 문법과 강한 문법을 포함한 ETag 헤더 설명입니다.

Google Search Central

• Crawling December: HTTP 캐싱 — Gary Illyes의 2024년 12월 9일 글로, ETag/If-None-Match와 Last-Modified/If-Modified-Since가 304를 만드는 방식과 크롤링 효율에 도움이 되는 이유를 설명합니다.
• Google 크롤러(User Agent) 개요 — 캐싱을 지원하는 Google 크롤러와 ETag를 Last-Modified보다 우선하는 권장 사항을 설명합니다.
• HTTP 상태 코드가 Google 크롤러에 미치는 영향 — 304에 관한 Google의 최신 행으로, 304가 그 밖의 색인 효과는 없더라도 Search가 URL 신호를 다시 계산할 수 있다는 단서가 포함되어 있습니다.
• Google Search 크롤링 오류 문제 해결 — 조건부 요청의 자원 절약이 크롤링 효율을 “may indirectly” 개선할 수 있고 Google이 모든 크롤링 시도에 조건부 헤더를 보내지는 않는다는 출처입니다.

Bing

• Live Search 크롤러 개선 발표 — If-Modified-Since/If-None-Match에서 304로 이어지는 조건부 GET 지원을 2008년부터 확인하는 오래된 Bing/Live Search 글입니다.

출처의 인용문

기록에 남은 발언입니다. 각 링크는 출처 페이지에서 해당 구절을 인용한 위치로 이동하는 딥 링크입니다.

HTTP 사양

• “The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false.” (번역) 「304(Not Modified) 상태 코드는 조건부 GET 또는 HEAD 요청을 받았으며 조건이 거짓으로 평가되지 않았다면 200(OK) 응답이 되었을 요청임을 나타냅니다.」 — RFC 9110, HTTP Semantics, §15.4.5. 섹션 읽기
• “A 304 response is terminated by the end of the header section; it cannot contain content or trailers.” (번역) 「304 응답은 헤더 영역의 끝에서 종료되며 콘텐츠나 트레일러를 포함할 수 없습니다.」 — RFC 9110, §15.4.5 (규범적인 “본문은 절대 없음” 규칙). 섹션 읽기

MDN Web Docs

• “The HTTP 304 Not Modified redirection response status code indicates that there is no need to retransmit the requested resources.” (번역) 「HTTP 304 Not Modified 리디렉션 응답 상태 코드는 요청한 리소스를 다시 전송할 필요가 없음을 나타냅니다.」 인용문으로 이동
• “Strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared to.” (번역) 「강한 검증은 리소스가 비교 대상과 바이트 단위로 동일함을 보장하는 것입니다.」 — MDN, “HTTP conditional requests.” 가이드 읽기

Gary Illyes, Google — “Crawling December: HTTP 캐싱” (2024년 12월 9일)

• “Especially if you have a large site with rarely-changing content under individual URLs, allowing caching locally may help your site be crawled more efficiently. Google’s crawling infrastructure supports heuristic HTTP caching as defined by the HTTP caching standard, specifically through the ETag response- and If-None-Match request header, and the Last-Modified response- and If-Modified-Since request header.” (번역) 「특히 개별 URL의 콘텐츠가 거의 변경되지 않는 대규모 사이트라면 로컬 캐싱을 허용하는 것이 사이트가 더 효율적으로 크롤링되는 데 도움이 될 수 있습니다. Google의 크롤링 인프라는 HTTP 캐싱 표준에 정의된 휴리스틱 HTTP 캐싱을 지원하며 ETag 응답 헤더와 If-None-Match 요청 헤더, Last-Modified 응답 헤더와 If-Modified-Since 요청 헤더를 사용합니다.」 게시물 읽기
• Google은 ETag를 오류가 적은 기본 검증자로 권장합니다. 게시물 읽기
• “If the ETag value sent by the crawler matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body.” (번역) 「크롤러가 보낸 ETag 값이 서버가 생성한 현재 값과 일치하면 서버는 HTTP 본문 없이 HTTP 304(Not modified) 상태 코드를 반환해야 합니다.」 게시물 읽기
• “Our recommendation is that you require a cache refresh on significant changes to your content; if you only updated the copyright date at the bottom of your page, that’s probably not significant.” (번역) 「콘텐츠에 중대한 변경이 있을 때 캐시 새로고침을 요구하고, 페이지 하단의 저작권 날짜만 업데이트했다면 아마 중대한 변경이 아닐 것입니다.」 게시물 읽기

Patrick Stox — Ahrefs 참고

• Patrick Stox는 304를 변경되지 않은 페이지를 캐시에 활용하는 응답으로 설명합니다. — HTTP 상태 코드와 SEO 영향 가이드에서 발췌(이 글은 해당 항목에서 다루지 못한 내용을 깊이 설명합니다). 인용문으로 이동

“304 Not Modified – Says the page hasn’t been modified. Typically used for caching.” (번역) 「304는 페이지가 변경되지 않았음을 나타내며 일반적으로 캐싱에 사용됩니다.」

맥락 속의 304: 혼동되는 본문 없는 코드와 3xx 코드

304와 비슷해 보이는 코드

함정은 304와 204가 모두 본문이 없고 304/301/302/307/308가 모두 3xx라는 점입니다. 하지만 304는 두 축 모두에서 예외입니다. 아무도 이동시키지 않는 유일한 3xx이고, “보낼 것이 없다”가 아니라 “이미 가지고 있다”는 뜻의 유일한 본문 없는 코드입니다.

두 검증자

두 검증자가 모두 있으면 If-None-Match가 If-Modified-Since보다 우선합니다.

빠른 사실 확인

• 304에는 절대 본문이 없습니다 — RFC 9110이 규범적으로 정합니다.
• 304는 3xx 코드지만 리디렉션은 아닙니다(Location도 새 URL도 없음).
• 직접적인 순위 효과는 없고, Google이 URL 신호를 다시 계산할 수 있는 것 외의 색인 효과도 없습니다. 이점은 대규모 사이트에서 크롤링 효율을 간접적으로 높일 수 있는 자원 절약입니다.
• Google은 ETag를 기본값으로 권장하며 ETag와 Last-Modified를 모두 설정해도 괜찮습니다.
• Last-Modified는 “요일, 일 월 연도 시:분:초 시간대 형식” 형식을 사용해야 하며, 그렇지 않으면 무시될 수 있습니다.
• 바닥글의 저작권 연도가 아니라 중요한 콘텐츠 변경에 캐시를 무효화하세요.
• 모든 크롤러 요청이 조건부인 것은 아닙니다 — 캐싱 지원은 크롤러마다 다릅니다.
• Bing은 조건부 GET → 304를 2008년부터 지원해 왔으며 이는 일반적인 HTTP 동작입니다.
• 실제 위험은 오래된 304(콘텐츠가 바뀐 뒤 서버가 304를 반환)이며 로그 분석에서 잡아야 합니다.

“요일, 일 월 연도 시:분:초 시간대 형식” (번역) 「Last-Modified는 이 HTTP 날짜 형식을 사용해야 합니다.」 “요일, 일 월 연도 시:분:초 시간대 형식” (번역) 「Last-Modified는 이 HTTP 날짜 형식을 사용해야 합니다.」 “요일, 일 월 연도 시:분:초 시간대 형식” (번역) 「Last-Modified는 이 HTTP 날짜 형식을 사용해야 합니다.」 “Weekday, DD Mon YYYY HH:MM:SS Timezone” (번역) 「Last-Modified는 이 HTTP 날짜 형식을 사용해야 합니다.」

원시 HTTP로 보는 조건부 요청 핸드셰이크

304가 만들어지는 방식을 보여 주는 구체적인 요청/응답 연결입니다. (헤더 값은 예시입니다.)

ETag / If-None-Match — 첫 번째 가져오기(200)

GET /blog/my-article/ HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "a1b2c3d4"
Cache-Control: max-age=3600

<full page body here>

클라이언트는 본문과 ETag 값을 저장합니다.

ETag / If-None-Match — 다음 가져오기, 콘텐츠 변경 없음(304)

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-None-Match: "a1b2c3d4"

HTTP/1.1 304 Not Modified
ETag: "a1b2c3d4"
Cache-Control: max-age=3600

본문이 없습니다. ETag가 일치했으므로 서버는 페이지를 생성하는 계산과 전송 대역폭을 절약했습니다. 클라이언트는 캐시 사본을 재사용합니다.

Last-Modified / If-Modified-Since — 날짜 기반 방식

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT

HTTP/1.1 304 Not Modified
Last-Modified: Fri, 4 Sep 1998 19:15:56 GMT

정확한 HTTP 날짜 형식인 “요일, 일 월 연도 시:분:초 시간대 형식”에 주의하세요. Google은 파싱 문제를 피하기 위해 이 형식을 권장합니다.

콘텐츠가 변경된 경우 — 304가 아니라 새로운 200

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-None-Match: "a1b2c3d4"

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "e5f6g7h8"          ← new value: content changed

<updated page body here>

저장된 ETag가 더 이상 일치하지 않으므로 서버는 새 콘텐츠와 새 검증자를 보냅니다. 캐시가 업데이트됩니다. 이것이 올바르게 구현된 304가 크롤러를 오래된 콘텐츠에 “가둘” 수 없는 이유입니다. 콘텐츠가 바뀌는 순간 검증자도 바뀌고 다음 요청은 실제 200을 받습니다.

약한 ETag와 강한 ETag

ETag: "a1b2c3d4"      ← strong: asserts byte-for-byte identity
ETag: W/"a1b2c3d4"    ← weak: asserts semantic equivalence (the W/ prefix)

경험칙: 변경이 드문 URL이 많은 대규모 사이트를 운영한다면 안정적인 ETag를 200 응답에 보내고 If-None-Match를 처리하세요. 그러면 크롤러는 본문 없는 저렴한 304로 “아직 같은지” 확인할 수 있고, Google이 나머지 사이트를 더 효율적으로 크롤링하는 데 간접적으로 도움이 될 수 있다고 말하는 대역폭과 계산을 절약합니다. 재압축 때마다 또는 로드 밸런싱된 서버 간에 ETag가 바뀌면 이 이점을 잃습니다.

조건부 캐싱을 망가뜨리는 304 실수

표현이 바뀌지 않았는데 ETag를 변경함

서버 인스턴스, 압축 단계 또는 요청 타임스탬프에 연결된 ETag는 검증자의 목적을 무너뜨립니다. 변경되지 않은 콘텐츠가 계속 전체 200을 반환하기 때문입니다. 표현에서 안정적인 검증자를 생성하거나 바이트 수준의 차이가 중요하지 않을 때는 약한 ETag를 의도적으로 사용하세요.

콘텐츠가 바뀐 뒤 304를 반환함

오래된 검증자는 클라이언트와 크롤러가 실제 업데이트를 보지 못하게 할 수 있습니다. 표현이 바뀔 때마다 ETag를 무효화하거나 Last-Modified를 앞당긴 다음, 이전 조건부 요청이 새 본문을 포함한 새로운 200을 받는지 확인하세요.

일치하는 조건부 요청 없이 304를 보냄

서버는 클라이언트가 캐시 사본을 가지고 있다고 추측해서는 안 됩니다. If-None-Match 또는 If-Modified-Since를 평가한 뒤에만 304를 반환하세요. 일반적인 첫 요청에는 완전한 응답이 필요합니다.

304를 리디렉션이나 빈 페이지처럼 취급함

304에는 Location 헤더도 응답 본문도 없습니다. 리디렉션 로직으로 처리하지 말고, 실제 빈 리소스를 304로 대체하지도 마세요. 실제 응답을 설명하는 상태 코드를 사용하세요.

흔한 304 문제

서버가 항상 200을 반환함

증상: 아무것도 바뀌지 않았는데도 반복 요청이 전체 본문을 다운로드합니다. 가능한 원인: 초기 응답에 검증자가 없거나 애플리케이션이 조건부 요청 헤더를 무시합니다. 해결: ETag 및/또는 유효한 Last-Modified를 보낸 뒤 일치하는 If-None-Match 또는 If-Modified-Since 검사를 구현하세요. 변경되지 않은 요청이 본문 없는 304를 반환하는지 확인합니다.

서로 다른 원본 서버가 서로 다른 ETag를 생성함

증상: 로드 밸런서 뒤에서 변경되지 않은 같은 URL이 200과 304 사이를 오갑니다. 가능한 원인: 각 노드가 자신의 검증자를 생성합니다. 해결: ETag를 제공 노드가 아니라 공유 콘텐츠 상태에서 만들고, 여러 응답에 같은 조건부 요청을 반복해 보세요.

업데이트된 콘텐츠가 여전히 304를 반환함

증상: 배포 후에도 브라우저나 크롤러가 오래된 표현을 계속 사용합니다. 가능한 원인: 콘텐츠와 함께 검증자를 무효화하지 않았습니다. 해결: 캐시 키 또는 배포 로직을 수정하고, 필요한 곳에서 영향을 받은 캐시를 비운 뒤, 이전 ETag가 새 검증자와 함께 200을 받는지 입증하세요.

Last-Modified가 무시되는 것처럼 보임

증상: If-Modified-Since가 304를 전혀 만들지 않습니다. 가능한 원인: 잘못된 HTTP 날짜, 부족한 타임스탬프 정밀도 또는 우선순위를 차지하는 ETag입니다. 해결: 원시 헤더를 검사하고 날짜 형식을 수정한 뒤 각 검증자를 별도로 테스트하세요.

애플리케이션 코드에서 304가 오류처럼 보임

증상: 실제로는 304를 받은 요청인데 스크립트나 앱이 예외를 발생시키거나 “오류”를 기록합니다. 가능한 원인: 일부 HTTP 클라이언트 라이브러리는 리디렉션을 따르거나 not-modified 응답을 허용하도록 명시적으로 구성하지 않는 한 유효한 304를 포함한 200이 아닌 모든 상태를 예외와 유사한 조건으로 취급합니다. 이는 프로토콜이나 서버 문제가 아니라 클라이언트 라이브러리의 특성입니다. 해결: 4xx/5xx 오류 처리뿐 아니라 304 처리를 구체적으로 확인하고, 서버를 탓하기 전에 원시 HTTP 응답이 정확하고 본문 없는 304인지 확인하세요.

플랫폼 캐싱 계층(예: IIS 출력 캐싱)이 상황을 흐림

증상: 원본 앱은 올바르게 보이지만 304 동작은 여전히 잘못된 것처럼 보입니다. 가능한 원인: IIS 출력 캐싱처럼 호스팅 플랫폼에 특화된 캐싱 계층이 앱과 클라이언트 사이에 놓여 304 응답을 자체적으로 생성하거나 가로챕니다. 해결: 이를 기본 용의자로 보지 말고 원본 앱, CDN, 로드 밸런서, 플랫폼 캐시 중 하나의 계층으로 다루세요. 각 계층에서 검증자를 한 번에 하나씩 바꾸는 통제된 테스트로 담당 계층을 분리한 뒤 결론을 내립니다.

프롬프트: 조건부 요청 추적 감사

첫 번째 가져오기와 반복 가져오기에서 나온 요청 및 응답 헤더를 붙여 넣으세요.

Act as an HTTP caching reviewer. I will paste two request/response header traces for
the same URL: an initial fetch and a conditional repeat. Identify the validator used,
check whether If-None-Match or If-Modified-Since was evaluated correctly, verify that
a 304 has no body or Location header, and flag unstable or stale-validator risks.
Return: observed flow, pass/fail checks, likely cause of each failure, and the exact
next request I should run. Do not infer headers that are not present.

[PASTE BOTH TRACES]

프롬프트: ETag 구현 검토

관련 애플리케이션, CDN 또는 서버 설정을 붙여 넣으세요.

Review this ETag/Last-Modified implementation for conditional GET correctness. Trace
the 200 -> conditional request -> 304 path, explain what causes the validator to
change, and test mentally for multiple origin nodes, compression variants, and real
content updates. Separate protocol violations from efficiency issues. Give a minimal
fix and a curl-based validation plan. Do not invent platform behavior.

[PASTE CONFIGURATION OR CODE]

셸: ETag를 조건부 요청으로 재현

macOS/Linux 터미널에서 실행하세요. 따옴표를 포함해 ETag를 정확히 복사하세요.

URL='https://example.com/page'
curl -sS -D - -o /dev/null "$URL"
curl -sS -D - -o /dev/null -H 'If-None-Match: "PASTE_ETAG_HERE"' "$URL"

첫 번째 응답에 검증자가 나타나야 합니다. 두 번째 응답은 표현이 변경되지 않았다면 304를, 붙여 넣은 ETag가 오래되었다면 200을 반환해야 합니다.

PowerShell: Last-Modified 테스트

URL과 타임스탬프를 바꾼 뒤 PowerShell에서 실행하세요.

$url = 'https://example.com/page'
$headers = @{ 'If-Modified-Since' = 'Tue, 14 Jul 2026 12:00:00 GMT' }
Invoke-WebRequest -Uri $url -Headers $headers -SkipHttpErrorCheck

DevTools 콘솔: 페이지 리소스 검증자 나열

브라우저 콘솔에서 실행하세요. 리소스 타이밍 항목을 보고하며, 실제 ETag, Last-Modified 및 상태 헤더를 확인하려면 Network 패널을 사용하세요.

console.table(performance.getEntriesByType('resource').map(r => ({name: r.name, transferSize: r.transferSize, encodedBodySize: r.encodedBodySize})));

304 동작을 검사하는 도구

• HTTP Header Checker: 정상 응답에서 ETag, Last-Modified, Cache-Control, Vary 및 CDN/엣지 지문을 확인한 뒤 검증자를 재현합니다.
• 브라우저 DevTools Network 패널: “Disable cache”를 끄고 새로고침한 뒤 요청/응답 헤더를 비교합니다. DevTools에서는 HSTS와 로컬 캐시 동작도 보이므로 브라우저 동작과 원본이 보낸 내용을 구분하세요.
• curl: 브라우저 캐시 상태가 방해하지 않도록 정확한 If-None-Match 또는 If-Modified-Since 헤더를 보냅니다.
• 액세스 로그: 어떤 크롤러 요청이 조건부였고 304 또는 전체 200으로 끝났는지 수치화합니다.

변경 후에도 조건부 응답이 작동함을 입증하기

변경되지 않은 표현 테스트

실행할 테스트: URL을 가져와 ETag를 복사한 뒤 curl -I -H 'If-None-Match: "VALUE"' URL로 반복합니다. 예상 결과: 304, 일치하는 검증자, 본문과 Location 없음. 실패 해석: 서버가 조건을 무시했거나 불안정한 검증자를 생성했습니다. 모니터링 창: 즉시. 롤백 트리거: 캐싱 변경으로 일반 요청이 완전한 200 응답을 잃습니다.

변경된 표현 테스트

실행할 테스트: 실제 콘텐츠 변경을 배포한 뒤 이전 ETag를 재현합니다. 예상 결과: 업데이트된 본문과 새 검증자가 포함된 200. 실패 해석: 캐시 무효화가 오래되었습니다. 모니터링 창: 배포가 모든 원본에 도달한 직후. 롤백 트리거: 롤아웃이 끝난 뒤에도 어느 원본이든 이전 검증자에 대해 304를 반환합니다.

여러 원본의 안정성 테스트

실행할 테스트: 제공 풀에 도달할 만큼 같은 일반 요청과 조건부 요청을 반복하고 ETag와 상태를 기록합니다. 예상 결과: 변경되지 않은 표현은 호환되는 검증자를 사용하고 일관되게 304를 만듭니다. 실패 해석: 일치하는 Vary 전략 없이 노드나 인코딩에 따라 검증자가 달라집니다. 모니터링 창: 배포된 풀 전체에서 즉시. 롤백 트리거: 새 검증자 로직이 오래된 콘텐츠를 제공하거나 클라이언트 사이에 표현을 섞습니다.

조건부 캐시 상태 측정

조건부 재검증 성공률

지표: 304로 끝나는 조건부 요청과 전체 200의 비교. 알려 주는 것: 변경되지 않은 리소스가 불필요한 전송을 피하는지 여부. 가져오는 방법: If-None-Match 또는 If-Modified-Since가 있는 액세스 로그 요청을 응답 상태와 URL 분류별로 그룹화합니다. 벤치마크/현실적 범위: 콘텐츠 유형별 기준선을 세우세요. 자주 바뀌는 페이지를 정적 자산의 비율로 맞추도록 강제해서는 안 됩니다. 주기: 롤아웃 중 매주, 이후 매월.

변경되지 않은 가져오기에서 절약한 바이트

지표: 유효한 304 응답에서 전송되지 않은 것으로 추정되는 응답 본문 바이트. 알려 주는 것: 크롤링 효율 이점 중 대역폭 측면. 가져오는 방법: 304 로그 수를 같은 URL 분류의 가장 최근 완전한 응답 크기와 결합합니다. 벤치마크/현실적 범위: 사이트 자체의 변경 전 기준선과 비교하세요. 모든 콘텐츠 구성에 맞는 보편적인 목표는 없습니다. 주기: 매월.

오래된 검증자 실패

지표: 이전 검증자를 여전히 받아들이는 변경된 URL. 알려 주는 것: 효율성이 최신성을 희생한 결과인지 여부. 가져오는 방법: 배포 전 ETag를 재현하는 작은 배포 후 표본을 실행합니다. 벤치마크/현실적 범위: 확인된 오래된 응답은 조사해야 합니다. 주기: 캐싱 또는 검증자 생성을 변경하는 모든 배포마다.

스스로 테스트하기: 304 Not Modified

304의 의미와 작동 방식을 묻는 짧은 질문 다섯 개입니다. 각 답을 고른 다음 확인하세요.

변경 내역