구조화 데이터 Structured Data / JSON-LD

구조화 데이터(Structured Data)는 검색엔진이 페이지의 의미를 정확히 이해하도록 schema.org 어휘를 기계가 읽을 수 있는 형식으로 담는 마크업이며, JSON-LD는 구글이 권장하는 작성 형식입니다. 리치 결과 노출의 자격 요건이 되지만, 구글은 구조화 데이터 자체가 순위 요소는 아니라고 밝혀 왔습니다.

테크니컬 2026. 7. 11 업데이트 By 박혜정

왜 구조화 데이터가 필요한가

구조화 데이터(Structured Data)는 검색엔진이 페이지의 의미를 정확히 이해하도록 schema.org 어휘를 기계가 읽을 수 있는 형식으로 담는 마크업입니다. 구글 검색 센트럴 문서는 이를 "페이지 정보를 제공하고 페이지 콘텐츠를 분류하는 표준화된 형식"으로 정의합니다 Google 공식. 크롤러는 HTML 텍스트를 읽을 수는 있지만 그 의미를 사람처럼 확실히 알지는 못합니다. 페이지에 적힌 "스튜디오 제이티"가 회사 이름인지, 사람 이름인지, 프로젝트 제목인지 문맥만으로는 애매하고, 구조화 데이터는 이 정보를 기계 판독 형식으로 분명히 밝혀 해석이 헷갈릴 여지를 줄입니다.

구조화 데이터를 갖춘 페이지는 별점, 가격, 브레드크럼 같은 리치 결과 형태로 SERP 에 노출될 자격을 얻습니다. 구글이 소개한 사례 연구에서 Rotten Tomatoes는 구조화 데이터를 적용한 페이지의 클릭률이 25% 높았고, Nestlé 는 리치 결과로 표시된 페이지의 클릭률이 82% 높았습니다 구글 사례 연구.

schema.org 어휘와 JSON-LD 작성법

schema.org는 구글, 마이크로소프트(Bing), 야후, 얀덱스가 공동 참여하는 표준 어휘 사전으로 Organization, Article, Product, LocalBusiness 등 800개가 넘는 타입을 정의합니다. 구글 검색 센트럴 문서는 검색용 구조화 데이터 대부분이 schema.org 어휘를 쓴다고 안내하면서도, 구글 검색에서의 실제 동작은 schema.org 문서가 아니라 구글 자체 문서를 기준으로 확인하라고 명시합니다 Google 공식.

작성 형식은 JSON-LD, Microdata, RDFa 세 가지가 있습니다. 구글 검색 센트럴 문서는 "사이트 설정이 허용한다면" JSON-LD를 권장하며, 대규모로 구현하고 유지보수하기 가장 쉬운 형식이라는 것을 이유로 듭니다 Google 공식. JSON-LD는 W3C가 2020년 7월 권고안(JSON-LD 1.1)으로 확정한 표준 형식으로 W3C 표준, HTML 태그 사이에 속성을 끼워 넣는 다른 방식과 달리 script 태그 하나에 데이터가 모여 있습니다. 다음은 회사 정보를 선언하는 Organization 예시입니다.

<script type="application/ld+json">
{
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://www.example.co.kr/#organization",
    "name": "예시 웹에이전시",
    "url": "https://www.example.co.kr/",
    "logo": "https://www.example.co.kr/assets/logo.png",
    "description": "워드프레스 맞춤 테마 제작 전문 웹에이전시",
    "sameAs": [
        "https://www.instagram.com/example",
        "https://www.linkedin.com/company/example"
    ]
}
</script>

워드프레스 맞춤 테마라면 이 스크립트를 wp_head 훅에서 출력하는 것이 정석입니다. @id를 붙여 두면 Article 이나 WebPage 같은 다른 스키마가 publisher 필드에서 이 엔티티를 참조할 수 있어, 사이트 전체가 하나의 그래프로 연결됩니다. 구글 Organization 문서는 url과 sameAs 같은 속성이 조직을 고유하게 식별하는 데 도움이 된다고 안내하며, sameAs 에는 여러 URL을 나열할 수 있습니다 Google 공식.

리치 결과는 보장되지 않습니다

구조화 데이터를 넣는다고 리치 결과가 보장되지는 않습니다. 구글 검색 센트럴 문서는 구조화 데이터가 리치 결과 표시를 가능하게 할 뿐, 표시 자체를 보장하지는 않는다고 명시합니다 Google 공식.

