JSON-LD 스키마 마크업 쉽게 이해하기

구글과 AI가 내 페이지를 정확히 이해하게 만드는 JSON-LD 구조화 데이터, 코드 예시와 2026년 리치 결과 변화까지 쉽게 정리합니다.

이루웹2026년 7월 23일45분 분량

JSON-LD는 내 페이지의 내용을 검색엔진과 AI에게 "번역"해서 알려주는 코드 조각이다. 스키마 마크업은 그 코드에 쓰이는 표준화된 어휘(스키마.org가 정한 용어집)를 말한다. 둘을 합쳐 흔히 구조화 데이터(structured data)라고 부른다.

사람은 페이지를 보면 "아, 이건 치과 홈페이지구나", "이건 원두 상품 페이지구나"를 한눈에 안다. 하지만 검색엔진과 AI는 코드를 읽을 뿐이라, 따로 알려주지 않으면 페이지 내용을 확실하게 구분하지 못한다.

결론부터 말하면 이렇다. JSON-LD는 구글이 공식적으로 추천하는 구조화 데이터 형식이고, <script type="application/ld+json"> 태그 안에 페이지 정보를 JSON 형태로 적어 넣는 방식이다. 별과 가격을 보여주는 상품 리치 결과, 지도에 뜨는 매장 정보, 검색 결과의 탐색경로(브레드크럼)까지 대부분 이 코드 한 덩어리에서 시작된다.

구글과 AI가 이해하는 구조화 데이터, JSON-LD 스키마 마크업 가이드 — JSON-LD는 페이지 내용을 검색엔진과 AI에게 명확히 전달하는 코드다.

이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.

JSON-LD가 무엇이고, 왜 구글이 이 형식을 추천하는가
스키마 마크업, 구조화 데이터, 스키마.org라는 비슷해 보이는 용어들의 정확한 관계
페이지 종류별로 어떤 스키마 타입을 써야 하는지 표로 정리
실제로 복사해서 쓸 수 있는 JSON-LD 코드 예시(좋은 예·나쁜 예)
2026년 5월, 구글이 FAQ 리치 결과를 검색에서 완전히 제외한 최신 변화와 대응법

조금 더 풀어 말하면, 홈페이지를 아무리 예쁘게 만들어도 검색엔진이 그 안의 정보를 정확히 못 읽으면 절반만 완성된 것이다. 구조화 데이터는 디자인이 아니라 "설명서"를 붙이는 작업에 가깝다.

이 글은 개발 지식이 없는 사업가도 오늘 바로 이해할 수 있도록, 정의부터 실제 코드, 업종별 적용 예시, 흔한 실수까지 예시 중심으로 쉽게 정리한다. 어려운 용어가 나오면 그 자리에서 한 문장으로 풀어 쓴다.

구조화 데이터는 흔히 "개발자만 아는 영역"으로 취급되어 사업가 입장에서는 지나치기 쉽다. 하지만 실제로는 홈페이지 제작을 맡길 때 반드시 확인해야 하는 항목 중 하나다. 제작사에 "우리 사이트에 JSON-LD가 제대로 들어가 있나요?"라고 한마디만 물어봐도, 그 제작사가 검색을 신경 쓰는 곳인지 아닌지 대략 가늠할 수 있다.

또 하나 짚어 둘 점이 있다. 구조화 데이터는 한 번 넣고 끝나는 작업이 아니라, 사이트 개편이나 상품 추가처럼 정보가 바뀔 때마다 함께 갱신되어야 제 역할을 한다. 이 글을 끝까지 읽고 나면, 우리 사이트에 구조화 데이터가 왜 필요한지, 무엇부터 챙겨야 하는지 스스로 판단할 수 있는 기준이 생긴다.

카페·치과·쇼핑몰·홈페이지 제작사·법률사무소·학원까지 실제 업종의 코드를 그대로 가져와 비교하니, 자기 업종과 가장 비슷한 예를 골라 값만 바꿔 넣는 것만으로도 절반은 완성된다. 개발자가 아니어도 괜찮다. 이 글이 목표로 하는 것은 코드를 외우는 것이 아니라, "우리 사이트에 무엇이 빠져 있는지"를 스스로 짚어 낼 수 있는 감각을 갖추는 것이다.

JSON-LD 구조화 데이터란 정확히 무엇인가?

JSON-LD는 "이 페이지가 무엇에 관한 것인지"를 정해진 형식의 코드로 적어 검색엔진에 알려주는 방법이다. JSON(제이슨)은 데이터를 주고받을 때 쓰는 아주 흔한 텍스트 형식이고, LD(Linked Data, 연결된 데이터)는 그 데이터가 스키마.org라는 공통 사전에 연결되어 있다는 뜻이다.

비유하자면 이렇다. 페이지 본문은 손님에게 보여주는 매장 진열대이고, JSON-LD는 그 진열대 뒤에 붙여 둔 재고 관리 카드다. 손님(방문자)은 진열대만 보면 되지만, 창고를 관리하는 시스템(검색엔진·AI)은 카드를 봐야 정확한 정보를 안다.

예를 들어 어떤 페이지에 "스페셜티 원두 200g, 4.6점, 리뷰 128개, 15,000원"이라는 문구가 화면에 보인다고 하자. 사람 눈에는 이게 상품 정보라는 게 당연해 보이지만, 검색엔진 입장에서는 그냥 나열된 글자일 뿐이다. JSON-LD는 이 글자들에 각각 이름표를 붙인다. "이건 상품명", "이건 평점", "이건 가격"이라고.

구조화 데이터는 검색엔진에게 "알아서 추측하지 말고, 내가 정확히 알려줄게"라고 말하는 작업이다.

여기서 자연스러운 의문이 생긴다. "요즘 AI가 이렇게 똑똑한데, 굳이 이름표를 붙여야 하나?" 결론부터 말하면 여전히 필요하다. 구글 검색과 AI가 페이지 텍스트를 읽고 대략적인 주제를 파악하는 것과, 정확한 수치·속성 단위로 정보를 인식하는 것은 전혀 다른 차원의 일이기 때문이다.

예를 들어 페이지 본문에 "4.6"이라는 숫자가 있다고 하자. 사람은 앞뒤 문맥을 보고 이게 평점인지, 가격인지, 무게(4.6kg)인지 쉽게 구분한다. 하지만 기계가 텍스트만으로 이걸 100% 확신하기는 쉽지 않다. "ratingValue": "4.6"처럼 명시적으로 표시해 두면, 해석의 여지 없이 정확한 값이 전달된다. 구조화 데이터의 존재 이유가 바로 이 지점에 있다.

이렇게 명확히 알려주면 구글은 이 정보를 검색 결과에 더 풍부한 형태(리치 결과)로 보여줄 수 있다. 별점과 가격이 검색 결과에 바로 뜨는 상품, 지도와 영업시간이 함께 나오는 매장, "3단계 중 2단계"처럼 표시되는 탐색경로가 모두 이 원리로 만들어진다.

여기서 중요한 오해 하나를 짚고 넘어간다. 구조화 데이터를 넣는다고 순위가 직접 오르지는 않는다. 구글도 공식 문서에서 구조화 데이터는 랭킹 요소가 아니라고 명시한다. 대신 구조화 데이터는 페이지가 리치 결과로 뜰 자격을 얻게 해 주고, 리치 결과는 검색 결과에서 더 눈에 띄어 클릭률을 올린다. 클릭률이 오르면 간접적으로 사이트 전체 평가에도 도움이 된다.

순위를 직접 올리는 마법이 아니라, "내 정보를 정확히, 매력적으로 보여 주는 장치"라고 이해하면 실무에서 헷갈릴 일이 없다.

스키마 마크업, JSON-LD, 스키마.org는 어떻게 다른가?

