JSON-LD 형식, 순위엔 영향 없는데 다들 붙이는 진짜 이유

검색 결과를 내리다 보면 유독 눈에 띄는 글이 있어요. 제목 아래 별점이 뜨고, 이동 경로가 보이고, 질문이 접혀 있는 그 결과들이요. 내 글은 제목과 두 줄짜리 설명뿐인데 말이죠. 이 차이를 만드는 게 바로 JSON-LD 형식의 구조화 데이터예요. 결론부터 말하면 JSON-LD는 검색 순위를 직접 올려주는 요소는 아니지만, 리치 결과 노출 자격을 만들어 클릭률을 끌어올리고 요즘은 AI 검색이 내 글을 정확히 이해하게 만드는 통로 역할까지 해요. 코딩을 몰라도 괜찮아요. 중괄호 세 줄만 이해하면 나머지는 템플릿을 고쳐 쓰는 일이고, 워드프레스라면 플러그인이 이미 절반을 해두고 있거든요.

• JSON-LD 형식이 뭐길래 검색 결과가 달라질까
• 구조화 데이터 3형식 비교: JSON-LD를 권하는 이유
• 레고 블록처럼 뜯어보는 JSON-LD 문법
• 어디에 넣어야 할까: script 태그 위치와 다중 삽입
• 블로그 글에 바로 쓰는 타입별 코드 템플릿
• Claude Code에게 JSON-LD를 맡겼다면 확인할 것들
• 워드프레스에서 Rank Math와 겹치지 않게 정리하기
• 리치 결과 테스트로 검증하고 오류 잡기
• 네이버와 AI 검색까지, GEO에서 중요해진 이유
• 자주 묻는 질문
• 참고자료

JSON-LD 형식이 뭐길래 검색 결과가 달라질까

JSON-LD는 JavaScript Object Notation for Linked Data의 줄임말이에요. 앞의 JSON은 데이터를 이름과 값의 짝으로 적는 형식이고, 뒤의 LD(Linked Data)는 그 이름들이 전 세계가 공유하는 사전을 따른다는 뜻이에요. 그 사전이 schema.org고요.

왜 이런 게 필요할까요. 사람은 글을 읽으면 이게 요리 레시피인지 채용 공고인지 바로 알아요. 하지만 크롤러 입장에서 HTML은 그냥 글자 덩어리예요. 제목 태그와 문단 태그는 있지만 이 숫자가 가격인지 조회수인지 구분할 근거가 없죠.

그래서 페이지 안에 기계용 요약본을 하나 더 붙이는 거예요. 사람 눈에는 안 보이고, 크롤러만 읽는 명함 같은 조각이죠. 여기에 이 글은 Article이고, 제목은 이것이고, 작성일은 언제이고, 저자는 누구라고 적어두면 검색엔진이 추측할 필요가 없어져요.

효과를 정확히 말하면 이래요. 구글은 구조화 데이터를 랭킹 시그널로 쓴다고 공식적으로 말한 적이 없어요. 대신 리치 결과, 그러니까 별점·FAQ 아코디언·이동 경로·상품 가격 같은 확장 표시는 구조화 데이터가 있어야만 뜰 자격이 생겨요. 순위가 그대로여도 검색 결과에서 차지하는 면적이 커지면 클릭률이 달라지고, 그 결과 트래픽이 늘어나는 구조예요.

블로그 운영자 입장에서 현실적인 기대치는 이 정도예요. 이동 경로(BreadcrumbList)는 비교적 잘 노출되고, 저자·발행일이 담긴 Article은 뉴스나 정보성 결과에서 도움이 되고, FAQ는 정책 변화에 따라 노출이 줄었다 늘었다 해요. 그러니 붙였다고 다음 날 별점이 뜨진 않아요. 자격을 갖추는 일이지 보장이 아니에요.

구조화 데이터 3형식 비교: JSON-LD를 권하는 이유

구조화 데이터를 적는 방법은 크게 세 가지예요. 마이크로데이터, RDFa, 그리고 JSON-LD요. 셋 다 schema.org라는 같은 사전을 쓰지만 적는 위치가 완전히 달라요.

차이를 한 장면으로 그려볼게요. 마이크로데이터는 상품 페이지의 가격 태그 안에 직접 표시를 붙이는 방식이에요. 그런데 테마를 바꾸거나 레이아웃을 손보면 그 태그가 통째로 사라지면서 마크업도 같이 날아가요. 실제로 오래된 워드프레스 테마를 교체한 뒤 서치콘솔 향상 보고서에서 항목이 사라지는 일이 이 이유로 자주 생겨요.

