AI 노출을 위한 Schema.org: 현재 중요한 마크업은 무엇인가

인공지능 노출을 위한 Schema.org: 현재 중요한 마크업은 무엇인가

2026년 9월 5일 현재, 구조화된 데이터는 여전히 검색 엔진이 페이지, 작성자, 조직 및 사실을 이해하는 데 도움이 됩니다. 그러나 인공지능 답변에 대한 직접적인 순위 결정 스위치는 아닙니다.

Google은 AI 개요(AI Overviews) 또는 **AI 모드(AI Mode)**에 나타나기 위해 페이지에 특별한 Schema.org 마크업이 필요하지 않다고 명시합니다. 페이지는 주로 크롤링 가능하고, 색인되어야 하며, 검색 스니펫에 적합해야 하고, 유용한 콘텐츠로 뒷받침되어야 합니다. Google은 또한 구조화된 데이터가 페이지의 보이는 콘텐츠와 일치해야 한다고 말합니다. (developers.google.com)

따라서 현재의 최선의 전략은 다음과 같습니다:

1. 페이지를 정확하게 설명하기 위해 구조화된 데이터를 사용합니다.
2. 마크업을 페이지의 진정한 목적과 일치시킵니다.
3. 기사, 작성자, 조직 및 주제 간에 명확한 관계를 구축합니다.
4. 보이는 HTML에 직접적이고 완전한 답변을 작성합니다.
5. 인공지능 인용을 전통적인 리치 결과와 분리하여 측정합니다.

주요 결론

광범위한 연구 결과는 중요합니다: 일반적인 구조화된 데이터만 추가하는 것으로는 인공지능 인용이 지속적으로 증가하지 않았습니다. 통제된 Ahrefs 연구는 JavaScript Object Notation for Linked Data를 추가한 1,885개 페이지와 4,000개의 대조 페이지를 추적했습니다. 이 연구는 Google AI 모드 또는 ChatGPT 인용에서 의미 있는 개선을 찾지 못했습니다. Google AI 개요 인용은 약간 감소했지만, 연구원들은 그 변화가 작았고 마크업 때문이라고 명확하게 비난할 수 없다고 경고했습니다. (ahrefs.com)

별도의 2026년 사전 인쇄본(preprint)에서는 Article, Organization, BreadcrumbList, WebPage와 같은 일반적인 유형이 검색 순위 및 도메인 권한을 통제한 후 인공지능 인용을 독립적으로 예측하지 못했다고 밝혔습니다. 가장 강력한 발견은 가격, 등급, 사양과 같이 구체적이고 속성이 풍부한 데이터를 포함하는 페이지가 일반적인 페이지 레이블만 있는 페이지보다 더 나은 성능을 보였다는 것입니다. 이 발견은 주로 제품 및 리뷰 페이지에 초점을 맞추었으므로, 이 기사의 어떤 유형이라도 인용 우위를 만든다는 증거로 간주해서는 안 됩니다. (aixiv.science)

구조화된 데이터가 할 수 있는 것과 할 수 없는 것

구조화된 데이터는 기계가 읽을 수 있는 페이지 설명입니다. 검색 엔진에 다음을 알려줄 수 있습니다:

• 페이지 유형
• 누가 작성했는지
• 어떤 조직이 게시했는지
• 어떤 질문에 답하는지
• 언제 게시 또는 업데이트되었는지
• 페이지가 어떤 사람, 회사, 용어 또는 데이터 세트를 설명하는지

Google은 구조화된 데이터가 시스템이 페이지 콘텐츠를 이해하고 페이지를 더 풍부한 검색 기능에 적합하게 만드는 데 도움이 될 수 있다고 말합니다. 또한 Google 검색은 해당 속성이 보이는 검색 결과를 트리거하지 않더라도 이해를 위해 다른 Schema.org 속성을 사용할 수 있다고 말합니다. (developers.google.com)

구조화된 데이터는 다음을 보장하지 않습니다:

• 더 높은 유기적 순위
• 인공지능 인용
• 리치 결과
• 지식 패널
• 인공지능 답변에 포함
• 마크업의 정확한 텍스트 사용

