구조화 데이터: 페이지가 무엇인지 기계에게 말하는 방법

구조화 데이터는 이 페이지가 무엇에 관한 것인지를 사람이 아니라 기계가 읽을 수 있는 형태로 적어 두었는가를 확인하는 카테고리입니다. SEO 100점 중 12점을 차지합니다. 검사 대상은 HTML 안의 <script type="application/ld+json"> 블록, 즉 JSON-LD입니다. Microdata나 RDFa는 검사하지 않습니다. Google이 JSON-LD를 권장 형식으로 안내하고 있고, 실무에서 새로 만드는 마크업의 대부분이 JSON-LD이기 때문입니다.

12점이라는 배점은 검색 접근성(20점)보다 낮고, 제목이나 본문 품질과 비슷한 수준입니다. 이유는 분명합니다. 구조화 데이터가 없어도 페이지는 색인되고 검색결과에 나올 수 있습니다. 구조화 데이터는 “색인되느냐”의 문제가 아니라 **“검색엔진과 AI 검색이 이 페이지를 얼마나 정확하게 이해하느냐”**의 문제이며, 리치 결과 자격이나 엔티티 인식에 도움이 될 수 있지만 그것을 약속하지는 않습니다. 검사기가 이 카테고리의 실패를 다른 카테고리보다 가볍게 다루는 것은 그 실제 역할을 반영한 결과입니다.

JSON 문법이나 어휘 선언에 문제가 있으면 속성을 채웠어도 의도대로 해석되지 않을 수 있습니다. 그래서 마크업을 읽을 수 있는지 먼저 확인하고, 엔티티의 속성을 본 다음, 본문과 대조하는 순서로 9개 항목을 읽는 것이 좋습니다.

첫 번째 층: 마크업이 읽히는가

이 층의 네 항목은 JSON-LD가 존재하고, 파싱되고, Schema.org 어휘로 해석되는지를 순서대로 확인합니다. 하나라도 걸리면 뒤의 엔티티 검사는 아예 시작되지 않거나 “해당 없음”으로 빠집니다.

JSON-LD 존재 (1점)

JSON-LD 존재는 초기 HTML에 application/ld+json 스크립트가 하나라도 있는지 봅니다. 없을 때의 판정은 “치명적”이 아니라 **“정보”**입니다. 구조화 데이터가 색인의 필수 조건이 아니기 때문에, 없다는 사실을 알려 주되 점수를 크게 깎지는 않습니다.

실무에서 이 항목이 뜻밖에 실패하는 경우는 대부분 렌더링 방식 때문입니다. React나 Vue로 만든 페이지에서 JSON-LD를 컴포넌트 안에 넣으면 브라우저에서는 보이지만 서버가 내려보내는 최초 HTML에는 없습니다. 검사기는 그 최초 HTML만 읽습니다. 본문이 통째로 클라이언트에서 그려지는 구조라면 이 항목은 “알 수 없음”으로 표시되며, 그때는 이 항목이 아니라 검색 접근성 카테고리의 초기 HTML 본문 항목부터 해결해야 합니다.

JSON-LD JSON 문법 (2점)

JSON-LD JSON 문법은 각 블록을 실제로 JSON 파서에 넣어 봅니다. 하나라도 파싱에 실패하면 “치명적”입니다. 존재 여부보다 높은 2점을 둔 이유는, 마크업을 넣었다고 생각하지만 실제로는 읽히지 않는 문제를 먼저 드러내기 위해서입니다.

깨지는 방식은 늘 비슷합니다. 마지막 속성 뒤에 남은 쉼표, 작은따옴표로 감싼 문자열, 템플릿 엔진이 본문 제목을 그대로 끼워 넣다가 제목 안의 큰따옴표가 이스케이프되지 않는 경우입니다. 특히 마지막 사례는 글마다 결과가 달라서 어떤 글은 통과하고 어떤 글은 실패합니다. 사이트 전체가 아니라 특정 페이지에서만 이 항목이 실패한다면 제목이나 설명에 따옴표가 들어간 글인지 먼저 확인해 보세요.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "그가 \"괜찮다\"고 말한 이유",
  "datePublished": "2026-09-21"
}

이 예시처럼 본문에서 가져온 값의 따옴표는 반드시 이스케이프돼야 합니다. 대부분의 언어에서는 문자열을 직접 이어 붙이지 말고 JSON 직렬화 함수에 객체를 넘기는 것만으로 해결됩니다.

JSON-LD @context (1점)