JSON-LD는 반대예요. 본문과 완전히 분리된 한 덩어리라서 디자인을 아무리 바꿔도 영향이 없어요. 대신 본문 내용이 바뀌었는데 JSON-LD를 안 고치면 실제 페이지와 신고 내용이 어긋나는 문제가 생겨요. 이건 뒤에서 다룰 검증 단계에서 잡아야 해요.

오픈그래프(og: 태그)와 헷갈리는 경우도 많은데, 성격이 달라요. 오픈그래프는 카카오톡·페이스북 같은 SNS에서 링크를 붙였을 때 뜨는 미리보기용이고, JSON-LD는 검색엔진과 AI가 내용을 이해하는 용도예요. 둘은 충돌하지 않으니 같이 쓰면 돼요.

레고 블록처럼 뜯어보는 JSON-LD 문법

중괄호가 겹쳐 있는 코드를 보면 겁부터 나는데, 실제로 외울 건 세 개뿐이에요. 사전 지정, 종류 지정, 그리고 속성이요.

최소 예제를 보면 감이 잡혀요. 아래가 블로그 글 하나를 설명하는 가장 짧은 형태예요.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "JSON-LD 형식 입문",
  "datePublished": "2026-08-31",
  "author": {
    "@type": "Person",
    "name": "VIBEPRESS"
  }
}
</script>

중괄호를 읽는 법은 간단해요. 여는 중괄호 하나가 대상 하나를 뜻해요. author 값이 중괄호로 다시 열린 건 저자가 이름 하나짜리 글자가 아니라 사람이라는 대상이기 때문이에요. 대괄호는 여러 개를 나열할 때 써요. FAQ 질문 다섯 개를 담을 때가 대표적이죠.

초보자가 가장 많이 겪는 문법 사고는 세 가지로 압축돼요. 첫째, 마지막 항목 뒤에 쉼표를 남겨두는 것. JSON은 후행 쉼표를 허용하지 않아서 그 순간 전체가 무효 처리돼요. 둘째, 워드프레스 에디터가 큰따옴표를 곡선 따옴표로 자동 변환하는 것. 눈으로는 구분이 안 되는데 파싱은 실패해요. 셋째, 날짜를 2026년 8월 31일처럼 한글로 쓰는 것인데, ISO 8601 형식(2026-08-31)이어야 인식돼요.

어디에 넣어야 할까: script 태그 위치와 다중 삽입

코드는 항상 <script type="application/ld+json">로 감싸요. 이 type 값이 브라우저에게 이건 실행할 자바스크립트가 아니라 데이터 덩어리라고 알려주는 표시예요. 그래서 화면에는 아무것도 안 나오고 크롤러만 읽어요.

위치는 head와 body 어디든 됩니다. 구글은 두 곳 모두 인식한다고 문서에 명시하고 있어요. 다만 관리 편의를 생각하면 head에 모아두는 편이 낫고, 글마다 다른 내용이 들어가야 하는 Article은 본문 하단에 자동 삽입되게 만드는 경우도 많아요.

한 페이지에 여러 개를 넣어도 문제없어요. 예를 들어 이동 경로용 BreadcrumbList 하나, 글 정보용 Article 하나, 질문 목록용 FAQPage 하나를 각각 별도 script 블록으로 넣는 방식이 흔해요. 크롤러는 페이지 안의 모든 ld+json 블록을 읽어서 합쳐 해석해요.

블록이 많아져 관리가 번거로우면 @graph를 써서 하나로 묶을 수 있어요. 대괄호 안에 여러 대상을 나열하는 방식이고, 각 대상에 @id를 붙여 서로 참조하게 만들 수도 있어요. Rank Math 같은 플러그인이 만들어내는 코드를 열어보면 대부분 이 @graph 구조예요. 여기서 @id는 이 조각의 고유 주소표 정도로 이해하면 충분해요. 예를 들어 저자 정보를 한 번만 적어두고 여러 글에서 그 주소를 가리키게 하는 식이죠.

중요한 원칙 하나는 페이지에 실제로 없는 내용을 신고하면 안 된다는 거예요. 화면에 보이지 않는 FAQ를 FAQPage로 마크업하거나, 받지도 않은 리뷰 별점을 넣는 건 구조화 데이터 정책 위반이라 수동 조치 대상이 될 수 있어요. 리치 결과가 안 뜨는 정도가 아니라 사이트 전체 신뢰도에 영향을 줄 수 있는 부분이에요.

