홈페이지 404 화면, 방문자가 다음 정보를 찾게 만드는 설계

# 홈페이지 404 화면, 방문자가 다음 정보를 찾게 만드는 설계

맞춤형 오류 페이지 설계와 soft 404 방지, 운영 중인 사이트를 점검하는 사람을 위한 실무 가이드

홈페이지를 운영하다 보면 없는 주소로 들어오는 방문자는 반드시 생깁니다. 페이지를 지우거나 주소 구조를 바꾸면, 오래된 즐겨찾기와 다른 곳에 걸린 링크, 검색 결과에 남은 주소가 모두 길을 잃습니다. 이때 방문자가 마주치는 화면이 홈페이지 404 페이지입니다.

이 화면은 방치하기 쉽습니다. 서버가 기본으로 내주는 흰 바탕의 짧은 문구가 그대로 노출되는 사이트가 적지 않습니다. 그런데 방문자 입장에서 이 화면은 "이 사이트가 나를 도와줄 의사가 있는가"를 처음 판단하게 되는 지점이기도 합니다.

이 글은 두 가지를 함께 다룹니다. 하나는 화면 설계입니다. 무엇을 쓰고, 어떤 길을 열어 주고, 접근성을 어떻게 확인하는지를 봅니다. 다른 하나는 서버 응답입니다. 화면은 친절한데 서버가 잘못된 신호를 보내면 검색엔진 쪽에서 문제가 생기므로, 404·410·301의 쓰임새와 soft 404의 원인을 함께 정리합니다.

핵심 요지는 한 문장입니다. 오류를 감추는 화면이 아니라, 방문자가 무슨 일인지 이해하고 다음 행동을 고를 수 있게 돕는 화면을 만들되, 서버는 사실대로 "없음"을 알려야 합니다.

404 응답과 맞춤형 오류 페이지, 화면과 신호를 나눠서 이해하기

404 화면은 사람에게 보이는 부분과 기계에게 전달되는 부분, 두 겹으로 이루어집니다. 이 구분이 이 글 전체의 뼈대입니다.

사람에게 보이는 부분은 방문자가 읽는 안내 문구와 링크, 디자인입니다. 기계에게 전달되는 부분은 서버가 브라우저와 검색 크롤러에게 보내는 HTTP 상태 코드입니다. 같은 화면이라도 이 두 겹이 서로 어긋나면 문제가 됩니다.

404의 정의

HTTP 표준을 정리한 RFC 9110(2022년 6월)은 404를 'Not Found'로 정의합니다. 서버가 요청한 주소에 해당하는 자원을 찾지 못했다는 뜻입니다. 여기서 눈여겨볼 점이 있습니다. 404는 그 자원이 잠시 없는 것인지, 영구히 없는 것인지를 말해 주지 않습니다. 단지 지금 찾지 못했다는 사실만 전달합니다.

맞춤형 오류 페이지란

맞춤형 오류 페이지는 서버의 기본 오류 문구 대신 사이트가 직접 만든 안내 화면을 보여 주는 방식입니다. 상태 코드는 그대로 404를 유지하면서, 화면만 사이트의 디자인과 문구로 바꾸는 것입니다.

Google Search Central은 맞춤 오류 화면에 대해 다음을 권장합니다.

① 요청한 페이지를 찾을 수 없다는 사실을 친절하고 분명한 말로 알리기
② 기존 사이트의 디자인과 내비게이션 유지하기
③ 인기 콘텐츠나 홈페이지 링크 두기
④ 깨진 링크를 알려 줄 방법 제공하기

이는 권장 사항이지 모든 사이트에 의무인 요소가 아닙니다. 사이트 규모와 성격에 따라 취사선택하면 됩니다. 다만 이 네 가지가 방문자의 다음 행동을 돕는다는 공통된 방향을 갖고 있다는 점은 기억해 둘 만합니다.

404가 검색 실적에 미치는 영향

