200 OK는 표준 성공 응답입니다. 내용이 무엇을 뜻하는지는 메서드에 따라 다릅니다. GET이면 요청한 리소스, HEAD면 본문 없이 같은 헤더, POST면 보통 작업 결과나 그에 대한 설명입니다.
200은 기본적으로 캐시할 수 있는(heuristically cacheable) 응답입니다. Cache-Control이나 Expires가 달리 지정하지 않으면, 캐시는 스스로 추정한 기간 동안(흔히 Last-Modified를 기준으로) 이 응답을 저장해 다시 사용할 수 있습니다. ETag, Last-Modified 같은 검증자(validator)가 있으면 클라이언트는 나중에 조건부 요청으로 사본이 아직 최신인지 확인할 수 있으며, 이때 응답은 304 Not Modified가 될 수 있습니다.
200은 콘텐츠가 사용자가 원하던 것인지에 대해서는 아무것도 알려 주지 않습니다. 오류 페이지, 빈 페이지, 로그인 화면이 200으로 제공되는 경우가 있는데, 그러면 브라우저와 모니터링 도구, 검색엔진 모두 문제를 알아차리지 못합니다.
응답 예시
HTTP/1.1 200 OK
Date: Fri, 06 Nov 2026 10:15:32 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 85
Cache-Control: public, max-age=600
ETag: "5f2b-1a3c"
Last-Modified: Wed, 28 Oct 2026 08:02:11 GMT
<!doctype html>
<html lang="en">
<title>Welcome</title>
<h1>Hello, world</h1>
</html>SEO 및 리디렉션 검사
사이트의 표준 URL은 200을 반환해야 하며, 모든 리디렉션 체인의 마지막 홉도 200을 반환하는 URL에서 끝나야 합니다. Google은 200 페이지를 색인 생성 대상으로 검토하지만, 콘텐츠가 “페이지를 찾을 수 없음” 메시지나 빈 페이지처럼 오류로 보이면 Search Console에서 소프트 404로 보고하며 해당 페이지는 색인이 생성되지 않습니다. 없는 페이지에는 실제 404 또는 410 응답을 사용하세요.
리디렉션 검사에서는 영구 리디렉션 한 번 만에 200에 도달하는 체인이 이상적입니다. 최종 URL이 예상한 URL인지 꼭 확인하세요. 리디렉션 후 홈페이지나 로그인 페이지에서 200이 나온다면 딥 링크가 깨졌다는 뜻인 경우가 많습니다. 리디렉션 체인 검사 도구는 최종 200까지 모든 홉을 보여 줍니다.
주요 원인과 사용 사례
- 페이지, 파일 또는 API 리소스가 존재하며 정상적으로 제공되었습니다.
- 소프트 404: 없는 페이지가 “찾을 수 없음” 메시지를 보여 주면서 200을 반환합니다. 대신 404나 410을 보내도록 서버를 설정하세요.
- 오류 페이지나 점검 페이지가 200을 반환합니다. 점검 중에는
Retry-After와 함께 503을 반환하세요. - 봇 확인 페이지나 동의 페이지가 실제 콘텐츠 대신 200을 반환합니다. TrueURL은 흔히 쓰이는 봇 확인(챌린지) 페이지를 따로 표시하지만, 모든 중간 페이지를 알아볼 수는 없습니다.