기록 목록공지사항
sitemap 정책 정리하면서 정리된 운영 기준
humanpchumanpc ·
05-2927
최근 sitemap 정책을 다시 정리하면서 의외로 운영에서 중요한 기준 하나를 다시 확인했습니다.
초기에는 locale 확장을 어느 정도 허용하는 방향도 고려했는데, 실제 운영과 검색엔진 관점에서는 결국 "보여줄 수 있는 URL 수"보다 "대표 URL을 얼마나 안정적으로 유지하느냐"가 훨씬 중요했습니다.
이번에 정리한 기준은 단순합니다.
* root만 locale 파생 허용
* 나머지는 canonical 1개만 유지
* sitemap은 "렌더 가능한 모든 URL"이 아니라 "색인 대표 URL"만 제공
즉 현재 기준은 아래처럼 정리됩니다.
허용:
```xml
<loc>https://hub.glitter.kr</loc>
<loc>https://hub.glitter.kr?locale=en</loc>
```
제외:
```xml
/projects?locale=en
/projects/{slug}?locale=en
/board/...?...
/page/...?...
```
실제로 운영하면서 느낀 건 locale 파생 URL을 계속 sitemap에 넣기 시작하면 이후 플랫폼이 늘어날수록 URL 조합이 급격히 증가한다는 점이었습니다.
예를 들어:
* projects
* archive
* labs
* videos
* board
* page
같은 구조가 추가되기 시작하면 locale 조합까지 함께 색인 대상으로 퍼집니다.
결국 sitemap이 "대표 URL 목록"이 아니라 "파생 URL 나열기"처럼 변하기 시작합니다.
이번에는 아예 정책을 명시적으로 고정했습니다.
* root만 locale expansion 허용
* 비root는 canonical 1개만 유지
* sitemap은 canonical-first 정책 유지
생각보다 이런 건 구현보다 운영 문서화가 더 중요하더군요.
처음엔 그냥 generator 수정 정도로 끝날 작업처럼 보였는데, 시간이 지나면 왜 그렇게 했는지 잊기 시작합니다.
그래서 이번에는 아예:
```text
docs/backend/seo-sitemap-policy.md
```
로 정책 문서를 따로 분리해 두었습니다.
나중에 플랫폼이 더 늘어나도:
* "왜 locale URL을 막았는가"
* "왜 canonical 1개만 유지하는가"
* "왜 sitemap을 작게 유지하는가"
를 다시 설명할 필요가 줄어들 것 같습니다.
운영하다 보면 결국 중요한 건 URL을 많이 만드는 게 아니라, 검색엔진에게 "대표 URL이 무엇인지 흔들리지 않게 전달하는 것"에 가까운 듯합니다.
댓글과 작업 영역을 나중에 불러옵니다
필요할 때 댓글과 작업 영역을 불러옵니다. 댓글 0개
