기술 SEO
HTTP Link 헤더 SEO 검사기
URL을 입력하세요. 서버 측에서 해당 URL을 가져와 RFC 8288에 따라 HTTP Link 응답 헤더에서 rel="canonical", rel="alternate" hreflang, rel="next"/"prev" 항목을 파싱합니다 — 그런 다음 같은 페이지의 HTML <link> 태그와 대조하여 충돌이 있으면 표시합니다.
reCAPTCHA로 보호됩니다. URL은 서버 측에서 가져오며(SSRF 방어 적용), 응답 헤더만 읽습니다 — 아무것도 저장되지 않습니다.
Link 헤더가 중요한 이유
canonical과 hreflang을 검사하는 도구는 대부분 페이지 <head> 안의 HTML <link> 태그만 봅니다. RFC 8288은 동일한 신호를 선언할 수 있는, 똑같이 유효한 두 번째 위치를 정의합니다 — 바로 HTTP Link: 응답 헤더입니다. Google은 이를 명시적으로 문서화하고 존중하며, WordPress와 여러 CDN이 자동으로 이를 전송합니다. 그리고 이는 HTML이 아닌 리소스 — PDF, 이미지, JSON API 응답 — 에 canonical이나 hreflang을 지정할 수 있는 유일한 방법입니다. 이런 리소스에는 <link> 태그를 넣을 <head> 자체가 없기 때문입니다. 어디에도 렌더링되지 않기 때문에, CDN 엣지 규칙이 HTML 태그와 조용히 다른 값을 설정해 버리거나, 이런 방식으로 canonical을 설정할 생각을 아무도 하지 못한 PDF는 브라우저에서도, HTML만 읽는 어떤 도구에서도 전혀 보이지 않습니다.
이 도구가 검사하는 항목
정규식으로 추측하는 것이 아니라, 서버가 실제로 보낸 응답 헤더를 읽는 진짜 RFC 8288 파서입니다.
RFC 8288 기반 Link 헤더 파싱
원본 Link: 헤더 값 — 쉼표로 구분된 여러 항목, 따옴표로 감싼 매개변수, 다중 값 rel 목록 포함 — 을 구조화된 rel=canonical, rel=alternate, rel=next/prev 항목으로 파싱하고, 유효한 link-value로 파싱되지 않는 세그먼트를 표시합니다.
헤더와 HTML의 canonical 충돌
헤더의 rel="canonical" 대상과 페이지 HTML의 <link rel="canonical"> 태그를 비교합니다. 불일치는 실제로 존재하지만 조용히 지나가는 문제입니다: 검색엔진이 둘 중 어느 신호든 따를 수 있어 canonicalization이 사실상 불확정적이게 됩니다. 헤더 canonical이 두 개 이상인 경우, 도메인이 다른 대상, 가져온 URL 자체를 참조하는지 여부도 표시합니다.
헤더를 통한 hreflang
모든 rel="alternate"; hreflang="..." 헤더 항목의 언어 코드를 검증하고, 항목이 2개 이상인데 x-default가 없는 경우, 자기 참조 항목이 없는 경우, 서로 다른 URL을 가리키는 중복 코드를 확인합니다 — 그런 다음 전체 세트를 페이지의 HTML hreflang 태그와 대조하여 충돌을 찾습니다.
HTML이 아닌 리소스의 커버리지
PDF, 이미지, API 응답(HTML이 없으므로 <link> 태그 자체가 불가능)의 경우, 헤더 canonical이 전혀 전송되지 않은 경우를 표시합니다 — 즉 해당 리소스는 검색엔진을 위한 canonicalization 신호가 전혀 없다는 뜻이며, 이는 매우 놓치기 쉬운 부분입니다.
자주 묻는 질문
HTTP Link 헤더란 무엇이고, 제 사이트는 왜 이를 전송하나요?
RFC 8288에 정의된 응답 헤더로, 보통 HTML <link> 태그로 작성하는 것과 동일한 rel 기반 관계(canonical, alternate, next, prev 등)를 담습니다 — 다른 점은 HTML이든 아니든 모든 응답에 대해 작동한다는 것입니다. WordPress 코어는 일부 Link 헤더를 자동으로 전송하며, 많은 CDN과 리버스 프록시가 엣지에서 이를 삽입하거나 재작성할 수 있는데, 때로는 원본 사이트가 이를 모르는 경우도 있습니다.
헤더의 canonical이 HTML canonical 태그와 다릅니다 — 버그인가요?
거의 항상 그렇습니다. Google의 공식 문서는 두 신호 모두 유효하다고 말하지만, 서로 충돌할 때 어느 쪽이 우선하는지는 보장하지 않습니다 — 실무에서는 이것이 해당 URL의 canonicalization을 예측 불가능하게 만들 뿐입니다. CDN, 캐싱 계층, 플러그인이 HTML 템플릿과 별개로 헤더를 삽입하고 있지는 않은지 확인하고 두 값을 일치시키세요.
HTML <link> 태그 없이 hreflang을 사용할 수 있나요?
가능합니다 — 헤더 형식은 태그 형식과 완전히 동등하며, HTML이 아닌 리소스(예: PDF)에 hreflang을 지정하거나 HTML 템플릿을 건드리지 않고 응답에 hreflang을 추가하는 표준적인 방법입니다. 규칙은 동일합니다: 모든 언어 버전은 자기 자신을 목록에 포함해야 하며(자기 참조), 버전이 두 개 이상이면 x-default를 추천합니다.
Google이 실제로 Link 응답 헤더를 사용하나요?
네. Google 서치 센트럴 문서는 rel="canonical"과 rel="alternate" hreflang을 모두 지정하는 지원되는 방법으로 HTTP 헤더를 명시적으로 나열하며, 이 메커니즘이 존재하는 이유로 HTML이 아닌 파일을 특별히 언급합니다.
제 URL이나 그 내용이 어딘가에 저장되나요?
아니요. 가져오기는 이번 한 번의 검사만을 위해 서버 측에서 이루어지며 결과는 브라우저로 바로 반환됩니다. 요청 제한(rate-limit) 카운터를 제외하면 데이터베이스나 로그에 기록되는 것은 없습니다.