대규모 hreflang 감사 방법

TL;DR — hreflang을 “대규모로” 감사한다는 것은 페이지를 하나씩 보는 대신 사이트 전체의 hreflang을 연결된 네트워크로 검사한다는 뜻입니다. 핵심은 hreflang이 서로 맞는 쌍으로 작동한다는 것입니다. A 페이지가 B를 가리키면 B도 A를 가리켜야 하며, 그렇지 않으면 Google은 그 쌍 전체를 제외합니다. 단일 페이지 검사로는 반환 링크 누락을 잡을 수 없으므로 모든 페이지를 읽고 누가 누구를 가리키는지 연결하는 크롤러가 필요합니다. 반환 링크 누락부터 고치세요. 모든 도구가 지적하는 x-default 누락은 나중에 해도 됩니다.

”한 번에 한 페이지” 방식이 통하지 않는 이유

독일어 페이지의 소스에서 깔끔한 hreflang 태그 블록을 보면 괜찮아 보입니다. 하지만 hreflang은 참조한 페이지들이 다시 가리켜야 작동합니다. 독일어 페이지가 완벽해도 해당 영어 페이지가 독일어를 역으로 참조하지 않았다면 관계가 깨집니다. 독일어 페이지 하나로는 보이지 않습니다. 영어, 프랑스어와 나머지 모든 버전을 열어 수동으로 대조해야 합니다. 페이지가 열 개라면 가능하지만 만 개라면 불가능합니다.

그래서 “대규모 hreflang 감사”는 별개의 역량입니다. 태그가 아니라 관계를 검사하기 시작하는 것입니다. 도구가 모든 페이지를 크롤링하고 모든 hreflang 주석을 기록한 뒤 핵심 질문을 던집니다. 이 그룹의 모든 페이지가 서로를 양방향으로 가리키는가?

실제로 필요한 것

세 가지입니다.

• 크롤러. Google은 hreflang 검증기를 제공하지 않으며 일부 문제를 지적하던 옛 Search Console 보고서는 2022년에 제거되었습니다. 따라서 Ahrefs Site Audit 이나 Screaming Frog 같은 제3자 크롤러로 모두 한곳에 모읍니다. 이 주장에 대한 근거 A complete audit needs to inspect HTML, HTTP Link headers, and XML sitemaps because Google supports hreflang in all three locations. 범위: Google Search-supported hreflang delivery methods. 신뢰도: 높음 · 검증일: 2026-07-14 Google: Localized versions
• 상호 참조 검사. 두 도구의 핵심 기능은 같습니다. 누가 누구를 가리키는지 지도를 만들고 단방향 링크를 표시합니다. 이것이 “반환 태그 누락”이며 실제로 중요한 오류입니다.
• 우선순위. 문제가 수백 개 나올 것입니다. 쌍을 깨뜨리는 반환 링크 누락부터, 다음으로 잘못된 국가/언어 코드를 수정하세요. x-default 누락은 가장 흔하지만 피해가 가장 적으므로 마지막에 두세요.

꼭 기억할 한 가지

hreflang을 사용하는 사이트 대부분에는 오류가 있습니다. 제가 2023년 Brighton SEO를 위해 374,756개 도메인을 연구 했을 때 hreflang을 사용하는 도메인의 67% 이상에 오류가 하나 이상 있었습니다. 첫 크롤링 결과가 빨갛게 나와도 당황하지 마세요. 정상입니다. 필요한 역량은 오류를 0개로 만드는 것이 아니라 실제로 트래픽 손실을 일으키는 것을 알아내 먼저 고치는 것입니다.

URL 구조, 지역 리디렉션, 콘텐츠 품질과 국가별 성과를 포함한 더 넓은 국제 감사는 국제 SEO 감사 를 보세요. hreflang의 개념과 구현법은 Hreflang 부터 시작하세요. 상호 태그 행렬, 클러스터 그래프 해설과 Screaming Frog 필터까지 대규모 방법론 전체를 보려면 고급 탭으로 전환하세요.

hreflang 수정 검증

상호 클러스터 재검사

실행할 테스트: 변경한 모든 클러스터를 다시 크롤링하고 실제 자기 참조 및 대체 버전 연결을 예상 로케일 행렬과 비교하세요. 예상 결과: 각 구성원은 자신과 의도한 모든 대체 버전을 참조하고 모든 연결에 역방향 연결이 있습니다. 실패 해석: 클러스터 전체를 갱신하지 않고 템플릿이나 페이지 하나만 수정했습니다. 관찰 시점: 배포 직후와 다음 생성 주기 이후. 롤백 조건: 변경한 클러스터에 우선 로케일의 비대칭 쌍이 여전히 있습니다.

대상 무결성

실행할 테스트: 리디렉션을 따라가지 않고 변경한 모든 hreflang 대상을 요청해 상태, robots 지시어와 canonical을 수집하세요. 예상 결과: 대상이 직접 200을 반환하며 색인 가능하고 의도한 대로 canonical을 지정합니다. 실패 해석: 로케일 지도가 오래되었거나 리디렉션·차단·통합된 URL을 가리킵니다. 관찰 시점: 릴리스 검증과 다음 전체 크롤링. 롤백 조건: 가치가 높은 클러스터가 오류 또는 예상 밖의 비canonical URL을 대상으로 합니다.

전달 방식의 일관성

실행할 테스트: 변경한 URL의 HTML, HTTP 헤더와 XML 사이트맵에서 발견한 주석을 비교하세요. 예상 결과: 의도한 방식만 존재하거나 생성된 모든 방식이 같은 클러스터를 선언합니다. 실패 해석: 여러 시스템이 hreflang을 담당하며 서로 달라졌습니다. 관찰 시점: 배포 이후와 다음 사이트맵 갱신 이후. 롤백 조건: 실제 서비스 URL에 모순된 방식이 남아 있습니다.

코드와 범위 검증

실행할 테스트: 변경한 모든 값을 지원되는 언어·지역 코드와 승인된 로케일 목록에 대조하세요. 예상 결과: 각 값은 유효한 언어로 시작하며 의도한 유효 지역만 추가합니다. 실패 해석: 국가를 언어로 사용했거나, 지원하지 않는 시장이 들어왔거나, 대소문자/형식 생성이 잘못되었습니다. 관찰 시점: CI 또는 배포 전 QA, 그리고 실제 서비스 크롤링에서 재확인. 롤백 조건: 잘못된 코드가 생성 템플릿이나 여러 클러스터에 영향을 줍니다.

TL;DR — 대규모 hreflang 감사는 태그가 아닌 그래프 검증입니다. 1단계: ccTLD/하위 도메인 구성에 맞춘 크롤러로 허용되는 세 위치(HTML head, HTTP Link 헤더, XML 사이트맵)의 모든 주석을 추출합니다. GSC로는 불가능합니다. International Targeting 보고서는 2022년 9월 22일 제거되었으며 그전에도 클러스터의 canonical 구성원만 보고했습니다. 2단계: 클러스터의 모든 URL × 모든 URL에 대해 A→B와 B→A 존재 여부를 표시하는 상호 태그 행렬을 만듭니다. 집중 검사는 제 returntag 클러스터 그래프/행렬로, 사이트 전체 크롤링은 Ahrefs와 Screaming Frog로 진행하세요. 3단계: 반환 태그 누락, 잘못된 코드, 비canonical 대상, 절대/상대 URL 혼용의 네 유형으로 분류합니다. 4단계: 빈도가 아니라 피해를 기준으로 우선순위를 정합니다. 쌍 전체를 깨뜨리는 반환 태그부터, 그다음 코드, 가장 흔하지만(56.3%) 피해가 적은 x-default는 마지막입니다. 5단계: 선언된 canonical이 아닌 색인된 URL을 기준으로 재검증합니다.

