블로그 스키마 마크업 지금 넣어야 하는 유형 따로 있다
블로그 스키마 마크업을 열심히 넣어뒀는데 검색 결과에 아무것도 안 뜨는 경험, 꽤 많이들 하더라고요. 구글 리치 결과 테스터를 돌려도 오류가 없으니 더 황당한 거고요. 알고 보면 이미 폐지된 유형인 경우가 대부분이에요. 😅
한국어 SEO 자료 상당수가 2023년 이전 기준을 그대로 싣고 있다. FAQ 스키마를 넣으면 검색 결과에 아코디언 형태로 질문이 펼쳐진다고 소개하는 글들이 지금도 상위에 있는데, 그 기능은 일반 사이트에서 2023년 8월부터 막혔고 2026년 5월 7일에 완전히 없어졌다.
문제는 '어떤 유형을 쓰면 되는가'만 알아선 반쯤 아는 것이라는 점이다. 구글 문서를 보면 headline, datePublished, @type, ListItem 같은 속성명이 줄줄이 나오는데, 이 이름들이 뭘 의미하고 구글이 어떻게 읽는지를 모르면 코드를 복붙해도 왜 오류가 나는지 파악이 안 된다. 이 글은 지금 블로그에 넣을 수 있는 스키마 유형을 짚되, JSON-LD 속성명 자체를 해독하는 쪽에 무게를 뒀다. 코드를 한 번 읽고 나면 직접 수정할 수 있게.
살아있는 스키마 유형과 폐지된 유형 현황
구글 Search Central 공식 문서를 기준으로 일반 블로그에서 각 스키마 유형의 현재 지원 여부와 폐지 타임라인을 정리했다.
| 스키마 유형 | 리치 결과 지원 | 일반 블로그 효과 | 비고 |
|---|---|---|---|
| BlogPosting / Article | ✅ 지원 | 제목·날짜·이미지 표시 개선 | 구글 공식 권장 |
| BreadcrumbList | ✅ 지원 | URL 대신 경로 텍스트 표시 | 전체 언어·지역 지원, 사이트 유형 제한 없음 |
| Organization | ✅ 지원 | 브랜드 패널 정보 보강 | 홈페이지에 1회 적용 |
| FAQPage | ❌ 폐지 | 리치 결과 없음 | 2023-08 일반 사이트 제한 → 2026-05-07 완전 제거 |
| HowTo | ❌ 폐지 | 리치 결과 없음 | 2023-09 모바일·데스크톱 완전 제거 |
| SitelinksSearchbox | ❌ 제거 | 효과 없음 | 2024-11-21 구글 제거 |
| Product | — | 해당 없음 | 쇼핑몰 전용 |
| Recipe | — | 해당 없음 | 레시피 콘텐츠 전용 |
FAQ 스키마는 2023년 8월에 일반 웹사이트 대상으로 리치 결과 표시가 중단됐고(당시 정부·의료 도메인만 일시 유지), 2026년 5월 7일 모든 사이트에서 완전히 제거됐다. 구글 공식 발표에는 기존 FAQ 마크업을 삭제하지 않아도 페널티가 없다고 명시되어 있다. 이미 넣어뒀다면 놔둬도 되지만, 신규로 추가할 이유는 없다.
BlogPosting 코드를 줄마다 읽어보면
구글 공식 권장 BlogPosting 코드다. 속성명을 그냥 넘기지 말고, 한 줄씩 뜯어보면 감이 온다.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "글 제목 (110자 이내 권장)",
"image": [
"https://example.com/image-16x9.jpg",
"https://example.com/image-4x3.jpg",
"https://example.com/image-1x1.jpg"
],
"datePublished": "2026-07-26T10:00:00+09:00",
"dateModified": "2026-07-26T10:00:00+09:00",
"author": {
"@type": "Person",
"name": "작성자 이름",
"url": "https://example.com/about"
}
}
@context와 @type — 이 두 줄이 JSON-LD의 문법적 뼈대다. @context는 "이 코드는 schema.org 어휘를 따른다"는 선언이고, @type은 "이 페이지의 종류는 BlogPosting이다"라는 분류다. 구글은 Article, NewsArticle, BlogPosting 세 가지를 공식 지원하는데, 개인 블로그 글에는 BlogPosting이 가장 정확한 타입이다.
headline — HTML <title> 태그와 달리, 구글이 리치 결과에서 글 제목을 끌어올 때 참조하는 속성이다. 110자 이내를 권장하는 이유는 검색 결과 제목 표시 한계와 관련된다. <title>에 긴 수식어를 달아도 리치 결과에서는 headline 값이 우선 반영될 수 있다.
image — 배열로 세 개를 쓰는 이유가 있다. 16:9, 4:3, 1:1 비율로 각각 준비하는 건 구글이 표시 환경마다 다른 비율을 쓰기 때문이다. 구글 검색 결과 상단 카드는 주로 16:9, 구글 뉴스는 1:1을 선호한다. 하나만 넣으면 환경에 따라 이미지가 잘리거나 아예 빠진다.
datePublished와 dateModified — 날짜 형식이 ISO 8601이다. +09:00은 한국 시간대(KST)를 명시하는 부분이다. 두 값이 다르면 구글은 수정 이력이 있는 글로 인식한다. dateModified를 매번 오늘 날짜로 갱신하면 신뢰도 신호에 역효과가 날 수 있어서, 글 내용을 실제로 바꿨을 때만 갱신하는 게 맞다.
author의 중첩 구조 — author 안에 또 @type이 들어간다. 이건 작성자 자체를 하나의 독립 객체로 선언하는 방식이다. Person으로 선언하면 구글이 저자 정보를 사람으로 인식하고, url을 함께 넣으면 저자 프로필 페이지와 연결할 수 있다. 흔히 하는 실수가 name 값에 "편집장 홍길동"처럼 직책을 같이 쓰는 건데, 구글 가이드라인에는 이름만 넣도록 명시되어 있다.
BreadcrumbList에서 position이 중요한 이유
URL 경로 대신 "홈 > SEO > 스키마 마크업"처럼 텍스트 경로를 검색 결과에 표시하는 마크업이다. 구글 공식 문서 기준으로 전 세계 모든 언어·지역에서 지원되며 사이트 유형 제한이 없다.
티스토리를 쓴다면 이 마크업이 제일 현실적인 선택이다. BlogPosting은 글마다 값이 달라야 해서 스킨 치환자로 동적 처리하기가 번거로운데, BreadcrumbList는 카테고리 구조가 고정되어 있으면 한 번 넣고 끝낼 수 있다.
속성명 중에서 헷갈리는 게 ListItem과 position이다. ListItem은 경로 각 단계를 나타내는 객체이고, position은 그 순서 번호다. 반드시 1부터 시작해야 하고 0으로 시작하면 구글 리치 결과 테스터가 경고를 뱉는다.
마지막 항목(현재 페이지)의 item 속성은 생략해도 되는데, 생략하지 않으면 반드시 접근 가능한 URL이어야 한다. 경로가 깊어질수록 각 ListItem의 name이 사이트 메뉴명과 일치하는지도 확인할 것. 코드와 내비게이션이 어긋나면 구글이 마크업을 무시할 수 있다.
BlogPosting이 글 단위 마크업이라면, BreadcrumbList는 사이트의 모든 페이지에 동일한 구조로 깔아두는 게 맞다.
Organization, 홈페이지에 한 번만 넣는 브랜드 선언
사이트 전체를 대표하는 마크업이다. 홈페이지에 한 번만 넣으면 된다. 블로그 이름, 로고, 연락처 같은 브랜드 정보를 구글에 전달하고, 사이트명으로 검색할 때 뜨는 브랜드 패널에 이 정보가 반영된다.
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "블로그 이름",
"url": "https://example.com",
"logo": "https://example.com/logo.png"
}
logo 속성의 값은 이미지 파일 URL이다. 해당 URL로 실제 이미지가 반환되는지 확인해야 한다. 404가 뜨면 구글이 해당 속성 자체를 무시한다. 또 이 마크업을 글 페이지마다 반복해서 넣는 경우가 있는데, 홈페이지 1회면 충분하다.
플랫폼에 따라 삽입 방식이 다르다
티스토리
스킨 편집을 통해 <head> 태그 안에 삽입한다.
- 관리자 → 꾸미기 → 스킨 편집으로 이동
- HTML 편집 탭 선택
</head>태그 바로 앞에<script type="application/ld+json">블록 추가
티스토리는 글마다 다른 BlogPosting 스키마를 자동 삽입하는 방법이 제한적이다. 스킨 치환자(변수)를 활용해 동적으로 처리하거나, 사이트 전체에 적용하는 Organization·BreadcrumbList 위주로 넣는 게 현실적인 방법이다.
워드프레스
두 가지 방법이 있다.
플러그인 사용 (권장): Rank Math 또는 Yoast SEO를 설치하면 코드 없이 Article, Organization, BreadcrumbList를 글별로 자동 삽입해준다. Rank Math는 무료 버전에서도 대부분의 스키마 유형을 지원한다.
직접 삽입: WPCode(구 Insert Headers and Footers) 플러그인으로 <head> 영역에 JSON-LD를 수동으로 넣을 수 있다. 글마다 다른 값이 필요한 BlogPosting은 PHP 함수를 써야 해서 난이도가 조금 있다.
자체 제작 사이트 (Next.js 등)
<head> 태그 안에 <script type="application/ld+json"> 태그로 삽입한다. Next.js App Router 기준으로는 각 페이지의 layout.tsx 또는 page.tsx에서 메타데이터와 함께 처리하는 방식이 일반적이다.
리치 결과 테스터로 코드를 검증하는 법
마크업을 넣었으면 구글이 제대로 읽는지 확인해야 한다. 구글의 공식 검증 도구인 리치 결과 테스터(search.google.com/test/rich-results)에서 URL이나 코드를 직접 붙여넣어 테스트할 수 있다.
확인 순서:
search.google.com/test/rich-results접속- 테스트할 페이지 URL을 입력하거나 JSON-LD 코드를 직접 붙여넣기
- "URL 테스트" 또는 "코드 테스트" 실행
- 결과 화면에서 감지된 스키마 유형, 오류(error), 경고(warning) 확인
특히 확인할 것들:
@type이BlogPosting으로 감지되는가headline·datePublished·author가 올바르게 파싱되는가- BreadcrumbList의
position순서가 맞는가 imageURL이 실제 접근 가능한 경로인가
Search Console에서도 "리치 결과 상태" 보고서를 통해 사이트 전체의 스키마 오류를 모니터링할 수 있다.
단, 리치 결과 테스터에서 오류 없음이 뜬다고 해서 검색 결과에 반드시 리치 결과가 뜨는 건 아니다. 표시 여부는 구글 알고리즘이 결정하며, 마크업은 그 가능성을 열어두는 작업이다.
JSON-LD 코드가 낯설지 않아지면
처음엔 @context나 ListItem이 왜 저런 이름인지 영 모르겠고, 복붙한 코드에 오류가 나면 어디서 잘못된 건지 감도 안 잡힌다. Schema.org는 전산학 어휘를 영어로 그대로 쓴 명세서라, 처음 읽을 때 낯선 건 어쩔 수 없다.
속성명 하나씩 뜯어보고 나면 달라진다. headline이 HTML <title>과 다른 역할을 한다는 걸 알고, position이 1부터 시작해야 하는 이유를 알고, author.name에 직책을 왜 넣으면 안 되는지 이해하고 나면 — 구글 Search Central 문서를 직접 열어도 더 이상 막막하지 않다. 스키마 유형이 새로 생기거나 폐지될 때, 그 문서를 스스로 읽고 판단할 수 있게 된다. FAQ 스키마처럼 누군가가 정리해준 글이 없어도.
참고자료
이 글이 도움이 됐나요?
여러분의 반응이 다음 글의 방향이 돼요
