페이지를 기계용으로 라벨링하기: 스키마 유형, 예시 및 안전한 배포

AI 검색에 구조화 데이터가 중요한 이유

빠른 테스트: 페이지 URL 하나를 Schema.org 검증기에 붙여넣고 오류와 경고 수를 센 후 오류부터 수정하세요.

스키마 마크업은 페이지의 엔티티와 관계를 소프트웨어가 해석할 수 있는 형식으로 설명합니다. AI 검색 맥락에서 조직명, 제품 속성, 기사 작성자 같은 세부 정보를 명시적으로 만들어 산문에서 모든 관계를 추론해야 하는 부담을 줄여줍니다.

이 설명은 페이지 자체를 반영할 때만 유용합니다. 마크업은 전문성을 만들지 않으며, 카피의 공백을 채우지 않으며, 불명확한 제안을 독자가 이해할 수 있게 만들지 않습니다. 먼저 가시적 페이지부터 시작하세요: 주요 주제, 지원 사실, 페이지가 다루는 행동이나 질문을 식별합니다. 그런 다음 가장 적합한 schema.org 유형을 사용해 해당 사실을 마크업하세요.

실용적인 테스트는 페이지를 읽는 사람이 마크업된 모든 주장을 인식할 수 있는지 묻는 것입니다. 페이지에 제품 가격이 표시되지 않으면 구조화 데이터에 가격을 넣지 마세요. 기사에 작성자가 명시되면 페이지와 마크업에서 동일한 작성자 정보를 사용하세요. 기술적 세부 사항을 넘어 콘텐츠 계획에 대해서는 AI 어시스턴트용 인용 가능 콘텐츠 가이드를 참조하세요.

어떤 schema.org 유형이 중요한가

유용한 schema.org 유형은 가장 인상적으로 들리는 유형이 아니라 페이지를 정확히 나타내는 유형입니다. 각 URL의 주요 목적으로 시작하여 가시적 콘텐츠와 사이트 역할에 맞는 유형을 선택하세요.

이는 필수 번들이 아닌 시작점입니다. 회사 사이트는 적절한 페이지에 Organization을, 편집 페이지에 Article을 사용할 수 있으며, 제품 페이지는 실제로 제공하는 제품을 설명할 수 있습니다. 경쟁사가 사용하거나 생성기가 제공한다는 이유만으로 유형을 추가하지 마세요.

두 유형이 모두 가능해 보이면 페이지의 중심 주제를 가장 잘 설명하는 유형을 선택한 후 각 속성에 가시적 지원 콘텐츠가 있는지 확인하세요. 관련 기술 세부 사항은 기술 AEO: 스키마, llms.txt 및 크롤러를 참조하세요.

마크업 예시: 한 줄씩 살펴보기

유용한 예시는 작고 정확하며 가시적 페이지 콘텐츠와 연결됩니다. JSON-LD는 메인 본문 텍스트와 분리된 스크립트 블록에 구조화 데이터를 제공하는 방법입니다. 아래 샘플은 페이지 자체에서 하지 않는 주장을 추가하지 않고 기사를 설명합니다.

예시 구조: @context: https://schema.org; @type: Article; headline: 지갑 보안 실용 가이드; author: 예시 연구팀; about: 지갑 보안.

이것을 변경하지 않고 붙여넣을 코드가 아닌 적응할 형태로 사용하세요. 샘플 제목과 작성자를 실제 페이지에 표시된 세부 정보로 바꾸세요. 게시 전에 URL, 제목, 작성자 신원 및 구현의 다른 속성을 확인하세요. 기술적으로 유효하지만 부정확한 필드는 구조화된 설명의 신뢰성을 떨어뜨릴 수 있습니다.

서비스 페이지의 경우 추가 속성을 포함하기 위해 제품으로 라벨링하지 마세요. 유형을 실제 제공 사항과 페이지가 제시하는 정보에 맞추세요. 공식 Schema.org 문서에서 어휘 및 유형 정의를 검토할 수 있습니다.

llms.txt와 schema.org: 각각의 역할은?