Bing도 유사한 지침을 제공합니다. 현재 Bing 웹마스터 지침은 구조화된 데이터가 더 명확한 근거를 제공할 수 있지만, 가시성이나 인용 트래픽을 보장하지는 않는다고 말합니다. Bing은 또한 게시자에게 보이는 페이지 콘텐츠에 사실과 정의를 명시적으로 표시하도록 조언합니다. (bing.com)

주요 연구 한계

인공지능 답변 패널은 일반적으로 소스 페이지를 보여주며, 해당 페이지에 있을 수 있는 Schema.org 유형을 보여주지 않습니다. Google은 예를 들어 페이지가 Article을 사용했기 때문에 WebPage 대신 인용되었다고 보고하지 않습니다.

이것은 세 가지 다른 질문을 만듭니다:

1. 페이지가 인용되었는가?
2. 페이지에 구조화된 데이터가 포함되어 있었는가?
3. 구조화된 데이터가 인용을 유발했는가?

대부분의 연구는 처음 두 가지 질문에만 답할 수 있습니다. 세 번째 질문은 증명할 수 없습니다.

이것이 FAQPage 마크업이 있는 페이지가 마크업이 이유가 아님에도 불구하고 인공지능 답변에 자주 나타날 수 있는 이유입니다. 해당 페이지는 강력한 콘텐츠, 높은 검색 순위, 많은 링크 또는 잘 알려진 브랜드를 가질 수 있습니다.

스키마 유형별 감사

1. Article

기능

Article은 기사, 뉴스 스토리, 블로그 게시물 또는 유사한 편집 페이지를 설명합니다. Google은 Article, NewsArticle, BlogPosting을 기사 유형으로 지원합니다. Google은 기사 마크업에 대한 필수 속성을 나열하지 않지만, 페이지에 적용되는 속성을 추가할 것을 권장합니다. (developers.google.com)

가장 중요한 속성

다음 속성이 보이고 정확할 때 사용하세요:

• headline
• author
• author.name
• author.url 또는 author.sameAs
• datePublished
• dateModified
• image
• publisher
• mainEntityOfPage
• about
• inLanguage

Google은 작성자로 실제 Person 또는 Organization을 사용할 것을 권장합니다. 또한 구조화된 데이터의 날짜가 보이는 게시 및 업데이트 날짜와 일치하도록 유지할 것을 권장합니다. (developers.google.com)

인공지능 효과

증거 수준: 간접적.

Article은 페이지 유형, 작성자, 최신성을 확립하는 데 도움이 됩니다. 이들은 검색 시스템, 특히 사실 정보 페이지 및 편집 콘텐츠에 유용한 신호입니다. 그러나 현재 증거는 Article을 추가하는 것만으로 인공지능 인용이 증가한다는 것을 보여주지 않습니다.

Article 체크리스트

• 페이지가 진정으로 기사인가.
• 헤드라인이 보이는 제목과 일치하는가.
• 보이는 모든 작성자가 포함되었는가.
• 각 작성자가 별도의 Person 또는 Organization 객체를 가지고 있는가.
• 작성자 이름에 직책이나 게시자 이름이 아닌 이름만 포함되어 있는가.
• 작성자가 실제 프로필 또는 작성자 페이지로 연결되는가.
• 게시 및 업데이트 날짜가 페이지에 보이는가.
• 날짜에 시간이 포함된 경우 올바른 시간대를 사용하는가.
• 이미지가 기사를 대표하는가.
• 게시자가 사이트 전체에서 일관되게 식별되는가.
• 페이지가 실제로 두 가지 목적을 모두 수행하지 않는 한, HowTo와 같은 다른 기본 유형으로 마크업되지 않았는가.

2. WebPage

기능

WebPage는 일반적인 페이지 유형입니다. Schema.org는 모든 웹 페이지가 암묵적으로 WebPage로 처리되지만, 페이지에 페이지 수준 속성이나 관계가 포함될 때 명시적인 선언이 도움이 될 수 있다고 명시합니다. (schema.org)

유용한 속성은 다음과 같습니다:

• url
• name
• description
• inLanguage
• dateModified
• breadcrumb
• mainEntity
• about
• isPartOf
• primaryImageOfPage

인공지능 효과

증거 수준: 낮고 간접적.

WebPage는 연결된 그래프에서 외부 페이지 계층으로 가장 잘 사용됩니다. 페이지를 주요 기사, 정의, 데이터 세트, 인물 또는 조직에 연결할 수 있습니다.

