Hreflang 은 디버그를 고유하게 귀찮게 만드는 속성을 가지고 있습니다: 모든 실패 모드는 정확해 보이는 마크업을 생성합니다. 콘솔 오류도 없고,브라우저에 빨간색 배지도 없고,빌드 실패도 없습니다. 태그가 렌더링되고,페이지가 HTML 로 유효성을 검사하고,주석이 아무 것도 하지 않고,몇 주 후에 Search Console 보고서나 다른 나라의 누군가가 잘못된 페이지를 얻었다고 말하는 것을 알게 됩니다.
저는 지금 이것들을 충분히 디버깅해서 목록을 가지고 있습니다. 이것은 그 목록인데,대략 제가 얼마나 자주 각 것을 찾느냐에 따라 정렬되어 있고,여러분이 관찰할 증상과 수정사항이 있습니다. 그것은 아래에 있습니다 완전한 흐레플랑 가이드 조각들과 함께 x-기본값 그리고 흐레플랑 대 표준.
TL;DR: 가장 일반적인 hreflang 오류는 반환 태그 누락, ISO가 아닌 코드 등입니다
en-UK, 상대 URL, 언어 전체를 가리키는 표준, 누락x-default및 동일한 URL 에 대한 구현 방법을 혼합합니다. 모두 무음입니다: 마크업이 렌더링되고 아무 작업도 수행하지 않습니다. Search Console's International Targeting report catches return-tag and unknown-code errors at scale; 나머지는 크롤링 또는 렌더링된 HTML 을 살펴봐야 합니다. The hreflang 태그 생성기 배포하기 전에 코드, URL, 중복 및 누락된 대체 기능의 유효성을 검사합니다.
1. 반환 태그 누락
증상: Search Console reports "no return tags". 언어 버전은 올바른 시장으로 교환되지 않으며 전체 세트는 마치 hreflang이 없는 것처럼 동작합니다.
원인: 페이지 A 는 페이지 B 를 대체 페이지로 선언하지만 페이지 B 는 페이지 A 를 선언하지 않습니다. Google 은 양측이 관계를 확인하도록 요구하고 보답되지 않은 주석을 삭제합니다.
수정: 자기 참조 항목을 포함하여 그룹의 모든 페이지에 완전하고 동일한 주석 세트를 넣습니다. 어떤 페이지에 어떤 항목이 필요한지 영리하게 설명하려고 하지 마십시오. 영어 페이지에는 영어,프랑스어, 독일어 및 x-default; 프랑스어 페이지도 마찬가지입니다; 독일어 페이지도 마찬가지입니다. 모든 곳에서 동일한 블록이 있습니다.
이것은 가장 일반적인 실패의 넓은 여백에 의해, 그리고 거의 항상 페이지 당 손으로 편집하거나 "the other languages" 보다는 "all languages"를 렌더링하는 템플릿에 의해 발생합니다.
2. 비 ISO 지역 코드 사용
증상: Search Console 보고서 "알 수 없는 언어 code" 또는 주석이 조용히 무시되는 동안 전혀 아무것도 없습니다.
원인: en-UK 분야를 이끌고. UK ISO 3166-1 알파-2 코드가 아닙니다; 영국은 GB. 발명된 지역 코드와 같습니다 en-EU 그리고 es-LATAM 와 같은 종류의 오류입니다 en-uk 이미 유효하지 않은 영역과 잘못된 케이스가 짝을 이룹니다.
수정: 언어 ISO 639-1는, 하이픈으로 결합된 ISO 3166-1 alpha-2 에서 지역, 라틴 아메리카를 위해, 유효한 응답 UN M49 부호입니다 es-419. 중국어의 경우 스크립트 하위 태그를 선호합니다: zh-Hant 그리고 zh-Hans.
| 틀린 | 오른쪽 | 왜 |
|---|---|---|
en-UK |
en-GB |
UK 는 ISO 3166-1 코드가 아닙니다 |
en-EU |
국가별로 별도의 항목을 입력하거나 일반 항목을 입력합니다 en |
EU는 국가 코드가 아닙니다 |
es-LATAM |
es-419 |
라틴 아메리카의 UN M49 지역 코드 |
zh-CH |
zh-Hans 또는 zh-CN |
CH 는 스위스 |
CA |
en-CA 그리고 fr-CA |
지역만으로는 유효하지 않습니다 |
3. 지역 전용 주석
증상: 아무 일도 일어나지 않습니다. 주석은 완전히 무시됩니다.
원인: 에서와 같이 언어 이름을 지정하지 않고 국가를 대상으로 하려고 합니다 hreflang="US" 또는 hreflang="CA". Hreflang은 설계상 언어 우선입니다; 지역은 그 자체의 목표가 아니라 언어의 선택적 축소입니다.
수정: 언어의 이름을 지정하십시오. 캐나다에 두 가지 언어로 서비스를 제공하는 경우,즉 두 가지 항목입니다: en-CA 그리고 fr-CA.
4. 상대 URL
증상: 주석은 무시됩니다. "this works on my machine" 상대 URL 은 브라우저에서 잘 해결되기 때문에 자주 동반됩니다.
원인: href="/fr/pricing" 대신 href="https://example.com/fr/pricing". Hreflang 은 프로토콜과 호스트를 포함한 완전한 자격을 갖춘 절대 URL 을 필요로 합니다.
수정: 절대 URL 을 내보냅니다. 템플릿에서 빌드하는 경우 하드코딩된 문자열이 아닌 구성된 사이트 원본에서 빌드하므로 스테이징 배포는 프로덕션 URL 을 게시하지 않거나 그 반대의 경우도 마찬가지입니다.
5.언어 전반을 가리키는 정경
증상: 전체 언어 버전이 색인에서 사라집니다. Hreflang 이 올바른 것으로 나타나며 아무런 효과가 없습니다.
원인: 프랑스어 페이지는 영어 페이지를 정식 페이지로 선언합니다. 이는 Google에 프랑스어 URL을 삭제하도록 지시하며 정식화된 URL은 hreflang의 말에 관계없이 누구에게도 제공될 수 없습니다. 정식은 더 강한 신호이며 승리합니다.
수정: 모든 페이지는 그 자체로 정경화됩니다. Hreflang 은 그 자체 정경 페이지들 사이의 관계를 설명합니다. 이것은 그 자체로 읽을 가치가 있습니다: 흐레플랑 vs 캐노니컬 매개변수화된 URL을 포함한 조합을 통해 작동합니다.
6. x 과태 없음
증상: 당신이 분명히 임의의 언어 버전에 땅을 대상으로하지 않는 국가에서 방문자.
원인: 어떤 대체 선언하지, 그래서 구글은 선택합니다.그 선택은 네덜란드 방문자가 독일어 페이지에 끝나는 방법, 당신에게 보이지 않는 유사성 신호를 기반으로합니다.
수정: 하나 추가 x-default 세트당 항목,언어 선택기 또는 기본 국제 버전을 가리킵니다. The x-기본 가이드 가리킬 곳과 쓸모없게 만드는 실수를 다룹니다.
7. 구현 방법 혼합
증상: 간헐적이고 재현하기 어려운 동작. 일부 페이지는 올바르게 교환되고 다른 페이지는 그렇지 않습니다.
원인: HTML <link> 태그 및 XML 사이트맵 xhtml:link 동일한 URL 에 대해 hreflang 을 선언하는 항목 모두. 각각은 단독으로 유효합니다. 함께 표류하는 진실의 두 가지 소스이며,그들이 동의하지 않을 때 Google 이 어느 것을 사용했는지 알 수있는 방법이 없습니다.
수정: URL 세트당 하나의 메서드를 선택합니다. 대부분의 사이트에 대한 HTML 태그,로컬이 많고 린 페이지 헤드를 원할 때 사이트맵 항목,PDF 와 같은 HTML 이 아닌 파일에 대한 HTTP 헤더. 그런 다음 백업으로 남겨 두지 않고 다른 하나를 제거합니다.
8. 후행-슬래시 및 프로토콜 불일치
증상: 반환 태그는 두 페이지 모두 주석을 가지고 있음에도 실패합니다.
원인: 주석은 다음을 가리킵니다 https://example.com/fr 인덱서블 URL 은 동안 https://example.com/fr/. 또는 가리킨다 http:// HTTPS 사이트에서. 이들은 다른 URL 이므로 실제 페이지의 반환 태그는 다른 페이지의 이름이 지정된 URL 과 일치하지 않습니다.
수정: 각 URL 의 정확한 표준 형식,사이트맵에 넣을 동일한 문자열을 사용하십시오. 표준 태그가 사용하는 동일한 URL 빌더에서 hreflang 을 생성하므로 두 사람이 동의하지 않을 수 없습니다.
9. 리디렉션이나 404s 를 가리키며
증상: 부분적이거나 저하된 동작; 영향을 받는 쌍에서 콘솔 오류를 검색하세요.
원인: 로케일이 폐기되고 URL 이 이제 리디렉션되거나 이름이 지정된 주석이 유지되는 동안 번역된 페이지가 삭제되었습니다. 리디렉션 대상은 여전히 해결되므로 치명적이지는 않지만 홉을 추가하고 최종 URL 의 반환 태그가 이름이 지정된 URL 과 일치하지 않을 수 있습니다. 404 대상은 쌍을 완전히 독살합니다.
수정: 자신만의 흐레플랑 타겟을 크롤링하고 상태 코드를 확인하세요. 이것은 아무도 실행하지 않는 검사이며, 작성 당시 올바른 세트에서 부패를 찾는 검사입니다.
10. noindex 페이지에 주석을 달기
증상: 집합은 일관되지 않게 동작합니다; 일부 대체 항목은 나타나지 않습니다.
원인: 페이지를 들고 있는 동안 언어 대체 페이지로 광고됩니다 noindex. 귀하는 Google에 이 URL을 시장에 제공하고 색인에서 제외하라고 지시했습니다. 모순은 유리하게 해결됩니다 noindex.
수정: 주석을 삭제하거나 삭제하세요 noindex. 남은 음식과 번역되지 않은 자리 표시자 페이지를 준비하는 것이 일반적인 범인입니다.
11. robots.txt 에서 hreflang 타겟 차단
증상: 대체 항목은 확인되지 않습니다. Search Console 은 반환 태그를 눈에 띄게 전달하는 페이지에 대한 반환 태그 오류를 표시합니다.
원인: 대상은 robots.txt 에서 허용되지 않으므로 Googlebot 이 가져올 수 없으며 반환 태그를 볼 수 없습니다. 옆의 주석은 괜찮습니다; 다른 쪽의 확인은 도달 할 수 없습니다.
수정: hreflang 주석에서 이름을 지정한 모든 URL 의 크롤링을 허용합니다. 섹션이 진정으로 크롤링되어서는 안된다면 hreflang 세트에도 있어서는 안됩니다. The robots.txt 발전기 의도한 것보다 더 넓은 현재 규칙이 차단하는 내용을 감사하는 데 유용합니다.
12. 한 세트 안에 코드를 복제한다
증상: 예측할 수 없습니다. Google 은 첫 번째,마지막을 가져 가거나 쌍을 버릴 수 있습니다.
원인: 서로 다른 URL 을 가리키는 동일한 hreflang 값을 가진 두 개의 엔트리,보통 두 시스템이 모두 주석을 방출하기 때문이거나 로케일 맵에 중복된 키가 있기 때문입니다. 둘 x-default 항목은 가장 일반적인 형태로 동일한 문제입니다.
수정: 세트당 코드당 하나의 엔트리. 템플릿이 아닌 렌더링된 소스를 봅니다; 두 번째 블록을 추가하는 플러그인은 템플릿만으로는 보이지 않습니다. The 무료 hreflang 발전기 페이지가 다른 무엇을 방출하는지 볼 수는 없지만 빌드한 세트에서 중복 코드를 플래그로 표시합니다.
이러한 오류를 어떻게 체계적으로 찾아내는가?
각각 다른 클래스를 잡기 때문에 이 순서로 세 번 패스합니다.
먼저 콘솔을 검색하세요. 국제 타겟팅 보고서는 전체 속성을 다루고 확장 두 가지 오류를 찾습니다: 누락 된 반환 태그와 알 수없는 언어 코드. 전체 다시 그리기가 얼마나 오래 걸릴 때까지 배포보다 뒤떨어져 있으므로 변화가없는 일주일을 정상으로 취급하십시오.
두 번째로 크롤링합니다. hreflang 을 추출하는 모든 크롤러는 URL 당 세트를 제공합니다. 클러스터별로 그룹화하고 카운트를 비교하십시오: 5 개 그룹에 4 개의 항목이있는 페이지가 버그입니다. 그런 다음 오류 8,9, 10 및 11 을 찾는 패스 인 모든 대상의 상태 코드를 확인하십시오.
잘못 작동하는 특정 페이지에 대해 HTML을 마지막으로 렌더링했습니다. curl 주석 블록을 세고, 계산합니다 x-default 항목을 입력하고 URL 문자를 표준 문자와 비교합니다. 여기서 중복 및 후행 슬래시 불일치가 나타나며 런타임에 플러그인이 주입된 내용을 볼 수 있는 유일한 패스입니다.
생성기는 그 어떤 것 이전에 실행할 가치가 있는데,왜냐하면 여러분이 작성한 지점에서 집합을 유효성 검사하면 오류 2,3, 4,6, 12 가 출하되기 전에 제거되기 때문입니다. 어떤 도구도 강제할 수 없는 것은 상호주의입니다. 왜냐하면 그것은 여러분 앞에 있는 페이지가 아닌 다른 페이지의 속성이기 때문입니다. 그것을 위해 규율은 구조적입니다: 하나의 로케일 맵,하나의 렌더러,모든 페이지의 전체 블록입니다 다음.js 그리고 워드 프레스 가이드는 코드에서 어떻게 보이는지 보여줍니다.
자주 묻는 질문
가장 흔한 hreflang 오류는 무엇입니까?
반환 태그 누락. 페이지 A 는 대체 페이지로 페이지 B 를 명명하지만 페이지 B 는 페이지 A 의 이름을 지정하지 않으므로 Google 은 관계를 폐기합니다. 수정 사항은 자기 참조 항목을 포함하여 완전히 동일한 주석 세트를 그룹의 모든 페이지에 넣는 것입니다.
Search Console에서 내 hreflang에 반환 태그가 없다고 말하는 이유는 무엇입니까?
왜냐하면 당신이 가리킨 페이지가 일치하는 주석으로 다시 가리키지 않거나 약간 다른 URL 로 다시 가리키기 때문입니다. 후행 슬래시,프로토콜 차이 및 www 대 non-www 는 모두 다른 URL 로 계산됩니다.
en-UK는 유효한 hreflang 코드입니까?
아니요. UK 는 ISO 3166-1 alpha-2 코드가 아닙니다. 영국의 올바른 코드는 GB, 그래서 값은 en-GB. en-UK 은 묵묵히 무시된다.
hreflang URL은 상대적일 수 있나요?
아니요. Hreflang 은 프로토콜과 호스트를 포함한 완전한 자격을 갖춘 절대 URL 을 필요로 합니다. 상대 URL 은 브라우저에서 정상적으로 해결되더라도 무시됩니다.
표준 태그가 hreflang을 재정의합니까?
효과적으로 그렇습니다. 페이지가 다른 언어 버전으로 표준화되는 경우 해당 URL 은 색인에서 삭제되고 hreflang 은 다시 가져올 수 없습니다. 각 페이지는 자체적으로 표준화되어야 합니다.
hreflang 수정 사항이 나타나는 데 얼마나 걸리나요?
며칠에서 몇 주까지. Google 은 반환 태그를 확인하기 전에 세트의 모든 페이지를 다시 작성해야하며 Search Console 은 동일한 일정으로 업데이트를보고합니다.
HTML 태그와 사이트맵 hreflang 을 모두 사용할 수 있습니까?
할 수는 있지만,하지 않습니다. 동일한 URL 에 대한 두 소스가 서로 떨어져 표류하며,동의하지 않을 때 어느 것이 사용되었는지 알 수있는 방법이 없습니다. URL 세트 당 하나의 메서드를 선택하십시오.
흐레플랑 표적은 크롤링이 가능해야 합니까?
예. robots.txt 에서 대상이 차단되거나 noindex 로 표시된 경우 Google 은 반환 태그를 확인할 수 없으며 마크업이 정확하더라도 주석이 실패합니다.
