SEO용 HTTP 상태 코드: 200, 301, 404, 503

URL이 사라지면 엔지니어는 SEO팀에 “이 페이지는 어떤 상태를 반환해야 하나요?”라고 묻곤 합니다. 답은 외운 표만으로 결정되지 않습니다. 동등한 리소스가 있는지, 중단이 임시적인지 영구적인지, 다음 방문에서 크롤러가 무엇을 하길 원하는지에 따라 달라집니다.

잘못된 상태는 계속 200을 반환하는 오류 페이지, 긴 리디렉션 체인, 크롤링을 감소시키는 수천 개의 503 응답을 만들 수 있습니다. 올바르게 선택하면 브라우저, 검색 봇, 캐시, 모니터링 시스템, 유지보수 담당자가 같은 상태를 이해합니다.

HTTP 상태 코드는 서버가 보내는 메시지입니다

브라우저나 크롤러가 URL을 요청할 때마다 서버는 상태 코드로 응답합니다. 주요 다섯 그룹은 다음과 같습니다.

• 1xx: 처리 중의 정보 응답.
• 2xx: 요청이 성공적으로 처리됨.
• 3xx: 다른 주소나 상태로 이동해야 함.
• 4xx: 클라이언트가 보낸 형태로는 요청을 처리할 수 없음.
• 5xx: 서버가 유효한 요청을 완료할 수 없음.

SEO에서는 상태 코드가 사용자가 보는 내용과 일치해야 합니다. “상품을 찾을 수 없습니다”라고 표시하면서 200 OK를 반환하면 소프트 404가 됩니다. 전체 콘텐츠를 보여주면서 500을 반환하면 크롤러가 그 내용을 무시할 수 있습니다. 상태와 본문이 서로 다른 이야기를 해서는 안 됩니다.

2xx 그룹: 성공이 색인을 보장하지는 않습니다

200 OK: 정상 응답

200은 서버가 성공적으로 응답했다는 뜻입니다. Google이 콘텐츠를 다음 처리 단계로 넘길 수 있지만 색인을 보장하지는 않습니다. noindex, 다른 URL을 가리키는 표준 URL, 낮은 콘텐츠 가치, 중복, 부족한 품질 신호 때문에 제외될 수 있습니다.

실제 콘텐츠가 있는 URL에만 200을 반환하세요. 상품이나 글을 삭제한 뒤 모든 주소를 계속 “살려 두는” 수단으로 사용하지 마세요.

204 No Content: 본문 없음

204는 요청은 성공했지만 본문이 없다는 뜻입니다. 일부 API나 콘텐츠가 필요 없는 작업에는 적합하지만 검색에 노출하려는 랜딩 페이지에는 맞지 않습니다. 빈 HTML 페이지는 성공 그룹의 상태를 반환해도 유용한 결과가 될 수 없습니다.

206 Partial Content: 부분 콘텐츠

206은 클라이언트가 동영상이나 대용량 파일의 특정 범위를 요청할 때 흔히 사용됩니다. HTML 문서의 일반적인 기본 코드는 아닙니다. CDN이나 프록시가 갑자기 모든 페이지에 206을 반환한다면 범위 요청 및 캐시 규칙을 점검하세요.

3xx 그룹: 의도적인 주소 이동

301 Moved Permanently: 영구 이동

URL을 영구적으로 옮겼고 동등한 대체 목적지가 있다면 301을 사용하세요. 대표적인 경우는 다음과 같습니다.

• 글의 슬러그 변경.
• HTTP에서 HTTPS로 전환.
• 검색 의도가 같은 두 글의 통합.
• 카테고리 구조 변경.
• 기존 상품을 실제로 동등한 후속 버전으로 연결.

목적지는 이전 URL이 충족하던 요구와 일치해야 합니다. 단종 상품을 홈페이지나 지나치게 넓은 카테고리로 리디렉션하면 방문자를 불편하게 하고 소프트 404로 처리될 수 있습니다.

302 Found: 임시 이동