이 글은 hreflang을 여섯 감사 영역 중 하나로 다루는 제 국제 SEO 감사 의 hreflang 전용 보충 자료입니다. 여기서는 대규모 hreflang 전용 방법론을 한 단계 더 깊게 다룹니다. 개념, 세 구현 방식과 상호 참조 규칙은 Hreflang 허브를, 대체 경로 태그는 x-default 를 보세요.

핵심 관점 전환: 그래프 문제입니다

이렇게 생각을 바꾸면 대규모 감사를 다룰 수 있습니다. “이 페이지에 hreflang 태그가 있는가”를 검사하는 것이 아닙니다. “이 페이지의 클러스터에 있는 모든 페이지가 이 페이지를 다시 가리키며, 클러스터의 모든 URL이 200인 canonical·색인 가능 페이지로 연결되는가”를 검사합니다.

그 근거는 Google의 문서입니다.

“If page X links to page Y, page Y must link back to page X. If this is not the case for all pages that use hreflang annotations, those annotations may be ignored or not interpreted correctly.” (번역) 「X 페이지가 Y 페이지에 링크하면 Y 페이지도 X 페이지로 돌아오는 링크를 제공해야 합니다. hreflang 주석을 사용하는 모든 페이지에 이 조건이 충족되지 않으면 해당 주석은 무시되거나 올바르게 해석되지 않을 수 있습니다.」

주의해서 읽으세요. 반환 링크 하나가 없으면 관련 주석이 무시되거나 잘못 해석될 수 있습니다. 단일 페이지 보기는 구조적으로 hreflang을 감사할 수 없습니다. 실패는 페이지 하나가 아니라 페이지 간 관계에 있기 때문입니다. 모든 클러스터 구성원을 기록하고 대조하는 크롤링이 필요합니다.

범위도 중요합니다. 무시되는 것은 깨진 쌍의 주석이지 더 큰 클러스터의 모든 관계가 자동으로 무시되는 것은 아닙니다. 다섯 페이지 클러스터에서 반환 링크 하나가 없더라도 다른 완전한 쌍들은 대체로 정상 처리됩니다. 아래 제 returntag 스크린샷도 이를 보여 줍니다. 아홉 상호 쌍은 유지되고 반환 링크 하나가 표시됩니다. 연결 하나가 깨지면 클러스터 전체가 사라진다고 가정하지 마세요. 도구가 그렇게 판단하려면 모든 쌍을 검사해야 하므로 여러분도 모든 쌍을 확인하세요.

사이트가 커질수록 더 어려워집니다. Google도 대형 사이트에 오류가 생기는 이유를 이렇게 설명합니다. Search Off the Record 에서 Gary Illyes는 각기 다른 URL 구조의 속성이 많아지고 속성마다 패턴을 달리해야 할 때 오류가 생긴다고 했습니다. Lizzi Sassman은 URL을 현지화하고 오타까지 생기면 동기화하기가 더 어렵다고 덧붙였습니다. 각기 조금씩 다른 게시 규칙을 가진 여러 ccTLD는 엔터프라이즈 구성의 전형입니다. 따라서 좋은 감사는 운영상 오류가 모이는 속성/도메인 그룹별로 결과를 나눕니다.

1단계 — 사이트 전체의 모든 hreflang 주석 추출

hreflang이 존재하는 세 위치

Google은 세 위치의 hreflang을 동등하게 인정하며 모두 검사해야 합니다.

1. HTML <link> 태그를 <head>에 사용 — 일반적인 방식.
2. HTTP Link: 응답 헤더 — PDF 같은 비HTML 파일에 사용.
3. XML 사이트맵의 xhtml:link 항목 — 모든 페이지의 템플릿에 넣는 대신 한 파일에 주석을 모으므로 대규모에서 흔히 사용.

HTML head만 읽는 크롤러는 헤더나 사이트맵의 대체 버전을 아무 경고 없이 놓칩니다. 깨졌다고 표시하는 것이 아니라 보지 못합니다. 사이트맵에 전체 hreflang 묶음이 있어도 해당 페이지에는 없다고 생각하게 되므로 더 나쁩니다. 수치 하나라도 믿기 전에 세 위치를 모두 읽도록 설정하세요.

사이트 구조에 맞는 크롤러 설정

• Screaming Frog: Configuration > Spider > Crawl Hreflang(설정에서 hreflang 크롤링)을 켜세요. 해당 대상을 지정하면 사이트맵과 헤더의 hreflang도 수집합니다. ccTLD/하위 도메인이 서로 참조한다면 Config > CDNs(설정의 CDNs)에 형제 도메인을 추가하세요. 그렇지 않으면 교차 도메인 hreflang 링크는 오류로 표시되는 것이 아니라 검증되지 않습니다. 엔터프라이즈 사이트는 ccTLD를 사용하는 경우가 많고 바로 이 추가 단계가 필요하므로 대규모에서 가장 흔한 사각지대입니다.
• Ahrefs Site Audit: 같은 이유로 형제 도메인을 프로젝트 범위에 포함하세요. 개별 클러스터 그래프를 보기 전에 Page Explorer 로 hreflang 문제 유형별 페이지를 대규모로 필터링하세요.

GSC가 대신해 줄 수 없는 이유

두 가지 이유가 있으며 대부분은 두 번째를 놓칩니다.

1. 보고서가 없어졌습니다. 일부 hreflang 문제를 표시하던 GSC International Targeting 보고서는 지원 중단 후 제거되었습니다. 발표는 2022년 8월, 제거는 2022년 9월 22일 이후였습니다. 직접적인 대체 보고서는 없습니다.
2. 존재할 때도 canonical만 보여 줬습니다. Search Off the Record에서 Illyes는 Search Console이 canonical만 보고한다고 설명했습니다. 유사 언어 hreflang 클러스터 대부분에서 대체 버전은 canonical이 아니므로 비canonical 구성원에서 무슨 일이 일어나는지 사실상 볼 수 없었습니다. Google이 대체 버전 세부 정보를 저장하지 않고 중복 클러스터에 넣기 때문입니다. 이는 GSC가 완전한 hreflang 감사 도구가 될 수 없었던 구조적 이유이지 단지 “보고서가 제거됐다”는 문제가 아닙니다. 크롤러를 우선해야 하는 직접적인 근거입니다.

Google은 검증기도 제공하지 않습니다. 같은 팟캐스트에서 Illyes는 Google이 hreflang 검증기를 제공한 적이 없고, 거의 사용되지 않던 보고 기능을 제거했으며, 지금은 Aleyda Solis의 도구, Bill Hunt의 hreflang 검사기와 Merkle 도구 같은 외부 도구를 안내한다고 했습니다. GSC가 하지 못하는 작업을 제3자 크롤러에 맡겨도 된다는 뜻이지 보증은 아닙니다. Google 문서는 제3자 hreflang 디버깅 도구를 유지 관리하거나 검사하지 않는다고 명시합니다. 제 도구를 포함한 모든 도구의 결과를 공식 판정이 아니라 해석이 필요한 진단 근거로 보세요. 중요한 결과는 파싱된 요약에서 멈추지 말고 HTTP 응답, 사이트맵 XML 또는 렌더링된 HTML 같은 원시 산출물과 대조하세요.