세 용어가 비슷해 보이지만 역할이 다르다. 스키마.org는 어휘 사전, 스키마 마크업은 그 사전을 이용해 태그를 다는 행위, JSON-LD는 태그를 담는 그릇(형식)이다. 이 셋을 한 문장으로 정리하면 "스키마.org 사전에 있는 단어를 JSON-LD라는 그릇에 담아 페이지에 붙이는 것이 스키마 마크업"이다.

첫째, 스키마.org란 무엇인가. 구글, 마이크로소프트(빙), 야후, 얀덱스가 2011년 공동으로 만든 공통 어휘 사전이다. "이 개체는 Product(상품)다", "이 개체는 LocalBusiness(지역 사업체)다", "이 개체는 Recipe(레시피)다"처럼 세상의 개체를 분류하는 표준 용어를 정의해 둔다.

주요 검색엔진들이 경쟁 관계이면서도 이 사전만큼은 함께 만들고 관리한다는 사실 자체가, 구조화 데이터가 특정 회사만의 기술이 아니라 웹 전체의 공통 언어라는 것을 보여 준다. 지금도 스키마.org는 새로운 개체 타입을 계속 추가하며 발전하고 있다.

전 세계 어떤 사이트든 이 사전에 있는 같은 단어(예: Product)를 쓰면, 검색엔진은 언어가 달라도 "아, 이건 상품이구나"라고 똑같이 이해한다. 표준어를 쓰면 누구나 알아듣는 것과 같은 원리다.

둘째, 스키마 마크업이란 무엇인가. 스키마.org의 어휘를 실제 페이지 코드에 적용하는 작업 전체를 가리킨다. "이 페이지에 스키마 마크업을 넣었다"는 말은 "스키마.org 어휘를 이용해 이 페이지의 정보를 구조화했다"는 뜻이다.

셋째, JSON-LD란 무엇인가. 앞서 설명했듯, 그 스키마 마크업을 담는 형식 중 하나다. 스키마.org 어휘는 JSON-LD 외에도 Microdata, RDFa라는 다른 그릇에 담을 수도 있다. 다만 구글은 셋 중 JSON-LD를 공식적으로 추천한다.

구조화 데이터를 표현하는 JSON-LD, Microdata, RDFa 세 가지 형식을 비교한 이미지 — 구글은 세 형식을 모두 인식하지만, 관리 편의성 때문에 JSON-LD를 공식 추천한다.

세 형식의 차이를 표로 정리한다.

형식	방식	특징
JSON-LD	`<script>` 태그로 본문과 분리	구글 공식 추천, 넣고 빼기 쉬움, 실무 표준
Microdata	HTML 태그 속성(`itemprop` 등)에 직접 삽입	본문 구조와 뒤섞여 유지보수가 번거로움
RDFa	HTML5 확장 속성 방식	문법이 복잡해 실무에서 잘 쓰이지 않음

세 형식 모두 구글이 인식은 하지만, 실무에서는 거의 JSON-LD만 쓴다고 봐도 무방하다. 본문 코드를 건드리지 않고 <head>나 <body> 어디에든 코드 한 덩어리로 넣고 뺄 수 있어서, 웹사이트를 관리하는 입장에서 가장 번거롭지 않기 때문이다. 셋 중 무엇을 골라야 할지 고민할 필요는 없다. 특별한 이유가 없다면 JSON-LD 하나만 알면 충분하다.

구조화 데이터는 사이트맵·robots.txt와 어떻게 다른가?

서로 다른 목적을 가진 완전히 별개의 장치다. 사이트맵은 "어떤 페이지들이 있는지"를 알려주는 목록이고, robots.txt는 "어디를 크롤링해도 되는지"를 정하는 규칙이며, 구조화 데이터는 "그 페이지 안의 내용이 무엇인지"를 설명하는 이름표다. 셋 다 SEO의 기본기이지만 역할이 완전히 다르므로 헷갈리지 않아야 한다.

비유하자면 이렇다. 사이트맵은 건물의 층별 안내도이고, robots.txt는 출입 가능한 문과 잠긴 문을 표시한 안내판이며, 구조화 데이터는 각 사무실 문에 붙은 명패다. 안내도로 건물 전체 구조를 파악하고, 안내판으로 들어가도 되는 곳을 확인한 뒤, 명패를 보고 그 방이 정확히 무슨 용도인지 아는 것이다.

세 가지의 관계를 표로 정리한다.

장치	역할	없으면 생기는 문제
사이트맵(`sitemap.xml`)	사이트의 전체 페이지 목록을 알려줌	새 페이지 발견이 늦어질 수 있음
robots.txt	크롤링을 허용·차단할 영역을 지정	불필요한 페이지까지 크롤링되거나, 실수로 전체 차단될 수 있음
구조화 데이터(JSON-LD)	페이지 내용의 의미를 설명	리치 결과·AI 이해도 측면에서 손해를 봄

셋 중 하나만 잘한다고 검색 성과가 완성되지는 않는다. 사이트맵으로 페이지를 발견시키고, robots.txt로 불필요한 크롤링을 막고, 구조화 데이터로 그 안의 의미를 정확히 전달하는 것이 한 세트다. 이 사이트처럼 Next.js 기반으로 구축된 사이트는 새 글을 추가하면 사이트맵과 구조화 데이터(BlogPosting, BreadcrumbList)가 코드 구조상 자동으로 함께 반영되도록 설계해 두는 경우가 많은데, 이렇게 자동화해 두면 담당자가 매번 수동으로 신경 쓰지 않아도 되는 장점이 있다.

실제로 셋 중 하나만 빠져도 문제가 생긴다. 사이트맵만 잘 갖추고 구조화 데이터가 없으면, 페이지는 발견되지만 검색 결과 화면은 밋밋하게 텍스트만 노출된다. 반대로 구조화 데이터를 아무리 정교하게 넣어도 robots.txt에서 해당 페이지가 실수로 차단되어 있으면, 구글은 애초에 그 페이지를 읽지도 못하므로 마크업 자체가 무의미해진다. 셋을 따로따로 점검하지 말고, 함께 갖춰졌는지 주기적으로 확인하는 습관이 필요한 이유다.

구조화 데이터를 넣으면 무엇이 달라지나?

구조화 데이터를 제대로 넣으면 검색 결과에서 더 많은 정보가, 더 눈에 띄게 노출된다. 같은 순위라도 별점과 가격이 함께 보이는 결과가 텍스트만 있는 결과보다 클릭을 더 많이 가져간다는 사실은 이미 여러 실무 데이터로 검증되어 있다.

이 변화는 검색 결과 화면을 실제로 나란히 놓고 비교해 보면 가장 잘 느껴진다. 한쪽은 파란 제목과 회색 설명 두 줄뿐이고, 다른 한쪽은 별점과 가격, 재고 상태까지 함께 보인다면 사람의 시선은 자연스럽게 정보가 많은 쪽으로 먼저 간다. 구조화 데이터는 이 차이를 만드는 가장 기본적인 장치다.

구체적으로 어떤 효과가 있는지 짚어 본다.

첫째, 검색 결과 화면이 풍부해진다(리치 결과). 상품 페이지에 Product 스키마를 넣으면 가격과 별점이 검색 결과에 바로 노출될 수 있다. 매장 페이지에 LocalBusiness 스키마를 넣으면 영업시간과 주소가 함께 뜬다. 블로그 글에 BreadcrumbList 스키마를 넣으면 URL 대신 "홈 > 블로그 > 글제목" 같은 탐색경로가 표시된다.

둘째, AI 검색과 답변 엔진이 내용을 더 정확히 이해한다. 챗지피티, 퍼플렉시티, 구글 AI 개요 같은 생성형 AI 검색은 페이지를 통째로 읽고 요약하는 경우가 많은데, 구조화 데이터가 잘 정리되어 있으면 "이 페이지가 무엇을 다루는지"를 AI가 더 빠르고 정확하게 파악한다. 검색이 AI 답변 형태로 옮겨가는 지금, 이 부분의 중요성은 오히려 커지고 있다.

