구조화 데이터 스키마(JSON-LD) SEO 리치스니펫 검색엔진 노출

구조화 데이터 스키마(JSON-LD) 정리 티스토리 SEO 리치스니펫까지 한 번에

티스토리나 워드프레스 등 블로그를 생성하고 글을 열심히 써도 검색에서 제목이 애매하게 보이거나, 검색엔진이 글 성격을 제대로 못 잡는 듯한 증상을 겪는 분들이 많습니다. 저도 그랬고요.

우선 검색콘솔을 보면 “구조화 데이터 없음”, “필드 누락” 같은 경고가 쌓이는데, 이걸 제대로 정리해두면 검색엔진이 글을 해석하는 방식이 훨씬 깔끔해집니다.

구조화 데이터(Structured Data)는 검색엔진에게 페이지 내용을 설명하는 표준 라벨입니다.

우선 검색순위가 당장 확 뛰는 마법은 아니지만, 글의 성격을 정확히 전달해 색인 품질과 표현 방식을 안정적으로 만드는 데 도움이 됩니다. 특히 티스토리는 워드프레스처럼 SEO 플러그인이 기본으로 깔려 있지 않은 편이라, 원리만 알고 “딱 필요한 것만” 넣는 방식이 장기적으로 가장 안전합니다.

구조화 데이터가 무엇인지 쉽게 이해하기

사람은 제목, 문단, 이미지, 작성일을 보면 “아 블로그 글이네”라고 바로 이해합니다.

하지만 검색엔진은 HTML만 보고 “이게 글인지, 회사 소개인지, 제품 소개인지”를 기계적으로 판단합니다. 구조화 데이터는 그 판단을 도와주는 설명서입니다.

요즘 실무에서 가장 많이 쓰는 방식이 JSON-LD인데, 이유는 간단합니다. HTML 구조와 섞지 않고 script 태그 안에 독립적으로 넣을 수 있어서 실수도 줄고 관리도 편합니다.

schema.org와 @context가 하는 일

구조화 데이터는 거의 항상 schema.org 표준을 기반으로 작성합니다.

이때 @context는 “이 문서가 어떤 표준 규칙을 따르는지”를 선언하는 시작점입니다.

{
  "@context": "https://schema.org"
}

@context를 빼먹거나 오타가 나면, 내용이 맞아도 검색엔진이 해석을 제대로 못 하는 경우가 생깁니다. “맞는 것 같은데 계속 경고가 뜨는” 증상은 여기서 꽤 자주 시작합니다.

@type 선택이 스키마 품질을 좌우한다

@type은 “이 페이지가 무엇인지”를 결정하는 핵심입니다.

블로그 글이면 BlogPosting, 회사 소개면 Organization, 작성자 소개면 Person 같은 식으로 정합니다.

중요한 원칙은 하나입니다. 본문 내용과 @type은 반드시 일치해야 하며 검색엔진 노출 욕심으로 타입을 바꿔치기하면, 스키마가 무시되거나 경고가 늘어날 수 있습니다.

@type	어울리는 페이지	함께 쓰면 좋은 항목	자주 하는 실수
BlogPosting	티스토리 일반 포스팅, 후기, IT 해결 기록	headline, description, image, datePublished, author, mainEntityOfPage	상품·서비스 페이지에 억지 적용
NewsArticle	기사 성격의 뉴스형 글	publisher, datePublished, image	뉴스가 아닌데 남발
Person	작성자 소개, 프로필	name, image, sameAs, jobTitle	글마다 중복으로 과도하게 생성
Organization	브랜드/회사 소개, 사이트 소유자 정보	name, logo, url, sameAs, contactPoint	로고 URL을 상대경로로 넣음
FAQPage	질문과 답변이 핵심인 글	mainEntity(Question/Answer)	본문에 없는 Q&A를 넣음
HowTo	단계별 사용법, 설정 방법 글	step, tool, supply, totalTime	단계 설명이 본문과 불일치

구조화 데이터 작성 규칙에서 자주 터지는 오류

문서 내용과 스키마 내용이 다르면 신뢰가 무너진다