JSON-LD @context는 @type을 가진 블록이 schema.org를 가리키는 @context를 갖고 있는지 확인합니다. 배점은 1점이지만 판정은 “치명적”입니다. 배점이 낮은 것은 실무에서 빠지는 일이 드물기 때문이고, 판정이 무거운 것은 빠졌을 때 결과가 문법 오류와 같기 때문입니다. @context 없이 "@type": "Article"이라고 적으면 파서는 그것이 Schema.org의 Article인지 다른 어휘의 Article인지 알 수 없고, 결국 해석하지 않습니다.

이 항목에서 자주 나오는 질문이 하나 있습니다. http://schema.org와 https://schema.org 중 무엇을 써야 하느냐는 것입니다. 검사기는 둘 다 통과시킵니다. Google 역시 두 표기를 동일하게 처리한다고 안내하고 있습니다. 다만 새로 만드는 마크업이라면 https로 통일하는 편이 이후의 혼란을 줄입니다.

JSON-LD @type (1점)

JSON-LD @type은 파싱된 블록마다 @type이 있는지 봅니다. @context만 있고 @type이 없는 블록은 “무엇인지 알 수 없는 데이터”이므로 “치명적”으로 판정합니다. 배점이 1점인 이유는 @context와 같습니다. 드물게 틀리지만 틀리면 전부 무의미해집니다.

여기에는 검사기가 일부러 판정을 보류하는 예외가 있습니다. @context가 Schema.org가 아닌 외부 어휘를 가리키는 블록은 “알 수 없음”으로 표시합니다. 그 어휘 안에서는 @type이 다른 이름으로 정의돼 있을 수 있고, 검사기는 외부 어휘를 해석하지 않기 때문입니다. 이것을 오류로 읽지 마세요. 검사기가 모른다고 말하는 것이지 틀렸다고 말하는 것이 아닙니다.

두 번째 층: 엔티티가 말이 되는가

첫 번째 층을 통과하면 검사기는 블록 안의 노드를 @type별로 분류하고, 자주 쓰이는 네 가지 엔티티에 대해 핵심 속성을 확인합니다. 네 항목 모두 **해당 타입의 노드가 없으면 “해당 없음”**으로 처리되며 점수에서 빠집니다. Organization 노드를 넣지 않았다고 감점되지는 않습니다. 넣었는데 비어 있을 때만 문제가 됩니다.

이 층의 판정은 첫 번째 층과 성격이 다릅니다. 첫 번째 층은 “읽히느냐”라는 기계적 사실을 확인하지만, 두 번째 층은 “무엇을 채워야 하느냐”라는 애드브랜치의 판단을 담고 있습니다. 그래서 항목마다 그 판단이 어디까지 Schema.org나 Google의 문서에 근거하고 어디부터 검사기의 우선순위인지를 나누어 적습니다.

Article 권장 정보 점검 (1점)

Article 권장 정보 점검은 Article·NewsArticle·BlogPosting·TechArticle 계열 노드에서 headline, image, datePublished 세 가지를 확인하고, 통과하면 author와 dateModified를 추가로 봅니다. 세 가지 중 하나라도 없거나 날짜가 ISO 8601 형식이 아니면 “치명적”, 추가 두 가지가 없으면 “경고”입니다.

이 항목의 이름에 “필수”가 아니라 “권장”이 들어간 데에는 이유가 있습니다. Google의 Article 문서는 필수 속성을 정하지 않습니다. 권장 속성만 안내합니다. 그러므로 이 항목의 “치명적” 판정은 Google의 판정이 아니라 애드브랜치가 정한 우선순위입니다. 왜 이렇게 무겁게 두었느냐 하면, 세 속성이 빠진 Article 노드는 실질적으로 “이것은 글입니다”라는 선언 이상의 정보를 담지 못하기 때문입니다. 제목도 대표 이미지도 날짜도 없는 글 정보는 검색엔진과 AI 검색에 줄 것이 거의 없습니다.

가장 흔한 실수는 날짜 형식입니다. 2026.09.21이나 2026년 9월 21일은 사람에게는 명확하지만 검사기는 통과시키지 않습니다. 2026-09-21 또는 2026-09-21T09:00:00+09:00 형태여야 합니다. 시간대를 넣을 때는 한국 시간이면 +09:00을 명시하는 편이 안전합니다. 시간대 없이 시각만 적으면 해석하는 쪽이 UTC로 읽어 날짜가 하루 어긋날 수 있습니다.

그리고 한 가지를 분명히 해 두고 싶습니다. 점수를 위해 정보를 지어내지 마세요. 대표 이미지가 없는 글에 무관한 이미지를 넣거나, 작성자가 없는 자동 생성 페이지에 가짜 이름을 넣는 것은 이 검사를 통과할 수는 있어도 구조화 데이터의 목적을 정면으로 거스릅니다. 마크업은 페이지 내용을 설명하는 것이지 페이지 내용을 대신하는 것이 아닙니다. 해당 정보가 정말 없다면 “경고”를 받아들이는 것이 옳습니다.

