2026년 5월 7일, 구글이 FAQ 리치 결과를 완전히 폐지했습니다. 정부·의료기관 사이트에만 남아있던 마지막 예외까지 없어진 거죠. 그런데 재밌는 건, 같은 시기에 SEO 커뮤니티에서는 "JSON-LD를 더 신경 써야 한다"는 얘기가 오히려 많아지고 있다는 점입니다. 도대체 무슨 일이 벌어지고 있는 걸까요? 이 글에서는 JSON-LD가 정확히 무엇인지부터, 2026년 현재 기준으로 꼭 챙겨야 할 실전 코드, 그리고 흔히 저지르는 실수까지 한 번에 정리합니다. 코드는 전부 그대로 복사해서 도메인만 바꿔 써도 되는 수준으로 준비했으니, 필요한 부분만 골라 읽어도 충분합니다. (참고로 이 글 자체도 머리부터 발끝까지 JSON-LD로 마크업되어 있습니다 😄)
JSON-LD, 정확히 뭔가요?
JSON-LD는 "JavaScript Object Notation for Linked Data"의 줄임말입니다. 이름은 복잡해 보이지만 개념은 단순합니다. 우리가 평소에 쓰는 JSON 형식에 "이 데이터가 무엇을 의미하는지" 알려주는 어휘(schema.org)를 더한 것뿐이에요. 비유를 하나 들어볼게요. 사람이 명함을 받으면 이름, 직함, 회사를 한눈에 구분할 수 있습니다. 글씨체와 배치, 상식으로 "이건 이름이고, 이건 직함이구나"를 알아채는 거죠. 그런데 컴퓨터는 그런 직관이 없습니다. HTML 페이지를 보고 "이게 글쓴이 이름인지, 그냥 본문 텍스트인지" 구분하지 못해요. JSON-LD는 바로 이 명함에 라벨을 붙여주는 역할을 합니다.
기술적으로는 <script type="application/ld+json"> 태그 안에 들어가는 별도의 데이터 블록입니다. 화면에 보이는 HTML과는 완전히 분리되어 있어서, 페이지 디자인이 어떻게 바뀌든 구조화 데이터만 따로 관리할 수 있다는 장점이 있습니다. 재미있는 점은, 이 스크립트 블록이 실제로는 자바스크립트로 '실행'되지 않는다는 사실입니다. type="application/ld+json"이라는 속성값 때문에 브라우저는 이 안의 내용을 그냥 무시하고 지나갑니다. 오직 검색엔진 크롤러와 AI 크롤러만 이 블록을 파싱해서 읽어갑니다. 그러니 사용자 경험이나 페이지 로딩 속도에는 거의 영향이 없다고 봐도 무방합니다.
같은 schema.org 어휘를 표현하는 방식은 Microdata, RDFa 등 세 가지가 더 있지만, 신규 사이트라면 굳이 다른 방식을 고민할 필요가 없습니다. Microdata는 HTML 태그 속성(itemscope, itemprop 같은 것들) 안에 직접 의미를 끼워 넣는 방식이라, 디자인이 바뀔 때마다 구조화 데이터도 같이 손봐야 하는 번거로움이 있습니다. RDFa도 비슷한 한계가 있고요. 구글은 2026년 2월 공식 문서를 통해 "JSON-LD를 추천하는 이유는 웹사이트 운영자가 구현하고 유지보수하기 가장 쉽기 때문"이라고 명확히 밝혔습니다. 세 가지 형식 모두 올바르게 구현했다면 구글 입장에서는 동등하게 유효하지만, 실무적으로는 JSON-LD가 압도적으로 편합니다. 리액트나 뷰 같은 컴포넌트 기반 프레임워크를 쓰는 경우라면 더더욱 그렇습니다. 구조화 데이터를 그냥 하나의 데이터 객체로 다루고, 컴포넌트가 렌더링될 때 통째로 출력하면 끝이거든요.
여기서 잠깐 schema.org 자체에 대해서도 짚어볼 필요가 있습니다. schema.org는 2011년 구글, 마이크로소프트, 야후, 얀덱스가 공동으로 만든 어휘 표준입니다. "사람", "장소", "이벤트", "글", "제품" 같은 개념들을 모두가 똑같은 방식으로 표현하자는 약속인 셈이죠. JSON-LD는 이 schema.org 어휘를 JSON 문법으로 담는 '그릇'이고, schema.org는 그 그릇 안에 무엇을 어떻게 적을지 정의한 '사전'입니다. 이 둘을 헷갈려서 "JSON-LD 타입이 800개나 된다"고 말하는 경우가 있는데, 정확히는 schema.org에 정의된 타입이 800개가 넘는 것이고 JSON-LD는 그걸 표현하는 형식 중 하나일 뿐입니다.
JSON-LD라는 이름의 'LD'는 'Linked Data'를 뜻합니다. 이 개념은 월드와이드웹의 창시자인 팀 버너스리가 2000년대 초반부터 주창한 '시맨틱 웹(Semantic Web)'이라는 더 큰 비전에서 나왔습니다. 핵심 아이디어는 단순합니다. 웹페이지가 서로 하이퍼링크로 연결되어 있는 것처럼, 데이터도 서로 의미를 가지고 연결되어야 한다는 거예요. 한 사이트의 "저자"가 다른 사이트의 "같은 저자"와 연결되고, 한 제품이 다른 사이트의 같은 제품과 연결되는 식으로요. 거의 20년 전 비전이 2026년 AI 검색 시대에 와서야 비로소 실용적인 형태로 완성되어가고 있다는 점이 개인적으로는 꽤 흥미롭습니다.
"구조화 데이터는 순위를 직접 올려주는 요소가 아닙니다. 검색엔진이 콘텐츠를 더 정확히 이해하도록 돕고, 그 결과로 더 풍부한 검색 결과를 보여줄 기회를 여는 도구입니다." – 구글 서치 센트럴 공식 가이드라인 요지
여기서 중요한 오해 하나를 짚고 가야 합니다. "JSON-LD를 넣으면 순위가 오른다"는 말은 정확하지 않습니다. 구글은 구조화 데이터가 직접적인 랭킹 요소가 아니라고 여러 차례 공식적으로 밝혔습니다. 하지만 간접적인 영향은 분명히 존재합니다. 리치 스니펫으로 클릭률이 올라가고, 엔티티(브랜드·인물·장소 등)가 명확하게 식별되면서 신뢰도 신호가 강화되고, 무엇보다 2026년 현재는 AI 검색 결과에 인용될 확률에까지 영향을 미칩니다. 순위를 올려주는 마법 지팡이는 아니지만, 안 챙기면 손해를 보는 기초 체력 같은 거예요. 비유하자면 운동선수의 기초 체력 훈련과 비슷합니다. 기초 체력만으로 메달을 따지는 못하지만, 기초 체력 없이는 어떤 화려한 기술도 오래 버티지 못하죠.
알아두면 좋은 용어 정리 — 엔티티(Entity): 사람·브랜드·장소처럼 검색엔진이 하나의 고유한 '대상'으로 인식하는 단위. 지식 그래프(Knowledge Graph): 이런 엔티티들과 그 관계를 구글이 정리해둔 거대한 데이터베이스. 리치 결과(Rich Result): 별점·이미지·드롭다운처럼 일반 텍스트 링크보다 풍성하게 표시되는 검색 결과. GEO(Generative Engine Optimization): 전통적인 검색 순위가 아니라 AI가 생성하는 답변에 인용되는 것을 목표로 하는 최적화 방식.
2026년에 더 중요해진 이유: AI 검색
예전에는 JSON-LD를 챙기는 이유가 거의 "리치 스니펫(별점, 빵 부스러기, FAQ 드롭다운 같은 것들)" 하나였습니다. 그런데 흐름이 완전히 바뀌었습니다. 구글 AI 오버뷰, AI 모드는 물론이고 ChatGPT, Perplexity, Gemini, Claude 같은 생성형 AI 검색 도구들이 답변을 만들 때 어떤 페이지를 인용할지 결정해야 하는데, 이때 JSON-LD가 "신뢰할 수 있는 출처 정보"를 가장 빠르게 전달하는 통로 역할을 합니다.
각 플랫폼이 구조화 데이터를 정확히 똑같은 방식으로 쓰는 건 아닙니다. 구글 AI 오버뷰와 AI 모드는 자체 지식 그래프와 색인 데이터를 함께 활용하기 때문에, sameAs로 연결된 엔티티 정보가 특히 중요합니다. ChatGPT는 웹 브라우징 기능을 쓸 때 실시간으로 페이지를 가져와 파싱하는데, 이때 본문보다 구조화 데이터에서 발행일·저자 정보를 먼저 확인하는 경향이 있다는 보고가 여럿 있습니다. Perplexity는 답변마다 출처 카드를 붙여주는 방식이라, 명확한 publisher·author 정보가 있는 페이지일수록 그 출처 카드에 "신뢰할 수 있는 출처처럼" 표시되기 유리합니다. 이런 차이는 있어도, 공통된 본질은 하나입니다. AI가 콘텐츠의 '신원'을 빠르게 확인할 수 있게 도와주는 정보일수록 인용 우선순위에서 앞서나간다는 점이에요.
생각해보면 당연한 이야기입니다. AI가 어떤 글을 인용하려면 "이 글을 누가 썼는지, 어떤 조직이 발행했는지, 언제 작성됐는지"를 빠르게 확인해야 합니다. 본문 텍스트만 보고 이걸 추론하는 것보다, 구조화된 author·publisher·datePublished 필드를 읽는 게 훨씬 빠르고 정확하죠. Organization과 Person 스키마에 sameAs 속성으로 공식 SNS나 위키 링크를 붙여두면, AI 시스템이 "이 브랜드를 다른 동명의 사이트와 혼동하지 않고" 지식 그래프 상의 정확한 엔티티로 연결할 수 있습니다. 예를 들어 동명의 개인 블로거가 여러 명 있는 흔한 이름이라면, sameAs에 깃허브나 링크드인처럼 본인 소유가 명확한 프로필을 걸어두는 것만으로도 "이 글의 저자는 다른 동명인이 아니라 바로 이 사람"이라는 신호를 강하게 줄 수 있습니다.
조금 더 구체적인 상황을 가정해볼게요. 만약 흔한 이름의 블로거가 "여행 후기"를 쓰는데, 같은 이름을 쓰는 다른 인물이 마침 다른 분야의 유명인이라면 어떨까요? sameAs 없이 이름만 author로 적어두면, AI 시스템이 두 사람을 같은 엔티티로 잘못 합쳐버릴 위험이 있습니다. 반면 author.sameAs에 본인의 깃허브·인스타그램·개인 사이트 링크를 걸어두면, "이름은 같지만 전혀 다른 사람"이라는 걸 시스템이 구분할 근거가 생깁니다. 이게 바로 엔티티 명확화(entity disambiguation)이고, 구조화 데이터가 실질적으로 풀어주는 문제 중 하나입니다.
이 흐름은 구글이 오래전부터 강조해온 E-E-A-T(경험·전문성·권위성·신뢰성) 개념과도 자연스럽게 맞물립니다. E-E-A-T 자체는 스키마 속성이 아니라 콘텐츠 품질에 대한 평가 철학이지만, author·publisher·sameAs 같은 구조화 데이터 필드는 그 철학을 기계가 읽을 수 있는 형태로 바꿔주는 다리 역할을 합니다. "이 글을 누가, 어떤 자격으로 썼는가"를 사람이 읽고 판단하던 것을, 구조화 데이터는 AI가 같은 판단을 더 빠르게 내릴 수 있도록 도와주는 셈입니다.
물론 여기서 소개되는 수치들은 출처마다 차이가 커서 곧이곧대로 믿기보다는 참고용으로만 보는 게 좋습니다. 일부 SEO 블로그에서는 "AI 오버뷰가 미국 검색의 절반 이상에서 노출된다"거나 "FAQ 스키마가 있는 페이지가 AI 오버뷰에 인용될 확률이 몇 배 더 높다"는 식의 통계를 자주 언급합니다. 출처와 측정 방식이 제각각이라 정확한 숫자로 받아들이긴 어렵지만, 방향성 자체는 업계에서 폭넓게 동의하는 분위기입니다. 구조화 데이터가 없는 페이지보다 있는 페이지가 AI 인용에서 유리하다는 큰 흐름은 분명해 보입니다. 다만 한 가지는 구글이 명확하게 선을 그었습니다. AI 오버뷰나 AI 모드를 위한 '전용 스키마'는 따로 존재하지 않는다는 점입니다. 화면에 보이는 콘텐츠를 명확하게 구조화하는 것이 곧 AI 최적화이기도 한 셈이죠. 특별한 비밀 마크업을 찾아다닐 필요가 없다는 뜻이라 오히려 마음이 편해지는 부분입니다.
실제로 GEO(Generative Engine Optimization)라는 용어도 이런 흐름 속에서 자리를 잡았습니다. 전통적인 SEO가 "검색 결과 1페이지에 내 링크가 뜨게 만드는 것"이었다면, GEO는 "AI가 답변을 생성할 때 내 콘텐츠를 출처로 골라 쓰게 만드는 것"에 가깝습니다. 두 목표가 완전히 다른 건 아니지만, 우선순위가 조금씩 달라집니다. 명확한 정의, 직접적인 질문-답변 구조, 그리고 신뢰할 수 있는 출처 메타데이터가 GEO 관점에서는 한층 더 중요해집니다. JSON-LD는 바로 이 세 번째, '신뢰할 수 있는 출처 메타데이터'를 가장 효율적으로 전달하는 방법입니다.
핵심 포인트
JSON-LD는 더 이상 "구글 리치 스니펫 전용 도구"가 아닙니다. ChatGPT, Perplexity, Gemini 같은 AI 검색 도구가 콘텐츠의 출처와 신뢰도를 빠르게 판단하는 데 쓰는 핵심 신호로 역할이 확장됐습니다. 다만 마크업이 화면에 보이는 실제 콘텐츠와 일치해야 한다는 원칙은 변함없이 가장 중요합니다.
기본 문법 완전 정복
실제 코드를 보면 훨씬 빨리 이해됩니다. 블로그 글 하나를 예로 들어, 가장 기본적인 BlogPosting 스키마를 작성해보겠습니다. 사실 이 블로그의 모든 글이 정확히 이 구조를 쓰고 있어요.
그 전에 @type으로 뭘 써야 할지 헷갈릴 때가 많은데, Article 계열 타입들을 표로 정리해두면 다음에 글을 쓸 때마다 고민하지 않아도 됩니다.
| 타입 | 적합한 콘텐츠 | 비고 |
|---|---|---|
| Article | 가장 범용적인 글 콘텐츠 | 다른 세부 타입이 애매할 때 기본값으로 무난 |
| BlogPosting | 개인·기업 블로그 포스트 | 이 블로그를 포함한 대부분의 블로그 글에 적합 |
| NewsArticle | 시사·보도성 기사 | 구글 뉴스 관련 기능과 더 밀접하게 연결됨 |
| TechArticle | 기술 문서·튜토리얼 | dependencies, proficiencyLevel 같은 전용 속성 사용 가능 |
이 블로그처럼 일반적인 블로그 포스트라면 BlogPosting을 기본값으로 쓰고, 굳이 더 세분화할 필요를 못 느끼면 Article로 충분합니다. 너무 세부 타입을 고민하느라 시간을 쓰기보다는, 어떤 타입이든 필수 속성을 빠짐없이 정확하게 채우는 데 더 신경 쓰는 게 효율적입니다.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://agmazon.com/blog/articles/technology/202606/json-ld-structured-data-guide.html"
},
"headline": "JSON-LD 완벽 가이드: 2026년 AI 검색 시대 SEO 필수 전략",
"description": "구글이 FAQ 리치 결과를 없앤 2026년, JSON-LD가 왜 더 중요해졌는지 정리한 가이드",
"image": "https://agmazon.com/blog/articles/technology/202606/json-ld-structured-data-guide.webp",
"author": {
"@type": "Person",
"name": "Gardenee",
"url": "https://agmazon.com/"
},
"publisher": {
"@type": "Organization",
"name": "Gardenee Blog",
"logo": {
"@type": "ImageObject",
"url": "https://agmazon.com/background/jennie.png"
}
},
"datePublished": "2026-06-24T12:00:00+09:00",
"dateModified": "2026-06-24T12:00:00+09:00"
}속성 하나씩 짚어볼까요. @context는 "이 문서가 schema.org 어휘를 쓴다"고 선언하는 부분입니다. 거의 항상 고정값이라 외울 필요도 없어요. @type은 이 데이터가 어떤 종류인지를 정의합니다. 글이면 Article이나 BlogPosting, NewsArticle 중 콘텐츠 성격에 맞는 걸 고르면 됩니다. mainEntityOfPage는 이 구조화 데이터가 어떤 페이지를 설명하는지 명시적으로 연결해주는 역할이고, headline과 description은 사람이 읽는 제목·요약과 똑같은 내용을 담아야 합니다. 여기서 본문과 다른 내용을 적으면 구글 가이드라인 위반이니 주의가 필요합니다.
author와 publisher는 AI 인용 시대에 체감상 가장 중요해진 필드입니다. "누가 썼고, 누가 발행했는가"가 명확할수록 신뢰도 신호가 강해집니다. datePublished와 dateModified는 ISO 8601 형식(YYYY-MM-DDTHH:mm:ss+09:00)을 정확히 지켜야 합니다. 날짜를 대충 적거나, 실제로는 수정하지 않았는데 dateModified만 매번 오늘 날짜로 갱신하는 식의 '신선도 어뷰징'은 장기적으로 신뢰를 깎아먹는 행동이니 피하는 게 좋습니다.
author 필드를 좀 더 풍성하게 채우고 싶다면 Person 타입에 sameAs를 추가하는 걸 추천합니다. 이렇게 하면 "이 글쓴이가 인터넷 어딘가에 존재하는 같은 사람"이라는 걸 검색엔진과 AI가 더 쉽게 확인할 수 있습니다.
"author": {
"@type": "Person",
"name": "Gardenee",
"url": "https://agmazon.com/",
"sameAs": [
"https://github.com/unluckysoon"
]
}제목과 이미지에도 알아두면 좋은 실무 규칙이 있습니다. headline은 너무 길면 일부 리치 결과에서 잘려 보일 수 있어서, 보통 110자 이내로 작성하는 걸 권장합니다. image는 가로 1200px 이상의 고해상도 이미지를 권장하며, 가로세로 비율도 다양하게(정사각형, 4:3, 16:9 등) 준비해두면 여러 검색 결과 레이아웃에 대응하기 좋습니다. 대표 이미지 하나만 문자열로 적어도 되지만, 여러 비율을 배열로 함께 적어주는 것도 괜찮은 선택입니다.
마지막으로 실수 하나를 미리 보여드릴게요. 아래는 자주 발생하는 깨진 코드와, 고친 버전을 나란히 비교한 예시입니다. 차이가 어디 있는지 한번 찾아보세요.
흔히 깨지는 코드 — { "name": "Gardenee Blog", "url": "https://agmazon.com/", } 마지막 속성 뒤에 쉼표가 남아있고, 워드프로세서에서 복사한 탓에 따옴표가 둥근 스마트 쿼트(" ")로 바뀌어 있습니다. 이 두 가지만으로도 JSON 파서는 전체 블록을 통째로 무시해버립니다.
고친 코드 — { "name": "Gardenee Blog", "url": "https://agmazon.com/" } 마지막 속성 뒤 쉼표를 지우고, 모든 따옴표를 일반 직선 쌍따옴표(")로 통일했습니다. 코드 에디터가 아닌 워드·노션·메모 앱에서 JSON을 작성했다면 이 두 가지는 꼭 다시 확인해보시길 권합니다.
실전 코드: Organization, Breadcrumb, @graph
블로그 한 개에는 보통 여러 종류의 스키마가 동시에 필요합니다. 글쓴이(Person), 발행 조직(Organization), 현재 위치(BreadcrumbList)가 한 페이지에 다 들어가야 하는 경우가 많죠. 이걸 따로따로 <script> 블록으로 나눠 적으면 같은 정보가 여기저기 중복되고, 나중에 관리하기도 번거로워집니다. 이때 쓰는 게 @graph입니다. 여러 엔티티를 하나의 JSON-LD 블록 안에 선언하고, @id로 서로 참조하게 만드는 방식이에요.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://agmazon.com/#organization",
"name": "Gardenee Blog",
"url": "https://agmazon.com/",
"logo": "https://agmazon.com/background/jennie.png",
"sameAs": [
"https://github.com/unluckysoon"
]
},
{
"@type": "WebSite",
"@id": "https://agmazon.com/#website",
"url": "https://agmazon.com/",
"name": "Gardenee Blog",
"publisher": { "@id": "https://agmazon.com/#organization" }
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Home", "item": "https://agmazon.com/blog/index.html" },
{ "@type": "ListItem", "position": 2, "name": "Technology", "item": "https://agmazon.com/blog/categories.html" },
{ "@type": "ListItem", "position": 3, "name": "JSON-LD 완벽 가이드" }
]
}
]
}이 방식의 장점은 명확합니다. publisher 정보를 한 번만 선언하고, 다른 모든 곳에서는 @id로 참조만 하면 됩니다. 회사 로고나 이름이 바뀌었을 때 수정할 곳이 한 곳으로 줄어드는 셈이죠. 사이트 전역에서 똑같이 쓰는 Organization, WebSite, Person 정보는 모든 페이지 공통 템플릿(이 블로그라면 article-template.html)에 한 번만 넣어두고, 각 글마다 달라지는 BlogPosting·BreadcrumbList만 페이지별로 추가하는 구조가 가장 깔끔합니다.
@id를 지을 때는 규칙을 정해두는 게 좋습니다. 흔히 쓰는 패턴은 도메인#organization, 도메인#website, 페이지URL#webpage, 페이지URL#blogpost, 도메인#person-이름 처럼 URL 뒤에 # 기호와 짧은 라벨을 붙이는 방식입니다. 이렇게 일관된 패턴을 정해두면, 글이 수백 개로 늘어나도 어떤 @id가 무엇을 가리키는지 헷갈리지 않습니다. 반대로 @id를 페이지마다 즉흥적으로 짓다 보면, 같은 조직을 가리키는 @id가 페이지마다 달라지는 '자기 참조 꼬임' 문제가 생기기 쉽습니다. 이런 경우 검색엔진이 같은 엔티티를 다른 엔티티로 잘못 인식할 위험이 커집니다. 한 번 정한 @id 네이밍 규칙은 워드프레스의 커스텀 필드든, 정적 사이트의 프런트매터든, 어떤 도구를 쓰든 문서 한 장으로 정리해 팀 전체가 공유하는 걸 추천합니다. 혼자 운영하는 블로그라도 몇 달 뒤의 자신이 까먹지 않도록 메모해두면 좋습니다.
WebSite 스키마에는 potentialAction으로 검색 기능을 연결해줄 수도 있습니다. 이걸 추가하면 구글이 검색 결과의 사이트링크 아래에 작은 검색창을 함께 보여줄 자격을 얻게 됩니다. 사이트에 검색 기능이 이미 있다면 어렵지 않게 추가할 수 있는 부분입니다. target에는 실제 검색 결과 페이지의 URL 패턴을 적고, {search_term_string} 자리에 사용자가 입력한 검색어가 그대로 치환됩니다. 이 기능이 표시될지 여부는 구글의 판단에 달려 있지만, 마크업을 정확히 갖춰두는 것 자체는 손해 볼 일이 없습니다.
{
"@type": "WebSite",
"@id": "https://agmazon.com/#website",
"url": "https://agmazon.com/",
"name": "Gardenee Blog",
"potentialAction": {
"@type": "SearchAction",
"target": "https://agmazon.com/blog/articles.html?q={search_term_string}",
"query-input": "required name=search_term_string"
}
}전자상거래를 운영한다면 Product 스키마, 매장이 있다면 LocalBusiness도 챙길 만합니다. Product의 경우 name, image, offers(가격·재고 상태), aggregateRating(평균 별점·리뷰 수) 네 가지가 핵심이며, 이 중 하나라도 빠지면 별점이나 가격이 검색 결과에 표시되지 않을 수 있습니다. LocalBusiness는 매장 주소, 영업시간, 전화번호 같은 정보를 구조화해서 지도 검색과 연동되는 결과에 활용됩니다.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "샘플 상품명",
"image": "https://example.com/product.webp",
"offers": {
"@type": "Offer",
"priceCurrency": "KRW",
"price": "29000",
"availability": "https://schema.org/InStock"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.7",
"reviewCount": "128"
}
}다만 이 블로그처럼 콘텐츠 중심 사이트라면 Article(또는 BlogPosting), Organization, Person, BreadcrumbList, 그리고 검색 기능이 있다면 WebSite의 SearchAction까지 다섯 가지만 정확하게 갖춰도 충분합니다. 괜히 관련 없는 스키마를 욱여넣는 것보다, 적은 종류라도 완전하고 정확하게 채우는 쪽이 훨씬 효과적입니다.
이미지나 영상이 콘텐츠의 핵심이라면 image 속성에 단순 URL 문자열 대신 ImageObject를 명시적으로 적어주는 것도 방법입니다. 너비·높이 정보까지 함께 제공하면, 검색엔진이 이미지를 다시 다운로드해 크기를 확인하는 과정 없이 바로 활용할 수 있어 처리 속도 면에서 유리합니다. 영상이 포함된 글이라면 VideoObject로 썸네일, 업로드 날짜, 재생 시간을 함께 적어주면 영상 관련 리치 결과 후보가 됩니다.
"image": {
"@type": "ImageObject",
"url": "https://agmazon.com/blog/articles/technology/202606/json-ld-structured-data-guide.webp",
"width": 1200,
"height": 675
}지금까지 설명한 조각들을 전부 모아, 이 글 자체에 실제로 적용해도 손색없는 통합 @graph 예시를 마지막으로 보여드립니다. Organization, WebSite, Person, BreadcrumbList, BlogPosting이 한 블록 안에서 @id로 서로를 참조하는 구조를 한눈에 보면, 지금까지 따로따로 설명한 내용이 어떻게 하나로 합쳐지는지 감이 잡힐 겁니다.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://agmazon.com/#organization",
"name": "Gardenee Blog",
"url": "https://agmazon.com/",
"logo": "https://agmazon.com/background/jennie.png",
"sameAs": ["https://github.com/unluckysoon"]
},
{
"@type": "WebSite",
"@id": "https://agmazon.com/#website",
"url": "https://agmazon.com/",
"name": "Gardenee Blog",
"publisher": { "@id": "https://agmazon.com/#organization" }
},
{
"@type": "Person",
"@id": "https://agmazon.com/#person-gardenee",
"name": "Gardenee",
"url": "https://agmazon.com/",
"sameAs": ["https://github.com/unluckysoon"]
},
{
"@type": "BreadcrumbList",
"@id": "https://agmazon.com/blog/articles/technology/202606/json-ld-structured-data-guide.html#breadcrumb",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Home", "item": "https://agmazon.com/blog/index.html" },
{ "@type": "ListItem", "position": 2, "name": "Technology", "item": "https://agmazon.com/blog/categories.html" },
{ "@type": "ListItem", "position": 3, "name": "JSON-LD 완벽 가이드" }
]
},
{
"@type": "BlogPosting",
"@id": "https://agmazon.com/blog/articles/technology/202606/json-ld-structured-data-guide.html#blogpost",
"headline": "JSON-LD 완벽 가이드: 2026년 AI 검색 시대 SEO 필수 전략",
"isPartOf": { "@id": "https://agmazon.com/#website" },
"breadcrumb": { "@id": "https://agmazon.com/blog/articles/technology/202606/json-ld-structured-data-guide.html#breadcrumb" },
"author": { "@id": "https://agmazon.com/#person-gardenee" },
"publisher": { "@id": "https://agmazon.com/#organization" },
"datePublished": "2026-06-24T12:00:00+09:00",
"dateModified": "2026-06-24T12:00:00+09:00"
}
]
}다섯 개의 엔티티가 한 블록에 들어가 있지만, 실제로 중복으로 적힌 정보는 하나도 없습니다. 조직 이름은 Organization 한 곳에만, 글쓴이 정보는 Person 한 곳에만 존재하고, 나머지는 모두 @id 참조로 연결되어 있을 뿐입니다. 이 구조를 한 번 템플릿으로 만들어두면, 그 다음 글부터는 BlogPosting과 BreadcrumbList의 내용만 바꿔주면 됩니다. 처음 템플릿을 잡는 데는 시간이 좀 걸리지만, 그 이후로는 글을 쓸 때마다 복사-붙여넣기 몇 줄로 끝나는 작업이 됩니다.
FAQ 리치 결과의 종말, 그리고 남은 가치
이 글을 쓰게 된 직접적인 계기가 바로 이 부분입니다. FAQPage 스키마는 한때 SEO 담당자들에게 거의 '국민 스키마'였습니다. 본문 아래에 질문-답변을 펼치는 드롭다운이 검색 결과에 그대로 표시되면서 화면을 더 많이 차지했고, 그만큼 클릭률도 좋았거든요. 그런데 그 화려한 시절은 사실상 끝났습니다. 아래 타임라인을 보시죠.
구글이 FAQ 리치 결과를 정식 출시. 스키마를 추가한 사이트들이 검색 결과에서 평소보다 훨씬 넓은 영역을 차지하기 시작했습니다.
남용이 심해지자 구글이 FAQ·HowTo 리치 결과 노출을 "잘 알려진 정부·의료기관 사이트"로 제한. 일반 사이트는 이때부터 사실상 효과가 사라졌습니다.
FAQ와 별개로, 사용 빈도가 낮고 효용이 떨어진다고 판단된 구조화 데이터 타입 7종이 검색 결과 노출 기능에서 추가로 정리됐습니다. 구글이 리치 결과 기능을 정기적으로 다이어트하고 있다는 걸 보여주는 사례입니다.
3월 코어 업데이트 이후, 남아있던 정부·의료기관 사이트들조차 FAQ 리치 결과 노출이 눈에 띄게 줄어들었다는 추적 데이터가 다수 보고됐습니다.
구글이 공식 문서에 폐지 공지를 추가. 남아있던 마지막 예외(정부·의료기관)까지 포함해 FAQ 리치 결과가 검색 결과에서 전면적으로 사라졌습니다. 공지는 화려한 블로그 발표 없이, 개발자 문서 상단에 짧은 한 줄로만 조용히 추가됐습니다.
서치 콘솔의 FAQ 보고서와 리치 결과 테스트 지원이 6월에, 서치 콘솔 API 지원이 8월에 순차적으로 종료될 예정입니다.
FAQPage가 완전히 사라진 건 아닙니다. 구글이 없앤 건 검색 결과 화면에 드롭다운을 그려주는 '리치 결과 기능' 그 자체입니다. FAQPage라는 스키마 타입 자체는 schema.org에서 여전히 유효하고, 구글도 이 마크업을 계속 읽어서 페이지 내용을 이해하는 데 쓴다고 공식적으로 밝혔습니다.
그래서 실무적으로 어떻게 해야 할까요? 결론은 이렇습니다. 단순히 검색 결과에 더 넓은 영역을 차지하려는 목적으로 FAQPage를 추가하는 전략은 더 이상 의미가 없습니다. 하지만 페이지에 실제로 보이는 진짜 FAQ 콘텐츠가 있다면, 그 부분에 FAQPage 마크업을 유지하는 건 여전히 가치가 있습니다. 이유는 두 가지입니다. 첫째, 질문-답변 형식은 AI 검색 도구가 답변을 추출하고 인용하기에 가장 다루기 쉬운 구조입니다. 둘째, 구글이 직접 밝혔듯 마크업 자체는 페이지 이해에 계속 활용됩니다. 다만 절대 "예전처럼 검색결과에 드롭다운이 뜰 거야"라는 기대는 접어야 합니다.
왜 구글이 굳이 이렇게까지 손을 댔을까 궁금하실 텐데, 배경을 알면 이해가 쉽습니다. 2019년 출시 이후 FAQ 리치 결과는 너무 매력적인 '검색결과 화면 점유 도구'가 되어버렸습니다. 실제로는 질문-답변 콘텐츠가 거의 없는 일반 제품 페이지나 광고성 페이지에도 억지로 FAQ 섹션을 끼워 넣고 스키마를 다는 경우가 폭증했죠. 화면을 더 차지하기 위한 수단으로 변질된 셈입니다. HowTo 리치 결과도 같은 시기에 비슷한 이유로 데스크톱 전용으로 축소됐다가 결국 단계적으로 정리됐습니다. 패턴을 보면 알 수 있듯, 구글은 "콘텐츠 품질과 무관하게 화면만 키워주는 기능"을 주기적으로 정리해온 전력이 있습니다.
참고로 FAQPage와 자주 혼동되는 QAPage는 용도가 다릅니다. FAQPage는 운영자가 직접 작성한 '단일 정답'용이고, QAPage는 포럼처럼 여러 사용자가 답을 다는 구조에 씁니다. 코드로 비교하면 차이가 더 명확합니다.
// FAQPage: 운영자가 작성한 단일 정답
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "JSON-LD가 검색 순위에 직접 영향을 주나요?",
"acceptedAnswer": {
"@type": "Answer",
"text": "아니요. 구글은 구조화 데이터가 직접적인 순위 요소가 아니라고 공식적으로 밝혔습니다."
}
}
]
}QAPage는 답변이 여러 개 달릴 수 있고, 각 답변마다 작성자와 채택 여부가 따로 존재한다는 점에서 구조가 더 복잡합니다. 커뮤니티형 게시판이나 Q&A 서비스를 운영하지 않는 일반 블로그라면 QAPage를 쓸 일은 거의 없으니, 이 글에서는 자세한 코드까지 다루지는 않겠습니다. 중요한 건 "내 콘텐츠가 둘 중 어느 쪽에 해당하는지"를 정확히 판단하는 감각입니다.
FAQ 리치 결과의 퇴장은 사실 더 큰 흐름의 한 장면일 뿐입니다. 구글은 평소에도 사용 빈도가 낮거나 효용이 떨어진다고 판단되는 검색 노출 기능을 조용히 정리해왔습니다. 2026년 1월에는 한 학습 콘텐츠용 기능의 지원 종료가 문서에 조용히 추가됐고, Dataset 구조화 데이터도 구글 검색 자체에는 쓰이지 않고 별도의 Dataset Search 전용이라는 점이 다시 한번 명확히 안내됐습니다. 이런 흐름을 보면, "이 스키마가 지금 어떤 검색 기능에 쓰이는지"를 주기적으로 한 번씩 확인하는 습관이 장기적으로 도움이 됩니다. 기능이 조용히 사라져도 마크업만 그대로 남아있는 경우가 생각보다 많거든요.
자주 저지르는 실수 9가지
JSON-LD는 문법이 단순한 만큼, 실수도 매우 흔하게 반복됩니다. 신기한 건 초보자만 실수하는 게 아니라는 점입니다. 몇 년째 운영 중인 사이트에서도 템플릿이 바뀌거나 담당자가 교체되는 시점에 똑같은 패턴의 오류가 슬그머니 다시 생기는 경우를 자주 봅니다. 실제로 자주 발견되는 패턴들을 정리해봤습니다. 하나씩 점검하면서 본인 사이트에 해당하는 항목이 있는지 확인해보시길 권합니다.
-
1
화면에 안 보이는 내용을 마크업하기
JSON-LD에 적은 정보가 실제 페이지에 보이지 않으면 구글 정책상 스팸으로 간주될 수 있습니다. 예를 들어 리뷰 5개를 마크업했는데 페이지에는 3개만 보인다면, 사용자에게는 보이지 않는 점수를 검색 결과에서만 보여주는 셈이라 정책 위반입니다. 마크업과 화면은 항상 1:1로 일치해야 합니다. 페이지를 리뉴얼하면서 본문 일부 섹션을 지웠는데 JSON-LD는 그대로 남겨두는 경우가 특히 자주 발생하니, 디자인 개편 작업을 할 때마다 구조화 데이터도 함께 점검 목록에 넣어두는 습관이 안전합니다.
-
2
모든 페이지에 Organization 스키마 중복 선언
사이트 전체에서 동일한 조직 정보를 페이지마다 따로 적으면 정보가 어긋날 위험이 커집니다. 로고 URL을 한 페이지에서만 바꾸고 나머지는 깜빡 잊는 식의 불일치가 실제로 자주 일어납니다. 전역 한 곳에 선언하고 @id로 참조하세요.
-
3
워드프로세서에서 복사한 스마트 쿼트
워드나 노션에서 코드를 복사하면 일반 따옴표(")가 둥근 스마트 쿼트(“ ”)로 자동 변환되어 JSON 파싱이 깨지는 경우가 흔합니다. 화면에서는 둘이 거의 똑같아 보여서 디버깅할 때 한참 헷갈리게 되는 대표적인 함정입니다.
-
4
trailing comma(끝에 붙은 쉼표)
JSON은 배열이나 객체의 마지막 항목 뒤에 쉼표를 허용하지 않습니다. 자바스크립트 객체 리터럴은 이를 허용하다 보니, 자바스크립트 코드를 작성하던 습관 그대로 JSON-LD를 적다가 자주 실수하는 부분입니다.
-
5
필수 필드 일부만 채우기
예를 들어 Product 스키마에 AggregateRating이 빠지면 별점이 표시되지 않고, Article에 author가 빠지면 작성자 정보가 누락됩니다. 부분적인 구현은 리치 결과 효과가 거의 없는 데다, "절반만 정확한 데이터"라는 인상을 줄 수 있습니다.
-
6
실제와 다른 날짜 정보
수정하지 않았는데 dateModified를 매번 오늘 날짜로 바꾸는 '신선도 어뷰징'은 장기적으로 신뢰 신호를 깎아먹습니다. 콘텐츠를 실제로 갱신했을 때만 dateModified를 갱신하는 습관을 들이는 게 좋습니다.
-
7
FAQPage와 QAPage 혼용
운영자가 직접 답하는 콘텐츠인지, 사용자가 여러 답을 다는 포럼형 콘텐츠인지에 따라 타입을 정확히 구분해야 합니다. 두 타입의 필수 속성 구조가 달라서, 혼용하면 마크업 전체가 무시될 수 있습니다.
-
8
한 번 적용하고 다시는 검증하지 않기
CMS 템플릿이 바뀌거나 플러그인이 업데이트되면 마크업이 조용히 깨지는 경우가 많습니다. 배포 당일에는 멀쩌멀쩡했던 코드가 몇 달 뒤 템플릿 리뉴얼로 슬그머니 사라져 있는 경우를 실제로 자주 목격하게 됩니다. 주기적인 재검증이 필요합니다.
-
9
다국어 페이지에서 언어 정보 불일치
영어 페이지인데 description을 한국어로 남겨두거나, 반대의 경우도 흔히 발견됩니다. 각 언어 페이지의 JSON-LD는 그 페이지에 실제로 보이는 언어와 정확히 일치해야 합니다. hreflang과 JSON-LD 내용이 서로 다른 언어를 가리키면 검색엔진에 혼란스러운 신호를 주게 됩니다.
2026년 검증 워크플로우
구글의 구조화 데이터 테스트 도구 역사도 한 번 정리해둘 필요가 있습니다. 예전에 쓰던 'Structured Data Testing Tool'은 2020년에 단계적으로 퇴역했고, 지금은 두 갈래로 나뉘어 있습니다. 하나는 구글 검색 결과 노출 여부를 보는 Rich Results Test, 다른 하나는 schema.org 표준 자체를 폭넓게 검사하는 Schema Markup Validator입니다. 둘의 역할이 다르기 때문에 같이 쓰는 게 정석입니다. 예전 도구를 한 번에 통째로 없애지 않고, 구글 전용 검증 기능과 범용 schema.org 검증 기능을 분리해서 각각 새 도구로 옮긴 점이 인상적입니다. 덕분에 "내 마크업이 구글 리치 결과에 자격이 있는가"와 "내 마크업이 schema.org 표준에 맞는가"라는 서로 다른 두 질문을 각각 더 정확하게 답할 수 있게 됐습니다.
처음 JSON-LD를 작성해보는 분이라면, 굳이 두 도구를 모두 외울 필요 없이 일단 Rich Results Test부터 열어보시길 권합니다. URL을 붙여넣거나 코드를 직접 붙여넣으면 몇 초 안에 결과가 나오고, 어떤 리치 결과 후보가 되는지, 어떤 필드가 빠졌는지 친절하게 알려줍니다. 익숙해진 다음에 Schema Markup Validator로 더 꼼꼼한 표준 준수 여부를 확인하는 순서가 학습 곡선이 부드럽습니다.
| 도구 | 용도 | 한계 |
|---|---|---|
| Rich Results Test | 구글 리치 결과 노출 자격 확인, 모바일/PC 렌더링 미리보기 | 구글이 지원하는 약 30종 타입만 검사, 전체 스키마 800여 종은 다루지 않음 |
| Schema Markup Validator | schema.org 전체 어휘 기준 문법·구조 검증 | 구글 전용 경고는 표시하지 않음 |
| 서치 콘솔 향상 보고서 | 실제 색인된 페이지의 누적 오류 모니터링 | 크롤링 시점 데이터라 실시간 반영이 늦음 |
| 크롤러형 도구 (예: Screaming Frog 등) | 사이트 전체 수십~수백 페이지를 한 번에 검사 | 별도 설치·설정이 필요해 진입장벽이 있음 |
실무에서는 이런 순서가 효율적입니다. 먼저 새 마크업을 작성한 직후 Rich Results Test나 Schema Markup Validator에 코드를 붙여넣어 빨간색 오류(필수 항목 누락 등)를 0개로 만듭니다. 배포 후에는 실제 URL로 다시 한 번 검사해서 렌더링이 의도한 대로 되는지 확인합니다. 그리고 1~2주 뒤 서치 콘솔의 향상 보고서를 열어, 구글이 실제로 크롤링한 결과에 오류가 없는지 마지막으로 점검합니다. 여기서 한 가지 함정이 있는데, 서치 콘솔의 향상 보고서는 '지금 이 순간'의 마크업이 아니라 '구글이 마지막으로 크롤링했던 시점'의 마크업을 보여줍니다. 그래서 이미 고친 오류가 보고서에는 며칠 더 남아있는 경우가 있는데, 이건 보고서가 잘못된 게 아니라 단순히 갱신 지연일 뿐이니 당황하지 않아도 됩니다.
검증 도구가 보여주는 경고 문구도 미리 알아두면 당황할 일이 줄어듭니다. "필수 필드가 누락되었습니다(Missing field)"는 그 스키마 타입에 꼭 있어야 하는 속성이 빠졌다는 뜻으로, 빨간색으로 표시되며 리치 결과 자격을 막습니다. "권장 필드가 누락되었습니다"는 노란색 경고로, 당장 자격을 막지는 않지만 채워두면 표시 품질이 좋아지는 항목입니다. "값 형식이 잘못되었습니다(Invalid value type)"는 날짜를 문자열로 적어야 하는데 숫자로 적었거나, 배열이어야 하는데 단일 객체로 적은 경우처럼 데이터 타입 자체가 틀렸을 때 나타납니다. 빨간 오류부터 우선 해결하고, 노란 경고는 시간 여유가 있을 때 채워나가는 순서가 합리적입니다.
참고로 Rich Results Test는 별도의 공개 API가 없어서, 수십 개 이상 페이지를 자동으로 검사하려면 서치 콘솔 API의 URL 검사 기능이나 크롤러형 도구를 함께 써야 합니다. 운영 중인 글이 수백 개 단위로 늘어난 블로그라면, 매번 손으로 하나씩 검사하는 건 사실상 불가능합니다. 이런 경우 빌드 파이프라인(예: GitHub Actions)에 스키마 검증 단계를 끼워 넣어, 사이트맵의 모든 URL을 순회하며 JSON-LD를 파싱하고 schema.org 규칙 위반이 있으면 배포 자체를 막는 방식이 점점 늘고 있습니다. 작은 개인 블로그라면 이렇게까지 갈 필요는 없지만, 글이 수천 건에 가까워진다면 충분히 고려할 만한 투자입니다.
커뮤니티 반응도 흥미롭습니다. 레딧 r/SEO 같은 곳에서는 "거의 동일한 콘텐츠, 동일한 키워드 난이도의 페이지 세 개를 만들어 구조화 데이터만 다르게 적용했더니, JSON-LD를 제대로 넣은 페이지만 AI 오버뷰에 인용되고 순위도 가장 높았다"는 식의 비공식 실험 글이 종종 화제가 됩니다. 다만 이런 실험은 표본이 1개 사례에 불과하고 다른 변수를 완벽히 통제하기 어렵다는 한계가 있어, 결과를 그대로 일반화하기보다는 "구조화 데이터를 제대로 갖추는 게 손해 볼 일은 없다"는 합리적인 결론 정도로 받아들이는 게 좋습니다.
개발자 커뮤니티 쪽 반응도 비슷한 결을 보입니다. 한 개발자는 자신의 개인 블로그에 JSON-LD를 처음 적용해본 경험을 공유하면서, "이 코드는 브라우저 입장에서는 그냥 무시되는 텍스트 덩어리에 불과하지만, 검색엔진과 AI 크롤러에게는 완전히 다른 의미를 가진다"는 점을 강조했습니다. 화면에 아무 변화가 없으니 처음엔 "이게 정말 효과가 있긴 한 건가" 싶은 의구심이 들 수 있지만, 바로 그 '눈에 보이지 않는다'는 특성이야말로 JSON-LD를 가볍게 시도해볼 수 있는 이유이기도 합니다. 잘못 적어도 사용자 경험을 해치지 않고, 검증 도구로 바로 확인하고 고칠 수 있으니 실패 비용이 낮은 편입니다.
마무리: 실전 체크리스트
긴 글이었지만 결론은 간단합니다. JSON-LD는 화려한 트릭이 아니라 기초 체력입니다. 화면에 보이는 콘텐츠와 정확히 일치하는 정보를, 올바른 스키마 타입으로, 빠짐없이 적어두는 것. 그게 전부입니다. 거창한 도구나 비싼 플러그인이 필요한 작업이 아니라, 텍스트 에디터와 검증 도구 하나만 있어도 오늘 바로 시작할 수 있는 일이라는 점도 강조하고 싶습니다. 본격적인 체크리스트에 들어가기 전에, 글을 쓰면서 자주 받을 법한 질문 몇 가지를 미리 정리해봤습니다.
독자들이 자주 묻는 질문
Q. 워드프레스를 쓰는데 플러그인이 자동으로 JSON-LD를 넣어주던데, 그래도 직접 신경 써야 하나요?
대부분의 SEO 플러그인은 기본적인 Article·Organization 스키마를 꽤 잘 만들어줍니다. 그래도 author의 sameAs, 정확한 이미지 비율, BreadcrumbList처럼 플러그인이 빈칸으로 두는 항목은 직접 채워주는 게 좋습니다. 플러그인 설정 화면의 "고급" 또는 "스키마" 탭을 한 번 살펴보면, 의외로 빈칸으로 남아있는 필드를 쉽게 찾을 수 있습니다. 플러그인이 만든 코드도 한 번쯤 Rich Results Test에 돌려보는 습관을 들이면 안심이 됩니다.
Q. 정적 사이트(Jekyll, Hugo, Astro 등)에서는 어떻게 적용하나요?
대부분 템플릿 엔진의 변수 치환 기능을 그대로 활용하면 됩니다. 글의 메타데이터(프런트매터)에 제목, 날짜, 저자 같은 값을 적어두고, 공통 레이아웃 파일에서 그 값을 JSON-LD 틀에 끼워 넣는 식입니다. 이 블로그도 비슷한 원리로, 파이썬 스크립트의 변수만 바꾸면 각 글의 JSON-LD가 자동으로 채워지는 구조를 쓰고 있습니다.
Q. 다국어 사이트는 언어별로 JSON-LD를 따로 작성해야 하나요?
네, 각 언어 페이지는 그 페이지에 보이는 콘텐츠와 일치하는 headline·description을 따로 가져야 합니다. 다만 hreflang 태그로 언어 간 관계를 이미 명시하고 있다면, JSON-LD에서 굳이 언어 간 관계까지 중복으로 표현할 필요는 없습니다. 각 페이지는 자기 자신의 콘텐츠만 정확하게 설명하면 충분합니다.
Q. 구조화 데이터를 한꺼번에 다 빼버리면 페널티를 받나요?
아니요. 구글은 "쓰이지 않는 구조화 데이터가 검색에 문제를 일으키지는 않는다"고 공식적으로 밝혔습니다. 다만 있어서 손해 볼 일이 거의 없는 데다, AI 인용 측면의 이점까지 고려하면 굳이 빼야 할 이유는 찾기 어렵습니다.
Q. 한 페이지에 JSON-LD <script> 블록을 여러 개 넣어도 되나요?
가능합니다. 구글은 한 페이지에 여러 개의 JSON-LD 블록이 있어도 모두 파싱합니다. 다만 관리 편의성을 생각하면, 서로 관련된 엔티티는 앞서 설명한 @graph로 하나로 묶고, 정말 성격이 다른 정보(예: 전역 공통 정보와 페이지별 정보)만 블록을 나누는 쪽을 권장합니다.
Q. 이미 색인된 페이지의 JSON-LD를 수정하면 바로 검색 결과에 반영되나요?
아닙니다. 구글이 해당 페이지를 다시 크롤링하고 색인을 갱신해야 변경 사항이 반영됩니다. 보통 며칠에서 몇 주가 걸릴 수 있고, 서치 콘솔의 URL 검사 도구로 재색인을 요청하면 그 과정을 조금 앞당길 수 있습니다.
Q. 이 글에서 다루지 않은 HowTo, Recipe, Event 같은 스키마는 어떻게 하나요?
이 블로그처럼 글 중심 콘텐츠라면 이 글에서 다룬 다섯 가지(Article, Organization, Person, BreadcrumbList, WebSite)만으로 충분합니다. 다만 요리·레시피 콘텐츠를 다룬다면 Recipe, 행사를 안내한다면 Event, 단계별 설명이 핵심인 콘텐츠라면 여전히 유효한 HowTo를 schema.org 공식 문서에서 찾아 같은 원칙(필수 속성 빠짐없이, 화면과 일치)으로 적용하면 됩니다.
이제 이 글을 적용할 때 바로 점검할 수 있는 체크리스트를 정리했습니다.
- Article/BlogPosting에 headline, description, author, publisher, datePublished가 모두 채워져 있나요?
- Organization·Person 정보를 사이트 전역에서 중복 없이 @id로 참조하고 있나요?
- sameAs로 공식 SNS·외부 프로필 링크를 연결해 엔티티를 명확히 했나요?
- 마크업에 적은 내용이 실제 화면에 100% 동일하게 보이나요?
- FAQPage는 진짜 보이는 Q&A에만, 리치 결과를 기대하지 않는 전제로 유지하고 있나요?
- @id 네이밍 규칙(도메인#organization 같은 패턴)을 사이트 전체에서 일관되게 쓰고 있나요?
- 배포 전 Rich Results Test와 Schema Markup Validator로 오류 0개를 확인했나요?
- 1~2주 뒤 서치 콘솔 향상 보고서로 실제 색인 상태까지 재확인할 계획이 있나요?
- 글이 많아질 경우를 대비해 주기적인 일괄 재검증 루틴을 정해두었나요?
이 글에서 다룬 코드는 모두 직접 복사해서 도메인과 정보만 바꿔 바로 써도 되는 수준으로 작성했습니다. 다음 글을 쓸 때까지, 혹시 여러분의 사이트에 FAQPage 스키마가 남아있다면 한 번쯔음 화면에 실제로 보이는 콘텐츠와 일치하는지 점검해보시는 것도 좋은 타이밍일 것 같네요. 구조화 데이터는 한 번 제대로 정리해두면 그 다음부터는 거의 손댈 일이 없는, 투자 대비 효율이 꽤 좋은 작업입니다. 화려하지 않아서 자꾸 미루기 쉬운 작업이지만, 미뤄둔 만큼 나중에 한꺼번에 손볼 양이 늘어난다는 점도 함께 기억해두시면 좋겠습니다. 끝까지 읽어주셔서 감사합니다 🙌