셋째, 개체(entity) 정보가 명확해진다. 회사 이름, 로고, 공식 SNS 채널 같은 정보를 Organization 스키마와 sameAs 속성으로 연결해 두면, 구글이 "이 사이트가 어떤 사업체인지"를 지식 그래프(구글이 실체를 정리해 두는 데이터베이스)에 더 정확히 등록할 확률이 올라간다.

넷째, 경쟁사와의 화면 격차가 생긴다. 같은 검색어로 나란히 뜬 두 결과 중 하나만 별점과 가격이 보인다면, 사람 눈은 자연스럽게 정보가 더 많은 쪽으로 간다. 구조화 데이터를 챙긴 사이트와 그렇지 않은 사이트의 차이는 순위표에는 안 보여도 실제 클릭 화면에서는 분명하게 드러난다.

다만 여기서 최근 가장 크게 달라진 부분을 반드시 짚고 가야 한다. 구글은 2026년 5월 7일, FAQ 리치 결과를 검색 결과에서 전면 제외했다. 이 변화는 갑작스러운 것이 아니라 2023년 8월부터 시작된 단계적 축소의 마지막 단계다. 당시 구글은 FAQ 리치 결과 노출 대상을 정부·보건 기관 등 일부 신뢰도 높은 사이트로 크게 줄였고, 같은 시점에 HowTo(단계별 안내) 리치 결과는 검색에서 아예 사라졌다.

2026년 기준 구글 검색에서 여전히 리치 결과로 노출되는 스키마 타입과 제외된 타입을 비교한 이미지 — FAQPage와 HowTo는 2026년 현재 검색 리치 결과에서 제외됐지만, 다른 주요 타입은 여전히 유효하다.

2026년 5월 이후로는 그 예외조차 사라져, 어떤 사이트든 FAQPage 마크업만으로 검색에서 확장된 형태(질문이 접혔다 펼쳐지는 형태)로 노출되지는 않는다. 구글은 이와 함께 6월에는 서치 콘솔의 FAQ 관련 리포트를, 8월에는 API 지원까지 순차적으로 정리한다고 공지했다.

그렇다고 FAQPage 마크업 자체가 "틀린 것"이 되는 건 아니다. 구글은 "쓰지 않는 구조화 데이터가 있어도 검색에 문제를 일으키지 않는다"고 안내한다. 다만 검색 리치 결과라는 실익은 더 이상 기대하기 어렵다.

이 변화가 주는 실무적 시사점은 두 가지다.

FAQPage 스키마에 시간을 쏟는 우선순위를 낮춘다. 남겨 둬도 무방하지만, 이제 리치 결과를 목적으로 새로 공들여 작성할 이유는 크지 않다.
다만 페이지 안에 질문형 소제목과 직접적인 답변을 쓰는 콘텐츠 구조 자체는 여전히 가치가 있다. 이는 구글 검색 노출이 아니라, AI 검색 엔진이 답변을 만들 때 인용하기 좋은 형태이기 때문이다. GEO(생성형엔진최적화)의 기본 원리가 이것인데, 궁금하다면 GEO 생성형엔진최적화 가이드에서 더 자세히 다룬다.

정리하면, 구글 검색의 리치 결과라는 "화면 효과"는 줄었지만, AI가 내용을 이해하도록 돕는 구조화 데이터의 근본적인 역할은 오히려 더 중요해지고 있다. 무엇을 쓰고 무엇을 덜 신경 써도 되는지 구분하는 안목이 필요한 시점이다.

어떤 페이지에 어떤 스키마 타입을 써야 하나?

페이지 종류마다 어울리는 스키마 타입이 다르다. 엉뚱한 타입을 쓰면 오히려 구글이 페이지 성격을 잘못 이해할 수 있으니, 실제 내용과 정확히 맞는 타입을 골라야 한다.

가장 자주 쓰이는 타입을 표로 정리한다. 2026년 현재 검색 리치 결과 지원 여부도 함께 표시한다.

스키마 타입	적합한 페이지	2026년 리치 결과
`Organization`	회사·브랜드 전체(주로 홈)	지식 패널 보조 정보
`LocalBusiness`	지역 매장·병원·학원	지도·영업시간 노출
`Product`	개별 상품	가격·재고 노출
`Review` / `AggregateRating`	리뷰·평점이 있는 페이지	별점 노출
`Article` / `BlogPosting`	블로그·뉴스 글	작성자·날짜 정보
`BreadcrumbList`	계층 구조가 있는 모든 페이지	탐색경로 노출
`Event`	행사·세미나 안내	날짜·장소 노출
`JobPosting`	채용 공고	채용 정보 카드
`Recipe`	레시피 콘텐츠	조리시간·이미지 노출
`VideoObject`	영상이 포함된 페이지	썸네일·재생시간 노출
`FAQPage`	자주 묻는 질문 섹션	2026년부터 리치 결과 없음

표 하나로 모든 경우를 다 담을 수는 없지만, "이 페이지의 정체성이 무엇인가"를 스스로 물으면 타입은 대개 자연스럽게 정해진다. 카페 소개 페이지라면 LocalBusiness, 원두 상품 페이지라면 Product, 블로그 글이라면 Article이 기본값이다.

한 페이지에 여러 타입을 함께 쓸 수도 있다. 예를 들어 블로그 글 페이지에는 Article과 BreadcrumbList를 동시에 넣는 경우가 흔하다. 실제로 이 사이트의 블로그 글에도 Article, BreadcrumbList 스키마가 함께 들어간다. 각자 다른 정보를 설명하는 독립된 코드 덩어리이므로 여러 개를 넣어도 문제가 되지 않는다.

타입을 잘못 고르면 어떤 일이 생기는지 예를 들어 보자. 어떤 세무사무소가 상담 안내 페이지에 Product를 붙였다고 하자. 구글은 이 페이지를 "구매 가능한 상품"으로 이해하려 시도하지만, 실제로는 가격·재고 같은 상품 속성이 존재하지 않으므로 인식에 실패하거나 어색한 결과가 노출된다. 반대로 ProfessionalService(전문 서비스업)로 정확히 선언하면, 구글은 이 페이지를 "상담이 필요한 서비스"로 올바르게 분류한다.

타입 선택은 "가장 화려해 보이는 것"이 아니라 "가장 정확한 것"을 고르는 일이다. 화려한 리치 결과를 기대하고 맞지 않는 타입을 붙이는 것보다, 소박해도 정확한 타입을 쓰는 편이 장기적으로 훨씬 안전하다.

스키마.org 사전에는 이 글에서 다루는 것보다 훨씬 많은 세부 타입이 있다. LocalBusiness 하위에도 Restaurant, HairSalon, RealEstateAgent 같은 수십 가지 세부 타입이 정의되어 있다. 시간이 된다면 스키마.org 공식 사이트에서 내 업종에 정확히 맞는 세부 타입이 있는지 검색해 보는 것도 좋은 방법이다. 세부 타입을 정확히 쓸수록 구글이 파악하는 정보의 해상도가 올라간다.

타입을 고를 때 기준은 하나다. "이 페이지를 사람에게 한 문장으로 설명한다면 뭐라고 할까?" 그 답에 해당하는 타입을 고르면 된다.

딱 맞는 타입을 못 찾겠다면 너무 오래 고민하지 않아도 된다. 스키마.org에는 아주 구체적인 세부 타입부터 폭넓은 상위 타입까지 여러 층위가 존재하므로, 정확한 세부 타입을 못 찾았다면 그보다 상위의 폭넓은 타입을 쓰는 것도 방법이다. 예를 들어 정확한 업종 타입이 애매한 서비스업이라면, 가장 상위 개념인 LocalBusiness만 정확히 채워도 충분한 출발점이 된다. 나중에 더 정확한 세부 타입을 알게 되면 그때 바꿔도 늦지 않다.

