AI 검색 최적화 체크리스트는 회사 사이트가 ChatGPT, 구글 AI 개요, 네이버 AI 브리핑 같은 AI 답변의 출처로 쓰일 준비가 되었는지 다섯 단계로 확인하는 점검 목록입니다. 크롤러(crawler, 웹 페이지를 돌아다니며 읽어 가는 프로그램) 접근, 답변 구조, 구조화 데이터, 근거와 날짜, llms.txt 순서로 보고, 단계마다 직접 확인하는 방법과 개발 담당자에게 요청할 일을 나눠 적었습니다. 그대로 복사해 고쳐 쓸 수 있는 설정 예시와 확인 명령은 글 끝 "개발자를 위한 심화"에 모았습니다.
한눈에 보기
- AI 답변에 우리 회사가 출처로 나오려면, AI가 페이지를 읽을 수 있어야 하고(접근), 읽은 페이지에서 답을 바로 찾을 수 있어야 합니다(구조).
- 앞 단계가 막히면 뒤 단계가 소용없으므로 앞에서부터 차례로 점검합니다. 크롤러 접근이 가장 먼저이고, 효과가 확인되지 않은 llms.txt는 맨 끝의 선택 항목입니다.
- 절반은 브라우저 주소창과 "페이지 소스 보기"만으로 직접 확인할 수 있고, 나머지는 이 글의 요청 문장을 개발 담당자나 호스팅 업체에 그대로 전하면 됩니다.
예시는 젠아이랩스(GenAI Labs)가 자사 사이트 gensapps.com에 먼저 적용하며 쓴 형태를 가상의 회사 "예시테크(www.example.co.kr)"에 맞게 바꾼 것입니다. 개념부터 보고 싶다면 생성형 AI 검색 최적화(GEO)란?을 먼저 읽어 보세요.
이런 상황을 떠올려 보세요. 작은 인테리어 업체를 운영하는 김 대표는 상담 전화에서 "ChatGPT에 동네 욕실 리모델링 업체를 물어봤더니 다른 두 곳이 나오던데요"라는 말을 들었습니다. 홈페이지도 있고 시공 사례도 꾸준히 올렸는데 왜 빠졌는지 알 길이 없습니다. 홈페이지 제작 업체에 물어보려 해도 무엇을 물어야 할지부터 막힙니다. 이 글은 그 질문 목록입니다. 무엇을 직접 열어 보고, 무엇을 업체에 요청할지를 단계마다 적었습니다.
AI 답변 엔진은 "출처를 달아 요약해 주는 기자"와 비슷합니다. 기자는 들어갈 수 없는 건물은 취재하지 못하고, 들어가더라도 질문의 답이 어디 있는지 한눈에 보이는 자료를 먼저 인용합니다. 아래 점검은 이 기자가 우리 사이트에 들어와(접근), 답을 빨리 찾고(구조), 회사 정보를 틀리지 않게 옮겨 적도록(구조화 데이터, 날짜, 출처) 돕는 일입니다.
30분 점검표
아래 목록을 위에서부터 따라가면 됩니다. 대부분 브라우저만 있으면 되고, 항목마다 무엇이 문제인지와 업체에 전할 요청 문장은 이어지는 단계별 설명에 적었습니다. 괄호 안 시간은 직접 확인하는 데 드는 대략의 시간이고, 업체에 묻고 답을 받는 시간은 따로 듭니다.
1단계. 크롤러 접근(직접 확인 10분, 업체 요청은 별도)
- 주소창에
example.co.kr과www.example.co.kr을 각각 넣어 둘 다 같은 홈으로 열리는지 봅니다. - 주소창에
www.example.co.kr/robots.txt를 넣어 파일이 열리는지,Disallow: /한 줄로 전체를 막아 두지 않았는지 봅니다. - 같은 파일 끝에
Sitemap:줄이 있는지,Crawl-delay(요청 사이에 몇 초씩 쉬라고 요구하는 줄) 뒤 숫자가 1보다 크지 않은지 봅니다. - 방화벽이나 CDN(사이트 앞에서 페이지를 대신 내주는 중계 서비스)의 "봇 차단" 기능을 켰는지 호스팅 업체에 물어봅니다.
2단계. 답변 구조(10분)
- 주요 페이지 맨 위 제목 바로 아래 첫 문단이 "우리 회사는 무엇을 하는가"에 두세 문장으로 답하는지 봅니다(슬로건 한 줄이면 고칠 대상).
- 소제목이 "Overview" 같은 메뉴 이름이 아니라 고객이 실제로 묻는 질문 형태인지 봅니다.
- 비교나 절차가 긴 문단 대신 목록이나 표로 정리돼 있는지 봅니다.
3단계. 구조화 데이터(5분)
- 구글 리치 결과 테스트나 스키마 마크업 검사기에 회사 소개 페이지 주소를 넣고, 회사 정보(Organization)가 잡히는지, 오류가 없는지 봅니다.
4단계. 근거와 날짜(3분)
- 글과 안내 페이지에 "최종 수정일"이 보이는지 봅니다.
- 수치나 정책을 인용한 곳에 원문 링크가 달려 있는지 봅니다.
5단계. llms.txt(2분, 선택)
- 주소창에
www.example.co.kr/llms.txt를 넣어 봅니다. 없어도 괜찮습니다. 있다면 내용이 회사 소개 페이지와 어긋나지 않는지 봅니다.
손으로 하나씩 보기 번거롭다면 자동 진단으로 전체를 먼저 훑는 방법도 있습니다. 젠아이랩스의 GenAI AEO는 사이트가 AI 답변의 출처로 인용되기 쉬운 상태인지 5개 영역 19개 항목으로 진단하며, 무료 진단 방법은 글 끝에 적었습니다. 이 글에서 "진단 기준"이라고 적은 기준값은 이 진단이 정한 값입니다.
고치면 무엇이 달라지나?
가장 흔한 문제는 첫 화면입니다. 많은 회사 홈페이지가 제목 아래에 "스마트한 공장의 시작" 같은 한 줄 슬로건을 둡니다. 사람에게는 인상적이지만, 누가 "예지 보전이 뭐야?"라고 물었을 때 AI가 옮겨 줄 문장은 없습니다. 같은 자리를 아래처럼 바꾸면 AI가 그대로 인용할 수 있는 답이 생깁니다.
설비 예지 보전은 진동·온도·전류 같은 설비 데이터를 계속 모아 이상 신호를 찾고, 고장이 나기 전에 부품을 점검하거나 교체하는 정비 방식입니다. 정해진 주기마다 정비하는 방식보다 불필요한 교체와 갑작스러운 설비 정지를 함께 줄이는 것이 목적입니다.
젠아이랩스도 이 점검 항목들로 gensapps.com을 고쳤습니다. 아래 다섯 숫자는 모두 진단 대상 20페이지 기준으로 2026년 9월 12일부터 14일까지 잰 기록입니다. 점수가 크게 오른 때는 robots.txt를 정리한 71.1점 단계와, 최종 수정일 표기와 색인 대상 정리를 함께 한 81.9점 단계, 두 번이었습니다.
| 조치 | 조치 뒤 점수(20페이지 기준) |
|---|---|
| 첫 측정 | 61.1 |
| robots.txt 정리, llms.txt 추가 | 71.1 |
| 자주 묻는 질문 28개와 FAQPage 추가 | 72.8 |
| 회사·서비스 구조화 데이터 추가 | 73.7 |
| 최종 수정일 표기, 색인 대상 정리 | 81.9 |
표의 FAQPage는 자주 묻는 질문을 기계가 읽게 적는 구조화 데이터이고(3단계에서 설명합니다), 색인 대상 정리는 검색에 올릴 페이지와 뺄 페이지를 가려 두는 일입니다.
덧붙여 둘 점이 두 가지 있습니다. llms.txt는 점수에 들어가지 않으므로 71.1점으로 오른 몫은 robots.txt 정리에서 나왔습니다. 81.9점 단계는 색인 대상을 정리하면서 진단한 페이지 구성도 바뀌었을 수 있어, 오른 폭을 한 가지 조치의 효과로 떼어 볼 수 없습니다.
지금 점수는 측정 조건이 달라 따로 적습니다. 2026년 9월 16일 무료 진단(홈 포함 3페이지) 기준 85.8점이고, 제목 아래 답 문단, 질문형 소제목, sameAs가 남은 개선 항목으로 나와 있습니다.
점검 순서는 어떻게 정했나?
크롤러가 페이지를 가져가지 못하면 뒤의 항목을 아무리 고쳐도 AI가 읽지 못합니다. 그래서 접근부터 보고, 그다음 AI가 실제로 근거로 뽑아 가는 본문 구조, 그 본문을 기계용으로 한 번 더 설명하는 구조화 데이터, 날짜와 출처를 보며, 효과가 확인되지 않은 선택 항목인 llms.txt는 맨 뒤에 둡니다. 구글도 AI 기능에 나오려면 색인되어 검색 결과에 요약문과 함께 나올 수 있으면 충분하고, 별도의 AI용 파일이나 특별한 구조화 데이터는 필요 없다고 안내합니다8. 아래 표의 오른쪽 칸은 앞에서 소개한 자동 진단이 같은 내용을 확인하는 항목입니다1.
flowchart TD
S1["1단계 크롤러 접근
응답 · robots.txt · 봇 차단"] --> S2["2단계 답변 구조
답 문단 · 질문형 소제목 · 제목 단계"]
S2 --> S3["3단계 구조화 데이터
Organization · Article · FAQPage"]
S3 --> S4["4단계 근거와 날짜
수정일 · 외부 출처 · 분량"]
S4 --> S5["5단계 llms.txt
선택, 점수 밖"]
| 단계 | 무엇을 보나 | 자동 진단 항목1 |
|---|---|---|
| 1 | 크롤러 접근 | 정상 응답, AI 크롤러 허용, Crawl-delay, 사이트맵 선언, 규칙 묶음 |
| 2 | 답변 구조 | 질문형 소제목, 제목 아래 답 문단, 제목 단계, 목록·표 |
| 3 | 구조화 데이터 | JSON-LD 유무, 문법, 페이지 종류 표시(타입), 회사 정보, sameAs, 글쓴이 |
| 4 | 근거와 날짜(콘텐츠 깊이) | 본문 분량, 최종 수정일, 외부 출처 |
| 5 | llms.txt | 점수에 넣지 않음(선택) |
1단계: AI 크롤러가 들어올 수 있나?
크롤러에는 OpenAI의 OAI-SearchBot, Anthropic의 Claude-SearchBot, 네이버의 Yeti처럼 회사마다 이름(user-agent, 방문할 때 스스로 밝히는 이름표)이 있습니다. robots.txt는 사이트 최상위 경로에 두는 텍스트 파일로, 건물 입구의 출입 안내판과 같습니다. "이 층은 관계자 외 출입 금지"라고 적어 두면 규칙을 지키는 크롤러는 따르지만, 강제로 잠그는 자물쇠는 아닙니다.
1-1. 페이지가 정상 응답하는지 확인
홈과 주요 페이지가 200 응답을 주는지 봅니다. 응답 코드는 서버가 요청을 받을 때마다 돌려주는 세 자리 숫자로, 200은 "정상, 여기 페이지가 있다"는 뜻입니다. 리다이렉트(redirect, 한 주소로 들어온 방문자를 다른 주소로 넘기는 일)가 여러 번 이어지거나 로그인 화면으로 넘어가면 크롤러는 본문을 받지 못합니다.
- 직접 확인하기: 점검표 첫 항목처럼
www가 있는 주소와 없는 주소를 각각 엽니다. 한쪽이 "사이트에 연결할 수 없음"으로 나오거나, 주소가 여러 번 바뀌다 로그인 화면이 뜨면 문제입니다. - 개발 담당자에게 요청하기: "
www가 있는 주소와 없는 주소 중 하나를 대표 주소로 정하고, 다른 쪽은 한 번의 영구 이동(301)으로 넘겨 주세요. 홈과 주요 페이지가 로그인 없이 200으로 열리는지 확인해 주세요."
확인 명령은 글 끝 "개발자를 위한 심화"의 "응답과 봇 차단 확인 명령"에 있습니다.
1-2. robots.txt 확인
robots.txt에서 볼 것은 네 가지입니다. AI 크롤러를 의도치 않게 막지 않았는지, 규칙이 User-agent 줄 아래에 제대로 들어 있는지, Crawl-delay를 크게 두지 않았는지, Sitemap: 줄이 있는지입니다. 크롤러 이름별 용도와 AI 학습은 막고 AI 검색 노출은 허용하는 식의 목적별 설정은 robots.txt로 AI 크롤러 설정하기에서 자세히 다룹니다.
- 직접 확인하기: 점검표대로 파일을 열었는데 열리지 않으면 제작 업체에 만들어 달라고 합니다. 열리면 전체 차단 여부(
User-agent: *바로 아래Disallow: /한 줄)와 함께,GPTBot,ClaudeBot,Google-Extended같은 이름이 적혀 있다면 회사가 의도한 설정인지 봅니다. - 개발 담당자에게 요청하기: "AI 검색 노출은 허용하고 관리 화면만 막는 robots.txt로 정리해 주세요. 모든 규칙이
User-agent줄 아래에 들어가게 하고, 한 묶음 안에는 빈 줄을 넣지 말아 주세요. AI 크롤러에 걸린Crawl-delay는 빼거나 1초 이하로 줄이고, 파일 끝에는 사이트맵 주소를 절대 주소로 적어 주세요."
Crawl-delay는 요청 사이 간격을 초 단위로 요구하는 비표준 지시어(robots.txt 표준인 RFC 9309에 없어서 따를지 말지를 크롤러마다 정하는 줄)입니다. 값이 크면 크롤러가 정해진 시간 안에 페이지를 몇 장밖에 가져가지 못합니다. gensapps.com도 한때 Crawl-delay: 10을 두었다가 점검에서 뺐습니다.
Sitemap: 줄은 손이 가장 덜 가는 항목인데도 국내 주요 사이트에서 빠뜨린 곳이 많았습니다. 해외와 견준 수치는 국내 주요 사이트 103곳 첫 관측에 있습니다.
규칙 문법, 설정 예시, 빈 줄 때문에 규칙이 무효가 된 gensapps.com 사례는 글 끝 "개발자를 위한 심화"의 "robots.txt 설정 예시와 규칙"에 옮겨 두었습니다.
1-3. robots.txt 밖에서 막히지 않는지 확인
robots.txt와 별개로 방화벽이나 CDN의 봇 차단 기능이 크롤러 요청을 막는 경우가 있습니다. CDN(Content Delivery Network, 콘텐츠 전송 네트워크)은 방문자와 가까운 곳에서 페이지를 대신 내주는 중계 서비스로, Cloudflare가 대표적입니다. 이런 서비스에는 "AI 봇 차단"을 켜는 설정이 따로 있는 경우가 많습니다. 구글도 AI 기능에 나타나려면 robots.txt와 함께 CDN·호스팅 설정에서도 수집이 허용되어 있어야 한다고 안내합니다8. 국내 주요 사이트 관측에서도 robots.txt 대신 HTTP 403 응답으로 관측 크롤러를 거절한 곳이 있었습니다. 403은 "요청은 알아들었지만 들여보내지 않겠다"는 거절 응답입니다. 사람이 브라우저로 보면 멀쩡히 열리는 사이트도 크롤러에게는 403을 줄 수 있습니다. 안내판(robots.txt)은 열어 두고 경비원(방화벽)이 문 앞에서 돌려보내는 것과 같습니다.
- 직접 확인하기: 브라우저로는 재현하기 어렵습니다. 호스팅 업체에 묻거나, 쓰고 있는 호스팅이나 CDN 관리 화면에 "봇 차단", "Bot Fight", "AI 크롤러 차단" 같은 메뉴가 켜져 있는지 봅니다.
- 개발 담당자에게 요청하기: "OAI-SearchBot, PerplexityBot, Claude-SearchBot 이름으로 홈에 요청했을 때 403이 나오는지 확인해 주세요. 방화벽 로그에서 OpenAI와 Perplexity가 공개한 크롤러 IP 주소의 요청이 어떻게 처리됐는지도 봐 주세요."
2단계: 페이지가 질문에 바로 답하나?
AI 답변은 페이지에서 질문에 맞는 내용을 골라 근거로 씁니다. 제목과 문단의 구조가 분명할수록 어느 부분이 무슨 질문에 답하는지 가려내기 쉽습니다. 여기서 제목 단계는 HTML(웹 페이지를 짜는 표시 언어로, "페이지 소스 보기"를 누르면 보이는 원문)에 적는 제목 등급을 말합니다. H1은 페이지에 하나만 두는 가장 큰 제목, H2는 그 아래 큰 소제목입니다. 신문으로 치면 1면 머리기사 제목과 기사 안 중간 제목에 해당합니다.
| 항목 | GenAI AEO 진단 기준(업계 표준이 아님) | 고칠 예 |
|---|---|---|
| 제목 아래 답 문단 | H1 바로 뒤 첫 문단이 80자 이상 | "스마트한 공장의 시작" 같은 한 줄 슬로건 |
| 질문형 소제목 | 물음표로 끝나거나 "~란?" 형태, 3개면 만점 | "Overview", "Solution" 같은 영어 메뉴 이름 |
| 제목 단계 | H1은 1개, H2는 2개 이상 | 디자인 때문에 로고를 H1으로, 본문 제목을 이미지로 |
| 목록·표 | 목록이나 표가 1개 이상 | 비교 내용을 긴 문단 하나에 이어 씀 |
제목 단계는 국내 사이트가 가장 많이 놓친 항목입니다. 젠아이랩스의 2026년 9월 17일 관측에서 점수가 나온 국내 70곳 가운데 H1 하나에 H2 두 개 이상을 둔 곳은 11.4%였고, 해외 64곳은 45.3%였습니다. 제목 바로 아래 80자 이상 답 문단을 둔 곳은 국내 2.9%, 해외 10.9%였습니다.
- 직접 확인하기: 페이지에서 마우스 오른쪽 버튼을 눌러 "페이지 소스 보기"를 엽니다. Ctrl+F(맥은 Cmd+F)로
<h1을 찾아 몇 개인지 세고,<h2도 셉니다. 첫<h1바로 뒤에 오는 문장이 질문에 답하는 두세 문장인지 봅니다. 소제목을 고객 질문으로 바꾸는 일과 답 문단을 쓰는 일은 글을 쓰는 사람이 직접 할 수 있습니다. - 개발 담당자에게 요청하기: "페이지마다 H1은 본문 제목 하나로, 로고는 H1이 아니게 해 주세요. 이미지로 넣은 제목은 글자로 바꿔 주세요. 첫 화면 디자인은 유지하되, HTML 순서상 H1 바로 뒤에 답 문단이 오게 해 주세요."
화면 모양과 HTML 순서는 따로 정할 수 있어서, 첫 화면을 큰 이미지와 짧은 문구로 채우는 디자인도 그대로 둔 채 답 문단을 넣을 수 있습니다. 예지 보전 페이지로 만든 HTML 뼈대는 글 끝 "개발자를 위한 심화"의 "답변 구조 HTML 뼈대"에 있습니다.
3단계: 구조화 데이터로 페이지 설명하기
구조화 데이터(structured data)는 페이지의 회사명, 글쓴이, 날짜, 질문과 답 같은 정보를 schema.org의 항목 이름으로 적은 데이터입니다. schema.org는 검색 회사들이 함께 정한 "기계가 읽는 항목 이름 사전"입니다. 사람용 명함 옆에 붙인 기계용 바코드라고 생각하면 쉽습니다. 사람은 화면의 회사 소개를 읽고, 기계는 바코드를 찍어 이름·주소·연락처를 틀림없이 옮깁니다. 적는 형식은 JSON-LD, 마이크로데이터(Microdata), RDFa 세 가지가 있는데, 구글은 구현하고 관리하기 쉬운 JSON-LD를 권합니다11. JSON-LD는 페이지 안에 화면에는 보이지 않게 넣는 데이터 묶음으로, <script type="application/ld+json"> 안에 JSON으로 씁니다. 점검표에 나온 리치 결과(rich results)는 검색 결과에 별점, 자주 묻는 질문 펼침처럼 일반 링크보다 풍부하게 나오는 모양을 말합니다11.
앞에서 적었듯 구글은 AI 기능에 나오는 데 특별한 구조화 데이터가 필요하지 않다고 밝혔습니다8. 그래도 회사 이름·주소·글쓴이처럼 틀리면 안 되는 사실을 여러 AI 서비스에 같은 형태로 주는 수단이라 2단계 다음에 봅니다.
- 직접 확인하기: 점검표 3단계의 두 검사 도구에 회사 소개 페이지뿐 아니라 블로그 글 주소도 넣어 "Article" 항목이 잡히는지 봅니다. "페이지 소스 보기"에서
application/ld+json을 찾아 보는 것도 방법입니다. 여기서 보이면 서버가 보낸 HTML 안에 들어 있다는 뜻입니다. - 개발 담당자에게 요청하기: 아래 3-1~3-2의 항목을 그대로 전합니다. 코드 예시는 글 끝 "개발자를 위한 심화"의 "JSON-LD 예시"에 있습니다.
3-1. 회사 정보(Organization)
회사 소개 페이지나 사이트 공통 머리에 한 벌을 둡니다. 진단 기준은 다음 여덟 항목(키, 정보를 적는 칸의 이름)이 있는지 봅니다. name(회사명), url(대표 주소), logo(로고 그림 주소), description(한 줄 소개), sameAs, address(주소), contactPoint(연락처), knowsAbout(전문 분야). sameAs는 "이 회사와 같은 주체"라는 뜻으로, 회사가 운영하는 공식 채널(링크드인, 네이버 블로그, 유튜브 등) 주소를 적는 칸입니다. 공식 채널 주소 2개 이상을 만점 기준으로 봅니다.
sameAs에는 회사가 직접 운영하는 공식 채널만 넣습니다. 보도 기사나 남이 만든 소개 페이지는 넣지 않습니다.- 이름·주소·연락처는 화면에 보이는 회사 정보, 사업자 정보와 글자 하나까지 같게 적습니다.
- 여덟 키를 모두 채운 사이트는 드뭅니다. 국내외 주요 사이트 관측에서도 이 항목의 만점은 나오지 않았습니다(국내 주요 사이트 103곳 첫 관측).
3-2. 글, 글쓴이, 자주 묻는 질문
블로그 글과 고객 사례에는 그 페이지를 설명하는 글(Article) 정보와 사람 글쓴이(Person)를, 자주 묻는 질문 페이지에는 본문에 보이는 질문과 답만 담은 FAQPage를 둡니다. 구글 검색에서 FAQ 리치 결과는 2023년 8월부터 잘 알려진 정부·보건 사이트에만 보였고, 2026년 5월 7일부터는 아예 나오지 않습니다12. 한 페이지에 같은 글 정보가 두 벌 들어가지 않았는지, 화면에 없는 질문을 마크업에만 넣지 않았는지는 개발자 심화의 "JSON-LD 예시" 아래 기준으로 확인합니다.
3-3. 문법과 넣는 위치
쉼표 하나만 잘못 들어가도 그 블록을 읽지 못합니다. 위 검사 도구에서 오류가 나오면 개발 담당자에게 화면을 캡처해 전합니다.
넣는 위치도 중요합니다. "서버가 보낸 HTML"은 페이지를 열 때 서버가 처음 보내 주는 원본 글로, 자바스크립트(브라우저에서 돌아가며 화면을 나중에 바꾸는 프로그램)가 덧붙이는 내용은 빠진 상태입니다. 구글은 자바스크립트로 넣은 JSON-LD도 읽을 수 있다고 밝혔지만11, 자바스크립트를 실행하지 않는 크롤러는 원본만 받습니다. 여러 AI 크롤러에 같은 정보를 주려면 서버가 보내는 HTML에 넣는 편이 안전합니다. 문법만 빠르게 확인하는 명령은 글 끝 "개발자를 위한 심화"의 "JSON-LD 문법 확인 명령"에 있습니다.
4단계: 근거와 날짜 표시
4-1. 최종 수정일
보이는 날짜와 기계가 읽는 날짜를 함께, 같은 값으로 적습니다. 화면에 "최종 수정일 2026년 9월 15일"을 보여 주고, 같은 날짜를 HTML의 <time> 태그에도 적습니다.
JSON-LD의 dateModified와 사이트맵의 lastmod도 같은 날짜로 맞춥니다. lastmod는 사이트맵 파일에 페이지마다 적는 "마지막으로 바뀐 날"입니다. 구글은 이 값이 실제 수정 시점과 꾸준히 맞을 때만 쓴다고 밝혔습니다13. 날짜는 내용이 실제로 바뀐 날에만 바꿉니다. 배포할 때마다 오늘 날짜를 자동으로 넣으면 날짜가 아무 정보도 주지 못합니다.
- 직접 확인하기: 점검표에서 수정일이 보였다면, 내용을 고친 날에 그 날짜도 바뀌는지 한 번 더 봅니다.
- 개발 담당자에게 요청하기: "화면의 수정일, JSON-LD의
dateModified, 사이트맵의lastmod를 같은 값으로 맞추고, 배포 날짜가 아니라 내용이 바뀐 날짜가 들어가게 해 주세요."
4-2. 외부 출처 링크
수치나 정책을 인용하면 원문 링크를 답니다. 진단은 자기 사이트 주소(도메인)와 그 하위 주소를 뺀 외부 사이트 3곳으로 가는 링크를 만점으로 칩니다. 링크 수보다 원문인지가 중요합니다. 보도 기사를 거친 수치라면 발표 기관의 원문을 찾아 링크하고, "최대 40%"를 "평균 40%"로 옮기는 식의 오차가 없는지 확인합니다. 이 일은 글을 쓰는 사람이 직접 할 수 있습니다.
4-3. 본문 분량
진단 기준은 보이는 글자 3,000자를 본문 분량 항목의 만점으로 둡니다. 콘텐츠 깊이 영역 배점 15점 가운데 일부입니다. 질문에 답하는 내용 없이 길이만 늘리면 2단계 항목이 오히려 나빠집니다. 구글도 페이지 길이에 이상적인 값은 없다고 적었습니다10.
5단계: llms.txt를 둘 것인가?
llms.txt는 AI 에이전트(사람 대신 웹 페이지를 찾아 읽고 일을 처리하는 AI 프로그램)가 사이트를 활용하는 데 필요한 정보를 마크다운(Markdown, # 같은 기호로 제목과 목록을 표시하는 간단한 글 형식) 파일 하나로 요약해 두자는 제안입니다. 매장 입구에 둔 안내 브로슈어와 비슷합니다. 2024년 9월 Jeremy Howard가 제안했고, 2026년 8월 2판에서 /docs/llms.txt 같은 하위 경로 파일은 자기 경로 아래 페이지를 다룬다는 규칙이 정해졌습니다9. 형식은 순서가 정해져 있습니다. 반드시 필요한 것은 사이트 이름을 적은 H1 하나이고, 그 뒤에 요약 인용 블록, 설명 문단, H2로 나눈 링크 목록이 선택으로 옵니다.
효과는 따로 따져야 합니다. 구글은 구글 검색(생성형 AI 기능 포함)이 llms.txt 같은 AI 텍스트 파일을 쓰지 않는다고 밝혔습니다10. llms.txt는 크롤러 접근이나 본문 구조를 대신하지 못합니다. 앞에서 소개한 자동 진단도 llms.txt 유무를 점수에 넣지 않습니다. 그래서 이 목록의 맨 뒤에 두었습니다. 그래도 둔다면 사이트의 다른 페이지와 사실이 어긋나지 않게 관리해야 합니다.
작성법과 둘 때 주의할 점은 llms.txt란?에 따로 정리했습니다. 예시테크용 예시 파일은 글 끝 "개발자를 위한 심화"의 "llms.txt 예시"에 있습니다.
다섯 단계를 한 번에 확인하려면
위 점검표로 한 항목씩 볼 수도 있지만, 사이트 주소를 넣어 다섯 영역을 한 번에 재는 편이 빠릅니다. GenAI AEO 무료 진단은 전체 19개 항목 가운데 자바스크립트 실행 전후 비교를 뺀 18개 항목을 홈 포함 3페이지에서 확인하고, 기준에 못 미친 항목마다 이 글과 같은 형태의 수정 예시 코드를 결과 화면에 보여 줍니다. 그 예시는 개발 담당자에게 그대로 전하면 됩니다. 설정을 고친 뒤에는 같은 조건으로 다시 진단해, 기준에 못 미쳤던 항목이 통과로 바뀌었는지 확인합니다. 무료 진단 시작하기
관련 글: robots.txt로 AI 크롤러 설정하기 · llms.txt란? · 국내 주요 사이트 103곳 첫 관측 · 생성형 AI 검색 최적화(GEO)란?
개발자를 위한 심화
이 부분은 직접 구현하는 개발자를 위한 내용입니다.
응답과 봇 차단 확인 명령
아래는 www가 있는 주소와 없는 주소가 몇 번 넘겨진 뒤 어떤 응답 코드로 끝나는지 보는 명령입니다.
curl -sIL https://www.example.co.kr/ | grep -iE "^HTTP|^location"
curl -sIL https://example.co.kr/ | grep -iE "^HTTP|^location"
사용자 에이전트만 바꿔 요청하고 응답 코드를 비교하면 봇 차단 여부를 1차로 확인할 수 있습니다. 아래는 크롤러 이름 넷으로 홈을 요청해 응답 코드를 나란히 출력하는 명령입니다.
for ua in "OAI-SearchBot/1.4" "PerplexityBot/1.0" "Claude-SearchBot" "Mozilla/5.0"; do
printf "%-20s " "$ua"
curl -s -o /dev/null -w "%{http_code}\n" -A "$ua" https://www.example.co.kr/
done
크롤러 이름에 따라 403이 나오면 봇 차단 설정을 확인합니다. 방화벽이 IP 주소로 진짜 크롤러인지 확인하는 경우에는 이 방법으로 재현되지 않습니다. OpenAI와 Perplexity는 크롤러 IP 목록을 공개하고 있으므로36, 방화벽 로그에서 그 주소의 요청이 어떻게 처리됐는지 함께 봅니다.
robots.txt 설정 예시와 규칙
robots.txt 표준인 RFC 9309에 따르면 크롤러는 자기 이름이 적힌 묶음을 찾아 그 규칙을 따르고, 같은 이름의 묶음이 여러 개면 하나로 합쳐 읽습니다. 그런 묶음이 없는 크롤러만 User-agent: * 묶음으로 갑니다. Allow와 Disallow가 겹치면 경로가 더 긴(더 구체적인) 규칙이 우선합니다2. 규칙에 걸리지 않는 경로는 허용이므로 Allow: /는 따로 적지 않아도 됩니다. 위에서부터 차례로 읽다가 처음 맞는 규칙을 따르는 파서(parser, 파일을 읽어 규칙으로 해석하는 프로그램)도 있어서, 아래 예시는 Allow: /를 빼고 막을 경로만 적었습니다.
예시 A. AI 검색과 학습 모두 허용(관리 화면만 막음)
User-agent: *
Disallow: /admin/
Disallow: /login
Sitemap: https://www.example.co.kr/sitemap.xml
예시 B. AI 학습용 수집은 막고 AI 검색 노출은 허용
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: *
Disallow: /admin/
Disallow: /login
Sitemap: https://www.example.co.kr/sitemap.xml
예시 B를 쓸 때 알아 둘 점이 있습니다.
- OpenAI는 GPTBot(모델 학습)과 OAI-SearchBot(ChatGPT 검색 노출) 설정이 서로 독립이라고 안내합니다. 예시 B에서 OAI-SearchBot은
*묶음을 따라 허용됩니다. robots.txt를 바꾼 뒤 검색 결과에 반영되기까지 24시간쯤 걸릴 수 있습니다3. - Anthropic은 ClaudeBot(학습), Claude-SearchBot(검색 품질), Claude-User(사용자 요청)를 나눠 두었고 세 크롤러 모두 robots.txt를 따릅니다. 예시 B는 ClaudeBot만 막습니다4.
- 구글의 Google-Extended는 요청을 보내는 크롤러가 따로 없는 제어용 이름입니다. 구글이 수집한 내용을 Gemini 모델 학습과 근거 활용에 쓸지를 정하며, 구글 검색 노출과 순위에는 영향을 주지 않습니다5. 막기 전에 회사의 콘텐츠 방침을 먼저 정합니다.
- 이름 묶음을 만든 크롤러는
*묶음의Disallow를 따르지 않습니다. 관리 화면처럼 모두에게 막아야 할 경로가 있는데 어떤 크롤러에게 이름 묶음을 따로 만들어 일부를 허용한다면, 같은Disallow를 그 묶음에도 적어야 합니다. - ChatGPT-User와 Perplexity-User처럼 사용자가 요청해 방문하는 에이전트에는 robots.txt가 적용되지 않을 수 있다고 두 운영사가 밝혔습니다36.
앞에서 소개한 자동 진단은 크롤러 이름마다 robots.txt를 따로 해석해 막힌 이름을 알려 줍니다. 대상은 OAI-SearchBot, GPTBot, ChatGPT-User, ClaudeBot, PerplexityBot, Google-Extended, Googlebot, Bingbot, Yeti(네이버) 아홉 개입니다.
규칙은 User-agent 묶음 안에
Allow, Disallow는 User-agent 줄 아래에 있어야 적용됩니다. RFC 9309는 어느 묶음에도 속하지 않은 규칙을 무시하라고 권합니다2. 파일 맨 위에 User-agent 없이 Disallow를 쓰면 어느 크롤러에도 적용되지 않습니다. 아래 두 파일은 잘못 쓴 예와 고친 예입니다.
# 고칠 예: 첫 줄은 묶음 밖에 있어 적용되지 않는다
Disallow: /admin/
User-agent: *
Disallow: /login
# 고친 예
User-agent: *
Disallow: /admin/
Disallow: /login
한 묶음 안에는 빈 줄을 넣지 않는 편이 안전합니다. 빈 줄은 RFC 9309 문법상 허용되지만, 빈 줄을 묶음의 끝으로 읽는 파서(파이썬 표준 라이브러리의 urllib.robotparser 등)가 아직 쓰입니다. gensapps.com은 2026년 9월 12일 점검에서 User-agent: * 아래 규칙 사이에 빈 줄과 주석을 넣어 둔 탓에, 이 파서로 읽으면 Disallow 규칙이 모두 무효가 되는 것을 확인하고 고쳤습니다. 지금 gensapps.com robots.txt의 머리 주석에 그 이유를 적어 두었습니다.
Crawl-delay는 짧게 두거나 빼기
Crawl-delay는 RFC 9309에 없는 지시어라 지원 여부가 크롤러마다 다릅니다. Anthropic은 지원한다고 밝혔습니다4. AI 크롤러에 걸린 Crawl-delay가 1초를 넘으면 진단 기준에서는 미달입니다.
Sitemap 줄 적기
Sitemap: 줄은 어느 묶음에도 속하지 않는 지시어라 파일 끝에 둡니다. 절대 주소로 적고, 사이트맵이 여러 개면 줄을 여러 개 씁니다. 네이버도 robots.txt에 사이트맵 위치를 적어 수집을 도울 수 있다고 안내합니다7. 아래는 사이트맵 두 개를 선언한 예입니다.
Sitemap: https://www.example.co.kr/sitemap.xml
Sitemap: https://www.example.co.kr/blog/sitemap.xml
답변 구조 HTML 뼈대
아래는 H1 바로 뒤 답 문단, 질문형 H2, 표와 목록을 갖춘 예지 보전 페이지의 HTML 뼈대입니다.
<h1>설비 예지 보전이란?</h1>
<p>설비 예지 보전은 진동·온도·전류 같은 설비 데이터를 계속 모아 이상 신호를
찾고, 고장이 나기 전에 부품을 점검하거나 교체하는 정비 방식입니다. 정해진 주기마다
정비하는 방식보다 불필요한 교체와 갑작스러운 설비 정지를 함께 줄이는 것이 목적입니다.</p>
<h2>예지 보전은 예방 정비와 무엇이 다른가요?</h2>
<table> ... </table>
<h2>도입하려면 어떤 데이터가 필요한가요?</h2>
<ul>
<li>설비별 진동 데이터(가속도 센서)</li>
<li>정비 이력과 고장 기록</li>
</ul>
<h2>도입 기간은 얼마나 걸리나요?</h2>
<p>...</p>
JSON-LD 예시
아래 세 블록은 회사 정보, 글과 글쓴이, 자주 묻는 질문을 JSON-LD로 적은 예입니다. @id는 JSON-LD에서 한 대상에 붙이는 고유 식별 주소입니다. 회사 정보에 "@id": ".../#organization"을 한 번 붙여 두면, 글의 publisher나 글쓴이의 worksFor에서 같은 @id만 적어 "앞에서 설명한 그 회사"를 가리킬 수 있습니다.
아래는 회사 소개 페이지나 사이트 공통 머리에 넣는 회사 정보(Organization)입니다.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://www.example.co.kr/#organization",
"name": "예시테크",
"alternateName": "Example Tech",
"url": "https://www.example.co.kr/",
"logo": "https://www.example.co.kr/static/logo.png",
"description": "제조 설비 데이터를 모아 고장을 미리 알려 주는 예지 보전 소프트웨어 회사",
"address": {
"@type": "PostalAddress",
"addressCountry": "KR",
"addressRegion": "서울",
"addressLocality": "강남구",
"streetAddress": "테헤란로 000, 0층"
},
"contactPoint": {
"@type": "ContactPoint",
"contactType": "customer support",
"email": "contact@example.co.kr",
"telephone": "+82-2-0000-0000",
"availableLanguage": ["ko", "en"]
},
"sameAs": [
"https://www.linkedin.com/company/example-tech",
"https://blog.naver.com/example-tech",
"https://www.youtube.com/@example-tech"
],
"knowsAbout": ["예지 보전", "설비 데이터 분석", "스마트 팩토리"]
}
</script>
아래는 블로그 글 페이지에 넣는 글(Article)과 글쓴이(Person)입니다.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "설비 진동 데이터로 베어링 고장을 미리 찾는 법",
"description": "진동 센서 데이터에서 베어링 이상 신호를 찾는 기준과 현장 적용 순서",
"datePublished": "2026-09-01T09:00:00+09:00",
"dateModified": "2026-09-15T14:20:00+09:00",
"inLanguage": "ko-KR",
"author": {
"@type": "Person",
"name": "홍길동",
"jobTitle": "데이터 분석 팀장",
"worksFor": {"@id": "https://www.example.co.kr/#organization"},
"sameAs": ["https://www.linkedin.com/in/example-hong"]
},
"publisher": {"@id": "https://www.example.co.kr/#organization"},
"mainEntityOfPage": "https://www.example.co.kr/blog/bearing-vibration"
}
</script>
아래는 본문에 보이는 질문과 답을 그대로 옮긴 자주 묻는 질문(FAQPage)입니다.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "설치에 공장 가동을 멈춰야 합니까?",
"acceptedAnswer": {
"@type": "Answer",
"text": "멈추지 않아도 됩니다. 센서는 설비 외부에 부착하고, 데이터 수집 장치는 기존 네트워크와 분리해 설치합니다."
}
}
]
}
</script>
글(Article)과 글쓴이(Person)
블로그 글, 가이드, 고객 사례 페이지에는 페이지 성격을 설명하는 타입을 둡니다. Organization·WebSite·BreadcrumbList만 있으면 사이트 공통 정보일 뿐 그 페이지를 설명하지 않습니다. 글쓴이가 사람이면 Person으로 적습니다. 진단 기준은 글쓴이가 Person이 아니면 부분 점수를 줍니다.
한 페이지에 같은 글을 설명하는 Article과 BlogPosting을 따로 두고 글쓴이나 날짜를 다르게 적는 경우가 흔합니다. 테마와 플러그인이 각각 마크업을 넣을 때 생기는 일입니다. 한 벌만 남깁니다.
자주 묻는 질문(FAQPage)
- 본문에 보이는 질문과 답만 넣습니다. 화면에 없는 질문을 마크업에만 넣지 않습니다.
- 앞에서 적었듯 FAQ 리치 결과는 구글 검색에서 더 나오지 않으므로, 리치 결과를 기대하기보다 본문의 질문과 답을 기계가 읽기 쉬운 형태로 함께 주는 용도로 씁니다.
- 자주 묻는 질문을 설정 파일 하나에 두고 그 파일에서 본문과 FAQPage를 함께 만들면 두 곳이 어긋날 일이 없습니다.
JSON-LD 문법 확인 명령
페이지에서 JSON-LD 블록을 뽑아 문법만 먼저 확인하는 간단한 방법입니다.
curl -s https://www.example.co.kr/about | python3 -c '
import sys, re, json
html = sys.stdin.read()
blocks = re.findall(r"<script[^>]*application/ld\+json[^>]*>(.*?)</script>", html, re.S)
print("JSON-LD 블록", len(blocks), "개")
for i, b in enumerate(blocks, 1):
try:
d = json.loads(b)
t = d.get("@type") if isinstance(d, dict) else "(목록)"
print(i, "문법 정상", t)
except json.JSONDecodeError as e:
print(i, "문법 오류", e)
'
이 명령은 서버가 보낸 HTML만 봅니다. 자바스크립트로 구조화 데이터를 넣는 사이트라면 여기서 블록이 0개로 나옵니다. 자바스크립트를 실행하지 않는 크롤러는 이 명령과 같은 결과를 받습니다. 타입별 필수 속성은 구글 리치 결과 테스트와 schema.org 검사기로 따로 확인합니다.
최종 수정일 HTML
아래는 화면에 보이는 날짜와 기계가 읽는 날짜를 한 줄에 같이 적는 예입니다.
<p class="updated">최종 수정일
<time datetime="2026-09-15">2026년 9월 15일</time></p>
llms.txt 예시
아래는 llmstxt.org 형식(H1, 요약 인용 블록, 설명 문단, H2 링크 목록)을 따른 예시테크의 llms.txt입니다.
# 예시테크
> 예시테크는 제조 현장의 설비 데이터를 모아 고장을 미리 알려 주는 예지 보전 소프트웨어를 만드는 회사입니다. 서울에 본사가 있고 국내 제조 기업에 서비스를 제공합니다.
사업자 정보와 연락처는 회사 소개 페이지와 같습니다. 각 서비스의 제공 상태는 서비스 페이지 표기를 따릅니다.
## 회사
- [회사 소개](https://www.example.co.kr/about): 설립 연도, 사업 분야, 사업자 정보, 연락처
- [고객 사례](https://www.example.co.kr/cases): 업종별 도입 사례와 도입 범위
## 서비스
- [설비 예지 보전](https://www.example.co.kr/products/predictive): 지원 설비, 도입 절차, 요금 문의 방법
- [자주 묻는 질문](https://www.example.co.kr/faq): 보안, 설치 방식, 계약 기간
## Optional
- [기술 블로그](https://www.example.co.kr/blog): 설비 데이터 분석 글
gensapps.com은 llms.txt와 페이지 본문 전체를 모은 llms-full.txt를 빌드할 때 자동으로 만듭니다. 서비스마다 [운영 중], [베타], [출시 예정]을 붙여 서비스 카탈로그 페이지와 같은 상태를 적습니다. 손으로 따로 쓰면 페이지와 어긋나기 쉽기 때문입니다.
참고 자료
| 번호 | 자료 | 다루는 내용 | 발행처·날짜(확인일) |
|---|---|---|---|
| 1 | GenAI AEO 진단 기준 | 5개 영역 19개 항목과 기준값 | GenAI Labs, 기준 2026.09.15-2 판(2026-09-17) |
| 2 | RFC 9309 Robots Exclusion Protocol | 묶음 선택·병합, 경로 길이 규칙, 묶음 밖 규칙 | IETF, 2022-09(2026-09-17) |
| 3 | Overview of OpenAI Crawlers | GPTBot, OAI-SearchBot, ChatGPT-User, IP 목록 | OpenAI(2026-09-17) |
| 4 | Does Anthropic crawl data from the web | ClaudeBot, Claude-SearchBot, Claude-User, Crawl-delay | Anthropic(2026-09-17) |
| 5 | Google's common crawlers: Google-Extended | Google-Extended의 성격과 영향 범위 | Google, 2026-07-14 갱신(2026-09-17) |
| 6 | Perplexity Crawlers | PerplexityBot, Perplexity-User, IP 목록 | Perplexity(2026-09-17) |
| 7 | robots.txt 설정하기 | Yeti와 robots.txt, 사이트맵 지정 | 네이버 서치어드바이저(2026-09-17) |
| 8 | AI features and your website | AI 기능 요건, CDN·호스팅의 수집 허용, 별도 파일·구조화 데이터 불필요 | Google Search Central, 2025-12-10 갱신(2026-09-27) |
| 9 | The /llms.txt file, v2 | llms.txt 제안과 형식 | Jeremy Howard, 2026-08-10 수정(2026-09-17) |
| 10 | Optimizing your website for generative AI features on Google Search | llms.txt와 페이지 길이를 보는 구글 입장 | Google Search Central, 2026-07-10 갱신(2026-09-17) |
| 11 | Introduction to structured data markup in Google Search | JSON-LD 권장, 자바스크립트로 넣은 JSON-LD, 리치 결과 테스트 | Google Search Central, 2025-12-10 갱신(2026-09-27) |
| 12 | Search Central documentation updates | FAQ 리치 결과 종료(2026-05-07) | Google Search Central(2026-09-27) |
| 13 | Build and submit a sitemap | 사이트맵 lastmod를 쓰는 조건 |
Google Search Central, 2026-07-08 갱신(2026-09-27) |
| 14 | Schema Markup Validator | schema.org 구조화 데이터 검사 | Schema.org(2026-09-27) |
글쓴이 박수현(젠아이랩스 대표) with AI (Claude Opus 5). 위 표의 gensapps.com 점수는 GenAI Labs가 자사 사이트를 고치며 남긴 기록입니다. AI 실무서로는 『바이브 코딩의 시대, 프롬프트를 넘어 컨텍스트 엔지니어링으로』 등 네 권을 썼습니다.