Schema.org와 llms.txt는 다른 종류의 사이트 수준 신호입니다. 스키마 마크업은 구조화된 설명을 페이지 콘텐츠에 첨부하고, llms.txt 파일은 언어 모델 도구에 웹사이트와 리소스에 대한 간결한 오리엔테이션을 제공하기 위한 텍스트 문서입니다. 둘 중 하나가 유용하고 접근 가능한 페이지를 대체하지는 않습니다.

스키마의 경우 URL별로 작업하세요: 해당 페이지에 표시된 기사, 조직 또는 제품을 설명하세요. llms.txt의 경우 사이트의 더 넓은 지도를 생각하세요: 조직과 콘텐츠를 이해하는 데 가장 유용한 리소스는 무엇인가요? 파일을 간결하고 정확하며 유지 관리하기 쉽게 유지하세요. 오래된 URL이나 명시된 목적을 지원하지 않는 페이지를 나열하지 마세요.

각각 명확한 작업이 있을 때만 둘 다 사용하세요. 파일의 목적과 설정에 대한 자세한 내용은 llms.txt란 무엇이며 필요한가 및 llms.txt 및 AI 크롤러 설정 가이드를 읽어보세요.

7포인트 스키마 체크리스트

한 번에 하나의 템플릿에 대해 다음 7단계를 실행하세요. 하나의 수정된 템플릿이 수백 페이지를 복구할 수 있으므로 가장 많이 사용하는 템플릿부터 시작하세요.

• 페이지 유형을 나열하고 각각 하나의 스키마 유형을 선택하세요.
• 가시적 마크업과 분리된 JSON-LD를 작성하세요.
• 방문자가 볼 수 있는 것만 마크업하세요.
• 조직 이름을 모든 템플릿에서 동일하게 유지하세요.
• 릴리스 전에 모든 템플릿을 검증하세요.
• 각 사이트 업데이트 후 재검증하세요.
• 오류를 시트에 기록하고 주당 3개를 수정하세요.

한 줄 용어

JSON-LD (쉽게 말해: 가시적 페이지와 별도로 구조화 데이터를 전달하는 스크립트 블록).

스키마 유형은 페이지가 무엇에 관한 것인지 말해주는 Organization 또는 Product와 같은 라벨을 의미합니다.

구현은 어떻게 하나요?

흔한 실수: 보이지 않는 콘텐츠를 마크업하는 것. 방문자가 볼 수 없으면 라벨을 붙이지 마세요.

스키마 마크업을 구현하려면 각 페이지의 가시적 콘텐츠를 정확한 구조화된 설명에 연결한 후 게시 후 결과를 확인하세요. 작고 반복 가능한 워크플로우는 템플릿 오류가 사이트 전체로 퍼지는 것을 방지하는 데 도움이 됩니다.

페이지 인벤토리로 시작하세요. URL, 페이지 목적, 주요 엔티티, 페이지에 명시적으로 표시된 사실을 기록하세요. 그런 다음 각 페이지를 적절한 유형에 매핑하고 해당 콘텐츠가 지원하는 속성만 포함하세요. 마크업이 사이트 플랫폼, 템플릿 또는 코드 변경을 통해 어떻게 추가될지 결정하고 페이지가 변경될 때 업데이트를 검토할 담당자를 지정하세요.

릴리스 전에 렌더링된 페이지와 JSON-LD를 비교하세요. 이름, 제목, 설명 및 관계가 일치하는지 확인하고 스크립트가 의도된 URL에 있는지 확인하며 관련 검증 도구를 사용해 구문 또는 적격성 문제를 찾으세요. 페이지 템플릿 변경 후 대표 URL에서 해당 확인을 반복하고 둘 이상의 페이지 유형을 검사하세요.

llms.txt 구현 방법을 묻는다면 별도 작업으로 처리하세요: 파일의 목적에 동의하고, 현재 고가치 리소스를 수집하며, 최신 상태를 유지할 책임자를 지정하세요. 페이지별 스키마나 명확한 편집 콘텐츠의 대체물로 취급하지 마세요.

마크업이 도움이 되는지 확인하기

