AI 검색에 잡히기 위한 GEO 세팅 기준은 결국 사람이 잡아줘야해요

그래서 1인 빌더가 AI 검색 인용을 챙기려면 점검 도구에 기대지 말고 직접 기준을 잡아야 합니다. 핵심은 세 가지로 압축됩니다. 인용 가능한 문장 밀도, JS·로그인 뒤로 본문이 숨지 않는 HTML 노출, 출처와 기준 시점의 명시. 이 세 가지가 갖춰져야 ChatGPT, Perplexity, Google AI Overviews가 본문을 잘라 인용할 확률이 올라갑니다.

주의할 점은 Lighthouse의 Agentic Browsing 항목들을 "GEO 점수"로 오해해 불필요한 곳에 시간을 낭비하지 않는 것입니다. 9개의 검사 항목(audit) 중 사이트맵이나 schema.org 같은 건 도움을 주지만, WebMCP나 agents.json 같은 항목은 결제·예약 등 '작업형 사이트' 전용이라 1인 빌더의 블로그나 뉴스레터에는 우선순위가 크게 떨어집니다.

어려운 기술 용어를 걷어내고, 1인 빌더가 진짜 시간을 써야 할 GEO 세팅법을 처음부터 끝까지 알기 쉽게 정리해 드릴게요.

1. 라이트하우스 13.3의 새 카테고리는 GEO가 아닙니다

Lighthouse 13.3.0은 2026년 5월 7일 정식 출시되면서 "Agentic Browsing" 카테고리를 누구에게나 노출되는 안정 채널에 편입했습니다. 크롬에서 우클릭 → Inspect → Lighthouse 탭을 누르면 바로 확인할 수 있고, PageSpeed Insights에도 반영이 시작됐죠. 아직 실험(Experimental) 단계라 0~100점 대신 통과/실패(pass/fail) 비율로만 보여줍니다.

이 카테고리 등장 후 SEO 업계에서는 "드디어 GEO를 자동으로 채점해 준다"며 들썩였지만, 이는 절반만 맞는 이야기입니다. 이 도구의 목적은 '검색 인용 최적화(GEO)'가 아니라, 'AI 에이전트가 사이트에서 작업을 실행할 때의 준비도(Agentic Browsing)'를 평가하는 것이기 때문입니다.

헷갈리지 않도록 두 영역이 어떻게 다른지 표로 확실히 짚고 넘어갈게요.

표를 보면 아시겠지만, 블로그나 뉴스레터를 운영하는 1인 빌더가 Lighthouse의 새 카테고리를 만점 받는다고 해서 내 글이 AI에 더 많이 인용된다는 보장은 없습니다. 평가하는 기준 자체가 다르니까요. 즉, 진짜 GEO 영역은 우리가 직접 기준을 잡고 챙겨야 합니다. Lighthouse 13.3.0과 Agentic Browsing 카테고리가 정확히 무엇이고 왜 등장했는지, 9개 감사 항목이 각각 어떤 신호를 보는지에 대한 개념은 "라이트하우스 13.3에 새로 생긴 Agentic Browsing 카테고리, 열어보니 이런 게 있었어요"에서 한 번에 정리하고 있습니다.

2. 1인 빌더의 GEO는 결국 사람이 직접 챙겨야 합니다

GEO에서 자동 채점이 어려운 이유는 "이 문장이 다른 글에 잘려 들어가도 의미가 통하는가?" 같은 의미 단위의 판단이 필요하기 때문입니다. 브라우저 점검 도구가 이걸 매번 완벽히 추론해 주기는 현실적으로 어렵습니다.

구글 역시 AI Overviews가 기존 검색 시스템을 기반으로 작동한다고 밝히며, "별도의 꼼수"보다 검색자가 만족할 구조와 출처를 갖추는 것이 진짜 GEO라고 강조합니다. 도구 한 번 돌려서 해결될 문제가 아니라, 글을 쓰는 사람이 직접 통제해야 하는 세 가지 핵심 기준이 있습니다.

기준 1. 인용 가능한 문장 밀도 (자기완결성)

가장 큰 차이를 만드는 부분입니다. AI 크롤러는 본문을 통째로 가져가지 않고 의미가 독립적인 문장 단위로 잘라 갑니다.

• 약한 문장: "최근 AI 검색이 트래픽 비중을 빠르게 키우고 있어요." (언제가 최근인지, 얼마나 빠른지 알 수 없음)
• 인용 가능한 문장: "2026년 5월 분석에 따르면 Lighthouse 13.3.0은 Agentic Browsing 카테고리를 기본 설정에 편입했어요." (시점, 버전, 고유명사, 인과가 명확함)

한 문단에 이런 단정형·구체적 문장이 하나도 없으면 AI의 인용 후보에서 가차 없이 탈락합니다.

기준 2. HTML 본문 노출 (숨바꼭질 금지)

본문이 클라이언트 사이드 JS에 의존하거나, 로그인·클릭 뒤에 숨어 있다면 크롤러는 '빈 껍데기'만 읽고 돌아갑니다.

• 피해야 할 함정: 회원가입 후 열리는 본문, '전체 보기' 클릭 후 모달로 뜨는 구조, 본문이 JS 번들 안에 묶여있는 SPA 구조.
• 해결책: Next.js의 App Router, Astro 등 서버에서 HTML을 먼저 만들어 보내는 SSR 또는 정적 사이트 생성을 활용하세요.

기준 3. 출처와 기준 시점 명시