흔한 오해부터 짚겠습니다. 404가 많으면 사이트 순위가 떨어진다고 걱정하는 분이 많지만, Search Console 도움말은 일반적으로 404 오류가 사이트의 검색 실적에 영향을 주지 않는다고 설명합니다. 존재하지 않는 주소가 404를 돌려주는 것은 정상 동작입니다.

그렇다면 왜 404 화면을 공들여 설계해야 할까요. 검색 순위 때문이 아니라 방문자 경험 때문입니다. 길을 잃은 방문자가 홈이나 검색으로 이어지는 길을 찾을 수 있느냐가 사용자 이탈 방지의 실제 대상입니다. 이 글도 404 자체가 SEO에 해롭다는 주장은 하지 않습니다. 다만 서버가 잘못된 신호를 보내는 soft 404는 별개의 문제이며, 뒤에서 자세히 다룹니다.

방문자가 읽는 첫 문장, 404 화면 설계의 문구 원칙

화면 문구의 목표는 방문자를 탓하지 않고 상황을 분명히 알리는 것입니다. 영국 정부 서비스의 GOV.UK 디자인 시스템과 영국 통계청(ONS) 서비스 매뉴얼은 이 점에서 한목소리를 냅니다.

큰 제목은 사실을 그대로

큰 제목은 "페이지를 찾을 수 없습니다"처럼 쓰는 것이 기본입니다. GOV.UK 지침은 제목에 페이지를 찾을 수 없다는 뜻이 분명히 드러나야 한다고 하며, 영문 예시로 페이지 제목 "Page not found – 서비스 이름 – GOV.UK", 본문 제목 "Page not found"를 듭니다. 브라우저 탭에 보이는 title도 같은 뜻을 담으라는 이야기입니다. 탭이 여러 개 열려 있을 때 어느 탭이 오류 화면인지 구분하게 해 주고, 화면 낭독기 사용자에게도 먼저 읽히는 정보이기 때문입니다.

피해야 할 표현

세 기관의 지침을 종합하면 피할 것이 비슷하게 모입니다.

① "404"나 "bad request" 같은 기술 용어를 화면 전면에 내세우지 않기. 방문자 대부분은 이 숫자의 뜻을 모르며, 알아야 할 이유도 없습니다. '404' 숫자를 넣지 않거나, 넣더라도 작게 두는 편이 낫습니다.
② "oops" 같은 가볍거나 농담조인 표현을 쓰지 않기. 방문자는 지금 원하는 정보를 못 찾아 당황한 상태일 수 있어서, 농담이 오히려 불쾌하게 읽힐 수 있습니다.
③ 느낌표와 경고용 빨간 글자를 쓰지 않기. 방문자가 잘못을 저지른 것처럼 보이게 만듭니다.
④ 사용자를 탓하는 표현을 쓰지 않기. "잘못된 주소를 입력하셨습니다" 같은 문장은 책임을 방문자에게 돌립니다. 링크가 깨진 원인은 사이트 쪽에 있을 수도 있기 때문입니다.
⑤ 모호한 말을 쓰지 않기. "문제가 발생했습니다"만으로는 무슨 문제인지, 이제 무엇을 해야 하는지 알 수 없습니다.

'친절한 말투'의 올바른 해석

Google은 맞춤 오류 화면을 "친절하게(friendly)" 알리라고 권장합니다. 여기서 친절함을 재치 있는 농담으로 해석하는 경우가 있는데, 그렇지 않습니다. 이 글에서는 방문자를 탓하지 않는 정중하고 분명한 말로 읽는 것이 맞다고 봅니다. 이는 GOV.UK 지침이 요구하는 방향과 정확히 맞아떨어집니다. 친절함은 말투의 가벼움이 아니라 방문자가 다음에 할 일을 알 수 있게 해 주는 명료함에서 나옵니다.

문구 구성 예시

아래는 위 원칙을 모아 만든 본문 구성의 한 예입니다.

> 페이지를 찾을 수 없습니다
> 주소를 직접 입력하셨거나 복사하셨다면, 주소가 정확한지 확인해 주세요.
> 즐겨찾기로 들어오셨다면 새 주소로 다시 저장해 주시기 바랍니다.
> 찾으시는 내용이 아래에 없다면 문의해 주세요.