2단계 — 상호 태그 행렬 만들기

추출한 내용 정규화

행렬을 만들기 전에 모두 일관된 형태로 정리하세요. 선언된 hreflang 관계마다 출발 URL, 대상 URL, 로케일 값과 원본 방식(HTML head, HTTP 헤더 또는 사이트맵)을 기록하세요. 특히 대상의 상태 코드, 리디렉션 체인, 색인 가능성, canonical 대상, 원시 HTML에서 발견했는지 렌더링된 DOM에서 발견했는지도 기록해야 합니다. 크롤러마다 내보내는 형식은 다릅니다. 이 맥락을 붙인 방향성 URL 간 연결로 정규화해야 행렬과 3단계의 모든 분류가 서로 떨어진 행 더미가 아니라 신뢰할 수 있는 자료가 됩니다.

행렬의 의미

개념적으로 각 클러스터의 모든 URL을 행과 열로 나열하고, 각 셀에 행 URL에서 열 URL로 hreflang 링크가 있는지를 예/아니요로 표시합니다. 올바른 클러스터는 대칭입니다. A→B가 있으면 B→A도 있습니다. 한 방향만 존재하는 모든 비대칭 셀은 반환 태그 누락입니다.

대규모에서 이 표를 손으로 만드는 것은 아닙니다. 도구가 만들어 줍니다. 하지만 행렬을 머릿속에 그릴 수 있어야 결과를 제대로 읽을 수 있습니다. 제 returntag는 행렬을 그래프로 그리면서 실제 셀도 보여 줍니다. Screaming Frog의 “Missing Return Links”(반환 링크 누락) 필터는 비대칭 셀을 목록으로 만들고 Ahrefs Site Audit은 또 다른 대규모 클러스터 보기를 제공합니다. 관계 검사는 같고 표현과 크롤링 범위가 다릅니다.

그래프로 읽기: 제 returntag 클러스터 검증기

집중적인 클러스터 검사에는 제 무료 returntag 도구가 선언된 로케일 관계를 그래프와 상호 행렬로 표시합니다. 각 로케일은 노드, 선언된 hreflang 주석은 연결이며, 문제 목록은 역방향 링크가 없는 정확한 URL을 알려 줍니다. 아래 스크린샷은 사이트맵 전용 실행입니다. 사이트맵의 선언만 읽으며 페이지 head 태그나 HTTP Link 헤더는 의도적으로 가져오지 않습니다. 한 페이지의 클러스터에서 세 출처 전체를 보려면 Page URL 모드를 사용하세요.

읽는 방법:

• 정상 클러스터는 모든 노드가 서로 양방향으로 연결된 완전 연결망입니다.
• 단방향 연결은 비대칭 셀입니다. X가 Y를 가리키지만 Y는 X를 가리키지 않습니다. 반환 태그 오류를 글이 아닌 그림으로 보는 것입니다.
• 고립 노드 — 클러스터에 나타나지만 클러스터로 돌아가는 링크가 없는 URL은 연결되지 않은 hreflang URL입니다.

실무적 이점은 빠른 우선순위 판단과 이해관계자 소통입니다. 개발자에게 추상적인 표의 행을 주는 대신 단방향 관계와 정확한 반환 태그 누락을 함께 보여 줍니다. 클러스터가 수백·수천 개라면 완전한 크롤링 범위를 위해 Ahrefs Site Audit이나 Screaming Frog를 작업 흐름에 유지하세요. returntag는 특정 클러스터를 빠르게 검사하고 설명하는 방법입니다.

스프레드시트로 읽기: Screaming Frog 필터

Screaming Frog에서는 크롤링 후 Crawl Analysis(크롤링 분석)를 실행해 반환 링크 데이터를 채우면 행렬이 필터로 나타납니다. 4단계 우선순위와 맞으므로 대략 다음 순서로 처리하세요.

• Missing Return Links(반환 링크 누락) — 비대칭 셀로, 최우선 결과입니다.
• Inconsistent Language & Region Return Links(언어·지역 반환 링크 불일치) — 반환 링크는 있지만 바깥쪽 연결과 다른 코드를 사용합니다. A가 B를 fr-FR라고 하고 B는 실제 en-US인 A를 en-GB라고 하는 경우입니다. 더 미묘하게 쌍을 깨뜨립니다.
• Non-Canonical Return Links(비canonical 반환 링크) — 다른 곳으로 canonical이 지정된 URL을 가리키므로 태그가 있어도 신호 연결이 끊깁니다.
• Noindex Return Links(noindex 반환 링크) — 반환 대상이 noindex라 주석을 전달할 수 없습니다.
• Non-200 Hreflang URLs(200이 아닌 hreflang URL) — 대상이 리디렉션이나 오류 페이지입니다.
• Unlinked Hreflang URLs(연결되지 않은 hreflang URL)와 Incorrect Language & Region Codes(잘못된 언어·지역 코드) — 고립 노드와 코드 검증 오류입니다.

Reports > Hreflang(보고서의 Hreflang)에서 전체를 내보내세요. 필터별 전체 개요는 Screaming Frog hreflang 튜토리얼 이 훌륭하므로 설정 단계를 여기서 다시 적지는 않겠습니다.

3단계 — 결과를 네 가지 오류 유형으로 분류

크롤링 결과에는 잡음이 많습니다. 374,756개 도메인 연구 에서 반복되는 네 유형 중 하나로 모든 결과를 분류하세요. 여기서는 우선순위 논리를 뒷받침하는 수치 두 개만 가져옵니다. 오류 아홉 유형의 전체 표는 이미 국제 SEO 감사 에 있으므로 다시 붙일 필요가 없습니다.

1. 반환 태그 누락: 쌍을 깨뜨리는 오류

행렬의 비대칭 셀입니다. hreflang 사용 도메인의 **15.3%**에 존재합니다. 연구 글에서 저는 “As I mentioned, hreflang tags work in pairs. If both pages don’t reference each other, they can’t establish the connection and swap properly in the search results.” (번역) 「말씀드렸듯 hreflang 태그는 쌍으로 작동합니다. 두 페이지가 서로 참조하지 않으면 연결을 성립시키고 검색 결과에서 제대로 교체할 수 없습니다.」라고 했습니다. Google 문서에 따르면 쌍 전체의 신호를 무효화하므로 가장 흔하지 않아도 최우선입니다.

2. 잘못된 언어/지역 코드: 일부는 조용히 허용됩니다

언어에는 ISO 639-1, 지역에는 ISO 3166-1 alpha-2를 사용하세요. 흔한 오류는 일본어 ja 대신 jp, ja를 js로 잘못 쓴 경우, gb 대신 gbr 같은 세 글자 코드, “라틴 아메리카”의 뜻으로 la(라오스)를 잘못 사용한 경우입니다.

