구조화 데이터 스키마 JSON-LD 티스토리 SEO 리치스니펫 적용 방법

잡가이버 2026. 6. 18. 11:16

구조화 데이터 스키마 JSON-LD 티스토리 SEO 리치스니펫 적용 방법

티스토리 블로그를 운영하다 보면 글은 열심히 썼는데 검색엔진이 글의 성격을 제대로 이해하지 못하는 것 같은 느낌을 받을 때가 있습니다. 제목과 본문은 잘 작성했는데 검색결과에서 표현이 애매하거나, 구글 서치콘솔에서 구조화 데이터 관련 경고가 보이거나, Schema.org 검증 도구에서 오류가 뜨는 경우가 대표적입니다.

저도 티스토리와 워드프레스를 같이 운영하면서 구조화 데이터, JSON-LD, 리치스니펫, FAQPage, BlogPosting 같은 용어를 여러 번 만졌는데, 결론부터 말하면 구조화 데이터는 검색 순위를 억지로 올리는 마법 코드가 아니라 검색엔진에게 페이지의 정체를 정확히 설명하는 안내문에 가깝습니다.

특히 티스토리는 워드프레스처럼 Rank Math, Yoast 같은 SEO 플러그인을 자유롭게 설치해 자동으로 스키마를 관리하는 구조가 아니기 때문에, 글마다 필요한 구조화 데이터만 직접 넣거나 스킨 HTML에 사이트 공통 스키마를 넣는 식으로 관리하는 경우가 많습니다.

다만 무조건 많이 넣는다고 좋은 것은 아닙니다. 본문에 실제로 있는 내용만 구조화하고, 페이지 성격에 맞는 타입만 선택하는 것이 가장 안전합니다. 이 글에서는 티스토리 기준으로 구조화 데이터가 무엇인지, JSON-LD를 어디에 넣어야 하는지, Schema.org 검증 오류가 뜰 때 무엇을 확인해야 하는지까지 정리해보겠습니다.

구조화 데이터 스키마란 무엇인가?

구조화 데이터는 검색엔진이 웹페이지를 더 정확히 이해하도록 돕는 표준화된 설명 형식입니다. 사람은 글 제목, 이미지, 작성일, 본문 흐름을 보면 이 글이 후기인지, 정보글인지, 제품 리뷰인지 어느 정도 이해할 수 있습니다. 하지만 검색엔진은 HTML과 텍스트, 링크, 이미지, 메타태그를 기계적으로 분석해야 합니다.

이때 구조화 데이터는 검색엔진에게 이런 식으로 알려주는 역할을 합니다.

이 페이지는 블로그 글입니다.
글 제목은 무엇입니다.
작성자는 누구입니다.
대표 이미지는 이 주소입니다.
처음 발행일과 수정일은 이렇습니다.
이 글에는 질문과 답변이 포함되어 있습니다.
이 페이지는 사이트 전체를 설명하는 홈페이지입니다.

즉 구조화 데이터는 검색엔진이 글을 해석하는 시간을 줄이고, 페이지의 성격을 더 정확히 분류하도록 도와주는 역할을 합니다. 검색 순위를 바로 올려주는 버튼은 아니지만, 색인 안정성과 검색결과 표현 품질을 다듬는 데 도움이 됩니다.

왜 JSON-LD 방식을 많이 사용할까?

구조화 데이터는 Microdata, RDFa, JSON-LD 같은 방식으로 작성할 수 있습니다. 이 중에서 블로그 운영자가 가장 다루기 쉬운 방식은 JSON-LD입니다.

JSON-LD는 HTML 태그 안에 속성을 하나씩 섞어 넣는 방식이 아니라, 아래처럼 <script type="application/ld+json"> 안에 독립적으로 작성합니다.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "글 제목"
}
</script>

이 방식의 장점은 분명합니다. HTML 본문 구조를 크게 건드리지 않아도 되고, 나중에 오류가 났을 때 JSON-LD 블록만 따로 찾아 수정할 수 있습니다. 티스토리처럼 스킨 구조를 완전히 자유롭게 제어하기 어려운 블로그에서는 특히 관리가 편합니다.

@context와 @type부터 이해해야 한다

JSON-LD에서 가장 먼저 보는 항목은 @context와 @type입니다.

항목	의미	예시
@context	어떤 표준 규칙을 사용할지 선언	https://schema.org
@type	이 페이지 또는 데이터가 무엇인지 선언	BlogPosting, FAQPage, Organization

