AEO·GEO

병원 다국어 페이지, hreflang과 언어 리디렉션은 어떻게 점검할까?

2026-09-23 · 메디리바이브

한국어와 영어 콘텐츠는 언어별로 고정된 URL을 두고 사용자가 직접 전환할 수 있는 링크를 제공합니다. 병원 홈페이지가 한국어와 영어를 함께 제공할 때 중요한 것은 방문자를 자동으로 맞혀 보내는 기능보다 각 언어 페이지가 고정된 주소에서 열리고 서로 연결되는 구조입니다. 한국어 글 주소를 열었는데 브라우저 언어 때문에 영문 홈으로 이동한다면 사용자는 찾던 내용을 잃고 검색 로봇도 원문을 보지 못할 수 있습니다. 이 글은 Google 공식 문서를 병원 홈페이지 운영 관점에서 재구성한 가이드이며 검색 노출이나 AI 인용을 보장하지 않습니다.

Google은 언어별로 다른 URL을 사용하고 hreflang으로 대응 관계를 알리며, 사용자가 페이지 언어를 직접 전환할 수 있게 하라고 안내합니다. 또한 언어를 추정해 자동으로 다른 버전으로 리디렉션하는 방식을 피하라고 설명합니다. Googlebot은 보통 미국에서 요청하고 Accept-Language 헤더를 보내지 않기 때문에 동적 언어 처리의 모든 변형을 발견하지 못할 수 있습니다.

이 글은 번역 품질 자체를 평가하는 글이 아닙니다. 언어별 URL, hreflang 상호 참조, canonical, 자동 이동, 사용자 선택 링크가 같은 구조를 가리키는지 점검하는 방법을 설명합니다. 설정을 바꾸기 전에는 현재 응답과 검색 콘솔 관찰 결과를 보관하고 사이트 전체 변경은 별도 승인 절차를 거칩니다.

1. 언어별 콘텐츠는 고정된 URL에서 열리게 합니다

Google은 언어별 페이지에 서로 다른 URL을 사용할 것을 권장합니다. 같은 주소가 쿠키, 브라우저 설정, 접속 위치에 따라 한국어와 영어를 번갈아 보여 주면 검색 로봇과 사용자가 같은 콘텐츠를 확인하기 어렵습니다. URL이 고정되어야 내부링크, canonical, 사이트맵, 성과 기록도 언어별로 관리할 수 있습니다.

한국어 기본 글이 https://example.com/guide/이고 영어 번역이 https://example.com/en/guide/라면 두 주소가 각각 자기 언어 본문을 안정적으로 반환해야 합니다. 영어 번역이 아직 없다면 한국어 글을 영문 홈으로 보내지 않습니다. 번역 준비 중이라는 이유로 관계없는 홈을 대응 페이지처럼 처리하면 질문과 답이 끊깁니다.

언어 URL 구조는 하위 디렉터리, 하위 도메인, 국가 도메인 등 여러 방식이 가능합니다. 운영 비용과 서비스 지역을 기준으로 하나를 선택하고 일관되게 유지합니다. URL 매개변수만으로 언어를 바꾸는 방식은 관리와 이해가 복잡해질 수 있으므로 기존 구조를 점검합니다.

페이지의 언어는 보이는 본문과 내비게이션에서 분명해야 합니다. Google은 HTML lang 속성이나 hreflang만으로 페이지 언어를 판단하지 않고 실제 보이는 콘텐츠를 사용한다고 설명합니다. 메뉴만 영어이고 본문은 한국어인 혼합 페이지를 완전한 영어 번역처럼 표시하지 않습니다.

병원명, 주소, 진료시간 같은 공통 요소도 번역 페이지의 실제 운영 정보와 일치해야 합니다. 번역하면서 과거 진료시간이나 없는 서비스를 복제하지 않고 원자료 확인 날짜를 남깁니다. 번역은 원문 문장을 바꾸는 작업뿐 아니라 최신 운영 상태를 다시 확인하는 과정입니다.

먼저 언어별 URL 목록을 만듭니다. 한국어 주소, 영어 주소, 번역 완료 여부, 마지막 확인일, 담당자를 적고 대응 페이지가 없는 경우 빈칸을 관계없는 홈으로 채우지 않습니다. 이 목록이 hreflang과 사이트맵 점검의 기준표가 됩니다.

공식 근거: Google 다국어·다지역 사이트 관리 안내 ↗

2. hreflang은 한쪽 링크가 아니라 상호 관계입니다

hreflang은 언어 또는 언어·지역 변형이 서로 대응한다는 사실을 알리는 방법입니다. 한국어 페이지가 영어 페이지를 가리키면 영어 페이지도 한국어 페이지와 자기 자신을 함께 가리켜야 합니다. 한쪽에만 태그가 있거나 URL이 틀리면 대응 관계를 신뢰하기 어렵습니다.

