404·410·리디렉션·soft 404 처리 기준: 삭제·이동 URL을 올바르게 정리하는 법
없는 페이지는 올바른 404·410을 반환하고, 같은 목적의 새 주소가 있을 때만 영구 리디렉션합니다. 모든 오류를 홈으로 보내면 soft 404와 사용자 혼란이 생길 수 있습니다.
404가 존재한다는 사실 자체는 사이트 품질 문제나 페널티가 아닙니다. 중요한 것은 없는 콘텐츠에 200을 반환하거나, 관련 없는 홈으로 리디렉션해 사용자와 검색엔진을 속이지 않는 것입니다.
삭제·이동·오타·권한 제한은 서로 다른 상황입니다. URL의 과거 역할, 대체 페이지의 관련성, 외부 링크와 트래픽, 복구 가능성을 확인한 뒤 상태 코드와 안내 화면을 선택해야 합니다.
URL 상태별 권장 응답을 결정합니다
| 상황 | 권장 처리 | 후속 작업 |
|---|---|---|
| 영구 삭제, 대체 없음 | 404 또는 410 | 사이트맵·내부 링크 제거 |
| 같은 콘텐츠가 새 주소로 이동 | 301 또는 308 | canonical·사이트맵·내부 링크 갱신 |
| 일시 장애·점검 | 503과 Retry-After 검토 | 짧은 시간 안에 복구·모니터링 |
| 콘텐츠는 있으나 얇거나 빈 결과 | 내용 보강 또는 실제 404 | 200 상태의 오류 화면 방지 |
| 로그인 전용 콘텐츠 | 401·403 또는 인증 흐름 | 검색 노출 제어와 접근 권한 분리 |
사용자에게 친절한 404 화면을 보여주더라도 HTTP 상태가 200이면 soft 404로 해석될 수 있습니다. 브라우저 화면과 네트워크 응답을 모두 확인해야 합니다.
먼저 URL이 왜 없어졌는지 분류합니다
콘텐츠를 삭제했는지, 슬러그가 바뀌었는지, 제품이 일시 품절인지, 필터 조합이 빈 결과인지 기록합니다. 원인을 모른 채 리디렉션하면 관련 없는 페이지로 사용자를 보내거나 복구 가능한 콘텐츠를 잃을 수 있습니다.
Search Console 예시 URL, 서버 로그의 404 요청, 외부 링크 보고서를 합쳐 빈도가 높은 URL부터 봅니다. 모든 404를 없애는 것이 목표가 아니라 가치 있는 요청에 적절한 응답을 제공하는 것이 목표입니다.
대체 페이지가 같은 의도를 해결할 때만 리디렉션합니다
이전 제품과 사실상 같은 후속 모델, 통합된 가이드, 변경된 대표 URL처럼 사용자의 목적을 이어받는 페이지가 있다면 영구 리디렉션을 사용합니다. 제목에 같은 단어가 있다는 이유만으로 카테고리나 홈으로 보내지 않습니다.
여러 URL을 하나로 통합했다면 새 페이지가 이전 문서의 핵심 정보를 충분히 포함하는지 확인합니다. 리디렉션 체인은 한 단계로 줄이고 HTTP·HTTPS, 호스트, 끝 슬래시 규칙을 일관되게 적용합니다.
404와 410은 검색엔진보다 운영 의미를 기준으로 고릅니다
404는 리소스를 찾을 수 없음을, 410은 의도적으로 영구 제거됐음을 더 명확히 표현합니다. 둘 다 시간이 지나면 검색 색인에서 제외될 수 있으므로 모든 삭제에 410이 더 빠르다는 단순 공식으로 운영하지 않습니다.
대량 삭제에서 410을 쓸 수 있지만 잘못 적용했을 때 복구 비용이 큽니다. 정책상 영구 제거가 확정된 URL에만 사용하고 배포 목록과 롤백 방법을 보관합니다.
사용자용 오류 화면은 탐색을 돕되 강요하지 않습니다
404 페이지에는 사이트 로고, 홈·검색·주요 카테고리 링크, 신고 방법을 제공할 수 있습니다. 그러나 존재하지 않는 URL을 다른 콘텐츠로 자동 이동시키거나 광고만 보여주면 사용자가 오류를 이해하기 어렵습니다.
오류 화면의 제목과 본문은 명확하게 “페이지를 찾을 수 없음”을 알려야 합니다. 사이트 내 검색 결과도 없는 조합이라면 유사 항목을 제안하면서 상태 코드 정책을 일관되게 유지합니다.
내부 링크·사이트맵·canonical을 함께 정리합니다
삭제 URL을 사이트맵에 계속 넣거나 메뉴와 본문에서 반복 링크하면 검색로봇과 사용자가 계속 오류에 도달합니다. 크롤링 도구로 내부 404를 찾아 원본 링크를 수정합니다.
리디렉션한 URL은 사이트맵에서 새 대표 URL로 교체하고 canonical도 최종 주소를 가리켜야 합니다. 오래된 리디렉션을 즉시 삭제하기보다 외부 링크와 방문 기록이 남아 있는지 확인합니다.
배포 후 상태 코드와 요청 추세를 관찰합니다
대표 URL 표본에 curl -I를 실행해 상태, Location 헤더, 캐시 정책을 확인합니다. 브라우저 캐시와 CDN 때문에 이전 응답이 보일 수 있으므로 외부 환경에서도 테스트합니다.
Search Console의 페이지 색인 보고서와 서버 로그에서 404·soft 404·리디렉션 오류 추세를 봅니다. 오류 수가 줄었는지보다 중요한 URL이 올바른 목적지와 상태를 갖는지 확인합니다.
삭제·이동 URL을 상태 원장으로 관리합니다
변경 전에는 URL별 현재 상태 코드, 유입·외부 링크, 대체 문서, canonical과 사이트맵 포함 여부을 같은 표에 저장합니다. 기준값이 없으면 이후 변화가 수정 효과인지 계절성·수요·배포 환경 차이인지 구분하기 어렵습니다. 표본 URL과 수집 시각, 사용한 도구 버전까지 남겨 다른 담당자가 같은 결과를 재현할 수 있게 합니다.
배포 기록에는 404·410·301 선택, 리디렉션 대상, 내부 링크와 사이트맵 제거 시각을 적고, 관찰 단계에서는 soft 404, 리디렉션 체인, 크롤 오류, 사용자 도착 성공과 잔존 외부 유입을 함께 비교합니다. 한 가지 수치만 좋아졌다고 완료하지 말고 사용자 경험·검색 접근·사업 목적 사이의 부작용을 확인합니다.
완료 기준은 각 폐기 URL이 관련 대체 문서 또는 명확한 없음 상태로 한 번에 응답하고 내부 신호가 일치하는 상태입니다. 반대로 관련 없는 홈 리디렉션, 루프, 대량 5xx 또는 중요한 URL 오분류가 발견되면 매핑 테이블을 이전 버전으로 복구합니다. 롤백 판단을 담당자의 감에 맡기지 말고 배포 전에 임계값과 연락 순서를 정하세요.
책임자는 콘텐츠 소유자, SEO 담당자와 라우팅 운영자입니다. 월별 또는 분기별 검토에서 오래된 가정, 소유자가 없는 규칙, 더 이상 존재하지 않는 URL과 도구 의존성을 제거합니다. 이 기록은 장애 대응뿐 아니라 다음 콘텐츠·기술 개선의 우선순위를 정하는 근거가 됩니다.
- 삭제 이유와 소유 팀 기록
- 외부 링크·트래픽 가치 확인
- 대체 URL 관련성 승인
- 상태 코드와 본문 동시 검증
- 내부 링크·사이트맵 일괄 수정
- 90일 뒤 잔존 요청과 리디렉션 재검토
삭제와 대표 URL 판단에 필요한 연결 문서
상태 코드만 바꾸지 말고 크롤링, 페이지 마크업, 미디어 링크까지 함께 확인하면 반복 오류를 줄일 수 있습니다.
공식 자료와 확인 도구
CDN·호스팅·프레임워크별 오류 처리 방식이 다르므로 최종 공개 URL의 HTTP 응답을 기준으로 판단하세요.
자주 묻는 질문
404가 많으면 검색 순위가 떨어지나요?
정상적으로 삭제된 URL의 404 자체는 문제로 단정할 수 없습니다. 중요한 내부 링크가 계속 404를 가리키거나 실제 콘텐츠가 soft 404라면 사용자 경험과 수집 효율을 개선해야 합니다.
모든 404를 홈으로 301 보내도 되나요?
권장하지 않습니다. 관련 없는 홈 이동은 soft 404로 처리될 수 있고 사용자가 찾던 정보를 잃습니다. 같은 목적의 명확한 대체 페이지가 있을 때만 리디렉션합니다.
404 페이지에 noindex를 넣어야 하나요?
진짜 404·410 상태라면 검색엔진이 상태 코드를 처리할 수 있습니다. 200 상태의 오류 화면에 noindex만 넣어 문제를 숨기기보다 올바른 HTTP 상태를 반환하는 것이 우선입니다.
정리: 없는 URL을 무조건 없애려 하지 말고 삭제·이동·일시 장애를 구분해 상태 코드, 안내 화면, 내부 링크와 사이트맵을 일관되게 정리하세요.