WebPage 핵심 속성 (1점)

WebPage 핵심 속성은 WebPage·AboutPage·ContactPage·FAQPage 같은 페이지 계열 노드에 name과 유효한 url이 있는지 봅니다. 빠지면 “경고”입니다. Schema.org는 WebPage에 필수 속성을 두지 않으므로 이 판정 역시 검사기의 우선순위입니다. 배점이 1점인 것은 WebPage 노드가 대개 보조적인 역할이기 때문입니다. 글 페이지의 주인공은 Article이고, WebPage는 그것을 감싸는 그릇입니다.

그런데도 url을 확인하는 이유는 오탐이 아니라 실제 사고를 잡기 위해서입니다. 템플릿에 WebPage 노드를 넣고 url을 사이트 홈으로 고정해 두면 모든 글 페이지가 “나는 홈페이지다”라고 선언하는 셈이 됩니다. 검사기는 url이 현재 페이지와 같은지까지는 비교하지 않지만, 최소한 형식이 맞는 절대 URL인지는 확인합니다. 정식 URL(canonical)과 같은 값을 넣는 것이 원칙입니다.

Organization 핵심 속성 (1점)

Organization 핵심 속성은 Organization, Corporation, LocalBusiness, NewsMediaOrganization 계열 노드에서 name과 유효한 url을 확인하고, logo가 있다면 그것이 절대 URL인지 봅니다. 문제가 있으면 “경고”입니다. logo는 없어도 감점하지 않습니다. 있는데 상대 경로면 감점합니다. /logo.png 같은 상대 경로는 HTML 안에서는 브라우저가 기준 URL로 풀어 주지만, 구조화 데이터를 따로 떼어 처리하는 쪽에서는 기준이 없어 어디를 가리키는지 알 수 없습니다.

이 항목이 1점인 것은 Organization 노드가 페이지가 아니라 발행 주체에 관한 정보이기 때문입니다. 페이지 단위 검사기가 사이트 단위의 엔티티를 완전히 평가할 수는 없습니다. 발행자의 이름·URL·로고가 일관되게 선언돼 있으면 검색엔진과 AI 검색이 “이 글은 누가 냈는가”를 식별하는 데 도움이 될 수 있지만, 그 효과는 이 페이지 하나가 아니라 사이트 전체의 일관성에서 나옵니다. 검사기는 그중 이 페이지에서 확인할 수 있는 최소한만 봅니다.

BreadcrumbList 필수 속성 (2점)

BreadcrumbList 필수 속성은 두 번째 층에서 유일하게 Google 문서가 실제로 필수라고 정한 속성을 검사합니다. 각 ListItem에 position과 name이 있어야 하고, 마지막 항목을 제외한 ListItem에는 item도 있어야 하며, position은 1부터 빈틈없이 이어져야 합니다. 하나라도 어긋나면 “치명적”입니다. 두 번째 층에서 가장 높은 2점을 준 것도 같은 이유입니다. 다른 세 항목의 감점은 검사기의 판단이지만, 이 항목의 감점은 Google이 breadcrumb 리치 결과를 처리하지 않는 조건과 직접 겹칩니다.

마지막 항목의 item은 예외입니다. Google은 현재 페이지를 나타내는 마지막 ListItem에서 item을 생략하는 것을 허용하고, 검사기도 이 경우를 “치명적”이 아닌 “경고”로 낮춥니다. 경고인 이유는 그것이 의도된 생략인지 실수인지 검사기가 구분할 수 없기 때문입니다. 마지막 항목이 현재 페이지라면 이 경고는 무시해도 됩니다.

실무에서 이 항목이 실패하는 전형적인 방식은 position의 불연속입니다. CMS가 카테고리 계층을 breadcrumb으로 변환하면서 홈을 0번으로 두거나, 숨김 처리된 중간 카테고리를 건너뛰면서 번호를 그대로 두는 경우입니다. 화면의 breadcrumb은 멀쩡해 보이는데 마크업만 깨지는 상황이라 검사기 없이는 알아채기 어렵습니다.

세 번째 층: 구조화 데이터와 본문 일치

구조화 데이터와 본문 일치(2점)는 문법이 맞는 마크업과 실제 페이지 내용이 어긋나는 경우를 찾습니다. JSON-LD 존재와 Article 권장 정보 점검에서 각각 1점씩 옮겨, 총점 12점 안에서 본문 대조에도 비중을 두었습니다.

비교 대상은 FAQPage 질문 문장과 답변의 앞 30자, Article 계열의 headline입니다. 공백과 대소문자 등을 정규화한 뒤 본문 샘플·문서 제목·H1에서 찾습니다. 확인 가능한 항목이 모두 일치하면 통과, 일부만 불일치하면 경고, 2개 이상을 확인했는데 전부 불일치하면 치명적입니다. 비교 대상이 없으면 해당 없음이고, 앱 셸이나 잘린 본문 때문에 모두 확인할 수 없으면 확인 불가입니다.