제목은 사실만 말하고, 본문은 확인할 점을 순서대로 안내하며, 마지막에 연락 경로로 이어 줍니다. 느낌표도, 농담도, 방문자 탓도 없습니다. 이 예시는 설명을 위한 문안일 뿐이며, 사이트의 말투에 맞게 다듬어 쓰면 됩니다.

막다른 길을 만들지 않는 법, 다음 행동을 고르게 하는 구성 요소

좋은 404 화면은 방문자에게 최소 하나의 다음 길을 열어 줍니다. 문구가 상황을 설명했다면, 이제 그 상황에서 벗어날 방법을 줄 차례입니다.

화면에 둘 수 있는 요소

앞서 본 Google 권장과 CMS 디자인 시스템, GOV.UK 지침을 종합하면 다음 요소를 후보로 삼을 수 있습니다.

① 주소 확인 안내: 직접 입력하거나 복사한 경우 철자와 전체 주소를 확인하라는 문장입니다. CMS 지침은 주소 오타를 고치거나 즐겨찾기를 갱신하라고 안내할 수 있다고 합니다.
② 홈페이지 링크와 인기 콘텐츠 링크: 가장 기본적인 탈출구입니다. 방문자가 처음부터 다시 탐색할 수 있게 합니다.
③ 검색: 찾는 내용을 직접 입력할 수 있게 합니다.
④ 연락 경로: 그래도 찾지 못한 방문자를 위한 마지막 길입니다. GOV.UK 지침은 필요에 따라 연락 경로를 주라고 합니다.
⑤ 깨진 링크를 알릴 방법: Google이 권장하는 항목으로, 방문자가 문제를 신고할 수 있게 합니다.

이 모두를 한 화면에 넣어야 하는 것은 아닙니다. 선택지가 너무 많으면 오히려 고르기 어려워집니다. 사이트 성격에 맞춰 두세 가지를 분명하게 두는 편이 낫습니다.

검색은 중복하지 않기

CMS 디자인 시스템은 머리말에 검색창이 이미 있으면 오류 화면에 검색창을 또 넣지 않는다고 안내합니다. 같은 기능이 한 화면에 두 번 나오면 혼란스럽고, 어느 쪽을 써야 하는지 헷갈립니다. 앞서 Google이 권장한 "기존 사이트의 디자인과 내비게이션 유지"를 지키면 머리말의 검색창이 오류 화면에도 그대로 나타나므로, 본문에는 홈 링크와 인기 콘텐츠 링크를 두는 구성이 자연스럽습니다.

브레드크럼은 두지 않기

사이트 위치를 보여 주는 이동 경로(브레드크럼)는 오류 화면에 두지 않습니다. GOV.UK와 ONS가 모두 이 점을 명시합니다. 이유는 간단합니다. 요청한 페이지가 존재하지 않으니, 그 페이지가 사이트 구조 안 어디에 있는지 보여 줄 수 없습니다. 근거 없는 경로를 보여 주면 오히려 방문자를 오도합니다.

참조 코드가 필요한 경우

ONS 서비스 매뉴얼은 "Page not found" 화면에 고객 지원 담당자에게 전달할 참조 코드를 넣어야 할 수도 있다고 안내합니다. 방문자가 문의할 때 어떤 주소에서 문제가 생겼는지를 지원 담당자가 바로 확인할 수 있게 하려는 것입니다. 모든 사이트에 필요한 것은 아니며, 문의 응대가 활발한 서비스에서 고려할 만한 선택입니다.

같은 디자인, 같은 머리말과 바닥글

CMS 지침은 오류 화면에도 표준 머리말과 바닥글을 두고 여러 화면 크기에 맞추라고 합니다. 404 화면만 동떨어진 모양이면 방문자는 사이트를 떠난 것으로 느낄 수 있습니다. 기존 내비게이션이 살아 있으면 방문자는 오류 화면에서도 메뉴로 이동할 수 있어서, 별도의 길 안내를 덜 만들어도 됩니다.

