개발 slecs

보관된 글 404 에러를 홈 리다이렉트로 수정

목차

보관된 상태의 글들이 404를 반환하고 있었다. 이를 홈으로의 301 영구 리다이렉트로 바꿨는데, 덕분에 이미 검색 색인에 등재된 751건 글의 링크 권한을 보존할 수 있었다.

왜 단순 404 응답이 문제였나

처음엔 "보관된 글이니까 404 내보내면 되지"라고 단순하게 생각했다. 하지만 이 접근이 여러 각도에서 손실을 초래했다.

검색 엔진 관점에서, 이미 색인된 글들은 외부 사이트의 링크나 소셜 미디어에서 들어오는 트래픽이 있다. 404 응답은 그 URL의 검색 가치(링크 에퀴티)를 완전히 버리는 셈이다. 반면 301 영구 리다이렉트는 원래 페이지의 검색 권위도를 목적지로 옮겨주기 때문에 SEO 친화적이다.

사용자 경험 측면에서도, 누군가 보관된 글로 링크를 타고 들어올 땐 404가 아니라 홈으로 자연스럽게 연결되면 최신 콘텐츠를 발견할 기회가 생긴다. 깨진 링크보다는 재진입점이 되는 셈이다.

운영 정책으로는, 750개 이상의 보관 글이 존재한다는 건 상당한 레거시 콘텐츠를 다뤄야 한다는 뜻이다. 이들을 완전히 버릴 순 없지만 직접 노출할 필요도 없다. 301 리다이렉트는 이런 "조용한 마이그레이션"의 표준 방식이다.

어떻게 구현했나

파일 역할
src/lib/db.ts ARCHIVED 상태 글 감지 로직
src/pages/[slug].astro 슬러그 기반 라우트에서 301 처리
src/pages/p/[id].astro ID 기반 라우트에서 301 처리

세 파일이 함께 움직이는 구조다. 먼저 db.ts에서 "이 글은 ARCHIVED 상태"를 판정하고, 두 동적 페이지 컴포넌트가 그 상태에 따라 리다이렉트를 실행한다.

대략 이런 식의 로직이다:

// src/pages/[slug].astro 에서
const post = await db.getPostBySlug(slug);

if (post?.status === 'ARCHIVED') {
  return Astro.redirect('/', 301);
}
// 정상 상태면 글 렌더링

외부 링크는 자동으로 홈으로 흘러가고, 검색 엔진은 이 URL의 페이지 권위를 목적지로 옮긴다.

배운 점

751건이라는 수치를 보니 이건 단순 버그 수정이 아니라 운영 정책 결정 같았다. 보관 콘텐츠 처리할 때 보통 세 가지 선택지가 있다:

  • 404 유지: 깔끔하지만 SEO 손실, 사용자는 막힌 길 경험
  • 301 리다이렉트: 링크 가치 보존, 자연스러운 재진입
  • 별도 보관 페이지: 과할 수 있음 (보관 이유, 관련 글 제시 등)

이 경우 301을 택한 건, 보관 글을 명시적으로 노출할 필요 없지만 기존 외부 링크의 가치는 버릴 수 없기 때문이다.

또 하나 배운 점: 마이그레이션 규모와 영향도를 커밋에 함께 기록하기. "301 리다이렉트"만 본다면 기술적 변경에 불과하지만, "751건 색인 보존"이라는 명시가 이 작업의 비즈니스 가치를 한눈에 보여준다. 몇 개월 뒤 이 커밋을 다시 읽을 때 "아, 이건 단순 버그 수정이 아니라 SEO 전략의 일부였구나" 하고 바로 이해된다.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.