모든 언어 버전은 자기 자신과 다른 버전을 목록에 포함합니다. 예를 들어 ko와 en 두 버전이 있으면 각 페이지의 hreflang 집합에 ko와 en이 모두 있어야 합니다. 언어 코드만으로 충분한 경우 불필요하게 지역 코드를 붙이지 않고 실제 대상이 명확할 때 언어·지역 코드를 사용합니다.

지원되지 않는 방문자를 위한 기본 경로가 필요하면 x-default를 검토할 수 있습니다. 언어 선택 페이지나 기본 버전을 지정하는 데 사용할 수 있지만, 모든 페이지에 반드시 넣어야 하는 의무는 아닙니다. 사이트 구조와 대응 페이지가 실제로 존재할 때 적용합니다.

hreflang 구현 방식은 HTML head, HTTP 헤더, 사이트맵 중 하나를 선택할 수 있습니다. Google은 세 방식이 동등하다고 설명하며, 세 가지를 모두 쓰면 검색상 이점이 늘어나는 것이 아니라 관리가 어려워질 수 있습니다. 운영팀이 검증하기 쉬운 한 방식을 일관되게 유지합니다.

번역이 일부 페이지만 준비된 경우에도 준비된 쌍에만 hreflang을 적용할 수 있습니다. 전체 사이트 번역이 끝날 때까지 기다리거나 빈 페이지를 만드는 것이 아닙니다. 대응 본문이 없는 URL을 태그에 넣지 않고 번역 완료 상태표와 함께 관리합니다.

검증할 때에는 태그의 존재만 세지 않고 각 href가 HTTP 200으로 열리는지, 최종 주소가 예상과 같은지, 반대쪽 페이지에서 돌아오는 링크가 있는지 확인합니다. 리디렉션을 거쳐 홈으로 가거나 언어가 바뀌면 hreflang 목록을 수정하기 전에 리디렉션 원인을 조사합니다.

3. canonical은 각 언어 페이지의 대표 주소를 가리킵니다

번역된 페이지는 주된 본문이 다른 언어이므로 일반적으로 서로 단순 중복으로 보지 않습니다. 한국어 글의 canonical을 영어 홈이나 영어 번역으로 통합하면 한국어 URL의 대표성이 약해질 수 있습니다. 각 언어 페이지는 보통 자기 언어의 최종 URL을 self-canonical로 가리키고 hreflang으로 관계를 알립니다.

같은 언어 안에서 추적 매개변수나 인쇄용 주소처럼 유사 URL이 있다면 언어별 대표 URL을 정합니다. 한국어 변형은 한국어 대표로, 영어 변형은 영어 대표로 모이게 합니다. canonical과 hreflang이 서로 다른 최종 주소를 가리키지 않도록 언어별 행으로 대조합니다.

지역만 다른 같은 언어 페이지처럼 본문이 매우 유사한 경우에는 canonical과 hreflang을 함께 고려할 수 있습니다. 그러나 병원 주소, 진료 체계, 이용 조건이 실제로 다르면 한 페이지로 통합할지 신중히 판단합니다. 태그는 운영 차이를 대신 설명하지 못합니다.

canonical은 강제 명령이 아니라 대표 선호를 전달하는 신호입니다. Google이 다른 URL을 대표로 선택할 수 있으므로 Search Console에서 사용자가 선언한 canonical과 Google이 선택한 canonical을 구분해 봅니다. 값이 다르면 내부링크, 리디렉션, 사이트맵, 본문 유사성, 언어 설정을 함께 조사합니다.

사이트맵에는 각 언어의 최종 색인 URL을 포함하고 필요하면 hreflang 관계를 표시합니다. 사이트맵 제출 자체가 색인이나 생성형 AI 노출을 보장하지 않습니다. 공개, 크롤링 가능, canonical, hreflang, 사이트맵 포함을 각각 별도 상태로 기록합니다.

WordPress와 WPML 같은 다국어 플러그인은 여러 설정을 자동 생성할 수 있습니다. 관리자 화면의 선택값만 믿지 않고 공개 HTML의 canonical과 alternate 링크를 파싱합니다. 플러그인 업데이트나 캐시 뒤 값이 바뀔 수 있으므로 최종 배포 후 다시 확인합니다.

점검 항목	정상 상태	문제가 되는 예
언어별 URL	한국어와 영어가 각자 고정 주소	쿠키에 따라 같은 URL 내용이 변경
hreflang	자기 자신과 대응 URL을 상호 참조	한쪽만 상대 페이지를 표시
canonical	각 언어 페이지가 자기 대표 주소를 표시	한국어 글이 영문 홈을 대표로 지정
언어 전환	사용자가 링크로 직접 선택	브라우저 언어만으로 강제 이동

4. 브라우저 언어 기반 강제 이동을 실제 요청으로 시험합니다

