구조화 데이터는 넣는 것보다 무엇을 넣지 않을지 고르는 게 더 중요해졌습니다. 2023년 이후 구글이 FAQ·HowTo 리치 결과를 사실상 접었고 2024년 11월에는 사이트링크 검색창 지원마저 끝냈기 때문에, 몇 년 전 블로그 글을 보고 따라 넣은 마크업 중 상당수는 지금 아무 일도 하지 않습니다. 개인 블로그가 실제로 챙길 가치가 있는 스키마는 네 종류 정도이고, 그중 눈에 보이는 효과가 확실한 건 하나뿐입니다. 아래 내용은 2026년 10월 기준 구글 검색 센터의 공개 문서와 schema.org 명세를 근거로 정리한 것이며, 정책이 다시 바뀔 수 있는 영역이므로 작업 전에 공식 문서를 한 번 더 확인하는 편이 안전합니다.
구조화 데이터가 해주는 일은 ‘순위 상승’이 아니다
먼저 기대치를 정확히 맞춰야 합니다. 구글은 구조화 데이터가 순위를 올려주는 신호라고 말한 적이 없습니다. 공식 문서가 일관되게 설명하는 역할은 두 가지입니다. 하나는 페이지의 내용을 기계가 덜 헷갈리게 이해하도록 돕는 것, 다른 하나는 리치 결과(rich result) 표시 자격을 얻는 것입니다. 자격을 얻는다는 것도 표시를 보장한다는 뜻이 아닙니다. 마크업이 완벽해도 구글이 안 보여주기로 하면 안 보입니다.
그러면 왜 넣느냐. 수익형 블로그 입장에서 실익은 순위가 아니라 클릭률에서 나옵니다. 같은 7위라도 검색 결과에 경로나 별점이 함께 보이면 클릭이 늘고, 늘어난 클릭이 그대로 광고 노출로 이어집니다. 반대로 말하면 리치 결과가 표시되지 않는 스키마를 넣는 작업은 수익에 기여하는 바가 0에 가깝습니다. 이 구분이 이 글의 전부입니다. 노출 자체를 못 받고 있는 상황이라면 마크업보다 색인이 먼저 문제이므로 구글 서치콘솔 색인 안 될 때 원인 체크리스트부터 확인하는 게 순서입니다.
또 하나 자주 오해되는 지점이 있습니다. “구조화 데이터를 넣으면 구글이 글을 신뢰한다”는 식의 설명인데, 근거가 없습니다. 마크업은 내용의 진위를 증명하지 못합니다. 저자가 누구라고 적어넣는 것과 그 저자가 실제로 신뢰할 만한지는 전혀 다른 문제이고, 구글도 마크업을 신뢰도 판단의 근거로 쓴다고 말하지 않습니다. 마크업은 이미 있는 정보를 정확하게 전달하는 포맷일 뿐입니다.
리치 결과가 사라진 스키마부터 걷어내자
작업 순서를 뒤집는 게 좋습니다. 새로 넣기 전에, 이미 넣어둔 것 중 수명이 끝난 것을 확인하세요. 세 가지가 대표적입니다.
FAQPage는 2023년 8월 변경 이후 정부·보건 기관처럼 구글이 권위 있다고 판단한 사이트에만 제한적으로 표시됩니다. 개인 블로그에서는 마크업이 유효하게 인식되더라도 검색 결과에 아코디언 형태로 나오지 않습니다. HowTo는 같은 시기 데스크톱·모바일 모두에서 리치 결과 표시가 중단됐습니다. 즉 단계별 가이드 글에 HowTo를 공들여 넣어도 지금은 표시 자체가 없습니다. WebSite의 SearchAction(사이트링크 검색창)은 2024년 11월 지원이 종료됐습니다.
여기서 판단이 갈립니다. 이미 넣어둔 걸 지워야 하냐는 질문인데, 답은 “급하지 않다”입니다. 표시가 안 되는 마크업이 페널티를 유발한다는 근거는 없고, 삭제 작업에 드는 시간 대비 얻는 게 없습니다. 다만 두 경우는 예외입니다. 첫째, 플러그인이 FAQ 블록을 쓰느라 글 구조를 억지로 Q&A로 꼬아놨다면 글 자체를 손보는 게 맞습니다. 둘째, 수동으로 넣은 JSON-LD가 본문과 불일치하는 상태라면 — 예를 들어 본문에서 지운 질문이 마크업에만 남아 있다면 — 이건 정책 위반 소지가 있으니 정리해야 합니다. 구조화 데이터는 반드시 페이지에 사람이 볼 수 있는 형태로 존재하는 내용만 담아야 합니다.
한 가지 덧붙이면, 리치 결과가 사라졌다고 해서 글 안의 FAQ 섹션 자체가 쓸모없어진 건 아닙니다. 리치 결과를 노린 마크업은 효용이 끝났지만, 독자가 실제로 궁금해하는 질문에 답하는 섹션은 체류 시간과 재방문에 그대로 기여합니다. 없애야 하는 건 마크업이지 콘텐츠가 아닙니다.
개인 블로그가 실제로 챙길 스키마는 네 가지
남는 것은 많지 않습니다. 아래 표는 수익형 블로그 기준으로 우선순위를 정리한 것입니다.
| 스키마 | 검색 결과에 보이는가 | 넣는 난이도 | 우선순위 |
|---|---|---|---|
| BreadcrumbList | 보임 (URL 자리에 카테고리 경로) | 낮음 — 플러그인이 대부분 자동 처리 | 1순위. 유일하게 효과가 눈에 보인다 |
| Article / BlogPosting | 직접 안 보임 | 낮음 | 2순위. 제목·작성일·저자 전달용 |
| Person / Organization | 직접 안 보임 | 중간 — 저자 페이지 연결 필요 | 3순위. 필명 블로그라면 의미 있음 |
| ItemList | 목록형 글에서 간헐적 | 중간 | 4순위. “TOP 7” 류 글만 |
| Product / Review | 보임 | 높음 | 해당 없음 — 직접 판매·실사용 리뷰 아니면 금지 |
| FAQPage / HowTo | 안 보임 (2023년 중단) | 낮음 | 넣지 않는다 |
표의 마지막 두 줄이 핵심입니다. Product와 Review는 리치 결과가 살아 있어서 유혹이 크지만, 구글 정책은 자기 사업체·자기 콘텐츠에 대한 자체 평가(self-serving review)를 리뷰 스니펫으로 쓰는 것을 금지합니다. 직접 판매하지 않는 남의 제품에 별점을 매겨 마크업하는 것도 위반 소지가 큽니다. 도구 비교 글을 쓰면서 별점 스키마를 붙이고 싶은 마음이 들 텐데, 여기서 얻는 클릭보다 수동 조치 위험이 큽니다. 비교 글의 신뢰도는 마크업이 아니라 비교 기준을 밝히는 문장에서 나옵니다. 애초에 체험하지 않은 제품에 점수를 매기는 글이라면 별점부터가 허위가 되고요.
BreadcrumbList를 1순위로 둔 이유도 분명합니다. 이것만 유일하게 모든 글에서 즉시 눈에 보이는 변화를 만들고, 동시에 사이트 구조가 정리돼 있어야만 제대로 작동합니다. 카테고리가 난립해 있으면 경로 자체가 이상하게 찍히므로, 마크업 전에 워드프레스 카테고리·태그 구조 설계하는 법에서 정리한 기준으로 분류를 먼저 손보는 게 효율적입니다.
플러그인에 맡길까, JSON-LD를 직접 넣을까
결론부터 말하면 거의 모든 경우 플러그인입니다. 직접 작성이 나은 상황은 한 가지로 좁혀집니다.
| 방식 | 장점 | 단점 | 맞는 상황 |
|---|---|---|---|
| SEO 플러그인 내장 (Yoast·Rank Math 등) | 전 글에 일괄 적용, 구글 정책 변경 시 업데이트로 따라감 | 세부 통제 어려움, 플러그인 교체 시 전부 사라짐 | 기본값. 글이 수십~수백 편이면 사실상 유일한 선택 |
| 전용 스키마 플러그인 | 글별로 타입 지정 가능 | SEO 플러그인과 중복 출력 충돌이 잦음 | 특정 글 유형이 반복적으로 많을 때 |
| 테마 functions.php에 직접 JSON-LD | 출력 내용을 100% 통제, 플러그인 의존 없음 | 직접 유지보수, 정책 변경을 본인이 추적해야 함 | 특수 타입 한두 개를 전체에 일괄 적용할 때 |
| 글마다 수동 삽입 | — | 본문과 불일치가 생기고, 글 수정 때 잊어버림 | 권하지 않음 |
가장 흔한 사고는 중복 출력입니다. SEO 플러그인이 이미 Article과 BreadcrumbList를 내보내는데 스키마 플러그인을 추가로 깔면, 같은 페이지에 서로 다른 내용의 마크업이 두 벌 실립니다. 구글은 이런 경우 어느 쪽을 믿을지 알 수 없어 둘 다 무시할 수 있습니다. 그래서 작업 전에 “지금 내 사이트가 이미 무엇을 내보내고 있는지”를 먼저 확인해야 합니다. 플러그인을 더 얹기 전에 기존 구성을 점검하는 기준은 워드프레스 필수 플러그인 고르는 법에 정리해뒀습니다.
functions.php 직접 삽입을 고를 때 반드시 전제가 되는 조건이 하나 있습니다. 자식 테마를 쓰고 있어야 합니다. 부모 테마 파일을 고치면 테마 업데이트에서 전부 날아갑니다. 이 조건을 만족하지 않는다면 코드를 만지는 선택지는 애초에 고려 대상이 아닙니다.
넣은 다음 검증하는 순서와 자주 나는 오류
검증은 세 단계로 나눠서 하는 게 정확합니다. 순서를 지키는 이유는 각 도구가 보는 게 다르기 때문입니다.
1단계 — 리치 결과 테스트. 구글이 이 페이지에서 어떤 리치 결과 자격을 인식했는지 봅니다. 여기서 아무 항목도 안 잡히면 구글 입장에서는 마크업이 없는 것과 같습니다. 2단계 — 스키마 마크업 검증기. schema.org 명세 기준으로 문법 오류를 봅니다. 1단계에서 “자격 없음”이 나왔을 때 원인이 문법인지 정책인지 여기서 갈립니다. 3단계 — 서치콘솔 개선 사항 리포트. 사이트 전체에서 같은 오류가 몇 개 글에 걸쳐 있는지 봅니다. 개별 테스트로는 한 글만 보이지만, 플러그인 설정 문제는 전 글에 똑같이 퍼져 있으므로 이 리포트가 사실상 가장 중요합니다.
자주 나는 오류는 패턴이 정해져 있습니다. 첫째, 이미지 필드 누락 — 대표이미지를 지정하지 않은 글에서 Article의 image가 비어 경고가 뜹니다. 둘째, 작성자 정보 누락 — 저자 표시를 테마에서 끈 경우 author가 비어 있습니다. 셋째, 날짜 불일치 — 글을 대폭 수정했는데 dateModified가 갱신되지 않아 검색 결과 날짜가 과거로 남습니다. 넷째, 마크업에만 있는 내용 — 앞서 말한 정책 위반 유형이고 유일하게 급히 고쳐야 하는 항목입니다.
세 번째 항목은 특히 신경 쓸 만합니다. 오래된 글을 손볼 때 수정일이 반영되지 않으면 품질 개선 작업이 검색 결과에 전혀 드러나지 않습니다. 글을 고쳐도 성과가 안 보이는 원인이 여기일 때가 있어서, 오래된 블로그 글 업데이트하는 법에서 다룬 보수 작업과 묶어 한 번에 점검하는 게 좋습니다. 그리고 검색 결과에 보이는 제목·설명 자체를 손보는 일은 마크업보다 클릭률 효과가 훨씬 크므로, 둘 중 하나만 할 시간이 있다면 블로그 글 제목과 메타 설명 쓰는 법 쪽이 먼저입니다.
이럴 땐 이걸 고르세요
글이 30편 미만이고 아직 애드센스 승인 전이라면 — 구조화 데이터는 지금 할 일이 아닙니다. SEO 플러그인 하나를 깔고 기본값을 켜두는 선에서 끝내세요. 승인 심사는 마크업을 보지 않습니다. 전체 순서가 궁금하다면 워드프레스 애드센스 수익형 블로그 완전 가이드의 단계별 순서를 따라가는 게 빠릅니다.
노출은 나오는데 클릭률이 1% 아래라면 — BreadcrumbList가 제대로 찍히는지 확인하고, 그다음 제목·메타 설명을 손보세요. 이 조합이 투입 시간 대비 효과가 가장 확실합니다.
글이 100편을 넘고 카테고리가 정리돼 있다면 — 서치콘솔 개선 사항 리포트를 열어 사이트 전체에 퍼진 오류를 한 번에 잡는 작업이 남는 장사입니다. 글 하나씩 열어보는 방식으로는 끝나지 않습니다.
FAQ·HowTo 마크업을 열심히 넣어둔 상태라면 — 지우느라 시간 쓰지 말고, 본문과 마크업 내용이 어긋난 글만 골라 정리하세요. 그 외에는 방치해도 손해가 없습니다.
도구 비교·추천 글을 주로 쓴다면 — Review·AggregateRating 스키마는 쓰지 마세요. 직접 써보지 않은 제품에 점수를 매기는 순간 허위 표시가 되고, 리치 결과 이득보다 수동 조치 위험이 큽니다. 비교 기준을 본문에 명시하는 쪽이 신뢰도에 훨씬 크게 기여합니다.
자주 묻는 질문
Q. 구조화 데이터를 넣으면 순위가 오르나요?
A. 아니요. 구글은 구조화 데이터를 순위 신호로 쓴다고 밝힌 적이 없습니다. 얻는 것은 리치 결과 표시 ‘자격’이고, 그마저 표시가 보장되지 않습니다. 실익은 검색 결과가 조금 더 눈에 띄어 클릭률이 올라가는 경로로만 생깁니다. 순위를 올리려면 마크업보다 글의 내용과 내부링크 구조를 손보는 게 맞습니다.
Q. 플러그인을 바꾸면 마크업이 전부 사라지나요?
A. 네, 플러그인이 출력하던 마크업은 비활성화하는 순간 같이 사라집니다. 다만 구조화 데이터는 글 내용에 저장되는 게 아니라 페이지 출력 시점에 생성되는 것이므로, 새 플러그인을 켜면 대부분 자동으로 다시 생성됩니다. 복구가 필요한 건 마크업이 아니라 플러그인에만 저장돼 있던 메타 설명·제목 같은 입력값입니다. 이쪽이 실제 손실이라 교체 전 백업이 필요합니다.
Q. 수동으로 JSON-LD를 넣었는데 리치 결과 테스트에서 아무것도 안 잡힙니다.
A. 흔한 원인은 두 가지입니다. 스크립트가 캐시 플러그인의 HTML 최소화 과정에서 깨진 경우, 그리고 type="application/ld+json" 속성이 빠져 브라우저가 일반 스크립트로 처리한 경우입니다. 캐시를 비운 뒤 페이지 소스에서 해당 블록이 그대로 살아 있는지 먼저 확인하세요. 소스에 정상적으로 있는데도 안 잡히면 문법 오류이므로 스키마 마크업 검증기로 넘어가면 됩니다.