감사에서 한 가지 더 구분해야 합니다. 기본 언어 태그 명세인 BCP 47은 Google hreflang 구현이 실제로 처리하는 것보다 훨씬 넓은 값을 허용합니다. 여기에는 Google 문서가 인식되는 값이라고 확인하지 않는 문자 체계 하위 태그 등 BCP 47상 적법한 구성도 있습니다. BCP 47 형식이 완벽해도 Google hreflang 지침에서 지원한다고 명시한 값이 아닐 수 있습니다. 일반 BCP 47 형식 유효성이 아니라 Google 문서의 언어/지역/x-default 규칙에 맞춰 검증하세요. 문법적으로 올바른 태그가 Google에는 기능적으로 보이지 않을 수 있습니다.

단순한 우선순위 판단과 맞지 않는 미묘한 점이 있습니다. Google은 일부 오류를 조용히 수정하지만 다른 것은 그렇지 않습니다. 문서에 따르면 다른 용도로 예약된 코드를 사용하면 “Google Search ignores that part of the annotation (for example, using EU, UN, or UK in hreflang annotations doesn’t have an effect on Google Search).” (번역) 「Google 검색은 주석의 해당 부분을 무시합니다. 예를 들어 hreflang에 EU, UN 또는 UK를 사용해도 Google 검색에는 영향이 없습니다.」 따라서 UK는 사실상 제외되며 필요한 값은 GB입니다. 그러나 주석의 나머지 부분까지 없애지는 않습니다. 반면 ja 대신 jp처럼 단순히 틀린 코드는 그 쌍을 깨뜨립니다. “기술적으로 틀리지만 Google이 처리하는 것”과 “틀려서 실제 쌍이 깨지는 것”은 긴급도가 다르므로 감사에서 구분해야 합니다.

3. hreflang의 비canonical URL: 보이지 않는 오류

태그 내보내기에서는 멀쩡해 보이지만 작동하지 않는 유형입니다. 제가 Pubcon 2019 에서 강조한 구분은 hreflang은 canonical이 아니라 색인된 버전에 관한 것이라는 점입니다. hreflang이 실제 색인된 버전과 달리 canonical로 다른 곳을 지정한 URL을 가리키면 태그 자체는 “유효”해도 신호 연결이 끊깁니다. 크롤링 내보내기와 색인 상태를 대조해야만 드러납니다. 많은 튜토리얼은 hreflang을 색인 파이프라인의 일부가 아니라 독립적인 태그 검사로 취급해 이를 빠뜨립니다. 검증 방법은 5단계에서 더 설명합니다.

같은 언어로 정렬되어 있는지도 확인할 가치가 있습니다. 거의 중복인 여러 URL이 로케일의 canonical 후보가 될 수 있을 때 Google의 canonicalization 지침은 같은 언어 또는 최선의 대체 URL을 선호하며, 완전한 상호 hreflang 클러스터에 속한 페이지를 그렇지 않은 페이지보다 어느 정도 선호합니다. 따라서 hreflang 대상이 다른 언어의 중복 페이지로 벗어나지 않고 같은 언어의 canonical 후보를 가리키게 해야 합니다. 하지만 크롤러나 검사기가 이를 확실히 입증할 수는 없습니다. canonical 태그, hreflang 연결, 클러스터 구성 같은 설정된 신호는 보여 줘도 Google의 실제 최종 선택은 보여 주지 못합니다. 크롤링 결과를 확인 증거가 아닌 진단 근거로 보세요.

4. 절대/상대 URL 혼용: 템플릿 오류

Google은 명확히 말합니다. “Alternate URLs must be fully-qualified, including the transport method (http/https), so: https://example.com/foo, not //example.com/foo or /foo.” (번역) 「대체 URL은 전송 방식(http/https)을 포함한 완전한 형식이어야 합니다. 즉 https://example.com/foo이며 //example.com/foo나 /foo는 아닙니다.」 대규모에서는 hreflang 블록을 불완전한 URL 패턴으로 생성해 수천 URL에 한꺼번에 영향을 주는 템플릿 오류인 경우가 대부분이며 일회성 오타인 경우는 거의 없습니다. 크롤러가 시스템적 문제로 표시하는 이유입니다. 하나를 발견하면 대개 템플릿 전체에 해당하는 문제를 찾은 것입니다.

4단계 — 반환 태그부터, 다음 코드, x-default는 마지막

이 글에서 가장 중요한 생각은 오류의 심각도가 빈도에 비례하지 않는다는 것입니다. 도구가 반환한 행 수가 아닌 피해로 정렬하세요.

어디에나 있는 x-default를 마지막에 두는 이유는 이렇습니다. 제 374,756개 도메인 연구에서 56.3%, Dan Taylor의 독립적인 SALT.agency 18,786개 도메인 연구 에서 **47.95%**로 모든 연구의 가장 흔한 결과입니다. 규모가 크게 다른 두 연구의 결론은 대부분의 사이트에 없다는 것입니다. 하지만 저는 연구에서 “Setting an x-default is not required. But it is recommended if you need a fallback page for users whose language settings don’t match any of your localized versions.” (번역) 「x-default 설정은 필수가 아닙니다. 다만 사용자의 언어 설정이 현지화한 어느 버전과도 맞지 않을 때의 대체 페이지가 필요하면 권장됩니다.」라고 썼습니다. Google 팀도 색인에 결정적인 신호가 아닌 UX 대체 경로로 취급합니다. Search Off the Record에서 Illyes는 사용자 언어와 맞는 버전이 없을 때의 대체 페이지를 주석으로 표시하는 것이며 전용 선택기가 아닌 다른 언어 페이지여도 된다고 했습니다. 고치되 실제 클러스터를 깨뜨리는 것 뒤에 고치세요.

자기 참조가 3등급인 이유도 같습니다. Google의 hreflang 구현에 참여한 Illyes도 자기 참조가 왜 필수인지 완전히 기억하지 못하며 없어도 클러스터가 작동할 것이라고 상당히 확신한다고 공개적으로 말했습니다. 같은 블록을 어디에나 복사·붙여넣기해 설정을 쉽게 만드는 용도로 주로 설명했습니다. 기능적 필수 조건이 아니라 구현 정비입니다.

hreflang뿐 아니라 국제 감사 여섯 영역 전체의 영향 × 노력 매트릭스는 여기서 다시 만들지 않고 국제 SEO 감사 의 프레임워크 탭을 사용하세요.

5단계 — 크롤링이 아닌 색인된 URL을 기준으로 재검증

크롤링은 태그를 검증합니다. 태그가 가리키는 URL이 Google이 실제로 색인한 URL인지는 검증하지 못합니다. hreflang은 색인된 버전을 따르므로(3단계 유형 3), 다른 곳으로 canonical이 지정되거나 리디렉션되거나 후속 대상이 noindex인 URL을 가리키는 태그는 일괄 수정 결과가 “정상”이어도 신호가 끊깁니다.

수정 배포 후 Search Console의 URL 검사로 가치가 가장 높은 클러스터를 표본 점검하세요. Google이 색인되었다고 보고하는 URL과 hreflang 참조 URL이 같은지 확인합니다. 단순 태그 내보내기로 보이지 않는 canonical 체인의 변화를 잡는 단계입니다. 모든 URL이 아니라 크롤링이 끝났다고 한 뒤 시장별 매출 기여 페이지를 검사합니다.

Bing에 관한 짧은 참고

Bing Webmaster Tools가 이 모든 것을 검증해 줄 것이라 기대하지 마세요. Bing은 hreflang을 Google보다 훨씬 약한 신호로 취급하고 2020년에 Geo Targeting 기능을 제거했으며 대신 Content-Language 헤더에 의존합니다. 대규모 hreflang 감사는 기본적으로 Google을 위한 작업입니다. Bing용 Content-Language는 별도로 확인하세요. 국제 SEO 감사 에서 다룹니다.