302는 짧은 실험, 대체 주소가 있는 유지보수 페이지, 한시적인 트래픽 분배, 원래 URL로 돌아갈 캠페인 등 임시 리디렉션에 적합합니다. 이동이 영구적인 것으로 바뀌었다면 301로 변경해 모든 시스템에 의도를 명확히 전달하세요.

실제로 Google은 전체 신호에 따라 여러 리디렉션을 비슷하게 처리할 수 있습니다. 그래도 브라우저, 캐시, 다른 클라이언트, 시스템 유지보수 담당자에게는 올바른 코드를 선택하는 것이 중요합니다.

303 See Other: 다른 리소스 참조

303은 주로 POST 요청 후 클라이언트를 GET으로 결과 페이지에 안내할 때 사용됩니다. 예를 들어 양식을 제출한 사용자를 확인 페이지로 이동시키는 경우입니다. 이는 애플리케이션 패턴이며 SEO용 URL 이전의 주된 도구는 아닙니다.

307과 308

307 Temporary Redirect와 308 Permanent Redirect는 리디렉션 시 HTTP 메서드를 유지합니다. 308은 영구, 307은 임시 이동을 뜻합니다. 일반적인 GET 요청에서는 사이트 이전에 사용할 수 있지만 양식이나 API에 적용하기 전에 기술팀이 메서드 동작을 이해해야 합니다.

리디렉션 체인: 여러 세대의 URL을 거치는 이동

글의 주소가 A에서 B로, 다시 C로 바뀌었다고 합시다. A가 여전히 B로, B가 C로 리디렉션하면 방문할 때마다 두 단계를 거쳐야 합니다. 오래된 웹사이트에서는 의도적으로 설계하지 않았어도 다섯 또는 여섯 홉의 체인이 생길 수 있습니다.

다음과 같은 결과를 초래합니다.

• 사용자와 크롤러의 지연 시간 증가.
• 서버 요청 추가 발생.
• 표준 URL 및 분석 문제의 디버깅 복잡화.
• 중간 홉 오류나 순환 위험 증가.
• 폐기된 구조를 가리키는 내부 링크 유지.

각 이전 주소는 현재 목적지를 직접 가리켜야 합니다. 리디렉션 체인 검사기로 모든 홉, 상태, 순환, 최종 URL을 확인하세요. 이후 내부 링크, 표준 URL, 사이트맵을 갱신해 리디렉션에 계속 의존하지 않고 최종 주소를 사용하세요.

4xx 그룹: URL 또는 접근 권한 문제

400 Bad Request: 잘못된 요청

크롤러와 브라우저의 응답이 다르면 실제 요청과 접근 권한이 있는 서버 또는 엣지 로그를 검토하세요. 공개 Cloudflare 탐지는 WAF 규칙, 헤더 제한이나 계정 정책을 공개하지 않습니다.

401 Unauthorized: 인증 필요

401은 인증을 요구합니다. 로그인 영역, 비공개 API, 권한이 필요한 문서에 적합합니다. 검색 순위를 얻고 싶은 콘텐츠에 크롤러 로그인을 동시에 요구할 수는 없습니다. 크롤링 조절에 401을 사용하지 말고 서버 부하와 URL 구조를 적절한 곳에서 해결하세요.

403 Forbidden: 접근 금지

403은 서버가 요청을 이해했지만 거부했다는 뜻입니다. 지나치게 강한 CDN, WAF, 봇 방어 설정이 정상 크롤러에게 이를 잘못 반환할 수 있습니다. 공개 페이지가 색인에서 사라지기 시작하면 사용자 에이전트 문자열만 믿지 말고 시간, 사용자 에이전트, 검증된 IP를 기준으로 로그를 비교하세요.

404 Not Found: 찾을 수 없음

404는 리소스가 없고 동등한 대체 페이지도 없을 때 올바른 응답입니다. 모든 404가 리디렉션이 필요한 “SEO 오류”는 아닙니다. 잘못 입력한 URL, 완전히 단종된 상품, 삭제된 테스트 글은 정상적으로 404를 반환할 수 있습니다.

