인용 전략보다 먼저 확인할 GEO의 기술 조건
중요한 사실이 JavaScript 실행 뒤에만 나타난다면 AI 에이전트는 그 정보를 받지 못할 수 있습니다.
여기에는 제품 기능, 비교 페이지의 결론, 가격 조건, 문서의 답변, 작성자 정보, 그리고 AI가 인용하기를 바라는 근거가 포함됩니다. 사람이 Chrome에서 완성된 페이지를 본다고 해서 크롤러, 본문 추출기, 브라우저 에이전트도 같은 콘텐츠를 얻는 것은 아닙니다.
한 SEO 실무자는 페이지 템플릿별로 원본 HTML과 렌더링 후 페이지를 비교했습니다. 글, 튜토리얼, 상점, 코스, 랜딩 페이지, 카테고리 페이지에서 보이는 콘텐츠 대부분은 이미 HTML에 있었고, JavaScript 뒤에 나타나는 부분은 적었습니다. 중요한 것은 정확한 비율이 아닙니다. 첫 HTML 응답에 에이전트가 이해해야 할 답이 이미 있는가가 핵심입니다.
GEO에서 이것은 인용 이전의 자격 검사입니다. 시스템이 페이지의 핵심 사실을 가져오지 못하면 근거를 평가하거나 인용 후보로 선택할 수 없습니다.
페이지에 접근하는 경로마다 JavaScript를 사용할 수 있는 범위가 다릅니다. 원본 요청과 본문 추출은 대체로 HTML 응답에만 의존합니다.
Google이 렌더링한다고 모든 에이전트가 렌더링하는 것은 아니다
"Google은 JavaScript를 렌더링할 수 있다"는 말은 맞습니다. 그러나 모든 AI 검색 제품과 에이전트가 최종 브라우저 화면을 본다는 뜻으로 확장하면 위험합니다.
같은 URL도 여러 경로로 접근될 수 있습니다.
| 접근 경로 | 실제로 받는 것 | JavaScript 의존성 |
|---|---|---|
| 원본 HTTP 요청 | 최초 HTML 응답 | 실행하지 않음 |
| 리더 또는 본문 추출기 | HTML에서 고른 텍스트 | 보통 실행하지 않음 |
| 브라우저 자동화 | 렌더링된 DOM | 실행할 수 있으나 시간 제한과 정책의 영향을 받음 |
| 검색 색인 파이프라인 | 수집 후 대기열에서 필요 시 렌더링 | 플랫폼마다 다름 |
| 도구 사용 에이전트 | 자신이 쓰는 웹 수집 도구의 출력 | 원본 요청과 가까운 경우가 많음 |
Google의 렌더링 능력은 강력하지만 다른 시스템에도 적용되는 보장은 아닙니다. 답변 엔진, 사내 검색, 브라우징 에이전트, 웹 추출 도구는 HTML만 가져오거나 느린 클라이언트 데이터가 끝나기 전에 작업을 중단할 수 있습니다. 특정 플랫폼의 능력을 사이트 설계의 전제로 삼는 것은 불필요한 도박입니다.
안전한 원칙은 단순합니다. 발견과 인용에 중요한 공개 사실은 첫 응답에서 읽을 수 있어야 합니다.
프레임워크가 아니라 사실이 나타나는 계층을 점검하라
SSR과 CSR은 GEO 성적표가 아닙니다. React, Vue, Next.js 사이트도 에이전트 친화적으로 만들 수 있습니다. 반대로 전통적인 서버 렌더링 사이트도 핵심 사실을 클라이언트 API 호출 뒤에 숨길 수 있습니다.
중요한 블록이 어느 계층에서 사용 가능해지는지 점검해야 합니다.
| 콘텐츠 계층 | 대표 예 | GEO 위험 |
|---|---|---|
| 초기 HTML | 제목, 본문, 사양, FAQ, 작성자, 날짜 | 낮음 |
| 서버에서 가져와 출력한 HTML | 현재 가격, 지역별 제공 여부 | 낮음에서 중간 |
| 클라이언트 API 요청 | 제품 장점, 비교표, 문서 본문 | 높음 |
| 사용자 상호작용 후 | 탭, 아코디언, 필터, 무한 스크롤 결과 | 높음 |
| 로그인 후 화면 | 대시보드, 비공개 지식 베이스 | 공개 인용을 기대하지 말 것 |
AI가 공개 답변에서 반복하기를 바라는 사실은 클릭, 클라이언트 요청 성공, 긴 JavaScript 작업에 의존하면 안 됩니다. 상호작용은 남겨도 되지만 설명에 필요한 정보는 앞쪽으로 옮겨야 합니다.
흔한 실패는 로딩 껍데기만 보내는 제품 페이지, hydration 뒤에 표가 나타나는 비교 페이지, 클라이언트 라우팅으로 본문을 불러오는 문서, 무한 스크롤에만 의존하는 카테고리, 결론이 이미지나 Canvas 안에만 있는 시각 모듈입니다.
완성된 화면이 보기 좋아도 최초 HTML 응답은 의미 있는 정보를 거의 내보내지 않을 수 있습니다.
두 가지 화면 상태를 비교해 확인하라
사이트가 React를 쓰는지 묻지 마십시오. 같은 URL에서 다음 두 버전을 저장하십시오.
- JavaScript를 실행하지 않고 가져온 원본 HTML
- 브라우저에서 주요 콘텐츠를 기다린 뒤 추출한 렌더링된
main텍스트
기본 수집은 다음처럼 시작할 수 있습니다.
curl -sL "https://example.com/product" -o raw.html
헤더, Cookie 배너, 푸터가 아니라 의미 있는 블록을 비교해야 합니다.
- H1과 짧은 답변
- 첫 설명 문단
- 제품 사실과 제약 조건
- 비교표
- FAQ 답변
- 작성자와 업데이트 날짜
- 내부 링크와 canonical URL
브라우저 완료 조건으로 networkidle만 쓰지 마십시오. 분석 스크립트, 채팅 위젯, 장기 연결이 페이지를 계속 통신 중으로 보이게 할 수 있습니다. 주요 콘텐츠 선택자가 나타나는 시점이나 핵심 사실을 제공하는 특정 데이터가 완료되는 시점을 기다리는 편이 낫습니다.
이 비교는 배포 지표로도 쓸 수 있습니다.
핵심 콘텐츠 노출률 = 원본 HTML에 있는 핵심 블록 수 / 페이지에 필요한 핵심 블록 수
목표는 모든 픽셀을 HTML에 넣는 것이 아닙니다. 페이지를 이해하는 데 필요한 근거가 클라이언트 실행 성공에 의존하지 않게 만드는 것입니다.
프런트엔드를 다시 만들기 전에 콘텐츠 전달 경로를 고쳐라
대부분의 팀은 사이트 전체를 다시 쓸 필요가 없습니다. 안정적인 공개 정보는 첫 응답으로 옮기고, 필터, 저장된 설정, 지도, 애니메이션, 개인화에는 JavaScript를 계속 쓰면 됩니다.
| 상황 | 더 적합한 전달 방식 |
|---|---|
| 안정적인 글, 튜토리얼, 용어 페이지 | 정적 생성 또는 빌드 시점 사전 렌더링 |
| 자주 바뀌는 가격, 재고, 지역 정보 | 캐시와 명시적 무효화를 갖춘 서버 렌더링 |
| 상호작용은 많지만 설명은 안정적인 페이지 | 설명, 사실, FAQ는 서버에서 출력하고 상호작용만 hydration |
| 대규모 앱 안의 공개 문서 | 공개 경로를 사전 렌더링하고 핵심 답을 로그인에 의존시키지 않음 |
| 여러 내부 API에 의존하는 페이지 | 서버 또는 BFF 계층에서 핵심 데이터를 모아 HTML과 앱이 공유 |
JSON-LD는 유용하지만 읽을 수 있는 페이지 본문을 대신하지는 못합니다. 구조화 데이터에는 방문자와 추출기가 문서 안에서도 찾을 수 있는 사실을 넣어야 합니다.
GEO 팀을 위한 2주 실행 순서
1-2일차: 자연 유입, AI 인용, 영업 지원, 고객 지원에 영향을 주는 템플릿을 나열합니다. 글, 제품 페이지, 문서, 비교 페이지, 카테고리 페이지면 대개 충분합니다.
3-5일차: 템플릿마다 URL을 표본으로 뽑아 원본 HTML과 렌더링 후 콘텐츠를 저장합니다. 누락된 H1, 설명, 제품 사실, FAQ, 내부 링크를 표시합니다.
6-9일차: 가치가 높고 내용이 안정적인 페이지부터 고칩니다. 정의, 사실, 비교 결론, FAQ를 서버 또는 빌드 출력으로 옮깁니다.
10-14일차: 같은 테스트를 반복하고 배포 게이트를 추가합니다. 초기 HTML에 H1, 주요 답변, 핵심 사실, canonical 링크가 없으면 해당 템플릿을 배포하면 안 됩니다.
이 방법이 모든 AI 제품의 인용을 보장하지는 않습니다. 다만 잠재적인 에이전트가 공개 정보를 안정적으로 읽지 못하는, 피할 수 있는 실패는 없앱니다.
Auspia의 관점
GEO는 브랜드 언급, 출처 품질, 엔터티 명확성, 답변 구조부터 이야기하는 경우가 많습니다. 그러나 이 모든 것은 시스템이 우선 페이지를 얻었다는 전제를 갖습니다.
JavaScript 자체가 문제는 아닙니다. 공개 설명을 클라이언트 실행의 부수 효과로 취급하는 것이 문제입니다. HTML에는 콘텐츠 책임을, JavaScript에는 경험 책임을 맡기십시오. 이 구분은 테스트, 기술 SEO, 에이전트 접근성에도 도움이 됩니다.
FAQ
Google이 JavaScript를 렌더링한다면 원본 HTML을 점검할 필요가 있나요?
있습니다. Google의 능력이 다른 크롤러, 리더 도구, 에이전트가 같은 경로를 쓴다는 뜻은 아닙니다. 원본 HTML 점검은 렌더링 지연과 클라이언트 요청 실패도 드러냅니다.
GEO에서 SSR은 항상 CSR보다 좋은가요?
아닙니다. 정적 생성, 서버 렌더링, 사전 렌더링 모두 가능합니다. 높은 상호작용이 필요한 요소에는 클라이언트 렌더링을 남길 수 있습니다. 기준은 공개 페이지의 핵심 사실이 최초 HTML 응답에서 읽히는가입니다.
페이지 전체에서 JavaScript를 피해야 하나요?
아닙니다. 필터, 애니메이션, 지도, 저장 설정, 개인화, 로그인 경험에는 JavaScript를 쓸 수 있습니다. 페이지 주제를 설명하고 인용 가능한 사실을 보여 주는 콘텐츠를 우선해야 합니다.
llms.txt가 JavaScript 뒤에만 보이는 콘텐츠를 해결하나요?
해결하지 못합니다. 어떤 시스템이 llms.txt를 읽어도 전체 본문이나 클라이언트 API 데이터를 자동으로 얻지는 못합니다. 공개 페이지 자체가 핵심 콘텐츠를 접근 가능하게 해야 합니다.
출처 메모
이 글은 Adrian Skowron의 SSR과 CSR 가시 콘텐츠 비교 게시물 에서 출발했습니다. 게시물의 차트는 작성자 자신의 템플릿 측정값이며 업계 전체 벤치마크는 아닙니다.
작성자: Julian Mercer, Auspia의 14년 경력 테크니컬 SEO 실무자. Julian은 크롤링, 렌더링, 구조화 데이터, 검색과 AI가 콘텐츠를 이해하게 하는 기술 기반을 다룹니다.
