div만 잔뜩 써도 사이트가 잘 돌아가는데, 굳이 시맨틱 태그로 바꿔야 할까요? 저도 한때 그렇게 생각했습니다. 그런데 Lighthouse 접근성 점수가 바닥을 치고, 애드센스 첫 신청이 거절당하고 나서야 생각이 바뀌었습니다. 시맨틱 HTML은 단순한 코드 스타일 문제가 아니라, 크롤러와 사람이 동시에 읽을 수 있는 구조를 만드는 문제였습니다.
접근성이 바닥이었던 이유, div 중첩 구조 때문이었습니다
처음 블로그를 만들 때 저는 div.wrap, div.container, div.content, div.post-area 이렇게 4단 중첩으로 쌓았습니다. 기능은 멀쩡히 돌아갔습니다. 그런데 3개월 뒤 같은 코드를 다시 열었을 때, 어디가 본문이고 어디가 사이드바인지 파악하는 데 꽤 오래 걸렸습니다. 태그 이름에 정보가 없으니 변수명만 보고 맥락을 유추해야 했습니다.
시맨틱 태그(Semantic Tag)란 태그 이름 자체가 콘텐츠의 역할을 설명하는 HTML 요소를 말합니다. header, nav, main, aside, footer 같은 태그가 여기 해당하고, div나 span처럼 아무 의미 없이 영역만 구분하는 태그와 구별됩니다. HTML Living Standard 명세에서는 section, article, aside, nav 각각의 쓰임을 명확하게 정의하고 있습니다(출처: WHATWG HTML Living Standard).
처음에 article과 section 구분이 정말 헷갈렸습니다. "독립적으로 배포 가능한 콘텐츠가 article이다"라는 설명을 열 번 읽어도 감이 안 왔습니다. 제가 결국 이해한 방식은 이렇습니다. article은 그 덩어리만 잘라서 다른 곳에 붙여도 의미가 통하는 것이고, section은 다른 내용과 묶여야 의미가 완성되는 것입니다. 블로그 포스팅 하나는 어디서 봐도 그 자체로 내용이 있으니 article이고, 그 포스팅 안의 소챕터는 포스팅 전체 맥락이 있어야 의미가 통하니 section입니다. 이렇게 생각하니 헷갈림이 많이 줄었습니다.
WAI-ARIA(Web Accessibility Initiative - Accessible Rich Internet Applications)와의 연결도 짚고 넘어갈 필요가 있습니다. WAI-ARIA란 스크린 리더 같은 보조 기술이 웹 콘텐츠를 올바르게 해석하도록 도와주는 기술 명세입니다. 시맨틱 태그를 쓰면 별도의 ARIA 속성 없이도 스크린 리더가 각 영역의 역할을 파악할 수 있습니다. W3C의 HTML 접근성 매핑 문서에 따르면 nav 태그는 자동으로 navigation 역할을 부여받고, main 태그는 main 역할로 스크린 리더에 전달됩니다(출처: W3C HTML Accessibility API Mappings). 접근성이 올라가면 Lighthouse 점수가 올라가고, 이것이 SEO에 간접적으로 연결되는 경로입니다.
시맨틱 태그로 구조를 정리한 뒤 Lighthouse를 다시 돌려보니 접근성 항목 점수가 눈에 띄게 올랐습니다. Lighthouse의 SEO 감사 항목은 meta 태그, 구조화 데이터, 그리고 문서 구조의 논리성을 함께 봅니다. 제가 직접 확인해보니 시맨틱 구조가 잡혀 있을 때 관련 항목에서 경고가 사라졌습니다.
시맨틱 태그를 쓸 때 주의해야 할 점을 정리하면 다음과 같습니다.
- article: 블로그 포스팅, 뉴스 기사처럼 단독으로 의미가 통하는 콘텐츠에 사용
- section: 포스팅 내 소챕터처럼 전체 맥락과 묶여야 의미가 완성되는 구역에 사용
- nav: 사이트 전체 메뉴, 주요 카테고리 탐색처럼 핵심 내비게이션 블록에만 사용
- aside: 본문과 관련은 있지만 독립적으로 분리 가능한 사이드바, 광고 영역에 사용
- main: 페이지당 하나만 쓰고, 반복되는 헤더나 푸터 영역은 포함하지 않음
크롤러가 본문을 못 찾으면 SEO도 없습니다
애드센스 첫 신청이 거절됐을 때 저는 콘텐츠 분량 문제겠거니 했습니다. 그런데 소스를 다시 뜯어보니 main 태그가 아예 없었습니다. 광고 자리, 사이드바, 본문이 같은 div 레벨에 나란히 쌓여 있는 구조였습니다. 크롤러 입장에서는 어디가 진짜 본문인지 파악하기 어려운 상황이었습니다.
크롤러(Crawler)란 검색 엔진이 웹페이지 내용을 수집하고 색인(인덱싱)하기 위해 자동으로 사이트를 탐색하는 프로그램입니다. 구글의 크롤러인 Googlebot은 HTML 구조를 분석해 어느 영역이 본문인지, 어느 영역이 반복 요소인지 구분하려고 합니다. 이때 시맨틱 태그가 명확하게 잡혀 있으면 크롤러가 main 영역을 빠르게 식별하고 핵심 콘텐츠에 집중할 수 있습니다.
인덱싱(Indexing)이란 크롤러가 수집한 페이지 내용을 검색 결과에 반영할 수 있도록 데이터베이스에 등록하는 과정입니다. 구조가 불분명한 페이지는 인덱싱 품질이 낮아질 수 있고, 이것이 검색 노출에 영향을 줄 가능성이 있습니다. 직접 인과를 단정하기는 어렵지만, 시맨틱 구조 정리 이후 애드센스 재신청에서 결과가 달라진 것을 경험했습니다.
한 가지 더 짚을 부분이 있습니다. nav 태그를 처음 쓸 때 저는 소셜 공유 버튼 묶음, 관련 글 목록, 카테고리 링크 전부에 nav를 붙였습니다. 나중에 알고 보니 nav는 사이트의 주요 탐색 블록에만 써야 하는 태그였습니다. 소셜 버튼이나 관련 글 목록은 nav가 아니라 ul이나 div로 처리하는 것이 맞습니다. 잘못 쓰면 구조를 더 망친다는 것을 직접 겪고 나서야 알았습니다.
시맨틱 태그가 SEO를 직접 올려준다는 주장에는 동의하기 어렵습니다. 구글은 시맨틱 HTML 사용 여부를 랭킹 직접 요소로 공식 발표한 적이 없습니다. 콘텐츠 품질이 나쁜데 div를 header로 바꾼다고 갑자기 검색 순위가 오르지는 않습니다. 실제로 div가 잔뜩인 블로그가 시맨틱 태그를 완벽하게 적용한 블로그보다 검색 순위가 높은 경우를 봤는데, 이유는 단순했습니다. 콘텐츠가 좋았기 때문입니다.
그런데 간접적인 경로는 분명히 존재합니다. 접근성 향상 → Lighthouse 점수 개선, 크롤러의 본문 식별 용이 → 인덱싱 품질 향상, 이 두 가지가 쌓이면 결국 SEO에 긍정적 영향을 줄 수 있다는 논리는 타당합니다. 직접이냐 간접이냐의 차이입니다.
시맨틱 태그는 기본기입니다. 기본기를 갖춘 상태에서 좋은 콘텐츠가 나와야 의미가 있습니다. HTML 구조를 아무리 완벽하게 짜도 글 자체가 부실하면 아무 의미가 없습니다. 순서를 바꾸면 안 됩니다.
구조 정리부터 시작하되, 거기서 멈추면 안 됩니다. 시맨틱 태그는 기반을 닦는 일이고, 그 위에 좋은 콘텐츠를 쌓는 것이 본게임입니다. 지금 당장 소스를 열어서 div 개수를 세어보십시오. header, nav, main, aside, footer 중 없는 태그가 있다면 그게 시작점입니다. 작은 구조 정리가 코드 유지보수와 협업 효율부터 달라지게 만든다는 것, 제가 직접 경험한 가장 확실한 변화였습니다.
참고: W3C HTML Living Standard (시맨틱 요소 공식 명세) https://html.spec.whatwg.org/multipage/sections.html
MDN Web Docs - HTML 시맨틱 요소 https://developer.mozilla.org/ko/docs/Glossary/Semantics
Google Search Central - HTML 기반 구조화 데이터 https://developers.google.com/search/docs/crawling-indexing/special-tags
Google Lighthouse SEO 감사 항목 https://developer.chrome.com/docs/lighthouse/seo/
W3C HTML 접근성 매핑 (WAI-ARIA) https://www.w3.org/TR/html-aam-1.0/
WebAIM - 시맨틱 구조와 접근성 https://webaim.org/techniques/semanticstructure/