JSON-LD 코드는 실제로 어떻게 생겼나?

말로만 설명하면 감이 잘 안 오니, 실제 코드로 확인해 보자. 코드를 처음 보면 낯설게 느껴질 수 있지만, 사실 이 코드는 "항목: 값"을 쉼표로 나열한 목록에 지나지 않는다. 엑셀 표에서 한 행을 세로로 풀어 쓴 것과 비슷하다고 생각하면 훨씬 편하다.

아래는 지역 매장을 예로 든 가장 기본적인 형태다.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "이루웹",
  "url": "https://iruweb.com",
  "telephone": "02-000-0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "예시로 123",
    "addressLocality": "서울",
    "addressCountry": "KR"
  }
}
</script>

구조를 하나씩 풀면 이렇다.

@context: "이 코드는 스키마.org 사전을 쓴다"는 선언. 거의 항상 고정된 값이다.
@type: 이 개체가 스키마.org의 어떤 타입에 해당하는지. 여기서는 LocalBusiness(지역 사업체).
그 아래 줄들: 이름, 주소, 전화번호처럼 스키마.org가 정의해 둔 속성(property)에 실제 값을 채운 것.

여기까지가 전부다. 복잡해 보이지만 실제로는 "이름표를 붙인 항목 나열"에 가깝다. 어렵게 느껴진다면, 사업 등록증에 적는 항목(상호, 주소, 연락처)을 코드 형태로 옮겨 적는다고 생각하면 된다.

이제 실수하기 쉬운 좋은 예와 나쁜 예를 비교해 본다. 상품 페이지에 평점 정보를 마크업하는 상황이다.

같은 상품 페이지에 대한 나쁜 JSON-LD 예시와 좋은 JSON-LD 예시를 코드로 비교한 이미지 — 나쁜 예는 실제 리뷰 없이 평점을 임의로 채웠고, 좋은 예는 실제 값과 정확히 일치한다.

나쁜 예는 두 가지 문제가 있다. @context가 빠져 있어 구글이 이 데이터가 스키마.org 기준인지 확신할 수 없고, 실제 리뷰가 없는데도 평점을 "5.0"으로 임의로 적었다. 가짜 평점은 구글의 스팸 정책 위반이며, 적발되면 해당 페이지의 리치 결과 자격이 아예 박탈될 수 있다.

좋은 예는 @context를 명확히 선언했고, 실제 리뷰 128건을 근거로 한 평점 4.6을 적었다. 화면에 보이는 값과 코드 속 값이 정확히 일치한다는 점이 핵심이다.

구조화 데이터의 첫 번째 원칙은 "화면에 없는 내용을 코드에만 적지 않는다"는 것이다. 사람 눈에 안 보이는 정보를 마크업에만 몰래 넣는 것은 구글이 명시적으로 금지하는 행위다.

실무에서는 코드를 매번 손으로 짤 필요는 없다. 워드프레스 같은 CMS는 SEO 플러그인이 상품·글 정보를 읽어 자동으로 JSON-LD를 생성해 주는 경우가 많고, Next.js 같은 프레임워크로 만든 사이트는 페이지 데이터를 기반으로 스크립트를 자동 출력하도록 개발 단계에서 설계해 둔다. 중요한 것은 코드를 직접 짜는 능력이 아니라, 어떤 값이 정확히 들어가야 하는지를 아는 것이다.

나쁜 마크업을 단계별로 고쳐볼까?

이해를 굳히기 위해, 실제로 흔한 나쁜 마크업 하나를 단계별로 고쳐 보자. 정답을 외우는 것보다 고치는 과정을 눈으로 따라가는 편이 훨씬 오래 남는다. 예로 든 것은 동네 필라테스 학원의 홈페이지다.

처음 마크업은 이랬다.

{
  "@type": "WebPage",
  "name": "홈"
}

문제가 한눈에 보인다.

@context가 없다. 이 코드가 스키마.org 기준이라는 선언 자체가 빠졌다.
타입이 부정확하다. WebPage는 "그냥 웹페이지"라는 뜻이라, 이 사이트가 필라테스 학원이라는 정보가 전혀 담기지 않는다.
이름조차 의미가 없다. "홈"이라는 값은 사람에게도 검색엔진에게도 아무 정보를 주지 못한다.

이제 순서대로 고쳐 본다.

@context를 선언한다. "@context": "https://schema.org"를 가장 먼저 추가한다.
정확한 타입으로 바꾼다. 필라테스 학원은 체육 시설이므로 LocalBusiness(또는 그 하위 타입인 ExerciseGym)로 바꾼다.
핵심 정보를 채운다. 이름, 주소, 전화번호, 영업시간처럼 손님이 실제로 궁금해할 정보를 넣는다.

최종 결과는 이렇게 바뀐다.

{
  "@context": "https://schema.org",
  "@type": "ExerciseGym",
  "name": "망원동 필라테스 ○○",
  "address": { "@type": "PostalAddress", "addressLocality": "서울 마포구" },
  "telephone": "02-000-0000",
  "openingHours": "Mo-Fr 07:00-22:00"
}

처음의 의미 없는 코드와 비교하면, 이제 검색엔진은 이 페이지가 "망원동에 있는 필라테스 시설"이라는 사실을 명확히 파악할 수 있다. 이 과정을 한 문장으로 요약하면, "이 페이지의 정체가 무엇인가"를 가장 정확한 타입으로 선언하고, 그 정체에 맞는 핵심 정보를 빠짐없이 채우는 것이다.

어떤 업종이든 이 순서대로 물으면 부실한 마크업이 쓸모 있는 마크업으로 바뀐다.

업종별로 어떻게 다르게 적용하나?

같은 원리라도 업종마다 강조할 속성이 다르다. 실제 업종 예시로 감을 잡아 보자.

카페

카페는 LocalBusiness(또는 하위 타입인 CafeOrCoffeeShop)를 기본으로 쓴다. 핵심은 위치, 영업시간, 좌석·와이파이 같은 편의시설을 정확히 채우는 것이다.

{
  "@context": "https://schema.org",
  "@type": "CafeOrCoffeeShop",
  "name": "성수동 카페 ○○",
  "address": { "@type": "PostalAddress", "addressLocality": "서울 성동구" },
  "openingHours": "Mo-Su 09:00-22:00",
  "amenityFeature": "무료 와이파이, 콘센트 좌석"
}

지역 검색과 지도 노출에 직접 연결되므로, 카페·식당처럼 동네 손님이 중요한 업종일수록 이 마크업의 효과가 크다. 특히 "영업 중"이라는 실시간 표시는 openingHours 값이 정확할 때만 신뢰할 수 있게 작동하므로, 시즌별로 영업시간이 바뀌는 카페라면 이 값을 주기적으로 업데이트하는 것이 중요하다.

치과·병원

의료 업종은 MedicalBusiness나 Dentist 같은 세부 타입을 쓰고, 진료 과목, 의료진 정보, 리뷰를 함께 다룬다. 다만 의료 정보는 구글이 특히 정확성을 까다롭게 검토하는 분야이므로, 과장되거나 확인되지 않은 효능·후기는 넣지 않아야 한다.

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "name": "○○치과의원",
  "address": { "@type": "PostalAddress", "addressLocality": "서울 강남구" },
  "medicalSpecialty": "임플란트, 보철"
}

병원은 특히 신뢰가 사업의 전부라고 해도 과언이 아니다. 환자는 치료를 받기 전 검색 결과에서부터 "믿을 만한 곳인가"를 판단하기 시작하므로, 정확하고 절제된 정보 표기가 화려한 문구보다 훨씬 큰 신뢰를 만든다.

쇼핑몰

