크롤링 오류·리디렉션 해결 가이드 — 404·5xx·소프트 404·301 총정리

크롤링 오류는 검색엔진 로봇이 페이지를 요청했을 때 정상 응답(200)을 받지 못한 상태입니다. 원칙은 네 가지입니다. 살아 있는 페이지는 200, 주소가 바뀐 페이지는 한 번의 301, 없어진 페이지는 404 또는 410, 예정된 점검은 503을 반환합니다. 이 원칙에서 어긋난 곳을 찾아 바로잡는 것이 크롤링 오류 관리의 전부입니다.

상태 코드별로 검색엔진은 어떻게 반응하나요?

검색엔진은 화면에 보이는 내용보다 서버가 보낸 HTTP 상태 코드를 먼저 봅니다. 구글 검색 센터 문서를 기준으로 정리하면 다음과 같습니다.

한국 사이트에서 자주 보는 함정은 해외 IP 차단입니다. 구글봇은 주로 미국 IP에서 크롤링하므로, 호스팅이나 보안 플러그인에서 해외 접속을 막으면 구글봇까지 403을 받습니다. 방화벽·WAF 규칙이 검색엔진 로봇을 막고 있지 않은지 먼저 확인하세요.

5xx 서버 오류와 점검 중 페이지는 어떻게 처리하나요?

5xx는 서버가 요청을 처리하지 못했다는 뜻입니다. 구글은 5xx를 받으면 서버 부담을 줄이려고 크롤링 속도를 낮추고, 오류가 오래 이어지면 이미 색인된 페이지도 검색 결과에서 뺍니다. 접속이 몰릴 때만 502·504가 난다면 서버 로그의 시간대를 보고 PHP 워커 수, DB 연결, 타임아웃 설정을 점검합니다.

예정된 점검이라면 503 상태 코드와 Retry-After 헤더를 보내는 것이 정석입니다. 점검 안내 화면을 200으로 보내면 그 문구가 색인될 수 있고, 404로 보내면 삭제된 페이지로 처리됩니다. Laravel의 php artisan down처럼 프레임워크의 점검 모드는 대부분 503을 반환합니다. 특히 robots.txt가 5xx를 반환하면 구글이 사이트 전체 크롤링을 멈출 수 있으니 robots.txt 가이드도 함께 확인하세요.

소프트 404는 왜 생기고 어떻게 고치나요?

소프트 404는 사용자에게는 「페이지를 찾을 수 없습니다」나 빈 화면이 보이는데 서버는 200을 보내는 상태입니다. 구글은 이런 페이지를 색인하지 않고, 서치 콘솔 페이지 색인 생성 보고서에 「소프트 404」로 표시합니다. 흔한 원인은 다음과 같습니다.

• 삭제된 상품·게시글 주소에서 「없는 상품입니다」 안내만 200으로 보여 주는 경우
• 결과가 0건인 검색·필터 페이지, 상품이 하나도 없는 빈 카테고리
• React·Vue 같은 SPA가 존재하지 않는 경로에도 index.html을 200으로 돌려주는 경우
• 삭제한 페이지를 모두 홈페이지로 리디렉션한 경우

해결 원칙은 없는 페이지는 서버가 404(또는 410)를 반환하게 하는 것입니다. 404 안내 화면을 친절하게 꾸며도 상태 코드만 404면 문제없습니다. SPA에서 서버 응답을 바꾸기 어렵다면 오류 화면에 <meta name="robots" content="noindex">를 넣는 방법을 구글이 대안으로 안내합니다. 품절 상품은 재입고 예정이면 200을 유지한 채 품절 표시만 하고, 영구 단종이면 후속 상품으로 301을 걸거나 404를 반환합니다.

301과 302, 무엇을 언제 써야 하나요?

둘 다 사용자를 새 주소로 보내지만 검색엔진에 주는 신호가 다릅니다. 301은 「이제 새 주소가 대표」라는 강한 신호라서 색인이 새 주소로 옮겨 가고, 302는 원래 주소를 계속 대표로 둘 가능성이 큽니다. 주소를 영구적으로 바꿨는데 302를 쓰면 예전 주소가 검색 결과에 오래 남습니다.

302가 섞이는 이유는 대부분 도구의 기본값입니다. PHP의 header('Location: ...'), Laravel의 redirect(), Express의 res.redirect()는 따로 지정하지 않으면 302를 보내므로 영구 이동이라면 301을 명시하세요. 메타 새로고침이나 자바스크립트 리디렉션은 서버 설정을 바꿀 수 없을 때만 쓰는 차선책입니다. 네이버 로봇(Yeti)은 자바스크립트 실행이 제한적이라 서버 리디렉션이 가장 안전합니다.

Nginx에서는 모든 변형 주소를 최종 주소로 한 번에 보내도록 설정합니다.

# http://example.com, http://www.example.com → https://www.example.com
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

# https://example.com → https://www.example.com
server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate 설정 생략
    return 301 https://www.example.com$request_uri;
}

# 본 사이트 server 블록 안에서 개별 페이지 이동
location = /old-page {
    return 301 https://www.example.com/new-page;
}

HTTP에서 HTTPS로 옮기는 전체 과정은 HTTPS·보안 헤더 가이드에서 다룹니다.

리디렉션 체인과 루프는 어떻게 찾고 없애나요?

