사이트맵 404 오류 98% 해소
목차
사이트맵에서 대량의 404 에러가 발생 중이었다. 검색 엔진이 사이트맵을 크롤링할 때 나열된 URL의 거의 대부분이 존재하지 않는 상태였고, 이는 SEO 관점에서 매우 심각한 문제였다. 동적 라우팅으로 생성되는 슬러그 기반 URL들의 정규주소(canonical URL) 처리가 제대로 되지 않은 게 원인이었다. 정규주소 라우트를 체계적으로 추가해서 사이트맵 404 에러를 98% 감소시켰다.
사이트맵과 정규주소가 맞지 않던 문제
상황이 꽤 황당했다. 사이트맵 XML을 생성할 때는 게시글 슬러그를 기반으로 URL을 나열하는데, 실제로 그 URL들에 접속하면 404가 나는 경우가 대부분이었다. 검색 엔진 입장에서 보면, "여기 콘텐츠 있어"라고 광고한 사이트맵을 따라가는데 문을 열면 아무것도 없는 셈이다.
이런 현상은 보통 두 가지 원인에서 비롯된다. 첫째는 실제로 라우트가 존재하지 않는 경우고, 둘째는 라우트는 존재하지만 정규주소 설정이 일관되지 않은 경우다. 우리의 경우는 후자였다. 같은 콘텐츠를 여러 경로로 접근할 수 있도록 설계되어 있었는데 (예: /post/slug, /content/slug, /blog/slug 등), 사이트맵 생성 시에는 특정 경로 형식만 나열되고 있었던 것이다.
검색 엔진은 이런 상황에서 혼란스러워한다. 중복 콘텐츠로 판단할 수도 있고, 사이트맵이 부정확하다며 신뢰도를 떨어뜨릴 수도 있다. SEO 측면에서는 색인 우선순위가 흔들리고, 최악의 경우 검색 순위 저하까지 이어진다.
정규주소로 모든 라우트 통합하기
해결책은 명확했다. 정규주소를 명시적으로 선언하고, 모든 라우트가 그 정규주소를 가리키도록 설정하는 것이다. Astro 환경에서는 HTML <head>에 <link rel="canonical">을 추가해서 이를 구현했다. 이는 검색 엔진에게 "이 페이지의 정식 주소는 이것"이라고 명확히 알려주는 표준 방식이다.
변경된 파일들의 역할을 정리하면:
| 파일 | 역할 | 수정 내용 |
|---|---|---|
src/pages/[slug].astro |
핵심 동적 라우팅 | 정규주소 메타 태그 추가 |
src/layouts/Post.astro |
게시글 레이아웃 | 각 게시글의 canonical URL 설정 |
src/lib/eligibility.ts |
URL 유효성 검증 | 정규주소 명시 여부까지 검증 로직 추가 |
src/pages/author/gov-editor.astro |
작성자 페이지 | 정규주소 처리 |
src/pages/c/[category].astro |
카테고리 페이지 | 정규주소 처리 |
src/pages/index.astro |
홈페이지 | 메타 정보 일관성 확보 |
핵심은 같은 콘텐츠에 접근할 수 있는 모든 경로에 대해 일관된 정규주소를 명시하는 것이었다. 검색 엔진이 "결국 같은 페이지"라고 정확히 인식하도록 한 것이다. 동시에 사이트맵 생성 로직을 수정해서 정규주소만 나열하도록 했다. 이렇게 하면 크롤러가 추적할 URL이 명확하고, 중복 색인 문제도 원천 차단된다.
개선 효과와 SEO 영향
수정 후 사이트맵을 다시 생성하고 검증 도구로 확인해보니, 404 오류가 거의 모두 사라졌다. 98% 감소라는 수치는 사이트맵에 나열된 URL 중 대부분이 이제 유효한 페이지라는 뜻이다.
이 개선이 가져오는 긍정적 효과들:
- 크롤 효율 향상: 검색 엔진 봇의 제한된 크롤링 예산이 유효한 페이지에 집중된다
- 색인 신뢰도 증가: 정확한 사이트맵은 검색 엔진이 우리 사이트를 더 정확히 파악하게 한다
- 중복 콘텐츠 판정 해소: 정규주소 명시로 의도하지 않은 중복 페널티를 피한다
- 검색 순위 안정화: 동일 콘텐츠가 여러 URL로 경쟁하는 상황이 제거된다
작은 개선처럼 보이지만, 검색 유입이 중요한 서비스라면 이런 SEO 기초 작업이 누적되면 수개월 뒤 트래픽 그래프에 명확히 나타난다.
회고: 정규주소 설정은 아키텍처 결정
이 작업을 하면서 깨달은 건, 정규주소 설정이 단순한 "SEO 팁"이 아니라는 점이다. 특히 동적 라우팅을 사용하고 같은 콘텐츠를 여러 경로로 제공하는 구조에서는 처음부터 정규주소를 설계에 포함시키는 게 중요하다.
실무에서 자주 놓치는 부분은, 사이트맵 생성 로직을 짜면서 "404 반환 안 함"까지만 검증하고, 정규주소가 명시되었는지는 확인하지 않기 쉽다는 것이다. URL이 살아있다고 해서 그 경로가 정규주소인지, 아니면 리다이렉트 대상인지 구분해야 한다. eligibility.ts 같은 검증 모듈에서부터 이를 엄격히 체크하는 게 버그를 줄이는 지름길이다.
팀에 제안한 건, 동적 라우팅이 필요한 경우 항상 먼저 "정규주소는 어느 것으로 할 건가"를 결정하고, 그 결정을 코드에 명시적으로 반영하는 것이다. 그렇게 해야 나중에 사이트맵, robots.txt, 메타 데이터 일관성 문제로 야단치는 상황을 피할 수 있다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.