특별한 인공지능 최적화 유형으로 취급되어서는 안 됩니다. 일반적인 WebPage 객체만 포함하는 페이지는 주요 엔티티를 명확하게 식별하는 페이지보다 덜 유용한 정보를 제공하는 경우가 많습니다.

WebPage 체크리스트

• 페이지에 하나의 안정적인 @id를 사용하는가.
• 페이지 URL로 표준 URL을 사용하는가.
• 페이지의 진정한 mainEntity를 식별하는가.
• mainEntityOfPage로 주요 엔티티를 페이지로 다시 연결하는가.
• inLanguage를 아는 경우 추가하는가.
• 페이지 이름과 설명을 보이는 콘텐츠와 일치시키는가.
• 페이지가 실제로는 기사, 프로필, 데이터 세트 또는 질문 페이지라는 사실을 숨기기 위해 WebPage를 사용하지 않는가.

3. QAPage

기능

QAPage는 하나의 질문과 그 답변에 초점을 맞춘 페이지를 위한 것입니다. Google은 QAPage로 표시된 페이지의 Question 구조화된 데이터를 사용하며, 페이지에는 하나의 QAPage와 하나의 주요 Question만 있어야 한다고 말합니다. (developers.google.com)

필수 속성

현재 Google 질문-답변 자격 기준:

• QAPage.mainEntity
• 중첩된 Question
• Question.answerCount
• acceptedAnswer 또는 suggestedAnswer 중 하나
• Answer.text

답변이 없는 질문은 리치 결과 자격이 없습니다.

중요한 콘텐츠 규칙

QAPage는 다음에는 사용하지 마세요:

• 일반적인 자주 묻는 질문 페이지
• 질문에 답하는 블로그 게시물
• 방법(how-to) 기사
• 여러 질문이 포함된 제품 페이지
• 사이트 소유자만 작성한 편집 답변

Google은 일반적인 QAPage의 경우 사용자가 답변을 제출할 수 있어야 한다고 말합니다. 유효한 예시로는 포럼 질문 또는 사용자가 답변을 제공할 수 있는 지원 페이지가 있습니다. (developers.google.com)

인공지능 효과

증거 수준: 중간 정도의 의미론적 적합성, 인과적 상승 효과는 입증되지 않음.

실제 질문-답변 페이지는 검색 시스템이 자연스럽게 이해하기 쉽습니다. 그러나 QAPage 마크업 자체가 인공지능 인용을 증가시킨다는 강력한 공개 연구는 없습니다.

QAPage 체크리스트

• 페이지가 하나의 질문에 초점을 맞추는가.
• 페이지가 특별 교육 질문-답변 경험에 해당하는 경우가 아니라면, 사용자가 답변을 제출할 수 있는가.
• 전체 질문이 보이는가.
• 전체 답변 텍스트가 보이는가.
• answerCount가 실제 답변 수와 일치하는가.
• 채택된 답변과 제안된 답변이 올바르게 레이블링되었는가.
• 댓글이 답변이 아닌 댓글로 표시되었는가.
• 페이지가 단순히 편집적인 자주 묻는 질문 페이지가 아닌가.
• 페이지에 여러 개의 관련 없는 질문이 포함되어 있지 않은가.

QAPage 예시

html

이 패턴은 페이지가 진정으로 질문-답변 상호작용을 지원할 때만 사용하세요.

4. HowTo

기능

HowTo는 단계별 지침을 설명합니다. Google은 한때 How-to 리치 결과를 지원했지만, 2023년 9월에 해당 검색 기능을 지원 중단했습니다. Google은 How-to 결과가 더 이상 데스크톱에 나타나지 않으며 이미 모바일 검색에서 제거되었다고 밝혔습니다. (developers.google.com)

인공지능 효과

증거 수준: Google의 경우 낮음.

보이는 단계들은 여전히 사용자 및 검색 시스템에 도움이 될 수 있습니다. 제목, 번호가 매겨진 단계, 도구, 시간 및 경고가 포함된 명확한 튜토리얼은 읽고 인용하기 더 쉽습니다. 그러나 현재 증거는 HowTo 마크업이 Google AI 개요 또는 AI 모드에서 특별한 이점을 창출한다는 것을 보여주지 않습니다.

