404 에러 SEO에 미치는 영향 — 둬도 되는 404와 살려야 하는 404 구분법

서치콘솔에 404가 쌓이는데 트래픽이 빠진다 — 이게 진짜 SEO 타격일까

서치콘솔 페이지 보고서에 "찾을 수 없음(404)"이 수십, 수백 건씩 쌓여 있고, 같은 시기에 검색 트래픽도 빠지고 있다면 누구라도 둘을 연결해서 보게 됩니다. 삭제하거나 이동한 페이지가 검색 결과에서 사라지면서 "이게 그래서 SEO 타격인가, 아닌가" 판단이 안 서는 상황이죠. 그런데 실무에서 보면, 대부분은 404 숫자만 보고 불안해하면서 정작 그 404 URL이 어떤 페이지였는지는 확인하지 않습니다.

먼저 결론부터 말씀드리면, 404 에러 SEO에 미치는 영향은 "URL마다 다르다"가 정답입니다. Google Search Central — Do 404s hurt my site?에서도 "404 에러는 사이트 전체 순위에 영향을 주지 않으며, 정상 200 URL의 검색 결과 성능에 영향을 미치지 않는다"고 못 박고 있습니다. 즉 404가 많다고 도메인이 강등되는 일은 없습니다. 문제는 404 자체가 아니라, 404가 되어버린 그 URL이 원래 트래픽이나 백링크를 가지고 있었느냐에서 갈립니다.

저희가 컨설팅하면서 가장 자주 보는 패턴은 이렇습니다. 서치콘솔 404 보고가 늘었다 → 불안한 마음에 일단 모든 404 URL을 홈으로 301 리다이렉트했다 → 그랬더니 이번엔 "soft 404"가 늘었다는 보고가 새로 떴다 → 색인 제거 요청만 누르고 끝냈다 → 백링크가 살아 있던 URL 한두 개에서 권위가 그대로 새고 있다. 이 글에서는 둬도 되는 404와 살려야 하는 404를 어떻게 가르는지, 그리고 서치콘솔 보고서를 어떤 순서로 정리해야 하는지 실무 기준으로 풀어드립니다.

404가 SEO에 영향을 주는 경우와 주지 않는 경우

404 자체는 HTTP 상태 코드일 뿐, 페널티 신호가 아닙니다. Google 검색 센터 — HTTP 상태 코드 가이드를 보면 4xx 응답(429 제외)은 모두 동일하게 처리되며, soft 404는 200 응답이지만 콘텐츠가 오류일 때 발생한다고 명시되어 있습니다. 그래서 진짜로 봐야 하는 건 "404가 났다"가 아니라 "어떤 URL이 404냐"입니다.

괜찮은 404 — 원래 없던 URL, 봇 스캔, 오타 요청

이런 404는 신경 쓸 필요가 거의 없습니다. 예를 들어 /wp-login.php나 /admin/setup.php 같이 워드프레스/PHP 스캐너가 무차별로 찔러보는 URL, 외부 사이트가 잘못 적은 오타 URL, 옛날에 한 번도 색인되지 않은 URL. 이런 건 그대로 404를 유지하는 게 정답입니다. 구글도 시간이 지나면 알아서 크롤 빈도를 줄이거나 색인에서 빼버립니다.

문제 있는 404 — 백링크가 살아있는 페이지

가장 아까운 케이스입니다. 다른 사이트에서 링크를 걸어 줬는데, 정작 우리 사이트에서 그 페이지를 삭제해버린 경우죠. 그 백링크가 가져다주던 권위(link equity)가 그대로 증발합니다. 백링크 분석기로 해당 도메인의 외부 링크를 한 번 점검해보면, 의외로 "내가 지운 줄도 몰랐던 URL"에 백링크가 박혀 있는 경우가 많습니다.

문제 있는 404 — 내부 링크가 향하는 페이지

사이트 내부에서 여전히 그 URL로 링크를 걸고 있는데 정작 페이지는 404라면, 크롤러가 헛걸음을 반복하고 사용자도 막다른 길에 빠집니다. 이건 도메인 페널티는 아니지만 크롤 버짓을 갉아먹고 UX 신호를 떨어뜨립니다. 온페이지 SEO 분석 도구 같은 진단 도구로 깨진 내부 링크를 한 번에 잡아내는 게 빠릅니다.

문제 있는 404 — 검색 트래픽이 들어오던 페이지

최근 3~6개월간 자연 검색에서 클릭이 들어오던 URL이 어느 날 404가 됐다면, 그건 직접적인 트래픽 손실입니다. 이건 무조건 살려야 합니다. 같은 주제의 대체 페이지가 있으면 301로 연결하고, 없으면 콘텐츠를 복원하는 게 우선순위입니다.