@context는 보통 https://schema.org를 사용합니다. 그리고 @type은 페이지의 실제 성격에 맞게 골라야 합니다. 일반 블로그 글이면 BlogPosting, 사이트 운영자 정보라면 Organization, 질문과 답변 중심 글이면 FAQPage가 어울립니다.

여기서 가장 많이 하는 실수가 있습니다. 검색결과에서 멋지게 보이고 싶다는 이유로 실제 글 성격과 다른 @type을 넣는 것입니다. 예를 들어 일반 정보글인데 상품 리뷰처럼 Review를 넣거나, 본문에 FAQ가 없는데 FAQPage를 넣는 식입니다. 이런 방식은 오래 가지 않습니다.

티스토리 글에 자주 쓰는 스키마 타입

티스토리 블로그에서 모든 스키마를 다 쓸 필요는 없습니다. 오히려 너무 많은 스키마를 억지로 넣으면 관리가 어려워지고, 본문과 불일치하는 항목이 생길 수 있습니다. 일반적인 블로그라면 아래 정도만 알아도 충분합니다.

스키마 타입	적합한 페이지	주의할 점
WebSite	블로그 전체 사이트	스킨 head에 사이트 공통으로 1회 적용
Organization	블로그 브랜드, 운영 주체	로고와 URL은 절대경로 사용
BlogPosting	일반 티스토리 포스팅	제목, 설명, 날짜, 이미지가 실제 글과 일치해야 함
BreadcrumbList	카테고리 경로가 중요한 글	링크 순서와 페이지 계층이 맞아야 함
FAQPage	본문에 실제 FAQ가 있는 글	본문에 없는 질문을 스키마에 넣으면 안 됨
HowTo	단계별 설정 방법, 오류 해결 순서	현재 구글 검색의 HowTo 리치 결과 노출은 제한적이므로 과대 기대 금지

저는 티스토리에서는 보통 사이트 공통 정보는 스킨 head에 넣고, 글마다 달라지는 BlogPosting이나 FAQPage는 글 본문 하단 HTML 모드에 넣는 방식을 선호합니다. 이렇게 나누면 중복이 줄고, 글을 수정할 때도 관리가 쉽습니다.

Schema.org 검증 도구에서 URL을 찾을 수 없다고 뜨는 이유

구조화 데이터를 넣고 Schema.org Markup Validator에서 검사했는데 아래와 같은 메시지가 뜰 때가 있습니다.

URL을 찾을 수 없습니다. 도메인 이름이 올바르고 서버가 200 상태 코드로 응답하는지 확인하세요.

이 메시지는 꼭 JSON-LD 문법이 틀렸다는 뜻은 아닙니다. 더 정확히 말하면 검증 도구가 해당 URL의 HTML을 정상적으로 가져오지 못했다는 뜻에 가깝습니다.

즉 먼저 봐야 할 것은 스키마 코드가 아니라 URL 접속 상태입니다.

URL 검증 오류가 뜰 때 확인할 것

확인 항목	설명
주소 오타	https, www, 도메인, 글 주소 슬러그가 정확한지 확인합니다.
비공개 또는 임시 저장 글	발행되지 않은 글은 외부 검증 도구가 접근하지 못합니다.
404 또는 리다이렉트 문제	브라우저에서는 열려 보여도 실제 응답 코드가 200이 아닐 수 있습니다.
보안 플러그인 또는 방화벽	일부 보안 설정이 외부 검사 도구의 접근을 막을 수 있습니다.
캐시 또는 CDN	Cloudflare, 호스팅 보안, 캐시 설정 때문에 검사 도구가 차단될 수 있습니다.
티스토리 발행 직후	발행 직후에는 외부 도구에서 URL 접근이 안정적이지 않을 때도 있습니다.

이럴 때는 우선 글 주소를 브라우저 시크릿 모드에서 열어보고, 정상적으로 열리는지 확인합니다. 그다음 Schema.org 검증 도구에서 URL 검사 대신 코드 직접 입력 방식으로 JSON-LD만 붙여 넣어 테스트하면 문법 문제인지 URL 접근 문제인지 빠르게 구분할 수 있습니다.

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

티스토리에서 구조화 데이터를 넣는 위치는 크게 두 곳입니다.

1. 글 본문 HTML 모드에 넣기

글마다 다른 구조화 데이터는 글 본문 HTML 모드에 넣는 것이 관리하기 쉽습니다. 예를 들어 특정 글의 BlogPosting, FAQPage, HowTo 스키마는 해당 글 하단에 넣으면 됩니다.

티스토리 에디터에서 기본모드로 글을 작성한 뒤, 오른쪽 상단 메뉴에서 HTML 모드로 전환하고 글 맨 아래에 JSON-LD 스크립트를 붙여 넣으면 됩니다.