Product와 Offer(가격 정보), AggregateRating(종합 평점)을 함께 쓴다. 상품이 수백 개라면 하나하나 손으로 넣기보다, 쇼핑몰 플랫폼이나 CMS가 상품 데이터베이스를 기반으로 자동 생성하도록 설정하는 것이 현실적이다.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "스페셜티 원두 200g",
  "offers": { "@type": "Offer", "priceCurrency": "KRW", "price": "15000" },
  "aggregateRating": { "@type": "AggregateRating", "ratingValue": "4.6", "reviewCount": "128" }
}

쇼핑몰은 페이지가 수백에서 수천 개에 이르므로, 마크업 하나를 잘못 설계하면 그 오류가 사이트 전체에 그대로 복제된다는 위험도 함께 있다. 템플릿 단계에서 값이 정확히 채워지는지 한 번만 꼼꼼히 검증해 두면, 이후 수백 개 상품에 자동으로 동일한 품질이 적용된다는 것이 쇼핑몰 구조화 데이터의 특징이다.

홈페이지 제작사·에이전시

Organization을 기본으로 하고, sameAs 속성에 공식 SNS·지도 URL을 나열해 회사 개체를 하나로 묶어 준다. 이렇게 하면 구글이 여러 채널에 흩어진 정보를 같은 사업체로 인식하는 데 도움이 된다.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "이루웹",
  "url": "https://iruweb.com",
  "logo": "https://iruweb.com/logo.png",
  "sameAs": ["https://instagram.com/iruweb", "https://blog.naver.com/iruweb"]
}

이런 개체 정보는 대개 홈페이지에 한 번만 넣어 두면 되지만, 회사의 정체성을 규정하는 만큼 정확도가 특히 중요하다. 로고 이미지 경로가 틀리거나 SNS 링크가 오래된 계정을 가리키고 있으면, 잘못된 정보가 계속 참조될 수 있으니 사이트를 개편할 때마다 이 부분도 함께 점검하는 것이 좋다.

블로그·정보성 콘텐츠

Article(또는 BlogPosting)과 BreadcrumbList를 함께 쓴다. 저자, 발행일, 대표 이미지를 정확히 채우면 뉴스·정보 콘텐츠로서의 신뢰도(E-E-A-T, 경험·전문성·권위·신뢰)를 검색엔진에 더 명확히 전달할 수 있다. E-E-A-T와 콘텐츠 신뢰도를 쌓는 방법은 검색에 강한 SEO 글쓰기에서 더 다룬다.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "홈페이지 제작 비용을 결정하는 요소",
  "datePublished": "2026-06-20",
  "author": { "@type": "Organization", "name": "이루웹" }
}

법률·세무 사무소

전문직 서비스는 LegalService나 AccountingService 같은 세부 타입을 쓴다. 핵심은 취급 업무 범위와 신뢰 근거(자격, 경력)를 명확히 담는 것이다. 의뢰인은 어떤 업무를 다루는 곳인지부터 확인하기 때문에, 업무 범위를 구체적으로 적을수록 정확한 검색어와 잘 맞아떨어진다.

{
  "@context": "https://schema.org",
  "@type": "AccountingService",
  "name": "○○세무회계",
  "areaServed": "서울",
  "priceRange": "상담 후 안내"
}

학원(영어)

교육 업종은 EducationalOrganization을 기본으로 쓰고, 대상 연령, 과목, 위치를 명확히 밝힌다. 학부모는 "우리 아이에게 맞는 곳인가"를 가장 먼저 확인하므로, 대상을 구체적으로 적어 둔 마크업일수록 정확한 손님과 연결된다.

{
  "@context": "https://schema.org",
  "@type": "EducationalOrganization",
  "name": "분당 초등 영어학원 ○○",
  "address": { "@type": "PostalAddress", "addressLocality": "경기 성남시" }
}

이렇게 업종마다 강조점은 다르지만, 원리는 하나로 같다. "이 페이지의 핵심 정보가 무엇인지 화면과 정확히 같은 값으로 코드에 남긴다."

상품 페이지 하나, 처음부터 끝까지 만들어 보면?

앞서 여러 조각으로 나눠 설명한 내용을 하나로 이어서, 쇼핑몰 상품 페이지 하나를 처음부터 끝까지 완성하는 과정을 순서대로 따라가 보자. 지금까지 배운 개념이 실제로 어떻게 합쳐지는지 확인하는 것이 목적이다.

1단계, 페이지 정체성을 정한다. 이 페이지는 "린넨 셔츠"를 파는 상품 페이지다. 스키마.org에서 가장 정확한 타입은 Product다.

2단계, 필수 정보를 나열한다. 상품명, 가격, 통화, 재고 상태처럼 화면에 이미 나와 있는 정보를 그대로 옮긴다. 없는 값을 지어내지 않는다.

3단계, 신뢰 정보를 더한다. 실제 리뷰가 있다면 aggregateRating으로 평점과 리뷰 수를 추가한다. 리뷰가 없다면 이 항목은 아예 뺀다. 없는 데이터는 빈칸으로 두는 것이 지어내는 것보다 항상 낫다.

4단계, 완성된 코드를 확인한다.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "린넨 오버핏 셔츠",
  "image": "https://example-mall.com/images/linen-shirt.jpg",
  "description": "구김이 적은 여름 린넨 혼방 오버핏 셔츠",
  "offers": {
    "@type": "Offer",
    "priceCurrency": "KRW",
    "price": "39000",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "62"
  }
}

5단계, 검증한다. 이 코드를 페이지에 삽입한 뒤 Rich Results Test에 URL을 넣어, Product 타입이 오류 없이 인식되는지 확인한다.

이 다섯 단계는 상품 페이지뿐 아니라 어떤 페이지에도 그대로 적용할 수 있는 흐름이다. 정체성을 정하고, 사실을 나열하고, 신뢰 정보를 더하고, 코드로 옮기고, 검증한다. 순서를 기억해 두면 어떤 업종이든 스스로 적용할 수 있다.

넣은 구조화 데이터, 어떻게 검증하나?

마크업을 넣었다고 끝이 아니다. 문법 오류가 있거나 필수 속성이 빠지면 구글이 아예 인식하지 못할 수 있으므로 반드시 검증해야 한다.

가장 확실한 방법은 구글이 무료로 제공하는 Rich Results Test(리치 결과 테스트) 도구다. 페이지 URL이나 코드를 직접 붙여 넣으면, 어떤 스키마가 인식됐는지, 오류나 경고가 있는지 바로 보여준다.

확인 절차는 이렇게 진행하면 된다.

Rich Results Test에 페이지 URL을 입력한다. 실제 배포된 페이지 기준으로 검사하는 것이 가장 정확하다.
인식된 항목을 확인한다. 의도한 타입(예: Product)이 목록에 뜨는지 본다.
오류와 경고를 구분한다. 오류(error)는 반드시 고쳐야 리치 결과 자격을 얻는다. 경고(warning)는 선택 속성이 빠졌다는 뜻으로, 급하지 않지만 채워 두면 더 좋다.
구글 서치 콘솔의 "향상된 기능" 리포트로 사이트 전체를 주기적으로 점검한다. 특정 페이지만이 아니라 사이트 전체에서 같은 오류가 반복되는지 확인할 수 있다. 서치 콘솔 활용법 전반은 구글 서치 콘솔 사용법에서 자세히 다룬다.

검증은 한 번으로 끝나지 않는다. 페이지 디자인을 바꾸거나 CMS를 교체할 때 마크업이 함께 깨지는 경우가 흔하므로, 큰 개편이 있을 때마다 다시 검사하는 습관을 들이는 것이 안전하다.

검증에서 오류가 나면 대부분 원인은 단순하다. 필수 속성 누락, 값의 형식 오류(가격에 통화 기호를 함께 적는 등), 혹은 같은 타입을 실수로 중복 선언한 경우다. 하나씩 고쳐 재검사하면 대개 금방 해결된다.

