404 페이지와 리다이렉트가 작은 블로그 신뢰도에 미치는 영향

작은 블로그를 운영할 때 404 페이지와 리다이렉트는 처음에는 뒤로 밀리기 쉽습니다. 글 몇 개 없는 사이트에서 “없는 페이지”까지 신경 써야 하나 싶기 때문입니다. 하지만 글이 쌓이고, slug를 조금씩 다듬고, 외부에 링크가 공유되고, Search Console에 크롤링 기록이 남기 시작하면 이야기가 달라집니다. 사라진 주소를 어떻게 처리하느냐는 단순한 기술 설정이 아니라 사이트가 얼마나 정돈되어 있는지 보여주는 신호가 됩니다.

404는 나쁜 것이 아닙니다. 정말 없는 페이지라면 404가 맞습니다. 문제는 관련 있는 새 주소가 있는데도 사용자를 막다른 길에 세우거나, 반대로 아무 관련 없는 페이지로 전부 리다이렉트해서 사용자를 헷갈리게 만드는 경우입니다. 작은 블로그일수록 이 판단을 초반에 정해두면 나중에 URL을 바꿔야 할 때 훨씬 덜 흔들립니다.

이 글에서는 기술 블로그 기준으로 404와 리다이렉트를 어떻게 나누어 다룰지 정리합니다. 특히 /blog/<slug>처럼 단순한 구조를 쓰는 블로그에서 slug 변경, 글 삭제, 카테고리 개편, 도메인 정리, 외부 공유 URL을 어떤 순서로 봐야 하는지에 초점을 맞추겠습니다.

기반 설계URL 관리

404 페이지와 리다이렉트가 작은 블로그 신뢰도에 미치는 영향

작은 블로그에서도 사라진 글, 바뀐 slug, 잘못 공유된 주소를 어떻게 처리하느냐가 탐색 경험과 검색 신뢰에 영향을 줍니다. 404로 둘 때와 리다이렉트할 때를 나누는 기준을 정리했습니다.

핵심 1

404와 리다이렉트는 서로 반대가 아니라 역할이 다릅니다

핵심 2

작은 블로그에서 404가 생기는 흔한 이유

핵심 3

리다이렉트해야 하는 경우

URL 관리기반 설계404 redirect blog trust

404와 리다이렉트는 서로 반대가 아니라 역할이 다릅니다

404와 리다이렉트는 둘 중 하나가 무조건 좋은 선택인 관계가 아닙니다. 역할이 다릅니다.

블로그에서 가장 많이 쓰는 것은 404와 301입니다. 404는 “이 주소에는 보여줄 문서가 없다”는 정직한 응답이고, 301은 “이 문서는 새 주소로 옮겨졌다”는 안내입니다. 둘 다 올바르게 쓰면 신뢰를 높이고, 잘못 쓰면 탐색 경험을 흐립니다.

중요한 기준은 페이지의 의미입니다. 요청된 URL과 새 URL이 같은 내용을 가리킨다면 리다이렉트가 맞습니다. 하지만 비슷한 주제라는 이유만으로 억지로 보내는 것은 조심해야 합니다. 사용자는 “내가 누른 링크의 답”을 기대하고 들어왔기 때문입니다.

작은 블로그에서 404가 생기는 흔한 이유

404는 사이트가 커져야만 생기는 문제가 아닙니다. 오히려 초반에 구조를 바꾸는 일이 많아서 작은 블로그에서도 금방 생깁니다.

대표적인 원인은 이렇습니다.

• 글 제목을 바꾸면서 slug도 함께 바꿈
• 날짜나 카테고리를 URL에서 빼는 구조 개편을 함
• 예전에 만들었던 테스트 글을 삭제함
• 외부 글이나 SNS에 잘못된 링크가 공유됨
• 대소문자, 하이픈, 끝 슬래시가 섞임
• 배포 플랫폼의 임시 주소가 검색엔진에 잡힘
• 예전 도메인에서 새 도메인으로 옮김

