AI 접근 가능성: 렌더링 없이 읽히는 본문

AI 접근 가능성은 JavaScript를 실행하지 않는 도구가 이 페이지의 본문을 그대로 읽을 수 있는가를 확인하는 카테고리입니다. GEO 100점 중 25점을 차지하며, GEO 검사 결과에서 가장 먼저 보여 주는 영역입니다. 답변 인용 형식을 갖추거나 출처 정보를 정리하는 일은 모두 본문이 읽히는 상태여야 의미가 생기기 때문입니다.

여기서 말하는 “도구”는 넓은 뜻입니다. 생성형 검색의 수집 크롤러, 답변을 만들 때 실시간으로 페이지를 가져오는 브라우징 기능, 인용 근거를 확인하려고 URL을 여는 에이전트가 모두 포함됩니다. 이들 중 상당수는 검색엔진과 달리 별도의 렌더링 예산을 두고 페이지를 다시 그리지 않습니다. 첫 번째 HTTP 응답에 담긴 HTML이 곧 이들이 보는 문서의 전부일 가능성이 큽니다.

배점을 25점으로 잡은 이유도 같습니다. 다른 GEO 카테고리의 문제는 대체로 “덜 좋아지는” 문제입니다. 답변 형식이 어긋나면 발췌하기 어렵고, 출처 정보가 없으면 신뢰 판단에 근거가 부족합니다. 그러나 이 카테고리의 문제는 “읽을 것이 없는” 문제입니다. 본문이 클라이언트에서만 그려진다면 나머지 75점에 해당하는 신호를 관찰할 대상 자체가 사라집니다.

왜 이 순서로 보는가

10개 항목은 실무자가 점검할 순서대로 배열돼 있습니다. 먼저 읽을 본문이 있는지(7점, 5점), 다음으로 그 본문을 막는 신호가 없는지(4점, 3점), 이어서 본문이 없을 때 대안이 있는지(2점), 그다음 문서의 언어와 구획이 선언돼 있는지(2점, 2점)를 봅니다. robots.txt의 두 접근 진단과 llms.txt 안내 파일은 각각 0점입니다.

앞 단계가 뒤 단계를 조건 짓습니다. 초기 HTML에 본문이 없으면 언어 선언이 있어도 그 언어로 쓰인 문장을 확인할 수 없고, 주 영역 표시가 있어도 그 안이 비어 있습니다. 배점은 “얼마나 자주 틀리는가”가 아니라 **“이 항목이 무너지면 나머지 항목이 얼마나 무의미해지는가”**를 기준으로 정했습니다. 그래서 본문 존재가 7점으로 가장 높고, 이미 본문이 있는 상태에서 덧붙이는 신호는 2점에 머뭅니다.

robots.txt 관련 두 항목이 0점인 이유는 뒤에서 따로 설명합니다. 짧게 말하면, 사업자마다 크롤러 정책이 다르고 그 정책은 정당한 선택이므로 점수로 우열을 매기지 않기로 했습니다.

1단계: 읽을 본문이 있는가

초기 HTML 본문 존재 (7점)

검사기는 JavaScript를 실행하지 않은 최초 HTML 응답에서 스크립트·스타일·내비게이션을 제외한 본문 텍스트를 찾습니다. 이 항목이 카테고리 안에서 가장 높은 7점인 이유는 앞서 말한 조건 관계 때문입니다. 본문이 없으면 이 카테고리의 다른 항목뿐 아니라 다른 GEO 카테고리도 “확인 불가”로 남을 가능성이 있습니다. 검사기가 이 항목을 첫 번째로 보여 주는 것은 결과 표를 읽는 순서를 안내하려는 뜻이기도 합니다. 이 항목이 실패했다면 아래 항목들의 판정보다 이 항목을 먼저 고치는 것이 맞습니다.

