503 오류
503 오류(503 Service Unavailable)는 서버가 일시적으로 요청을 처리할 수 없는 상태를 나타내는 HTTP 상태 코드로, 주로 서버 과부하나 점검 중에 발생합니다. SEO 관점에서는 사이트 점검 시 503과 Retry-After 헤더를 함께 반환해 크롤러에 다운타임이 일시적임을 알리는 용도로 권장됩니다.
- 503 오류는 서버가 일시적으로 요청을 처리할 수 없음을 뜻하는 상태 코드로, 과부하나 점검 시 발생합니다.
- 사이트 점검 시에는 404나 200이 아니라 503을 반환해 검색 크롤러에 다운타임이 임시임을 알리는 것이 권장됩니다.
- Retry-After 헤더로 복구 예상 시점을 함께 전달하면 Googlebot이 재크롤링 시점을 조정합니다.
- 503이 며칠 이상 지속되면 Google이 영구 다운으로 간주해 해당 URL을 색인에서 제거할 수 있습니다.
- 503은 일시적 응답이므로 캐싱하지 않도록 주의하고, 사용자에게는 상황을 설명하는 안내 페이지를 함께 제공합니다.
개요
503 오류(503 Service Unavailable)는 서버가 요청을 처리할 준비가 되어 있지 않음을 나타내는 서버 오류 응답 상태 코드입니다. MDN 문서에 따르면 가장 흔한 원인은 서버가 점검 중이거나 과부하 상태일 때입니다. 점검 중에는 관리자가 모든 트래픽을 503 페이지로 일시 라우팅하기도 하고, 과부하 시에는 메모리·CPU·연결 풀 같은 자원 한계에 도달하면 일부 서버 애플리케이션이 요청을 503으로 거부해 더 심각한 장애를 막습니다.
핵심은 503이 일시적 조건을 위한 코드라는 점입니다. 페이지가 영구히 사라졌음을 뜻하는 404나, 오류 화면을 정상 응답처럼 보이게 하는 200과 달리, 503은 "지금은 처리할 수 없지만 곧 돌아온다"는 신호를 전달합니다.
SEO 권장 사용
Google Search Central은 계획된 점검으로 사이트를 잠시 내릴 때 404(Not Found)나 200(OK)이 아니라 503을 반환할 것을 권장합니다. 503은 검색 크롤러에 다운타임이 일시적이며 나중에 다시 확인해야 함을 알려 주기 때문입니다. 404를 반복 반환하면 Googlebot이 재크롤링을 미루게 되고, 오류 페이지를 200으로 내보내면 빈 페이지가 정상 콘텐츠로 색인되는 문제가 생깁니다.
함께 사용하는 것이 Retry-After 헤더입니다. MDN에 따르면 Retry-After는 503 응답에서 서비스가 얼마나 오래 사용 불가 상태일지를 나타내며, 두 가지 형식으로 표현됩니다. 응답 수신 후 대기할 초 단위 정수, 또는 다시 시도할 시점을 HTTP 날짜 형식으로 지정하는 방식입니다. Googlebot은 이 헤더를 존중해 재크롤링 시점을 조정합니다.
다만 503을 영구 해결책처럼 사용하면 안 됩니다. Google Search Central은 일시적 다운타임에는 503이 적합하지만, 503이 며칠 이상 지속되면 서버가 영구적으로 사용 불가 상태가 된 신호로 해석해 해당 URL을 Google 색인에서 제거할 수 있다고 명시합니다. 즉 하루 정도의 짧은 점검에는 안전하지만, 일주일 이상 차단하면 사용한 방법과 무관하게 검색 결과에 부정적 영향을 줄 수 있습니다.
주요 상태 코드 비교
| 코드 | 의미 | 크롤러에 주는 신호 | 점검 시 적합성 |
|---|---|---|---|
| 200 OK | 정상 응답 | 현재 콘텐츠가 유효함 | 부적합(빈 오류 페이지가 색인될 위험) |
| 404 Not Found | 페이지 없음 | 리소스가 존재하지 않음 | 부적합(재크롤링 지연, 색인 제외 위험) |
| 503 Service Unavailable | 일시적 사용 불가 | 다운타임이 임시이니 나중에 재확인 | 적합(Retry-After와 함께 권장) |
올바른 처리
점검 페이지를 내보낼 때는 응답 헤더가 실제로 503을 반환하는지 확인하는 것이 가장 중요합니다. Yoast에 따르면 캐시 플러그인이 503 상태를 제대로 전달하지 못하는 경우가 있어, 라이브 사이트에 적용하기 전 반드시 테스트가 필요합니다. 또한 MDN은 503이 일시적 문제이므로 응답을 캐싱하지 않도록 주의해야 한다고 명시합니다. 캐싱하면 수정 배포 이후에도 클라이언트가 오래된 오류 페이지를 받을 수 있기 때문입니다. 사용자에게는 상황을 설명하는 안내 페이지를 함께 제공하는 것이 좋습니다.
Apache(.htaccess) 예시
RewriteEngine On
RewriteCond %{REQUEST_URI} !=/maintenance.html
RewriteRule ^.*$ /maintenance.html [R=503,L]
ErrorDocument 503 /maintenance.html
Header always set Retry-After "3600"Nginx 예시
location / {
return 503;
}
error_page 503 /maintenance.html;
location = /maintenance.html {
add_header Retry-After 3600 always;
internal;
}위 예시의 Retry-After 3600은 1시간(3600초) 뒤 재시도를 의미합니다. 복구 예상 시점을 알 수 있다면 정확한 값을 넣고, 점검이 끝나면 즉시 설정을 해제합니다.
실행 체크리스트
- 계획된 점검 시 404·200이 아닌 503 상태 코드를 반환합니다.
- 503과 함께 Retry-After 헤더로 복구 예상 시간(초 또는 날짜)을 전달합니다.
- 다운타임은 가능한 한 짧게 유지하고, 며칠 또는 일주일 이상 503을 지속하지 않습니다.
- 점검 페이지가 실제로 503을 반환하는지 응답 헤더를 직접 확인합니다(캐시 플러그인 주의).
- 503 응답이 캐싱되지 않도록 캐싱 헤더를 점검합니다.
- 사용자에게는 상황과 복구 예정 시점을 설명하는 안내 페이지를 함께 제공합니다.
- 점검 종료 후 503 설정과 Retry-After 헤더를 즉시 해제합니다.