둬도 되는 404 vs 살려야 하는 404 — 실무 판단 기준

이제 본론입니다. 둬도 되는 404와 살려야 하는 404를 가르는 기준을 잡는 게 이 글의 핵심입니다. 추상적인 원칙이 아니라 실무에서 그대로 쓸 수 있는 4단계 체크리스트로 정리해드립니다.

1단계: GA4/서치콘솔에서 해당 URL 트래픽 확인

먼저 그 URL이 최근 6개월간 자연 검색에서 클릭이 들어왔는지 확인합니다. 서치콘솔 → 실적 → 페이지 탭에서 URL로 필터링해서 보면 됩니다. GA4의 페이지 보고서에서도 organic 채널의 세션 수를 같이 봅니다. 클릭이 0이라면 "원래 검색에서 안 들어오던 페이지"고, 월 10~수백 클릭이 있었다면 "잃으면 안 되는 페이지"입니다.

2단계: 백링크 체커로 외부 링크 유입 확인

다음은 외부에서 그 URL로 들어오는 링크가 있는지 봅니다. 백링크 도구로 URL 단위 백링크를 조회하면 됩니다. 도메인 권위가 있는 사이트에서 단 한 개라도 dofollow로 링크를 걸어주고 있다면, 그건 살려야 합니다. 권위가 그대로 증발하니까요.

3단계: 사이트 내부 링크 잔존 여부 확인

우리 사이트 안에서 그 URL을 가리키는 내부 링크가 남아 있는지도 봐야 합니다. 크롤러 기반 진단 도구로 사이트 전체를 한 번 돌리거나, 사이트맵과 현재 페이지 목록을 대조해보면 됩니다. 내부 링크가 살아 있다면, 먼저 그 링크부터 새 URL로 갈아끼우거나 제거합니다.

4단계: 판단 — 그대로 404, 301, 410 중 선택

위 세 가지 신호를 종합해서 처리 방식을 정합니다.

404와 410의 차이는 신경 쓸 만큼 크지 않습니다. Search Engine Journal — Mueller의 404 vs 410 해설에서 구글의 John Mueller는 "404와 410의 처리 차이는 너무 미미해서 SEO 목적으로는 어느 쪽을 선호할 이유가 없다"고 말합니다. 다만 "이 페이지는 다시 안 돌아옵니다"라는 의도를 명확히 전달하고 싶다면 410이 더 적합합니다. 구글이 색인에서 빼는 속도가 약간 더 빠르다는 경험은 있지만, 결정적 차이는 아닙니다.

404 처리할 때 흔히 하는 3가지 실수

독자는 트래픽이 빠지는 게 불안해서 404 관련 글을 검색했습니다. 하지만 대부분 404 숫자만 신경 쓰고, 정작 그 404가 어떤 URL인지는 놓칩니다. 이 문제를 해결하려면 먼저 처리 방식을 잘못 선택했을 때 어떻게 더 악화되는지부터 알아야 합니다. 저희가 자주 보는 실수 세 가지입니다.

실수 1: 모든 404를 홈으로 301 리다이렉트 → soft 404로 더 악화

가장 흔하고, 가장 손해 보는 실수입니다. 404가 무서워서 일단 모든 404 URL을 홈으로 301 리다이렉트로 묶어버리는 케이스. 구글은 이걸 곧바로 "soft 404"로 분류합니다. 원래 페이지 콘텐츠와 무관한 곳(홈)으로 보내버리니, 사용자 의도와 맞지 않는 리다이렉트라고 판단하는 거죠.

실수 2: 색인 제거 요청만 누르고 원인 페이지는 그대로 둠

서치콘솔에서 색인 제거 요청은 임시 조치입니다. 약 6개월 후엔 다시 노출됩니다. 원인 URL을 그대로 두고 색인 제거만 반복하면, 같은 404가 보고서에 영원히 따라다닙니다. 진짜 해법은 410으로 응답하거나, 301로 적절한 페이지에 연결하거나, 콘텐츠를 복원하는 것 중 하나입니다.

실수 3: robots.txt로 차단하면 사라질 거라 생각 — 보고서엔 그대로 남음

"robots.txt에서 차단하면 안 보이겠지" 하고 막아버리는 경우가 많은데, 이건 오히려 문제를 키웁니다. 크롤러가 그 URL을 못 가니까 404인지 200인지조차 확인하지 못하고, 서치콘솔 보고서에는 "robots.txt에 의해 차단됨"이라는 새 상태로 남습니다. robots.txt 생성기로 차단 규칙을 만들 때도 "404는 차단이 아니라 응답으로 정리한다"는 원칙은 같습니다. 404 정리에 robots.txt는 쓰지 마세요.

