당신의 다국어 사이트는 아마 한 언어만 색인되고 있습니다
같은 URL에서 자바스크립트로 언어를 바꾸는 것은 여섯 개의 번역을 검색엔진에 보이지 않게 만드는 가장 흔한 방법입니다. 실제로 무엇이 색인되는지, 그리고 정적 사이트를 어떻게 구성해야 그런 일이 없는지.
자주 보는 패턴이 있습니다. 어떤 회사가 사이트를 여섯 언어로 번역하고 언어 전환기를 붙였는데, 어느 신규 시장에서도 유입이 없습니다. 번역 품질은 좋습니다. 아무도 찾지 못할 뿐입니다.
원인은 거의 언제나 같고, 편집이 아니라 구조의 문제입니다.
검색엔진이 색인하는 것은 URL이지 애플리케이션 상태가 아니다
언어 전환기가 페이지의 텍스트를 바꾸고 그 선택을 localStorage나 쿠키에 기억한다면, 모든 언어가 하나의 URL을 공유합니다.
크롤러는 그 URL을 요청해 HTML에 구워진 언어를 받고 그것을 색인합니다. 검색 관점에서 나머지 여섯 번역은 존재하지 않습니다. 순위를 매길 두 번째 URL도, 별도의 제목도 설명문도 없습니다.
이건 우회해야 할 크롤러의 한계가 아닙니다. URL이 색인의 단위입니다. 하나의 URL은 색인된 하나의 문서를 뜻합니다.
검사는 간단합니다. 당신의 페이지를 일본어로 여는 링크를 누군가에게 보낼 수 있습니까? 못 한다면 구글도 일본어판을 색인할 수 없습니다.
클라이언트 전환이 괜찮은 경우
이 방식에도 공정해야 합니다. 언제나 틀린 건 아닙니다. 페이지가 본문 내용으로 찾아지는 종류가 아니라면 클라이언트 전환은 충분히 합리적입니다.
- 로그인 뒤의 앱 화면
- 대시보드와 사내 도구
- 광고, 추천, 입소문으로 유입되는 소규모 소개 사이트
그 언어들에서 자연 검색 유입을 원하는 순간 문제가 됩니다. 콘텐츠 마케팅, 문서, 블로그가 정확히 그 경우입니다.
각 언어에 진짜 URL을 주세요
흔한 세 가지 구조이고, 검색엔진은 모두 받아들입니다.
| 구조 | 예 | 비고 |
|---|---|---|
| 하위 디렉터리 | example.com/ja/page | 가장 단순. 도메인 권위를 물려받음. 보통 이게 정답. |
| 서브도메인 | ja.example.com/page | 가능하지만 DNS와 인증서 관리가 늘어남. |
| 별도 도메인 | example.jp/page | 지역 신호는 가장 강하고 비용도 최대. 각 도메인이 따로 권위를 쌓음. |
대부분의 팀에는 하위 디렉터리를. 권위가 쌓이는 도메인 하나를 갖고, 인프라 작업도 늘지 않습니다.
그다음, 이 페이지들이 서로 연결됨을 알리세요
URL을 나누기만 하면 새로운 위험이 생깁니다. 같은 말을 하는 일곱 페이지가 중복처럼 보일 수 있습니다. hreflang은 "이건 같은 페이지의 다른 언어판이니 알맞은 것을 보여 달라"고 말하는 방법입니다.
모든 판에, 자기 자신을 포함한 모든 판을 나열합니다.
<link rel="alternate" hreflang="en" href="https://example.com/en/page">
<link rel="alternate" hreflang="vi" href="https://example.com/vi/page">
<link rel="alternate" hreflang="ja" href="https://example.com/ja/page">
<link rel="alternate" hreflang="x-default" href="https://example.com/en/page">여기에 각 페이지가 자기 자신을 가리키는 canonical을 더합니다.
<link rel="canonical" href="https://example.com/ja/page">이것을 망치는 다섯 가지 실수
- 되돌아오는 링크 누락.
hreflang은 상호적이어야 합니다. 영어 페이지가 일본어를 가리키는데 일본어가 되가리키지 않으면 그 짝은 무시됩니다. 압도적으로 가장 흔한 실패입니다. - canonical이 다른 언어를 가리킴. 일본어 페이지의 canonical이 영어 URL을 가리키면 그 페이지를 버리라고 지시하는 셈입니다. canonical은 자기 자신을 가리켜야 합니다.
- 언어와 지역 혼동.
hreflang="ja"는 일본어라는 언어입니다.hreflang="ja-JP"는 일본 전용 일본어입니다. 지역별 판이 실제로 있는 게 아니라면 지역 없는 언어 코드를 쓰세요. 불필요하게 좁히면 다른 지역 독자를 잃습니다. - 코드 오류. 지역 하위 태그는 언어 코드가 아니라 국가 코드입니다. 영국 영어는
en-GB이지en-UK가 아닙니다. 중국어는 국가보다 문자가 중요해서zh-Hans와zh-Hant가 됩니다. - 상대 URL.
hreflang과 canonical에는 프로토콜과 도메인이 포함된 절대 URL이 필요합니다.
슬러그도 번역하세요
쉽게 얻을 수 있는데 건너뛰는 이득: URL 안의 단어는 해당 언어에서 관련성 신호입니다. 베트남어 페이지가 /vi/how-to-look-up-a-character에 있다면 그 URL은 베트남어로는 아무것도 기여하지 않습니다.
슬러그를 번역하고, 판끼리 짝지을 안정적인 내부 식별자를 두세요. 이 블로그가 정확히 그렇게 구성되어 있습니다. 각 글은 절대 바뀌지 않는 id와 언어마다 달라지는 slug를 가집니다.
IP 기반 자동 리디렉션은 하지 마세요
솔깃하고, 실제로 해롭습니다. 방문자의 국가를 감지해 강제로 리디렉션하면:
- 크롤러는 대개 한 국가에서 요청하므로 한 판만 보게 될 수 있습니다.
- 의도적으로 다른 언어를 고른 사람을 덮어씁니다. 일본에 있는 많은 사람이 영어로 읽고 싶어 합니다.
강제 말고 제안을. 배너를 띄우고, 전환기를 잘 보이게 두고, 내용은 URL이 결정하게 하세요.
정적 사이트라면 이건 쉽습니다
위의 어느 것도 CMS나 서버를 필요로 하지 않습니다. 빌드 시점에 페이지당 언어당 HTML 파일을 하나씩 생성하고, 올바른 태그를 구워 넣고, 폴더를 업로드하면 됩니다. 산출물은 순수한 정적 파일이고, 똑똑함은 배포 전에 돌리는 생성기 안에 있습니다.
이 블로그도 그렇게 합니다. 내용은 글마다 언어마다 파일 하나로 관리하고, 작은 스크립트가 hreflang, canonical, JSON-LD, 언어별 사이트맵 항목이 붙은 HTML을 생성합니다. 사이트 자체는 백엔드 없이 정적 파일 폴더 그대로입니다.
점검 목록
- 각 언어가 남에게 보낼 수 있는 고유 URL을 가짐
- 각 페이지가 자기 자신을 포함한 모든 언어를
hreflang에 나열하고 상호 대응함 - 맞는 판이 없는 방문자를 위한
x-default가 있음 - 각 페이지의 canonical이 자기 자신을 가리킴
- 슬러그가 번역되고, 내부적으로는 안정적인 id로 짝지어짐
- 사이트맵이 각 언어 URL과 대체판을 나열함
html lang이 실제 내용과 일치함- IP 기반 강제 리디렉션이 없음