권장 사항

HowTo는 다음 경우에만 사용하세요:

• 페이지가 진정으로 작업을 가르치는 경우.
• 단계가 페이지 콘텐츠에 보이는 경우.
• 다른 검색 엔진, 플랫폼 또는 내부 시스템이 마크업으로부터 이점을 얻는 경우.
• 팀이 충돌하는 데이터를 생성하지 않고 유지 관리할 수 있는 경우.

Google 검색의 경우, 강력한 HTML 제목, 번호가 매겨진 목록, 명확한 지침, 유용한 이미지 또는 동영상에 우선순위를 두세요.

튜토리얼 체크리스트

• 페이지가 실제 작업을 가르치는가.
• 작업의 결과가 명확한가.
• 각 단계가 보이는가 완전한가.
• 단계 이름이 보이는 제목과 일치하는가.
• 도구와 재료가 실제이며 보이는가.
• 예상 시간이 정확한가.
• 필요한 경우 안전 경고가 포함되었는가.
• 첫 번째 섹션이 짧은 답변 또는 결과를 제공하는가.
• 페이지가 지침을 제공하기 위해 마크업에만 의존하지 않는가.

5. ClaimReview

기능

ClaimReview는 사실 확인 콘텐츠를 위해 설계되었습니다. Google은 검색 결과를 단순화하려는 2025년 노력의 일환으로 검색에서 Claim Review 지원을 단계적으로 폐지했습니다. 이 유형은 Search Console 보고 및 리치 결과 테스트에서 제거되었습니다. (developers.google.com)

인공지능 효과

증거 수준: 현재 Google 이점 없음.

고품질 사실 확인은 다음을 명확하게 명시하기 때문에 여전히 인용될 수 있습니다:

• 주장
• 평가
• 증거
• 날짜
• 사실 확인 조직
• 결론의 근거

이러한 이점은 주로 콘텐츠 자체에서 비롯되며, 지원이 중단된 Google 검색 기능에서 오는 것이 아닙니다.

권장 사항

사실 정보 페이지의 경우:

1. 페이지가 편집 콘텐츠인 경우 Article 또는 NewsArticle을 사용하세요.
2. 보이는 텍스트에 주장을 명확하게 명시하세요.
3. 1차 증거를 인용하세요.
4. 작성자와 검토 조직을 식별하세요.
5. 게시 및 검토 날짜를 추가하세요.
6. 다른 플랫폼 또는 데이터 시스템이 특별히 요구하는 경우에만 ClaimReview를 사용하세요.

Google 인공지능 답변이 선호할 것이라고 기대하여 ClaimReview를 추가하지 마세요.

6. FAQPage

기능

FAQPage는 질문과 공식 답변이 포함된 페이지를 설명합니다. Google은 2026년 5월 7일부터 검색에서 FAQ 리치 결과 표시를 중단했으며, 2026년 6월에는 관련 문서를 제거했습니다. (developers.google.com)

인공지능 효과

증거 수준: 약하고 혼재됨.

90일간의 벤더 연구는 120개 페이지에 FAQPage 마크업을 추가했습니다. 이 연구는 ChatGPT, Gemini 또는 Google AI 개요 인용에서 신뢰할 수 있는 개선을 찾지 못했습니다. Perplexity는 약간 증가했지만, 연구 자체는 이 결과가 플랫폼별이며 인과 관계를 증명하지 못한다고 말했습니다. (authorityradar.com)

이미 인용된 615개 페이지를 대상으로 한 또 다른 연구에서는 FAQ 마크업이 자주 인용되는 페이지에서 더 자주 나타난다는 것을 발견했습니다. 그러나 동일한 게시자의 반복된 페이지를 통제한 후에는 이 관계가 사라졌습니다. 연구원들은 이 증거가 마크업 자체의 효과를 확립하지 못했다고 결론지었습니다. (getintel.ai)

권장 사항

독자를 위해 페이지를 개선하는 경우 자주 묻는 질문을 사용하세요. 인공지능 답변을 목표로 단순히 일반적인 질문을 대량으로 추가하지 마세요.

다른 검색 엔진 또는 콘텐츠 시스템을 위해 FAQPage 마크업을 유지하는 경우:

• 모든 질문을 보이게 만드세요.
• 모든 답변을 완전하게 만드세요.
• 마크업을 페이지와 동일하게 유지하세요.
• 여러 스키마 블록에서 동일한 질문을 반복하지 마세요.
• Google FAQ 리치 결과를 기대하지 마세요.

Google 이외의 소비자를 위한 FAQPage 예시

html

이것은 의미론적 설명이며, Google 검색 기능에 대한 약속이 아닙니다.

7. Organization

기능

Organization은 Google이 회사, 비영리 단체, 게시자, 학교 또는 기타 조직을 이해하고 모호성을 해소하는 데 도움을 줍니다. Google은 조직 마크업이 검색에 표시되는 로고 및 일부 지식 패널 정보와 같은 시각적 요소에 영향을 미칠 수 있다고 말합니다. Google의 현재 조직 가이드에는 필수 속성이 없습니다. (developers.google.com)

권장 속성

사실이고 보이는 속성을 사용하세요:

• name
• alternateName
• url
• logo
• sameAs
• description
• telephone
• email
• address
• identifier
• foundingDate
• parentOrganization

인공지능 효과

증거 수준: 간접적이지만 유용함.

Organization은 다음을 연결할 수 있습니다:

• 게시자를 기사에
• 회사를 제품 또는 서비스에
• 브랜드를 공식 프로필에
• 조직을 알려진 웹 아이덴티티에

이것은 엔티티 모호성 해소에 유용합니다. 인공지능 시스템이 페이지를 인용할 것이라고 증명하지는 않습니다.

Organization 체크리스트

• 전체 조직 객체를 홈 페이지 또는 조직 페이지에 배치하는가.
• https://www.example.com/#organization과 같은 안정적인 @id를 사용하는가.
• 정확한 공개 조직 이름을 사용하는가.
• sameAs로 실제 공식 프로필에 연결하는가.
• 적절할 때 올바른 조직 하위 유형을 사용하는가.
• 조직을 대표하는 실제 로고를 사용하는가.
• 연락처 정보를 최신 상태로 유지하는가.
• 모든 페이지에서 충돌하는 버전을 다시 만들지 않고 기사에서 조직을 참조하는가.

8. Person

기능

Person은 페이지를 작성, 검토, 소유, 관리 또는 등장하는 사람을 식별합니다. 일반적으로 다음 항목과 연결될 때 가장 유용합니다:

• Article.author
• QAPage 질문 또는 답변 작성자
• ProfilePage.mainEntity
• Organization.employee
• Review.author

Google의 프로필 지침은 프로필 페이지가 한 사람 또는 조직에 초점을 맞춰야 한다고 말합니다. ProfilePage 객체는 mainEntity를 요구하며, 이 엔티티는 Person 또는 Organization이어야 합니다. 사람 또는 조직은 name을 가져야 하며, 이름이 없는 경우 alternateName을 가져야 합니다. (developers.google.com)

권장 속성

• name
• url
• sameAs
• image
• description
• jobTitle
• worksFor
• knowsAbout
• affiliation
• identifier

인공지능 효과

증거 수준: 간접적.

Person 마크업은 작성자의 이름을 다음에 연결하는 데 도움이 될 수 있습니다:

• 약력
• 직업 또는 역할
• 조직
• 게시된 기사
• 외부 프로필
• 전문 분야

페이지가 뒷받침하지 않는 전문성을 주장하기 위해서가 아니라, 정체성을 명확하게 하기 위해 사용하세요.

Person 체크리스트

• Person을 실제 인물에 대해서만 사용하는가.
• 회사 또는 출판물에 Organization을 사용하는가.
• 인물을 보이는 작성자 페이지에 연결하는가.
• sameAs를 정확하고 공식적인 프로필에만 사용하는가.
• 직책과 자격 증명을 최신 상태로 유지하는가.
• 주요 작성자뿐만 아니라 보이는 모든 작성자를 추가하는가.
• 기사 및 프로필 페이지 전체에서 동일한 @id를 사용하는가.

필수 속성 매트릭스

Google의 일반적인 지침은 불완전한 마크업의 많은 양보다 완전하고 정확한 데이터를 선호합니다. 또한 구조화된 데이터는 보이는 콘텐츠를 나타내야 하며, 올바른 마크업도 리치 결과를 보장하지는 않는다고 경고합니다. (developers.google.com)