화면보다 먼저 확인할 것, 서버 응답과 soft 404

화면이 아무리 좋아도 서버가 200 OK를 보내면 검색엔진은 그 페이지를 정상 페이지로 받아들입니다. 이것이 soft 404이며, 맞춤형 오류 페이지를 만들 때 가장 자주 생기는 함정입니다.

soft 404란

Google은 존재하지 않는 URL에 실제 404 응답을 돌려줘야 한다고 안내합니다. 오류 안내 화면을 보여 주면서 정상 응답(200 OK)을 보내면 soft 404가 됩니다. 방문자 눈에는 "페이지를 찾을 수 없습니다"가 보이지만, 서버는 "정상입니다"라고 말하는 셈입니다. Search Console이 soft 404로 표시한 페이지는 Google 검색에서 제외됩니다.

상태 코드별 쓰임새

없는 주소를 어떻게 처리할지는 상황에 따라 나뉩니다. 아래 표는 이 글에서 다루는 응답을 정리한 것입니다.

301을 쓸 때와 404·410을 쓸 때

기준은 대체 페이지가 분명한가입니다.

콘텐츠가 다른 주소로 옮겨졌고 대체 페이지가 분명하면 301 Moved Permanently(영구 리디렉션) 를 씁니다. 옛 주소로 들어온 방문자와 크롤러를 새 주소로 안내하는 정식 방법입니다.

콘텐츠가 없어졌고 비슷한 대체 페이지가 없으면 404 또는 410을 돌려줍니다. 억지로 다른 곳으로 보내지 않습니다.

404와 410, 어느 쪽을 쓸까

RFC 9110은 410을 'Gone'으로 정의합니다. 서버가 자원을 영구히 없앴다고 알고 있다면 410을 쓰는 것이 낫다고 하면서도, 영구히 없는 자원마다 410을 붙일 필요는 없다고 덧붙입니다. 즉 410은 선택 사항입니다.

실무에서 중요한 것은 Google의 취급 방식입니다. Search Console 도움말은 "현재 Google은 410을 404와 같게 취급한다"고 설명하고, Google 크롤링 문서도 429를 뺀 4xx 응답을 모두 같게 처리한다고 적습니다. 410이 404보다 빨리 처리된다는 내용은 현재 Google 문서에 없습니다. 따라서 검색엔진 처리 속도를 이유로 410을 일괄 적용할 근거는 없습니다. 영구 삭제라는 의미를 표준에 맞게 전달하고 싶을 때 선택하는 정도로 이해하면 됩니다.

없는 주소를 홈페이지로 몰아 보내지 않기

가장 흔한 실수 중 하나는 없는 주소를 전부 홈페이지로 리디렉션하는 것입니다. 깨진 링크가 사라진 것처럼 보여서 편해 보이지만, Search Console 도움말은 이를 명시적으로 말립니다. 없는 주소를 홈페이지로 리디렉션하거나, 가짜 콘텐츠를 만들거나, robots.txt로 404를 막지 말라고 합니다.

방문자 입장에서도 이는 좋지 않습니다. 특정 글을 찾아 들어왔는데 갑자기 홈페이지에 도착하면, 무슨 일이 일어났는지 알 수 없습니다. 원하는 페이지가 없다는 사실부터 정직하게 알려 주는 편이 낫습니다.

다만 예외는 있습니다. 자주 틀리는 철자나 다른 표기로 들어오는 주소가 확인되면, 그 주소를 관련 페이지로 연결하는 방법을 Search Console 도움말이 제시합니다. 이때 핵심은 "관련 있는 페이지"로 연결한다는 점입니다. 모든 오류를 홈으로 보내는 것과는 다릅니다.

흔한 soft 404 원인 둘, 단일 페이지 앱과 Apache ErrorDocument

soft 404는 대개 의도해서 만들어지는 것이 아니라 설정의 부산물로 생깁니다. 특히 자주 만나는 경우가 두 가지 있습니다.

원인 ①: 단일 페이지 앱(SPA)