실무에서 이 항목이 틀리는 방식은 대체로 세 가지입니다. 첫째, React·Vue 같은 프레임워크로 만든 SPA를 정적 호스팅에 올리면서 사전 렌더링을 설정하지 않은 경우입니다. <div id="root"></div> 하나만 남고 본문은 번들 실행 후에야 나타납니다. 둘째, SSR을 쓰긴 하지만 본문 데이터를 클라이언트에서 별도 API로 받아오는 경우입니다. 레이아웃은 서버에서 그려지지만 정작 기사 본문은 로딩 스피너 자리에 들어옵니다. 셋째, 서버 응답은 정상인데 봇 판별 로직이 검사기의 요청을 브라우저가 아니라고 판단해 빈 껍데기나 안내 페이지를 돌려주는 경우입니다.

흔한 오해 하나를 짚습니다. “Google은 JavaScript를 렌더링하니까 괜찮다”는 말은 절반만 맞습니다. Google 검색의 렌더링 대기열은 별도 예산으로 나중에 처리되고, 생성형 검색의 브라우징 기능이나 답변 생성 시점의 실시간 수집은 그 대기열을 거치지 않을 가능성이 큽니다. 검색 색인에서는 문제없던 페이지가 AI 도구에서는 빈 문서로 보이는 차이가 여기서 생깁니다.

JS 렌더링 의존 가능성 (5점)

이 항목은 앞 항목과 짝을 이룹니다. 초기 HTML 본문 존재가 “본문이 있는가”를 본다면, JS 렌더링 의존 가능성은 **“있는 본문이 스크립트 없이도 충분한가”**를 봅니다. 초기 HTML에 텍스트가 있긴 하지만 그 양이 스크립트 태그의 양에 비해 극히 적거나, 본문 자리에 “로딩 중” 같은 자리표시 문구만 있는 경우를 잡으려는 항목입니다.

배점을 7점이 아니라 5점으로 둔 이유는 이 항목이 추정이기 때문입니다. 검사기는 초기 HTML의 텍스트 밀도와 스크립트 비중, 자리표시 패턴을 근거로 “렌더링에 의존하는 것으로 보인다”고 판단합니다. 실제로 JavaScript를 실행해서 전후를 비교하는 것이 아닙니다. 그래서 항목 이름에도 “가능성”을 붙였습니다. 추정에 근거한 항목에 확정 판정과 같은 배점을 줄 수는 없습니다.

오탐이 생기는 전형적인 경우가 있습니다. 본문은 서버에서 온전히 렌더링됐지만 분석 스크립트·광고 스크립트·챗봇 위젯이 인라인으로 대량 삽입돼 스크립트 비중이 커 보이는 페이지입니다. 이 경우 본문 자체는 읽히므로 실제 위험은 낮습니다. 이 항목이 경고를 냈는데 초기 HTML 본문 존재는 통과했다면, 페이지 소스를 열어 본문이 실제로 들어 있는지 눈으로 확인하는 것이 먼저입니다. 반대로 통과했다고 안심할 수도 없습니다. 짧은 소개 문단만 서버에서 그리고 핵심 내용은 클라이언트에서 채우는 구조라면 검사기는 “본문이 있다”고 볼 수 있습니다.

2단계: 본문을 막는 신호가 없는가

HTML robots 색인 제한 부재 (4점)

<head> 안의 <meta name="robots"> 와 특정 크롤러 이름을 지정한 메타 태그에서 noindex·none·noai 같은 제한 토큰을 찾습니다. SEO 검사에도 같은 계열의 항목이 있지만, GEO 쪽에서 다시 보는 이유는 판정 기준이 다르기 때문입니다. SEO 검사는 검색 색인이 막히는지를 봅니다. 이 항목은 AI 관련 도구가 문서 수준의 제한 신호를 만났을 때 협조적으로 물러설 수 있는 상태인지를 봅니다.

배점이 4점인 것은 이 신호가 문서 안에 명시된 의사 표시라는 점 때문입니다. 본문이 있고 렌더링에도 의존하지 않는데 noindex가 남아 있다면, 그 문서는 “읽을 수는 있지만 쓰지 말라”고 선언한 셈입니다. 검사기는 이 선언을 존중하는 도구의 관점에서 판정합니다. 다만 실제로 그 선언을 따를지는 사업자 정책에 달려 있으며, 검사기가 그 결과를 알 수는 없습니다.