AI 요약

고급 버전을 압축한 내용입니다.

• 태그가 아닌 그래프 문제입니다. 페이지 하나에 태그가 있는지가 아니라 클러스터의 모든 페이지가 서로를 다시 가리키는지 검사합니다. Google에 따르면 “If page X links to page Y, page Y must link back to page X,” (번역) 「X 페이지가 Y 페이지에 링크하면 Y 페이지도 X 페이지로 돌아오는 링크를 제공해야 합니다.」 그렇지 않으면 주석이 “may be ignored” (번역) 「무시될 수 있습니다」. 반환 링크 하나가 없으면 클러스터 전체가 무효화될 수 있습니다.
• 1단계 — 모두 추출. hreflang은 HTML head, HTTP Link 헤더와 XML 사이트맵에 있으므로 크롤러가 세 위치를 모두 읽어야 합니다. 형제 ccTLD/하위 도메인을 설정하세요. Screaming Frog는 Config > CDNs, Ahrefs는 프로젝트 범위입니다. 그렇지 않으면 교차 도메인 링크가 검증되지 않습니다. GSC로는 불가능합니다. International Targeting 보고서는 2022년 9월 22일 제거되었고 그전에도 클러스터의 canonical 구성원만 보고했습니다.
• 2단계 — 상호 태그 행렬. 클러스터의 모든 URL × 모든 URL이며 비대칭 셀은 반환 태그 누락입니다. 특정 클러스터는 returntag 그래프와 행렬로, 사이트 전체는 Ahrefs Site Audit과 Screaming Frog로 살펴보세요.
• 3단계 — 오류 네 유형: 반환 태그 누락, 잘못된 코드(예약된 UK는 무시하는 식으로 조용히 처리하지만 ja 대신 jp 같은 것은 처리하지 않음), 비canonical 대상(hreflang은 색인된 URL을 따름), 절대/상대 URL 혼용(대규모 템플릿 오류).
• 4단계 — 빈도가 아닌 피해로 우선순위. 쌍 전체를 깨뜨리는 반환 태그부터, 다음은 코드/깨진 대상, x-default는 마지막입니다. 제 374,756개 도메인 연구에서 56.3%, SALT.agency 연구에서 47.95%로 가장 흔하지만 피해가 가장 적고 “필수가 아닙니다”.
• 5단계 — 색인된 URL 재검증. 수정 후 URL 검사로 확인하세요. 크롤링이 검증하는 것은 태그이지 색인 상태의 변화가 아닙니다.
• 규모 맥락: hreflang 사용 도메인의 67% 이상에 오류가 하나 이상 있습니다. 제 Brighton SEO 2023 연구는 374,756개 도메인을 다뤘습니다. Bing은 짧게만 주의하면 됩니다. hreflang이 아닌 Content-Language를 확인하세요.

공식 문서

hreflang 감사를 위한 1차 출처 참조 자료입니다.

Google

• Tell Google about localized versions of your page — 페이지 현지화 버전을 Google에 알리는 hreflang 참조 문서입니다. 상호 반환 태그 요구 사항, 완전한 URL 규칙, 예약 코드 처리와 동등한 세 구현 방식(HTML link 태그, HTTP Link 헤더, XML 사이트맵)을 다룹니다.
• The International Targeting report is deprecated — Search Console Help — International Targeting 보고서 지원 중단에 관한 Search Console 도움말입니다. 일부 hreflang 문제를 표시하던 보고서는 2022년 9월 22일 이후 제거되었습니다.
• Managing Multi-Regional and Multilingual Sites — 다지역·다국어 사이트 관리 문서로, 다중 속성 구성이 hreflang 오류를 가장 많이 만드는 이유의 URL 구조 맥락을 제공합니다.
• How to specify a canonical URL with rel=canonical and other methods — rel=canonical 등으로 canonical URL을 지정하는 방법입니다. 3단계의 비canonical hreflang 검사 근거인 같은 언어 canonical 선호 지침입니다.

Bing / Microsoft

• Bing Webmaster Tools help — Bing 웹마스터 도구 도움말입니다. Bing에는 hreflang 검증 작업 흐름이 없고 대신 Content-Language 헤더에 비중을 두며 2020년에 Geo Targeting을 제거했습니다.

출처의 인용문

감사 방법론의 근거가 되는 공개 발언입니다.

Google — 상호 참조 요구 사항: 감사 전체의 뼈대

• “If page X links to page Y, page Y must link back to page X. If this is not the case for all pages that use hreflang annotations, those annotations may be ignored or not interpreted correctly.” (번역) 「X 페이지가 Y 페이지에 링크하면 Y 페이지도 X 페이지로 돌아오는 링크를 제공해야 합니다. hreflang 주석을 사용하는 모든 페이지에 이 조건이 충족되지 않으면 해당 주석은 무시되거나 올바르게 해석되지 않을 수 있습니다.」 — Google Search Central 문서. 인용 위치로 이동

Google — 완전한 URL: 절대/상대 URL 혼용의 근본 원인

• “Alternate URLs must be fully-qualified, including the transport method (http/https), so: https://example.com/foo, not //example.com/foo or /foo.” (번역) 「대체 URL은 전송 방식(http/https)을 포함한 완전한 형식이어야 합니다. 즉 https://example.com/foo이며 //example.com/foo나 /foo는 아닙니다.」 — Google Search Central 문서. 인용 위치로 이동

Google — 예약 코드는 조용히 제외되며 페이지를 깨뜨리지는 않습니다

• “If you use codes that are listed as reserved for something else, Google Search ignores that part of the annotation (for example, using EU, UN, or UK in hreflang annotations doesn’t have an effect on Google Search).” (번역) 「다른 용도로 예약된 코드를 사용하면 Google 검색은 주석의 해당 부분을 무시합니다. 예를 들어 hreflang에 EU, UN 또는 UK를 사용해도 Google 검색에는 영향이 없습니다.」 — Google Search Central 문서. 인용 위치로 이동

Patrick Stox — 쌍이 중요한 이유: 374,756개 도메인 연구

• “As I mentioned, hreflang tags work in pairs. If both pages don’t reference each other, they can’t establish the connection and swap properly in the search results.” (번역) 「말씀드렸듯 hreflang 태그는 쌍으로 작동합니다. 두 페이지가 서로 참조하지 않으면 연결을 성립시키고 검색 결과에서 제대로 교체할 수 없습니다.」 — Over 67% of Domains Using Hreflang Have Issues, Ahrefs (hreflang 사용 도메인의 67% 이상에 문제가 있음)

• “Setting an x-default is not required. But it is recommended if you need a fallback page for users whose language settings don’t match any of your localized versions.” (번역) 「x-default 설정은 필수가 아닙니다. 다만 사용자의 언어 설정이 현지화한 어느 버전과도 맞지 않을 때의 대체 페이지가 필요하면 권장됩니다.」 — Over 67% of Domains Using Hreflang Have Issues, Ahrefs (hreflang 사용 도메인의 67% 이상에 문제가 있음)

Gary Illyes, Google — GSC로 hreflang을 감사할 수 없는 이유와 검증기가 없는 이유