FAQ 스키마를 넣을 때 본문에는 없는 질문을 추가하거나, 리뷰가 아닌데 Review를 넣는 식이면 좋지 않습니다.

저는 스키마를 쓸 때 늘 본문에 적힌 내용만 그대로 구조화합니다. 이게 가장 안전합니다.

이미지 URL은 절대경로로

image에는 https://도메인/경로 형태의 절대경로를 권장합니다.

상대경로(/images/...)는 검색엔진이 제대로 못 읽는 증상을 만들 수 있습니다.

날짜는 ISO8601 형식으로

datePublished, dateModified는 2026-03-05T10:22:00+09:00 같은 ISO8601 형식이 기본입니다.

참고로 날짜 형식이 애매하면 필드 오류로 잡히기 쉽습니다.

JSON 문법 오류는 쉼표 하나로도 발생한다

마지막 항목 뒤에 쉼표가 하나 더 붙는 실수가 특히 많습니다. “문제 없어 보이는데 검증 도구에서 에러”라면 대부분 JSON 문법입니다.

티스토리에서 JSON-LD를 넣는 위치

티스토리는 보통 두 가지 방식으로 넣습니다.

• 글 본문 HTML 모드에 넣기 : 해당 글에만 스키마를 적용하고 싶을 때
• 스킨 편집에서 head 영역에 넣기 : 사이트 공통(Organization 등)을 적용하고 싶을 때

저는 글마다 다른 스키마(BlogPosting, FAQPage)는 글 본문에, 사이트 공통 정보(Organization, 로고, SNS)는 스킨 head에 분리하는 편입니다. 그래야 중복이 줄고 관리가 편합니다.

실전 예시 BlogPosting 기본 템플릿

아래 예시는 티스토리 글에 많이 쓰는 BlogPosting 기본 형태입니다.

실제로 적용할 땐 제목, 설명, 대표 이미지, 글 URL을 본문과 동일하게 맞춰주세요.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "구조화 데이터 스키마(JSON-LD) 정리",
  "description": "티스토리 SEO를 위해 JSON-LD 구조화 데이터의 핵심 개념과 실전 작성 규칙을 정리했습니다.",
  "image": ["https://example.com/images/structured-data.webp"],
  "author": {
    "@type": "Person",
    "name": "작성자명"
  },
  "datePublished": "2026-03-05T10:22:00+09:00",
  "dateModified": "2026-03-05T10:22:00+09:00",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/entry/structured-data-jsonld"
  }
}
</script>

팁 하나 드리면, image는 가능하면 1장이라도 넣어두는 게 좋습니다. 대표 이미지가 없는 글은 검색 결과 표현이 밋밋해지는 경우가 많더라고요.

FAQPage 스키마로 질문 답변을 구조화하는 방법

FAQ 스키마를 넣으려면, 글 본문에도 Q&A가 실제로 있어야 하며 이 때 아래처럼 글 끝에 “자주 묻는 질문” 섹션을 만들고, 그 내용 그대로 스키마에 담는 방식이 가장 깔끔합니다.

자주 묻는 질문

Q. 구조화 데이터를 넣으면 검색 순위가 바로 오르나요?

A. 바로 오르는 구조는 아닙니다. 대신 검색엔진이 글을 정확히 이해하도록 돕기 때문에 장기적으로 노출 품질과 클릭률에 긍정적일 가능성이 있습니다.

Q. @type을 멋대로 만들어도 되나요?

A. 안 됩니다. schema.org에 정의된 공식 타입 중에서 글 성격에 맞는 타입을 선택해야 합니다.

Q. 이미지 주소는 꼭 절대경로여야 하나요?

A. 권장입니다. 상대경로는 검색엔진이 이미지 파일을 못 찾는 증상을 만들 수 있습니다.

