실제 콘텐츠와 운영 약속에서 로케일을 선택하세요
로케일은 페이지의 언어이며, 중요할 때만 지역 대상(리전)을 포함합니다. 페이지 유형, 언어, 지역, 담당자(owner), 콘텐츠 차이, URL 패턴 및 폴백을 매트릭스에 유지하세요. 주요 콘텐츠나 상업 조건이 실제로 다르고 누군가가 최신 상태로 유지할 수 있을 때만 지역 버전을 추가하세요; 일반 언어 페이지가 더 나은 선택인 경우가 많습니다.
메인 콘텐츠를 변경하지 않은 채 헤더와 푸터만 번역해 로컬이라고 표기하지 마세요. Google은 상용구(boilerplate)만 번역된 페이지가 나쁜 경험과 중복 결과를 초래할 수 있다고 경고합니다. 우선순위 카피, 가격, 재고, 정책, 지원 및 거래 메시지를 검토하세요. 페이지를 아직 지원할 수 없다면 오해의 소지가 있는 빈 껍데기를 발행하기보다는 생략하세요.
의도된 코드, 공개 URL 패턴, 담당자, canonical 대상, 폴백 및 출시 상태를 하나의 관리된 표에 기록하세요.
안정적인 URL을 사용하고 사용자가 선택하도록 하세요
각 언어 버전에 브라우저와 크롤러가 요청할 수 있는 직접 URL을 부여하세요. Google은 쿠키나 브라우저 설정으로 언어를 변경하는 것보다 서로 다른 URL을 권장합니다. 국가 도메인, 서브도메인, 서브디렉터리 모두 작동할 수 있으므로 팀이 일관되게 관리할 수 있는 패턴을 선택하세요. Google은 URL 기반 분할에 대해 URL 파라미터를 권장하지 않습니다.
언어 또는 지역 선택을 표시하고 방문자가 선택한 버전에 머물도록 하세요. Google은 추정된 언어에 기반한 자동 리디렉트는 권장하지 않으며 동적 변경이 변형의 발견을 방해할 수 있다고 조언합니다. 결정 기제로 IP 위치를 사용하지 마세요; Google은 IP 기반 판별이 어렵고 일반적으로 신뢰성이 낮으며 크롤링을 제한할 수 있다고 합니다. 직접 접근 가능한 URL과 쉽게 되돌릴 수 있는 방법을 보존하세요.
각 로케일 URL을 깨끗한 세션에서 열어 위치 기반 강제 바운스 없이 해당 버전을 제공하는지 확인하세요.
완전하고 유효한 hreflang 클러스터를 만드세요
hreflang 클러스터는 동등한 로케일 URL을 연결합니다. Google은 HTML link 요소, 비-HTML 응답을 위한 HTTP Link 헤더, 또는 XML 사이트맵 항목을 지원하며 이들 방법을 동등하게 취급합니다. 릴리스 프로세스가 생성하고 감사할 수 있는 방법을 선택하세요. 모든 대체 URL은 https를 포함한 완전한 정규화된(fully qualified) 형태여야 하며 의도된 공개 페이지로 해석되어야 합니다.
동일한 집합을 모든 동등 페이지에 게시하세요: 자기참조(self-reference)와 모든 지원되는 대안을 포함해야 합니다. Google은 페이지들이 서로를 가리키지 않을 때 태그를 무시할 수 있으며, 반환 링크(return link)가 누락되는 경우를 흔한 실수로 지적합니다. 클러스터는 공유 데이터에서 생성하고 수동 편집된 템플릿에 의존하지 마세요. 특정 로케일에서 페이지를 사용할 수 없다면 그리드를 채우기 위해 근사치 페이지를 임의로 생성하지 마세요.
나열된 모든 쌍(pair)에 대해 두 페이지가 동일한 대체 집합(자신의 URL 포함)을 노출하는지 확인하세요.
HTML head 마크업을 사용할 수 없는 현지화된 PDF에는 HTTP Link-헤더 방식을 사용하세요.
검색 구현을 염두에 두고 언어 태그를 선택하세요
언어 태그는 en, en-GB, zh-Hant 같은 식별자입니다. BCP 47은 IETF의 권장 관행 프레임워크이며 IANA Language Subtag Registry는 W3C가 저자에게 안내하는 참조 레지스트리입니다. 주요 언어로 시작한 다음 스크립트나 지역을 콘텐츠를 구별할 때만 추가하세요. W3C는 필요한 구분만 허용하도록 태그를 가능한 짧게 유지할 것을 권고합니다.
Google hreflang의 경우 모든 문법적으로 유효한 BCP 47 태그가 아니라 Google이 지원하는 코드 규칙을 따르세요. Google은 항상 언어가 먼저 오고 지역만 단독으로 쓰는 것을 허용하지 않으며 ISO 639-1 언어 코드와 선택적 ISO 3166-1 Alpha-2 지역을 문서화합니다. 예를 들어 es-419는 hreflang에서 지원되지 않는다고 Google은 명시합니다. 구현 시 코드를 확인하고 배포 검사에서 임의로 만든 값을 거부하세요.
UK 버전이 의미 있게 다를 때만 en-GB를 사용하세요; 그렇지 않다면 일반 en 버전이 더 간단합니다.
canonical, 폴백, 콘텐츠 신호를 호환되게 유지하세요
캐노니컬화(canonicalization)는 중복 또는 매우 유사한 URL들 가운데 우선 URL을 선택하고, hreflang은 의도된 대안들을 식별합니다. 독립적인 로케일 페이지에는 자기참조(self-referential) canonical 또는 동일 언어의 canonical을 사용하세요. Google은 동일 언어의 canonical 또는 가능한 최선의 대체를 권장합니다. 언어가 다른 canonical은 의도한 대안을 통합(consolidate)하여 사라지게 할 수 있습니다.
일치하는 버전이 없는 사용자를 위해 x-default를 사용하세요. 특히 언어 또는 국가 선택기와 함께 사용할 때 유용합니다. x-default는 실제 대안의 대체물이 아니라 폴백입니다. 그것이 중립적인 선택기인지 기본 언어 페이지인지 결정하고, 사용 가능하게 만들며 자동 리디렉트 루프를 피하세요. 각 페이지의 표시되는 주요 콘텐츠는 명확히 하나의 언어여야 합니다.
샘플마다 요청된 URL, 최종 URL, canonical, 인덱스 가능성, hreflang 대상, 사이트맵 항목을 비교하세요.
라우트 및 콘텐츠 변경으로서 릴리스를 테스트하세요
배포 전에 대표 템플릿 유형을 샘플링하세요: 홈, 카테고리, 상업(커머셜), 에디토리얼, 도움말, 현지화된 파일 등. 선택한 방식에 따라 전달된 head, 헤더 또는 사이트맵을 검사하세요. 공개 응답, 최종 HTTPS URL, 자기참조 및 상호 대체, canonical 대상, 표시되는 로컬 콘텐츠, 작동하는 스위처, 우연한 noindex 또는 robots 차단이 없는지 확인하세요.
출시 후 Search Console에서 대표 페이지를 검사하세요. 라이브 테스트는 Google이 현재 페이지에 접근할 수 있는지 확인하고, 인덱스 보고서는 선택된 캐노니컬을 보여줄 수 있습니다. 라이브 테스트는 선택된 캐노니컬을 예측하거나 인덱싱을 보장할 수 없습니다. 테스트한 클러스터, 예외, 담당자 및 재테스트 증거를 날짜가 있는 릴리스 로그로 보관하세요.
우선순위 페이지가 잘못 리디렉트되거나, 상호 쌍이 깨졌거나, canonical과 충돌하거나, 선택될 수 없을 때 출시는 차단하세요.
로케일 구성의 버전 관리를 하고 안전한 공유 템플릿 역전(롤백)을 위해 이전 URL과 표기 맵을 보존하세요.