자주 나오는 경고·오류 메시지를 미리 알아 두면 당황하지 않는다.

"필수 속성이 누락되었습니다": 그 타입에서 반드시 있어야 하는 값이 빠졌다는 뜻이다. 도구가 어떤 속성인지 정확히 알려주므로 그 항목만 채우면 된다.
"권장 속성이 누락되었습니다": 없어도 인식은 되지만, 채우면 리치 결과가 더 풍부해진다는 안내다. 급하지 않지만 시간이 될 때 채우는 것이 좋다.
"구문 분석 오류": JSON 문법 자체가 깨졌다는 뜻이다. 쉼표 위치나 중괄호 짝을 다시 확인한다.
"페이지에서 이 항목을 찾을 수 없습니다": 마크업에는 있지만 실제 화면에는 없는 값이 있다는 신호다. 화면 내용과 코드가 어긋난 것이므로 반드시 맞춰야 한다.

검증을 마친 뒤에는 서치 콘솔의 "향상된 기능" 리포트를 몇 주 간격으로 다시 열어 보는 습관을 들이면 좋다. 처음에는 오류가 0건이었다가, 상품을 새로 추가하거나 페이지 구조를 바꾸는 과정에서 다시 오류가 생기는 경우가 흔하기 때문이다. 구조화 데이터는 "한 번 검증하고 끝"이 아니라 사이트가 바뀔 때마다 함께 관리해야 하는 살아있는 항목이라는 점을 기억해 두면 실수를 줄일 수 있다.

구조화 데이터를 쓸 때 흔한 실수는 무엇인가?

실무에서 반복적으로 나타나는 실수를 정리한다. 신기하게도 실수의 대부분은 "코드를 몰라서"가 아니라 "화면과 코드를 따로 관리해서" 생긴다. 페이지 내용을 바꿀 때 코드도 함께 바꾼다는 습관만 있어도 아래 문제의 절반은 저절로 예방된다.

첫 번째, 화면에 없는 내용을 마크업에만 넣는 것. 방문자 눈에는 안 보이는 정보를 코드에만 몰래 채우는 행위는 구글의 구조화 데이터 정책 위반이다. 예를 들어 페이지에는 없는 할인율이나 리뷰 개수를 코드에만 적으면, 적발 시 리치 결과 자격이 통째로 박탈될 수 있다. 마크업은 항상 화면 내용의 정확한 요약이어야 한다.

두 번째, 가짜 리뷰·평점. 앞서 코드 예시에서 본 것처럼, 실제 리뷰가 없는데 별점을 임의로 채우는 경우가 매우 흔하다. 이는 방문자를 속이는 행위이기도 해서, 발견되면 신뢰에도 큰 타격을 준다. 평점은 반드시 실제 데이터를 기반으로 한다.

세 번째, 모든 페이지에 같은 마크업을 복사하는 것. 홈, 서비스 페이지, 블로그 글에 전부 똑같은 Organization 정보만 붙여 넣으면, 검색엔진은 각 페이지의 고유한 정체성을 파악하기 어렵다. 페이지 성격에 맞는 타입을, 페이지마다 고유하게 넣어야 한다.

네 번째, 필수 속성 누락. 타입마다 "이건 반드시 있어야 인식된다"는 필수 속성이 있다. Product라면 이름과 가격 정보, Recipe라면 조리 시간 같은 항목이다. 이걸 빠뜨리면 아무리 나머지를 잘 채워도 리치 결과 자격을 얻지 못한다.

다섯 번째, FAQPage에 과도한 시간을 쏟는 것. 앞서 다뤘듯 2026년 5월부터 FAQPage는 검색 리치 결과가 없다. 기존에 넣어 둔 마크업을 급하게 지울 필요는 없지만, 새로 리치 결과를 기대하고 공들여 작성하는 것은 이제 우선순위가 낮다.

여섯 번째, 문법 오류로 아예 인식되지 않는 것. JSON 형식은 쉼표나 중괄호 하나만 틀려도 전체가 깨진다. 코드를 직접 수정했다면 반드시 Rich Results Test로 재검증해야 한다.

일곱 번째, 개체 연결(sameAs)을 빠뜨리는 것. 회사의 공식 채널들을 서로 연결해 두지 않으면, 구글이 같은 사업체를 여러 개의 서로 다른 개체로 오인할 수 있다. 특히 신생 사이트일수록 이 연결이 신뢰를 쌓는 데 중요하다.

여덟 번째, 페이지 성격과 맞지 않는 타입을 고르는 것. 단순 소개 페이지에 Product를 억지로 붙이거나, 상품 페이지에 Article을 붙이는 식이다. 타입이 실제 페이지 성격과 어긋나면 구글이 혼란스러워하고, 최악의 경우 리치 결과 자격 자체가 거부된다. 애매하면 가장 좁고 정확한 타입을 고르는 것이 안전하다.

아홉 번째, 한 페이지에 관련 없는 타입을 욱여넣는 것. "혹시 몰라서" 상품 페이지에 FAQPage, Event, Recipe를 전부 붙이는 경우가 있다. 페이지 내용과 실제로 관련 있는 타입만 남기고, 나머지는 과감히 제거하는 편이 낫다. 많이 넣는다고 유리해지지 않는다 — 정확하게 넣는 것이 유리해진다.

아홉 가지를 표로 한눈에 정리하면 아래와 같다.

실수	해결 방향
화면에 없는 내용을 마크업에만 추가	화면과 코드를 항상 같은 값으로 유지
가짜 리뷰·평점 입력	실제 데이터가 없으면 항목 자체를 생략
모든 페이지에 동일한 마크업 복사	페이지 성격에 맞는 고유한 타입 사용
필수 속성 누락	타입별 필수 항목을 사전에 확인
FAQPage에 과도한 시간 투입	여전히 유효한 타입으로 우선순위 이동
문법 오류로 인식 실패	수정 후 Rich Results Test로 재검증
`sameAs` 연결 누락	공식 채널 URL을 빠짐없이 연결
부정확한 타입 선택	가장 좁고 정확한 타입을 우선 고려
관련 없는 타입 욱여넣기	페이지와 직접 관련된 타입만 유지

이 아홉 가지만 피해도 대부분의 구조화 데이터 오류는 예방된다. 완벽한 코드보다, 정직하고 정확한 코드가 항상 우선이다.

직접 해도 될까, 전문가에게 맡겨야 할까?

정보성 페이지 몇 개라면 직접 시도해 볼 만하다. 이 글에서 소개한 예시 코드를 복사해 이름·주소·연락처 같은 값만 바꿔 넣고, Rich Results Test로 확인하는 정도는 개발 경험이 없어도 충분히 가능하다.

다만 아래 경우라면 전문가나 제작사의 손을 빌리는 편이 안전하다.

상품이 수십 개 이상인 쇼핑몰. 상품마다 손으로 코드를 넣는 것은 비효율적이고 실수도 잦다. 상품 데이터베이스와 자동으로 연동되는 구조로 설계해야 한다.
여러 지점을 운영하는 사업체. 지점마다 LocalBusiness를 따로, 정확하게 선언해야 각 지점이 검색과 지도에서 독립적으로 노출된다.
사이트 구조 자체를 새로 설계하는 경우. 페이지 종류가 늘어나고 구조가 복잡해질수록, 처음부터 구조화 데이터를 설계에 포함시키는 것이 나중에 하나씩 땜질하는 것보다 훨씬 효율적이다.

구조화 데이터는 "다 만들고 나중에 추가하는 장식"이 아니라, 처음 사이트를 설계할 때부터 함께 고려해야 할 기본 골격에 가깝다.