404 페이지에는 다음이 권장됩니다.

• 콘텐츠가 더 이상 없다는 점을 짧게 설명합니다.
• 적절하다면 탐색 메뉴와 검색창을 제공합니다.
• 사용자를 자동 이동시키지 말고 관련 영역을 제안합니다.
• 200이 아니라 계속 404 상태를 반환합니다.

410 Gone: 영구 삭제

410은 리소스가 의도적으로 삭제되었음을 명확히 밝힙니다. Google 검색에서는 404와 410 응답이 지속되면 모두 URL이 삭제되거나 색인되지 않는 결과로 이어집니다. 애플리케이션이 리소스의 종료를 알면 410, 단순히 없다면 404를 선택하세요. 더 빠른 삭제만을 기대하며 유효한 404 응답 수천 개를 410으로 바꿀 가치는 거의 없습니다.

429 Too Many Requests: 요청 과다

429는 클라이언트가 너무 많은 요청을 보냈다는 뜻입니다. Google은 이를 서버 과부하 신호로 보고 일시적으로 크롤링 속도를 낮출 수 있습니다. 요청 제한기가 크롤러에 자주 429를 반환한다면 할당량, 캐시, 식별 규칙을 점검하세요. 제한을 완전히 없애는 것도 답은 아닙니다. 목표는 안정적인 서비스 수준입니다.

5xx 그룹: 서버의 처리 실패

500 Internal Server Error: 내부 서버 오류

500은 원인이 특정되지 않은 애플리케이션 또는 서버 오류입니다. 일시적인 오류 몇 건은 발생할 수 있지만 많은 URL에서 비율이 높다면 배포 버전, 데이터베이스, 의존 요소, 시스템 자원에 문제가 있다는 신호입니다.

502 Bad Gateway: 잘못된 게이트웨이 응답

502는 프록시나 CDN이 업스트림에서 유효한 응답을 받지 못할 때 주로 발생합니다. 애플리케이션 서버 상태, 계층 사이의 시간 제한, 내부 DNS, 연결 제한을 확인하세요.

503 Service Unavailable: 서비스 이용 불가

503은 일시적인 유지보수나 과부하에 적합합니다. Retry-After 헤더로 클라이언트에 재시도 시점을 알릴 수 있습니다. 유지보수 페이지는 200이 아니라 503을 반환해야 합니다. 그렇지 않으면 검색엔진이 모든 URL에서 똑같은 “유지보수 중” 페이지를 볼 수 있습니다.

사이트가 실제로 종료되었거나 URL이 사라졌다면 503을 여러 날 지속시키지 마세요. 서버 오류가 계속되면 색인된 URL이 점차 제외되고 사이트 전체의 크롤링 속도가 낮아질 수 있습니다.

504 Gateway Timeout: 게이트웨이 시간 초과

504는 게이트웨이가 업스트림을 너무 오래 기다렸다는 뜻입니다. 느린 데이터베이스 쿼리, 의존 API, 캐시 미스, 가용 워커 고갈, CDN과 서버 사이의 불일치하는 시간 제한을 확인하세요.

상황별 상태 코드 선택표

이 표는 출발점입니다. 전자상거래에서 일시 품절 상품은 상품 정보, 구매 가능 여부, 대안을 제공하면서 계속 200을 반환할 수 있습니다. 영구 단종 상품에 거의 동등한 후속 상품이 있다면 301을 사용할 수 있습니다. 의미 있는 대체품이 없다면 404나 410이 더 정확합니다.

소프트 404: 상태는 성공이지만 콘텐츠는 실패

소프트 404는 주로 다음 상황에서 발생합니다.

• 상품이 없는 페이지가 계속 200을 반환함.
• 모든 잘못된 URL에서 홈페이지를 렌더링함.
• 결과 없는 검색 페이지가 여전히 색인 가능함.
• 콘텐츠가 삭제되어 템플릿에 헤더와 푸터만 남음.
• 관련 없는 URL을 넓은 카테고리로 리디렉션함.