이 중에서 가장 위험한 것은 slug 변경입니다. 글 제목은 자주 다듬을 수 있지만, slug는 주소 식별자에 가깝습니다. slug, 날짜, 카테고리 구조를 처음부터 덜 꼬이게 만드는 법에서 정리한 것처럼, 제목과 slug를 같은 것으로 취급하면 나중에 제목을 바꿀 때마다 주소가 흔들립니다.

그래서 저는 글을 발행한 뒤에는 slug를 웬만하면 바꾸지 않습니다. 제목이 더 좋아져도 기존 slug가 크게 틀리지 않다면 유지합니다. 정말 바꿔야 한다면 그때는 새 slug를 만들고 끝내는 것이 아니라, 예전 주소를 새 주소로 보내는 리다이렉트까지 한 세트로 처리합니다.

리다이렉트해야 하는 경우

리다이렉트가 필요한 경우는 생각보다 명확합니다. 요청한 URL에 해당하는 콘텐츠가 새 위치에 그대로 있거나, 실질적으로 같은 문서로 이어질 때입니다.

예를 들어 아래는 리다이렉트하는 편이 좋습니다.

여기서 공통점은 “사용자가 기대한 문서가 새 주소에 있다”는 점입니다. 이런 경우 404로 두면 사용자는 글을 찾지 못하고, 외부 링크의 흐름도 끊깁니다. 검색엔진 입장에서도 예전 URL과 새 URL의 관계를 이해하기 어렵습니다.

리다이렉트는 특히 canonical 정리와 함께 봐야 합니다. Vercel 배포 후 www, non-www, canonical을 한 번에 정리하는 방법에서 다룬 것처럼 실제 접속 주소, canonical, sitemap, 내부 링크가 같은 방향을 가리켜야 합니다. 리다이렉트는 새 주소로 보내는데 canonical은 예전 주소를 가리키는 식이면 신호가 섞입니다.

404로 두는 게 나은 경우

반대로 모든 없는 주소를 어딘가로 보내는 것은 좋지 않습니다. 특히 홈으로 전부 보내는 방식은 피하는 편이 좋습니다. 사용자는 특정 글을 기대했는데 갑자기 홈으로 떨어지면, 사이트가 뭔가 숨긴 것처럼 느껴질 수 있습니다.

아래는 404로 두는 편이 낫습니다.

• 대체할 글이 전혀 없는 삭제된 초안
• 자동 생성되었던 테스트 주소
• 스팸성 외부 링크가 만든 이상한 URL
• 존재한 적 없는 오타 주소
• 예전 글이 완전히 폐기되어 더 이상 추천할 수 없는 경우
• 비슷한 주제는 있지만 같은 답을 주지 못하는 경우

404는 실패 화면이 아니라 정직한 안내 화면입니다. “이 주소는 더 이상 없습니다. 대신 홈이나 블로그 아카이브에서 다시 찾아보세요.”라고 말하면 됩니다. 이 프로젝트의 src/app/not-found.tsx는 바로 그 역할을 합니다. 찾는 페이지가 아카이브에 없다고 설명하고, 홈과 블로그 목록으로 돌아가는 링크를 제공합니다.

좋은 404 페이지는 과하게 재치 있지 않아도 됩니다. 중요한 건 사용자가 다음 행동을 할 수 있게 해주는 것입니다.

좋은 404 페이지가 갖춰야 할 것

404 페이지는 사이트의 작은 안전망입니다. 독자가 깨진 링크를 눌렀을 때, 거기서 완전히 끊기지 않게 도와줍니다. 작은 블로그에서는 아래 정도만 갖춰도 충분합니다.

현재 이 프로젝트의 404 페이지는 이 기준에 잘 맞습니다. “찾으시는 페이지가 아카이브에 없습니다”라고 말하고, 홈과 아카이브로 돌아가는 길을 줍니다. 특히 블로그 중심 사이트에서는 검색창이 아직 없어도 아카이브 링크만으로 꽤 좋은 복구 경로가 됩니다.

