잘 쓴 글을 어디에 둘 것인가: GEO 발행 전략

GEO 가이드를 따라 글을 한 편 잘 만들었다고 해보겠습니다. 질문, 직답, 근거의 3단 구조로 짜고 출처와 수치를 붙인 데다 FAQ 스키마까지 얹었는데요. 그런데 자사 블로그에 올리고 며칠 기다린 뒤 ChatGPT와 Perplexity에 업계 질문을 던져보면, 답변에는 여전히 경쟁사 이름만 나오고 우리는 빠져 있곤 합니다. 글이 나쁜 게 아닙니다. 글이 한 곳에만 있는 게 문제입니다.

대부분의 GEO 조언은 "어떻게 쓰는가"에서 멈춥니다. 하지만 잘 쓴 글의 운명은 그다음에 갈립니다. 같은 글을 어디에 두는지, 몇 개의 표면에 어떤 모습으로 펼쳐 놓는지가 인용 여부를 가르기 때문입니다. 그래서 이 글은 글쓰기 다음 단계인 발행 전략을 다룹니다.

자기 사이트 한 곳으로는 왜 부족한가

AI가 답을 만들 때 우리 콘텐츠를 만나는 경로는 크게 두 갈래입니다. 하나는 모델이 학습 과정에서 본 정보이고, 다른 하나는 답을 만드는 순간 실시간으로 검색해 끌어오는 정보입니다. 어느 쪽이든 공통으로 나타나는 경향이 있는데요. 같은 사실이 여러 출처에서 반복될수록 모델이 그것을 더 신뢰하는 쪽으로 답을 구성한다는 점입니다.

여기서 자사 도메인 한 곳의 한계가 드러납니다. 우리 사이트에서 "우리 제품이 이 분야 1위"라고 아무리 잘 써도, 모델이 보기엔 한 회사가 자기 자신을 두고 한 번 한 주장일 뿐입니다. 함께 비교할 다른 출처가 없는 셈입니다. 잘못 인용하면 답이 틀릴 수 있다 보니, 모델은 단일 출처의 자기 주장을 답에 그대로 넣기를 꺼리는 편입니다.

식당으로 짧게 빗대면 이렇습니다. 사장이 직접 "우리 집이 이 동네 최고"라고 말하면 그건 광고입니다. 하지만 음식 블로거와 지역 매체와 비교 사이트가 각자 다른 각도에서 같은 결론에 닿으면, 그제야 사실에 가까워 보입니다. 모델도 비슷하게 움직이는 것으로 보이는데요. 여러 독립된 출처가 같은 결론을 가리킬 때 인용이 일어나는 이 현상을 흔히 엔티티 합의(Entity Consensus)라고 부릅니다.

핵심 단어는 "독립된"입니다. 같은 글을 복사해 여러 사이트에 붙여 넣는 것은 독립 출처가 아니기 때문입니다. 모델과 검색엔진은 중복 콘텐츠를 알아보고 한 덩어리로 묶으므로, 똑같은 글 50개도 결국 1개의 출처로만 셈해집니다. 합의는 표면의 개수가 아니라 관점의 다양성에서 나옵니다.

다도메인 분산이란 무엇인가

다도메인 분산은 하나의 엔티티를 중심에 두고, 성격이 서로 다른 여러 표면이 각자의 관점으로 그 엔티티를 다루게 하는 전략입니다. 중심이 되는 자사 도메인은 그대로 두고, 그 주위에 결이 다른 표면들을 함께 배치하는 식입니다.

중요한 것은 표면마다 정체성이 달라야 한다는 점입니다. 전문가 분석 매체, 동네 생활 가이드, 비교 리뷰 사이트, 사용자 경험담 블로그는 같은 사실을 다뤄도 제목과 구조, 톤, 강조점, 독자가 전부 다릅니다. 사실은 같고 관점만 다른 글이 여러 표면에 쌓일 때, 그것이 바로 모델이 찾는 독립 합의에 가까워집니다.

같은 엔티티를 다루는 두 글이 어떻게 갈라지는지 예를 들어보겠습니다. 어느 치과를 다룬다고 하면 표면에 따라 이렇게 달라질 수 있습니다.

엔티티에 관한 사실, 즉 이름과 위치, 가격, 수치는 모든 표면에서 한 글자도 다르지 않아야 합니다. 사실이 흔들리면 합의가 아니라 혼란이 되기 때문입니다. 다르게 가져가는 것은 사실이 아니라, 그 사실을 둘러싼 맥락과 관점이어야 합니다.

흔적(footprint)을 흩어야 하는 이유

다도메인 분산에서 가장 흔한 실패는 모든 표면이 똑같이 생기는 경우입니다. 같은 템플릿과 같은 발행 시각이 반복되고, 문장 패턴과 내부 링크 구조까지 닮으면, 모델이나 검색엔진은 이것을 한 주체가 운영하는 묶음으로 읽기 쉽습니다. 그렇게 묶이는 순간 여러 표면의 신뢰 가중치가 한꺼번에 깎일 수 있습니다.

그래서 표면을 늘릴 때는 흔적을 의도적으로 흩어 두는 게 안전합니다. 발행 시각을 다르게 하고, 글의 길이와 구조를 바꾸고, 도메인마다 다른 보이스로 쓰는 식입니다. 다양성은 합의의 조건일 뿐 아니라, 여러 표면이 서로 독립적으로 보이기 위한 조건이기도 합니다.

빠른 인덱싱: IndexNow와 크롤 가능성

아무리 좋은 글을 펼쳐 놓아도, 모델이 답을 만드는 순간 그 글이 검색 인덱스에 없으면 실시간 인용 경로에서는 존재하지 않는 것과 같습니다. GEO에서 인덱싱 속도가 중요한 이유입니다. 글을 발행하고 검색엔진이 알아서 발견하기를 기다리면 며칠에서 몇 주가 걸리는데, 그사이 경쟁사가 같은 질문의 답을 선점할 수 있습니다.