단일 페이지 앱처럼 서버가 모든 주소에 같은 화면(index.html)을 돌려주는 사이트는 없는 주소도 200 응답이 됩니다. 화면 안에서 자바스크립트가 "페이지를 찾을 수 없습니다"를 그려 주더라도, 서버가 이미 200을 보낸 뒤라서 soft 404가 생기기 쉽습니다.

Google 자바스크립트 SEO 문서는 두 가지 해결법을 안내합니다.

① 서버가 404를 돌려주는 주소로 자바스크립트 리디렉션하기
② 오류 화면에 자바스크립트로 `` 넣기

첫째 방법은 오류가 감지되면 서버가 404를 돌려주는 별도 주소로 이동시켜서, 크롤러가 진짜 404 응답을 받게 하는 방식입니다.
둘째 방법은 오류 화면에 noindex 지시를 넣어 색인되지 않게 하는 방식입니다. 어느 쪽이든 전제는 같습니다. 화면에서만 오류를 표시하면 충분하지 않고, 크롤러가 오류 상황을 알아챌 신호를 따로 줘야 합니다.

개발자라면 이 부분을 라우팅 설계 단계에서 정해 두는 편이 좋습니다. 없는 경로를 처리하는 규칙을 앱 코드 안에만 두지 않고, 서버나 배포 환경에서도 404가 나가도록 맞춰 두면 사후 수정보다 훨씬 수월합니다.

원인
②: Apache의 ErrorDocument에 전체 주소를 적은 경우

Apache 웹서버에서 `ErrorDocument 404` 지시문에 http로 시작하는 전체 주소를 적으면, 브라우저에 리디렉션이 가서 원래의 404 상태 코드가 전달되지 않습니다. 이것이 soft 404의 흔한 원인입니다.

잘못된 예와 올바른 예는 다음과 같습니다.

```
# 잘못된 예 — 전체 주소를 쓰면 리디렉션이 일어나 404가 전달되지 않음
ErrorDocument 404 https://example.com/404.html

# 올바른 예 — 사이트 안 경로로 적으면 404가 유지됨
ErrorDocument 404 /404.html
```

핵심은 "/404.html"처럼 사이트 안 경로로 적는 것입니다. 이렇게 하면 서버가 내부적으로 오류 화면을 보여 주면서도 404 상태 코드를 그대로 유지합니다. 이 내용은 Apache 2.4 문서의 ErrorDocument 설명에 근거합니다.

응답을 직접 확인하는 법

설정을 바꿨다면 반드시 실제 응답을 확인해야 합니다. 화면이 제대로 보이는 것만으로는 부족합니다.

① 존재하지 않을 것이 확실한 주소(예: 임의의 긴 문자열 경로)를 하나 정합니다.
② 브라우저 개발자 도구의 네트워크 탭에서 그 주소의 응답 상태를 확인하거나, 명령줄 도구로 응답 헤더만 요청합니다.
③ 상태가 404로 나오는지 확인합니다. 200이나 302가 나오면 설정을 다시 봐야 합니다.
④ Search Console의 URL 검사 도구로도 Google이 그 주소를 어떻게 보는지 확인합니다.

이 확인을 한 번 해 두면, 오류 화면을 아무리 예쁘게 만들어도 서버 쪽이 어긋나 있는 상황을 걸러낼 수 있습니다.

모두가 쓸 수 있는 오류 화면, 404 화면의 접근성 점검

오류 화면도 접근성 점검 대상입니다. 방문자가 가장 도움이 필요한 순간에 도움 요소에 닿지 못한다면 화면의 의미가 없습니다. CMS 디자인 시스템 지침을 기준으로 점검 항목을 정리합니다.

점검 항목