실무에서는 스테이징 환경의 noindex가 운영 배포에 섞여 들어오는 사고가 가장 흔합니다. 또 하나는 CMS 플러그인이 “AI 학습 방지” 옵션으로 noai 계열 토큰을 넣어 두었는데 담당자가 바뀌면서 그 사실을 잊은 경우입니다. 의도한 정책이라면 문제가 아닙니다. 검사기는 정책의 옳고 그름이 아니라 현재 상태가 의도와 일치하는지 확인할 기회를 주려는 것입니다.

이 항목은 HTTP 응답 헤더의 X-Robots-Tag를 보지 않습니다. 헤더 쪽 제한은 SEO 검사의 별도 항목에서 다루며, 이 항목의 수정 안내에도 그 사실을 명시해 두었습니다.

읽기 차단 화면 신호 부재 (3점)

초기 HTML이 실제 본문이 아니라 차단·검증·대기 화면인지를 봅니다. 봇 검증 페이지(“잠시만 기다려 주세요, 브라우저를 확인하고 있습니다”), 로그인 요구 화면, 연령 확인 게이트, 지역 차단 안내가 여기에 해당합니다. HTTP 상태 코드는 200이지만 본문은 원래 문서가 아닌 경우를 잡습니다.

이 항목을 색인 제한 항목보다 낮은 3점으로 둔 이유는 오탐 가능성 때문입니다. 검사기는 특정 문구 패턴과 구조로 차단 화면을 추정합니다. 실제 본문에 “로그인” 이라는 단어가 자주 나오는 회원 서비스 소개 페이지나, 챌린지 화면과 비슷한 짧은 레이아웃을 가진 랜딩 페이지가 잘못 걸릴 수 있습니다. 반대로 검사기가 모르는 형태의 차단 화면은 통과로 남을 수 있습니다.

이 항목에서 경고가 났다면 두 가지를 확인하는 것이 좋습니다. 첫째, CDN이나 WAF의 봇 관리 설정이 알려진 크롤러를 예외 처리하고 있는지입니다. 사람 방문자에게는 정상이지만 서버 요청에는 챌린지를 보내는 설정이 기본값인 서비스가 많습니다. 둘째, 그 차단이 의도한 것인지입니다. 유료 콘텐츠나 회원 전용 문서라면 차단은 올바른 상태이고, 이 항목의 경고는 “현재 이렇게 보인다”는 관찰일 뿐입니다.

3단계: 본문이 없을 때 대안이 있는가

대체 본문 안내 (2점)

<noscript> 안에 문서 주제를 알 수 있는 요약이나 안내가 있는지 봅니다. 이 항목은 앞 단계가 실패했을 때의 완충 장치입니다. 초기 HTML에 본문이 온전히 있다면 <noscript>는 필요 없고, 검사기도 이 경우 감점하지 않습니다. 본문이 클라이언트 렌더링에 의존하는데 <noscript>마저 비어 있거나 “JavaScript를 켜 주세요” 한 줄뿐일 때 문제가 됩니다.

배점이 2점에 그치는 이유는 이것이 근본 해법이 아니라 차선책이기 때문입니다. <noscript>에 요약을 넣는 것은 SSR로 전환할 수 없는 상황에서 문서 주제라도 전달하려는 조치입니다. 검사기가 이 항목에 높은 점수를 주면, SSR을 도입하는 대신 <noscript>만 채우는 방향으로 실무가 흐를 수 있습니다. 그것은 이 카테고리가 권하는 방향이 아닙니다.

흔한 오해는 <noscript>가 “JavaScript가 꺼진 브라우저”만을 위한 태그라는 생각입니다. 스크립트를 실행하지 않는 수집 도구는 <noscript> 안의 내용도 일반 텍스트로 읽을 수 있는 경우가 많습니다. 반대로 <noscript>에 본문 전체를 복제해 넣는 방식은 권하지 않습니다. 두 본문이 시간이 지나며 어긋나기 쉽고, 스크립트를 실행하는 도구에게는 숨겨진 중복 텍스트로 보일 수 있습니다.

4단계: 문서의 언어와 구획이 선언돼 있는가