나중에 글이 더 많아지면 404 페이지에 인기 글, 최신 글, 카테고리 링크를 추가할 수도 있습니다. 다만 처음부터 너무 많은 선택지를 주기보다는, 홈과 블로그 목록처럼 실패 가능성이 낮은 링크를 먼저 두는 편이 좋습니다.

리다이렉트는 기록으로 관리해야 합니다

리다이렉트는 한 번 추가하고 잊기 쉽습니다. 하지만 블로그가 오래되면 리다이렉트가 쌓이고, 나중에는 왜 이 규칙이 있는지 모르게 됩니다. 그래서 저는 리다이렉트를 코드나 설정으로 관리하더라도, 최소한의 이유를 함께 남기는 편을 추천합니다.

예를 들면 이런 표를 내부 문서에 둘 수 있습니다.

이 기록이 있으면 나중에 리다이렉트를 정리할 때 훨씬 편합니다. 특히 Cloudflare Pages, Vercel, Next.js 설정이 섞인 프로젝트에서는 리다이렉트가 어디에 정의되어 있는지 헷갈리기 쉽습니다.

Next.js 안에서 처리할지, 배포 플랫폼에서 처리할지도 기준을 정해야 합니다.

원칙은 단순합니다. 글 slug 변경처럼 콘텐츠와 가까운 규칙은 코드나 문서와 함께 관리하고, 도메인 통합처럼 인프라와 가까운 규칙은 배포 플랫폼에서 관리하는 편이 자연스럽습니다.

redirect chain은 만들지 않는 편이 좋습니다

리다이렉트에서 자주 생기는 문제는 chain입니다. 예전 주소가 중간 주소로 가고, 중간 주소가 다시 새 주소로 가는 구조입니다.

/old-post -> /newer-post -> /final-post

이런 흐름은 사용자는 잘 못 느낄 수도 있지만, 관리자는 점점 헷갈립니다. 가능하면 예전 주소는 최종 주소로 바로 보내는 편이 좋습니다.

/old-post -> /final-post
/newer-post -> /final-post

특히 도메인 리다이렉트와 slug 리다이렉트가 겹치면 chain이 생기기 쉽습니다. 예를 들어 http에서 https로, non-www에서 www로, 예전 slug에서 새 slug로 차례대로 이동하면 요청 하나가 여러 번 튈 수 있습니다. 출시 직후나 URL 개편 직후에는 실제로 예전 주소를 열어 최종 도착 주소와 응답 상태를 확인해야 합니다.

이 점은 블로그 출시 직후 7일 동안 확인해야 할 운영 체크리스트의 공개 주소와 canonical 점검 단계와도 이어집니다. 첫 주에 대표 주소를 잡았다면, 이후 URL 변경 때도 같은 원칙을 계속 적용하면 됩니다.

내부 링크는 항상 최종 주소로 고칩니다

리다이렉트를 추가했다고 해서 내부 링크를 그대로 두면 안 됩니다. 사이트 내부에서는 항상 최종 주소로 직접 연결하는 편이 좋습니다. 예전 주소가 리다이렉트되더라도, 내부 링크가 계속 예전 주소를 가리키면 다음과 같은 문제가 남습니다.

• 사용자가 불필요한 이동을 거칩니다.
• 운영자가 예전 주소를 계속 정상 주소처럼 착각합니다.
• sitemap과 내부 링크 신호가 어긋납니다.
• 나중에 리다이렉트를 제거하기 어렵습니다.

따라서 slug를 바꿨다면 해야 할 일은 세 가지입니다.

1. 예전 주소에서 새 주소로 301 리다이렉트를 추가합니다.
2. 사이트 내부 링크를 모두 새 주소로 바꿉니다.
3. sitemap과 canonical이 새 주소만 가리키는지 확인합니다.