사용 사례 구현 체크리스트

사실 정보 페이지

최상의 조합:

• WebPage
• Article 또는 NewsArticle
• Person
• Organization
• 다른 지원되는 소비자(플랫폼)만을 위한 선택적 ClaimReview

체크리스트:

• 페이지 상단 근처에 주요 사실을 명시하는가.
• 사실의 출처를 명시하는가.
• 1차 증거에 연결하는가.
• 발행일 및 최종 검토 날짜를 포함하는가.
• 작성자와 검토자를 식별하는가.
• 사실과 의견을 분리하는가.
• 페이지가 편집 콘텐츠인 경우 Article을 사용하는가.
• 현재 Google 검색 전술로 ClaimReview를 사용하지 않는가.

정의 페이지

최상의 조합:

• WebPage
• DefinedTerm
• 페이지가 긴 편집 설명인 경우 선택적 Article
• 전문가 또는 게시자가 책임자인 경우 Organization 또는 Person

DefinedTerm은 공식적인 정의가 있는 단어, 구문, 코드 또는 개념을 위한 것입니다. 주요 속성에는 name, description, termCode, inDefinedTermSet, sameAs가 포함됩니다. (schema.org)

체크리스트:

• 첫 번째 단락에서 정의를 제공하는가.
• 하나의 명확한 용어를 주요 엔티티로 사용하는가.
• 실제일 때만 대체 이름을 추가하는가.
• 적절할 때 신뢰할 수 있는 외부 정의에 연결하는가.
• 용어를 쉬운 언어로 설명하는가.
• 예시와 범위를 포함하는가.
• 관련 없는 용어 목록을 하나의 DefinedTerm으로 마크업하는 것을 피하는가.

튜토리얼

최상의 조합:

• WebPage
• 다른 소비자(플랫폼)가 필요할 때만 HowTo
• 튜토리얼이 편집 기사이기도 한 경우 Article
• 작성자를 위한 Person 및 Organization

체크리스트:

• 단계 전에 결과를 명시하는가.
• 번호가 매겨진 보이는 제목을 사용하는가.
• 각 단계가 하나의 행동에 초점을 맞추는가.
• 필요한 경우 도구, 재료, 시간 및 경고를 포함하는가.
• 도움이 되는 경우 이미지 또는 동영상을 추가하는가.
• JSON-LD에만 단계를 숨기지 않는가.
• Google 검색에서 How-to 리치 결과를 기대하지 않는가.

데이터 카탈로그

최상의 조합:

• WebPage
• DataCatalog
• Dataset
• DataDownload
• Organization

Schema.org는 Dataset을 구조화된 정보의 본문으로 정의하며, includedInDataCatalog 및 distribution과 같은 관계를 지원합니다. (schema.org)

Google은 2025년 후반에 데이터 세트 구조화된 데이터가 데이터 세트 검색에서 사용되며 일반적인 Google 검색 결과 기능이 아니라고 명확히 했습니다. 따라서 인공지능 인용 지름길이 아니라 데이터 검색 및 상호 운용성 계층으로 취급해야 합니다. (developers.google.com)

체크리스트:

• 각 데이터 세트에 안정적인 식별자를 부여하는가.
• 주제와 범위를 명시하는가.
• 게시자 또는 생성자를 포함하는가.
• 데이터가 다루는 날짜 범위를 추가하는가.
• 관련성이 있을 때 지리적 범위를 명시하는가.
• 라이선스 및 액세스 조건을 설명하는가.
• 각 다운로드 가능한 파일을 DataDownload로 추가하는가.
• 파일 형식 및 다운로드 URL을 포함하는가.
• 카탈로그 메타데이터를 실제 파일과 동기화하는가.
• 업데이트 빈도 및 최종 업데이트 날짜를 문서화하는가.

JSON-LD 예시: 사실 정보 페이지

이 예시는 페이지, 기사, 작성자, 게시자 및 주제를 연결합니다. 모든 값을 실제 페이지에 나타나는 정보로 바꾸십시오.

html

JSON-LD 예시: 정의 페이지

html

정의는 일반 페이지 텍스트로도 나타나야 합니다. 구조화된 데이터에만 정의를 배치하지 마세요.