블로그 글에 바로 쓰는 타입별 코드 템플릿

페이지 유형별로 어떤 @type을 고를지부터 정리할게요. 여기서 잘못 고르면 뒤 작업이 전부 헛돌아요.

가장 수요가 많은 두 가지 템플릿을 실제 코드로 볼게요. 먼저 이동 경로예요. 애드센스 준비 단계의 블로그라면 이것부터 붙이는 게 효율이 좋아요. 구조가 단순하고 노출도 비교적 잘 되거든요.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "홈",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "워드프레스",
      "item": "https://example.com/wordpress/"
    }
  ]
}

다음은 FAQPage예요. 조건이 하나 있어요. 여기 적는 질문과 답이 페이지 화면에도 그대로 보여야 해요. 안 보이는 내용을 넣으면 정책 위반이에요.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "JSON-LD는 어디에 넣나요?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "head 또는 body 안의 script 태그에 넣으면 됩니다."
      }
    }
  ]
}

템플릿을 고칠 때 주소는 반드시 실제 접속되는 전체 URL로 바꿔야 해요. example.com을 그대로 두거나 슬래시로 시작하는 상대 경로를 쓰면 검증 도구에서 잡히거나, 잡히지 않고 조용히 무시되기도 해요. 이미지 URL도 마찬가지고요.

Claude Code에게 JSON-LD를 맡겼다면 확인할 것들

JSON-LD는 AI 코딩 도구에게 맡기기 딱 좋은 작업이에요. 규칙이 명확하고 정답 구조가 정해져 있으니까요. 다만 그대로 믿고 붙이면 곤란한 지점들이 있어요.

먼저 요청하는 방법이에요. 그냥 JSON-LD 만들어줘라고 하면 일반적인 예제만 돌아와요. 실제 페이지 정보를 함께 주는 게 핵심이에요. 이런 형태로 요청하면 결과가 훨씬 정확해요.

아래 정보로 schema.org 기준 JSON-LD를 만들어줘.
- 타입: BlogPosting
- 제목: (실제 글 제목)
- URL: (실제 전체 주소)
- 발행일: 2026-08-31 (ISO 8601)
- 저자: VIBEPRESS (Person)
- 대표 이미지 URL: (실제 주소)
조건:
1. 구글 리치 결과 필수 속성만 남기고 불필요한 속성은 빼줘
2. 값이 확실하지 않은 속성은 임의로 만들지 말고 비워둔 채 표시해줘
3. script type=application/ld+json 태그까지 포함해서 줘

2번 조건이 특히 중요해요. AI는 빈칸을 싫어해서 없는 값을 그럴듯하게 채워 넣는 경향이 있어요. 존재하지 않는 로고 주소, 실제로 받은 적 없는 aggregateRating 별점, 임의로 지어낸 발행일 같은 것들이요. 별점을 가짜로 넣는 건 명백한 정책 위반이라 반드시 지워야 해요.

또 하나 자주 나오는 패턴은 오래된 스펙을 쓰는 거예요. 구글의 구조화 데이터 정책은 계속 바뀌어서, 예전에는 필수였던 속성이 지금은 무시되거나 반대로 새 요구사항이 생기기도 해요. AI가 학습 시점 기준으로 답하는 만큼, 만들어진 코드는 반드시 리치 결과 테스트를 한 번 거쳐야 해요. 필수 속성 목록은 구글 검색 센터 문서에서 해당 타입 페이지를 직접 확인하는 게 정확해요.

붙인 다음 화면이 깨졌다면 대개 script 태그가 제대로 닫히지 않았거나, 테마 편집 중 다른 코드 사이에 들어간 경우예요. 이럴 땐 AI에게 전체 코드를 그대로 보여주고 어디가 잘못됐는지 물어보면 빠르게 잡혀요.

워드프레스에서 Rank Math와 겹치지 않게 정리하기

워드프레스를 쓴다면 손대기 전에 확인할 게 있어요. Rank Math나 Yoast 같은 SEO 플러그인이 이미 JSON-LD를 자동으로 넣고 있을 가능성이 아주 높거든요. 모르고 같은 타입을 하나 더 붙이면 한 페이지에 Article이 두 개, Organization이 두 개가 되는 상황이 생겨요.

