김
GEO
JSON-LD 스키마·llms.txt 실전 설정법 — 복사해 쓰는 코드
JSON-LD·llms.txt 실전 코드, 복사 전에 무엇부터 확인하나요?
JSON-LD 스키마와 llms.txt는 코드를 몰라도 완성된 예시를 복사해 값만 바꾸면 됩니다. FAQPage·Article JSON-LD와 llms.txt·robots.txt 코드를 그대로 붙여 넣고 WordPress에 삽입해 검증하면 끝납니다.
개념과 판단은 앞선 두 편이 맡습니다. 스키마가 왜 필요하고 어떤 타입을 언제 쓰는지는 코드를 몰라도 만드는 구조화 데이터에, llms.txt가 무엇이고 AI 크롤러를 어떻게 대할지는 llms.txt와 AI 크롤러에 정리돼 있습니다. 남은 것은 복사해 붙일 실제 코드입니다.
필요한 코드는 네 벌의 JSON-LD, 한 벌의 llms.txt, 한 벌의 robots.txt로 정리됩니다. 각 코드가 언제 쓰이는지 먼저 인덱스로 잡아 두면 자기 페이지에 필요한 것만 골라 복사할 수 있습니다.
| 코드 | 언제 쓰나 | 형식 |
|---|---|---|
| FAQPage JSON-LD | 질문·답변 블록이 실제로 있는 페이지 | JSON-LD |
| Article(BlogPosting) JSON-LD | 블로그 글·기사 페이지 | JSON-LD |
| Organization JSON-LD | 사이트 공통(회사·브랜드 정보) | JSON-LD |
| BreadcrumbList JSON-LD | 경로가 있는 모든 페이지 | JSON-LD |
| @graph 통합 | 위 네 벌을 한 스크립트로 묶을 때 | JSON-LD |
| llms.txt | 사이트를 AI에 소개하는 루트 파일 | 마크다운 |
| robots.txt | AI 크롤러 허용·차단 규칙 | 텍스트 |
코드를 다루기 전 전제가 하나 있습니다. 스키마에는 페이지에 실제로 보이는 내용만 담아야 하고, 붙인 뒤에는 반드시 검증 도구로 문법과 내용을 확인해야 합니다(Google 검색 센터 구조화 데이터 일반 가이드라인). 없는 요소를 코드로 꾸며 넣으면 리치 결과에서 제외되거나 수동 조치를 받을 수 있으므로, 아래 코드도 값을 자기 페이지의 실제 내용으로 바꿔 써야 합니다.
FAQPage 스키마 JSON-LD는 어떻게 복사해 쓰나요?
FAQPage 스키마는 질문과 답변 쌍을 mainEntity 배열에 담아, 답변 엔진이 그대로 인용할 수 있는 형태로 만드는 코드입니다. 아래를 복사한 뒤 질문(name)과 답변(text)만 자기 페이지 것으로 바꾸면 됩니다.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"inLanguage": "ko-KR",
"mainEntity": [
{
"@type": "Question",
"name": "GEO와 SEO의 차이는 무엇인가요?",
"acceptedAnswer": {
"@type": "Answer",
"text": "SEO는 검색 순위를, GEO는 AI가 답변을 생성할 때 인용하는 출처가 되는 것을 목표로 합니다."
}
},
{
"@type": "Question",
"name": "llms.txt는 어디에 두나요?",
"acceptedAnswer": {
"@type": "Answer",
"text": "사이트 최상위 루트 경로 /llms.txt에 마크다운 텍스트 파일로 둡니다."
}
}
]
}각 필드의 역할은 아래와 같습니다. 배열에 질문 객체를 더 넣으면 FAQ가 늘어나는 구조이므로, 블록 하나를 복사해 이어 붙이면 항목을 추가할 수 있습니다.
| 필드 | 무엇을 넣나 | 주의 |
|---|---|---|
| inLanguage | 페이지 언어 코드 | 한국어는 ko-KR(영문 en-US 오기 주의) |
| mainEntity | 질문·답변 객체 배열 | 페이지에 실제로 보이는 FAQ만 |
| Question.name | 질문 문장 | 본문 FAQ 문구와 동일하게 |
| acceptedAnswer.text | 답변 문장 | 순수 문장 위주(링크·태그 최소화) |
핵심은 세 가지입니다. inLanguage는 한국어 페이지면 ko-KR로 지정하고, Question의 name은 본문에 실제로 있는 질문과 맞추며, Answer의 text에는 순수 문장을 넣습니다. FAQPage는 이제 검색 리치 결과로 표시되지는 않지만(FAQ 리치 결과는 2026년 중단) AI·답변 엔진이 질문과 답을 구조로 이해하도록 돕는 기계 판독 가치가 핵심입니다. 본문 FAQ와 스키마가 어긋나면 답변 엔진이 실제와 다른 문구를 인용할 수 있으므로, 코드의 질문·답변은 화면에 보이는 FAQ를 그대로 옮겨 적어야 합니다.
Article·Organization·BreadcrumbList 코드는 어떻게 작성하나요?
블로그 글 한 편에는 글을 설명하는 Article(BlogPosting), 발행 주체인 Organization, 사이트 경로인 BreadcrumbList가 함께 붙습니다. 세 코드를 차례로 복사해 제목·저자·URL 값만 바꾸면 됩니다.
먼저 글 자체를 설명하는 Article(BlogPosting)입니다. 저자는 Person으로 감싸 이름과 프로필 주소를 담습니다.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"@id": "https://geomkt.kr/json-ld-llms-txt-guide/#article",
"headline": "JSON-LD 스키마·llms.txt 실전 설정법",
"description": "복사해 바로 쓰는 JSON-LD·llms.txt 실전 코드와 배포·검증 방법.",
"inLanguage": "ko-KR",
"datePublished": "2026-07-01",
"dateModified": "2026-07-03",
"author": {
"@type": "Person",
"name": "김범수",
"jobTitle": "SEO·GEO 컨설턴트",
"url": "https://geomkt.kr/author/kimbumsoo/"
},
"publisher": { "@id": "https://geomkt.kr/#organization" },
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://geomkt.kr/json-ld-llms-txt-guide/"
}
}headline은 글 제목이며 검색 표시를 고려해 110자 이내로 두는 편이 안전합니다. datePublished와 dateModified는 YYYY-MM-DD 형식(ISO 8601)으로 적고, publisher는 뒤에서 만들 Organization을 @id로 가리키게 해 두면 조직 정보를 한 번만 정의해 재사용할 수 있습니다.
다음은 사이트 공통으로 쓰는 Organization입니다. 글마다 반복하지 않고 #organization이라는 @id로 한 번만 정의해 여러 글이 참조하게 만듭니다.
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://geomkt.kr/#organization",
"name": "GEOMKT",
"url": "https://geomkt.kr",
"logo": "https://geomkt.kr/wp-content/uploads/logo.png",
"sameAs": [
"https://seomkt.kr"
]
}sameAs에는 같은 조직을 가리키는 다른 주소(자매 사이트·소셜 프로필)를 배열로 넣습니다. 마지막은 사이트 경로를 나타내는 BreadcrumbList입니다. 홈에서 현재 글까지의 단계를 position 순서로 적습니다.
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "홈",
"item": "https://geomkt.kr"
},
{
"@type": "ListItem",
"position": 2,
"name": "실무",
"item": "https://geomkt.kr/practice/"
},
{
"@type": "ListItem",
"position": 3,
"name": "JSON-LD 스키마·llms.txt 실전 설정법",
"item": "https://geomkt.kr/json-ld-llms-txt-guide/"
}
]
}position은 1부터 매기고 item에는 각 단계의 실제 URL을 넣습니다. 현재 페이지에 해당하는 마지막 항목은 item을 생략해도 유효하지만, 위처럼 자기 주소를 그대로 넣어도 문제가 없습니다.
여러 스키마를 하나로 묶는 @graph 코드는 어떻게 만드나요?
@graph는 앞서 만든 여러 스키마를 하나의 배열로 묶어 한 스크립트에 담고, @id로 서로를 참조하게 만드는 구조입니다. 타입마다 스크립트를 따로 넣지 않고, @context를 한 번만 선언한 뒤 각 블록을 @graph 배열에 나열하면 됩니다.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://geomkt.kr/#organization",
"name": "GEOMKT",
"url": "https://geomkt.kr",
"sameAs": ["https://seomkt.kr"]
},
{
"@type": "BlogPosting",
"@id": "https://geomkt.kr/json-ld-llms-txt-guide/#article",
"headline": "JSON-LD 스키마·llms.txt 실전 설정법",
"inLanguage": "ko-KR",
"datePublished": "2026-07-01",
"dateModified": "2026-07-03",
"author": {
"@type": "Person",
"name": "김범수",
"url": "https://geomkt.kr/author/kimbumsoo/"
},
"publisher": { "@id": "https://geomkt.kr/#organization" },
"mainEntityOfPage": { "@id": "https://geomkt.kr/json-ld-llms-txt-guide/" }
},
{
"@type": "FAQPage",
"@id": "https://geomkt.kr/json-ld-llms-txt-guide/#faq",
"inLanguage": "ko-KR",
"mainEntity": [
{
"@type": "Question",
"name": "llms.txt는 어디에 두나요?",
"acceptedAnswer": {
"@type": "Answer",
"text": "사이트 최상위 루트 경로 /llms.txt에 둡니다."
}
}
]
},
{
"@type": "BreadcrumbList",
"@id": "https://geomkt.kr/json-ld-llms-txt-guide/#breadcrumb",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "홈", "item": "https://geomkt.kr" },
{ "@type": "ListItem", "position": 2, "name": "실무", "item": "https://geomkt.kr/practice/" },
{ "@type": "ListItem", "position": 3, "name": "JSON-LD 스키마·llms.txt 실전 설정법", "item": "https://geomkt.kr/json-ld-llms-txt-guide/" }
]
}
]
}이 구조의 이점은 두 가지입니다. BlogPosting의 publisher가 Organization을 @id로 참조하므로 조직 정보를 한 번만 적으면 되고, 검색엔진이 여러 블록을 한 페이지의 연결된 정보로 읽습니다. 실제 배포에는 개별 블록보다 이 통합본 하나를 넣는 편이 관리가 쉽습니다. 새 사이트를 만들며 처음부터 이 구조를 반영하는 순서는 신규 사이트 GEO 설계 체크리스트에서 단계별로 정리했습니다.
llms.txt 파일은 실제로 어떻게 작성하나요?
llms.txt는 사이트 루트에 두는 한 장짜리 마크다운으로, 제목(H1)·요약 인용·링크 목록 순서로 씁니다(llmstxt.org, 2024). 아래 예시에서 사이트 이름과 링크만 자기 사이트 것으로 바꾸면 됩니다.
# GEOMKT — AI 검색 시대의 SEO·GEO 컨설팅
> 중소기업과 스타트업이 AI 답변과 일반 검색 양쪽에서 발견되도록 돕는 GEO 전문 컨설팅. 진단부터 콘텐츠 실행까지 한 사람이 수행합니다.
## 핵심 페이지
- [무료 GEO 자가 진단](https://geomkt.kr/ai-search-self-check/): 도구 없이 30분 자가 진단 체크리스트
- [GEO 진단 프로세스](https://geomkt.kr/geo-audit-process/): 6개 평가 영역과 리포트 항목
- [SEO와 GEO 차이](https://geomkt.kr/seo-vs-geo/): AI 검색 시대의 검색 최적화 레이어
## 실무 가이드
- [JSON-LD·llms.txt 실전 설정법](https://geomkt.kr/json-ld-llms-txt-guide/): 복사해 쓰는 코드
- [신규 사이트 GEO 설계 체크리스트](https://geomkt.kr/new-site-geo-checklist/): 구축 단계 점검표
## Optional
- [회사 소개](https://geomkt.kr/about/)규칙은 단순합니다. 첫 줄 H1 제목은 필수이고, > 인용 한 줄로 사이트를 요약합니다. ## 섹션 아래에는 - [이름](URL): 설명 형식의 링크만 나열하고, 부차적 링크는 ## Optional로 내립니다. 파일은 UTF-8 순수 텍스트로 저장하고 확장자는 .txt를 유지합니다.
핵심은 모든 페이지를 넣는 것이 아니라 인용되길 바라는 페이지만 고르는 일입니다. GEOMKT도 자사 사이트를 직접 진단하다 llms.txt가 아직 없다는 점을 확인하고, 어떤 페이지를 안내에 올릴지 골라 파일을 준비하는 중입니다. 무엇을 넣고 뺄지의 판단 기준은 개념 편인 llms.txt와 AI 크롤러에서 다뤘습니다.
robots.txt로 AI 크롤러는 어떻게 허용·차단하나요?
robots.txt는 사이트 루트에 두는 규칙 파일로, User-agent로 크롤러를 지정하고 Disallow로 그 크롤러의 접근을 제한합니다. 답변·검색용 크롤러는 열어 두고 학습용만 선택적으로 막는 예시는 아래와 같습니다.
# 모든 검색·AI 크롤러 기본 허용
User-agent: *
Allow: /
# 학습용 수집만 선택 차단(답변·검색용은 열어 둠)
User-agent: GPTBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: CCBot
Disallow: /
# 사이트맵 위치 안내
Sitemap: https://geomkt.kr/sitemap.xml동작 원리는 단순합니다. 막고 싶은 크롤러의 이름을 User-agent 줄에 적고 범위를 Disallow에 적으면, 규칙을 존중하는 크롤러는 해당 범위를 읽지 않습니다. 위 예시의 GPTBot(OpenAI)·Google-Extended(Google)·CCBot(Common Crawl)은 주로 모델 학습 계열이라 막고, 이용자 질문에 답할 때 찾아오는 답변·검색용 크롤러는 열어 둔 형태입니다.
두 가지를 기억해야 합니다. 첫째, robots.txt는 강제 장치가 아니라 준수를 부탁하는 요청이므로 규칙을 무시하도록 만든 봇에는 효력이 없습니다. 둘째, 크롤러 이름과 정책은 자주 바뀌므로 정책을 정할 때마다 각 회사 공식 문서에서 최신 user-agent를 확인해야 합니다. GEO의 목표가 AI 답변 인용이라면 답변·검색용 크롤러는 오히려 열어 두는 편이 맞습니다.
작성한 코드를 WordPress에 어떻게 삽입하나요?
JSON-LD는 페이지 <head>에 <script type="application/ld+json">으로 감싸 넣고, llms.txt·robots.txt는 사이트 루트에 파일로 올립니다. 배포용 삽입 형태는 아래와 같습니다.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"inLanguage": "ko-KR",
"mainEntity": []
}
</script>WordPress에서 테마 파일을 직접 편집하지 않는 순서는 다음과 같습니다.
- RankMath를 쓴다면 글 편집 화면의 스키마 편집기에서 FAQPage·HowTo 같은 타입을 값 입력만으로 추가합니다.
- 편집기로 다루기 어려운 타입은 헤더 코드 플러그인(Insert Headers and Footers 등)에 위
<script>로 감싼 @graph를 붙여 넣습니다. - llms.txt와 robots.txt는 FTP나 호스팅 파일 관리자, 또는 파일 업로드 플러그인으로 사이트 최상위 폴더에 올립니다.
- 브라우저 주소창에
도메인/llms.txt와도메인/robots.txt를 입력해 200 응답과 내용이 보이는지 확인합니다.
여기서 가장 흔한 실수는 중복입니다. RankMath 같은 SEO 플러그인은 Organization·Article·BreadcrumbList·FAQPage를 이미 자동 생성하는 경우가 많아, 같은 타입을 헤더 코드로 또 넣으면 한 페이지에 스키마가 두 벌 실립니다. 그래서 자동 생성되는 타입은 플러그인에 맡기고, 플러그인이 만들지 않는 타입(HowTo 등)만 코드로 추가하는 편이 안전합니다. 이 코드를 자기 사이트에 실제로 적용하고 무엇이 비었는지 점검한 과정은 GEO 셀프 진단 실전기에서 단계별로 볼 수 있습니다.
삽입한 코드는 어떻게 검증하나요?
삽입한 스키마는 Schema Markup Validator로 모든 타입의 문법·구조를 확인하고, Google 리치 결과 테스트로는 Article·Breadcrumb처럼 리치 결과가 남아 있는 타입의 표시 자격을 점검한 뒤, 발행 뒤에는 Search Console에서 추적합니다. 코드를 읽지 못해도 도구가 무엇이 잘못됐는지 항목별로 짚어 줍니다.
- schema.org의 Schema Markup Validator(validator.schema.org)에 페이지 URL이나 코드를 넣어 모든 타입의 형식·구조에 문법 오류가 없는지 점검합니다. FAQPage·HowTo는 이제 구글 리치 결과로 표시되지 않으므로(FAQ 리치 결과는 2026년 중단) 이 검증기가 두 타입의 기본 점검 도구입니다.
- Google 리치 결과 테스트(Rich Results Test)는 Article·Breadcrumb처럼 아직 리치 결과가 남아 있는 타입의 표시 자격과 오류·경고를 확인하는 데 씁니다.
- 결과에서 오류(error)는 스키마가 인식되지 않게 하므로 반드시 고치고, 경고(warning)는 선택 항목이라 상황에 따라 채웁니다.
- 발행 후에는 Search Console의 향상 리포트에서 실제 색인된 페이지의 스키마 상태를 이어서 추적합니다.
가장 흔한 실패는 문법 오류(쉼표 누락·따옴표 짝)와 본문에 없는 정보를 스키마에 넣는 경우입니다. 스키마에는 페이지에 실제로 보이는 내용만 담습니다. 특히 AI에게 만들어 달라고 한 코드는 없는 정보를 그럴듯하게 채우거나 필드 이름을 틀리게 쓰는 일이 있어, 그대로 믿지 말고 검증 도구를 통과하는지 반드시 대조해야 합니다.
여기까지 밟으면 FAQPage부터 @graph, llms.txt, robots.txt까지 복사해 넣고 검증하는 한 바퀴가 끝납니다. 코드는 다 넣었는데 어느 페이지의 어떤 타입이 비었는지 확인이 필요하면 30분 무료 상담에서 지금 상황을 듣고 진단이 필요한지부터 말씀드리고, 이 과정을 체계적으로 익히고 싶다면 실무 강의 커리큘럼으로 이어 갈 수 있습니다.
자주 묻는 질문 (FAQ)
Q1. 스키마를 타입마다 따로 넣는 것과 @graph로 묶는 것 중 무엇이 나은가요?
@graph로 묶는 편을 권장합니다. @context를 한 번만 선언하고 여러 타입을 한 배열에 담아, publisher가 Organization을 @id로 참조하는 식으로 중복을 줄일 수 있습니다.
타입마다 스크립트를 따로 넣어도 인식은 되지만, 조직 정보 같은 공통 값을 여러 번 반복하게 되고 수정할 때 누락이 생기기 쉽습니다. 관리 편의와 일관성 면에서 통합본 하나를 두는 쪽이 유리합니다.
Q2. RankMath가 이미 스키마를 만드는데 이 코드를 또 넣어야 하나요?
대체로 그럴 필요가 없습니다. RankMath 같은 플러그인은 Organization·Article·BreadcrumbList·FAQPage를 자동 생성하는 경우가 많아, 같은 타입을 헤더 코드로 또 넣으면 스키마가 중복됩니다.
그래서 자동 생성되는 타입은 플러그인에 맡기고, 플러그인이 만들지 않는 HowTo 같은 타입만 코드로 추가하는 편이 안전합니다. 실제로 어떤 타입이 나가고 있는지는 검증 도구로 먼저 확인한 뒤 판단하면 됩니다.
Q3. 한국어 페이지인데 스키마 언어가 영문으로 나옵니다. 어떻게 고치나요?
한국어 콘텐츠에는 스키마의 inLanguage를 ko-KR로 지정합니다. 사이트 언어가 영문(en-US)이면 자동 생성 스키마에도 그대로 전파됩니다.
그래서 WordPress 일반 설정의 사이트 언어를 한국어로 먼저 맞춘 뒤 스키마를 재검증하는 순서가 안전합니다. 개별 코드의 inLanguage만 고치고 사이트 언어를 그대로 두면 다른 자동 생성 스키마에서 영문 표기가 남을 수 있습니다.
Q4. llms.txt와 robots.txt는 어디에 올리나요?
사이트 최상위 루트에 올립니다. 각각 도메인/llms.txt와 도메인/robots.txt 주소에서 열려야 하며, 하위 폴더가 아니라 도메인 바로 뒤 경로가 규격이 정한 자리입니다.
올린 뒤에는 브라우저 주소창에 해당 주소를 직접 입력해 200 응답과 파일 내용이 보이는지 확인합니다. 워드프레스처럼 폴더 접근이 번거로운 환경에서는 파일 업로드 플러그인으로 대신 올릴 수 있습니다.
Q5. AI에게 스키마를 만들어 달라고 해서 그대로 써도 되나요?
초안으로는 유용하지만 그대로 쓰는 것은 위험합니다. AI는 페이지에 없는 정보를 그럴듯하게 채우거나 필드 이름을 틀리게 쓰는 경우가 있습니다.
그래서 AI가 만든 코드는 반드시 Google 리치 결과 테스트나 검증기로 오류를 확인하고, 페이지의 실제 내용과 하나씩 대조해야 합니다. 무엇을 기준으로 점검할지는 GEO 진단의 6개 영역 항목을 참고하면 됩니다.
[참고] schema.org 구조화 데이터 공통 어휘 및 JSON-LD 예시(2011 출범) · Google 검색 센터 구조화 데이터 일반 가이드라인 및 JSON-LD 권장(2025) · llmstxt.org llms.txt 제안 규격(Answer.AI, 2024) · 로봇 배제 표준(RFC 9309, 2022) · GEOMKT 자사 GEO 셀프 진단(2026)
본 가이드는 일반적인 정보 제공을 목적으로 하며, 실제 적용 환경과 CMS·크롤러 정책에 따라 설정 방식이 달라질 수 있습니다. AI 크롤러의 이름과 정책은 각 회사 공식 문서로 최신 상태를 확인하시기 바랍니다.
우리 회사는 AI 답변에서 어디에 있을까요?
관련 글
경영진을 설득하는 GEO 도입 근거 — AI 검색 전환의 비즈니스 임팩트
검증 불가 성과 수치 없이 경영진을 움직이는 GEO 도입 근거를 리스크·기회비용·자산 효율 세 축으로 정리했습니다.
GEO 성과 측정법 — AI 인용을 추적하고 보고하는 지표와 도구
검색·AI 유입·AI 인용 지표를 무료 도구로 재고 한 장의 내부 성과 보고서로 묶는 GEO 성과 측정 실무 가이드.
GEO 독학 로드맵 — 마케터가 3개월 안에 익히는 학습 순서
마케터가 GEO를 3개월간 독학으로 익히는 학습 순서와 무료 자료를 1·2·3개월차 커리큘럼으로 정리했습니다.