① 보조기술 사용자가 오류 화면에 왔다는 것을 알 수 있어야 합니다. 화면 낭독기가 페이지 제목과 큰 제목을 읽을 때 "페이지를 찾을 수 없습니다"가 분명하게 전달되어야 합니다. 앞서 말한 제목 구성이 여기서도 쓰입니다.
② 키보드만으로 주요 버튼과 검색에 접근할 수 있어야 합니다. Tab 키를 눌러 홈 링크, 인기 콘텐츠 링크, 검색창에 순서대로 닿는지 확인합니다. 초점이 어디에 있는지 눈에 보여야 합니다.
③ 검색창·버튼·링크가 실제로 작동하는지 확인합니다. 오류 화면용 링크는 한번 만들어 두고 잊히기 쉽습니다. 사이트 개편 뒤에 링크가 다시 깨져 있는 일이 의외로 흔합니다.
④ 여러 화면 크기에서 보여야 합니다. 데스크톱뿐 아니라 좁은 화면에서도 요소가 겹치거나 잘리지 않는지 봅니다.
⑤ 200% 확대에서도 쓸 수 있어야 합니다. CMS 지침은 화면을 200% 로 확대해도 가로 스크롤 없이 보이고 작동하는지 시험하라고 합니다.

200% 확대 시험 방법

시험은 어렵지 않습니다.

1단계: 브라우저에서 404 화면을 엽니다.
2단계: 확대 배율을 200%로 맞춥니다.
3단계: 가로 스크롤바가 생기는지 확인합니다. 생기면 문제입니다.
4단계: 제목, 안내 문장, 링크, 검색창이 모두 보이고 눌러지는지 확인합니다.

시력이 낮거나 큰 글씨를 쓰는 방문자는 실제로 확대 상태로 사이트를 보기 때문에, 이 시험은 형식적 절차가 아니라 실제 사용 상황의 재현입니다.

디자인과 접근성이 만나는 지점

앞서 본 문구 원칙도 접근성과 맞닿아 있습니다. 경고용 빨간 글자를 쓰지 말라는 지침은 색에만 의존한 전달을 피한다는 뜻으로도 읽힙니다. 이 글에서는 색보다 분명한 문장으로 상황을 전달하는 쪽을 권합니다. 문구가 명확하면 색이나 아이콘의 도움 없이도 의미가 전달됩니다.

한 번 만들고 끝내지 않기, 깨진 링크 점검 습관과 우선순위

404 화면은 만든 뒤에도 운영 데이터로 계속 다듬어야 합니다. 어떤 주소가 자주 깨지는지 모르면 개선할 곳도 알 수 없습니다.

404 조회와 링크 클릭을 기록하기

CMS 디자인 시스템은 404 화면 조회와 그 안의 링크 클릭을 분석 도구로 기록하라고 안내합니다. 이렇게 하면 두 가지를 알 수 있습니다.

① 어떤 주소가 자주 깨지는지: 같은 주소가 반복해서 404를 만든다면, 그 주소를 어디서 연결하고 있는지 추적할 단서가 됩니다.
② 방문자가 404 화면에서 어디로 이동하는지: 홈 링크를 많이 누르는지, 인기 콘텐츠를 누르는지, 문의 링크를 누르는지를 보면 화면 구성이 방문자의 필요와 맞는지 가늠할 수 있습니다.

다만 이 기록만으로 특정 배치가 전환율을 높이는지 단정할 수는 없습니다. 이 글은 어떤 구성이 효과적이라고 주장하지 않으며, 기록은 개선 방향을 찾는 자료로 쓰시기를 권합니다.

Search Console에서는 무엇부터 고칠까

404 목록을 보면 항목이 많아 막막해질 수 있습니다. Search Console 도움말은 우선순위를 분명히 정해 줍니다. 페이지 색인 보고서 도움말은 고칠 대상으로 직접 건 링크나 사이트맵에 있는 주소의 404만 고치라고 권합니다. 다른 사이트가 잘못 건 링크까지 모두 고칠 필요는 없습니다.

이 구분은 실무에서 큰 부담을 덜어 줍니다. 다음 순서로 접근할 수 있습니다.