실제 사례가 있습니다. 구글은 2023년 8월 검색 센트럴 블로그에서 FAQ 리치 결과를 잘 알려진 권위 있는 정부·의료 웹사이트에만 표시하도록 제한하고 HowTo 리치 결과를 데스크톱 전용으로 축소한다고 발표했으며, 같은 해 9월에는 HowTo 표시를 데스크톱에서도 중단해 사실상 폐지했습니다 구글 블로그. 같은 글은 남은 마크업을 굳이 제거할 필요는 없지만, 사용되지 않는 구조화 데이터는 검색에서 아무 표시 효과가 없다고 덧붙였습니다.

순위와의 관계도 분명합니다. 구글의 존 뮬러는 2019년 구조화 데이터가 페이지의 엔티티를 이해하는 데 도움을 주지만 순위 요소는 아니라고 밝혔습니다. 구조화 데이터가 있다고 해서 구글이 그 페이지를 더 많은 사용자에게 보여주거나 순위를 올리지는 않는다는 뜻입니다 존 뮬러(Google). 구글의 구조화 데이터 일반 가이드라인 역시 정책 위반으로 수동 조치를 받으면 리치 결과 표시 자격을 잃을 뿐, 웹 검색 순위에는 영향이 없다고 두 영역을 구분합니다 Google 공식.

AI 검색 시대의 구조화 데이터

AI 검색 기능과 관련해서도 구글은 입장을 문서로 밝혔습니다. 구글 AI 기능 문서는 AI Overviews 나 AI 모드에 노출되기 위한 추가 요건이나 특별한 최적화는 없으며, AI를 위해 더해야 하는 특별한 schema.org 구조화 데이터도 없다고 안내합니다 Google 공식. 대신 "구조화 데이터가 페이지에 보이는 텍스트와 일치하는지 확인"하는 것을 기존 SEO 모범 사례의 하나로 제시합니다. GEO 관점에서도 새 마크업을 만들어 내기보다 이 기본을 지키는 것이 공식 문서에 들어맞는 방법입니다.

제작사 관점 실무 체크포인트

사이트를 직접 만드는 입장에서는 스키마 선언 자체보다 출력 경로와 검증 관리에서 사고가 납니다. 아래 항목은 구글 공식 문서의 권고를 따릅니다.

보이는 콘텐츠와 일치 - 구글 구조화 데이터 일반 가이드라인은 "페이지 독자에게 보이지 않는 콘텐츠를 마크업하지 말라"고 명시합니다 Google 공식. 페이지에 없는 별점이나 가격을 스키마에만 넣으면 수동 조치 대상이 될 수 있습니다.
검사기 필수 - 구글 Organization 문서는 리치 결과 테스트로 코드를 검증하고 심각한 오류를 수정하라고 권고합니다 Google 공식. 쉼표 하나로 블록 전체가 무시될 수 있으므로 눈 검토 대신 검사기를 거치고, 배포 후에는 서치 콘솔의 URL 검사 도구로 구글이 페이지를 어떻게 보는지 확인합니다.
로고 요건 - 구글 Organization 문서 기준으로 로고 이미지는 최소 112x112px 이어야 하고, 이미지 URL은 크롤링·색인 가능해야 하며, 구글 이미지가 지원하는 파일 형식이어야 합니다 Google 공식.
자기 리뷰 마크업 금지 - 구글 리뷰 스니펫 문서는 리뷰 대상이 자기 리뷰를 직접 통제하는 경우, LocalBusiness를 포함한 Organization 계열 페이지가 별점 표시 자격을 잃는다고 명시합니다 Google 공식.
중복 출력 점검 - SEO 플러그인이 이미 Organization을 출력하는데 테마에서 또 출력하면 서로 부딪히는 스키마 두 벌이 생깁니다. 페이지 소스에서 ld+json 블록 개수를 직접 확인하고 한쪽을 비활성화하거나 하나로 합칩니다.
폐지된 리치 결과에 신규 투자 금지 - 일반 사이트 기준으로 FAQ·HowTo 리치 결과는 더 이상 표시되지 않습니다. 남은 마크업이 문제를 일으키지는 않지만 표시 효과도 없다는 것이 구글 블로그의 안내입니다 구글 블로그.

함께 읽기

스키마 마크업 초심자 가이드 - 검색결과에서 돋보이기