구조화된 데이터 테스트 방법｜리치 결과 테스트와 스키마 마크업 유효성 검사 차이
구조화된 데이터 테스트 방법 - 리치 결과 테스트와 스키마 마크업 유효성 검사 차이
구조화된 데이터는 검색엔진과 AI가 내 글의 제목, 작성자, 날짜, FAQ, 상품, 리뷰 같은 정보를 더 정확하게 이해하도록 돕는 HTML 마크업입니다. 티스토리 블로그에서는 보통 JSON-LD 형식으로 넣으며, 적용 후에는 Google 리치 결과 테스트와 Schema Markup Validator를 함께 확인하는 것이 좋습니다.
블로그 글을 열심히 작성했는데 구글 검색 결과에서는 평범한 제목과 설명만 노출되는 경우가 많습니다. 반대로 어떤 글은 검색 결과에 별점, FAQ, 이미지, 상품 가격, 작성일, 탐색경로 같은 정보가 함께 표시되기도 하는데요. 이런 차이를 만드는 대표적인 요소 중 하나가 바로 구조화된 데이터, 흔히 말하는 스키마 마크업입니다.
특히 최근에는 단순한 검색엔진 최적화 SEO를 넘어서, 구글 AI 오버뷰나 ChatGPT, Gemini, Copilot 같은 생성형 AI 검색 환경까지 고려해야 합니다. 이때 글의 핵심 정보가 HTML 안에서 구조적으로 정리되어 있으면 검색엔진과 AI가 콘텐츠를 이해하기 훨씬 쉬워지고, 글의 주제와 신뢰도를 판단하는 데도 도움이 됩니다.
구조화된 데이터란?
구조화된 데이터는 웹페이지 안에 있는 정보를 검색엔진이 해석하기 쉬운 형식으로 정리해 넣는 마크업입니다. 사람은 글을 읽으면서 “이 부분은 제목이고, 이 부분은 작성자이고, 이 부분은 질문과 답변이구나”라고 자연스럽게 이해하지만, 검색엔진은 HTML 코드와 문맥을 함께 분석해야 합니다.
예를 들어 레시피 글이라면 음식 이름, 조리 시간, 재료, 칼로리, 평점 같은 정보가 있을 수 있고, 제품 리뷰 글이라면 제품명, 가격, 평점, 장단점, 리뷰 작성자 정보가 있을 수 있습니다. 이런 정보를 단순 문장으로만 적어두는 것이 아니라 Recipe, Product, Review, FAQPage, BlogPosting, BreadcrumbList 같은 스키마 타입으로 정리해 주는 것이 구조화된 데이터입니다.
구글에서는 JSON-LD, Microdata, RDFa 형식을 지원하지만, 일반 블로그나 티스토리 기준에서는 JSON-LD 방식이 가장 관리하기 쉽습니다. HTML 본문이나 스킨에 <script type="application/ld+json"> 형태로 삽입하면 되며, 본문 디자인에는 영향을 주지 않고 검색엔진에게만 의미 정보를 전달할 수 있습니다.
구조화된 데이터가 SEO, AEO, GEO에 중요한 이유
기존 SEO에서는 제목, 본문 키워드, 내부링크, 이미지 대체 텍스트, 메타디스크립션이 중요했습니다. 이 요소들은 여전히 중요하지만, 이제는 검색엔진이 단순히 키워드만 보는 것이 아니라 이 글이 어떤 주제의 글인지, 누가 작성했는지, 어떤 질문에 답하는지, 최신 정보인지, 실제 본문과 마크업이 일치하는지까지 함께 판단합니다.
1. 검색엔진이 글의 성격을 더 정확하게 이해합니다
예를 들어 “티스토리 구조화 데이터 적용 방법”이라는 글이 있다고 가정해 보겠습니다. 본문만 보면 검색엔진이 어느 정도 내용을 이해할 수 있지만, BlogPosting 스키마와 FAQPage 스키마를 함께 넣으면 이 글이 블로그 포스팅이고, 하단에는 실제 질문과 답변이 포함되어 있다는 것을 더 명확하게 전달할 수 있습니다.
2. 리치 검색 결과 노출 가능성이 생깁니다
구조화된 데이터를 적용한다고 해서 무조건 구글 검색 결과에 리치 스니펫이 뜨는 것은 아닙니다. 하지만 구글이 지원하는 구조화 데이터 타입을 올바르게 넣으면 FAQ, 상품, 리뷰, 이벤트, 레시피, 동영상, 탐색경로 같은 리치 결과 후보가 될 수 있습니다. 즉, 구조화 데이터는 검색 결과를 더 눈에 띄게 만들 수 있는 기본 조건에 가깝습니다.
3. AI 검색에서 문맥을 파악하기 쉬워집니다
AEO와 GEO 관점에서는 구조화된 데이터가 더 중요해지고 있습니다. AEO는 사용자의 질문에 바로 답변될 수 있도록 콘텐츠를 정리하는 방식이고, GEO는 생성형 AI 검색에서 내 콘텐츠가 더 잘 이해되고 인용될 수 있도록 최적화하는 방향입니다.
AI는 글 전체를 읽고 요약하지만, 글 안의 정보가 제목, 질문, 답변, 작성자, 수정일, 주제, 관련 엔티티로 깔끔하게 구분되어 있으면 콘텐츠를 더 안정적으로 해석할 수 있습니다. 그래서 요즘 블로그 글은 단순히 키워드를 많이 넣는 방식보다 질문에 바로 답하고, 근거를 설명하고, 구조화 데이터로 의미를 정리하는 방식이 더 유리합니다.
리치 결과 테스트와 스키마 마크업 유효성 검사 차이
구조화된 데이터를 테스트할 때 가장 많이 사용하는 도구는 두 가지입니다. 하나는 Google 리치 결과 테스트이고, 다른 하나는 Schema Markup Validator입니다. 두 도구는 비슷해 보이지만 목적이 다릅니다.
| 구분 | Google 리치 결과 테스트 | Schema Markup Validator |
| 검사 목적 | 구글 검색에서 리치 결과로 표시될 수 있는지 확인 | Schema.org 문법과 구조 자체가 올바른지 확인 |
| 검사 범위 | 구글이 지원하는 리치 결과 중심 | Schema.org 기반 마크업 전체 |
| 사용 시점 | 구글 검색 노출 가능성 확인 | 스키마 코드 문법 검증 |
| 결과 해석 | 유효한 항목, 경고, 오류, 미리보기 확인 | 스키마 타입, 속성, 누락값 확인 |
| 주의사항 | 구글이 지원하지 않는 스키마는 표시되지 않을 수 있음 | 문법이 맞아도 구글 리치 결과 대상은 아닐 수 있음 |
쉽게 말해 Schema Markup Validator는 문법 검사이고, Google 리치 결과 테스트는 구글 검색 노출 가능성 검사라고 보면 됩니다. 그래서 Schema Markup Validator에서는 정상으로 나오는데 리치 결과 테스트에서는 별다른 항목이 안 보일 수 있고, 반대로 리치 결과 테스트에서 경고가 나와도 치명적인 오류가 아니라면 검색 노출 자체에는 문제가 없는 경우도 있습니다.
URL을 찾을 수 없습니다 오류가 뜨는 이유
구조화된 데이터 테스트를 하다 보면 아래와 같은 오류가 뜨는 경우가 있습니다.
URL을 찾을 수 없습니다. 도메인 이름이 올바르고 서버가 200 상태 코드로 응답하는지 확인하세요.
이 오류는 스키마 코드 자체가 틀렸다는 뜻이 아닙니다. 테스트 도구가 입력한 URL에 정상적으로 접근하지 못했다는 의미입니다. 즉, 구조화 데이터 문제가 아니라 URL 접근 문제, 서버 응답 문제, 공개 상태 문제부터 먼저 확인해야 합니다.
1. 티스토리 비공개 글 또는 미리보기 주소를 넣은 경우
티스토리 글쓰기 화면의 미리보기 URL이나 비공개 글 주소는 외부 테스트 도구가 접근하지 못할 수 있습니다. 리치 결과 테스트는 실제 구글봇이 접근 가능한 공개 URL을 기준으로 검사하기 때문에, 반드시 글을 발행한 뒤 공개 주소로 테스트해야 합니다.
2. 도메인 주소를 잘못 입력한 경우
가장 단순하지만 의외로 많이 발생하는 원인입니다. https:// 누락, 슬래시 오류, 한글 URL 복사 오류, 모바일 주소와 PC 주소 혼동, http와 https 혼동 등이 있으면 테스트 도구가 페이지를 찾지 못할 수 있습니다.
3. 서버가 200 상태 코드로 응답하지 않는 경우
정상 페이지는 보통 HTTP 200 상태 코드로 응답해야 합니다. 만약 301 또는 302 리디렉션이 반복되거나, 403 접근 차단, 404 페이지 없음, 500 서버 오류가 발생하면 리치 결과 테스트에서 URL을 가져오지 못할 수 있습니다.
4. robots.txt 또는 noindex로 차단된 경우
페이지가 검색엔진 접근을 막고 있으면 구조화 데이터가 있어도 구글이 확인하기 어렵습니다. 티스토리에서는 일반적으로 큰 문제가 없지만, 스킨 수정이나 메타태그 삽입 과정에서 noindex가 들어갔거나 robots.txt에서 차단된 경우라면 반드시 수정해야 합니다.
5. 방화벽, 보안 플러그인, CDN이 테스트 도구를 막는 경우
워드프레스나 별도 호스팅 사이트에서는 Cloudflare, 보안 플러그인, 서버 방화벽이 Google 테스트 도구의 접근을 막는 경우가 있습니다. 티스토리는 이런 경우가 많지는 않지만, 개인 도메인을 연결한 경우 DNS 설정이나 SSL 인증서 문제도 함께 확인해야 합니다.
티스토리 블로그에 적용하기 좋은 스키마 타입
티스토리 블로그에 무조건 많은 스키마를 넣는다고 좋은 것은 아닙니다. 스키마는 실제 본문 내용과 일치해야 하며, 본문에 없는 내용을 구조화 데이터에만 넣으면 오히려 신뢰도가 떨어질 수 있습니다.
| 스키마 타입 | 적용하기 좋은 글 | 주의사항 |
| BlogPosting | 일반 블로그 포스팅 | 제목, 작성자, 발행일, 수정일 정보가 실제 글과 맞아야 함 |
| Article | 정보성 글, 뉴스형 글, 가이드 글 | 과도하게 뉴스 기사처럼 꾸미지 않는 것이 좋음 |
| FAQPage | 질문과 답변이 실제 본문에 있는 글 | 본문에 없는 FAQ를 JSON-LD에만 넣으면 안 됨 |
| HowTo | 단계별 설정 방법, 설치 방법, 오류 해결 글 | 순서가 명확한 글에만 사용하는 것이 좋음 |
| BreadcrumbList | 카테고리 구조가 명확한 글 | 실제 사이트 탐색 구조와 맞아야 함 |
| Product | 제품 리뷰, 가격, 재고, 상품 정보 글 | 실제 제품명, 가격, 리뷰 정보가 본문에 있어야 함 |
| Review | 직접 사용 후기, 평가 글 | 허위 별점이나 본문에 없는 평점 삽입 금지 |
잡가이버처럼 IT 오류 해결, 윈도우 설정, 프로그램 설치, 제품 리뷰, 자전거 장비 후기, 생활정보 글이 섞여 있는 블로그라면 기본은 BlogPosting + BreadcrumbList이고, 글 성격에 따라 FAQPage, HowTo, Product, Review를 추가하는 방식이 가장 안정적입니다.
구조화된 데이터 테스트 순서
구조화된 데이터를 적용했다면 바로 검색 결과에 반영되는 것이 아니라 먼저 테스트 과정을 거쳐야 합니다. 특히 티스토리 블로그는 스킨 구조, 본문 HTML, 광고 스크립트, 이미지 주소가 함께 섞이기 때문에 아래 순서대로 확인하는 것이 좋습니다.
1. 글을 공개 발행합니다
비공개 글이나 미리보기 글은 테스트 도구에서 정상 접근하지 못할 수 있습니다. 먼저 글을 공개 발행하고 실제 URL을 복사합니다.
2. Schema Markup Validator에서 문법을 확인합니다
먼저 Schema Markup Validator에서 JSON-LD 문법 오류가 없는지 확인합니다. 쉼표 누락, 따옴표 오류, 중괄호 누락, 잘못된 속성명 같은 기본 오류는 여기서 먼저 잡는 것이 좋습니다.
3. Google 리치 결과 테스트에서 구글 기준을 확인합니다
문법상 문제가 없다면 Google 리치 결과 테스트에서 해당 페이지가 구글 검색에서 리치 결과 후보가 될 수 있는지 확인합니다. 이때 유효한 항목이 감지되면 정상이고, 경고가 나오더라도 필수 오류가 아니라면 우선순위를 나눠서 수정하면 됩니다.
4. 구글 서치콘솔 URL 검사로 색인 상태를 확인합니다
리치 결과 테스트가 통과되었다고 해서 바로 검색 결과에 반영되는 것은 아닙니다. 구글 서치콘솔에서 URL 검사를 진행하고, 색인 생성 요청을 해두면 구글이 새 구조화 데이터를 다시 확인하는 데 도움이 됩니다.
5. 며칠 뒤 검색 결과 반영 여부를 확인합니다
구조화 데이터는 적용 즉시 검색 결과에 표시되지 않을 수 있습니다. 구글이 다시 크롤링하고, 품질 기준을 판단하고, 검색 결과에 반영하기까지 시간이 걸립니다. 따라서 테스트 도구에서 정상이라면 하루 이틀 만에 결론을 내리기보다 며칠 단위로 확인하는 것이 좋습니다.
티스토리 구조화 데이터 적용 시 주의할 점
티스토리에서는 플러그인처럼 자동으로 모든 스키마를 세밀하게 제어하기 어렵기 때문에, 본문 HTML 또는 스킨 HTML을 직접 수정하는 경우가 많습니다. 이때 가장 중요한 것은 본문에 보이는 내용과 구조화 데이터 내용이 일치해야 한다는 점입니다.
본문에 없는 FAQ를 넣지 마세요
FAQPage 스키마를 넣으려면 실제 본문에도 질문과 답변이 보여야 합니다. 검색엔진에게만 보이는 FAQ를 몰래 넣는 방식은 권장되지 않습니다. 그래서 글 하단에 FAQ 섹션을 먼저 만들고, 그 내용과 동일한 JSON-LD를 아래에 넣는 방식이 가장 안전합니다.
모든 글에 Product나 Review를 넣지 마세요
제품 리뷰 글이 아닌데 Product 스키마를 넣거나, 실제 평점이 없는 글에 Review 스키마를 넣는 것은 좋지 않습니다. 예를 들어 “윈도우11 프린터 오류 해결 방법” 글이라면 Product보다 HowTo나 FAQPage가 더 자연스럽습니다.
스키마를 너무 많이 중복 삽입하지 마세요
같은 페이지에 BlogPosting, Article, NewsArticle을 동시에 과하게 넣거나, 동일한 FAQPage를 여러 번 중복 삽입하면 검색엔진이 페이지 구조를 해석하기 어려워질 수 있습니다. 티스토리 글에서는 글 성격에 맞는 핵심 스키마만 깔끔하게 넣는 것이 좋습니다.
날짜와 작성자 정보는 실제 페이지와 맞춰야 합니다
datePublished, dateModified, author, publisher 정보는 실제 글 정보와 다르면 신뢰도가 떨어질 수 있습니다. 특히 오래된 글을 수정했다면 본문 안에도 수정 기준일을 자연스럽게 표시하고, 구조화 데이터의 dateModified도 함께 맞추는 것이 좋습니다.
FAQPage JSON-LD 예시
아래는 티스토리 글 하단에 FAQ를 작성한 뒤 함께 넣을 수 있는 JSON-LD 예시입니다. 실제 사용 시에는 질문과 답변을 본문 FAQ 내용과 동일하게 맞추는 것이 중요합니다.
<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "구조화된 데이터란 무엇인가요?", "acceptedAnswer": { "@type": "Answer", "text": "구조화된 데이터는 검색엔진과 AI가 웹페이지의 제목, 작성자, 날짜, 질문, 답변, 상품, 리뷰 같은 정보를 더 정확하게 이해할 수 있도록 HTML에 삽입하는 표준화된 데이터입니다." } }, { "@type": "Question", "name": "리치 결과 테스트와 Schema Markup Validator는 무엇이 다른가요?", "acceptedAnswer": { "@type": "Answer", "text": "리치 결과 테스트는 구글 검색에서 리치 결과로 표시될 수 있는지 확인하는 도구이고, Schema Markup Validator는 Schema.org 문법과 구조 자체가 올바른지 확인하는 도구입니다." } }, { "@type": "Question", "name": "URL을 찾을 수 없습니다 오류는 왜 발생하나요?", "acceptedAnswer": { "@type": "Answer", "text": "입력한 주소가 잘못되었거나, 글이 비공개 상태이거나, 서버가 200 상태 코드로 응답하지 않거나, robots.txt 또는 noindex로 접근이 차단된 경우 발생할 수 있습니다." } }, { "@type": "Question", "name": "티스토리 블로그에도 구조화된 데이터를 넣는 것이 좋나요?", "acceptedAnswer": { "@type": "Answer", "text": "네. 티스토리 블로그도 정보성 글, 오류 해결 글, 제품 리뷰 글, FAQ 글에 맞는 구조화 데이터를 넣으면 검색엔진이 글의 성격을 이해하는 데 도움이 됩니다." } } ] } </script> 구조화된 데이터 FAQ
구조화된 데이터를 넣으면 검색 순위가 바로 올라가나요?
구조화된 데이터 자체가 검색 순위를 바로 올려주는 버튼은 아닙니다. 다만 검색엔진이 페이지 내용을 더 정확하게 이해하도록 돕고, 리치 결과 노출 가능성을 만들기 때문에 클릭률과 검색 노출 품질을 개선하는 데 도움이 될 수 있습니다.
Schema Markup Validator에서 정상인데 리치 결과 테스트에서는 안 나옵니다. 문제인가요?
반드시 문제라고 보기는 어렵습니다. Schema Markup Validator는 Schema.org 문법을 검사하는 도구이고, 리치 결과 테스트는 구글이 지원하는 리치 결과 기준을 확인하는 도구입니다. 즉, 문법상 정상인 스키마라도 구글 리치 결과 대상이 아니면 리치 결과 테스트에서 별도 항목으로 표시되지 않을 수 있습니다.
티스토리 글에는 어떤 스키마를 가장 먼저 넣는 것이 좋나요?
일반 포스팅이라면 BlogPosting 또는 Article이 기본이고, 질문과 답변이 있는 글은 FAQPage, 단계별 해결 방법이 있는 글은 HowTo, 제품 사용 후기는 Product 또는 Review를 검토하면 됩니다. 단, 본문 내용과 스키마 내용은 반드시 일치해야 합니다.
리치 결과 테스트에서 URL을 찾을 수 없다고 나옵니다. 스키마 오류인가요?
대부분은 스키마 오류가 아니라 URL 접근 문제입니다. 공개 발행된 주소인지, 도메인이 정확한지, 서버가 200 상태 코드로 응답하는지, robots.txt나 noindex로 차단되어 있지 않은지 먼저 확인해야 합니다.
마무리
구조화된 데이터는 단순히 검색 결과를 예쁘게 꾸미기 위한 코드가 아닙니다. 검색엔진과 AI가 내 글의 의미를 더 정확하게 이해하도록 돕는 일종의 설명서에 가깝습니다.
티스토리 블로그라면 모든 글에 복잡한 스키마를 넣기보다, 글의 성격에 맞게 BlogPosting, FAQPage, HowTo, BreadcrumbList 정도부터 차근차근 적용하는 것이 좋습니다. 그리고 적용 후에는 반드시 Schema Markup Validator로 문법을 확인하고, Google 리치 결과 테스트로 구글 검색 기준에서 문제가 없는지 함께 확인해야 합니다.
만약 리치 결과 테스트에서 “URL을 찾을 수 없습니다”라는 오류가 나온다면 스키마 코드부터 의심하지 말고, 먼저 공개 URL, 도메인 주소, 서버 응답 코드, robots.txt, noindex 여부부터 확인하는 것이 정확합니다. 구조화 데이터는 검색 노출의 보조 장치이지만, 제대로 적용하면 SEO뿐 아니라 AEO와 GEO 관점에서도 블로그 콘텐츠의 이해도와 신뢰도를 높이는 데 충분히 의미 있는 작업입니다.
[블로그 수익화/블로그 SEO] - llms.txt란? AI 검색 시대 블로그와 홈페이지 준비해야 할 GEO·AEO 최적화 파일
[블로그 수익화/블로그 SEO] - 구조화 데이터 스키마 JSON-LD 티스토리 SEO 리치스니펫 적용 방법
[블로그 수익화/블로그 SEO] - 워드프레스 구글 서치콘솔 'Comment' 객체가 'CreativeWork' 객체 내부에 중첩