JSON-LD 예시: 튜토리얼

Google의 How-to 리치 결과가 지원 중단되었으므로, 이 마크업은 다른 시스템을 위한 선택적 마크업으로 취급하세요. 보이는 페이지에는 여전히 전체 지침이 포함되어야 합니다.

html

JSON-LD 예시: 데이터 카탈로그

html

흔히 발생하는 구현 오류

일치하지 않는 스키마

가장 심각한 실수는 사용자가 볼 수 없는 콘텐츠를 마크업하는 것입니다. Google은 구조화된 데이터가 페이지의 진정한 표현이어야 하며, 오해를 불러일으키거나 숨겨진 콘텐츠는 페이지를 리치 결과에 부적합하게 만들 수 있다고 말합니다. (developers.google.com)

흔한 예시:

• 실제 단계가 포함되지 않은 기사를 HowTo로 마크업하는 것
• 기사가 사람이 작성했는데 회사를 작성자로 마크업하는 것
• 페이지에 나타나지 않는 FAQ 답변을 추가하는 것
• 미래 발행일을 사용하는 것
• 일반 블로그 게시물을 QAPage로 마크업하는 것
• 의견 기사에 ClaimReview를 추가하는 것

부실한 답변

구조화된 데이터는 빈 페이지를 채울 수 없습니다.

Answer.text 또는 acceptedAnswer 내의 짧고 모호한 답변은 강력한 출처를 만들지 않습니다. 보이는 콘텐츠는 다음을 수행해야 합니다:

• 질문에 직접적으로 답변
• 중요한 제한 사항 및 예외 설명
• 출처 명시
• 유용한 경우 날짜, 예시 또는 측정값 포함
• 문맥에서 벗어나 복사될 때 스스로 독립적으로 존재

Google의 인공지능 지침은 이상적인 페이지 길이가 없으며, 인공지능 시스템을 위해 콘텐츠를 작은 조각으로 나눌 필요가 없다고 말합니다. 더 나은 목표는 유용하고 완전하며 사람 중심의 콘텐츠입니다. (developers.google.com)

중복 엔티티

동일한 조직, 작성자 또는 페이지의 여러 충돌하는 버전을 게시하지 마세요.

부실한 구현:

• 홈 페이지에 이름이 하나인 Organization 객체 하나
• 모든 기사에 이름이 다른 두 번째 객체
• 작성자 페이지에 @id가 없는 세 번째 객체

더 나은 구현:

• 조직에 안정적인 @id 하나를 부여
• 각 작성자에게 안정적인 @id 하나를 부여
• 기사, 프로필 및 질문 페이지에서 해당 객체를 참조
• 이름, 로고, URL 및 외부 ID 링크를 일관되게 유지

중복 질문

다음에서 동일한 질문을 반복하지 마세요:

• FAQPage
• QAPage
• 기사 마크업
• 여러 보이는 페이지 섹션
• 여러 JSON-LD 블록

페이지의 주요 목적과 일치하는 스키마 유형을 사용하세요. 단일하고 명확한 답변이 여러 중복 마크업 블록보다 낫습니다.

잘못된 날짜

Google은 여러 출처를 사용하여 발행일 및 업데이트 날짜를 추정합니다. 보이는 날짜와 구조화된 날짜가 일치해야 한다고 권장하며, 미래 날짜나 페이지 자체와 관련된 날짜가 아닌 기사에서 논의된 사건과 관련된 날짜를 사용하는 것에 대해 경고합니다. (developers.google.com)

sameAs 과도한 사용

sameAs 링크는 동일한 실제 인물 또는 조직을 식별해야 합니다. 다음에 연결하지 마세요:

• 관련 없는 소셜 프로필
• 검색 결과 페이지
• 일반 디렉토리 목록
• 철자나 ID가 다른 페이지
• 조직이 통제하지 않는 프로필

JavaScript 전용 마크업

Google은 렌더링된 페이지에 추가된 구조화된 데이터를 처리할 수 있지만, JavaScript 전용 구현은 다른 크롤러 및 감사 도구가 감지하기 더 어려울 수 있습니다. 서버에서 렌더링된 JSON-LD 블록은 일반적으로 테스트 및 유지 관리가 더 쉽습니다. (developers.google.com)