작은 사업체가 페이지 몇 개에 기본적인 LocalBusiness나 Organization 마크업을 넣는 정도는 직접 해봐도 좋은 연습이 된다. 하지만 사이트 전체의 구조화 데이터 전략, 여러 타입 간의 관계 설계, 자동화까지 고려한다면 처음부터 이를 염두에 두고 만드는 제작사와 함께하는 편이 장기적으로 시간과 비용을 아낀다.

직접 해 보기로 했다면, 처음부터 완벽하게 하려고 애쓰지 않아도 된다. 가장 중요한 페이지 하나만 정확히 마쳐도 충분히 의미 있는 시작이다. 그 다음 페이지, 그 다음 상품으로 하나씩 넓혀 가면 어느새 사이트 전체가 정리된다. 반대로 전문가에게 맡기기로 했다면, 담당자가 최소한 이 글에서 다룬 개념(JSON-LD가 무엇인지, 어떤 타입이 우리 업종에 맞는지)만큼은 이해하고 있는 것이 좋다. 결과물을 스스로 점검할 수 있어야 나중에 문제가 생겼을 때도 빠르게 원인을 파악할 수 있기 때문이다.

발행 전 체크리스트는 무엇인가?

실제로 페이지에 구조화 데이터를 넣기 전, 아래 항목으로 마지막 점검을 하면 실수를 줄일 수 있다.

구조화 데이터 발행 전 점검해야 할 8가지 체크리스트 이미지 — JSON-LD 형식 사용부터 필수 속성, 가짜 평점 금지까지 발행 전 마지막 점검 목록.

JSON-LD 형식을 사용했는가. 특별한 이유가 없다면 Microdata·RDFa 대신 JSON-LD로 통일한다.
화면에 보이는 내용과 정확히 일치하는가. 코드에만 있는 정보가 없는지 다시 확인한다.
타입별 필수 속성을 빠짐없이 채웠는가.
가짜 평점·리뷰가 없는가. 실제 데이터만 반영한다.
Rich Results Test에서 오류 없이 인식되는가.
sameAs로 공식 채널을 연결했는가.
페이지마다 고유한 타입과 값을 썼는가.
FAQPage에 새로 시간을 쏟기보다, 다른 우선순위 타입부터 챙겼는가.

이 여덟 가지를 습관처럼 확인하면, 특별한 개발 지식이 없어도 구조화 데이터의 기본은 안정적으로 관리할 수 있다.

자주 묻는 질문

JSON-LD를 넣으면 정말 순위가 오르나요?

직접적으로 순위를 올리지는 않는다. 구글은 구조화 데이터를 랭킹 요소로 쓰지 않는다고 공식적으로 밝히고 있다.

다만 리치 결과로 노출되면 검색 결과 화면에서 더 눈에 띄어 클릭률이 오르고, 클릭률이 오르면 간접적으로 사이트 평가에 긍정적인 영향을 줄 수 있다. "순위를 위한 지름길"이 아니라 "클릭을 부르는 장치"로 이해하는 것이 정확하다.

간혹 "구조화 데이터를 넣었더니 순위가 올랐다"는 사례가 공유되기도 하는데, 이는 대개 구조화 데이터 하나만의 효과가 아니라 그 작업을 계기로 페이지 정보 전체를 정리하고 오류를 고친 결과인 경우가 많다. 원인과 결과를 정확히 구분해서 이해하는 것이 실무에서 헛된 기대를 줄이는 방법이다.

FAQPage 마크업을 지워야 하나요?

당장 지울 필요는 없다. 구글은 쓰지 않는 구조화 데이터가 있어도 검색에 문제를 일으키지 않는다고 안내한다.

다만 2026년 5월부터 검색 리치 결과 노출은 없으므로, 새로 시간을 들여 정교하게 작성할 실익은 크지 않다. 기존에 있는 마크업은 그대로 두고, 앞으로의 우선순위는 Product·LocalBusiness·Article처럼 여전히 리치 결과가 유효한 타입에 두는 것이 합리적이다.

구조화 데이터는 개발자만 넣을 수 있나요?

꼭 그렇지는 않다. 워드프레스 같은 CMS를 쓴다면 SEO 플러그인이 상품·글 정보를 기반으로 JSON-LD를 자동 생성해 주는 경우가 많다. 코드를 직접 짜지 않아도 되는 경우가 대부분이다.

다만 직접 만든 홈페이지나 맞춤 개발된 사이트라면, 어떤 값이 정확히 들어가야 하는지 아는 담당자가 개발자에게 요청하는 방식으로 진행하는 것이 안전하다. 원리를 이해하고 있으면 결과물의 정확성을 점검할 수 있다.

구조화 데이터를 넣었는데 리치 결과가 안 뜹니다. 왜 그런가요?

여러 원인이 있을 수 있다. 먼저 Rich Results Test로 문법 오류나 필수 속성 누락이 없는지 확인한다. 문법에 문제가 없어도, 구글이 그 페이지를 아직 다시 크롤링(재방문)하지 않았을 수 있다. 마크업을 넣은 뒤 실제 검색 결과에 반영되기까지 며칠에서 몇 주가 걸리는 것이 일반적이다.

또한 구글은 마크업이 정확해도 리치 결과 노출 여부를 최종적으로 자체 판단한다. 자격을 갖췄다고 해서 100% 노출이 보장되지는 않는다는 점도 알아 두면 좋다.

스키마 마크업이 없으면 검색에서 아예 안 뜨나요?

그렇지 않다. 구조화 데이터가 없어도 페이지는 정상적으로 크롤링되고 색인(구글 검색 목록에 등록)될 수 있다. 구조화 데이터는 "검색에 뜨느냐 마느냐"가 아니라 "어떻게 더 풍부하게 보이느냐"에 관여하는 요소다.

다만 정보를 명확히 구조화해 두면 검색엔진과 AI가 페이지 성격을 더 빨리, 더 정확히 이해하는 데는 분명히 도움이 된다.

AI 검색(챗지피티, 퍼플렉시티 등)에도 구조화 데이터가 효과가 있나요?

간접적으로 도움이 된다. AI 검색 엔진은 페이지의 텍스트와 구조를 함께 읽어 답변을 구성하는데, 구조화 데이터가 잘 정리되어 있으면 "이 페이지가 무엇을 다루는지"를 더 빠르고 정확하게 파악할 수 있다.

다만 구글 검색의 FAQ 리치 결과처럼 "이 마크업이 있으면 AI가 반드시 인용한다"는 공식 보장은 없다. 구조화 데이터와 함께, 질문형 소제목 아래 직접적인 답변을 쓰는 콘텐츠 구조 자체가 AI 인용 가능성을 높이는 더 근본적인 방법이다.

이미 운영 중인 사이트에 나중에 추가해도 효과가 있나요?

당연히 효과가 있다. 구조화 데이터는 신규 사이트에만 적용되는 것이 아니라, 기존 페이지에 언제든 추가하거나 수정할 수 있다. 오히려 이미 어느 정도 검색에 노출되고 있는 페이지라면, 구조화 데이터를 새로 추가했을 때 리치 결과 효과를 비교적 빠르게 체감할 수 있다.

추가한 뒤에는 구글이 해당 페이지를 다시 크롤링할 때까지 며칠에서 몇 주 정도 기다려야 하며, 급하다면 서치 콘솔의 URL 검사 도구로 재색인을 요청할 수 있다.

구조화 데이터에 오류가 있으면 벌점을 받나요?

단순 오류만으로는 벌점을 받지 않는다. 필수 속성이 빠지거나 문법이 틀린 정도라면, 그 항목이 리치 결과로 노출되지 않을 뿐 페이지 자체에 불이익은 없다.

다만 의도적으로 사람을 속이는 마크업(실제로 없는 리뷰·평점을 꾸며내는 것, 화면에 없는 내용을 숨겨서 넣는 것)은 이야기가 다르다. 이런 경우는 구글의 스팸 정책 위반으로 간주되어, 리치 결과 자격이 박탈되거나 심한 경우 수동 조치(사람이 직접 검토해 페널티를 부과하는 것)로 이어질 수 있다. 실수는 괜찮지만, 의도적인 조작은 반드시 피해야 한다.

