llms.txt를 설치했습니다. JSON-LD도 11개의 스키마를 넣었습니다. SOV(Share of Voice)도 올라갔습니다.

그럼에도 Perplexity는 자신의 사이트를 인용해 주지 않습니다. ChatGPT의 답변에도 URL은 나오지 않습니다. 3개월 동안 로그를 계속 기록해 온 끝에, 저는 마침내 「구현해도 인용되지 않는 구조적인 이유」가 있다는 사실을 깨달았습니다.

본 기사는 본문의 명확한 설계에 관한 이야기가 아닙니다. llms.txt / JSON-LD를 구현 완료한 사이트가 그럼에도 인용되지 않는 **구조적 병목 현상 (Structural Bottleneck)**의 실측 기록입니다.

저는 이전에 「ChatGPT에 인용되지 않는 5가지 이유」라는 기사에서, 원인을 전부 수정했더니 3주 만에 인용되기 시작한 경험을 썼습니다. 하지만 본 기사는 그 속편입니다. 원인을 전부 수정한 '후'에도 남는, 한 단계 더 깊은 병목 현상에 관한 이야기입니다.

구현 완료했음에도 인용되지 않는다 ── 3개월간의 관측

저는 2026년 3월에, 자신의 회사 사이트에 6가지 LLMO(Large Language Model Optimization) 시책을 한꺼번에 도입했습니다.

• llms.txt와 llms-full.txt 모두 도입
• JSON-LD 11개 스키마 (Organization / Person / Book / Service / FAQPage 등)
• URL.md 패턴으로 모든 페이지의 Markdown 버전 배포
• robots.txt에서 GPTBot / ClaudeBot / Google-Extended를 명시적으로 Allow
• /ai/ 디렉토리에 전용 Markdown 정보 배치
• 33개의 Playwright 테스트로 LLMO 대응을 CI 게이트화

3개월이 경과한 시점에서, 다음과 같은 실측 결과가 남았습니다.

SOV는 4배 가까이 성장했습니다. 하지만 Perplexity의 인용은 10개 질문 중 1개 질문밖에 움직이지 않았습니다.

숫자를 나열했을 때, 저는 이렇게 생각했습니다. llms.txt와 JSON-LD는 「필요조건」이었지만, 「충분조건」은 아니었다고 말입니다.

중심 명제 ── 인용률을 결정하는 것은 「구현」이 아니라 「엔티티 (Entity)」

3개월간의 관측을 통해 제가 도출한 명제는 다음 한 문장으로 요약됩니다.

인용률을 결정하는 것은 llms.txt도 JSON-LD도 아닙니다. 두 가지가 가리키는 대상인

엔티티 (Entity)가 1차 소스(Primary Source)로 인지되고 있는가

이것이 결정적인 요인입니다.

llms.txt는 「내 사이트에는 이런 정보가 있습니다」라는 가이드입니다. JSON-LD는 「이 정보는 이런 의미입니다」라는 구조화입니다. 하지만 둘 다, 그 엔티티 자체가 신뢰할 가치가 있는가라는 질문에는 답하지 않습니다.

Perplexity나 ChatGPT는 인용원을 선택할 때 「1차 소스로 인지되는 엔티티」를 우선합니다. 구현이 잘 되어 있는 것만으로는 통과점에 불과하며, 선택되는 기준은 그 너머에 있습니다.

그 병목 현상은 제 관측 결과 3가지로 나뉘었습니다.

병목 현상 1: 엔티티 인지 ── 지목될 재료가 없다

1차 소스로 인지되기 위해서는 AI가 「이 토픽에 대해서는 이 사람/회사/서적이 권위자이다」라고 연결할 수 있어야 합니다. JSON-LD의 Person 스키마에 knowsAbout을 나열하는 것만으로는 부족합니다.

제 Person 스키마에는 다음과 같이 적혀 있었습니다.

