다국어 블로그는 번역 자체는 잘 되어 있어도 검색엔진에는 어색하게 보일 수 있습니다. 보통 문제는 글 내용보다 canonical URL과 alternate language 관계를 어떻게 표현했는지에 있습니다. 특히 글 상세만 맞고 카테고리, 아카이브, fallback 페이지에서 패턴이 깨지는 경우가 많습니다.
이 글은 self-canonical을 언제 써야 하는지, hreflang 쌍이 어떻게 연결되어야 하는지, x-default를 어디에 두면 좋은지, 그리고 실제 렌더 결과에서 무엇을 확인해야 하는지를 실전 기준으로 정리한 가이드입니다.
canonical과 hreflang은 서로 다른 일을 합니다
canonical은 이렇게 말합니다.
- 이 페이지 버전의 대표 URL은 이것이다
hreflang은 이렇게 말합니다.
- 이 콘텐츠의 다른 언어 버전은 이것들이다
한 언어 페이지를 다른 언어 페이지로 canonical 처리하면 보통 도움이 되지 않습니다. localized page의 독립적인 가치를 약하게 만들기 쉽습니다.
건강한 다국어 구조는 어떤 모습일까
한국어와 영어 블로그라면 보통 아래 패턴이 가장 자연스럽습니다.
- 한국어 페이지는 자기 자신을 canonical로 가리킨다
- 영어 페이지는 자기 자신을 canonical로 가리킨다
- 각 페이지는 실제 alternate language version과 연결된다
x-default는 일관된 기본 경험을 가리킨다
즉 서로 다른 페이지를 합치는 것이 아니라, 관련된 페이지로 연결하는 구조입니다.
왜 self-canonical이 중요한가
많은 다국어 설정이 canonical을 duplicate-control 지름길처럼 다루다가 망가집니다.
하지만 localized page는 보통 각각 독립적인 실제 페이지입니다. 그래서 기본값은 self-canonical이어야 합니다.
- 한국어는 한국어를 canonical로
- 영어는 영어를 canonical로
그리고 cross-language 관계는 hreflang으로 처리해야 합니다.
x-default는 언제 도움이 될까
x-default는 특정 언어와 정확히 맞는 페이지가 없는 사용자에게 fallback URL을 알려줄 때 유용합니다.
많은 2개 언어 블로그에서는 보통 아래 중 하나입니다.
- 기본 언어 홈
- 해당 경로의 기본 언어 버전
핵심은 일관성입니다. fallback이 페이지마다 들쭉날쭉하면 신호가 약해집니다.
어떤 페이지에 hreflang을 넣어야 하나
hreflang은 실제로 서로 대응되는 페이지가 있을 때 가치가 큽니다.
좋은 예:
- 글 상세와 번역 글
- 카테고리 페이지와 대응 카테고리 페이지
- 블로그 인덱스와 대응 인덱스
좋지 않은 예:
- 같은 주제라는 이유만으로 서로 다른 성격의 글을 alternate처럼 연결하는 경우
매핑 기준은 주제 유사성이 아니라 페이지 대응 관계여야 합니다.
전체 메타데이터 맥락을 같이 보고 싶다면 Technical Blog SEO Checklist for Astro를 곁들여 보는 것이 좋습니다.
다국어 블로그에서 흔한 실수
영어 페이지 canonical을 한국어 원문으로 보내는 경우
이렇게 하면 영어 페이지는 자기 버전의 대표 URL이 아니라는 신호를 줍니다.
페이지 유형마다 canonical 로직이 들쭉날쭉한 경우
글 상세는 한 방식인데 카테고리는 다른 방식이면 사이트 전체 해석이 어려워집니다.
카테고리와 아카이브 페이지를 비워두는 경우
글 상세만 alternate를 넣고 목록 페이지는 놓치는 경우가 많습니다.
URL 형식이 일관되지 않은 경우
locale prefix, trailing slash, route generation 규칙이 다르면 메타데이터도 잘못된 목적지를 가리킬 수 있습니다.
실전 점검 체크리스트
- 모든 언어 페이지가 자기 자신을 canonical로 가리키는가
- alternate가 진짜 대응 페이지를 연결하는가
x-default가 일관적인가- 카테고리 페이지도 alternate를 갖는가
- alternate URL이 실제로 열리는가
- canonical과 alternate가 같은 URL 형식 규칙을 따르는가
최종 렌더 결과에서 확인할 것
소스 컴포넌트만 보지 말고 실제 페이지 출력에서 아래를 확인해야 합니다.
- canonical URL
hreflang="ko"hreflang="en"hreflang="x-default"
글 상세는 맞는데 아카이브나 edge route에서 alternate가 빠져 있다면 다국어 구조는 아직 완성된 것이 아닙니다.
canonical과 alternate가 맞아 보이면 다음은 카테고리와 아카이브, 홈도 같은 규칙을 따르는지 SEO Guide for Technical Blogs 관점에서 같이 보면 좋습니다.
다국어 메타데이터를 보는 실전 관점
가장 안전한 사고방식은 비슷한 주제가 아니라 서로 대응되는 페이지라는 기준으로 생각하는 것입니다.
이 기준이 있으면 대부분의 실수를 피할 수 있습니다.
- 각 localized page가 실제 페이지이므로 canonical은 self-reference가 된다
hreflang은 진짜 alternate만 연결한다x-default는 duplicate control이 아니라 fallback 결정이 된다
이 모델이 분명해지면 구현은 오히려 더 단순해집니다.
FAQ
Q. 영어 페이지 canonical을 한국어 원문으로 보내야 하나요?
보통은 아닙니다. 각 언어 페이지가 자기 자신을 canonical로 가리키는 것이 자연스럽습니다.
Q. 카테고리 페이지에도 hreflang이 필요한가요?
양쪽 언어에 대응 카테고리가 있다면 필요합니다. 정보 구조의 일부이기 때문입니다.
Q. x-default는 보통 어디를 가리키나요?
보통 해당 경로의 기본 언어 버전이나 기본 글로벌 경험을 가리킵니다.
Q. 가장 흔한 구현 실수는 무엇인가요?
canonical과 hreflang을 서로 다른 역할의 신호로 보지 않고 중복 제어 태그처럼 섞어 쓰는 것입니다.
Read Next
- 구현 체크리스트를 더 자세히 보고 싶다면 Technical Blog SEO Checklist for Astro를 보세요.
- 메타데이터와 아카이브, 카테고리 구조까지 같이 정리하려면 SEO Guide for Technical Blogs가 다음 단계입니다.
Related Posts
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.
먼저 읽어볼 가이드
검색 유입이 많은 핵심 글부터 이어서 보세요.
- 미들웨어 트러블슈팅 가이드: Redis vs RabbitMQ vs Kafka 개발자를 위한 미들웨어 트러블슈팅 허브 글입니다. Redis, RabbitMQ, Kafka 중 어떤 증상부터 먼저 봐야 하는지와 어떤 문제 패턴이 각 시스템에 가까운지 정리합니다.
- Kubernetes CrashLoopBackOff: 먼저 볼 것들 startup failure, probe, config, resource limit 관점에서 CrashLoopBackOff를 어떻게 나눠서 봐야 하는지 정리한 가이드입니다.
- Kafka consumer lag가 계속 늘 때: 트러블슈팅 가이드 Kafka consumer lag가 계속 늘어날 때 무엇부터 봐야 하는지 정리합니다. poll 주기, 처리 속도, rebalance, consumer 설정까지 실전 기준으로 다룹니다.
- Kafka Rebalancing Too Often 가이드 Kafka consumer group에서 rebalance가 너무 자주 일어날 때 membership flapping, poll timing, protocol, assignment churn을 어떤 순서로 봐야 하는지 설명하는 실전 가이드입니다.
- Docker container가 계속 재시작될 때: 먼저 확인할 것들 exit code, command failure, environment mistake, health check 관점에서 Docker restart loop를 푸는 실전 가이드입니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.