IndexNow는 이 지연을 줄이려는 프로토콜입니다. 페이지를 발행하거나 수정하는 즉시 검색엔진에 "이 URL을 지금 확인하라"고 직접 알리는 방식입니다. 크롤러가 우리 사이트를 다시 방문할 때까지 기다리는 대신, 발행 시점에 능동적으로 통보하게 됩니다. 펼쳐 놓은 표면이 많을수록 발행과 인덱싱 사이의 지연을 줄이는 일은 더 중요해집니다.

인덱싱 이전에 점검할 더 기본적인 층도 있는데요. 모델과 크롤러가 애초에 우리 페이지에 접근할 수 있어야 한다는 점입니다.

• robots.txt: AI 봇 크롤링을 막고 있지 않은지 확인합니다. 인용을 원한다면 모델이 먼저 읽을 수 있어야 하기 때문입니다.
• 렌더링: 핵심 콘텐츠가 자바스크립트 실행 후에야 나타나면 일부 크롤러는 빈 페이지를 볼 수 있습니다. 그래서 본문은 처음부터 HTML에 담겨 있는 게 안전합니다.
• 응답 속도: 발행한 글이 빠르게 응답할수록 크롤러가 더 깊이, 더 자주 가져가는 경향이 있습니다.
• llms.txt: 사이트 루트에 핵심 페이지로 가는 지도를 두어, 모델이 헤매지 않도록 안내하는 보조 수단입니다.

AI가 신뢰하는 외부 표면

우리가 직접 통제하는 표면 바깥에는, 우리가 만들지 않았지만 모델이 자주 인용하는 신뢰 풀이 따로 있습니다. 백과형 위키, 업계 매체, 커뮤니티, 디렉터리, 비교 사이트가 그렇습니다. 우리 사이트를 한 번도 읽지 않은 모델이라도, 이런 표면에 담긴 정확한 우리 정보를 통해 우리를 근거로 끌어 쓸 수 있습니다.

여기서 챗봇과 검색형 답변의 차이를 나눠서 봐야 하는데요. 둘은 인용 표면이 다르게 작동하는 것으로 관찰되기 때문입니다.

• 챗봇(ChatGPT 등): 학습된 지식과 실시간 검색을 섞어 답하다 보니, 모델이 학습 단계에서 자주 본 표면, 즉 오래되고 널리 인용되는 신뢰 풀의 비중이 상대적으로 큰 편입니다.
• Google AI Overview: 검색 결과를 기반으로 답을 구성하는 표면이라, 지금 이 순간 검색 인덱스에서 상위에 있고 신선한 페이지가 더 잘 반영되는 경향이 있습니다. 그래서 인덱싱 속도와 직접 연결됩니다.

그래서 외부 표면 공략의 출발점은 추측이 아니라 관찰이어야 합니다. 우리 업계 질문을 실제로 던졌을 때 챗봇과 AI Overview가 각각 어떤 출처를 인용하는지 보면, 답변에 붙는 출처 목록이 곧 공략 대상 리스트가 됩니다. 그러면 그 표면에 담긴 우리 정보가 정확한지 점검하고, 비어 있는 질문 영역을 정확한 정보로 채우면 됩니다. 광고가 아니라 실제로 도움이 되는 정보여야 한다는 원칙은 여기서도 같습니다.

발행은 끝이 아니라 측정의 시작이다

표면을 갖추고 흩어서 발행하면 일이 끝난 것처럼 보이지만, 발행은 가설을 시장에 던진 시점일 뿐입니다. 어떤 표면의 어떤 관점이 실제 인용으로 이어졌는지는 측정하기 전까지 알 수 없습니다. 그래서 측정 없는 발행은 추측만 빠르게 쌓는 일에 가깝습니다.

발행과 측정을 하나의 루프로 묶으면 흐름은 다음과 같습니다.

1. 측정: 핵심 질문들을 생성형 엔진에 던져 우리와 경쟁사의 인용 현황을 기록하되, 챗봇과 AI Overview를 구분해서 봅니다.
2. 갭 분석: 경쟁사만 인용되는 질문과 우리가 빠진 표면을 추립니다. 여기가 다음 발행의 우선순위가 됩니다.
3. 발행: 그 갭을 메우는 글을 만들어 서로 다른 관점으로 여러 표면에 펼쳐 발행하고, 발행 즉시 인덱싱을 통보합니다.
4. 재측정: 같은 질문을 다시 던져 인용 변화를 확인하면서, 인용으로 이어진 표면과 관점은 키우고 반응 없는 것은 바꿉니다.

루프가 짧을수록 학습이 빨라집니다. 어떤 도메인 톤이, 어떤 앵글이, 어떤 외부 표면이 실제 인용을 만들었는지가 데이터로 쌓이면, 다음 발행은 감이 아니라 근거로 할 수 있기 때문입니다. 다만 생성형 엔진의 알고리즘은 대부분 비공개입니다. 그래서 이 인과를 단정하기보다, 반복 측정으로 드러나는 경향을 근거 삼는 자세가 현실적입니다.

실행 체크리스트

발행 전략의 어려움은 개념이 아니라 운영에 있습니다. 관점이 다른 글을 여러 도메인에 맞춰 만들고, 흔적을 흩어 발행하고, 인덱싱을 통보하고, 발행한 글이 인용으로 이어졌는지 챗봇과 AI Overview에서 각각 재측정하는 일을 수작업으로 돌리면 금세 버거워지기 때문입니다. 넛지오는 그 인용 현황을 먼저 확인하는 데서 출발하도록 돕습니다.