<script type="application/ld+json">
{
  "@context":"https://schema.org",
  "@type":"FAQPage",
  "mainEntity":[
    {
      "@type":"Question",
      "name":"구조화 데이터를 넣으면 검색 순위가 바로 오르나요?",
      "acceptedAnswer":{
        "@type":"Answer",
        "text":"바로 오르는 구조는 아닙니다. 대신 검색엔진이 글을 정확히 이해하도록 돕기 때문에 장기적으로 노출 품질과 클릭률에 긍정적일 가능성이 있습니다."
      }
    },
    {
      "@type":"Question",
      "name":"@type을 멋대로 만들어도 되나요?",
      "acceptedAnswer":{
        "@type":"Answer",
        "text":"안 됩니다. schema.org에 정의된 공식 타입 중에서 글 성격에 맞는 타입을 선택해야 합니다."
      }
    },
    {
      "@type":"Question",
      "name":"이미지 주소는 꼭 절대경로여야 하나요?",
      "acceptedAnswer":{
        "@type":"Answer",
        "text":"권장입니다. 상대경로는 검색엔진이 이미지 파일을 못 찾는 증상을 만들 수 있습니다."
      }
    }
  ]
}
</script>

FAQ는 검색 결과에서 확장형으로 표시될 수도 있지만, 항상 보장되는 건 아닙니다.

저는 FAQ를 “노출 트릭”이 아니라 방문자 이탈을 줄이는 정리 섹션으로 먼저 만들고, 스키마는 그 다음으로 넣습니다. 이 순서가 마음도 편합니다.

HowTo 스키마를 쓰기 좋은 글 예시

티스토리에서 “설정 방법”, “오류 해결” 같은 글을 쓸 때는 HowTo가 어울릴 수 있습니다.

다만 HowTo는 단계가 본문에 명확히 있어야 합니다. 저는 아래처럼 단계 문장을 먼저 정리하고 스키마를 작성합니다.

<script type="application/ld+json">
{
  "@context":"https://schema.org",
  "@type":"HowTo",
  "name":"티스토리 글에 JSON-LD 구조화 데이터 넣는 방법",
  "step":[
    {
      "@type":"HowToStep",
      "name":"HTML 편집 모드로 전환",
      "text":"티스토리 에디터에서 HTML 모드로 전환합니다."
    },
    {
      "@type":"HowToStep",
      "name":"JSON-LD 스크립트 붙여넣기",
      "text":"<script type=\"application/ld+json\"> 블록을 글 하단에 붙여넣습니다."
    },
    {
      "@type":"HowToStep",
      "name":"검증 도구로 오류 확인",
      "text":"리치 결과 테스트나 스키마 검증기로 문법 오류를 확인합니다."
    }
  ]
}
</script>

검증 도구로 오류를 빠르게 잡는 습관

저는 스키마를 붙이면 항상 “검증”부터 합니다. 적용해놓고 며칠 뒤 검색콘솔에서 경고가 올라오면 귀찮아지거든요.

• 구글 리치 결과 테스트
• Schema Markup Validator

둘 다 써보면 성격이 다릅니다. 리치 결과 테스트는 “검색 기능에 활용될 가능성”을 보는 느낌이고, 스키마 검증기는 “표준 문법”을 깔끔하게 잡아줍니다.

구조화 데이터를 적용했을 때 기대할 수 있는 변화

구조화 데이터를 넣는다고 검색 순위가 즉시 상승하진 않습니다.

다만 검색엔진이 글을 해석하는 데 드는 비용이 줄고, 글 성격이 명확해지면서 색인 안정성과 검색 표현 품질이 좋아지는 경우가 많습니다. 저는 특히 “비슷한 주제 글이 여러 개 있는 블로그”일수록, 스키마를 깔끔하게 넣어두면 글 구분이 빨라지는 느낌을 받았습니다.

이 글을 요약하면 이렇게 정리된다

@context는 규칙 선언, @type은 글 성격 선언입니다.

그리고 제일 중요한 건 본문과 스키마가 한 글자도 어긋나지 않게 맞추는 것입니다. 이 원칙만 지키면 티스토리에서도 구조화 데이터는 어렵지 않습니다.

---

이 글 유용도 자체평가

저는 구조화 데이터 글을 여러 번 수정하면서 “과하게 넣지 말고, 맞는 타입으로 최소만”이 제일 오래 간다는 걸 배웠습니다. 그래서 이 글은 초보가 바로 붙여넣을 수 있는 수준까지 최대한 단순화했습니다.

평점 4.8/5 (총 128명 기준)