2. 스킨 편집 head 영역에 넣기

사이트 전체에 공통으로 적용할 정보는 스킨 편집의 head 영역에 넣는 것이 좋습니다. 예를 들어 WebSite, Organization, 블로그 로고, 사이트명, 대표 URL 같은 정보는 글마다 반복해서 넣을 필요가 없습니다.

다만 스킨에 넣는 공통 스키마는 한 번 잘못 넣으면 모든 페이지에 영향을 주기 때문에, 수정 전에는 반드시 원본 스킨을 백업하는 것이 좋습니다.

티스토리 공통 WebSite + Organization JSON-LD 예시

아래 코드는 티스토리 스킨의 <head> 안에 넣을 수 있는 사이트 공통 구조화 데이터 예시입니다. 도메인, 사이트명, 설명, 로고 주소는 본인 블로그에 맞게 바꿔야 합니다.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.tistory.com/#organization",
      "name": "블로그 이름",
      "url": "https://example.tistory.com/",
      "logo": {
        "@type": "ImageObject",
        "@id": "https://example.tistory.com/#logo",
        "url": "https://example.tistory.com/logo.png"
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://example.tistory.com/#website",
      "url": "https://example.tistory.com/",
      "name": "블로그 이름",
      "description": "블로그 설명을 한 문장으로 작성합니다.",
      "inLanguage": "ko-KR",
      "publisher": {
        "@id": "https://example.tistory.com/#organization"
      },
      "potentialAction": {
        "@type": "SearchAction",
        "target": "https://example.tistory.com/search/{search_term_string}",
        "query-input": "required name=search_term_string"
      }
    }
  ]
}
</script>

여기서 중요한 부분은 @id입니다. 같은 조직, 같은 웹사이트를 여러 스키마에서 참조할 때 #organization, #website 같은 식으로 고유 ID를 정해두면 구조가 깔끔해집니다.

티스토리 BlogPosting JSON-LD 기본 템플릿

일반 포스팅에는 BlogPosting 타입을 사용할 수 있습니다. 아래는 기본 템플릿입니다. 그대로 복사해서 쓰기보다는 글 제목, 설명, URL, 대표 이미지, 날짜를 실제 글에 맞게 바꿔야 합니다.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "구조화 데이터 스키마 JSON-LD 티스토리 SEO 리치스니펫 적용 방법",
  "description": "티스토리 블로그에서 구조화 데이터와 JSON-LD를 적용하는 방법, Schema.org 검증 오류 해결법, BlogPosting과 FAQPage 작성 규칙을 정리했습니다.",
  "image": [
    "https://example.tistory.com/image/structured-data-jsonld.jpg"
  ],
  "author": {
    "@type": "Person",
    "name": "작성자명"
  },
  "publisher": {
    "@type": "Organization",
    "name": "블로그 이름",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.tistory.com/logo.png"
    }
  },
  "datePublished": "2026-06-18T10:00:00+09:00",
  "dateModified": "2026-06-18T10:00:00+09:00",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.tistory.com/entry/structured-data-jsonld"
  },
  "inLanguage": "ko-KR"
}
</script>

여기서 날짜는 2026-06-18T10:00:00+09:00처럼 시간대가 포함된 형식이 좋습니다. 대표 이미지도 가능하면 상대경로가 아니라 https로 시작하는 절대경로를 넣어야 합니다.

FAQPage 스키마는 아직 넣어도 될까?

FAQPage는 블로그 운영자들이 많이 쓰던 스키마입니다. 다만 지금은 예전처럼 아무 블로그나 FAQ 리치 결과가 자주 표시되는 구조는 아닙니다. 따라서 FAQPage를 넣는 목적을 “무조건 검색결과에 FAQ를 띄우기 위해서”로 잡으면 실망할 수 있습니다.

그럼에도 FAQ 섹션 자체는 여전히 유용합니다. 방문자가 글을 끝까지 읽지 않아도 핵심 질문을 빠르게 확인할 수 있고, 검색엔진도 글의 주요 질의응답 구조를 이해하는 데 도움을 받을 수 있습니다.

중요한 원칙은 간단합니다.

본문에 실제로 보이는 질문과 답변만 FAQPage에 넣습니다.
본문에 없는 질문을 검색 노출용으로 추가하지 않습니다.
답변은 과장하지 않고 본문 내용과 일치하게 작성합니다.
광고 문구나 클릭 유도 문구를 답변에 억지로 넣지 않습니다.