• Search Off the Record에서 Illyes는 Search Console이 canonical만 보고하므로 대체 버전이 canonical이 아닌 많은 hreflang 클러스터에서는 비canonical 구성원을 사실상 볼 수 없다고 설명했습니다. Google이 대체 버전 세부 정보를 저장하지 않고 중복 클러스터에 넣기 때문입니다. 또 Google은 hreflang 검증기를 제공한 적이 없고 사용이 적던 보고 기능을 제거했으며 지금은 외부 도구를 안내한다고 했습니다. 대본을 풀어쓴 내용입니다. 그대로 인용하기 전에 방송 페이지 와 표현을 대조하세요.

어떤 문제를 먼저 고쳐야 하나요?

크롤링을 마치고 빨간 결과로 가득한 화면을 보고 있다면 각 결과를 다음 순서로 판단하세요.

1. 반환 링크가 없거나 코드가 불일치하나요(비대칭 셀)? → 예 → 1등급. 지금 수정하세요. Google 문서에 따르면 쌍 전체가 깨집니다. 다른 모든 작업보다 먼저입니다. → 아니요 → 계속 진행.

2. hreflang이 200이 아니거나 리디렉션·noindex·비canonical URL을 가리키나요? → 예 → 2등급. 다음으로 수정하세요. 대상이 주석을 전달할 수 없습니다. 비canonical은 canonical 태그만 보지 말고 URL 검사로 색인된 URL과 대조하세요. → 아니요 → 계속 진행.

3. 언어/지역 코드가 잘못되었나요? → Google이 조용히 무시하는 예약 코드(UK, EU, UN)인가요? → 예 → 긴급도 낮음. 해당 부분만 제외하므로 긴급 대응이 아니라 정확성을 위해 수정하세요. → ja 대신 jp, js 오타, 세 글자 gbr처럼 일치를 깨뜨리는 실제로 틀린 코드인가요? → 예 → 2등급. 다음으로 수정하세요. 관계가 깨집니다.

