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 페이지에서 다시 탐색할 수 있게 한다. 작은 블로그의 신뢰는 이런 사소해 보이는 길 안내에서 꽤 많이 만들어진다.