스키마 품질을 두 가지 별도 검토로 확인하세요: 먼저 코드가 정확하고 사용 가능한지 확인한 다음, 중요한 페이지가 검색 및 AI 답변에서 올바르게 표현되는지 검토하세요. 깨끗한 검증 결과는 기술적 확인일 뿐, 그 자체로 페이지가 인용될 증거는 아닙니다.

기술 검토의 경우 마크업이 의도된 페이지에 있는지, 구문을 읽을 수 있는지, 속성이 가시적 콘텐츠와 일치하는지 검사하세요. URL, 유형, 검토 날짜, 발견된 문제 및 수정 책임자를 기록하세요. 이렇게 하면 나중에 템플릿 변경을 진단하기 쉬워집니다.

노출 검토의 경우 일관된 관련 질문 세트를 모니터링하고 ChatGPT 및 Perplexity 같은 도구의 응답에 어떤 페이지나 출처가 나타나는지 기록하세요. 브랜드가 정확히 설명되는지, 인용된 페이지가 관련 있는지, 답변이 중요한 사실을 누락하는지 기록하세요. 이러한 관찰을 방향성 요약으로 취급하세요: 답변 표현과 출처는 달라질 수 있으므로 단일 응답은 신뢰할 수 있는 측정이 아닙니다.

콘텐츠가 불완전하거나 해석하기 어려운 경우 발견 사항을 사용해 페이지 자체를 개선하세요. 더 넓은 평가를 위해 AI 검색 모니터링 및 AI 답변을 위한 FAQ 최적화 가이드를 참조하세요.

마크업에서 기대할 수 있는 것

스키마 마크업은 페이지가 말하는 내용을 명확히 할 수 있지만, 약한 콘텐츠를 유용하게 만들거나 AI 시스템이 사용할 출처를 지시할 수는 없습니다. 적절한 기대는 페이지와 일치하고 팀이 확인할 수 있는 더 잘 구조화된 정보입니다.

ChatGPT와 Perplexity는 페이지를 검색, 인용, 요약 또는 생략할지 독립적으로 결정하며, 출처 선택과 답변 렌더링은 통제 밖입니다. Google도 구조화 데이터가 포함되었다고 해서 특정 검색 표시를 보장하지 않습니다. 약속된 배치가 아닌 정확성과 유지 관리 가능성을 중심으로 구현을 구축하세요.

마크업을 게시하거나 확장하기 전에 다음 항목을 확인하세요:

• 선택한 유형이 페이지의 실제 목적에 맞는지.
• 모든 속성이 가시적이고 최신 콘텐츠로 지원되는지.
• 마크업이 의도된 URL에 배포되고 템플릿 변경 후 검토되는지.
• 명명된 담당자가 페이지 사실이 변경될 때 업데이트할 수 있는지.

편집 검토를 위해 MarketingExtra는 페이지의 가시적 주장과 구조화된 설명을 비교하여 팀에 불일치를 알릴 수 있습니다. 시작하려면 URL과 페이지의 주요 대상 또는 목적을 보내주세요. 다음 단계는 가시적 사실을 적절한 스키마 유형에 매핑하는 것입니다.

이용 방법

1. 페이지 인벤토리 작성중요한 URL을 나열하고 각 페이지의 목적, 주요 주제 및 가시적 사실을 기록하세요. 페이지 수준 마크업 요구 사항을 llms.txt 같은 사이트 전체 문서와 분리하세요.
2. 적합한 유형 선택각 페이지를 실제 콘텐츠를 설명하는 schema.org 유형에 매핑하세요. 단순히 사용 가능하다는 이유로 속성을 추가하지 마세요.
3. JSON-LD 초안 작성 및 구현페이지에 이미 표시된 정보로 구조화된 설명을 만든 후 적절한 사이트 템플릿 또는 구현 경로를 통해 추가하세요.
4. 코드와 페이지 비교게시된 URL, 가시적 카피 및 구조화 데이터를 함께 확인하세요. 일치하지 않는 이름, 설명, 관계 또는 지원되지 않는 주장을 수정하세요.
5. 변경 후 검토콘텐츠 또는 템플릿 업데이트 후 영향을 받는 URL을 재확인하고 문제 및 해결 기록을 유지하세요. AI 답변은 기술적 검증과 별도로 모니터링하세요.