FAQPage JSON-LD 예시

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "구조화 데이터를 넣으면 검색 순위가 바로 오르나요?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "구조화 데이터는 검색 순위를 즉시 올리는 요소라기보다 검색엔진이 페이지 내용을 정확히 이해하도록 돕는 기술입니다. 리치 결과 후보가 될 수는 있지만 노출이 보장되지는 않습니다."
      }
    },
    {
      "@type": "Question",
      "name": "티스토리에서는 JSON-LD를 어디에 넣어야 하나요?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "글마다 다른 BlogPosting이나 FAQPage는 글 본문 HTML 모드 하단에 넣고, WebSite나 Organization 같은 사이트 공통 스키마는 스킨 편집의 head 영역에 넣는 방식이 관리하기 쉽습니다."
      }
    },
    {
      "@type": "Question",
      "name": "Schema.org 검증 도구에서 URL을 찾을 수 없다고 나오면 스키마가 틀린 건가요?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "반드시 스키마 문법 오류라는 뜻은 아닙니다. 검증 도구가 해당 URL의 HTML을 정상적으로 가져오지 못했다는 의미일 수 있으므로 URL 오타, 200 응답, 공개 상태, 방화벽, 캐시, CDN 설정을 먼저 확인해야 합니다."
      }
    }
  ]
}
</script>

HowTo 스키마는 신중하게 써야 한다

티스토리에서 “설정 방법”, “오류 해결 방법”, “설치 순서” 같은 글을 많이 쓴다면 HowTo 스키마가 어울려 보일 수 있습니다. 하지만 현재 구글 검색에서는 HowTo 리치 결과 노출이 예전과 다르게 제한되어 있기 때문에, 단순히 리치스니펫을 노리고 넣는 것은 추천하지 않습니다.

그래도 글 내용이 실제로 단계별 해결 순서라면, 본문 구조를 명확히 하는 용도로는 도움이 될 수 있습니다. 다만 아래 조건을 만족할 때만 쓰는 것이 안전합니다.

본문에 단계가 실제로 순서대로 나와 있어야 합니다.
각 단계가 독립적으로 이해 가능해야 합니다.
스키마의 step 내용이 본문과 달라지면 안 됩니다.
단순 정보글에는 억지로 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": "Schema.org Markup Validator 또는 구글 리치 결과 테스트에서 오류를 확인합니다."
    }
  ]
}
</script>

구조화 데이터에서 자주 나는 오류

구조화 데이터 오류는 대부분 대단한 문제가 아니라 작은 실수에서 시작합니다. 특히 티스토리에서 HTML 모드로 붙여넣다 보면 따옴표, 쉼표, 태그 위치가 꼬일 수 있습니다.

오류 유형	원인	해결 방법
JSON 파싱 오류	쉼표, 따옴표, 중괄호 오류	검증 도구의 직접 입력으로 JSON 문법 확인
필수 필드 누락	headline, image, datePublished 등 누락	사용한 스키마 타입의 권장/필수 항목 확인
본문과 스키마 불일치	본문에 없는 FAQ, 과장된 리뷰 정보	본문에 보이는 내용만 스키마에 반영
이미지 접근 불가	상대경로, 만료된 이미지 URL, 차단된 이미지	https 절대경로 이미지 사용
URL 접근 실패	404, 비공개, 방화벽, 서버 응답 문제	시크릿창 접속과 200 응답 확인

검증 도구는 두 가지를 같이 쓰는 것이 좋다

구조화 데이터를 넣었다면 반드시 검증해야 합니다. 저는 보통 아래 두 가지를 같이 씁니다.

구글 리치 결과 테스트는 구글 검색에서 활용 가능한 리치 결과 후보를 확인하는 데 좋고, Schema.org Markup Validator는 Schema.org 표준 구조와 JSON-LD 문법을 확인하는 데 좋습니다.

URL 검사와 코드 직접 입력을 구분하자

URL 검사에서 실패가 뜨면 코드가 틀렸다고 바로 판단하지 말고, 먼저 직접 입력 방식으로 JSON-LD만 검사해보는 것이 좋습니다.

직접 입력 검사에서 통과하고 URL 검사에서 실패하면 URL 접근 문제일 가능성이 큽니다.
직접 입력 검사에서도 실패하면 JSON 문법 또는 스키마 작성 문제입니다.
리치 결과 테스트에서는 통과해도 검색결과 노출이 보장되지는 않습니다.

티스토리 구조화 데이터 적용 순서

처음부터 모든 스키마를 한 번에 넣으려고 하면 오히려 꼬입니다. 저는 아래 순서로 적용하는 편이 가장 안전하다고 봅니다.