리다이렉트는 외부에서 들어오는 사람을 위한 안전망이고, 내부 링크는 사이트가 스스로 쓰는 정답입니다. 이 둘을 섞어 생각하면 안 됩니다.

삭제한 글을 어디로 보낼지 애매할 때

가장 어려운 경우는 삭제한 글입니다. 같은 내용의 새 글이 있으면 리다이렉트하면 됩니다. 문제는 비슷하지만 완전히 같지는 않은 글이 있을 때입니다.

예를 들어 예전 글이 “Next.js 블로그 시작하기”였고, 새 글이 “Next.js 이미지 최적화”라면 둘은 같은 글이 아닙니다. 이때 예전 글을 새 글로 보내면 사용자는 기대한 답을 얻지 못합니다. 그런 경우에는 404가 더 정직합니다. 대신 404 페이지에서 블로그 목록으로 돌아갈 수 있게 하면 됩니다.

반대로 예전 글이 너무 짧고 부실해서 새 글로 완전히 흡수했다면 리다이렉트가 맞을 수 있습니다. 이때는 새 글 본문 안에서 예전 글의 핵심 질문을 실제로 답해야 합니다. 단순히 비슷한 키워드가 들어간다고 같은 문서가 되는 것은 아닙니다.

판단 기준은 아래처럼 잡으면 됩니다.

억지 리다이렉트는 단기적으로 404를 줄여 보이게 만들 수 있지만, 장기적으로는 탐색 신뢰를 떨어뜨립니다.

Search Console에서는 404 숫자보다 원인을 봅니다

Search Console에서 404나 not found 관련 항목이 보이면 불안해질 수 있습니다. 하지만 모든 404가 고쳐야 할 문제는 아닙니다. 존재한 적 없는 이상한 URL, 외부에서 잘못 링크한 주소, 오래전에 삭제한 테스트 페이지는 404가 정상일 수 있습니다.

볼 것은 숫자 자체보다 패턴입니다.

• 중요한 글의 예전 slug가 404로 남아 있는가
• 내부 링크에서 404가 발생하는가
• sitemap에 없는 주소가 계속 크롤링되는가
• 도메인 변경 후 예전 도메인 URL이 제대로 이동하는가
• 대량의 이상한 URL이 외부에서 들어오는가

내부 링크에서 발생한 404는 바로 고쳐야 합니다. 반대로 외부에서 잘못 만든 이상한 주소라면 무리하게 리다이렉트할 필요가 없습니다. Search Console은 문제를 보여주는 도구이지, 모든 항목을 0으로 만들어야 하는 점수판은 아닙니다.

제가 쓰는 판단 체크리스트

새 404나 예전 URL을 발견하면 저는 아래 순서로 봅니다.

이 체크리스트만 있어도 대부분의 상황은 정리됩니다. 핵심은 “없는 주소를 모두 숨긴다”가 아니라 “주소의 의미에 맞게 응답한다”입니다.

마무리

404와 리다이렉트는 작은 블로그에서도 꽤 중요한 운영 기준입니다. 404는 실패가 아니라 대체 콘텐츠가 없다는 정직한 응답이고, 리다이렉트는 같은 콘텐츠가 새 주소로 이동했다는 안내입니다. 이 둘을 구분하지 않으면 사용자는 길을 잃고, 검색 신호는 흐려지고, 운영자는 나중에 URL 이력을 이해하기 어려워집니다.

가장 좋은 습관은 slug를 함부로 바꾸지 않는 것입니다. 그래도 바꿔야 한다면 예전 주소에서 새 주소로 바로 보내고, 내부 링크와 sitemap, canonical까지 함께 정리합니다. 대체할 내용이 없다면 억지로 홈이나 비슷한 글로 보내지 말고, 친절한 404 페이지에서 다시 탐색할 수 있게 합니다. 작은 블로그의 신뢰는 이런 사소해 보이는 길 안내에서 꽤 많이 만들어집니다.