문서 언어 선언 (2점)

<html> 요소의 lang 속성이 있고 BCP 47 형식(ko, ko-KR, en 등)인지 봅니다. 배점이 2점인 이유는 본문이 있다면 언어는 대부분 내용에서 추정되기 때문입니다. 선언이 없어서 한국어 문서가 다른 언어로 오인되는 일은 드뭅니다. 그러나 드물다는 것이 없다는 뜻은 아닙니다. 한국어와 영어가 절반씩 섞인 기술 문서, 짧은 제품 페이지, 코드 블록이 본문보다 긴 페이지에서는 추정이 흔들릴 수 있습니다.

실무에서 이 항목이 틀리는 방식은 단순합니다. 프레임워크 기본 템플릿의 lang="en"을 그대로 두는 경우가 가장 많습니다. 한국어 사이트인데 lang="en"으로 선언돼 있으면 검사기는 통과로 판정합니다. 형식은 맞기 때문입니다. 이것은 검사의 한계이자 의도된 범위입니다. 검사기는 선언의 존재와 형식만 보고, 선언이 본문 언어와 일치하는지는 확인하지 않습니다. 이 항목을 통과했더라도 값이 실제 언어와 맞는지 한 번 눈으로 확인하는 것이 좋습니다.

lang="kr"처럼 국가 코드를 언어 코드 자리에 쓰는 실수도 자주 봅니다. kr은 BCP 47에서 한국어를 뜻하지 않습니다. 한국어는 ko이며, 지역을 붙이려면 ko-KR입니다.

콘텐츠 주 영역 표시 (2점)

<main> 또는 <article> 요소로 본문 구획이 표시돼 있는지 봅니다. 수집 도구가 내비게이션·푸터·사이드바와 본문을 구분할 때 이런 랜드마크는 유용한 단서입니다. 다만 대부분의 도구는 랜드마크 없이도 텍스트 밀도와 위치로 본문을 추출하므로, 이 항목은 있으면 좋은 신호이지 없다고 본문이 사라지는 문제는 아닙니다. 그래서 2점입니다.

이 항목에는 다른 항목과 다른 판정 규칙이 하나 있습니다. 확인하지 못한 항목은 감점하지 않습니다. 초기 HTML 본문이 없어서 구획을 판단할 대상 자체가 없는 경우, 검사기는 “확인 불가”로 표시하고 점수를 깎지 않습니다. 이미 앞 항목에서 7점을 잃은 페이지에 같은 원인으로 또 감점하는 것은 이중 처벌이기 때문입니다.

흔한 실수는 <main>을 여러 개 두거나, <main> 안에 헤더와 푸터까지 넣어 페이지 전체를 감싸는 것입니다. 후자는 검사기가 통과로 판정하지만 구획으로서의 의미는 없습니다. 또 하나는 블로그 목록 페이지에서 각 글 카드를 <article>로 감싸는 것입니다. 이것은 HTML 명세상 올바른 사용이지만, 검사기 관점에서는 “주 영역이 여러 개”로 보여 어느 것이 본문인지 특정하기 어렵습니다. 목록 페이지라면 목록 전체를 <main>으로 감싸고 개별 카드는 <article>로 두는 구조가 두 관점을 모두 만족합니다.

5단계: robots.txt는 무엇이라고 말하는가

AI 크롤러 robots.txt 접근 지시 (0점, 진단 항목)

사이트 루트의 robots.txt를 가져와 용도별 AI 관련 크롤러가 어떤 지시를 받는지 읽습니다. 검색용에는 OAI-SearchBot·Claude-SearchBot·PerplexityBot·meta-webindexer·Amzn-SearchBot·DuckAssistBot·MistralAI-Index·Applebot·YandexAdditional 계열, 사용자 요청용에는 ChatGPT-User·Claude-User·Perplexity-User·meta-externalfetcher·Amzn-User·MistralAI-User, 학습·통제용에는 GPTBot·ClaudeBot·CCBot·meta-externalagent·Amazonbot·MistralAI-Training·Google-Extended·Applebot-Extended 같은 1차 문서 확인 토큰을 사용합니다. 제공사 문서에 따라 이름과 용도를 갱신하므로 예전 목록을 그대로 복사하기보다 OpenAI, Anthropic, Perplexity, Meta, Mistral, Amazon, Apple, Common Crawl, Yandex의 현재 안내를 함께 확인하는 편이 안전합니다. 이 항목은 GEO 점수에 반영하지 않습니다. 이유는 분명합니다. AI 크롤러를 허용할지 차단할지는 저작권·트래픽 비용·사업 방향에 따라 달라지는 정당한 정책 결정이며, 검사기가 한쪽을 “옳다”고 점수로 말할 근거가 없습니다.