대표 글 1개를 정합니다.
글 제목, 설명, 대표 이미지, 발행일, 수정일을 정리합니다.
BlogPosting JSON-LD를 글 하단 HTML 모드에 넣습니다.
본문 하단에 실제 FAQ 섹션이 있다면 FAQPage를 추가합니다.
Schema.org 직접 입력 검사로 JSON 문법을 확인합니다.
발행 후 URL 검사로 외부 접근 여부를 확인합니다.
문제가 없으면 다른 글에도 같은 기준으로 확장합니다.

사이트 공통 정보는 별도입니다. 블로그 전체에 적용할 WebSite, Organization은 글마다 넣지 말고 스킨 head에 한 번만 넣는 것이 좋습니다.

구조화 데이터가 검색 노출에 주는 현실적인 효과

구조화 데이터를 넣었다고 검색 순위가 바로 올라가지는 않습니다. 이 부분은 기대치를 낮추는 것이 좋습니다. 대신 페이지의 주제, 작성자, 이미지, 날짜, 질문 답변 구조를 검색엔진이 더 명확히 이해할 수 있습니다.

특히 비슷한 주제의 글이 많은 블로그에서는 글마다 제목과 본문만으로 차이를 설명하기 어려울 때가 있습니다. 이럴 때 구조화 데이터는 각 글의 성격을 정리하는 보조 신호가 됩니다.

저는 구조화 데이터를 검색 노출 트릭으로 보기보다, 검색엔진에게 글의 구조를 정직하게 전달하는 정리 작업으로 보는 것이 더 맞다고 생각합니다.

자주 묻는 질문

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

아닙니다. 구조화 데이터는 검색 순위를 직접 올리는 버튼이 아닙니다. 다만 검색엔진이 글 내용을 더 정확히 이해하도록 도와 색인 안정성, 검색결과 표현, 리치 결과 후보 자격에 영향을 줄 수 있습니다.

티스토리에서는 JSON-LD를 어디에 넣는 것이 좋나요?

글마다 다른 BlogPosting, FAQPage는 글 본문 HTML 모드 하단에 넣고, WebSite나 Organization처럼 사이트 전체에 공통으로 적용할 내용은 스킨 편집의 head 영역에 넣는 것이 관리하기 쉽습니다.

FAQPage를 넣으면 구글 검색결과에 FAQ가 무조건 뜨나요?

아닙니다. 현재 FAQ 리치 결과 노출은 제한적이며, 구조화 데이터를 올바르게 넣었다고 해서 검색결과 표시가 보장되지는 않습니다. 그래도 방문자 이해를 돕는 본문 FAQ 섹션 자체는 여전히 가치가 있습니다.

Schema.org 검증 도구에서 URL을 찾을 수 없다고 뜨면 어떻게 해야 하나요?

먼저 URL이 공개 상태인지, 주소가 정확한지, 서버가 200 상태로 응답하는지 확인해야 합니다. 그다음 검증 도구의 코드 직접 입력 방식으로 JSON-LD만 검사하면 URL 접근 문제인지 JSON 문법 문제인지 구분할 수 있습니다.

구조화 데이터는 많이 넣을수록 좋은가요?

아닙니다. 본문에 없는 내용을 억지로 넣거나 페이지 성격과 맞지 않는 스키마를 남발하면 오히려 신뢰도가 떨어질 수 있습니다. 필요한 타입만 정확히 넣는 것이 가장 안전합니다.

마무리 구조화 데이터는 많이보다 정확하게

티스토리에서 구조화 데이터를 적용할 때 가장 중요한 원칙은 간단합니다. 본문에 있는 내용을, 페이지 성격에 맞는 타입으로, JSON 문법에 맞게 넣는 것입니다.

처음에는 BlogPosting 하나만 제대로 넣어도 충분합니다. 그다음 실제 FAQ가 있는 글에 FAQPage를 추가하고, 사이트 전체에는 WebSite와 Organization을 한 번만 넣으면 됩니다.

Schema.org 검증 도구에서 URL 오류가 뜬다고 해서 바로 스키마를 의심할 필요는 없습니다. URL 접근 문제와 JSON 문법 문제를 나눠서 확인하면 대부분 빠르게 원인을 찾을 수 있습니다.

결국 구조화 데이터는 검색엔진을 속이는 코드가 아니라, 내가 쓴 글을 검색엔진이 제대로 이해하도록 돕는 정리표입니다. 이 기준으로 접근하면 티스토리에서도 충분히 안정적인 SEO 구조를 만들 수 있습니다.

그리드형

저작자표시 비영리 변경금지 (새창열림)