4. 절대/상대 URL 혼용(//example.com/… 또는 /…)인가요? → 예 → 3등급이지만 템플릿을 확인하세요. 거의 항상 사이트 전체 템플릿 오류입니다. 한 사례가 수천 건을 뜻합니다. 템플릿에서 수정하고 나머지는 일괄 처리하세요.

5. 자기 참조 또는 x-default 누락인가요? → 예 → 4등급. 마지막입니다. 실제 정비 문제지만 클러스터를 깨뜨리지는 않습니다. x-default는 “권장이지 필수는 아님”이며 자기 참조는 복사·붙여넣기의 편의를 위한 것입니다. 마지막 일괄 정비에서 처리하세요.

의사결정의 기본 규칙: 도구가 반환한 행 수가 아니라 피해로 정렬하세요. 가장 흔한 오류인 x-default의 피해가 가장 적습니다.

SOP: 정기 hreflang 감사

개발자가 템플릿 변경을 배포할 때마다 hreflang은 조용히 깨지므로 정기적으로 실행하세요. 활발한 국제 사이트는 매월, 또는 현지화 템플릿을 건드린 모든 릴리스 이후에 실행합니다.

준비

1. hreflang 네트워크의 모든 속성, 즉 ccTLD·하위 도메인·하위 폴더가 크롤러 범위에 있는지 확인하세요. Screaming Frog에서는 Config > CDNs에 형제 도메인을 추가하고 Ahrefs Site Audit에서는 프로젝트 범위를 확인하세요.
2. HTML head, HTTP Link 헤더와 XML 사이트맵의 세 위치 모두를 읽는지 확인하세요. 사이트맵 기반 hreflang을 사용한다고 알고 있는 페이지로 검증합니다.

크롤링 3. hreflang 추출을 켜세요. Screaming Frog에서는 Configuration > Spider > Crawl Hreflang입니다. 크롤링을 실행합니다. 4. 반환 링크 필터를 채우기 위해 크롤링 후 분석을 실행하세요. Screaming Frog에서는 Crawl Analysis입니다. Ahrefs에서는 Site Audit이 완료될 때까지 기다린 뒤 hreflang 문제 묶음을 여세요.

우선순위 판단: 이 순서로 5. 1등급 — Missing Return Links(반환 링크 누락) + Inconsistent Return-Link Codes(반환 링크 코드 불일치). 먼저 내보내세요. 가장 피해가 큰 클러스터를 returntag 그래프/행렬로 열어 깨진 연결을 설명하고, 사이트 전체 검사 범위의 근거로 크롤러 내보내기를 유지하세요. 6. 2등급 — 비canonical/깨진/noindex 대상과 실제로 틀린 코드. 7. 3등급 — 절대/상대 URL 혼용(템플릿에서 수정), 자기 참조 누락. 8. 4등급 — x-default 누락. 마지막입니다.

분류 9. 오류 유형뿐 아니라 속성/도메인별로 결과를 묶으세요. 속성마다 URL 패턴이 달라지는 곳에 오류가 모입니다. 어느 팀의 템플릿을 수정해야 할지 알 수 있습니다.

검증 10. 수정 배포 후 다시 크롤링하세요. 이후 시장별 매출 기여 페이지를 URL 검사로 표본 점검해 hreflang이 canonical로 다른 곳을 지정한 URL이 아닌 색인된 URL을 가리키는지 확인하세요. 11. 주기마다 등급별 오류 수를 기록해 시간에 따른 변화를 관찰하세요.

hreflang 감사의 오해와 실수

잘못된 것을 감사하게 만드는 구체적인 오해입니다. 각각 틀린 이유와 대신 할 일을 설명합니다.

1. “hreflang이 깨지면 사이트가 불이익을 받으므로 모든 오류가 긴급하다.”

• 틀린 이유: Google은 깨지거나 비대칭인 hreflang을 무시할 뿐 페널티를 주지 않습니다. Gary Illyes는 잘못 구현해도 사이트에 해를 주지 않고 단순히 무시한다고 직접 말했습니다. Search Engine Roundtable 이 보도했고 Search Engine Journal 도 뒷받침했습니다. 손실은 순위 페널티가 아니라 잘못된 언어 페이지의 노출이나 시장 간 잠식 같은 기회 상실입니다.
• 대신 할 일: 존재하지 않는 페널티에 대한 공포가 아니라 클러스터별 트래픽·매출의 상실 기회로 우선순위를 정하세요.

2. “x-default 누락이 가장 흔하므로 먼저 수정해야 한다.”

• 틀린 이유: 빈도와 심각도는 다른 축입니다. x-default는 제 연구의 56.3%, SALT.agency의 47.95%로 가장 흔하지만 “권장이지 필수는 아님”이며 클러스터의 결정적 신호가 아닌 UX 대체 경로입니다.
• 대신 할 일: x-default는 마지막에 두세요. 쌍 전체를 깨뜨리는 반환 태그부터 수정하세요.

3. “자기 참조 태그는 필수이므로 모두 심각한 오류로 표시해야 한다.”

• 틀린 이유: Google hreflang 구현에 참여한 Illyes도 자기 참조가 왜 필수인지 확신하지 못하며 없어도 클러스터가 작동할 것으로 믿는다고 공개적으로 말했습니다. 주된 목적은 복사·붙여넣기 편의입니다.
• 대신 할 일: 반환 태그나 코드 오류보다 먼저가 아니라 마지막 정비 단계인 3–4등급에서 자기 참조를 고치세요.

4. “html lang 속성은 Google이 확인하는 언어 신호이므로 hreflang과 함께 감사해야 한다.”

• 틀린 이유: Search Off the Record에서 Google이 HTML lang 속성을 고려하는지 직접 묻자 Illyes는 아니라고 했습니다. CMS 템플릿 기본값으로 들어 있는 경우가 많아 신뢰하기 어렵고, 대신 보이는 콘텐츠로 언어를 감지합니다.
• 대신 할 일: 접근성과 다른 검색엔진을 위해 html lang을 정확히 유지하되 hreflang과 lang의 불일치를 실제 반환 태그 오류보다 우선하지 마세요.

5. “GSC 보고서가 없어졌으므로 유료 크롤러 없이는 hreflang을 감사할 수 없다.”

• 틀린 이유: 작은 사이트에는 소스 수동 표본 검사와 무료/부분 무료 검증기로 충분합니다. Aleyda Solis, Bill Hunt와 Merkle 도구는 Illyes가 신뢰할 만하다고 언급했지만 Google 문서는 제3자 hreflang 도구를 유지 관리하거나 검사하지 않는다고 명시합니다. 크롤러가 필요한 이유는 GSC의 부재가 아니라 규모입니다.
• 대신 할 일: 규모에 맞는 도구를 사용하세요. 작은 사이트는 수동 점검하고 클러스터 수동 검사가 실제로 불가능한 사이트에 크롤러를 사용하세요.

6. “hreflang 내보내기가 정상이므로 hreflang은 문제없다.”

• 틀린 이유: 태그 내보내기가 정상이어도 대상이 색인되었다는 뜻은 아닙니다. hreflang은 canonical이 아닌 색인된 URL을 따릅니다. canonical로 다른 곳을 지정하거나 noindex인 URL의 태그는 유효해 “보여도” 작동하지 않습니다.
• 대신 할 일: 태그 검사 후 주요 클러스터의 색인 상태를 URL 검사로 대조하세요.

수정 전후: 네 유형 읽기

각 오류와 수정법의 구체적이고 최소한의 예시입니다. 설명용 마크업입니다.

1. 반환 태그 누락: 쌍을 깨뜨리는 오류

수정 전 — 미국 페이지는 영국 페이지를 가리키지만 영국 페이지는 돌아오는 링크를 제공하지 않습니다.

<!-- https://example.com/us/  (present) -->
<link rel="alternate" hreflang="en-US" href="https://example.com/us/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/" />

<!-- https://example.com/uk/  (BROKEN — no link back to /us/) -->
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/" />

수정 후 — 영국 페이지도 미국 페이지를 참조하므로 쌍이 대칭입니다.

<!-- https://example.com/uk/  (fixed) -->
<link rel="alternate" hreflang="en-US" href="https://example.com/us/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/" />

2. 잘못된 언어/지역 코드

수정 전 — jp는 일본어 언어 코드가 아니라 국가 코드이며 en-UK는 유효하지 않습니다.

<link rel="alternate" hreflang="jp" href="https://example.com/jp/" />
<link rel="alternate" hreflang="en-UK" href="https://example.com/uk/" />

수정 후 — ISO 639-1 언어(ja)와 ISO 3166-1 alpha-2 지역(UK가 아닌 GB).

<link rel="alternate" hreflang="ja" href="https://example.com/jp/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/" />

3. 절대/상대 URL 혼용: 대규모 템플릿 오류

수정 전 — 프로토콜 상대 URL과 루트 상대 URL입니다. Google은 완전한 URL을 요구합니다.

<link rel="alternate" hreflang="fr-FR" href="//example.com/fr/" />
<link rel="alternate" hreflang="de-DE" href="/de/" />

수정 후 — 전송 방식을 포함한 완전한 URL입니다.

<link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/" />
<link rel="alternate" hreflang="de-DE" href="https://example.com/de/" />

4. 비canonical 대상: 유효해 보여도 작동하지 않음

수정 전 — hreflang이 색인된 버전과 달리 canonical로 다른 곳을 지정한 URL을 가리킵니다.

<!-- hreflang points here… -->
<link rel="alternate" hreflang="es-ES" href="https://example.com/es/producto?ref=nav" />
<!-- …but /es/producto?ref=nav has: <link rel="canonical" href="https://example.com/es/producto"> -->

수정 후 — hreflang이 canonical/색인된 URL을 가리켜 신호 연결이 유지됩니다.

<link rel="alternate" hreflang="es-ES" href="https://example.com/es/producto" />

#4의 함정은 태그만으로 볼 수 없다는 것입니다. 수정되었다고 믿기 전에 URL 검사로 색인된 URL을 확인하세요.

hreflang을 직접 추출하고 검사하기

표본 검사, 임시 추출과 다음 전체 크롤링 전 수정 검증에 사용합니다. 대규모에서는 여전히 크롤러가 기준 자료이며 이 방법들은 그 사이를 위한 것입니다.

Chrome DevTools Console — 현재 페이지의 모든 hreflang 출력

어떤 페이지에서든 Console에 붙여 넣으면 주석을 나열하고 프로토콜 상대 또는 루트 상대 URL을 표시합니다.

[...document.querySelectorAll('link[rel="alternate"][hreflang]')]
  .map(l => {
    const href = l.getAttribute('href');
    const bad = /^\/\//.test(href) || /^\/(?!\/)/.test(href);
    return `${l.hreflang}\t${href}${bad ? '\t⚠ not fully-qualified' : ''}`;
  })
  .join('\n') || 'No HTML hreflang tags on this page (check headers / sitemap).';

“No HTML hreflang tags” (번역) 「HTML hreflang 태그 없음」이 출력되면 HTTP 헤더나 사이트맵으로 제공될 수 있습니다. Console은 DOM만 보므로 별도로 확인하세요.

북마클릿 — 한 번의 클릭으로 클러스터 상호 참조 표본 검사

현재 페이지가 참조하는 모든 대체 버전을 가져와 반환 링크가 없는 것을 보고합니다. 브라우저 CORS로 인해 동일 출처에서만 가능하며 ccTLD 간 쌍에는 크롤러가 필요합니다.

javascript:(async()=>{const base=location.href.split('#')[0];const alts=[...document.querySelectorAll('link[rel="alternate"][hreflang]')].map(l=>({lang:l.hreflang,href:l.href})).filter(a=>a.lang!=='x-default');const out=[];for(const a of alts){try{const html=await(await fetch(a.href)).text();const back=/hreflang=["'][^"']*["']\s+href=["']([^"']+)["']/gi;let m,found=false;while((m=back.exec(html))){if(m[1].split('#')[0].replace(/\/$/,'')===base.replace(/\/$/,'')){found=true;break;}}out.push(`${found?'✓':'✗ MISSING RETURN'}  ${a.lang}  ${a.href}`);}catch(e){out.push(`?  ${a.lang}  ${a.href}  (fetch blocked — cross-origin)`);}}alert(out.join('\n'));})();

grep / 정규식 — 저장된 사이트맵이나 HTML에서 hreflang 추출

다운로드한 XML 사이트맵 또는 크롤링 HTML 내보내기에서 모든 주석을 추출합니다.

# From an XML sitemap using xhtml:link hreflang
grep -oE 'hreflang="[^"]+"[^>]*href="[^"]+"' sitemap.xml

# From a directory of saved HTML pages — list hreflang value + href per file
grep -rhoE '<link[^>]*hreflang="[^"]+"[^>]*>' ./pages/ \
  | grep -oE 'hreflang="[^"]+"|href="[^"]+"'

Python — Screaming Frog 내보내기로 상호 참조 행렬 만들기

출발 URL, hreflang 값, 대상 URL 열을 가진 Screaming Frog hreflang_all.csv 형태의 내보내기를 단방향, 즉 반환 누락 쌍의 집합으로 바꿉니다.

import csv
from collections import defaultdict

links = defaultdict(set)  # source -> set of targets it points to
with open("hreflang_export.csv", newline="", encoding="utf-8") as f:
    for row in csv.DictReader(f):
        src, tgt = row["Address"].strip(), row["Occurrence URL"].strip()
        if src and tgt and src != tgt:
            links[src].add(tgt)

missing = [(a, b) for a, targets in links.items()
                  for b in targets
                  if a not in links.get(b, set())]

print(f"{len(missing)} one-way (missing-return) pairs:")
for a, b in missing[:50]:
    print(f"  {a}  ->  {b}   (no return link)")

열 이름은 실제 내보내기에 맞게 조정하세요. 출력은 상호 태그 행렬의 비대칭 셀, 즉 1등급 수정 대상입니다.

대규모 hreflang 감사 도구

• returntag — 그래프/행렬 표본 검사의 주요 도구. 제 무료 도구는 페이지 또는 사이트맵 클러스터를 그래프와 상호 행렬로 바꾸고 누락 관계와 수정법을 알려 줍니다. Page URL 모드는 페이지 클러스터를, Sitemap 모드는 사이트맵의 선언만 검사합니다. 특정 클러스터를 조사하고 설명하는 데 사용하며 사이트 전체 크롤링을 대신하지 않습니다.
• Ahrefs Site Audit — 대규모용. HTML·헤더·사이트맵에서 hreflang을 추출하고 상호 검사를 하며 각 클러스터를 네트워크 그래프로 보여 줍니다. URL Details > Hreflangs tab에서 깨진 연결이 빨간색입니다. 어떤 관계가 깨졌는지 가장 빨리 보고 이해관계자에게 보여 주기 쉽습니다. Page Explorer 로 문제 유형별 페이지를 필터링한 뒤 개별 그래프를 보세요.
• Screaming Frog SEO Spider. Configuration > Spider > Crawl Hreflang을 켜고 교차 도메인 검증을 위해 Config > CDNs에 형제 ccTLD를 추가하세요. Crawl Analysis로 반환 링크 필터를 채웁니다. Missing Return Links(반환 링크 누락), Inconsistent Language & Region Return Links(언어·지역 반환 링크 불일치), Non-Canonical Return Links(비canonical 반환 링크), Noindex Return Links(noindex 반환 링크), Non-200 Hreflang URLs(200이 아닌 hreflang URL), Unlinked Hreflang URLs(연결되지 않은 hreflang URL)입니다. Reports > Hreflang에서 내보내세요. hreflang 튜토리얼 은 상세 설정 참조 자료입니다.
• Google Search Console — URL 검사. International Targeting 보고서가 없어졌고 예전에도 canonical 구성원만 보고했으므로 일괄 감사용은 아닙니다. 그러나 수정 후 hreflang이 색인된 URL을 가리키는지 확인하는 5단계에는 필수입니다.
• 작은 사이트와 표본 검사용 무료/부분 무료 검증기 — Aleyda Solis의 hreflang 태그 생성기/테스터, Bill Hunt 검사기와 Merkle 도구입니다. Gary Illyes가 잘 작동한다고 아는 도구로 언급했지만 Google 문서는 제3자 도구를 유지 관리하거나 검사하지 않는다고 명시합니다. 수동 검사가 가능할 때 사용하고 크롤러는 진정한 대규모에 사용하세요. 모든 도구의 판정은 공식 결론이 아니라 진단으로 취급하세요.
• Bing Webmaster Tools — hreflang 검증은 없습니다. Bing 시장용 Content-Language는 별도로 감사하세요.

살펴볼 만한 자료

제가 쓴 관련 글

• Over 67% of Domains Using Hreflang Have Issues (Study of 374,756 Domains) — hreflang 사용 도메인의 67% 이상에 문제가 있다는 374,756개 도메인 연구입니다. 제 Brighton SEO 2023 연구로 당시 최대 규모이며 이 방법론의 뼈대입니다. 오류 분포와 반환 태그/x-default 수치는 여기서 나옵니다.
• Hreflang: The Easy Guide for Beginners — 초보자를 위한 쉬운 hreflang 안내입니다. 이 글에서 이미 안다고 전제하는 기본 사항을 다루는 Ahrefs 구현 가이드입니다.
• The Beginner’s Guide to Technical SEO — 기술 SEO 입문 가이드로, 국제 신호가 더 넓은 기술적 맥락에서 어디에 위치하는지 설명합니다.

제 발표

• Hreflang Study and Interesting Issues — Brighton SEO 2023 (Speaker Deck) — hreflang 연구와 흥미로운 문제를 다룬 연구의 바탕 슬라이드입니다.
• The most common hreflang issues across 374,756 domains — Brighton SEO, Sept 2023 (YouTube) — 374,756개 도메인에서 가장 흔한 hreflang 문제를 다룬 2023년 9월 실제 발표입니다.
• International SEO: The Weird Technical Parts — Pubcon Vegas 2019 (SlideShare) — 국제 SEO의 특이한 기술 영역을 다루며, 3단계와 5단계의 근거인 “hreflang follows the indexed version, not the canonical” (번역) 「hreflang은 canonical이 아닌 색인된 버전을 따른다」는 주장을 설명합니다.

업계의 다른 자료

• Tell Google about localized versions of your page — Google에 현지화 버전을 알리는 공식 hreflang 참조 문서입니다. 상호 참조, 완전한 URL과 예약 코드를 다룹니다.
• Search Off the Record — “How serving works, hreflang, and more!” — 검색 결과 제공 방식과 hreflang 등을 다룹니다. Google Search Relations 팀의 Illyes, Splitt, Sassman이 GSC가 canonical만 보고하는 이유, 검증기가 없는 이유와 다중 속성 대형 사이트에서 오류가 많은 이유를 설명합니다.
• How To Audit & Test Hreflang (Screaming Frog) — hreflang 감사·테스트를 위한 필터별 상세 설정 해설입니다.
• Study: 31% of international websites contain hreflang errors (Search Engine Land) — 국제 사이트의 31%에 hreflang 오류가 있다는 Dan Taylor / SALT.agency의 독립적인 18,786개 도메인 연구입니다. 제 더 큰 연구와 비교하기 좋습니다.
• Google Says They Will Ignore Incorrect hreflang Implementation (Search Engine Roundtable) — Google이 잘못된 hreflang 구현을 무시한다고 말한 보도입니다. “무시이지 페널티가 아니다”라는 관점으로 공포 대신 우선순위를 정하게 합니다.
• Google Insights: Can Incorrect Hreflang Tags Hurt SEO? (Search Engine Journal) — 잘못된 hreflang 태그가 SEO에 해를 줄 수 있는지 다루며 같은 결과를 뒷받침합니다.

실력 점검: 대규모 hreflang 감사

대규모 방법론에 관한 짧은 질문 다섯 개입니다. 각각 답을 고르고 확인하세요.

변경 내역