구조화 데이터로 리치 결과 노출 가능성 높이기 (Schema.org/JSON-LD)

구조화 데이터란 무엇인가요?

구조화 데이터는 페이지의 내용이 '무엇에 관한 것인지'를 검색 엔진이 기계적으로 이해할 수 있도록, 정해진 어휘에 맞춰 정리해 둔 추가 정보입니다. 사람이 보는 본문은 그대로 두고, 그 본문이 '레시피인지, 기사인지, 자주 묻는 질문인지'를 별도의 코드로 명시해 주는 것이죠. 검색 엔진은 이 정보를 단서로 삼아 페이지를 더 정확하게 이해합니다.

여기서 쓰이는 공통 어휘 표준이 schema.org입니다. 구글, 마이크로소프트, 야후 등이 함께 만든 사전 같은 것으로, Article, Product, FAQPage처럼 수백 가지 타입과 속성이 정의되어 있습니다. 우리가 할 일은 내 페이지에 맞는 타입을 골라 그 규칙대로 정보를 채워 넣는 것입니다.

리치 결과(Rich Results)와 어떻게 연결되나요?

리치 결과는 일반적인 파란 제목 + 회색 설명으로만 이뤄진 검색 결과에, 별점·FAQ 펼침·빵부스러기 경로·이미지 등 시각적 요소가 추가로 붙은 형태를 말합니다. 검색 결과에서 더 넓은 자리를 차지하고 눈에 띄기 때문에, 클릭으로 이어질 가능성이 높아지는 경우가 있습니다.

이 리치 결과가 표시되려면 구글이 페이지 내용을 충분히 이해해야 하는데, 구조화 데이터가 바로 그 이해를 돕는 입력값입니다. 즉 구조화 데이터는 리치 결과의 '전제 조건'에 가깝습니다. 다만 한 가지는 분명히 짚고 가야 합니다.

JSON-LD, 마이크로데이터, RDFa 중 무엇을 쓸까?

구조화 데이터를 페이지에 심는 방법은 세 가지가 있습니다. 마이크로데이터와 RDFa는 HTML 태그 속성 안에 정보를 끼워 넣는 방식이고, JSON-LD는 본문과 분리된 스크립트 블록에 데이터를 따로 적는 방식입니다.

블로그·콘텐츠 사이트에 유용한 타입 4가지

schema.org에는 수많은 타입이 있지만, 블로그나 일반 콘텐츠 사이트라면 아래 네 가지만 제대로 다뤄도 충분한 경우가 많습니다. 내가 가진 페이지의 성격에 맞는 것만 골라 적용하면 됩니다.

1. Article / BlogPosting — 기사·블로그 글

블로그 글이나 뉴스 기사에 쓰는 가장 기본적인 타입입니다. 제목(headline), 작성일(datePublished), 수정일(dateModified), 작성자(author), 발행 주체(publisher), 대표 이미지(image) 등을 명시합니다. 이 정보가 정확하면 구글이 글의 출처와 갱신 시점을 더 잘 파악하며, 일부 검색 결과에는 발행일이나 작성자 정보가 함께 표시되기도 합니다.

2. FAQPage — 자주 묻는 질문

한 페이지에 질문과 답변이 정리되어 있을 때 사용하는 타입입니다. 마크업이 인정되면 검색 결과 아래에 질문들이 펼침 형태로 함께 표시될 수 있습니다. 다만 구글은 2023년부터 FAQ 리치 결과를 정부·보건 등 일부 권위 있는 사이트로 사실상 제한한 바 있습니다. 정책이 시기에 따라 바뀌어 왔으므로, 일반 블로그라면 노출은 어디까지나 가능성으로만 전제하고, FAQ 마크업 자체는 콘텐츠 구조를 정확히 전달하는 용도로 접근하는 편이 안전합니다.

3. BreadcrumbList — 빵부스러기 경로

사용자가 사이트 어느 위치에 있는지 보여주는 경로(예: 홈 > 웹사이트 SEO > 구조화 데이터)를 마크업하는 타입입니다. 인정되면 검색 결과의 URL 자리에 이 경로가 표시되어, 페이지의 맥락을 한눈에 전달합니다. 카테고리 구조가 명확한 블로그라면 비교적 안정적으로 표시되는 편입니다.

4. HowTo — 단계별 안내

