내부 링크 구조가 AI 인용에 미치는 영향

Google AI Overviews·Perplexity·ChatGPT Search는 문서를 개별 URL 단위로 처리하지 않는다. 크롤러가 수집한 페이지 그래프를 바탕으로 RAG 파이프라인이 토픽 클러스터를 식별하고, LLM이 인용 후보를 선택할 때 해당 클러스터 내 권위 노드(hub)를 우선 참조한다. 내부 링크 구조는 이 그래프에서 노드 간 엣지를 정의한다 — 엣지가 없으면 클러스터도 없고, 클러스터가 없으면 AI 인용 풀 진입도 없다.

크롤 그래프에서 내부 링크가 하는 역할

클릭 깊이와 크롤 커버리지

GPTBot·ClaudeBot·Google-Extended 등 AI 크롤러는 robots.txt를 준수하며 BFS(너비 우선 탐색) 방식으로 사이트를 수집한다. 홈페이지(depth 0)에서 링크를 따라 이동하며, 클릭 깊이가 깊어질수록 수집 우선순위가 낮아진다. 사례에 따라 다르지만 클릭 깊이 4 이상 URL은 주요 AI 크롤러의 재방문 주기가 현저히 길어지는 경향이 관측된다.

• 핵심 콘텐츠는 depth 3 이내 배치 — 왜: 깊이 증가 시 수집 빈도 감소로 AI 인용 풀에서 제외될 위험. 어떻게: pillar 페이지에서 cluster 페이지로 1-클릭 이내 도달하도록 내비게이션 구조 재설계.
• 고아 페이지(orphan page) 제거 — 왜: 내부 링크가 없는 URL은 크롤 그래프에서 단절 노드로 남아 클러스터 신호를 받지 못함. 어떻게: Screaming Frog·Sitebulb로 in-link count=0 페이지 추출 후 관련 cluster에 연결.
• XML Sitemap priority 값 내부 링크 밀도와 일치 — 왜: 크롤러가 priority를 색인 빈도 힌트로 사용하며, pillar 페이지가 높은 in-link 수를 보유함에도 priority=0.5이면 신호 불일치 발생. 어떻게: in-link 수가 10개 이상인 페이지는 priority 0.8 이상 부여.

허브-앤-스포크 클러스터 구조 구현

토픽 클러스터 모델은 pillar 페이지(허브)가 관련 세부 페이지(스포크)를 양방향으로 연결하는 구조다. 이 구조가 AI 인용에 유리한 이유는 크롤러가 클러스터 전체를 한 토픽의 권위 블록으로 인식하기 때문이다.

1. Pillar 페이지 선정 — 가장 포괄적인 개요 문서를 pillar로 지정. 왜: LLM이 토픽 전체를 커버하는 단일 문서를 인용 기준점으로 삼는 경향. 어떻게: 2,000자 이상 포괄 콘텐츠 + cluster 페이지 전체 링크 색인.
2. 양방향 링크 강제 — cluster → pillar, pillar → cluster 모두 배치. 왜: 단방향 링크만 있으면 그래프 엣지가 단절되어 클러스터 신호가 반감됨. 어떻게: CMS 템플릿에 "관련 주제" 자동 링크 블록 삽입.
3. BreadcrumbList JSON-LD 삽입 — 왜: 크롤러가 페이지의 계층 위치를 명시적으로 파악하게 해 클러스터 그래프 해석 정확도를 높임. 어떻게: 아래 예시와 같이 모든 cluster 페이지에 삽입.

{
  "@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/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "내부 링크 전략",
      "item": "https://example.com/seo/internal-linking/"
    }
  ]
}

이 마크업은 Google Rich Results Test에서 검증 가능하며, position 순서와 item URL이 실제 사이트 계층 구조와 일치해야 한다. 불일치 시 구조화 데이터 경고가 발생한다.

앵커 텍스트와 LLM 의미 신호

앵커 텍스트는 SEO에서 링크 타겟의 주제를 크롤러에 전달하는 신호다. RAG 파이프라인에서는 LLM이 청크 임베딩 시 앵커가 속한 문장의 맥락을 함께 처리해 링크된 페이지의 의미 표현에 영향을 미친다(추정, 공식 확인 없음).

• 키워드 포함 기술적 앵커 사용 — 왜: "여기를 클릭"류 앵커는 의미 신호가 없음. 어떻게: "내부 링크 최적화 방법론"처럼 타겟 페이지의 핵심 키프레이즈를 앵커에 삽입.
• 앵커 다양성 유지 — 왜: 완전 동일한 앵커 반복은 스팸 패턴으로 분류될 위험. 어떻게: 같은 타겟에 연결하는 앵커를 2~3가지 변형으로 운영.
• 앵커 주변 문장 최적화 — 왜: LLM 청크 분할 시 앵커 앞뒤 50~100 토큰이 같은 청크에 포함되며, 링크 직전 문장이 타겟 개념을 설명하면 임베딩 품질이 향상될 수 있음(추정). 어떻게: 링크 앞에 타겟 페이지를 한 문장으로 요약 삽입.

내부 링크 구조 검증과 AI 인용 측정

• Search Console 색인 커버리지 추적 — 내부 링크 재구성 후 새로 색인된 URL 수와 Discovered not indexed 변화를 모니터링. 색인률이 AI 크롤 커버리지와 상관관계가 높은 것으로 추정된다.
• AI 인용 직접 추적 — Perplexity·ChatGPT에 타겟 쿼리를 입력해 도메인 인용 여부와 인용된 URL의 cluster 소속 확인. 주 1회 대표 쿼리 20~30개를 수동 또는 스크립트로 체크.
• 크롤 로그 분석 — 서버 access log에서 AI 크롤러 User-Agent 필터링 후 cluster별 수집 빈도 비교. 예시: grep -E "GPTBot|ClaudeBot|Google-Extended" access.log | awk '{print $7}' | sort | uniq -c | sort -rn

신호 유형별 내부 링크 역할 비교

흔한 오해: "내부 링크는 많을수록 좋다"

한 페이지에 내부 링크를 수십 개 배치하면 PageRank가 분산되어 개별 타겟 페이지가 받는 권위가 희석된다. LLM 관점에서는 링크 밀도가 지나치게 높은 페이지가 청크 분할 시 핵심 본문 비율이 낮아져 임베딩 품질이 저하될 수 있다. 또한 앵커가 의미 없이 반복되면 크롤러가 스팸 패턴으로 분류할 위험도 있다.

올바른 처리법: 본문 500자당 내부 링크 1~3개로 제한하고, 각 링크는 해당 섹션의 핵심 주제와 직접 관련된 타겟에만 배치한다. 내비게이션·사이드바·푸터 링크는 본문 링크 수 계산에서 분리하며, pillar↔cluster 연결 외의 cross-link는 사이트맵 수준에서 사전 설계한 후 삽입한다.

참고 자료

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

• Google 검색 센터 — SEO 기본 가이드
• Google — 구조화 데이터 마크업 & 리치 결과
• Schema.org — 구조화 데이터 시작하기