① 사이트맵에 들어 있는 주소 가운데 404가 나는 것을 찾습니다. 사이트맵은 "이 주소들이 있다"고 검색엔진에 알리는 목록이므로, 404가 섞여 있으면 목록 자체가 어긋난 것입니다.
② 사이트 안에서 내가 직접 건 링크 가운데 깨진 것을 찾아 고칩니다. 메뉴, 본문 링크, 배너, 버튼 등이 대상입니다.
③ 콘텐츠를 옮긴 경우라면 옛 주소에 301을 설정합니다.
④ 콘텐츠를 지운 경우라면 404 또는 410을 유지하고, 내 쪽 링크만 정리합니다.
⑤ 외부에서 잘못 건 링크는 필요할 때만 대응합니다. 모두 고칠 의무는 없습니다.

반복되는 오타 주소 다루기

분석 기록에서 방문자가 자주 틀리는 철자나 다른 표기로 들어오는 주소가 보인다면, Search Console 도움말이 말한 대로 그 주소를 관련 페이지로 연결하는 방법이 있습니다. 예를 들어 서비스 이름을 다르게 표기한 주소가 반복해서 들어온다면, 해당 서비스 페이지로 301을 연결해 둘 수 있습니다. 이는 앞서 말린 "전부 홈으로 보내기"와 다릅니다. 대체 페이지가 분명한 개별 경우만 처리하는 것입니다.

정기 점검 루틴

한 번에 모든 것을 하려 하지 말고, 가벼운 루틴으로 만들면 오래갑니다.

① 사이트를 개편하거나 주소 구조를 바꾼 직후에 404 응답과 주요 링크를 점검합니다.
② 정기적으로 분석 도구에서 404 화면 조회가 많은 주소를 확인합니다.
③ Search Console의 색인 보고서에서 사이트맵 속 404가 있는지 봅니다.
④ 404 화면의 링크와 검색이 아직 작동하는지 직접 눌러 봅니다.

404 화면을 만들 때 판단 기준과 흔한 실수

404 설계에서 가장 중요한 판단은 "이 화면이 방문자를 돕는가, 오류를 감추는가"입니다. 아래는 앞서 다룬 내용을 점검용으로 묶은 것이며, 새로운 사실이 아니라 실행 직전의 확인 목록입니다.

설계 전 판단 기준

① 대체 페이지가 분명한가: 분명하면 301, 아니면 404(선택적으로 410)입니다.
② 서버가 실제로 404를 돌려주는가: 화면만 보지 말고 응답 코드를 확인합니다.
③ 기존 사이트의 디자인과 내비게이션이 유지되는가: 머리말·바닥글이 그대로인지 봅니다.
④ 방문자에게 최소 하나의 다음 길이 있는가: 홈, 인기 콘텐츠, 검색 중 무엇이 있는지 봅니다.
⑤ 머리말에 검색창이 이미 있는가: 있으면 본문에 중복해서 넣지 않습니다.

흔한 실수

실수 ① 화면은 친절한데 상태 코드가 200이다. soft 404의 전형입니다. SPA와 Apache 설정을 다시 확인합니다.

실수
② 없는 주소를 모두 홈페이지로 보낸다. Search Console 도움말이 말리는 방식이며, 방문자도 혼란을 겪습니다.

실수
③ "404" 큰 숫자와 농담 문구로 꾸민다. 눈길은 끌 수 있어도 GOV.UK, ONS, CMS 지침이 공통으로 피하라는 방향입니다. 방문자가 실제로 필요한 것은 재치가 아니라 다음 행동 안내입니다.

실수
④ 방문자를 탓하는 문장을 쓴다. "잘못된 주소입니다"보다 "주소가 정확한지 확인해 주세요"처럼 확인할 점을 안내하는 쪽이 낫습니다.

실수
⑤ 오류 화면에 이동 경로(브레드크럼)를 둔다. 존재하지 않는 페이지의 위치를 보여 줄 수 없으니 두지 않습니다.

실수
⑥ 검색창을 두 번 넣는다. 머리말에 이미 있다면 본문에는 넣지 않습니다.

실수
⑦ 404 때문에 검색 순위가 떨어질까 봐 과도하게 대응한다. Search Console 도움말은 일반적으로 404가 검색 실적에 영향을 주지 않는다고 설명합니다. 정리할 대상은 내가 건 링크와 사이트맵 속 404입니다.

