마케팅 글쓰기, JSON-LD 스키마를 활용, AEO GEO 구조화 데이터 활용법
핵심 요약
지난 글 SEO는 통과했는데 AI한테는 안 보인다고요? 끝에서 “구조화 데이터(스키마마크업, JSON-LD)에 본문 전체를 포함시키는 고급 기법”을 다음 주제로 예고했었습니다. 그런데 실제로 근거를 파보니, 그 방법은 고급 기법이 아니라 효과가 검증되지 않은 방법이라는 결론에 도달했습니다.
- JSON-LD의
articleBody에 본문 전체를 복사해 넣어도, 구글도 AI 답변엔진도 그 텍스트를 추가로 신뢰하거나 우선 인용하지 않습니다 — 이미 화면에 있는 내용이라 “추가 정보”가 아니기 때문입니다. - 대신 실제로 효과가 검증된 3가지: 본문에 출처·통계·인용문을 명시하기, @graph + @id로 엔터티를 서로 연결하기, 지난 글의 체크리스트 8가지와 결합하기입니다.
- 워드프레스·랭크매쓰 환경에서 오늘 얘기하는 걸 어디에 채워 넣어야 하는지도 정리했습니다.
지난 글에서 예고했던 그 이야기
왜 “본문 전체를 JSON-LD에 넣자”는 아이디어가 그럴듯하게 들렸는지부터 짚고 가겠습니다. 스키마마크업은 원래 검색엔진에게 페이지 내용을 구조화해서 알려주는 용도인데, 그렇다면 AI에게도 같은 방식으로 본문을 통째로 알려주면 되지 않을까 하는 생각이었습니다.
GPTBot, ClaudeBot, PerplexityBot 같은 AI 크롤러들은 OpenAI 공식 문서와 Anthropic 공식 안내를 보면 자바스크립트를 실행하지 않고 정적 HTML을 그대로 긁어가는 경우가 많습니다. 그러다 보니 실무자들 사이에서는 “그럼 처음부터 파싱하기 쉬운 순수 텍스트 형태로 본문을 JSON-LD 안에 통째로 넣어주면, AI가 굳이 HTML 태그를 헤집을 필요 없이 바로 가져가지 않을까?”라는 아이디어가 나왔습니다.
실제로 이게 완전히 근거 없는 상상은 아닙니다. Schema.org의 Article 타입에는 정말로 articleBody라는 필드가 있고, Schema.org 공식 정의에 “The actual body of the article(기사의 실제 본문)”라고 명시돼 있으며, 구글 자체 웹 색인 기준으로 전 세계 100만~1000만 개 도메인이 이미 이 필드를 쓰고 있을 만큼 흔한 속성이기도 합니다.
“필드가 있으니 채우면 되지 않을까” — 이게 지난 글 말미에서 저희가 다음 주제로 예고했던 생각이었습니다.
그런데 직접 확인해보니
결론부터 말하면, 이 방법을 권하는 SEO·GEO 실무 문서를 거의 찾을 수 없었습니다. 오히려 반대 방향의 근거가 훨씬 뚜렷했습니다.
먼저 구글의 공식 구조화 데이터 정책은 이렇게 명시합니다:
“Don’t mark up content that is not visible to readers of the page.” (독자에게 보이지 않는 콘텐츠를 마크업하지 마세요.)
본문 전체를 articleBody에 그대로 복사해 넣는다면 이 “보이지 않는 콘텐츠” 규정을 직접 어기는 건 아닙니다 — 화면에 있는 내용과 동일하니까요. 문제는 다른 데 있습니다. 같은 문서에서 구글은 “구조화 데이터만을 위한 빈 페이지를 만들지 말라”는 원칙도 함께 밝히는데, 이건 결국 “마크업은 사용자에게 실제 가치를 더할 때만 의미가 있다”는 같은 맥락의 이야기입니다.
그리고 실제 가치 여부를 따져보면 답이 나옵니다. 구글은 랭킹을 매길 때 articleBody의 텍스트를 별도로 사용하지 않고, 화면에 렌더링된 HTML에서 콘텐츠 품질과 관련성을 판단합니다. AI 답변엔진도 마찬가지로 화면에 노출된 본문에서 정보를 추출하지, JSON-LD의 articleBody를 따로 참조해 “추가 정보”를 얻지 않습니다 (관련 스키마 실무 가이드 참고). 이미 HTML 본문에 있는 글을 JSON-LD 안에 한 번 더 복사해 넣어봐야, AI 입장에서 처음 보는 정보가 아니라는 뜻입니다. 오히려 JSON-LD 코드 블록의 용량만 커지고, 본문을 수정할 때마다 JSON-LD도 같이 고쳐야 하는 유지보수 부담만 늘어납니다.
정직하게 인정하겠습니다. 지난 글에서 예고했던 “고급 기법”은, 직접 검증해보니 고급도 아니고 효과도 없었습니다. 그래서 오늘은 방향을 바꿔서, 실제로 근거가 있는 방법만 정리합니다.
그럼 진짜 먹히는 건 뭘까 — 3가지
1. 본문에 출처·통계·인용문을 명시적으로 박아넣기
프린스턴대·조지아텍 연구진이 발표한 논문 “GEO: Generative Engine Optimization”(Aggarwal et al., 2024, SIGKDD 2024 게재)은 “Generative Engine Optimization(GEO)”이라는 용어 자체를 처음 제시한 논문입니다. 약 1만 개 질의를 아홉 개 데이터셋에 걸쳐 테스트한 결과, 본문에 인용문(quotations)·통계 수치·명시적 출처(cite sources)를 추가하는 것만으로 AI 생성 답변 안에서의 노출도가 최대 30~40%대까지 올라갔습니다. 그중에서도 “출처를 명시하는 것(Cite Sources)”은 여러 도메인에 걸쳐 가장 일관되게 효과를 낸 방법으로 꼽혔습니다.
이건 JSON-LD의 문제가 아니라 본문 자체의 문제입니다. 이 사이트도 이미 이 원칙을 쓰고 있습니다 — 지난 체크리스트 글의 3번(주장에는 출처 링크), 8번(글 끝 참고 출처 정리) 항목이 바로 이 연구가 말하는 것과 같은 방향입니다.
2. JSON-LD는 본문 복붙이 아니라 “엔터티 연결”에 쓰기
구글이 실제로 공식 정책 문서에서 권장하는 방식은 따로 있습니다. 한 페이지 안에 서로 관련된 항목(예: 레시피와 그 레시피를 설명하는 영상)이 있을 때, 각 항목에 고유한 @id를 부여해서 “이 영상은 이 레시피에 대한 것이다”라고 서로 참조하게 연결하라는 것입니다. @id로 연결하지 않으면 구글이 두 항목의 관계를 아예 인식하지 못할 수 있다고 명시하고 있습니다.
이 원리를 블로그 글에 그대로 적용하면, Article·Person(글쓴이)·Organization(기관)·WebPage를 각각 따로 흩어놓지 않고, 하나의 @graph 배열 안에 넣은 뒤 @id로 서로 가리키게 만드는 구조가 됩니다. 말로 풀면 이렇습니다: Article 항목의 author 값이 별도 URL 텍스트가 아니라 Person 항목의 @id를 그대로 참조하고, 그 Person 항목의 publisher 관계도 같은 방식으로 Organization 항목의 @id를 참조합니다. Person·Organization 항목에는 각각 실제 운영 중인 인스타그램, 네이버 플레이스, 공식 채널 등의 URL을 sameAs 값으로 나열합니다.
이렇게 연결해두면 AI 입장에서는 “이 글을 쓴 사람이 누구고, 어느 기관 소속이고, 그 기관의 다른 공식 채널은 어디인지”를 본문 텍스트를 처음부터 다시 읽어가며 추측할 필요 없이, 그래프 형태로 곧바로 파악할 수 있습니다. 본문 전체를 복사해 넣는 것과 달리, 이건 화면 어디에도 없던 관계 정보를 새로 제공하는 것이라 구글의 “보이지 않는 콘텐츠 금지” 원칙과도 부딪히지 않습니다 — 애초에 관계(schema property)를 나타내는 것이지 별도의 “콘텐츠”를 새로 만드는 게 아니기 때문입니다.
3. 지난 글의 체크리스트 8가지와 결합하기
제목 태그 위계, 메타 description, 출처 링크, 이미지 alt, 실제 table 마크업, robots.txt의 AI 크롤러 허용, 목차, 참고 출처 정리 — 지난 글의 8가지 체크리스트는 전부 “AI가 콘텐츠를 그래프의 한 노드로 이해하기 쉽게 만드는 작업”이라는 점에서 오늘 얘기한 엔터티 연결과 같은 방향입니다. 오늘 내용은 그 위에 “누가, 어느 기관이 이 글을 썼는가”라는 한 겹을 더 얹는 것에 가깝습니다.
업종별로 어떻게 적용할까
랭크매쓰는 이미 모든 글에 BlogPosting·Person·WebSite·WebPage 스키마마크업을 자동으로 생성합니다. 업종에 상관없이 사람이 직접 손대야 하는 부분은 딱 하나, sameAs 채우기입니다.
| 업종 | Person 스키마 sameAs | Organization 스키마 sameAs |
|---|---|---|
| 병원·클리닉 | 원장 인스타그램, 유튜브 | 네이버 플레이스, 공식 채널 |
| 학원·교육기관 | 강사 블로그, 유튜브 | 공식 SNS, 학부모 커뮤니티 채널 |
| 이커머스·쇼핑몰 | 대표/브랜드 담당자 SNS | 스마트스토어, 인스타그램 등 판매 채널 |
| 로컬 서비스업(미용실·법률·세무 등) | 대표자 채널 | 네이버 플레이스, 카카오맵 등 지역 채널 |
다만 이 값들은 “화면에 보이지 않는 콘텐츠를 새로 만드는” 것이 아니라 이미 존재하는 사실을 연결하는 것이어야 합니다. 업종마다 표시·광고를 규제하는 법이 다르므로(병원은 의료광고 규정, 학원은 학원의 설립·운영 관련 표시·광고 규정, 금융·법률 서비스는 각각의 업권법 등) 스키마에 채우는 정보도 실제 사실과 다르지 않은지 해당 업종 규정에 맞춰 한 번 더 확인하는 게 안전합니다.
한 번 더, 빠르게 짚고 갈게요
- JSON-LD의
articleBody에 본문 전체를 복붙하는 건 효과가 검증되지 않은 방법입니다 — 이미 화면에 있는 내용이라 AI에게 새로운 정보가 아닙니다 - 본문에 출처·통계·인용문을 명시하는 것이 먼저입니다 — 프린스턴·조지아텍 GEO 연구에서 가장 일관된 효과가 확인된 방법입니다
- JSON-LD는 본문 복사가 아니라 엔터티(글쓴이·기관) 연결에 씁니다 —
@graph+@id로 “누가, 어디 소속인가”를 명시 - 이 모든 게 지난 글의 8가지 체크리스트 위에서 작동합니다 — 구조가 없는 글에 엔터티 연결만 얹어봐야 큰 효과가 없습니다
자주 묻는 질문
-
articleBody에 본문 전체를 넣으면 손해라도 보나요?
당장 눈에 띄는 불이익은 없습니다. 구글 정책상 화면과 동일한 내용이라 위반은 아닙니다. 다만 랭킹이나 AI 인용에 실질적인 도움이 된다는 근거가 없고, 스크립트 태그 용량과 유지보수 부담만 늘어나므로 굳이 할 이유가 없다는 것이 이 글의 결론입니다.
-
랭크매쓰가 자동으로 만드는 스키마로 충분한가요?
BlogPosting, Person, WebSite, WebPage 같은 기본 스키마는 랭크매쓰가 자동으로 생성해줍니다. 다만 sameAs처럼 글쓴이나 기관의 다른 공식 채널을 연결하는 값은 자동으로 채워지지 않으므로 직접 입력해야 합니다.
-
@graph와 @id는 꼭 개발자가 넣어야 하나요?
직접 JSON-LD 코드를 작성하려면 개발 지식이 필요하지만, 랭크매쓰 같은 SEO 플러그인은 이미 Person과 Organization 스키마를 자동 생성하면서 내부적으로 @id 연결 구조를 함께 만들어줍니다. 대부분의 경우 플러그인 설정 화면에서 sameAs 필드만 채워주면 됩니다.
-
이 방법이 정말 AI 답변 인용률을 높여주나요?
프린스턴·조지아텍 GEO 연구가 확인한 것은 출처·통계·인용문을 담은 콘텐츠가 AI 생성 답변에서 노출도가 올라간다는 것이지, 특정 스키마 구조 하나가 인용률을 몇 퍼센트 올려준다는 식의 개별 인과관계까지 실험으로 증명된 것은 아닙니다. 엔터티 연결은 AI가 콘텐츠의 맥락을 정확히 파악하도록 돕는 구조적 기반으로 이해하는 것이 정확합니다.
-
업종별로 규제되는 표시 항목이 있다면 스키마에도 주의해야 하나요?
네. 스키마에 넣는 정보도 결국 사이트가 외부에 제공하는 사실 정보이므로, 화면에 보이는 문구와 마찬가지로 정확해야 합니다. 병원의 의료광고 규정, 학원의 표시·광고 규정처럼 업종별로 표시 자체가 규제되는 항목이 있다면, 스키마에도 실제 사실과 다르게 넣지 않도록 주의가 필요합니다.
참고 출처 (7)
구조화 데이터 공식 정책·스펙
- Google 검색 센트럴 — General Structured Data Guidelines — 보이지 않는 콘텐츠 마크업 금지 원칙, @id로 관련 항목 연결하는 공식 권장 방식
- Schema.org — articleBody 속성 공식 정의 — 필드 정의와 실제 채택 도메인 규모
GEO 연구
- Aggarwal et al., “GEO: Generative Engine Optimization” (arXiv:2311.09735, SIGKDD 2024) — 인용문·통계·출처 명시가 AI 답변 노출도에 미치는 영향을 실험으로 측정한 프린스턴·조지아텍 공동 연구
실무 가이드
AI 크롤러 공식 문서
이 사이트의 관련 글
- SEO는 통과했는데 AI한테는 안 보인다고요? — AEO·GEO 체크리스트 — 이 글에서 다음 주제로 예고했던 내용을 검증한 것이 이번 글입니다
