404 오류(404 Error)는 요청한 주소에 해당하는 페이지를 서버가 찾지 못했을 때 돌려주는 HTTP 상태 코드로, “Not Found(찾을 수 없음)”를 뜻합니다. 방문자에게는 오류 화면이지만, 검색엔진에게는 “이 주소에는 더 이상 페이지가 없다”는 정상적인 신호이기도 합니다.
서버는 모든 요청에 세 자리 숫자로 답합니다. 앞자리 4는 요청하는 쪽의 문제(클라이언트 오류)를 뜻하고, 뒤의 04는 그중 “찾을 수 없음”이라는 구체적인 사유입니다. 주소를 잘못 입력했거나, 링크가 가리키는 페이지가 삭제됐거나, 주소가 바뀌었는데 새 주소로 연결해 두지 않았을 때 404가 나옵니다.
HTTP 표준 문서인 RFC 9110은 404를 “서버가 대상 리소스의 현재 표현을 찾지 못했거나, 존재 여부를 밝히고 싶지 않다”는 뜻으로 정의합니다. 이 상태가 일시적인지 영구적인지는 말하지 않는다는 점이 중요합니다. 영구히 없어졌다는 것을 서버가 안다면 410(Gone)이 더 정확한 코드입니다.
“404 뜻”을 검색하면 브라우저에서 오류 화면을 만난 사용자를 위한 해결법이 많이 나옵니다. 이 글은 사이트를 운영하는 쪽에서 404를 어떻게 봐야 하는지, 특히 구글 검색과의 관계를 다룹니다.

떨어지지 않습니다. 404를 돌려주는 주소 자체가 색인에서 빠질 뿐, 사이트의 다른 페이지 순위에는 영향을 주지 않습니다. 구글은 “404 오류가 사이트에 손상을 입히나요?”라는 글에서 404는 웹의 정상적인 일부이고, 일부 URL이 404를 반환한다는 사실만으로 검색 결과에서 불이익을 받지 않으며, 200을 반환하는 나머지 URL의 성과에도 영향이 없다고 답했습니다.
구글이 이렇게 보는 이유는 웹에서 페이지가 사라지는 일이 너무 흔하기 때문입니다. 퓨 리서치 센터가 커먼 크롤에서 뽑은 웹페이지 약 100만 개를 추적한 결과, 2013년에 있던 페이지의 38%가 2023년 10월에는 접속되지 않았습니다(2024년 5월 발표). 사이트 쪽에서 봐도 SE Ranking이 사이트 감사 418,125건을 분석한 결과(2025년 3월 공개) 35.73%의 사이트에 4xx 응답 페이지가 있었습니다. 영문권 중심 데이터이고, 국내 공개 조사는 아직 없습니다.
구글의 HTTP 상태 코드 문서가 설명하는 처리 방식은 이렇습니다. 이미 색인된 URL이 404를 반환하면 색인에서 삭제되고, 새로 발견된 404 페이지는 처리하지 않으며, 그 주소의 크롤링 빈도는 서서히 줄어듭니다. 즉 404의 결과는 그 주소 하나가 검색에서 빠지는 것입니다. 문제는 그 주소가 원래 트래픽을 받던 중요한 페이지였을 때입니다.
페이지가 없으면 404나 410, 다른 곳으로 옮겼으면 301을 돌려주고, 없는 페이지에 200을 돌려주는 소프트 404는 피합니다. 네 가지는 방문자가 보는 화면은 비슷해도 검색엔진이 받는 신호가 다릅니다.
| 404 | 410 | 소프트 404 | 301 | |
|---|---|---|---|---|
| 서버 응답 | 404 Not Found | 410 Gone | 200 OK (내용은 “없음”) | 301 + 새 주소 |
| 뜻 | 지금 없음 (영구 여부 모름) | 영구히 없앰 | 없는데 있다고 답함 | 영구히 옮김 |
| 구글의 처리 | 색인에서 삭제, 크롤링 감소 | 404와 같음 | 서치 콘솔에 오류로 표시, 계속 크롤링 | 새 주소를 대표로 처리 |
| 쓰는 때 | 삭제했고 대체 페이지가 없을 때 | 삭제가 확실할 때 | 쓰지 않음 | 내용이 다른 주소로 이어질 때 |
404와 410은 구글에게 사실상 같습니다. 상태 코드 문서는 429를 제외한 모든 4xx 오류를 동일하게 처리한다고 밝힙니다. 둘 중 무엇을 고를지 고민하기보다, 삭제한 페이지가 2xx가 아닌 4xx를 제대로 돌려주는지 확인하는 편이 중요합니다.
실무에서 더 자주 문제가 되는 것은 소프트 404입니다. 화면에는 “페이지를 찾을 수 없습니다”라고 나오는데 서버는 200(성공)을 돌려주는 경우입니다. 구글의 크롤링 예산 문서는 404가 그 URL을 다시 크롤링하지 말라는 강한 신호인 반면, 소프트 404 페이지는 계속 크롤링되며 예산을 낭비한다고 적고 있습니다.