Search Console의 페이지 색인 생성 보고서를 확인하고 영향을 받은 URL을 표본 조사하세요. 분류를 피하려고 오류 템플릿에 문장 몇 개만 추가하지 마세요. 실제 상태를 반환하거나 원래 요구에 진정으로 답하는 콘텐츠를 제공하세요.

Robots.txt는 상태 코드를 대신하지 못합니다

robots.txt에서 /old-page를 차단하면 크롤러에게 본문을 가져올 수 없다는 사실만 전달됩니다. 따라서 페이지가 이동했는지, 사라졌는지, 인증이 필요한지 알 수 없는 상태로 검색결과에 남을 수 있습니다. Robots.txt 검사기로 확인하세요.

URL이 이동했다면 리디렉션하세요. 사라졌다면 404나 410을 반환하세요. 계속 제공하지만 색인을 원하지 않는다면 크롤러가 접근해 noindex를 읽을 수 있게 하세요. Robots.txt 검사기는 우발적인 차단을 찾지만 URL 수명 주기는 여전히 응답에 담겨야 합니다.

정상 URL 몇 개가 아니라 템플릿별로 상태 코드 진단하기

홈페이지가 200을 반환한다고 상품 목록 전체가 정상이라는 뜻은 아닙니다. 다음 템플릿별로 표본을 추출하고 집계하세요.

1. 홈페이지와 기본 탐색 메뉴.
2. 카테고리, 페이지 나누기, 필터.
3. 재고 있음, 일시 구매 불가, 단종 상품.
4. 새 글, 이전 글, 이름 변경 글, 삭제된 글.
5. 매개변수, 대소문자, 슬래시, 호스트명 변형.
6. 사이트맵, robots.txt, 핵심 이미지, 중요 파일.

상태를 표준 URL, 메타 로봇, 사이트맵, 내부 링크와 대조하세요. 301 URL이 사이트맵에 남아 있어서는 안 됩니다. 404 페이지에 내부 링크가 수천 개 연결되어서는 안 됩니다. 색인을 원하는 200 페이지가 다른 곳을 표준 URL로 지정해서는 안 됩니다.

SEO 검사기로 대표 응답과 페이지 내부 신호를 점검한 다음 무료 SEO 진단으로 템플릿 수준에서 반복되는 결함을 찾으세요.

트래픽이 감소하기 전에 모니터링하기

중요 URL의 5xx 비율, 응답 시간, 상태 변경에 대한 알림을 설정하세요. 배포나 사이트 이전 후에는 다음을 포함하는 기본 동작 검사를 실행하세요.

• 홈페이지, 로그인 페이지, 매출 페이지.
• 각 템플릿을 대표하는 URL 하나.
• Robots.txt와 사이트맵 색인.
• 이전 URL의 리디렉션.
• 실제 404를 확인할 존재하지 않는 URL 하나.

서버 로그에는 상태, 경로, 소요 시간, 사용자 에이전트, 요청 ID를 전후 비교에 충분한 기간 동안 보관해야 합니다. 특정 봇이나 지역에만 문제가 있다면 노트북 한 대에서 페이지를 새로고침하는 것보다 로그에서 더 빨리 답을 찾을 수 있습니다.

결론

HTTP 상태 코드는 서버와 클라이언트 사이의 간결한 약속입니다. 검색 시스템은 이를 통해 콘텐츠가 존재하는지, 이동했는지, 사라졌는지, 일시적으로 제공되지 않는지 이해합니다. URL의 실제 수명 주기에 맞는 코드를 선택하고 본문과 일치시키며 이동 후마다 사이트맵과 내부 링크를 정리하세요.

모든 오류를 홈페이지로 리디렉션하거나 빈 페이지에 200을 반환하거나 결정하지 않은 수명 주기를 robots.txt로 가리지 마세요. 명확한 상태 체계는 방문자, 크롤러, 운영자의 추측을 줄여줍니다.

참고 자료: HTTP 상태 코드가 크롤러에 미치는 영향에 관한 Google Search Central 문서 및 리디렉션 처리 가이드.