SEO가 깨지지 않는 공개 라우트 계약 설계

문제 정의

SPA는 브라우저 안에서 라우팅이 잘 되면 정상처럼 보입니다. 하지만 View Source나 curl 기준 HTML이 비어 있으면 검색엔진과 외부 도구는 페이지 내용을 제대로 읽지 못할 수 있습니다. 공개 라우트는 내부 화면 전환이 아니라 외부에 약속한 URL 계약입니다.

이 계약이 흔들리면 글이 존재해도 검색 결과에는 다른 도메인이나 오래된 페이지가 더 강하게 노출됩니다.

상황과 배경

블로그는 홈, 글 목록, 카테고리 목록, 카테고리 상세, 글 상세, 정책 페이지처럼 공개 URL이 많습니다. 이 중 하나라도 정적 HTML, canonical, sitemap에서 빠지면 사용자와 검색엔진의 탐색 경로가 달라집니다.

SPA SEO의 기본 점검은 SPA에서 신경 써야 할 SEO 체크리스트에서 더 넓게 다룹니다.

공개 라우트 계약의 핵심

• 초기 HTML: h1, 요약, 주요 글 제목이 JS 실행 전에도 있어야 합니다.
• canonical: blog 도메인의 페이지는 blog 도메인으로 자기 자신을 가리켜야 합니다.
• sitemap: 홈, 카테고리, 글 상세, 신뢰 페이지가 빠지지 않아야 합니다.
• fallback: 새로고침과 직접 접근이 같은 화면을 보여야 합니다.

실제 적용 방법

라우트 목록을 코드 안에서 한 번만 정의하고 sitemap, 정적 route shell, 프론트 라우터가 같은 기준을 쓰게 만듭니다. 글 slug는 DB, API, sitemap, OG 이미지 경로가 모두 같은 값을 사용해야 합니다. 카테고리도 label과 slug를 분리해 한국어 UI와 안정적인 URL을 함께 유지합니다.

새 글 배포 후에는 smoke test로 글 상세 HTML과 sitemap 포함 여부를 확인합니다.

홈에서 어떤 공개 경로를 먼저 보여 줄지는 콘텐츠 허브 큐레이션 기준과 함께 결정하면 좋습니다.

운영 체크리스트

• 공개 URL 목록을 문서나 코드 상수로 관리합니다.
• slug 변경은 redirect 계획 없이는 하지 않습니다.
• canonical이 메인 서비스 도메인으로 잘못 향하지 않는지 확인합니다.
• 글 상세는 제목, summary, 본문 첫 섹션을 초기 HTML에 포함합니다.
• 카테고리 count와 실제 필터 결과가 일치하는지 테스트합니다.

결론

공개 라우트는 프론트엔드 구현 세부가 아니라 검색과 공유의 계약입니다. 이 계약을 명확히 관리하면 SPA도 검색엔진이 읽을 수 있는 블로그로 운영할 수 있습니다.