그럼에도 이 항목을 두는 이유는 정책과 현재 상태가 일치하는지 확인할 기회를 주기 위해서입니다. 허용하려 했는데 차단돼 있거나, 차단하려 했는데 열려 있거나, 애초에 robots.txt가 없어서 아무 지시도 못 하고 있는 상태를 알려 줍니다. 세 번째 경우가 가장 흔합니다. robots.txt가 404를 반환하면 검사기는 “접근 지시를 확인하지 못했습니다”라고만 표시합니다. 이것은 차단도 허용도 아니며, 대부분의 크롤러는 파일이 없으면 접근 가능으로 해석합니다.

여기서 오해 하나를 바로잡습니다. AI 크롤러를 허용한다고 해서 생성형 검색에 인용되거나 답변에 쓰이는 것이 약속되지는 않습니다. robots.txt는 문을 열어 두는 것이고, 누가 들어와서 무엇을 가져가는지는 각 사업자의 수집 정책과 답변 생성 방식에 달려 있습니다. 반대로 차단한다고 해서 이미 수집된 내용이 사라지지도 않습니다.

판정은 용도별로 나눕니다. 검색·사용자 요청용 토큰을 전면 차단하면 개선 권장, 학습·사용 통제용 토큰만 차단하면 참고로 알립니다. Google-Extended 차단은 Gemini 학습과 grounding 근거 활용을 제한할 수 있지만 Google 검색의 포함·순위나 AI 개요에는 영향을 주지 않습니다. 따라서 이 분류를 모든 AI 활용 경로의 완전한 분리로 이해하면 안 됩니다. OpenAI도 검색용 OAI-SearchBot과 학습용 GPTBot을 별도로 설명합니다. OpenAI 크롤러 안내, Google 공통 크롤러 안내

Content-Signal과 Content-Usage 문구는 접근 규칙과 구분해 근거로 보여 줍니다. 둘 다 콘텐츠 사용 선호를 표현하며, 이 문구가 있다고 네트워크 접근이 차단되는 것은 아닙니다. Content-Usage는 아직 RFC가 아닌 IETF 초안에 정의된 선언입니다. Cloudflare Content Signals 안내, IETF AIPREF 문서 목록. Cloudflare의 현재 Block 설정은 Googlebot·Bingbot·Applebot 같은 혼합 용도 크롤러에도 적용될 수 있으므로 robots.txt만으로 WAF 상태를 판단하지 마세요. Cloudflare 혼합 용도 크롤러 설정 안내

robots.txt 의 현재 경로 접근 지시 (0점, 진단 항목)

앞 항목이 크롤러별 지시를 본다면, 이 항목은 지금 검사 중인 URL 경로가 AI 관련 크롤러 그룹 또는 * 그룹에서 어떻게 처리되는지 봅니다. 사이트 전체는 열어 두었지만 /blog/ 아래를 특정 크롤러에 막아 둔 경우처럼, 크롤러 단위 판정과 경로 단위 판정이 다를 수 있어 별도 항목으로 나눴습니다.

점수를 넣지 않는 이유는 앞 항목과 같습니다. 덧붙여 이 항목에는 해석의 한계가 하나 더 있습니다. robots.txt 문법에서 같은 User-agent 그룹이 파일 안 여러 곳에 떨어져 선언된 경우, 검사기는 이를 하나로 합쳐 해석하지 않습니다. 반면 Google 공식 문서에 따르면 Googlebot은 같은 크롤러에 해당하는 그룹을 내부적으로 합쳐 해석하므로, 이 항목의 판정은 Google의 실제 처리 방식과 다를 수 있습니다. 또 Allow와 Disallow가 같은 경로에 겹칠 때의 우선순위는 크롤러마다 조금씩 다르며, 검사기는 가장 긴 일치 규칙을 우선하는 일반적인 해석을 따릅니다. 이 해석이 특정 사업자의 실제 동작과 다를 수 있습니다.

