JSON-LD 구조화 데이터로 검색 노출 보강하기
기술 블로그에 BlogPosting JSON-LD를 적용해 검색엔진이 제목, 발행일, 이미지, 작성자 정보를 더 명확히 이해하도록 돕는 방법입니다.
JSON-LD 구조화 데이터는 검색엔진에게 페이지의 의미를 기계가 읽기 쉬운 형식으로 전달하는 방법입니다. 블로그 글이라면 제목, 설명, 발행일, 수정일, 대표 이미지, 작성자, 게시자, canonical URL 같은 정보를 BlogPosting 스키마로 제공할 수 있습니다. 구조화 데이터는 검색 순위를 보장하지 않지만, 검색엔진이 문서를 이해하는 데 도움을 주고, 일부 경우 검색 결과 표현을 더 풍부하게 만드는 기반이 됩니다.
기술 블로그에서는 글 템플릿이 일정하므로 JSON-LD를 한 번 잘 구성해 두면 모든 포스트에 안정적으로 적용할 수 있습니다. 이 글은 서민혁닷컴 같은 정적 블로그에서 JSON-LD를 적용할 때 필요한 필드, 검증 방법, 실무 주의점을 정리합니다.
JSON-LD가 하는 일
HTML 본문은 사람이 읽기 좋은 문서입니다. 검색엔진도 HTML을 해석할 수 있지만, 제목이 무엇인지, 발행일이 어디에 있는지, 대표 이미지가 무엇인지 사이트마다 구조가 다릅니다. JSON-LD는 이런 정보를 표준 어휘인 Schema.org 형식으로 명확히 전달합니다.
블로그 글에는 보통 BlogPosting 또는 Article 타입을 사용합니다. 기술 블로그라면 BlogPosting이 자연스럽고, 조직 블로그라면 publisher 정보를 함께 넣습니다. 중요한 것은 JSON-LD의 값이 실제 페이지 내용과 일치해야 한다는 점입니다.
| 필드 | 의미 | 실무 기준 |
|---|---|---|
headline |
글 제목 | 페이지 H1과 일치 |
description |
글 설명 | 메타 description과 일치 |
datePublished |
발행일 | ISO 형식 권장 |
dateModified |
수정일 | 수정 시 실제 날짜 반영 |
image |
대표 이미지 | 절대 URL 사용 |
author |
작성자 | 개인 또는 조직 |
publisher |
게시자 | 조직명과 URL |
mainEntityOfPage |
대표 페이지 URL | canonical URL과 일치 |
기본 예시
정적 블로그의 글 상세 템플릿에서는 frontmatter 값을 바탕으로 JSON-LD 객체를 만들 수 있습니다. 핵심은 상대 경로를 그대로 넣지 않고 운영 도메인을 붙인 절대 URL로 만드는 것입니다.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "JSON-LD 구조화 데이터로 검색 노출 보강하기",
"description": "기술 블로그에 BlogPosting JSON-LD를 적용하는 방법입니다.",
"datePublished": "2026-07-17T00:00:00.000Z",
"dateModified": "2026-07-17T00:00:00.000Z",
"image": "https://example.com/images/jsonld.svg",
"author": {
"@type": "Organization",
"name": "서민혁닷컴"
},
"publisher": {
"@type": "Organization",
"name": "서민혁닷컴",
"url": "https://example.com"
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://example.com/posts/json-ld-structured-data"
},
"inLanguage": "ko-KR"
}실제 구현에서는 예시 값을 하드코딩하지 말고 글 데이터에서 가져와야 합니다. 제목이나 대표 이미지가 바뀌었는데 JSON-LD만 예전 값이면 신뢰도가 떨어집니다. 정적 사이트 생성기의 템플릿에서 자동 생성하는 방식이 가장 안전합니다.
적용 위치와 형식
JSON-LD는 보통 HTML의 <head> 영역에 다음처럼 넣습니다.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting"
}
</script>프레임워크에 따라 JSON 문자열을 안전하게 삽입하는 방식이 다릅니다. 따옴표 escaping이 깨지거나, 객체가 [object Object]로 출력되거나, 여러 글에서 같은 JSON-LD가 반복되지 않도록 주의해야 합니다. 빌드 결과 HTML을 직접 열어 구조화 데이터 스크립트가 정상 JSON인지 확인하는 것이 좋습니다.
sitemap, robots, 색인 요청과 함께 보기
JSON-LD는 페이지 의미를 설명하지만 URL 발견을 대신하지 않습니다. 검색엔진이 페이지를 찾으려면 내부 링크와 sitemap이 필요하고, robots.txt가 차단하지 않아야 합니다. 따라서 robots.txt와 sitemap.xml 올바르게 쓰는 법을 먼저 정리한 뒤 JSON-LD를 적용하는 흐름이 좋습니다.
새 글을 발행한 뒤에는 Google Search Console에서 색인 요청하는 방법에 따라 URL 검사를 실행하고, 실제 URL 테스트에서 구조화 데이터 오류가 없는지도 함께 확인할 수 있습니다. Search Console의 URL 검사 결과는 색인 가능성, 크롤링 상태, 모바일 사용성까지 연결해서 볼 수 있어 실무 점검에 유용합니다.
검증 도구
구조화 데이터는 눈에 보이지 않는 데이터이므로 검증 도구를 사용해야 합니다. Google Rich Results Test와 Schema Markup Validator를 활용하면 JSON 문법 오류, 필수 또는 권장 필드 누락, URL 형식 문제를 확인할 수 있습니다. 단, 모든 권장 경고를 반드시 해결해야 하는 것은 아닙니다. 사이트 목적에 맞는 필드를 정확히 제공하는 것이 우선입니다.
검증할 때는 운영 URL과 빌드된 HTML을 모두 확인하세요. 개발 서버에서는 잘 보이지만 운영 도메인의 환경 변수, base URL, canonical 설정이 달라져 오류가 날 수 있습니다.
| 검증 항목 | 확인 내용 |
|---|---|
| JSON 문법 | 쉼표, 따옴표, escaping 오류 |
| 절대 URL | image, mainEntityOfPage가 운영 도메인인지 |
| 날짜 형식 | ISO 형식과 실제 발행일 일치 |
| 내용 일치 | headline, description이 페이지와 같은지 |
| 중복 스크립트 | 같은 BlogPosting이 여러 번 출력되지 않는지 |
접근성과 콘텐츠 품질이 먼저다
구조화 데이터만 잘 넣는다고 좋은 검색 경험이 만들어지지는 않습니다. 실제 페이지의 제목 구조, 이미지 ALT, 링크 문구, 본문 품질이 먼저입니다. JSON-LD는 이미 좋은 문서를 검색엔진이 더 잘 이해하도록 보강하는 역할입니다. 기본 문서 구조는 웹 접근성 기본 — 제목·ALT·대비를 참고해 점검하세요.
특히 headline과 H1이 다르거나, description이 실제 본문과 맞지 않거나, image가 깨진 URL이면 구조화 데이터가 오히려 신뢰를 해칠 수 있습니다. 사람이 보는 화면과 기계가 읽는 데이터가 같은 이야기를 해야 합니다.
실무 체크리스트
- 모든 글 상세 페이지에 BlogPosting JSON-LD가 있는가?
- headline이 글 제목과 일치하는가?
- description이 메타 설명과 일치하는가?
- datePublished와 dateModified가 올바른가?
- image가 운영 도메인의 절대 URL인가?
- author와 publisher 타입이 사이트 운영 주체와 맞는가?
- mainEntityOfPage가 canonical URL과 일치하는가?
- inLanguage가
ko-KR로 설정되어 있는가? - 빌드 결과 HTML에서 JSON 문법이 깨지지 않았는가?
- 검증 도구에서 치명적인 오류가 없는가?
실무 주의점
첫째, 없는 정보를 구조화 데이터에 넣지 마세요. 실제 페이지에 보이지 않는 리뷰 점수, 평점, FAQ를 검색 노출 목적으로만 추가하는 것은 위험합니다. 구조화 데이터는 페이지에 존재하는 정보를 명확히 표현해야 합니다.
둘째, 도메인 이전이나 이미지 경로 변경 시 JSON-LD도 함께 바뀌어야 합니다. sitemap과 canonical은 새 도메인인데 JSON-LD image만 예전 도메인을 가리키면 데이터 일관성이 깨집니다.
셋째, 날짜를 자동으로 현재 시간으로 덮어쓰지 마세요. 글을 수정하지 않았는데 매 빌드마다 dateModified가 바뀌면 검색엔진과 독자에게 잘못된 신호를 줄 수 있습니다. 실제 내용 변경이 있을 때만 수정일을 갱신하는 운영 규칙이 필요합니다.
넷째, 여러 템플릿에서 구조화 데이터를 중복 생성하지 않도록 주의하세요. 공통 레이아웃과 글 상세 컴포넌트가 각각 JSON-LD를 출력하면 한 페이지에 서로 다른 값의 BlogPosting이 두 번 들어갈 수 있습니다. 검색엔진이 반드시 오류로 처리하지 않더라도 데이터 해석이 불명확해집니다. 빌드된 HTML에서 application/ld+json 스크립트 개수와 내용을 확인하고, 사이트 전체 공통 데이터와 글 단위 데이터를 역할별로 분리해 관리하세요.
마지막으로 JSON-LD는 SEO 작업의 끝이 아니라 기본 위생 관리에 가깝습니다. 명확한 콘텐츠, 안정적인 URL, 빠른 로딩, 접근성, 내부 링크가 함께 갖춰졌을 때 구조화 데이터가 제 역할을 합니다.