콘텐츠 클러스터(토픽 허브)로 권위 쌓기

콘텐츠 클러스터(Content Cluster)는 광범위한 주제를 다루는 허브(Pillar) 페이지와 세부 하위 주제별 스포크(Cluster) 페이지를 양방향 내부 링크로 연결한 토픽 그래프 구조다. Google의 PageRank 기반 권위 전파 메커니즘에서 외부 백링크를 허브 한 곳에 집중시키면 스포크로 권위가 분배되고, 스포크의 역링크가 허브를 재강화하는 자기강화 루프가 형성된다. LLM 기반 답변 엔진(AI Overviews, Perplexity)이 인용 후보를 결정할 때는 RAG 파이프라인이 동일 토픽 신호를 발신하는 페이지 군을 하나의 권위 노드로 처리하는데, 클러스터 구조가 이 신호를 명시적으로 제공한다. 단일 롱폼 전략과 달리, 구조 설계 자체가 랭킹과 AI 인용에 영향을 주는 독립 변수가 됐다.

작동 원리 — PageRank 흐름과 토픽 클러스터 신호

PageRank 집중과 분배: 외부 백링크를 허브 URL 한 곳에 집중시키면 허브의 PageRank가 높아지고, 허브에서 각 스포크로 내부 링크를 걸면 이 권위가 분배된다. 왜: 스포크 개별 페이지가 외부 링크를 받지 못해도 허브 경유로 권위 신호를 얻을 수 있다. 어떻게: 허브 본문에 컨텍스트 앵커 텍스트로 스포크를 연결하고, 스포크 말미에 허브로의 역링크 블록을 표준화한다.
크롤 빈도 우선순위: Googlebot은 내부 링크가 많이 걸린 페이지를 더 자주 크롤한다. 왜: 허브가 N개 스포크의 역링크를 받으면 크롤 빈도가 높아져 콘텐츠 갱신이 더 빨리 색인된다. 어떻게: 모든 스포크 하단에 "관련 가이드: [허브 제목]" 링크 블록을 공통 컴포넌트로 렌더링.
토픽 어휘 일관성: Google의 토픽 모델은 도메인 내에서 동일 어휘 집합을 반복 사용하는 페이지 군을 하나의 토픽 권위 단위로 인식한다. 왜: LSI(잠재 의미 색인) 키워드가 허브-스포크 전체에 일관되게 등장할수록 토픽 신호가 강해진다. 어떻게: 클러스터 착수 전 핵심 토픽 어휘 집합을 문서화하고, 각 페이지 작성 시 참조.
LLM RAG 파이프라인 신호: ChatGPT Search·Perplexity는 크롤한 페이지를 청크 단위로 임베딩해 벡터 DB에 저장한다. 동일 도메인에서 관련 주제 청크가 다수 존재하고 상호 참조 링크까지 있으면, 검색 쿼리에 대해 해당 도메인 청크가 상위 컨텍스트로 선택될 확률이 높아진다(추정). 어떻게: 스포크 본문 내 관련 스포크 간 상호 링크를 삽입해 청크 간 연관성을 텍스트 레벨에서도 명시.

허브-앤-스포크 URL 아키텍처와 구조화 데이터 구현

URL 계층은 크롤러가 클러스터 경계를 파악하는 가장 명시적인 구조 신호다.

계층형 URL 설계: /topic/(허브) → /topic/subtopic-a/, /topic/subtopic-b/(스포크). 왜: URL 경로 공통 접두어가 관련 문서 인식 신호로 작동한다. 어떻게: CMS slug 설계 시 허브 slug를 스포크 경로의 첫 세그먼트로 강제.
BreadcrumbList JSON-LD: 모든 스포크 페이지에 삽입해 크롤러에게 계층 관계를 명시한다. 왜: 브레드크럼 링크는 추가 내부 링크 신호를 생성하고 Rich Result(SERP 경로 표기)에도 반영된다. 어떻게: 아래 예시를 스포크 <head>에 적용.
ItemList JSON-LD (허브 전용): 허브 페이지에 클러스터 멤버 전체를 ItemList로 명시한다. 왜: 크롤러가 클러스터 범위를 HTML 파싱 없이 파악 가능하고, LLM 크롤러에도 구조 신호로 전달된다. 어떻게: 아래 예시 참조.

JSON-LD BreadcrumbList + ItemList 설정 예시

<!-- 허브 페이지 <head> 내 삽입 -->
<script type="application/ld+json">
[
  {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
      { "@type": "ListItem", "position": 1, "name": "홈",        "item": "https://example.com/" },
      { "@type": "ListItem", "position": 2, "name": "SEO 가이드","item": "https://example.com/seo-guide/" }
    ]
  },
  {
    "@context": "https://schema.org",
    "@type": "ItemList",
    "name": "SEO 가이드 — 세부 주제 시리즈",
    "description": "SEO·AEO·GEO 핵심 개념과 실무 구현을 다루는 전문 가이드.",
    "numberOfItems": 3,
    "itemListElement": [
      { "@type": "ListItem", "position": 1,
        "url":  "https://example.com/seo-guide/technical-seo/",
        "name": "기술적 SEO: 크롤링·색인·Core Web Vitals" },
      { "@type": "ListItem", "position": 2,
        "url":  "https://example.com/seo-guide/schema-markup/",
        "name": "스키마 마크업: 어디까지 해야 효과가 있을까" },
      { "@type": "ListItem", "position": 3,
        "url":  "https://example.com/seo-guide/internal-linking/",
        "name": "내부 링크 구조가 AI 인용에 미치는 영향" }
    ]
  }
]
</script>

