페이지 코드에서의 hreflang 마크업은 하나의 문제지만, 독일, 폴란드 또는 브라질의 방문자가 실제로 받는 것은 전혀 다릅니다. Google은 태그를 무시할 수 있고, CDN은 잘못된 방향으로 리디렉션할 수 있으며, 서버는 IP에 따라 잘못된 버전을 제공할 수 있습니다. 모든 것이 제대로 작동하는지 확인하는 유일한 방법은 문서상의 마크업을 믿지 않고 다양한 국가에서 웹사이트를 "실시간"으로 확인하는 것입니다.
hreflang이란 무엇이며 코드에 태그만으로는 충분하지 않은 이유
hreflang은 검색 엔진에 특정 언어 또는 지역 버전의 페이지가 어떤 사용자에게 적합한지를 알려주는 속성입니다. 기술적으로는 <head> 또는 sitemap.xml에 있는 링크의 집합처럼 보이며, 각 페이지는 자신의 대체 페이지를 참조합니다: ru-RU, en-US, de-DE 등입니다.
문제는 코드 유효성 검사기(Screaming Frog, Ahrefs, Semrush)를 통해 확인할 경우 마크업에 작성된 내용만 보여준다는 것입니다. 이는 가장 중요한 질문에 답하지 않습니다: 바르샤바나 마드리드에서 실제 사람이 귀하의 웹사이트를 열 때 실제로 무슨 일이 발생합니까? 필요한 로컬로 리디렉션이 작동합니까? CDN이 캐시 때문에 사용자를 영어 버전으로 리디렉션하지 않습니까? 사용자가 모바일 통신사를 통해 접속할 경우 geo-IP가 국가를 올바르게 식별합니까?
다국적 웹사이트, 다양한 지역을 위한 랜딩 페이지 또는 특정 국가를 위한 Google Ads 및 Facebook Ads 캠페인을 테스트하는 마케팅 전문가와 SEO 전문가에게는 이것이 매우 중요합니다. hreflang이 잘못 설정되면 필요한 국가의 사용자가 잘못된 버전의 웹사이트를 볼 수 있으며, 이는 전환 손실로 이어지고 검색 엔진은 해당 국가에서 잘못된 URL을 색인할 수 있습니다.
hreflang이 "거짓말"하는 이유: 5가지 전형적인 원인
실제로 마크업과 웹사이트의 실제 동작 간의 불일치는 여러 가지 이유로 발생하며, 그 대부분은 페이지 코드만 보고는 발견할 수 없습니다.
- Geo-IP 리디렉션이 hreflang을 무시합니다. 서버는 IP에 따라 국가를 식별하고 사용자가 명시적으로 다른 언어 버전을 직접 링크로 열었더라도 강제로 로컬로 리디렉션합니다.
- 캐시하는 CDN이 오래된 버전을 제공합니다. Cloudflare 또는 다른 CDN은 요청 국가를 고려하지 않고 HTML을 캐시할 수 있으며, 모든 사용자는 지리적 위치에 관계없이 동일한 버전을 받습니다.
- 언어 및 지역 코드 불일치. 마크업에는
en이 명시되어 있지만en-GB와en-US가 별도로 필요하여 결국 영국과 미국의 사용자가 동일한 버전을 보게 됩니다. - 자기 참조 태그가 없습니다. 페이지가 hreflang 목록에서 자신을 참조하지 않으면 Google이 마크업을 유효한 것으로 인식하지 않을 수 있습니다.
- www와 비www, http와 https의 다양한 URL 변형. 태그는 하나의 프로토콜을 가리키지만 서버는 실제로 다른 프로토콜로 리디렉션하여 확인 체인을 깨뜨립니다.
이러한 모든 문제는 필요한 국가의 IP로 실제로 접속할 때만 나타납니다. 따라서 테스트하는 유일한 신뢰할 수 있는 방법은 각 목표 국가의 방문자를 에뮬레이션하고 웹사이트가 실제로 무엇을 제공하는지 확인하는 것입니다.
10개국에서 확인하기 위해 필요한 것
hreflang을 "실시간"으로 확인하려면 각 목표 국가에서 IP 주소를 물리적으로 또는 프로그래밍적으로 얻고, 해당 IP에 대해 서버가 어떤 버전의 웹사이트를 제공하는지 확인해야 합니다. 이를 위해 세 가지 작업 방법이 있습니다:
- 필요한 국가에 지리적으로 연결된 프록시 서버 — 가장 유연하고 확장 가능한 방법으로, 수동 확인 및 자동화 모두에 적합합니다.
- 안티탐지 브라우저 (Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) — 각 국가에 대해 개별 브라우저 프로필을 유지하고 시각적으로 비교할 수 있어 편리합니다. 쿠키와 캐시의 혼란을 피할 수 있습니다.
- 명령줄 도구 (curl, httpie)와 프록시 — 인터페이스를 로드하지 않고 HTTP 헤더, 리디렉션 및 서버 응답을 빠르게 확인할 수 있습니다.
10개국에서 hreflang을 테스트하는 데 가장 적합한 것은 주거용 프록시입니다. 이들은 특정 국가의 실제 사용자 IP를 사용하므로 geo-IP 서비스와 CDN이 이를 일반 웹사이트 방문자처럼 식별합니다. 데이터 센터 프록시는 때때로 지리 서비스의 블랙리스트에 올라가며, 서버가 이를 신고된 국가가 아닌 "데이터 센터, 국가 불명"으로 식별할 때 잘못된 결과를 제공할 수 있습니다.
안티탐지 브라우저에서 프록시 설정하기
프로그래밍 기술이 없는 마케팅 전문가에게 가장 실용적인 방법은 10개 목표 국가 각각에 대해 안티탐지 브라우저에서 개별 프로필을 생성하고 이를 통해 hreflang을 시각적으로 확인하는 것입니다.
Dolphin Anty 또는 AdsPower에서 단계별로 진행하면 다음과 같습니다:
- 새 브라우저 프로필을 생성하고 국가에 따라 이름을 지정합니다. 예를 들어 독일의 경우 "hreflang-DE"로 이름을 지정합니다.
- 프로필 설정에서 "프록시" 섹션을 열고
HTTP/SOCKS5유형을 선택합니다. - 독일에 지리적으로 연결된 프록시 데이터를 입력합니다: IP 또는 호스트, 포트, 로그인 및 비밀번호.
- 프로필을 저장하고 확인이 완료될 때까지 기다립니다. 안티탐지 브라우저가 특정 지리적 위치, 시간대 및 IP를 표시합니다.
- 프로필을 시작하고 직접 URL로 웹사이트를 열어 검색에서 이동하지 않습니다.
- 어떤 버전이 열렸는지 확인합니다: 주소 표시줄의 URL, 콘텐츠 언어, "페이지 소스 보기"를 통해 hreflang 값.
- 각 10개 목표 국가에 대해 반복하여 각 국가에 대해 개별 프로필을 생성합니다.
이러한 접근 방식은 프로필이 저장되므로 일주일 또는 한 달 후에 돌아와서 CDN 업데이트 또는 새로운 버전 배포 후 웹사이트의 동작이 변경되지 않았는지 확인할 수 있습니다. 이 작업에는 특정 도시에 연결된 주거용 프록시가 적합합니다. 이는 실제 방문자를 보다 정확하게 에뮬레이션할 수 있습니다.
명령줄 및 curl을 통한 확인
시각적 버전이 아니라 HTTP 헤더, 리디렉션 및 서버 응답을 빠르게 확인해야 할 경우 브라우저는 항상 전체 그림을 제공하지 않습니다. 일부 로직은 응답 헤더에 숨겨져 있습니다. 이를 위해 curl과 프록시를 사용하는 것이 편리합니다.
필요한 국가에 연결된 프록시를 통한 기본 확인:
curl -x http://login:password@proxy-host:port \
-I https://example.com/ \
-H "Accept-Language: de-DE"
-I 플래그는 페이지 본문 없이 응답 헤더만 표시합니다. 이를 통해 리디렉션 코드(301 또는 302), 서버가 리디렉션하는 위치를 나타내는 Location 헤더 및 Accept-Language가 캐싱에 고려되는지 여부를 나타내는 Vary 헤더를 빠르게 확인할 수 있습니다.
HTML을 추출하고 서버 응답에서 hreflang 태그를 찾으려면 -I를 제거하고 출력을 필터링합니다:
curl -x http://login:password@proxy-host:port \
-s https://example.com/ | grep -i hreflang이 요청은 서버가 반환한 HTML에서 hreflang 언급이 있는 모든 줄을 추출하며, 문서에서 예상되는 내용이 아닙니다. 요청이 어떤 국가의 프록시를 통해 전송되었는지에 따라 결과가 다르다면, 서버가 실제로 IP에 따라 콘텐츠를 변경하고 있다는 것을 의미하며, 단순히 정적 마크업에서 이를 선언하는 것이 아닙니다.
10개국 모두를 자동으로 확인하기 위해 프록시 목록을 반복하고 각 요청의 응답을 비교를 위해 별도의 파일에 저장하는 간단한 스크립트를 작성할 수 있습니다:
for country in de fr es it pl nl br mx jp kr; do
curl -x "http://login:password@${country}.proxy-host:port" \
-s https://example.com/ | grep -i hreflang > "result_${country}.txt"
done스크립트를 실행한 후 파일을 비교하면 됩니다. 만약 모든 곳에서 동일한 hreflang 태그 세트가 있다면, 서버가 지리적 위치에 따라 마크업을 변경하지 않는다는 것을 의미합니다. 이는 예상되는 동작일 수 있습니다(마크업이 정적이고 보편적임) 또는 문제일 수 있습니다(다른 지역에 대해 다른 정Canonicalization이 예상되었을 경우).
브라우저 및 DevTools를 통한 확인
시각적 확인 및 사용자 경험 분석을 위해 일반 브라우저에서 설정된 프록시와 열린 개발자 도구를 사용하는 것이 더 편리합니다. 이는 코드가 필요하지 않으며, 사용자가 보는 것을 직접 확인하고자 하는 마케팅 전문가에게 적합합니다.
작업 순서:
- 브라우저에서 확장 프로그램(예: FoxyProxy)을 통해 또는 시스템 네트워크 설정을 통해 프록시를 설정하고, 검사할 국가의 IP를 지정합니다.
- 웹사이트를 열고 즉시 F12를 눌러 DevTools를 열고 "Network" 탭으로 이동합니다.
- 페이지를 새로 고치고 문서의 첫 번째 요청을 찾습니다(일반적으로 사이트 도메인과 동일한 이름입니다).
- 오른쪽 패널에서 "Headers" 탭을 열고 리디렉션 및
Content-Language값이 있는지 확인합니다. - "Elements" 탭을 열고 Ctrl+F를 통해 페이지 소스에서 모든
hreflang항목을 찾습니다. - 주소 표시줄의 URL을 이 국가에 대해 예상했던 것과 비교합니다.
이 방법은 마크업의 기술적 정확성과 콘텐츠의 시각적 표시를 동시에 확인해야 할 때 특히 유용합니다. 예를 들어, 특정 국가에 맞게 통화, 날짜 형식 또는 현지화된 배너가 올바르게 표시되는지 확인할 수 있습니다.
지리적 타겟팅 테스트를 위한 프록시 선택하기
모든 유형의 프록시가 hreflang 확인에 동일하게 적합한 것은 아닙니다. 차이는 지리적 위치를 식별하는 서비스가 IP를 인식하는 방식과 프록시가 신고된 국가에 얼마나 안정적으로 연결되는지에 있습니다.
| 프록시 유형 | Geo-IP 정확도 | 사용 시기 |
|---|---|---|
| 주거용 프록시 | 높음, 실제 제공자의 IP | 특정 국가 및 도시의 실제 방문자를 정확하게 에뮬레이션 |
| 모바일 프록시 | 높음, 통신사 IP | 모바일 트래픽 및 AMP 버전의 동작 확인 |
| 데이터 센터 프록시 | 낮음, 때때로 데이터 센터로 표시됨 | 지리적 정확성이 중요하지 않은 curl을 통한 헤더 및 리디렉션의 빠른 확인 |
다국어 웹사이트 또는 Google Ads에서 국제 광고 캠페인을 시작하기 전 최종 수용 검사를 위해서는 주거용 또는 모바일 프록시를 사용하는 것이 좋습니다. 이들은 실제 사용자가 목표 국가에서 볼 수 있는 것과 가장 가까운 결과를 제공합니다.
10개국에 대한 hreflang 확인 체크리스트
대량 확인 시 놓치는 일이 없도록 다음 목록을 각 10개국에 대해 사용하세요:
- 정확히 이 국가의 IP를 가진 프록시가 연결되어 있으며, IP-checker를 통해 지리적 위치가 확인되었습니다.
- 직접 URL이 열려 있습니다(검색에서 이동하지 않고 referrer 없이).
- 모든 리디렉션 후 최종 URL이 확인되었으며, 예상된 로컬과 일치하는지 확인합니다.
- 페이지 코드에 자기 참조 hreflang이 포함되어 있습니다.
- hreflang 목록에 다른 9개 언어 버전이 누락 없이 모두 포함되어 있습니다.
- 언어 및 지역 코드가 ISO 표준에 부합합니다(예:
pt-BR, 단순히pt가 아닌 경우, 브라질과 포르투갈을 구분해야 합니다). - 컨텐츠가 브라우저 언어에 따라 달라지는 경우
Vary: Accept-Language헤더가 포함되어 있습니다. - 페이지의 콘텐츠(통화, 가격, 배너)가 신고된 지역에 맞습니다.
- 정Canonical 태그
rel="canonical"이 자신을 가리키고 있으며, 다른 로컬을 가리키지 않습니다. - 일주일 후 재확인 — CDN 캐시 업데이트 후 결과가 예상치 않게 변경되지 않았습니다.
테스트 중 자주 발생하는 오류
프록시를 통해 hreflang을 수동으로 확인할 때 마케팅 전문가들은 종종 테스트 결과를 왜곡하는 몇 가지 반복적인 오류를 범합니다.
첫째, 로그인된 계정이나 저장된 세션에서 검사를 수행하는 경우 서버는 개인화된 콘텐츠를 표시할 수 있으며, 새로운 방문자가 보는 것과는 다를 수 있습니다. 항상 시크릿 모드 또는 브라우저의 역사 없이 깨끗한 안티탐지 브라우저 프로필에서 확인하세요.
둘째, 프록시를 전환할 때 DNS 및 브라우저 캐시를 지우는 것을 잊어버리는 경우가 많습니다. 이로 인해 이전 버전의 페이지가 계속 표시되며, IP가 이미 변경되었음에도 불구하고 그렇습니다. 각 지리적 위치 변경 시 페이지를 강제로 새로 고치는(Ctrl+Shift+R) 방법을 사용하세요.
셋째, 내부 섹션 및 제품 카드 등을 무시하고 홈페이지만 테스트하는 경우가 많습니다. hreflang 마크업은 URL이 동적으로 생성되는 경우가 많기 때문에 주로 문제가 발생합니다.
넷째, 모든 10개국에 대해 동일한 프록시를 사용하고 Accept-Language 헤더만 변경하는 경우가 많습니다. 이는 실제 geo-IP와 동등하지 않으며, 서버가 IP에 따라 작동하는 경우 잘못된 긍정적 결과를 제공할 수 있습니다.
결론
페이지 코드에서 hreflang을 확인하는 것은 전체 그림의 절반만 제공합니다. 특정 국가의 사용자가 실제로 무엇을 받는지 이해하려면 해당 국가의 IP를 통해 방문을 에뮬레이션해야 합니다. 프록시, 안티탐지 브라우저 또는 간단한 curl 요청을 사용하여 이를 수행할 수 있습니다. 이러한 접근 방식은 정적 감사에서 찾을 수 없는 문제를 드러냅니다: geo-IP 리디렉션, 지역을 고려하지 않은 CDN 캐싱, 언어 코드 불일치 및 깨지는 자기 참조 태그.
다국어 웹사이트를 정기적으로 테스트하거나 10개 이상의 국가를 대상으로 광고 캠페인을 준비하는 경우 주거용 프록시를 사용해 보시기 바랍니다. 이들은 각 목표 국가의 실제 방문자를 가장 정확하게 에뮬레이션하여 hreflang을 확인할 수 있도록 하며, 검색 로봇이 아닌 실제 사용자가 보는 것처럼 확인할 수 있습니다.