헤딩 구조 Heading Structure

헤딩 구조(Heading Structure)는 h1부터 h6까지의 제목 태그로 문서의 위계를 나타내는 HTML 골격입니다. 사용자와 스크린 리더가 페이지를 탐색하는 기준이자, AI 검색 시대에는 콘텐츠가 발췌·인용되는 청크 단위의 경계 역할까지 맡습니다.

온페이지 2026. 7. 11 업데이트 By 박혜정

문서의 위계를 그리는 h1~h6 골격

헤딩 구조는 h1부터 h6까지 여섯 단계의 제목 태그로 문서의 논리적 위계를 나타내는 HTML 골격입니다. 책의 목차처럼, 방문자와 스크린 리더가 페이지를 훑어보고 원하는 섹션으로 건너뛰는 기준이 됩니다. 구글 검색 센터의 SEO 기본 가이드는 긴 콘텐츠를 문단과 섹션으로 나누고 헤딩으로 탐색을 돕도록 권합니다 Google 공식.

접근성 데이터는 그 값을 수치로 보여줍니다. WebAIM 스크린 리더 사용자 설문(9차, 2021년)에서 긴 페이지의 정보를 찾을 때 응답자의 67.7%가 "페이지의 헤딩을 먼저 탐색한다"고 답했고, 이는 찾기 기능(13.9%)이나 꼼꼼히 읽기(8.1%)을 크게 앞선 압도적 1위였습니다 WebAIM 조사. 헤딩이 없거나 위계가 엉킨 페이지는 이 사용자들에게 목차 없는 책과 같습니다.

페이지 전체의 제목이 타이틀 태그라면, 헤딩은 본문 속 장(章) 제목입니다. 구글의 제목 링크 문서는 검색 결과의 제목을 만들 때 주요 시각 제목과 헤딩 요소를 참고한다고 설명하며, 가장 눈에 띄는 h1을 다른 텍스트와 시각적으로 구분되게 두라고 권합니다 Google 공식.

h1~h6 위계와 올바른 작성법

구글 개발자 문서 스타일 가이드는 네 가지를 분명히 밝힙니다. 콘텐츠를 헤딩 태그로 계층 구성할 것, 페이지당 레벨 1 헤딩(h1)은 한 번만 쓸 것, 헤딩 레벨을 건너뛰지 말 것(h3은 h2 아래에만), 빈 헤딩 없이 헤딩 뒤에 반드시 콘텐츠를 둘 것입니다 Google 공식.

<h1>웹사이트 제작 가이드</h1>

<h2>기획 단계</h2>
    <h3>요구사항 정의</h3>
    <h3>사이트맵 설계</h3>

<h2>디자인 단계</h2>
    <h3>와이어프레임</h3>

<h2>개발 단계</h2>

MDN 문서도 같은 원칙을 권합니다. 페이지에는 콘텐츠를 설명하는 h1 하나를 두고, 레벨을 건너뛰지 말고 헤딩을 중첩하라는 것입니다 MDN. 워드프레스에서는 대부분의 테마가 글·페이지 제목을 h1으로 출력하므로, 구텐베르크 에디터로 쓰는 본문은 h2부터 시작하는 것이 안전합니다.

순위 신호일까 - 공식 입장과 실측을 나눠 본다

헤딩과 순위의 관계는 구글 공식 입장과 업계 실측을 구분해 읽어야 오해가 없습니다. 구글은 헤딩의 개수와 순서를 순위 신호로 보지 않습니다. 기본 가이드는 헤딩을 의미 순서대로 두는 것이 스크린 리더에는 훌륭하지만 구글 검색에서는 순서가 뒤섞여도 상관없다고 명시합니다 Google 공식. 존 뮬러도 "H1 태그가 하나도 없든 다섯 개든 사이트는 문제없이 순위에 오릅니다"라고 말했습니다 Google 공식.

업계 실측도 이 입장과 대체로 비슷합니다. Ahrefs는 H1 모범 사례를 어겨도 SEO 재앙이나 구글 페널티로 이어질 가능성은 극히 낮다고 정리하며, H1이 완벽하지 않아도 구글이 콘텐츠를 이해하는 장치를 갖췄다고 설명합니다 Ahrefs 실측. 같은 문서가 인용한 Gotch SEO의 2024년 분석에서도 H1의 부분 키워드 일치와 순위의 상관은 -0.03으로 사실상 0에 가까웠습니다 Gotch SEO 실측.

두 근거가 한 방향을 가리킵니다. 헤딩 구조의 직접적인 순위 효과는 약하고, 진짜 가치는 사용자·보조기기·AI 발췌 경험에 있습니다. 그래서 검색어를 욱여넣은 헤딩으로 순위를 끌어올리려는 시도는 공식 문서와 실측 어느 쪽에서도 지지받지 못합니다.

AI 검색 시대의 새 역할 - 발췌·인용의 청크 단위