SEO·AEO·GEO 관점별 클러스터 효과 비교

관점	클러스터가 영향 미치는 신호	핵심 측정 지표	주요 도구
SEO	PageRank 흐름, 크롤 빈도, 토픽 권위 점수	순위 변화, 색인 커버리지, 클릭률	Google Search Console, 서버 액세스 로그
AEO	Featured Snippet 선택 신호, PAA 연결 빈도	제로클릭 노출 수, AI Overviews 인용 횟수	GSC 검색어 리포트, 수동 SERP 확인
GEO	RAG 청크 밀도, 도메인 권위 추론, 인용 다양성	LLM 응답 내 도메인 언급·인용 URL 수	Perplexity 수동 테스트, 브랜드 모니터링

검증과 측정

GSC 토픽 커버리지 확인: Performance 리포트에서 허브 URL 필터 후 유입 쿼리 수를 확인한다. 클러스터가 효과적으로 형성되면 허브 단일 URL로 수십 개의 롱테일 쿼리가 유입된다. 어떻게: [Pages] 탭에서 허브 URL 선택 → [Queries] 탭 전환, 노출 수 기준 정렬 후 4주 변화 추적.
크롤 로그 빈도 분석: 허브 내부 링크 재편 전후로 스포크 페이지의 Googlebot 방문 횟수를 비교한다. 어떻게: grep "Googlebot" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30 으로 URL별 크롤 횟수 추출.
LLM 인용 수동 테스트: 클러스터 핵심 질문을 ChatGPT·Perplexity·Gemini에 입력해 자사 도메인 URL이 인용되는지 확인한다. Perplexity는 소스 URL을 명시해 정량 추적이 가능하다. 어떻게: 허브 토픽의 대표 질문 5개를 표준화해 주 1회 테스트, 스프레드시트에 인용 여부를 기록.

흔한 오해: "허브는 키워드를 빽빽하게 넣은 긴 글"

허브 페이지를 스포크와 동일 키워드를 반복 나열한 롱폼 문서로 설계하는 경우가 많다. 이는 두 가지 문제를 일으킨다. 첫째, 허브와 스포크가 같은 타깃 키워드로 순위를 다투는 내부 카니발라이제이션이 발생해 Google이 어떤 URL을 canonical로 취급할지 모호해진다. 둘째, 허브가 스포크보다 정보 밀도가 높으면 사용자가 스포크로 이동할 유인이 없어 내부 링크 활성화가 저조해지고 클러스터 구조 전체의 체류 신호가 약해진다.

올바른 설계 기준: 허브는 토픽 개요와 '왜 이 문제가 중요한가'를 다루고, 각 스포크는 특정 구현·실행 방법을 독점적으로 담는다. 허브의 각 섹션 뒤에 "구체적 구현 방법 → [스포크 제목]" 명시적 CTА 링크를 배치해 사용자 이동 경로를 설계한다. 키워드 분기도 허브에는 SEO 가이드 전체 개요, 스포크에는 기술적 SEO 크롤링 설정 방법처럼 의도(informational vs instructional)를 분리한다.

허브 1개에 스포크가 몇 개여야 Google이 클러스터로 인식하는가?

공식 기준은 공개되지 않았으나, 실무 사례에서는 스포크 최소 5개 이상 구조가 토픽 권위 신호로 작동한다고 보고된다(사례에 따라 다름). 스포크 3개 이하면 단순 카테고리 페이지로 처리될 가능성이 있다. 반대로 스포크가 15개를 넘으면 허브에서 각 스포크로 전달되는 PageRank가 희석되므로, 스포크 간 상호 링크 또는 중간 서브 허브를 추가해 2단계 계층으로 분산하는 것이 낫다. 예: /seo-guide/(메인 허브) → /seo-guide/technical/(서브 허브) → /seo-guide/technical/crawl-budget/(스포크).

기존 개별 포스트를 클러스터로 재편할 때 URL을 변경해야 하는가?

가능하면 URL 이동을 최소화하는 것이 원칙이다. 기존 URL에 외부 백링크가 이미 쌓여 있다면 301 리다이렉트에서 발생하는 PageRank 손실(추정 10~15%)보다 현 URL 유지 후 내부 링크 재편성만으로 클러스터 효과를 먼저 시도해야 한다. URL 구조가 클러스터 설계와 완전히 불일치하는 경우(예: /blog/12345 번호형)에는 /topic/subtopic/ 구조로 이전하되, 301 리다이렉트 전체 맵을 XML 사이트맵과 함께 관리하고 GSC Coverage 리포트에서 Redirect error 발생 여부를 이전 직후 48시간 내 확인해야 한다.

참고 자료

이 글의 권고는 아래 공식 문서·연구를 근거로 합니다.