구조화 데이터, 뭐부터 넣어야 하나 — 77.3%가 없습니다

2026.09.11·기록

지난달 국내 쇼핑몰 3,035곳을 점검했더니 77.3%가 구조화 데이터를 넣지 않았습니다. 열 곳 중 여덟입니다. 뒤집으면 넣기만 해도 상위 22.7%에 든다는 뜻이고, 이 조사에서 투자 대비 효과가 가장 컸던 항목입니다. 뭐부터 어떻게 넣는지 정리했습니다.

구조화 데이터가 하는 일

사람은 페이지를 보면 "아, 이건 회사 소개구나", "이건 상품이구나"를 압니다. 기계는 그걸 글자만 보고는 확신하지 못합니다.

구조화 데이터는 그 정보를 기계가 읽는 형식으로 따로 적어주는 것입니다. "이 페이지는 조직 소개이고, 이름은 이거고, 연락처는 저거다"를 명시적으로 알려줍니다.

검색엔진은 이걸 보고 리치 결과(별점·FAQ 펼침 등)를 만들고, AI는 이걸 보고 페이지 내용을 정확히 파악합니다. 인용될 때 정보가 틀리지 않는 이유가 여기 있습니다.

형식은 여러 가지가 있지만 JSON-LD 하나만 알면 됩니다. 구글이 권장하는 방식이고, 본문 HTML을 건드리지 않고 <script> 한 덩어리만 넣으면 끝나서 제일 안전합니다.

넣는 순서

스키마 종류는 800개가 넘습니다. 전부 알 필요 없고 네 개면 대부분 해결됩니다. 아래 순서대로 넣으세요.

1번과 2번은 홈페이지에 한 번만 넣으면 됩니다. 여기부터 하세요. 10분이면 끝납니다.

복사해서 쓰는 예제

홈페이지에 넣을 것

</head> 바로 앞에 넣으면 됩니다. 대괄호 부분만 바꾸세요.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://내도메인.com/#org",
      "name": "[상호명]",
      "url": "https://내도메인.com/",
      "description": "[한 문장 소개]",
      "areaServed": { "@type": "Country", "name": "대한민국" }
    },
    {
      "@type": "WebSite",
      "@id": "https://내도메인.com/#website",
      "url": "https://내도메인.com/",
      "name": "[사이트 이름]",
      "inLanguage": "ko",
      "publisher": { "@id": "https://내도메인.com/#org" }
    }
  ]
}
</script>

@graph로 묶으면 여러 개를 한 덩어리에 넣을 수 있고, @id로 서로를 참조할 수 있습니다. 스크립트를 여러 개 흩어놓는 것보다 이 방식이 관리하기 쉽습니다.

글 페이지에 넣을 것

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "[글 제목]",
  "description": "[요약 한 문장]",
  "datePublished": "2026-09-11",
  "dateModified": "2026-09-11",
  "author": { "@type": "Person", "name": "[작성자]" },
  "publisher": { "@type": "Organization", "name": "[상호명]" },
  "mainEntityOfPage": { "@id": "https://내도메인.com/글주소" }
}
</script>

datePublished와 dateModified를 꼭 넣으세요. AI는 오래된 문서를 눈에 띄게 덜 인용합니다. 날짜가 없으면 판단할 근거가 없어서 후순위로 밀립니다.

FAQ가 있다면

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "[질문]",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "[답변 — 두세 문장으로 완결되게]"
      }
    }
  ]
}
</script>

이게 GEO 관점에서 가장 값어치 있는 스키마입니다. 질문과 답이 한 쌍으로 묶여 있어서 AI가 그대로 떼어다 쓰기 좋거든요. 답변을 쓸 때 그 문단만 떼어놔도 말이 되게 쓰는 게 요령입니다.

자주 나오는 실수 넷

하나 · 페이지에 없는 내용을 적는 것

가장 위험한 실수입니다. 화면에 별점이 없는데 스키마에 별점을 적거나, 없는 FAQ를 적어넣는 것. 구글은 이걸 스팸으로 보고 리치 결과를 아예 막습니다.

스키마는 페이지에 실제로 있는 것을 기계용으로 옮겨 적는 것입니다. 없는 걸 만들어내는 도구가 아닙니다.

둘 · 쉼표와 따옴표

JSON은 문법이 빡빡합니다. 마지막 항목 뒤에 쉼표가 붙어 있거나, 따옴표가 하나 빠지면 덩어리 전체가 무시됩니다. 일부만 반영되는 게 아니라 통째로요.

넣고 나면 반드시 검증하세요. 아래에 방법을 적었습니다.

셋 · 주소를 리다이렉트되는 것으로 적는 것

@id나 url에 적는 주소는 실제로 서비스되는 최종 주소여야 합니다. /about.html이 /about으로 넘어가는 구조라면 /about을 적어야 합니다.

리다이렉트되는 주소를 적으면 신호가 어긋납니다. 흔한데 잘 안 보이는 실수입니다.

넷 · 한 번 넣고 잊는 것

상호가 바뀌거나 페이지 내용이 달라지면 스키마도 같이 고쳐야 합니다. 틀린 스키마는 없는 것보다 나쁩니다. AI가 잘못된 정보를 그대로 인용하니까요.

제대로 들어갔는지 확인

넣었으면 반드시 확인하세요. 두 가지 도구가 있습니다.

• Schema.org Validator — 문법이 맞는지 봅니다
• 구글 리치 결과 테스트 — 구글이 실제로 인식하는지 봅니다

주소를 넣거나 코드를 붙여넣으면 바로 결과가 나옵니다. 오류가 하나라도 있으면 고치고 다시 돌리세요. 경고(Warning)는 넘어가도 되지만 오류(Error)는 안 됩니다.

무료 진단 도구에서도 구조화 데이터 유무를 확인할 수 있습니다. 다만 이건 있는지 없는지만 보므로, 내용이 맞는지는 위 두 도구로 확인하셔야 합니다.

정리

구조화 데이터는 어렵다는 인상 때문에 미뤄지는데, 실제로는 홈페이지에 스크립트 한 덩어리 넣는 것부터입니다. 10분이면 됩니다.

그리고 그 10분으로 77.3%를 앞지릅니다. 이만한 비율의 항목이 다른 데는 없습니다.

순서만 다시 정리하면 — 홈페이지에 Organization과 WebSite, 글에는 Article, 질문답변이 있으면 FAQPage. 넣고 나면 검증. 이게 전부입니다.

함께 읽으면 좋은 글

• 국내 쇼핑몰 7,200곳을 점검했습니다 — 절반 이상은 사이트가 없었습니다2026.09.07
• GEO 마케팅이 뭔가요? 3분 정리2026.08.26
• GEO 진단 도구 5개 비교 — 무엇을 보고, 무엇을 못 보나2026.08.31