JSON-LD가 없으면 AI가 회사 정보를 못 읽나?
못 읽지는 않습니다. 대신 본문을 보고 추측합니다. 구조화 데이터는 그 추측을 사실로 바꾸는 장치입니다. 다만 "AI 때문에 스키마가 필수"라는 말은 과장이라, 무엇이 사실이고 무엇이 마케팅인지부터 정리했습니다.
구조화 데이터는 사람이 보는 화면과 별개로, 기계가 읽으라고 같은 페이지에 넣어두는 정보입니다. 회사 이름·주소·전화·업종을 정해진 형식으로 적어두면 기계가 해석할 필요 없이 그대로 가져갑니다.
그런데 이 주제는 요즘 과장이 많습니다. 그것부터 정리하고 시작하겠습니다.
"AI 때문에 스키마가 필수"라는 말은 사실인가?
아닙니다. 적어도 구글에 대해서는 공식 문서가 정반대로 말합니다.
There are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary.
You don't need to create new machine readable files, AI text files, or markup to appear in these features. There's also no special schema.org structured data that you need to add.
읽는 그대로입니다. AI 개요에 나오기 위해 따로 넣어야 하는 스키마는 없습니다. 구글이 요구하는 건 색인될 것, 크롤 허용, 텍스트 콘텐츠가 있을 것 — 즉 기본기입니다.
그러니 "AI 시대라서 스키마를 넣어야 한다"는 판매 문구를 들으면 한 번 의심하는 게 맞습니다. 저희도 이 지표를 채점하지만, 그 근거를 AI 노출 요건으로 대지는 않습니다.
그럼 왜 여전히 넣는 게 나은가?
이유가 세 가지 있고, 셋 다 AI 유행과 무관하게 원래 성립하던 것들입니다.
1. 추측을 사실로 바꿉니다
스키마가 없으면 기계는 본문을 보고 추론합니다. 회사명이 <title>에 있는 그것인지, 푸터에 있는 법인명인지, 페이지마다 다른 그 표기인지 판단해야 합니다.
지점명·브랜드명·법인명이 섞여 있는 사이트라면 추론은 자주 틀립니다. 스키마는 "우리 회사의 정식 명칭은 이것"이라고 못 박는 일입니다.
2. 검색 결과 표시가 달라집니다
구글은 구조화 데이터의 효과를 이렇게 설명합니다.
Adding structured data can enable search results that are more engaging to users and might encourage them to interact more with your website, which are called rich results.
리치 결과(별점·빵부스러기 경로·제품 정보 등)는 구조화 데이터가 있어야만 나옵니다. 이건 AI와 무관하게 확실한 이득입니다.
다만 어떤 리치 결과가 지원되는지는 구글이 계속 줄이고 있습니다. FAQ는 2023년에 "잘 알려진 권위 있는 정부·보건 사이트"로 제한됐고, 2026년 6월에는 기능 문서 자체가 제거됐습니다 — 더 이상 검색 결과에 표시되지 않습니다. HowTo도 마찬가지입니다. 지금 지원되는 목록은 검색 갤러리에서 확인하는 게 정확합니다.
3. JSON-LD는 결국 페이지 안의 텍스트입니다
이 점이 의외로 덜 언급됩니다. JSON-LD는 별도 파일이 아니라 HTML 안에 들어 있는 텍스트입니다. 원본 HTML을 통째로 가져가는 크롤러라면 그 내용도 함께 가져갑니다.
모델이 그것을 특별히 더 중요하게 다루는지는 공개된 바가 없습니다. 다만 회사 정보가 기계가 파싱할 수 있는 형태로 한 덩어리에 정리돼 있다는 사실 자체는 남습니다.
어떤 스키마부터 넣나?
전부 넣을 필요는 없습니다. 효용 순서가 분명합니다.
| 순위 | 타입 | 언제 |
|---|---|---|
| 1 | Organization 또는 LocalBusiness | 거의 모든 사이트. 지역 기반 사업이면 후자 |
| 2 | Product · Service | 파는 것이 명확할 때 |
| 3 | BreadcrumbList | 계층이 있는 사이트 |
| 4 | Article · BlogPosting | 콘텐츠를 지속 발행할 때 |
1번이 8할입니다. 회사가 무엇인지 특정되지 않으면 나머지는 누구의 제품인지 모르는 제품 정보가 됩니다.
FAQPage는 이 표에서 뺐습니다. 리치 결과가 없어진 지금은 검색 노출을 근거로 권할 수 없습니다. 질문·답변을 정리해 두는 것 자체는 여전히 의미가 있지만, 그건 스키마의 효과가 아니라 본문에 답이 있느냐의 문제입니다.
@id는 왜 중요한가?
빠뜨리기 쉬운데, 이것 하나로 스키마가 흩어진 조각에서 연결된 구조로 바뀝니다.
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.co.kr/#organization",
"name": "디비나라",
"legalName": "주식회사 디비나라",
"url": "https://example.co.kr",
"telephone": "+82-2-0000-0000",
"address": {
"@type": "PostalAddress",
"streetAddress": "○○구 ○○로 00",
"addressLocality": "서울",
"addressCountry": "KR"
},
"sameAs": [
"https://blog.naver.com/...",
"https://www.instagram.com/..."
]
}
@id를 주면 다른 스키마가 이걸 참조할 수 있습니다.
{
"@type": "Product",
"name": "제품명",
"brand": { "@id": "https://example.co.kr/#organization" }
}
@id가 없으면 페이지마다 별개의 회사가 선언됩니다. 같은 회사라는 걸 알려주는 장치가 @id입니다.
sameAs도 같은 역할을 합니다 — "이 URL들이 전부 우리다"라는 선언이라, 흩어진 채널을 하나로 묶는 실마리가 됩니다.
우리 사이트는 어떤 상태인가요?
무료 진단이 페이지의 JSON-LD를 파싱해 어떤 타입이 있는지 봅니다. 회사 기본 정보(Organization·LocalBusiness)의 유무를 가장 비중 있게 보고, 제품·FAQ·계층 정보가 있으면 더 성숙한 것으로 판정합니다.
주의할 점이 하나 있습니다. 저희는 크롤러가 받은 원본 HTML에서 JSON-LD를 찾습니다. JavaScript로 나중에 주입되는 스키마는 잡히지 않습니다. 이건 저희 판정의 한계이기도 하고, 동시에 실제 상황이기도 합니다 — 앞 글에서 다룬 것과 같은 이유입니다.
자주 틀리는 것
| 증상 | 원인 | 대응 |
|---|---|---|
| 스키마를 넣었는데 인식이 안 된다 | JS로 주입돼 원본 HTML에 없음 | 서버 렌더로 <head>에 직접 삽입 |
| 리치 결과가 안 나온다 | 문법은 맞지만 필수 필드 누락 | Rich Results Test로 확인 |
| 페이지마다 회사 정보가 다르게 잡힌다 | @id 없이 페이지별로 선언 | 공통 @id 부여 후 참조 |
| 화면엔 없는 내용이 스키마에만 있다 | 스키마를 마케팅 문구로 채움 | 구글은 화면 텍스트와 일치시킬 것을 권장합니다 |
마지막 항목은 짚어둘 만합니다. 구글은 "Making sure your structured data matches the visible text on the page" 를 권장합니다. 화면에 없는 내용을 스키마에만 적는 건 권장되지 않습니다. 스키마는 없는 사실을 만드는 도구가 아니라 있는 사실을 정리하는 도구입니다.
정리
- 구글 AI 기능(AI 개요·AI 모드) 노출을 위해 반드시 넣어야 하는 스키마는 없습니다. 구글이 공식적으로 그렇게 말합니다.
- 다른 AI 서비스(챗GPT·클로드·퍼플렉시티)는 공개 문서가 없습니다. 그쪽에 대해서는 "없다"가 아니라 "모른다" 가 정확합니다 — 그 자리를 "그러니 넣어야 한다"로 채우는 글이 많습니다.
- 그럼에도
Organization하나는 넣는 게 낫습니다. 추측을 사실로 바꾸고, 리치 결과를 열고, 회사를 특정 가능하게 만듭니다. - 넣는다면
@id와sameAs를 반드시 포함하세요. 그게 조각을 구조로 만듭니다. - 화면에 있는 내용만 적으세요.
출처
- Google — Intro to structured data (최종 확인 2026-09-11)
- Google — AI Features and Your Website (최종 확인 2026-09-11)
- Google — 검색 갤러리(지원 기능 목록) (최종 확인 2026-09-14 — FAQ·HowTo 부재 확인)
다음 단계 — 회사가 특정됐다면, 그다음은 AI가 바로 꺼내 쓸 '답'이 있는가입니다.
- 흩어진 우리 회사를 하나로 묶으려면? — 더 깊이:
@id·sameAs실행편 - AI 가독성이란 무엇인가 — 8개 지표 전체 보기
- 이미지에 담긴 정보는 AI가 못 읽나? — 앞 글
- 무료 진단 받기 — 우리 사이트의 구조화 데이터 확인
우리 홈페이지는 AI에게 어떻게 보일까?
주소만 넣으면 8개 지표로 채점한 결과를 바로 보여드립니다. 가입도, 카드도 필요 없습니다.
다른 글
robots.txt는 허용인데 왜 안 읽히나?
robots.txt를 열어두는 것과 크롤러가 실제로 내용을 받아가는 것은 다른 층의 일입니다. 보안장비가 먼저 끊거나, 없는 경로에도 200을 주거나, 봇에게만 다른 화면을 주는 경우가 있습니다. 2026년 9월 15일 클라우드플레어 기본값 변경까지 포함해, 선언과 실제의 간극을 확인하는 법을 정리했습니다.
흩어진 우리 회사를 하나로 묶으려면?
홈페이지엔 "주식회사 ○○", 네이버 플레이스엔 "○○", 인스타엔 영문 표기. 사람은 같은 회사인 줄 알지만 기계는 모릅니다. 구조화 데이터 편에서 이름만 꺼낸 @id와 sameAs가 이 문제를 푸는 도구입니다. 표준 표기를 정하고 흩어진 채널을 묶는 순서를 정리했습니다.
AI가 읽을 수 있는 회사 소개는 어떻게 다른가?
회사 소개를 텍스트로 옮기고 나면 다음 질문이 남습니다 — 무엇을 어떻게 쓸 것인가. AI는 회사 소개를 감상하지 않고 사실을 꺼내 갑니다. 그래서 잘 쓴 소개문의 기준이 사람용과 다릅니다. 반드시 들어가야 하는 여덟 가지와, 고치기 전후 예시를 정리했습니다.