중복이 무조건 오류로 뜨진 않아요. 다만 서로 다른 값이 들어 있으면 검색엔진이 어느 쪽을 믿어야 할지 모호해지고, 향상 보고서에서 예상과 다른 항목이 잡히기도 해요. 그래서 순서는 이렇게 잡는 게 깔끔해요.

수동 삽입 방법도 몇 가지 중에 고를 수 있어요. 특정 글 하나에만 넣는다면 구텐베르크의 커스텀 HTML 블록이 가장 간단해요. 사이트 전체 공통 정보라면 헤더·푸터 스크립트 삽입 플러그인을 쓰거나, 자식 테마의 functions.php에 wp_head 훅으로 출력하는 방식이 안정적이에요. 부모 테마 파일을 직접 고치면 테마 업데이트 때 날아가니 자식 테마를 쓰는 게 맞아요.

티스토리나 블로그스팟처럼 서버 파일에 접근할 수 없는 플랫폼도 방법은 있어요. 스킨 편집의 HTML 영역에서 head 안에 script를 추가하면 되고, 글마다 다른 값이 필요한 부분은 플랫폼이 제공하는 치환자 변수를 활용하면 돼요.

리치 결과 테스트로 검증하고 오류 잡기

붙였으면 반드시 검증해야 해요. 코드가 눈으로 멀쩡해 보여도 쉼표 하나에 통째로 무시되는 게 JSON이거든요. 검증 도구는 성격에 따라 세 가지를 나눠 써요.

여기서 자주 나오는 메시지를 해석하는 법이 중요해요. 결과는 크게 오류와 경고로 나뉘는데 대응이 달라요.

• 오류(빨강) — 필수 속성이 없다는 뜻이에요. 이 상태면 리치 결과 자격 자체가 없으니 반드시 고쳐야 해요. Product에 price가 빠졌거나 offers 자체가 없는 경우가 대표적이에요.
• 경고(노랑) — 있으면 더 좋은 권장 속성이 빠진 상태예요. 리치 결과는 뜰 수 있어요. image나 aggregateRating 같은 항목이 여기 잡히는데, 실제로 없는 값이라면 무시해도 됩니다.
• 구문 분석 오류 — 코드 자체를 못 읽었다는 뜻이에요. 후행 쉼표, 곡선 따옴표, 닫히지 않은 중괄호가 원인의 대부분이에요.
• 감지된 항목 없음 — 코드가 페이지에 출력조차 안 되고 있어요. 캐시 플러그인이 예전 버전을 서빙하고 있을 수 있으니 캐시를 비우고 다시 확인해보세요.

효과 측정은 서치콘솔 실적 보고서에서 해요. 적용 전후 4주씩 끊어서 같은 페이지의 노출수와 클릭률을 비교하면 흐름이 보여요. 다만 순위 변동이나 계절 요인이 섞이니 하루 이틀 차이로 판단하지 말고 최소 2~4주 단위로 보는 게 맞아요. 그리고 URL 검사 도구로 색인 재요청을 해두면 반영이 빨라져요.

네이버와 AI 검색까지, GEO에서 중요해진 이유

국내 블로그 운영자라면 네이버는 어떤지 궁금할 거예요. 네이버 서치어드바이저도 구조화 데이터 문서를 제공하고 있고, JSON-LD 형식을 인식해요. 다만 노출되는 리치 결과의 형태와 지원 범위가 구글과 달라서, 구글 기준으로 만들었다고 네이버에서 똑같이 보인다고 기대하면 안 돼요. 서치어드바이저에 사이트를 등록해두고 그쪽 가이드를 별도로 확인하는 게 정확해요.

요즘 더 주목받는 건 GEO, 생성형 엔진 최적화 쪽 맥락이에요. AI가 답변을 만들 때 웹 문서를 읽는데, 본문 글만 읽으면 저자가 누구인지 언제 쓴 글인지 어떤 주제인지 추론해야 해요. JSON-LD가 있으면 그 정보가 이미 정리된 형태로 놓여 있죠. 사람이 읽을 글 옆에 기계용 요약본을 나란히 두는 셈이에요.

그래서 저자 정보(author), 발행·수정일(datePublished, dateModified), 발행 주체(publisher)를 채워두는 게 예전보다 의미가 커졌어요. 정보의 출처와 최신성을 판단하는 근거가 되니까요. 애드센스 준비 중인 블로그라면 이 세 가지만 정확히 넣어도 기본은 갖춘 거예요.

