클라이언트 사이트에 스키마 마크업을 처음 추가했을 때 a를 손으로 입력했습니다 Product 테마 헤더에 블록을 넣고 배포한 후 영리한 느낌으로 넘어갔습니다. 2 주 후 Rich Results Test 는 제안 개체가 누락되었다고 말했습니다 @type, 가격은 Google이 문자열을 원하는 숫자였고, 길 잃은 후행 쉼표는 전체 블록을 조용히 무효화했습니다. Google은 내내 이를 무시해 왔습니다. 구조화된 데이터로 아무도 경고하지 않는 것입니다: 유효하지 않은 JSON-LD는 오류를 발생시키거나 아무것도 빨간색으로 바꾸지 않습니다. 단지 조용히 아무것도 하지 않으며, 몇 달 후 당신이 기대했던 풍부한 결과가 결코 나타나지 않을 때 알게 됩니다.
어휘 자체는 에 게시됩니다 schema.org그리고 Google이 실제로 풍부한 결과를 보여줄 것은 더 좁은 목록입니다 구조화된 데이터 문서.
나는 생활을위한 도구를 구축 - Toolz.dev, WP Adminify 플러그인, Laravel 및 React 앱의 스택 - 그리고 구조화 된 데이터는 내가 손으로 그것을하는 것을 분개 할만큼 자주하고 거의 매번 정확한 속성 이름을 잊어 버릴만큼 충분히하지 않는 작업 중 하나입니다 그래서 나는 구축 스키마 마크업 생성기 나에게 가장 큰 비용을 초래한 두 가지 실패 모드를 제거하기 위해: 잘못된 중첩 및 침묵 무효. 이 가이드는 스키마 마크업이 실제로 수행하는 작업,생성기가 이를 구축하는 방법,유효해 보이는 마크업이 풍부한 결과를 얻지 못하게 하는 구체적인 실수를 살펴봅니다.
TL;DR: 스키마 마크업은 페이지가 무엇인지 검색 엔진에 정확하게 알려주는 구조화된 데이터 (schema.org 어휘 사용) 로,FAQ 아코디언,제품 가격,브레이크크럼과 같은 풍부한 결과를 얻을 수 있습니다. Google 은 JSON-LD 형식 - 독립형 - 을 권장합니다
<script type="application/ld+json">구획. 발전기는 9 개의 일반적인 유형을 위한 유효한 JSON-LD 를,중첩합니다 이하 목표를 같이 건설합니다PostalAddress그리고Offer올바르게, 필수 및 권장 필드가 누락 된 플래그를 지정하고 브라우저에서 100% 실행되므로 입력 한 내용이 업로드되지 않습니다.
스키마 마크업이란 무엇이며, 왜 중요한가요?
스키마 마크업은 페이지의 내용을 기술하는 표준화된 방법으로,머신이 그것을 이해할 수 있도록 하기 위한 것이지,그냥 렌더링하는 것이 아니다. 어휘는 schema.org 에서 나온 것으로,구글, 마이크로소프트,야후, 얀덱스가 지원하는 공유 프로젝트인 페이지를 마크업할 때 Article당신은 검색 엔진 "this를 말하고 있다 뉴스 또는 블로그 기사, 여기 그것의 표제, 여기 그것을 쓴 사람, 여기 그것이 간행 될 때 이다." 그 구조화 된 설명은 풍부한 결과에 대 한 자격이 페이지를 만드는 것-별 등급, 가격, FAQ 드롭다운, 이벤트 날짜, 그리고 일반 파란색 링크 보다 더 많은 공간을 차지 하 고 더 많은 클릭을 적립 빵 부스러기 흔적 강화 된 목록.
중요한 이유는 지난 몇 년 동안 변경되었습니다. 그것은 순전히 Google 의 풍부한 결과에 관한 것이 었습니다. 이제 구조화 된 데이터는 AI 응답 엔진과 Google's AI 개요에도 피드됩니다. ChatGPT,Perplexity 또는 Gemini 가 비즈니스가 수행하는 작업이나 쿼리와 일치하는 제품을 요약하려고 할 때 깨끗한 구조화 된 데이터는 사실을 올바르게 파악하는 데 도움이되는 신호 중 하나입니다. 자신을 명확하게 선언하는 페이지 Organization 이름, 로고 및 소셜 프로필을 사용하면 HTML에 모든 것을 암시하는 것보다 모든 시스템에서 추론하기가 훨씬 쉽습니다.
문제는 구조화된 데이터가 용서할 수 없다는 것입니다. 코드이고 코드가 정확히 맞아야 합니다. 철자가 붙은 속성입니다 datePublish 대신 datePublished 는 단순히 무시된다. An Offer 없이 @type 는 제안으로 인식되지 않습니다. 그리고 이러한 실수 중 어느 것도 눈에 보이는 페이지를 깨지 않기 때문에 프로덕션에 무기한 숨겨집니다. 그것이 생성기가 채우는 간격입니다. 개념을 작성하는 것이 아니라 매번 구문과 구조를 올바르게 얻는 것입니다.
왜 마이크로데이터나 RDFa 대신 JSON-LD 인가?
페이지에 schema.org 데이터를 추가하는 세 가지 방법이 있으며, 생성기가 왜 그 중 하나만 생성하는지 이해하는 데 도움이됩니다.
마이크로데이터 그리고 RDFa 추가 속성을 사용하여 구조화된 데이터를 눈에 보이는 HTML에 직접 엮습니다 itemscope, itemprop, property등등. 당신의 <div> 제품 검토를 위해 눈에 보이는 텍스트의 각 조각에 레이블을 지정하는 속성을 얻습니다. 이것은 작동하지만 마크업을 페이지 구조에 단단히 연결합니다. 레이아웃을 변경하면 스키마를 깨뜨릴 위험이 있습니다. 또한 장황하고 읽기 어렵습니다.
JSON-LD 반대의 접근법을 취합니다. 모든 구조화된 데이터를 하나의 독립된 <script type="application/ld+json"> 블록, 일반적으로 <head>는, 보이는 HTML에서 완전히 분리합니다. 구글은 정확하게 이 분리 때문에 수년간 JSON-LD를 추천했습니다: 당신은 그것을 추가하거나, 그것을 새롭게 하거나, 당신의 템플렛을 만지기 없이 꼬리표 매니저를 통해서 주사할 수 있습니다. 그것은 모든 현대 도식 튜토리얼이 가르치는 체재이고, 발전기가 출력하는 무슨입니다.
| 포맷 | 그것이 사는 곳 | 유지보수의 용이성 | Google's 스탠스 |
|---|---|---|---|
| JSON-LD | 싱글 <script> HTML과 별도로 차단합니다 |
가장 쉬운 - 한 블록을 편집 | ...에 추천된 |
| 마이크로데이터 | 보이는 HTML 내부의 속성 | 더 단단함 - 레이아웃과 결합됨 | 지원되는 |
| RDFa | 보이는 HTML 내부의 속성 | 더 단단함 - 레이아웃과 결합됨 | 지원되는 |
WordPress 에서 작업하는 경우 JSON-LD 는 대부분의 SEO 플러그인이 주입하는 것이기도하며 WP Adminify 와 같은 도구가 깔끔하게 옆에 있습니다. 독립형 블록이기 때문에 여기에서 생성하여 프레임 워크 특정 체조없이 사용자 정의 HTML 필드,태그 관리자 또는 Laravel Blade 레이아웃에 붙여 넣을 수 있습니다.
스키마 마크업 생성기를 어떻게 사용합니까?
워크플로는 유형을 선택하고 입력할 때 JSON-LD 어셈블리를 볼 수 있도록 라이브 미리보기를 사용하여 짧은 양식을 작성하는 방식으로 구성됩니다.
1 단계 - 스키마 유형을 선택합니다. 조직,로컬 비즈니스,웹 사이트,기사, 제품,FAQPage, BreadcrumbList,Person, 또는 Event 에서 선택하십시오. 양식은 즉시 유형이 필요로하는 필드로 바뀝니다. 이 9 개는 중소 규모 사이트가 실제로 마크 업을 필요로하는 압도적 인 다수를 다룹니다.
2단계 - 필드를 채웁니다. 필수 필드는 별표로 표시됩니다. 입력할 때 도구는 JSON-LD 를 조립하고 빈 칸으로 남겨둔 필드를 삭제하므로 빈 칸으로 끝나지 않습니다 "" 출력을 오염시키는 속성. LocalBusiness 및 Event 와 같은 주소 기반 유형의 경우 개별 주소 필드가 올바르게 입력된 필드로 접힙니다 PostalAddress 자동으로 개체.
3단계 - 검증을 시청하세요. 생성기는 두 종류의 문제를 플래그합니다. 오류 (필수 필드 누락,잘못된 URL) 는 깨끗한 결과를 차단하고 빨간색으로 표시됩니다. 경고 (Google 에서 권장하는 필드를 누락하는 것과 같습니다 image 또는 datePublished또는 위치 지정자가 없는 검색 URL 템플릿)이 호박색으로 표시됩니다. 마크업은 여전히 유효하지만 풍부한 결과 잠재력은 테이블에 남깁니다.
4 단계 - 복사 및 배포. 전체 사이를 전환합니다 <script> 태그(붙일 준비가 되었습니다 <head>) 및 원시 JSON(태그 관리자 및 CMS 필드용). 스크립트 출력은 그렇지 않으면 길을 잃게 만드는 문자를 이스케이프합니다 </script> 당신의 자료에서 페이지를 끊으십시오. 그 후에 Google's 부유한 결과 시험을 가진 살아있는 페이지를 유효하게 하십시오.
모든 것이 클라이언트 측에서 실행되기 때문에 NDA 하에서 게시되지 않은 제품 페이지,스테이징 환경 및 클라이언트 작업에서 사용하기에 안전합니다. 귀하의 가격,이벤트 세부 정보 및 내부 URL 은 브라우저를 떠나지 않습니다 - 사이트의 모든 도구 뒤에 동일한 개인 정보 보호 입장,내가 에 대해 쓴 데이터 개인정보 보호 가이드.
실제로 어떤 스키마 유형을 사용해야 합니까?
모든 페이지에 마크업이 필요한 것은 아니며,지원할 수 없는 유형을 쌓는 것은 없는 것보다 더 나쁩니다. 발전기가 다루는 9 가지에 대해 제가 생각하는 방법은 다음과 같습니다.
조직 귀하의 홈페이지 또는 정보 페이지에 속합니다. 이는 지식 패널을 제공하고 Google이 귀하의 브랜드를 소셜 프로필에 연결하는 데 도움이 되는 스키마입니다 sameAs. 웹 사이트 이 항목과 쌍을 이루고 다음을 통해 사이트링크 검색 상자를 선언할 수 있습니다 SearchAction, 사용자가 결과 페이지에서 직접 사이트를 검색할 수 있도록 합니다. 지역사업 물리적 위치가있는 경우 필수입니다: 주소, 전화, 가격대 및 영업 시간을 전달하며 지역 팩 및지도 결과를 뒷받침합니다.
기사 (발전기가 방출하는 것입니다 Article 블로그 게시물에 동일하게 유효한 유형)은 편집 콘텐츠에 헤드라인, 저자, 출판사 및 게시 날짜를 표시합니다. 제품 중첩된 판매용 제품을 설명합니다 Offer 가격, 통화 및 가용성을 전달하는 것이 가격 및 가용성 조각에 대한 권한입니다. 이벤트 컨퍼런스부터 웨비나까지 날짜와 장소가 포함된 모든 것을 다룹니다.
FAQ페이지 그리고 빵가루 목록 "thing."에 관한 것이 아니라 구조적입니다 FAQPage 는 질문과 답변 내용을 표시합니다; Google 은 FAQ 풍부한 결과를 권위있는 정부 및 건강 사이트로 좁혔지만 마크 업은 여전히 다른 검색 엔진 및 AI 응답 엔진이 Q & amp;A 를 구문 분석하는 데 도움이됩니다. BreadcrumbList 는 URL 구조가 읽는 방법을 향상시키는 결과에 제목 아래에 표시된 브레드 크럼 트레일을 생성합니다. 사람 작가, 창립자 또는 공인 등 개인을 표시하며 작가 약력 및 EEAT 신호에 유용합니다.
내가 따르는 규칙: 페이지가 진정으로 무엇에 관한 것인지 마크업하고,페이지에 실제로 보이는 콘텐츠를 반영하는 속성만 주장하십시오. Google's 가이드라인은 구조화된 데이터가 실제 눈에 보이는 콘텐츠를 설명해야 한다는 점을 명시합니다. - 페이지에 나타나지 않는 가격을 마크업하는 것은 바로가기가 아니라 위반입니다.
생성기는 마크업을 어떻게 유효하게 유지합니까?
그 가치는 손으로 잘못되기 쉬운 세부 사항에 있습니다. 몇 가지 불러 볼 가치가 있습니다.
올바른 중첩 @type. JSON-LD에서 중첩된 개체는 일반 하위 개체가 아닙니다. 각 개체에는 고유한 개체가 필요합니다 @type. 주소는 a입니다 PostalAddress, 제안은 다음과 같습니다 Offer, 기사's 저자는 a Person, 출판사는 입니다 Organization 누구의 로고가 ImageObject. 생성기는 이러한 모든 것을 올바른 유형으로 구축하므로 파서는 이를 익명 얼룩으로 처리하는 대신 인식합니다.
가지치기가 비워집니다. 필드를 비워두면 해당 속성이 제거되어야 하며 방출이 제거되어서는 안 됩니다 "telephone": "". 빈 문자열과 빈 배열은 출력에서 자동으로 제거되므로 복사하는 내용은 항상 깨끗합니다.
스크립트 안전 탈출. 인라인 JSON-LD에서 가장 위험한 캐릭터는 다음과 같습니다 < - 구체적으로 시퀀스입니다 </script> 스크립트 블록을 일찍 종료하고 페이지를 깨뜨릴 데이터 내부(설명)에 나타납니다. 생성기가 이스케이프됩니다 <, >, 그리고 & 유니코드 이스케이프를 사용하는 스크립트 태그 출력에서 Google's 자신의 예가 수행하는 것과 정확히 같습니다.
필수 및 권장 인식. 각 유형은 Google 이 요구하는 것과 권장하는 것의 자체 목록을 가지고 있습니다. 기사는 정말로 다음을 원합니다 image 그리고 datePublished; 제품이 원합니다 price; 이벤트에는 다음이 필요합니다 startDate. 공구는 권고 (경고) 에서 단단한 필요조건 (오류로 취급하는) 를 구별합니다,그래서 당신은 "this 의 다름을 work"와 "this 일 수 있었습니다 더 나은."
더 광범위한 기술 워크플로를 구성하는 경우 스키마 생성기는 자연스럽게 다른 SEO 유틸리티인 the와 나란히 위치합니다 메타 태그 생성기 제목,설명, Open Graph 태그에 대한,그리고 the XML 사이트맵 생성기 URL 제출을 위해. 함께 그들은 페이지 기술 SEO 표면의 대부분을 커버, 그리고 나는 그 이유로 그룹화 웹 개발자 툴킷 개요.
구조화된 데이터를 테스트하고 배포하려면 어떻게 해야 합니까?
유효한 JSON-LD를 생성하는 것은 작업의 절반입니다; 나머지 절반은 Google이 의도한 대로 읽었는지 확인하는 것입니다.
Google's 로 시작하세요 리치 결과 테스트URL을 가져오거나 붙여넣은 코드를 허용하고 페이지에 적합한 리치 결과 유형과 오류 또는 경고를 보고합니다. 그런 다음 다음을 통해 동일한 마크업을 실행합니다 스키마 마크업 유효성 검사기 google's rich-result 요구 사항이 아닌 schema.org 어휘 자체에 대한 적합성을 확인하는 validator.schema.org 에서. 두 가지는 다른 것을 포착합니다: Rich Results Test 는 특정 Google 기능에 대한 자격이 있는지 여부를 알려주는 반면 validator 는 마크업이 구조적으로 건전한 schema.org 인지 알려줍니다.
페이지가 활성화되면 향상 기능이 보고됩니다 구글 검색 콘솔 시간 경과에 따른 성능을 추적하고 Google 이 크롤링 중에 찾은 오류를 표시합니다. 여기서 규모로만 나타나는 문제 - 예를 들어 중복된 이동경로 위치를 내보내는 템플릿 또는 필요한 필드를 가끔 생략하는 제품 피드.
배포를 위해 붙여넣습니다 <script> 블록을 차단하세요 <head> 설명하는 특정 페이지 중. 모든 페이지에서 실행되는 전역 템플릿에 단일 제품 블록을 넣지 마십시오. 마크업은 현재 사용 중인 페이지와 일치해야 합니다. CMS 에서는 플랫폼이 제공하는 사용자 정의 HTML 또는 SEO 필드를 사용합니다. 태그 관리자에서는 사용자 정의 HTML 태그를 사용하고 JSON 을 복사합니다. React 또는 Laravel 앱에서는 크롤러가 수화 후가 아닌 초기 HTML 에서 볼 수 있도록 블록 서버 측을 삽입합니다.
일반적인 실수 나는 아직도 본다
몇 가지 오류가 계속해서 나타나며, 모든 오류는 보기에는 괜찮지만 아무 작업도 수행하지 않는 마크업을 생성합니다.
클래식은 보이지 않는 콘텐츠를 표시합니다 - 페이지 어디에도 나타나지 않는 리뷰 등급이나 가격을 추가합니다. Google 은 이를 명시적으로 금지하고 이에 대한 수동 작업을 발행할 수 있습니다. 두 번째는 중첩된 개체의 잘못된 유형입니다, 일반적으로 실종입니다 @type 주소나 제안에. 세 번째는 유사한 유형을 융합합니다를 사용하는 것처럼 Product 단일 제품이 아닌 카테고리 리스팅 페이지의 마크업. 그리고 네번째,제 개인적인 적은 손 편집의 구문 오류입니다 - 전체 블록을 무효화하는 후행 쉼표 또는 이스케이프되지 않은 따옴표입니다.
이 모든 것이 발전기가 그 유지율을 얻는 이유입니다. 그것은 당신의 가격이 페이지에 보이는지 알 수 없습니다 - 즉 당신에게 있습니다 - 그러나 그것은 결코 후행 쉼표, 누락을 방출하지 않을 것입니다 @type또는 빈 속성입니다. 그것만으로도 구조화된 데이터가 자동으로 실패하는 대부분의 방법이 제거됩니다. 이러한 종류의 툴링과 관련된 개발자 워크플로에 대한 더 깊은 배경 지식을 얻으려면 코딩 도구 가이드 는 좋은 동반자 읽기.
자주 묻는 질문
스키마 마크업이란 무엇입니까?
스키마 마크업은 공유 schema.org 어휘를 사용하여 검색 엔진에 page's 콘텐츠를 설명하는 구조화된 데이터입니다. 추가하면 FAQ 아코디언,제품 가격,리뷰 별,브레이크크럼과 같은 풍부한 결과를 얻을 수 있는 페이지를 만들 수 있습니다. 이 도구가 생성하는 형식인 JSON-LD 는 보이는 HTML 과는 별개로 단일 스크립트 태그에 살고 있기 때문에 Google 이 권장하는 구문입니다.
JSON-LD, 마이크로데이터, RDFA의 차이점은 무엇입니까?
세 가지 모두 Schema.org 구조화된 데이터를 페이지에 추가하는 방법입니다. MicroData와 RDFA는 가시적인 HTML에 짜여진 속성이며, JSON-LD는 스크립트 태그에서 JSON의 독립형 블록입니다. Google은 페이지 마크업에서 추가, 업데이트 및 별도로 유지하기가 더 쉽기 때문에 JSON-LD를 권장합니다. 이 도구는 이러한 이유로 JSON-LD를 출력합니다.
생성된 JSON-LD는 어디에 두어야 합니까?
가득 붙여넣기 <script type="application/ld+json"> 태그를 입력하세요 <head> 설명하는 페이지 또는 페이지의 어느 곳에서나 <body> - Google 은 어느 위치에서나 읽습니다. Google 태그 관리자를 사용하는 경우 JSON 을 복사하고 사용자 정의 HTML 태그를 통해 추가합니다. 항상 마크업을 모든 곳에 적용하는 템플릿이 아니라 설명하는 콘텐츠가 있는 동일한 페이지에 마크업을 배치합니다.
스키마 마크업을 추가하면 풍부한 결과가 보장됩니까?
...이 아닌 . 구조화된 데이터는 페이지를 다양한 결과에 적합하게 만들지만, Google은 품질, 관련성 및 자체 지침을 기반으로 표시할지 여부를 결정합니다. 마크업은 페이지에 실제로 표시되는 콘텐츠도 반영해야 합니다. 스키마를 켜는 스위치가 아니라 풍부한 결과를 위한 요구 사항으로 생각하십시오.
내 구조화된 데이터를 어떻게 테스트합니까?
생성된 마크업을 Google's Rich Results Test 와 Schema Markup Validator (schema.org's validator) 를 통해 실행합니다. 둘 다 JSON-LD 를 구문 분석하고 누락된 필수 필드 또는 구문 오류를 보고합니다. 페이지가 라이브가 된 후 Google Search Console 향상 보고서는 구조화된 데이터가 시간에 따라 어떻게 작동하는지 추적합니다.
각 유형에 필요한 필드는 무엇입니까?
요구 사항 유형에 따라 다릅니다. 기사에는 제목이 필요하고, 제품에는 이름이 필요하고, 이벤트에는 이름과 시작 날짜가 필요하며, FAQPage에는 최소한 하나의 질문과 답변이 필요합니다. 이 도구는 필수 필드를 표시하고 채워질 때까지 출력을 차단하는 동시에 풍부한 결과를 얻을 가능성을 높이는 권장 필드에 대해 경고합니다.
내 페이지에 대한 FAQ 스키마를 생성할 수 있습니까?
네. FAQPage 유형을 선택하고 각 질문에 답을 추가하면 도구가 MainEntity 질문 및 답변 개체의 배열을 자동으로 빌드합니다. Google은 이제 주로 권위 있는 정부 및 의료 사이트에 대해 FAQ가 풍부한 결과를 표시하지만 마크업은 다른 검색 엔진 및 AI 응답 엔진에 대해 유효하고 유용합니다.
내 데이터가 비공개로 유지됩니까?
예. JSON-LD 는 일반 JavaScript 로 브라우저에서 완전히 조립됩니다. 미공개 가격,이벤트 세부 정보 또는 개인 URL 을 포함하여 입력하는 모든 항목이 전송,기록 또는 저장되며 생성기는 한 번 로드된 네트워크 연결 없이 계속 작동합니다.