리디렉션 체인은 A→B→C처럼 여러 번 거쳐야 최종 페이지에 닿는 상태입니다. 구글봇은 최대 10단계까지 따라가지만, 단계마다 응답 시간이 늘고 신호 전달도 불안정해집니다. 터미널에서 curl로 바로 확인할 수 있습니다.

$ curl -sIL http://example.com/about | grep -iE "^(HTTP|location)"
HTTP/1.1 301 Moved Permanently
Location: https://example.com/about
HTTP/2 301
location: https://www.example.com/about
HTTP/2 301
location: https://www.example.com/about/
HTTP/2 200

위 예시는 3단계를 거칩니다. http·https, www 유무, 끝 슬래시 규칙을 하나로 합쳐 어떤 주소로 들어와도 1단계 만에 최종 주소에 닿게 하고, 내부 링크는 처음부터 최종 주소를 쓰게 고칩니다.

리디렉션 루프는 A→B→A처럼 끝나지 않는 상태로, 브라우저에 ERR_TOO_MANY_REDIRECTS 오류가 뜹니다. 대표 원인은 세 가지입니다.

• Cloudflare SSL 모드가 Flexible인데 원본 서버가 다시 HTTPS로 보내는 경우 → SSL/TLS 모드를 Full (strict)로 바꿉니다.
• CMS의 사이트 주소 설정(www 포함)과 서버 규칙(www 제거)이 서로 반대인 경우
• 끝 슬래시를 붙이는 규칙과 떼는 규칙이 동시에 있는 경우

깨진 내부 링크는 어떻게 찾고 고치나요?

깨진 내부 링크는 사이트 안의 링크가 404나 오류 페이지를 가리키는 것입니다. 사용자는 막다른 길을 만나고, 검색엔진은 크롤링 자원을 낭비합니다.

1. 서치 콘솔 확인: 페이지 색인 생성 보고서의 「찾을 수 없음(404)」 목록을 보고, URL 검사에서 어느 페이지가 링크했는지(참조 페이지) 확인합니다. 외부 사이트의 잘못된 링크도 섞여 있으니 내부 링크에서 온 것부터 고칩니다.
2. 크롤러 실행: Screaming Frog SEO Spider(무료판은 500 URL까지) 같은 도구로 사이트 전체 링크의 상태 코드를 수집합니다.
3. 템플릿부터 수정: 메뉴·푸터·배너처럼 모든 페이지에 들어가는 링크 하나가 수백 건의 오류를 만듭니다.
4. 링크 자체를 고치기: 리디렉션으로 덮기보다 링크 주소를 최종 URL로 바꾸는 것이 근본 해결입니다. 외부 링크가 들어오는 옛 주소에만 301을 추가합니다.

사이트맵에 404나 리디렉션되는 주소가 있어도 같은 문제가 생깁니다. XML 사이트맵 가이드와 내부 링크 가이드를 함께 참고하세요.

사이트를 옮길 때 무엇을 주의해야 하나요?

도메인 변경, 쇼핑몰 솔루션 교체, URL 구조 개편은 크롤링 오류가 한꺼번에 생기는 시점입니다. 다음 순서로 준비하세요.

• 기존 URL 전체 목록을 확보했다 (사이트맵, 서치 콘솔 실적 보고서, 방문 분석 도구)
• 옛 URL과 새 URL의 1:1 대응표를 만들었다 (전부 홈으로 보내지 않는다)
• 서버 측 301로 한 번에 최종 주소로 보낸다
• 새 사이트의 canonical, 내부 링크, hreflang, 사이트맵을 새 주소로 바꿨다
• 개발 서버에서 쓰던 noindex나 robots.txt 차단이 남아 있지 않다
• 도메인을 바꿨다면 서치 콘솔 「주소 변경」 도구를 실행하고, 네이버 서치어드바이저에도 새 사이트를 등록해 사이트맵을 제출했다
• 리디렉션을 최소 1년 이상 유지하고, 옛 도메인은 계속 보유한다
• 이전 후 몇 주 동안 서버 404 로그와 페이지 색인 생성 보고서를 확인한다

이전 직후의 일시적인 순위 변동은 흔합니다. 구글은 중간 규모 사이트라면 대부분의 페이지가 새 주소로 옮겨 가는 데 몇 주가 걸릴 수 있다고 안내합니다.

SEO Check에서는 이렇게 점검합니다

무료 SEO 진단은 서버 응답과 리디렉션을 다음 기준으로 확인합니다.

• HTTP 상태: 홈페이지가 최종적으로 200을 반환하는지, 4xx·5xx 오류가 없는지
• HTTPS 이동: http:// 요청이 301 영구 이동으로 https://에 연결되는지
• www 통일: www와 non-www 중 한쪽 주소로 모이는지
• 리디렉션 단계: 최종 주소까지 1단계 이내면 통과, 2단계 이상이면 체인으로 경고
• 사이트맵 표본 URL: 사이트맵의 URL이 리디렉션 없이 200을 반환하는지
• robots.txt 응답: 5xx 오류로 크롤링이 막히지 않는지

정밀진단 리포트는 사이트 안 30페이지를 크롤링해 페이지별 상태 코드, 깨진 내부 링크, noindex, 응답 속도를 목록으로 보여 줍니다. 크롤링·색인 관리 전반은 전자책 PART 5. 기술적 SEO에서 더 자세히 다룹니다.