구글 AI 오버뷰나 대화형 AI 검색은 페이지 전체가 아니라 질문에 답이 되는 조각(청크)을 골라 인용합니다. 구글은 AI 기능이 검색 색인에서 관련 콘텐츠를 가져와 요약하고, 응답에 쓴 출처 페이지 링크를 함께 보여준다고 안내합니다 Google 공식. 이는 RAG 방식과 같습니다.

RAG 시스템은 문서를 청크로 나눠 각각을 임베딩하고, 이 청크가 검색·인용의 단위가 됩니다. 문단·헤딩 같은 구조적 경계를 분할 기준으로 삼을수록 각 청크가 논리적 단위와 일치해 검색 정확도가 올라갑니다. 헤딩 하나와 그 아래 문단 묶음이 곧 독립된 인용 단위가 되는 셈입니다.

청크 안에서 무엇이 인용 확률을 높이는지는 연구로 검증돼 있습니다. 프린스턴·IIT Delhi 연구진의 GEO 실험(KDD 2024, 쿼리 1만 개)에서는 통계 추가·인용문 추가·출처 인용이 가장 효과적이어서, 최상위 기법이 생성엔진 가시성을 기준선 대비 41% 끌어올린 반면 키워드 반복은 효과가 없었고, 특히 출처 인용은 검색 5위 페이지의 가시성을 115.1% 높였습니다 GEO 논문. 헤딩으로 청크 경계를 또렷이 나누고 그 안에 수치·출처를 담는 편이 발췌·인용에 유리하다는 뜻입니다.

그래서 헤딩 작성에는 한 가지 습관이 도움이 됩니다. 각 헤딩과 그 직후 문단만 떼어 읽어도 완결된 답이 되도록 쓰는 것입니다. "더 알아보기" 같은 모호한 헤딩보다 "워드프레스 헤딩 구조 검사 방법"처럼 구체적인 헤딩이 발췌되기에 유리하고, 헤딩만 이어 읽었을 때 문서 요약이 되는지 확인해 보면 됩니다.

구조를 검증하는 실무 체크포인트

헤딩 구조의 절반은 콘텐츠 작성 전 템플릿 단계에서 이미 결정됩니다. 구글과 MDN 가이드에서 뽑아낸 점검 항목입니다.

로고는 헤딩이 아닙니다. h1은 그 페이지 콘텐츠의 주제에 붙이고, 로고는 링크나 이미지로 처리합니다. 구글은 페이지당 h1을 한 번만 쓰라고 안내합니다 Google 공식.
위젯·사이드바·푸터 제목에 h2, h3을 남발하면 본문 위계와 뒤섞여 문서 아웃라인이 흐려집니다.
카드·배너 같은 공통 컴포넌트는 헤딩 레벨을 옵션으로 받도록 설계합니다. 같은 컴포넌트가 페이지에 따라 h2 또는 h3이 되어야 하기 때문입니다.
크기와 굵기는 CSS로 조절합니다. MDN은 헤딩이 시각적 스타일이 아니라 문서 구조를 나타내는 요소라고 설명합니다 MDN.
검수 단계에서는 헤딩 아웃라인을 시각화하는 브라우저 확장이나 접근성 감사 도구로 위계를 직접 확인합니다.

자주 하는 실수 - 디자인이 위계를 결정할 때

가장 흔한 실수는 글자 크기 때문에 위계를 건너뛰는 것입니다. h3의 기본 크기가 커 보인다는 이유로 h2 다음에 h4를 쓰는 식입니다. 구글과 MDN 모두 레벨을 건너뛰지 말라고 분명히 밝히며, MDN은 레벨을 건너뛰면 스크린 리더 사용자가 빠진 헤딩을 찾느라 혼란스러워할 수 있다고 설명합니다 MDN.

<!-- 잘못 : 글자 크기 때문에 레벨을 건너뜀 -->
<h2>서비스 소개</h2>
<h4>제작 프로세스</h4>

<!-- 교정 : 위계는 순서대로, 크기는 CSS로 -->
<h2>서비스 소개</h2>
<h3 class="heading-sm">제작 프로세스</h3>

h1을 여러 개 사용 - MDN은 중첩된 섹션마다 h1을 쓰던 옛 방식이 "문서 아웃라인 알고리즘"에 기댔지만, 이 알고리즘은 브라우저와 보조기기에 실제로 구현된 적이 없어 현재는 비권장(non-conforming)이라고 밝힙니다 MDN. 구글이 다중 h1을 허용하더라도, 페이지당 h1 하나를 유지하는 편이 안전합니다.
헤딩을 굵은 글씨 대용으로 사용 - 강조는 strong, 구조는 헤딩입니다.
빈 헤딩 - 구글은 헤딩 뒤에 반드시 콘텐츠가 오게 하라고 안내합니다 Google 공식.
헤딩 없는 긴 본문 - 두세 스크롤이 넘도록 헤딩이 없다면 h2, h3으로 끊어 줍니다. 발췌 단위가 없으면 AI 검색이 인용할 조각도 없습니다.
검색어를 욱여넣은 나열형 헤딩 - 사람이 읽기 어려운 헤딩은 인용 단위로서의 가치도 함께 떨어집니다.