서치콘솔 페이지 보고서에서 404 정리하는 순서

이론은 충분하니 이제 실제로 어떻게 서치콘솔 보고서를 비워나가는지 순서를 보여드립니다. 저희 팀이 매월 돌리는 루틴 그대로입니다.

Step 1: 페이지 보고서에서 '찾을 수 없음(404)' 목록 내보내기

서치콘솔 → 페이지(색인 생성) → "찾을 수 없음(404)" 클릭 → 우상단 내보내기 버튼으로 CSV로 받습니다. 1000개까지 내보낼 수 있습니다. 더 많다면 BigQuery 연동을 쓰거나, 우선순위가 높은 URL부터 처리한다고 생각하면 됩니다.

Step 2: 트래픽·백링크 데이터와 매칭

내보낸 CSV에 두 개 컬럼을 추가합니다. 하나는 GA4/서치콘솔에서 본 최근 6개월 organic 클릭 수, 다른 하나는 백링크 도구에서 가져온 외부 링크 도메인 수. 두 컬럼이 모두 0인 URL은 "그대로 둘 404", 둘 중 하나라도 값이 있는 URL은 "처리 대상"입니다.

Step 3: 처리 방식별로 그룹 분류 (유지/301/410)

처리 대상으로 분류된 URL을 다시 그룹 짓습니다.

• 대체 페이지가 명확한 URL → 301 그룹
• 의도적으로 영구 삭제할 URL → 410 그룹
• 되살릴 가치가 큰 URL → 콘텐츠 복원 그룹
• 나머지(스캐너/오타) → 그대로 404 유지

301과 410 적용은 서버 설정 또는 호스팅 패널에서 합니다. Vercel/Netlify는 redirects 파일, 워드프레스는 플러그인 또는 .htaccess로 처리하면 됩니다.

Step 4: 처리 후 URL 검사 도구로 재크롤 요청

처리를 끝낸 URL은 서치콘솔의 URL 검사 도구에 하나씩 넣어 재크롤을 요청합니다. 한 번에 다 안 빠집니다. 보통 1~4주 사이에 보고서에서 점진적으로 사라지거나 "리다이렉트됨" 상태로 바뀝니다. 사이트맵에서도 죽은 URL이 제거됐는지 점검하세요. 사이트맵 생성기로 새 사이트맵을 만들어 다시 제출하는 것도 좋은 마무리입니다.

커스텀 404 페이지로 이탈을 줄이는 방법

404 처리를 잘해도, 사용자가 실제로 마주치는 404 페이지 자체가 막다른 골목이면 의미가 반감됩니다. SEO 손실이 아니라 UX 손실이 발생하는 거죠. 커스텀 404 페이지에는 최소한 다음 요소가 들어가야 합니다.

• "페이지를 찾을 수 없습니다"라는 명확한 메시지
• 홈 또는 주요 카테고리로 가는 링크 3~5개
• 사이트 검색창
• 최근 인기 글 또는 추천 콘텐츠 링크
• 브랜드 톤과 일치하는 일관된 디자인 (어색한 농담보다는 차분한 안내가 안전합니다)

막다른 페이지에서 다음 동선을 제시하는 것만으로도 이탈이 눈에 띄게 줄어듭니다. 실무에서는 평균적으로 30~40%의 사용자가 추천 링크나 검색을 통해 사이트 안에서 다른 페이지로 이동합니다(자체 측정 기준). 이게 곧 세션 길이와 페이지뷰 증가로 이어지고, 간접적으로 사이트의 사용성 신호를 개선합니다.

정리 — 404를 SEO 자산으로 관리하는 월간 루틴

404는 손대지 않아도 자연스럽게 발생하는 현상이지만, 그렇다고 방치하면 살릴 수 있는 권위를 흘려보내게 됩니다. 핵심은 "404가 났느냐"가 아니라 "어떤 URL이 404이고, 그 URL이 무엇을 가지고 있었느냐"입니다. 마지막으로 매월 30분만 투자해서 돌릴 수 있는 루틴으로 정리해드립니다.

처음 한 번만 시간이 좀 들고, 두 번째 달부터는 새로 추가된 404만 처리하면 되기 때문에 점점 빨라집니다. 익숙해지면 월간 15분이면 충분합니다.

관련해서 같이 보면 좋은 글로는 구글 서치콘솔 사용법, 구글 크롤링 문제 진단 가이드, 구글 색인 요청 방법이 있습니다. 서치콘솔 보고서를 다루는 기본기와 색인 정리를 함께 익혀두시면 404 정리도 훨씬 빨라집니다.