네이버 검색에도 구조화 데이터가 통하나요?

부분적으로 통한다. 네이버도 스키마.org 기반 구조화 데이터를 일부 인식하지만, 구글만큼 다양한 리치 결과를 지원하지는 않는다. 네이버는 자체 서비스(블로그, 플레이스, 쇼핑 등)의 노출 방식이 별도로 있어, 네이버 노출까지 신경 쓴다면 네이버 서치어드바이저에 별도로 사이트를 등록해 관리하는 것이 좋다.

그래도 "정확한 정보를 정확한 형식으로 전달한다"는 원칙은 어느 검색엔진에서나 통한다.

한 페이지에 여러 스키마 타입을 함께 넣어도 되나요?

되며, 오히려 권장되는 경우가 많다. 예를 들어 블로그 글 페이지라면 Article과 BreadcrumbList를, 매장 상세 페이지라면 LocalBusiness와 Review를 함께 넣는 식이다. 각각의 스크립트가 서로 다른 정보를 설명하는 독립된 코드이기 때문에 충돌이 나지 않는다.

다만 앞서 흔한 실수에서 다뤘듯, 페이지 내용과 실제로 관련 있는 타입만 넣어야 한다. 관련 없는 타입을 이것저것 끼워 넣는 것은 도움이 되지 않는다.

구조화 데이터를 넣는 데 비용이 드나요?

코드 자체는 무료다. JSON-LD 문법도, 구글의 Rich Results Test 검증 도구도, 서치 콘솔도 모두 무료로 쓸 수 있다. 비용이 든다면 그건 코드 자체가 아니라 그 코드를 정확히 설계하고 관리하는 인력의 시간이다.

간단한 페이지 몇 개라면 직접 해도 충분하지만, 여러 페이지 타입을 아우르는 체계적인 설계는 시간이 꽤 든다. 이 시간을 아끼려고 제작사에 맡기는 비용을 지불하는 것이지, 구조화 데이터 자체에 별도의 사용료가 있는 것은 아니다.

스키마.org 표준이 자주 바뀌나요?

어휘 자체는 비교적 안정적이지만, 구글이 어떤 타입을 리치 결과로 채택하는지는 종종 바뀐다. 앞서 다룬 FAQ·HowTo 사례처럼, 스키마.org에 타입이 존재해도 구글이 검색 결과에서 활용하는 방식은 시기에 따라 달라질 수 있다.

그래서 구조화 데이터는 "한 번 세팅하고 잊어버리는 것"이 아니라, 구글 서치 센트럴 블로그나 서치 콘솔 공지를 가끔 확인하며 큰 변화가 있을 때 우선순위를 조정하는 태도가 필요하다. 다만 이런 변화를 일반 사업자가 일일이 추적하기는 현실적으로 어려우므로, 검색 동향을 지속적으로 살피는 파트너와 함께 관리하는 것도 좋은 방법이다.

구글 태그 매니저로 JSON-LD를 넣어도 되나요?

가능은 하지만 권장하지는 않는다. 구글 태그 매니저(GTM)는 자바스크립트로 태그를 나중에 삽입하는 도구라, 구조화 데이터도 기술적으로는 넣을 수 있다. 하지만 GTM으로 삽입한 코드는 페이지가 처음 열릴 때 바로 보이지 않고 약간의 지연 후에 나타나는 경우가 있어, 구글이 이를 제대로 못 읽을 위험이 있다.

가능하다면 서버가 페이지를 만들 때부터 HTML 안에 JSON-LD를 포함시키는 방식이 가장 안전하다. 부득이하게 GTM을 써야 한다면, 반드시 Rich Results Test로 정상 인식되는지 확인해야 한다.

마무리: 설명서를 붙이는 일부터 시작하자

구조화 데이터는 화려한 디자인 작업이 아니다. 이미 있는 정보에 정확한 이름표를 붙이는 작업이고, 그 대가로 검색 결과에서 더 눈에 띄고 AI에게 더 정확히 이해받는다.

오늘 배운 핵심을 정리하면 이렇다.

JSON-LD는 구글이 추천하는 구조화 데이터 형식이고, 스키마.org 어휘를 코드로 담는 그릇이다.
구조화 데이터는 순위를 직접 올리지 않지만, 클릭을 부르는 리치 결과의 기반이 된다.
2026년 5월부터 FAQ 리치 결과는 검색에서 사라졌다 — 우선순위를 Product·LocalBusiness·Article 같은 여전히 유효한 타입으로 옮겨야 한다.
마크업은 항상 화면에 보이는 내용과 정확히 일치해야 하며, 가짜 리뷰·평점은 금물이다.
넣은 뒤에는 반드시 Rich Results Test와 서치 콘솔로 검증한다.

무인도에 예쁜 호텔을 지어도 손님이 존재를 모르면 끝이라는 말처럼, 아무리 좋은 콘텐츠를 만들어도 검색엔진과 AI가 그 내용을 정확히 못 읽으면 절반의 노력만 전달된다. 구조화 데이터는 그 나머지 절반을 채우는 작업이다.

당장 무엇부터 하면 좋을지 막막하다면, 오늘 아래 세 단계만 따라 해 보자.

가장 중요한 페이지 하나(홈 또는 대표 서비스 페이지)를 고른다. 모든 페이지를 한 번에 손보려 하지 말고, 손님이 가장 많이 들어오는 페이지부터 시작한다.
그 페이지의 정체성에 맞는 타입 하나를 이 글의 예시에서 골라 적용한다. LocalBusiness, Organization, Product 중 가장 가까운 것을 고르면 된다.
Rich Results Test로 오류 없이 인식되는지 확인한다. 이 세 단계만으로도 사이트의 검색 노출 방식이 눈에 띄게 달라진다.

구조화 데이터는 한 번에 완벽하게 끝내는 작업이 아니라, 페이지를 하나씩 정확하게 채워 나가는 과정이라는 점을 기억하면 부담 없이 시작할 수 있다.

검색이 단순한 링크 목록에서 AI가 요약해 주는 답변으로 빠르게 옮겨가는 지금, 구조화 데이터의 역할은 사라지기는커녕 오히려 넓어지고 있다. 구글 검색의 리치 결과라는 하나의 창구가 좁아진 자리에, AI 검색이라는 새로운 창구가 열리고 있기 때문이다. 결국 중요한 것은 특정 리치 결과 하나에 일희일비하는 것이 아니라, 내 사이트의 정보를 언제나 정확하고 명확하게 정리해 두는 기본기다. 그 기본기를 갖춘 사이트는 검색 방식이 앞으로 또 어떻게 바뀌더라도 흔들리지 않는다.

이루웹은 SEO를 처음부터 설계에 넣어 홈페이지를 만드는 웹 에이전시입니다. JSON-LD 구조화 데이터 세팅부터 사이트맵, 검색 등록, 콘텐츠 구조까지 검색과 AI에 모두 강한 사이트를 함께 만들어 드리고 있습니다. 직접 구조화 데이터를 넣기 어렵거나 지금 내 사이트에 어떤 스키마가 빠져 있는지 궁금하시다면 SEO 홈페이지 제작 서비스와 전체 서비스를 살펴보시고, 무료 상담으로 현재 사이트 상태를 진단받아 보시길 권해 드립니다. 정확한 설명서를 붙이는 일부터, 검색과 AI 모두에 잘 보이는 사이트를 만드는 일까지 함께하겠습니다.

검색되는 사이트가 필요하신가요?

이 글의 원칙을 그대로 적용해 사이트를 만듭니다. 상담은 무료입니다.

무료 상담 신청