실용적인 테스트 계획

마크업이 점진적인 효과를 가지는지 측정하려면 몇 가지 수동 검색에 의존하는 대신 통제된 테스트를 사용하세요.

변경 전

다음을 기록하세요:

• 대상 쿼리
• 현재 유기적 순위
• 인공지능 답변 표시 여부
• 인용된 페이지
• 사용 가능한 경우 인용 위치
• 검색 트래픽
• 전환
• 현재 구조화된 데이터
• 테스트 기간 동안 변경된 콘텐츠

테스트 중

• 한 번에 하나의 주요 마크업 변경 사항만 추가하세요.
• 콘텐츠, 내부 링크, 제목 및 백링크를 안정적으로 유지하세요.
• 변경 사항이 적용되지 않는 유사한 대조 페이지를 사용하세요.
• 변경 사항의 정확한 게시 날짜를 기록하세요.
• 크롤링 및 재처리될 때까지 충분히 기다리세요.

Ahrefs는 일치하는 대조군과 시차-차분(difference-in-differences) 방법을 사용했습니다. 그들의 접근 방식은 상관 관계가 인과 관계를 증명한다고 가정하기보다 구조화된 데이터를 테스트하려는 조직에 유용한 모델입니다. (ahrefs.com)

변경 후

다음을 추적하세요:

• Google Search Console 인공지능 성능 데이터
• Google AI 개요 인용
• Google AI 모드 인용
• Bing 웹마스터 도구 인공지능 인용
• 관련성이 있을 때 ChatGPT, Gemini 또는 Perplexity 인용
• 유기적 순위
• 검색 클릭
• 간접 전환

Google은 Search Console 성능 보고를 통해 인공지능 검색 트래픽을 보고합니다. Bing의 인공지능 성능 보고서는 인용된 페이지와 근거 쿼리를 보여주지만, 페이지가 선택된 이유나 답변 내에서 얼마나 중요한지는 보여주지 않습니다. (developers.google.com)

권장 구현 순서

대부분의 게시자에게 최선의 순서는 다음과 같습니다:

1. 보이는 콘텐츠를 먼저 수정합니다.
2. 크롤링 및 색인 생성을 안정적으로 만듭니다.
3. 실제 편집 페이지에 Article을 구현합니다.
4. Person 및 프로필 페이지로 작성자를 연결합니다.
5. Organization으로 게시자를 연결합니다.
6. WebPage를 깨끗한 페이지 수준 그래프 계층으로 사용합니다.
7. QAPage는 진정한 커뮤니티 질문에만 사용합니다.
8. 용어집 및 정의 페이지에 DefinedTerm을 사용합니다.
9. 데이터 리소스에 Dataset 및 DataCatalog를 사용합니다.
10. FAQPage, HowTo, ClaimReview는 Google 검색 기능이 제거되거나 지원 중단되었으므로 보조 또는 비Google 마크업으로 취급합니다.

결론

현재 가장 강력한 교훈은 간단합니다: Schema.org 마크업은 기계가 콘텐츠를 이해하는 데 도움이 되지만, 인공지능 답변으로 가는 보장된 길은 아닙니다.

가장 지속 가능한 구현은 많은 스키마 유형의 방대한 컬렉션이 아닙니다. 작고 정확한 엔티티 그래프입니다:

• Article은 편집 페이지를 설명합니다.
• Person은 작성자를 식별합니다.
• Organization은 게시자를 식별합니다.
• WebPage는 페이지를 주요 엔티티에 연결합니다.
• QAPage는 진정한 사용자 질문과 그 답변을 설명합니다.
• DefinedTerm은 정의를 명확히 합니다.
• Dataset 및 DataCatalog는 구조화된 데이터 리소스를 설명합니다.

명확한 의미를 추가하는 곳에 구조화된 데이터를 사용하십시오. 부실한 콘텐츠를 위장하거나, 보이는 텍스트를 중복하거나, Google이 더 이상 지원하지 않는 검색 기능을 모방하기 위해 사용하지 마십시오. 인공지능 노출을 위해서는 가장 가치 있는 작업이 여전히 명확한 답변, 강력한 증거, 정확한 엔티티, 최신 정보, 그리고 스스로 독립적으로 존재할 수 있는 콘텐츠입니다.