robots.txt 리디렉션은 남은 요청 예산 안에서 최대 2홉까지 따라가며 매번 대상 주소를 검증합니다. 예산 초과나 수집 실패는 확인 불가로 남습니다. Applebot 전용 그룹이 없고 Googlebot 그룹이 있으면 Apple의 문서에 따라 Googlebot 규칙을 적용합니다. 다른 크롤러의 실제 요청 방식이나 캐시 상태까지 재현하는 것은 아닙니다. Applebot 안내

llms.txt 안내 파일 (0점, 점수 미반영 진단)

llms.txt 안내 파일은 사이트 루트의 /llms.txt를 한 번 요청해 응답과 첫 제목 줄을 확인합니다. 리디렉션을 따라가지 않으며 최대 64KB만 읽습니다. 2xx 응답이 HTML이거나 첫 줄에 H1이 없으면 개선 권장, H1이 있으면 통과입니다. 3xx·4xx는 참고, 서버 오류·본문 읽기 실패·요청 한도 초과는 확인 불가입니다.

파일이 없어도 감점하지 않습니다. llms.txt는 공개 제안 형식이지 검색 필수 표준이 아니며, Google은 검색에서 이 파일을 사용하지 않는다고 설명합니다. 다른 서비스가 타 사이트의 llms.txt를 수집한다는 공식 확인도 부족합니다. 파일을 만드는 것보다 본문과 접근 정책을 먼저 점검하는 이유입니다. Google 생성형 AI 검색 안내, llms.txt 제안

이 검사가 확인하지 못하는 것

정직하게 범위를 밝힙니다.

• 단일 페이지 검사입니다. 한 URL과 robots.txt·sitemap·llms.txt·404 탐침을 확인하되, 리디렉션을 포함해 최대 6회 요청합니다. 다른 본문 페이지나 사이트 전체의 렌더링 상태는 조사하지 않습니다.
• 초기 HTML 기준입니다. JavaScript 실행 후의 DOM은 보지 않습니다. 이 카테고리는 그 기준 자체를 검사 대상으로 삼기 때문에 다른 카테고리보다 이 한계가 덜 문제되지만, 렌더링 후 본문이 정상적으로 나타나는지는 확인하지 않습니다.
• 추정 항목이 있습니다. JS 렌더링 의존 가능성과 읽기 차단 화면 신호 부재는 패턴에 근거한 추정이며, 오탐과 미탐이 모두 있을 수 있습니다.
• 검사기의 요청은 특정 크롤러를 흉내 내지 않습니다. 서버가 User-agent에 따라 다른 응답을 돌려준다면 GPTBot이나 ClaudeBot이 실제로 받는 HTML은 검사 결과와 다를 수 있습니다.
• X-Robots-Tag 응답 헤더는 이 카테고리 범위 밖입니다. 헤더 쪽 색인 제한은 SEO 검사의 검색 접근성 카테고리에서 다룹니다.
• robots.txt 해석에 한계가 있습니다. 흩어진 그룹 선언을 합치지 않고, 사업자별 확장 문법을 지원하지 않습니다.
• 판정은 애드브랜치의 우선순위입니다. 배점과 심각도는 이 검사기가 정한 기준이며, Google이나 AI 검색 사업자가 이 페이지를 실제로 수집·인용할지에 대한 판정 그 자체가 아닙니다. 모든 항목을 통과해도 인용이나 노출이 약속되지는 않습니다.

이어서 읽기

항목별 수정 방법과 코드 예시는 아래 표에 정리돼 있습니다. 개념을 더 깊이 보려면 GEO 점검 체크리스트, AI 크롤러 접근 설정, 제목 구조(H1~H6) 설계를 함께 읽어 보세요.