{
"@type": "Person",
"name": "井本 賢",
...

하지만 이 기술만으로는 Perplexity가 「井本 賢이라는 사람이 LLMO 전문가이다」라는 인지를 형성할 수 없었습니다.

제가 나중에 추가한 실측 기반의 조정 사항은 다음 3가지입니다.

• knowsAbout의 각 항목에 대해, 외부 인용이 최소 2개 이상 있는 토픽만 남길 것
• sameAs에 Zenn / Qiita / GitHub / LinkedIn / X 5개를 갖출 것
• Person과 Organization을 worksFor로 명시적으로 연결할 것

세 번째 항목이 의외로 효과적이었습니다. sameAs만으로는 「다른 플랫폼에 동명이인 계정이 있다」 정도까지만 전달됩니다. 하지만 worksFor로 회사를 연결하면, AI는 「이 개인 = 이 회사 = 이 토픽」이라는 삼각형을 인식할 수 있습니다.

병목 현상 2: Retrieval Signals ── 질문 문구와 사이트 언어의 불일치

두 번째 병목 현상은 질문 문구와 사이트 언어의 불일치였습니다.

저는 제 사이트에 「LLM 최적화」라고 적어 두었습니다. 하지만 사용자가 Perplexity에 던지는 질문은 「AI에 인용되는 사이트 만드는 법」이었습니다. 이 두 가지는 같은 내용을 서로 다른 어휘로 말하고 있는 것입니다.

Perplexity의 리랭킹 (Reranking)은 질문 문구와 페이지의 n-gram 일치뿐만 아니라, **세만틱한 근접도 (Semantic Proximity)**도 확인합니다. 하지만 완전히 다른 어휘를 사용할 경우, 리랭킹 상위에 오르지 못하는 경우가 있습니다.

제가 조정한 것은 다음 3가지입니다.

사이트 측의 정보량이 늘어난 것은 아닙니다. 단지 「독자가 실제로 사용하는 언어」에 맞추었을 뿐입니다.

llmoframework.com은 Knowledge Clarity의 5요소로 구조, 어휘, 참조, 권위, 업데이트 빈도를 꼽고 있습니다. 이 5요소 중 제가 3개월 동안 놓치고 있었던 것은 「어휘」였습니다.

병목 현상 3: 일차성 (Primariness) ── 원천 소스로 선택되는 것

세 번째는 제 관측 결과 가장 움직이기 어려운 병목 현상이었습니다.

Perplexity가 인용 소스를 선택할 때, 동일한 정보가 여러 곳에 있다면 「출처를 추적할 수 있는 쪽」을 우선합니다. 제 사이트에 「Claude Code의 스킬 설계는 3층 구조로 작성한다」라고 적더라도, Anthropic의 공식 문서에 동일한 취지의 내용이 있다면 인용은 Anthropic으로 향합니다.

이는 어쩔 수 없는 일입니다. 일차 소스 (Primary Source)로 선택되기 위해서는 다음 중 하나가 필요했습니다.

• 일차 관측 (Primary Observation): 직접 측정한 수치를 제시 (3개월간 100건의 로그, 실측 매트릭스 등)
• 일차 정의 (Primary Definition): 아무도 사용하지 않는 용어를 처음으로 정의
• 일차 사례 (Primary Case Study): 자신만이 경험한 구체적인 실패와 개선 사례를 기술

제 기사 중 Perplexity가 인용해 준 것은 이 세 가지 중 하나를 담고 있는 기사뿐이었습니다. 「일반적인 해설」을 작성한 기사는 구현이 잘 되어 있더라도 인용이 0건이었습니다.

구현 단계 × 인용률 매트릭스

3개월간의 관측을 통해 저는 다음과 같은 매트릭스를 그릴 수 있게 되었습니다. llms.txt와 JSON-LD의 구현 단계를 곱한, Perplexity 인용률의 변화입니다.

이 매트릭스에서 읽을 수 있는 점은 다음 3가지입니다.

• 구현 단계 0과 최대 단계 사이에서 인용률은 0%에서 10%로 상승한다 (성장은 제한적)
• llms.txt만 정비해도 JSON-LD가 없다면 5%를 넘지 못한다
• 구현 단계가 최대라 하더라도, 기사 측에서 일차 소스를 보유하지 않으면 10%에서 정체된다

즉, 구현은 10%라는 천장을 만드는 데까지만 효과가 있으며, 나머지 성장 잠재력은 기사의 종류에 달려 있습니다.

인용 로그를 남기는 법 ── 여기서부터 시작하세요

세 가지 병목 현상을 논하기 위한 전제로 인용률 측정이 필요합니다. 제가 운영하고 있는 최소한의 측정 절차를 적어둡니다.

Stage 1: 프롬프트 라이브러리 고정하기

10개에서 15개의 질문을 고정합니다. 회사명, 본인 이름, 서적명, 전문 토픽을 섞습니다. 질문 문구는 실제 독자가 던질 법한 자연어로 작성합니다.

Stage 2: 주 단위로 3개 엔진에 던지기

ChatGPT search / Perplexity / Google AI Overviews 세 곳에 매주 동일한 질문을 던집니다. 개인화(Personalization)를 배제하기 위해 시크릿 모드나 새 세션을 사용합니다.

Stage 3: 인용 여부와 종류 기록하기

인용은 세 가지 유형으로 나누어 기록합니다.

• 직접 인용: URL이 출처로 표시됨
• 정보 반영: URL은 나오지 않지만, 사이트 고유의 정보 (설립일, 독자적 정의, 실측 수치)가 답변에 포함됨
• 간접 효과: Zenn / Qiita 등 다른 플랫폼을 경유하여 정보가 사용됨

세 가지를 나누어 계산하면, 「구현은 효과가 없지만 간접 효과는 늘어나고 있다」와 같은 중간 상태를 확인할 수 있습니다.

3가지 병목 현상 자가 진단 체크리스트

3개월간의 관측을 바탕으로, 제가 스스로에게 던지는 9가지 체크 항목을 남겨둡니다.

병목 현상 1 (엔티티 인지)

• Person 스키마의 knowsAbout이 외부 인용이 2개 이상 있는 토픽으로만 한정되어 있는가
• sameAs가 주요 5대 플랫폼을 모두 갖추고 있는가
• Person과 Organization을 worksFor로 연결했는가

병목 현상 2 (Retrieval Signals)

• H1은 "독자가 실제로 검색창에 입력할 단어"로 작성되었는가
• llms-full.txt의 서두 200자가 독자의 페인 포인트 (Pain Point) 언어로 시작되는가
• FAQPage의 Question은 독자 측의 어휘로 작성되었는가

병목 현상 3 (일차성/독창성)

• 기사는 직접 측정한 수치를 보유하고 있는가
• 기사는 자신만이 정의한 용어나 프레임워크를 가지고 있는가
• 기사는 자신의 실패와 개선을 타인의 글을 베끼는 것이 아니라 스스로 작성했는가

9가지 항목 중 구현 (병목 현상 1)만이 기술로 해결할 수 있는 영역입니다. 나머지 6개 항목은 작성 방식과 관측으로 해결해야 하는 영역이었습니다.

30일 개선 플랜의 기준

제가 실제로 실행했던 30일간의 개선 사이클을 그대로 남깁니다.

이 30일 안에 모든 것을 해결할 수는 없습니다. 다만 "구현은 입장권"이며, 그 너머에 몇 단계의 벽이 있는지는 이 순서를 통해 확인할 수 있게 됩니다.

요약

3개월간의 관측을 통해 제가 얻은 것은 다음 3가지입니다.

• llms.txt와 JSON-LD를 모두 넣으면 SOV는 늘어나지만, Perplexity의 인용률은 10%에서 정체되었습니다.
• 인용률을 결정하는 것은 엔티티 인지(Entity Recognition) · Retrieval Signals · 일차성(Originality)의 3가지이며, 구현은 첫 번째 요소에만 효과가 있었습니다.
• 나머지 2가지는 작성 방식과 관측으로 해결해야 하는 영역이며, 기사의 종류를 바꾸지 않으면 구현만으로는 넘을 수 없었습니다.

llms.txt를 넣는 작업은 하루면 끝납니다. 하지만 인용되는 사이트가 되기 위한 본게임은 그 하루가 끝난 다음 날부터 시작됩니다.

관련 나의 기사

• ChatGPT가 내 사이트를 인용하지 않는 5가지 이유: 전부 수정했더니 3주 만에 나타났다
• Retrieval Signals를 설계하기 ── AI가 인용하고 싶어 하는 본문 5가지 구조
• llms.txt 다음에 올 URL.md 패턴 ── AI에게 읽히는 제2의 웹을 만드는 법
• SOV가 높은데 AI에게 선택받지 못한다? LLMO 2대 지표 SOV와 SOM의 결정적인 차이

Knowledge Clarity의 5요소에 대해서는 LLMO Framework의 공식 문서가 가장 잘 정리되어 있습니다.

Discussion