AI는 "현재도 유효한 정보인가"를 따집니다. "최근 라이트하우스"보다 "2026년 5월 기준 라이트하우스 13.3.0"처럼 시점이 박힌 문장을 훨씬 선호합니다. 가장 좋은 방식은 [도메인명](URL) 형식의 인라인 텍스트 링크로 본문 흐름 안에 출처를 자연스럽게 박아두는 것입니다. 맨 아래 '참고문헌'으로 빼면 AI가 문장과 출처를 바로 매칭하지 못할 수 있습니다.

3. 효율 극대화: 1인 빌더 맞춤 4단계 세팅 루틴

어디서부터 손을 대야 할지 막막한 1인 빌더를 위해, 시간 대비 효율이 가장 높은 순서대로 작업 단계를 정리했습니다. (위로 갈수록 사람이 해야 하고, 아래로 갈수록 한 번 세팅하면 끝나는 작업입니다.)

1. 본문 자기완결성 점검 (가장 중요): 글을 발행하기 전, 각 헤딩별로 "이 문단에서 한 문장만 똑 떼어놔도 의미가 통하는가?"를 자문하며 구체적인 주어와 숫자를 채워 넣으세요.
2. 기본 발견 인프라 점검: 메타 태그, sitemap.xml, robots.txt를 확인하세요. 특히 robots.txt에서 GPTBot이나 PerplexityBot 같은 AI 크롤러를 실수로 막아두진 않았는지 반드시 체크해야 합니다.
3. schema.org Article 구조화 데이터: 콘텐츠 사이트라면 Article 타입 하나만 잘 넣어도 충분합니다. (headline, datePublished, dateModified, author, image 5개 필드). 한 번 템플릿을 만들어 두면 매번 자동화할 수 있습니다.
4. HTML 렌더 점검: 크롬에서 "페이지 소스 보기"를 눌러 생짜 HTML에 내 본문 첫 문단이 제대로 들어있는지 검색해 보세요. 여기서 검색이 되어야 AI도 정상적으로 읽어갈 수 있습니다.

4. 라이트하우스 9개 항목, 쉽게 번역해 드립니다

자, 이제 다시 문제의 Lighthouse 카테고리로 돌아와 보죠. 검사기를 돌렸을 때 나오는 9개의 어려운 영어 항목들, 1인 빌더의 시선으로 아주 쉽게 번역해서 무엇을 버리고 무엇을 취할지 솎아드리겠습니다.

Lighthouse를 돌려보고 agents.json이나 WebMCP 같은 항목이 '실패(Fail)'로 뜬다고 해서 당황할 필요가 전혀 없습니다. 위 표에서 보듯, 1인 빌더의 블로그에 필요한 건 결국 기존 SEO의 기본기인 '주소록(사이트맵)'과 '이름표(스키마)' 정도입니다. 결제나 예약을 할 일이 없는 콘텐츠 사이트에서 자동 리모컨(WebMCP 등)은 애초에 챙길 이유가 없으니까요.

한 번 더, 빠르게 짚고 갈게요

Q. llms.txt만 만들면 GEO 점수가 올라가나요? A. 단독으로는 큰 변화를 기대하기 어려워요. Google AI Optimization Guide는 AI 검색 노출을 위해 별도 텍스트 파일을 요구하지 않는다고 명시했고, llms.txt는 ChatGPT·Perplexity 같은 비Google LLM이 사이트의 대표 글을 발견하는 보조 지도 역할에 가까워요. 본문 자기완결성과 HTML 노출이 먼저 갖춰진 다음에 보조용으로 두는 게 우선순위가 맞아요.

Q. 콘텐츠 사이트인데 Agentic Browsing 항목까지 챙겨야 하나요? A. 9개 중 sitemap-discoverable, schema-org-density, auto-discovery-links 세 가지는 어차피 일반 SEO 작업과 겹쳐서 자동으로 챙겨져요. 나머지 agents.json·WebMCP·agent-runbook은 결제·예약처럼 에이전트가 실제 행동하는 사이트용이라 블로그·뉴스레터에서는 굳이 점수를 채울 필요가 없어요.

Q. 구조화 데이터는 어떤 타입부터 넣으면 좋을까요? A. 콘텐츠 사이트라면 Article 타입 하나만 잘 넣어도 충분해요. headline, datePublished, dateModified, author, image 다섯 필드면 GEO 신호로는 거의 다 챙긴 거예요. Google Rich Results Test로 한 번 통과한 JSON-LD 템플릿을 모든 글에 재사용하면 글당 추가 작업 시간이 사실상 0분이 돼요.

Q. PageSpeed Insights에서 Agentic Browsing 결과가 DevTools랑 다르게 나와요. A. PageSpeed Insights는 Lighthouse 카테고리를 단계적으로 반영해서 시점에 따라 DevTools와 결과가 어긋날 수 있어요. 2026년 5월 21일경 반영이 시작됐지만 모든 audit이 동기화된 건 아니에요. 차이가 있다면 DevTools(로컬 Chrome) 결과를 우선 기준으로 보고, PageSpeed Insights는 참고 지표로 활용하는 게 안전해요.

Q. AI 검색 인용을 점수로 확인할 수 있는 도구는 없나요? A. 2026년 6월 기준 ChatGPT·Perplexity·Google AI Overviews 모두 공식 "인용 카운트" API를 외부에 공개하지 않았어요. 차선책으로 Perplexity에서 자기 도메인을 검색해 인용 여부를 확인하거나, Google Search Console에서 AI 오버뷰가 노출된 쿼리의 클릭률 변화를 간접 지표로 보는 방법이 있어요. 도구가 없는 영역이라 본문 품질 자체를 통제 변수로 보는 접근이 가장 현실적이에요.