마지막으로 렌더링 이슈 하나. Next.js나 React 같은 방식으로 만든 사이트에서 자바스크립트로 JSON-LD를 나중에 그려 넣으면, 크롤러가 그 시점 전에 페이지를 읽고 지나가면서 인식이 안 될 수 있어요. 워드프레스는 서버에서 HTML을 완성해 보내니 이 문제가 거의 없지만, Claude Code로 직접 만든 랜딩페이지나 포트폴리오 사이트라면 확인이 필요해요. 페이지 소스 보기에서 ld+json이 보이면 정상이고, 안 보이는데 개발자 도구에서만 보인다면 서버에서 미리 넣는 방식으로 바꿔야 해요.

자주 묻는 질문

JSON-LD를 넣으면 검색 순위가 올라가나요?

직접적인 순위 상승 효과는 없어요. 구글은 구조화 데이터를 랭킹 요소로 공식화한 적이 없어요. 대신 리치 결과로 노출될 자격이 생기고, 검색 결과에서 눈에 띄는 면적이 커지면서 클릭률이 개선되는 간접 효과를 기대하는 거예요.

head와 body 중 어디에 넣어야 하나요?

둘 다 가능해요. 구글은 두 위치 모두 인식한다고 문서에 명시하고 있어요. 관리 편의상 사이트 공통 정보는 head에, 글마다 달라지는 정보는 본문 영역에 자동 출력되게 두는 구성이 일반적이에요.

한 페이지에 JSON-LD를 여러 개 넣어도 되나요?

넣어도 됩니다. 크롤러는 페이지 안의 모든 ld+json 블록을 읽어요. 다만 같은 타입을 서로 다른 값으로 중복해서 넣는 건 피하는 게 좋고, 블록이 많아지면 @graph로 묶어 관리하는 편이 깔끔해요.

Rank Math를 쓰는데 JSON-LD를 따로 넣어야 하나요?

대부분은 안 넣어도 돼요. Rank Math가 Article, BreadcrumbList, WebSite, Organization 등 기본 타입을 이미 출력하고 있어요. 먼저 리치 결과 테스트로 현재 감지되는 항목을 확인하고, 거기에 없는 특수 타입만 수동으로 추가하세요.

코드를 붙였는데 검증 도구에서 아무것도 안 잡혀요.

세 가지를 순서대로 확인하세요. 첫째 페이지 소스 보기에서 ld+json이 실제로 출력되는지, 둘째 캐시 플러그인이 예전 버전을 보여주는 건 아닌지, 셋째 후행 쉼표나 곡선 따옴표로 구문 분석이 실패한 건 아닌지요. 대부분 이 셋 중 하나예요.

참고자료

• Google 검색 센터 — 구조화된 데이터 마크업 작동 방식: 타입별 필수·권장 속성과 정책 원문을 확인할 수 있어요.
• 리치 결과 테스트: URL 또는 코드를 붙여넣어 구글이 인식하는지 바로 확인하는 도구예요.
• Schema Markup Validator: schema.org 문법 자체의 유효성을 검사해요.
• 네이버 서치어드바이저 웹마스터 가이드: 국내 포털의 구조화 데이터 지원 범위를 확인할 수 있어요.

중괄호가 겹친 코드 앞에서 막막했던 마음이 조금은 가벼워졌길 바라요. 결국 JSON-LD는 사전 이름 한 줄, 페이지 종류 한 줄, 그리고 속성 몇 개가 전부거든요. 순위를 올려주는 마법은 아니지만, 검색엔진과 AI에게 내 글을 정확히 설명해두는 최소한의 예의 같은 작업이에요. 시작 순서는 이렇게 잡길 권해요. 먼저 리치 결과 테스트로 지금 내 사이트에 뭐가 들어가 있는지 확인하고, Rank Math가 이미 처리하는 부분은 그대로 두고, 빠진 것만 하나씩 추가한 뒤 반드시 검증하는 거예요. 처음 붙인 코드가 한 번에 통과하는 경우는 드물어요. 쉼표 하나, 따옴표 하나 때문에 몇 번 되돌아가는 게 정상이고, 그 과정을 한 번 겪고 나면 다음 글부터는 템플릿 복사에 5분이면 끝나요.

함께 보면 좋은 글

• 워드프레스 호스팅, 다들 월 요금만 보는데 진짜 갈림길은 따로 있어요
• CSS 선택자 총정리, “이 버튼만 바꿔줘”가 사이트 전체를 바꾼 이유
• 웹호스팅 종류 4가지 비교, 첫 워드프레스 블로그엔 뭐가 맞을까?