블로그 URL을 슬러그에서 ID 기반으로 바꿔 SEO 안정성 확보

배경: slug 변경이 만드는 SEO 문제

제목을 수정하거나 콘텐츠를 개선할 때마다 URL 슬러그가 바뀌면서 기존 링크들이 깨지는 문제가 있었다. 검색 엔진이 이전 URL을 인덱싱하고 있다가 갑자기 404를 만나면 de-indexing 현상이 발생하는데, 이게 꽤 심각한 SEO 타격이다. 특히 외부 사이트나 SNS에서 링크되어 있는 콘텐츠라면 더 그렇다.

기존에는 /author-name/article-title-slug/ 형태의 URL을 사용했을 텐데, 이렇게 하면 의미 있는 정보를 URL에 담을 수 있다는 장점이 있지만 제목 변경이라는 단순한 수정이 URL 구조를 흔든다는 치명적 단점이 있다. 팀과 논의 결과 안정적인 URL 구조가 UX의 약간의 손실보다 중요하다고 판단했고, ID 기반의 /p/{id}/ 형식으로 통일하기로 했다.

작업 범위와 의사결정

이 리팩토링은 단순한 라우팅 변경이 아니었다. 데이터베이스 쿼리(src/lib/db.ts), 글 작성/편집 페이지(src/pages/author/ssul-editor.astro), 카테고리 페이지(src/pages/c/[category].astro), 홈페이지(src/pages/index.astro), 그리고 RSS 피드(src/pages/rss.xml.js)까지 연쇄적으로 손봐야 했다.

특히 고민했던 부분이 점진적 마이그레이션 vs 파괴적 변경이었다:
- 점진적 방식: 구형 URL에서 신규 URL로 301 리다이렉트하면서 천천히 전환 (seo에 안전, 구현 복잡)
- 파괴적 방식: 구 URL 페이지는 지우고 새 URL로 한 번에 전환 (간단, 그동안 누적된 SEO 신호 손실 위험)

결국 구 URL의 301 리다이렉트 파일을 별도로 준비하되, 신규 페이지 구조는 ID 기반으로 명확하게 가져가기로 했다. 이 정도면 검색 엔진이 링크 주스를 이어받을 수 있으면서도 향후 유지보수가 깔끔해진다.

기술적 처리

코드 측면에서 가장 신경 썼던 것은 쿼리 성능이었다. ID는 integer 또는 UUID일 텐데, slug 대비 훨씬 빠르게 색인되므로 조회 성능은 오히려 개선될 가능성이 높다. DB 스키마에 이미 id가 primary key로 설정되어 있었으니 추가 마이그레이션은 최소화할 수 있었다.

회고와 일반론

이런 라우팅 리팩토링을 할 때 팀과 함께 고려해야 할 점들:

1. SEO 영향 추정: slug-based URL은 사용자 친화적이지만 안정성이 약하다. 콘텐츠 변경이 빈번한 서비스라면 ID 기반이 낫다.
2. 마이그레이션 비용: 기존 링크, 북마크, 외부 참조 등이 깨지지 않도록 충분한 리다이렉트 전략이 필요.
3. 팀 커뮤니케이션: 콘텐츠 팀, 마케팅 팀도 URL 변경 일정을 알아야 한다. 외부에 공지된 링크가 있다면 더욱.
4. 모니터링: 변경 후 한 달간 404 에러, 검색 순위 변동을 꾸준히 모니터링해야 한다.

비슷한 상황이 또 오면, 신규 URL 구조는 ID나 UUID처럼 변하지 않는 식별자를 우선으로 두고, 사용자 경험 차원에서 필요하면 title이나 slug를 서브 패라미터로 넣는 방식 (예: /p/123/?slug=article-title) 을 고려하겠다.

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

• 노트북 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

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