실수
⑧ robots.txt로 404를 막거나 가짜 콘텐츠를 만든다. Search Console 도움말이 말리는 방식입니다.

실수
⑨ 한 번 만들고 링크 작동을 다시 보지 않는다. 개편 뒤에 오류 화면의 링크가 다시 깨져 있는 일이 생깁니다.

실수
⑩ 키보드 접근과 200% 확대를 확인하지 않는다. 마우스와 기본 배율에서만 시험하면 놓치는 문제가 있습니다.

자주 묻는 질문

404 화면에 사이트 소개나 이벤트 배너를 넣어도 되나요?

법으로 정해진 금지는 아닙니다. 다만 이 화면은 방문자가 길을 잃은 상태에서 보는 곳입니다. Google이 권장하는 방향은 찾을 수 없다는 사실을 분명히 알리고 다음 길을 주는 것이므로, 본래의 안내를 가리는 요소는 줄이는 편이 방문자에게 더 도움이 됩니다. 어떤 배치가 성과를 높이는지는 이 글에서 단정할 수 없으며, 직접 기록한 분석 데이터로 확인하시기 바랍니다.

서버 오류 화면(500번대)도 같은 방식으로 만들면 되나요?

이 글의 근거는 "페이지를 찾을 수 없음"에 한정되어 있어서 500번대 오류의 상세 설계는 다루지 않았습니다. 다만 ONS 서비스 매뉴얼은 오류 화면 전반에서 사용자가 다음에 할 일과 연락 방법을 알려 주고, 모호한 말과 "500" 같은 기술 용어를 피하라고 합니다. 이 원칙은 다른 오류 화면을 설계할 때도 출발점으로 삼을 수 있습니다.

오류 화면을 직접 만들지 않고 서버 기본 화면을 그대로 두면 안 되나요?

가능합니다. Google의 권장은 의무가 아니며, 404 자체가 검색 실적에 영향을 주지 않는다고 Search Console 도움말이 설명합니다. 다만 기본 화면은 사이트의 내비게이션이 없어서 방문자가 다음 길을 찾기 어렵습니다. 방문자 경험을 고려하면 맞춤형 오류 페이지를 두는 쪽이 유리합니다.

404는 사이트가 방문자에게 건네는 안내판입니다

404 화면 설계는 화면과 서버 응답이 한 쌍으로 움직이도록 맞추는 일입니다. 화면에서는 "페이지를 찾을 수 없습니다"라고 정중하고 분명하게 말하고, 홈·인기 콘텐츠·검색·연락 경로로 이어지는 길을 열어 줍니다. 서버에서는 없는 주소에 실제 404를 돌려주고, 옮긴 주소에는 301을 쓰며, 오류 화면에 200 OK를 보내는 soft 404를 피합니다.

여기에 네 가지 습관을 더하면 완성도가 올라갑니다.

① 큰 '404' 숫자, 농담, 느낌표, 빨간 경고, 방문자 탓을 피합니다.
② 없는 주소를 홈페이지로 몰아 보내지 않습니다.
③ 키보드 접근과 200% 확대를 시험합니다.
④ 404 화면 조회와 링크 클릭을 기록하고, 내가 건 링크와 사이트맵 속 404부터 고칩니다.

지금 운영 중인 사이트가 있다면, 오늘 할 수 있는 가장 작은 점검은 하나입니다. 존재하지 않을 것이 확실한 주소를 하나 열어, 화면이 어떻게 보이는지 그리고 응답 상태가 정말 404인지 확인해 보시기 바랍니다.

참고 자료

- Google Search Central 크롤링 오류 해결: https://developers.google.com/search/docs/crawling-indexing/troubleshoot-crawling-errors

- Search Console 404 오류 도움말: https://support.google.com/webmasters/answer/2445990

- Google 자바스크립트 SEO 기본: https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics

- GOV.UK Design System: https://design-system.service.gov.uk/patterns/page-not-found-pages/

- CMS Design System: https://design.cms.gov/patterns/404-page-guidance/

- IETF RFC 9110: https://datatracker.ietf.org/doc/rfc9110/