서치 콘솔이 오류로 잡는 상태 코드의 범위

서치 콘솔은 4xx~5xx 범위의 상태 코드와 실패한 리다이렉션(3xx)에 대해 오류 메시지를 생성합니다. 404(찾을 수 없음), 500(서버 오류), 리다이렉트 체인이 끊긴 3xx 응답이 모두 이 리포트에 잡히는데, 오류 유형에 따라 원인이 완전히 다르므로 리포트에 뜬 오류 개수만 보고 놀라기 전에 어떤 유형이 늘었는지부터 구분해야 합니다.

소프트 404는 왜 일반 404보다 더 까다로운가

소프트 404는 페이지가 없다는 메시지를 보여주면서도 상태 코드는 200(성공)으로 응답하는 오류입니다. 사용자 눈에는 "페이지를 찾을 수 없습니다"라고 정상적으로 표시되지만, 서버는 구글에게 "이 페이지는 정상적으로 존재합니다"라고 잘못된 신호를 보내는 셈입니다. 이런 소프트 404는 실제 콘텐츠가 있는 페이지 대신 크롤링되며 크롤 커버리지를 갉아먹을 수 있어, 겉보기에는 사용자 경험상 문제없어 보여도 SEO 관점에서는 조용히 손해를 누적시킵니다.

페이지 상태에 따라 어떤 코드로 응답해야 하나

페이지가 이동했고 대체 페이지가 있으면 301(영구 리다이렉트)로 응답해 사용자 경험을 끊지 않으면서 새 위치를 검색엔진에 알려야 합니다. 페이지가 완전히 삭제됐고 대체할 페이지가 없다면 404(찾을 수 없음) 또는 410(사라짐) 상태 코드로 응답해야 하며, 여기서 200이나 302 같은 엉뚱한 코드를 쓰면 구글이 실제 사이트 구조를 잘못 이해하게 됩니다.

없어진 URL을 홈페이지로 몰아버리면 왜 안 되나

사이트가 알 수 없는 URL 요청을 전부 홈페이지로 리다이렉트하도록 설정해두는 경우가 실무에서 흔히 보이는데, 이는 사용자 편의를 위한 조치처럼 보여도 구글이 이런 패턴을 대량으로 감지하면 소프트 404와 유사하게 취급해 사이트 이해도에 부정적 영향을 줄 수 있습니다. 삭제된 페이지는 관련 카테고리 페이지로 개별 리다이렉트하거나, 대체할 곳이 정말 없다면 차라리 정직하게 404로 응답하는 편이 낫습니다.

커버리지 리포트를 읽을 때 우선순위를 정하는 기준

리포트에 뜨는 오류 URL 수가 많다면 전부를 한 번에 처리하려 하기보다, 최근에 급증한 오류 유형과 실제 트래픽이 있었던 URL을 우선순위로 삼는 것이 효율적입니다. 오래전부터 존재해온 소량의 오류보다, 최근 배포 이후 갑자기 늘어난 오류가 현재 진행형 사고일 가능성이 높기 때문입니다.

오류 원인을 실제로 추적하는 절차

특정 URL이 오류로 잡혔다면 서치 콘솔의 URL 검사 도구로 그 URL을 직접 조회해 구글이 실제로 어떤 응답을 받았는지 확인하고, 필요하면 브라우저 개발자 도구의 네트워크 탭으로 실제 서버 응답 코드를 다시 확인하는 순서가 안전합니다. 서치 콘솔에 표시되는 시점과 실제 재크롤링 시점 사이에는 시차가 있어, 이미 수정한 문제인데도 리포트에는 며칠간 그대로 남아 있을 수 있다는 점도 감안해야 합니다.

대량 오류가 사이트 이관 직후에 몰리는 이유

도메인 변경이나 플랫폼 이전 직후에는 이전 URL 구조와 새 URL 구조 사이에 매핑이 빠진 페이지들이 한꺼번에 오류로 잡히는 경우가 흔합니다. 이관 프로젝트를 진행한다면 이관 전 전체 URL 목록을 미리 확보해두고, 이관 직후 며칠간은 커버리지 리포트를 평소보다 자주 확인하는 일정을 잡아두는 것이 안전합니다.

개발팀에 오류 수정을 요청할 때 전달할 정보

단순히 "404 오류가 많다"고만 전달하지 말고, 서치 콘솔에서 추출한 오류 URL 목록과 각 URL의 오류 유형(404, 리다이렉트 실패 등)을 함께 전달해야 개발팀이 원인을 빠르게 좁힐 수 있습니다. 이 목록 없이 구두로만 전달하면 개발팀이 별도로 오류를 재현하고 찾는 데 불필요한 시간을 쓰게 됩니다.

오류 리포트를 정기적으로 확인하는 담당자를 정해두기

커버리지 리포트는 한 번 확인하고 끝내는 게 아니라 최소 주 1회는 훑어봐야 새로 생긴 오류를 조기에 잡을 수 있는데, 실무에서는 담당자가 명확히 정해지지 않아 몇 달씩 방치되는 경우가 흔합니다. 이 리포트를 주간 마케팅 점검 항목에 포함시켜 놓으면, 개발 배포와 무관하게 서버 설정이나 CDN 캐시 문제로 갑자기 늘어난 오류도 놓치지 않고 발견할 수 있습니다.

리다이렉트 체인이 길어질 때 생기는 부수적 손해

URL이 여러 차례 이관되며 A에서 B로, B에서 C로 리다이렉트가 체인처럼 이어지면 페이지 로딩 속도가 느려지고 크롤러의 대역폭도 불필요하게 소모됩니다. 리다이렉트 체인이 발견되면 중간 단계를 모두 걷어내고 최종 목적지로 한 번에 연결되도록 정리하는 작업을 이관 프로젝트와 별개로도 주기적으로 해줄 필요가 있습니다.

오류 유형별로 담당 부서를 미리 정해두는 이유

404·리다이렉트 오류는 콘텐츠 삭제, 서버 설정 변경, CDN 캐시 문제 등 원인이 제각각이라 한 팀이 전부 처리하기 어려운 경우가 많습니다. 오류 유형별로 어느 팀이 1차로 확인할지(콘텐츠 삭제는 운영팀, 서버 응답 코드는 개발팀 등) 미리 정해두면, 오류가 발견됐을 때 "누구에게 전달해야 하는지"부터 다시 논의하느라 대응이 늦어지는 상황을 줄일 수 있습니다.