'~하는 법'처럼 순서가 있는 작업을 단계별로 설명하는 페이지에 쓰는 타입입니다. 각 단계(step)와 필요하다면 도구·소요 시간 등을 명시합니다. 다만 구글은 2023년 이후 HowTo 리치 결과 표시를 사실상 중단한 상태이므로, 검색 결과 노출을 기대하기보다 '본문 구조를 정확히 전달한다'는 관점으로 접근하는 편이 현실적입니다.

Article 구조화 데이터 작성 예시 (JSON-LD)

아래는 블로그 글에 넣는 Article(또는 BlogPosting) JSON-LD에 들어가는 핵심 속성들입니다. 페이지 head 안에 application/ld+json 타입의 script 태그로 넣고, 값은 실제 페이지 정보와 정확히 일치시켜야 합니다.

• headline: 글 제목입니다. 본문 h1/title과 의미가 일치해야 하며, 너무 길지 않게 작성합니다.
• datePublished / dateModified: 최초 발행일과 마지막 수정일입니다. 수정일을 거짓으로 갱신하지 마세요. 실제 변경이 없으면 오히려 신뢰를 떨어뜨립니다.
• author: 작성자 정보입니다. Person 또는 Organization 타입으로 이름과 가능하면 프로필 URL을 함께 넣습니다.
• image: 대표 이미지 URL입니다. 본문에 실제로 존재하는 이미지를, 가능하면 충분히 큰 해상도로 지정합니다.
• publisher: 발행 주체(보통 사이트/브랜드)와 로고 정보입니다.

별점(Review/AggregateRating)을 쓸 때 주의점

검색 결과의 노란 별점은 클릭률을 높이는 대표적인 리치 결과라 욕심이 나기 쉽습니다. 하지만 이 마크업은 자가 평가에는 쓸 수 없습니다. 즉 '우리 서비스 5점'처럼 사이트 운영자가 자기 자신을 평가한 별점은 인정되지 않으며, 정책 위반에 해당합니다.

• 적용 가능: 제3자(고객)가 남긴 실제 리뷰가 페이지에 표시되는 경우.
• 적용 불가: 운영자가 자사 상품·서비스에 스스로 매긴 별점.
• 필수 조건: 별점 마크업은 Product, Recipe 등 별점이 의미 있는 대상 타입과 함께, 페이지에 보이는 리뷰 내용을 기반으로만 사용합니다.

적용 후 반드시 검증하기

구조화 데이터는 따옴표 하나, 속성명 오타 하나로도 인식되지 않습니다. 그래서 적용 후 검증은 선택이 아니라 필수입니다. 무료로 쓸 수 있는 검증 도구를 활용하세요.

1. 1리치 결과 테스트에 페이지 URL 또는 코드를 입력해, 감지된 항목과 경고·오류를 확인합니다.
2. 2오류(error)는 반드시 수정합니다. 경고(warning)는 권장 항목 누락이므로 가능하면 채웁니다.
3. 3수정 후 다시 테스트해 통과를 확인합니다.
4. 4배포 뒤에는 Search Console의 개선 사항 리포트에서 실제 색인된 페이지 기준으로 문제가 없는지 주기적으로 모니터링합니다.

흔한 실수와 정책 위반

구조화 데이터 이전에, 색인이 먼저입니다

여기서 자주 놓치는 순서가 있습니다. 구조화 데이터는 '이미 색인된 페이지'가 검색 결과에서 더 풍부하게 보이도록 돕는 장치입니다. 페이지가 애초에 구글에 색인조차 되어 있지 않다면, 아무리 정교한 마크업을 넣어도 검색 결과에 나타날 수 없습니다.

그래서 구조화 데이터를 손보기 전에, 내 글들이 구글에 제대로 색인되어 있는지부터 확인하는 것이 합리적입니다. 구글 검색창에 site:내도메인 으로 검색하면 색인된 페이지를 대략 가늠할 수 있고, 더 정확한 데이터는 Search Console의 '페이지' 리포트에서 볼 수 있습니다. 누락된 글이 많다면 색인 요청을 먼저 정리하는 편이 우선순위가 높습니다.

이런 색인 현황 파악과 누락 글 처리를 한 번에 정리하고 싶다면 인덱스키트의 PDF 진단 보고서를 활용할 수 있습니다. 블로그·웹사이트 주소를 넣으면 어떤 글이 색인되고 어떤 글이 빠져 있는지 보여주고, 색인 현황 페이지에서 미색인 글에 Google Indexing API로 색인 요청을 보낼 수 있습니다. 다만 색인은 검색엔진에 대한 '요청'이며, 최종 색인 여부와 시점은 구글 정책과 알고리즘에 따라 달라질 수 있습니다.