본문 샘플은 최대 20,000자입니다. 전체 본문이 더 긴 경우 샘플에서 찾지 못한 항목은 불일치로 단정하지 않고 판정에서 제외합니다. 답변 전체의 의미나 사실성을 평가하는 검사가 아니라 문자열 대조이므로, 표현만 다르게 쓴 문장도 수동 확인이 필요합니다.

Google은 보이지 않는 내용을 마크업하지 말고 실제 페이지를 정확하게 나타내라고 안내합니다. 구조화 데이터 수동 조치를 받으면 리치 결과 자격을 잃지만 일반 웹 검색 순위에는 영향을 주지 않습니다. Google 구조화 데이터 일반 지침, Google 수동 조치 보고서 안내

FAQPage를 넣는 목적도 구분해야 합니다. Google은 2026년 5월 7일부터 FAQ 리치 결과를 전면 중단했다고 안내합니다. 과거의 정부·의료 사이트 예외를 현재 기준으로 설명해서는 안 됩니다. 이는 독자에게 유용한 FAQ 본문을 지우라는 뜻이 아닙니다. 또한 Organization에는 Google이 정한 필수 속성이 없고 sameAs 등은 권장 속성입니다. Google Search 문서 변경 기록, Organization 안내

점검 순서에 대한 조언

검사 결과에서 이 카테고리의 항목이 여러 개 실패했다면 위에서 적은 순서, 즉 문법과 @context와 @type을 먼저 고치세요. 첫 번째 층의 문제를 고치면 두 번째 층의 판정이 바뀌는 경우가 많습니다. 파싱에 실패한 블록 안에 있던 Article 노드는 그동안 검사기에 보이지도 않았을 것이고, 문법을 고치는 순간 새로 나타난 Article 항목이 별도의 경고를 낼 수 있습니다. 이것은 검사가 흔들리는 것이 아니라 비로소 내용을 볼 수 있게 된 것입니다.

반대로 두 번째 층의 “경고”는 급하지 않습니다. author나 dateModified가 없어서 나온 경고는 해당 정보가 실제로 있을 때만 채우면 되고, 없다면 그대로 두어도 색인이나 검색 노출에 직접적인 손해가 생기지 않습니다.

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

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

• 단일 페이지 검사입니다. 한 URL의 JSON-LD만 읽습니다. 홈페이지에 선언한 Organization과 글 페이지의 publisher가 서로 다른 이름을 쓰는지, 사이트 전체에서 엔티티가 일관되는지는 알 수 없습니다.
• 초기 HTML 기준입니다. JavaScript 실행 후에 삽입되는 JSON-LD는 보지 않습니다. 클라이언트에서 마크업을 넣는 구조라면 검사 결과가 브라우저에서 확인한 것과 다를 수 있습니다.
• JSON-LD만 검사합니다. Microdata나 RDFa로 적은 구조화 데이터는 있어도 없는 것으로 판정됩니다.
• 값의 진실성은 확인하지 않습니다. headline과 일부 FAQ 문구는 본문 샘플과 대조하지만, 게시일이 실제 발행일인지나 이미지 파일이 실제로 존재하는지는 확인하지 않습니다. 문자열 일치는 사실 확인이 아닙니다.
• @graph나 중첩 노드의 참조 관계를 완전히 따라가지 않습니다. 같은 타입의 노드가 여러 개면 첫 번째 노드만 검사합니다. @id로 노드끼리 연결한 구조에서 참조가 올바른지는 판정하지 않습니다.
• 리치 결과 자격을 판정하지 않습니다. 여기서 통과해도 Google의 리치 결과 테스트에서는 다른 결과가 나올 수 있고, 그 반대도 가능합니다. 두 검사는 목적과 기준이 다릅니다.
• 판정은 애드브랜치의 우선순위입니다. BreadcrumbList를 제외한 두 번째 층의 “치명적”과 “경고”는 이 검사기가 정한 기준이며, Google이나 AI 검색엔진의 판정 그 자체가 아닙니다. 구조화 데이터를 갖췄다고 해서 검색 순위나 AI 답변에서의 인용이 약속되는 것도 아닙니다.

이어서 읽기

항목별 수정 방법과 코드 예시는 옆의 규칙 표에 정리돼 있습니다. JSON-LD를 처음 작성하는 방법, 페이지 유형별로 어떤 @type을 골라야 하는지, 여러 노드를 @graph로 묶는 방법은 구조화 데이터 작성 가이드에서 이어서 읽어 보세요.