Google은 사용자가 페이지 언어를 직접 선택할 수 있게 하고, 사용자의 언어를 추정해 자동으로 다른 버전으로 보내는 리디렉션을 피하라고 안내합니다. 자동 이동은 사용자가 원래 페이지를 보지 못하게 만들고 검색 로봇이 모든 변형을 발견하는 것도 어렵게 할 수 있습니다.

테스트는 데스크톱 한 번으로 끝내지 않습니다. 비로그인 창, 모바일 화면, Google 스마트폰 라이브 테스트 등 실제 요청 조건에서 한국어 글 URL이 그대로 유지되는지 봅니다. 브라우저가 영문 환경이어도 요청한 한국어 페이지가 열리고 사용자가 원하면 영어 링크를 누를 수 있어야 합니다.

번역이 없는 한국어 글을 열었을 때 영문 홈으로 이동하는지 확인합니다. 이 문제는 새 콘텐츠를 더 만들기 전에 해결해야 하는 기술 장애일 수 있습니다. 검색 콘솔에서 라이브 테스트가 다른 URL을 렌더링했다면 요청한 URL, 최종 URL, canonical, 화면 본문을 함께 기록합니다.

리디렉션이 필요한 예외도 있습니다. 잘못된 옛 URL을 새 URL로 영구 이동하거나 로그인 뒤 보호된 화면으로 보내는 경우처럼 목적이 분명할 수 있습니다. 그러나 언어 선택은 사용자의 의도를 추정하기보다 명시적인 링크와 언어 선택 UI를 제공하는 편이 진단과 접근성에 유리합니다.

설정을 바꾸기 전에는 현재 동작을 캡처하고 사이트 전체 영향 범위를 확인합니다. 브라우저 언어 리디렉션을 끄는 변경은 여러 페이지와 사용 경험에 영향을 줄 수 있으므로 일반 글 발행과 구분해 승인·배포·복구 계획을 세웁니다. 이 글을 공개한다는 사실이 전역 설정 변경 승인으로 해석되지는 않습니다.

변경 후에는 한국어·영어 대표 페이지와 번역 없는 페이지를 각각 검사합니다. 언어 전환 링크가 작동하는지, 주소가 유지되는지, canonical과 hreflang이 맞는지, 사이트맵과 내부링크가 최종 URL을 가리키는지 확인합니다. 한 화면만 성공했다고 전체 사이트가 해결됐다고 보고하지 않습니다.

5. 언어 선택 경로를 한 장의 표로 관리합니다

실무 표에는 원문 URL, 대응 번역 URL, 번역 완료 여부, self-canonical, hreflang 집합, 사용자 전환 링크, 자동 이동 여부, 마지막 확인일을 적습니다. 한 줄에서 모든 신호를 보면 한국어 글이 영문 홈을 가리키거나 번역 없는 URL이 대응 목록에 들어간 문제를 찾기 쉽습니다.

다국어 사이트 성과는 언어별로 나누어 봅니다. 한국어와 영어의 검색어, 지역, 방문 목적이 다를 수 있으므로 전체 트래픽 합계만으로 구조가 맞는지 판단하지 않습니다. 번역 페이지의 방문 수가 적더라도 특정 환자군이나 파트너에게 필요한 정보라면 목적을 별도로 평가합니다.

AI 검색 최적화도 같은 기본을 사용합니다. Google은 생성형 AI 기능을 위해 별도의 AI 파일이나 특수 스키마가 필요하지 않다고 안내합니다. 각 언어 페이지가 크롤링·색인 가능하고, 보이는 콘텐츠가 명확하며, 스니펫 제어가 목표와 맞는지 먼저 확인합니다.

번역 품질과 기술 태그를 따로 점검합니다. hreflang이 정확해도 번역 본문이 오래되거나 운영 정보가 틀리면 사용자에게 도움이 되지 않습니다. 반대로 번역이 훌륭해도 자동 리디렉션 때문에 크롤러와 사용자가 페이지에 도달하지 못하면 발견이 어렵습니다.

담당자는 전역 설정 변경과 개별 콘텐츠 업데이트를 구분합니다. 글 한 편의 수정은 기존 post ID에서 진행하고, 언어 리디렉션이나 URL 구조 변경은 별도 작업으로 영향 범위를 검토합니다. 응답이 불명확하면 새 번역 글을 중복 생성하지 않고 현재 URL과 편집 기록을 먼저 확인합니다.

병원 다국어 홈페이지의 목표는 브라우저 언어를 완벽히 추측하는 것이 아니라 사용자가 원하는 언어 페이지에 도달하고 다른 언어로 쉽게 전환하도록 돕는 것입니다. 고정 URL, 상호 hreflang, 자기 canonical, 명시적 전환 링크, 라이브 테스트를 같은 표에서 관리하면 검색 로봇과 사람 모두가 같은 경로를 사용할 수 있습니다.