404를 전부 없애는 것이 목표가 아니라, 사람이 실제로 도착하는 404만 골라 고치는 것이 목표입니다. 서치 콘솔의 페이지 색인 생성 보고서에서 “찾을 수 없음(404)” 항목을 열면 구글이 발견한 404 주소가 나옵니다. 구글 스스로 이 목록에 대해 “대체할 페이지 없이 삭제된 경우 404 응답이 반드시 문제가 되는 것은 아니다”라고 적고 있습니다.
목록의 주소를 아래 기준으로 나눠 봅니다.
| 404 주소의 성격 | 조치 |
|---|---|
| 주소만 바뀐 페이지 (내용은 새 주소에 있음) | 새 주소로 301 리디렉션 |
| 외부 사이트가 링크를 걸어 둔 옛 페이지 | 내용이 이어지는 페이지가 있으면 301, 없으면 404 유지 |
| 오타가 난 외부 링크 (예: /awsome) | 올바른 주소로 301 |
| 내 사이트의 메뉴·본문 링크가 가리키는 404 | 링크 자체를 고침 |
| 사이트맵에 들어 있는 404 | 사이트맵에서 뺌 |
| 한 번도 존재한 적 없는 이상한 주소 | 무시 |
오타 링크를 301로 살리라는 것과, 존재한 적 없는 주소의 404는 무시해도 된다는 것은 앞의 구글 블로그 글에 나온 내용입니다. 구글은 어떤 404가 중요한지 알 수 없어 발견한 404를 모두 보여 주는 것이고, 판단은 사이트 운영자에게 맡긴다고 설명합니다. 내부 링크가 404를 가리키는 경우는 순위와 별개로 방문자와 크롤러가 막다른 길을 만나는 것이므로 가장 먼저 고칩니다. 크롤러는 링크를 따라 페이지를 발견하기 때문에, 깨진 링크는 그만큼 헛걸음이 됩니다.
컨설턴트의 실전 팁
404 주소에 301을 거는 것은 대체할 페이지가 있는 주소만으로 한정합니다. 사이트를 이관하면서 404를 전부 홈으로 301 해 버리는 개발업체가 꽤 많은데, 이렇게 하면 검색에 노출되지도 않는 불필요한 페이지들이 크롤링 예산만 잡아먹습니다.
화면은 친절하게 꾸미되, 응답 코드는 반드시 404로 둡니다. 구글 블로그 글은 보기 좋은 404 페이지를 보여 주려면 200을 반환해야 한다고 생각하는 경우가 많지만 그렇지 않다며, 404 응답 코드를 반환하면서 원하는 내용을 얼마든지 보여 줄 수 있다고 설명합니다. 좋은 404 페이지에는 검색창, 주요 카테고리 링크, 홈으로 가는 링크처럼 방문자가 다음에 갈 곳을 둡니다.
# Apache (.htaccess)
ErrorDocument 404 /404.html
# NGINX
error_page 404 /404.html;
워드프레스는 테마의 404 템플릿을 보여 주면서 404 코드를 함께 돌려주는 것이 기본 동작입니다. 다만 플러그인이나 커스텀 코드가 끼어들면 달라질 수 있으니, 없는 주소를 하나 만들어 응답 헤더를 직접 확인해 봅니다.
$ curl -I https://example.com/this-page-does-not-exist
HTTP/2 404
여기서 HTTP/2 200이 나오면 소프트 404입니다. 서치 콘솔의 URL 검사에서 실시간 테스트를 돌려도 구글이 그 페이지를 어떻게 받아들이는지 볼 수 있습니다.
404와 색인의 관계는 인덱싱(색인) 글에서 색인에서 빠지는 다른 이유들과 함께 볼 수 있습니다.
AI 답변은 구글 검색보다 404 주소로 방문자를 보내는 비율이 높습니다. Ahrefs가 ChatGPT, Perplexity, Copilot, Gemini, Claude, Mistral이 인용한 고유 URL 1,600만 개를 분석한 결과(2025년 9월), AI 어시스턴트가 보낸 클릭의 0.43%가 404에 도착했고 구글 검색은 0.15%였습니다. 약 2.87배 차이입니다. ChatGPT는 클릭된 URL의 1.01%, 인용한 전체 URL의 2.38%가 404였습니다.
원인은 두 가지로 봅니다. 예전에 있었지만 리디렉션 없이 삭제되거나 옮겨진 주소, 그리고 사이트의 URL 패턴을 흉내 냈지만 실제로는 존재한 적 없는 주소입니다. Ahrefs는 둘을 정확히 가르기는 어렵다고 밝히면서, 의미 있는 유입이 들어오는 404 주소에는 301을 걸고 404 페이지 자체를 쓸모 있게 만들어 두라고 권합니다. 서버 로그나 분석 도구에서 AI 서비스를 통해 들어온 404 주소를 따로 걸러 보면 어디에 리디렉션을 걸지 판단할 수 있습니다.
