schema.org AI 최적화: 지금 보고 계신 페이지부터 시작하는 가이드

페이지 레이블은 방문자가 볼 수 있는 페이지와 일치해야 합니다

Schema.org 마크업은 소프트웨어에 페이지와 그 주제에 대한 구조화된 설명을 제공합니다. 페이지가 이미 말하고 있는 내용을 설명해야 하며, 방문자가 확인할 수 없는 주장을 추가해서는 안 됩니다.

먼저 페이지의 목적과 주요 엔티티를 기록하세요. 그런 다음 가장 적합한 간단한 유형을 선택하세요. 프로젝트 소개 페이지와 제품 페이지는 같은 웹사이트에 있더라도 서로 대체할 수 없습니다. 이는 AI 노출을 위한 schema.org 마크업의 유용한 첫 번째 점검 사항을 제공합니다. 사람이 각 마크업된 사실 뒤에 있는 가시적인 콘텐츠를 가리킬 수 있습니까?

지원되지 않는 속성으로 가득 찬 복잡한 레코드보다는 팀이 유지 관리할 수 있는 작은 세트를 선호합니다. 기술 작업에 대한 더 넓은 시각은 기술 AEO 가이드를 참조하세요.

사람들이 이미 묻는 프로젝트 세부 정보부터 시작하세요

첫 출시가 조용했던 창업자를 상상해 보세요. 답변할 수 있는 유일한 사람이 휴가를 갔고, 새로운 방문자는 여전히 프로젝트에 대한 명확한 세부 정보가 필요합니다.

큰 마크업 템플릿이 아닌, 방문자가 필요로 하는 페이지부터 시작합니다. 프로젝트 이름, 제품 설명, 연락처 세부 정보가 사이트에 명확하게 표시되는지 확인합니다. 그런 다음 표시된 사실만 적절한 schema.org 속성에 매핑합니다. 페이지가 진실의 원천이며, 마크업은 이를 따릅니다.

프로젝트에 제품 페이지와 짧은 설명 기사가 있다고 가정해 보세요. 제품 페이지가 실제로 제품을 설명한다면 Product를 지원할 수 있습니다. 설명 기사는 작성자와 편집 세부 정보가 표시될 때 Article에 적합할 수 있습니다. 페이지가 필드를 지원하지 않으면 생략하고 프로젝트 담당자에게 먼저 출처를 명확히 해 달라고 요청하세요.

이렇게 하면 작업을 인계하기도 더 쉬워집니다. 팀원은 각 필드와 페이지 간의 연결을 따라 추가된 이유를 추측하지 않아도 됩니다. 유용한 소스 페이지를 만드는 방법에 대한 자세한 내용은 AI 어시스턴트를 위한 인용 가능한 콘텐츠를 방문하세요.

프로젝트 사이트의 다양한 부분에 적합한 스키마 유형은 무엇인가요?

올바른 스키마 유형은 특정 페이지가 나타내는 내용에 따라 달라집니다. 프로젝트 웹사이트는 각각이 표시된 콘텐츠를 반영하는 한 여러 URL에 걸쳐 여러 유형을 사용할 수 있습니다.

사이트와 페이지부터 시작하세요

Organization은 프로젝트나 회사를 설명할 수 있습니다. WebSite는 웹사이트 전체를 설명하고, WebPage는 개별 URL을 설명합니다. 이러한 유형은 관계가 실제이고 명확할 때 연결될 수 있습니다. 페이지와 마크업 전반에 걸쳐 이름과 공개 세부 정보를 일관되게 유지하세요.

콘텐츠별 유형은 적합한 경우에만 추가하세요

Article은 작성자나 게재 세부 정보가 표시된 편집 리소스에 적합할 수 있습니다. Product는 제품을 진정으로 제시하는 페이지에 적합할 수 있습니다. SoftwareApplication은 소프트웨어를 설명하는 페이지에 적합할 수 있으며, 마크업에 표시된 세부 정보가 해당 페이지에서 지원되어야 합니다.

예를 들어, 소프트웨어 기능을 설명하는 페이지는 SoftwareApplication 적합성을 검토할 수 있습니다. 프로젝트를 일반적으로만 논의하는 경우 해당 유형을 추가하면 잘못 설명할 수 있습니다. 빠른 페이지별 검토를 통해 하나의 템플릿이 다른 페이지에 복사되는 것을 방지할 수 있습니다.

JSON-LD 객체는 작고 읽기 쉬울 수 있습니다. 여기서 이름과 주소는 예시이며, 프로젝트에 대한 실제 사실이 아닙니다:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Project",
  "url": "https://example.org/"
}

사이트의 실제 공개 세부 정보를 사용한 후, 렌더링된 페이지가 이를 지원하는지 확인하세요. 질문 페이지의 경우 FAQ 최적화가 마크업을 고려하기 전에 표시되는 답변을 계획하는 데 도움이 될 수 있습니다.

페이지 목록에서 확인된 JSON-LD까지의 차분한 5단계 과정

페이지 목록과 간단한 증거 확인은 스키마 작업을 검토하기 쉽게 만듭니다. 이 순서를 사용하여 각 레코드를 설명하는 페이지에 연결된 상태로 유지합니다.

1. 우선순위 URL을 선택하세요. 먼저 중요한 페이지를 나열합니다. 각 페이지의 목적, 주요 엔티티, 표준 주소를 기록합니다.
2. 적합한 유형을 선택하세요. 페이지가 조직, 웹사이트, 기사, 제품, 소프트웨어 또는 기타 적절한 주제를 설명하는지 결정합니다.
3. 각 속성을 추적하세요. 방문자가 사실을 볼 수 있는 위치 또는 신뢰할 수 있는 프로젝트 출처가 이를 확인하는 위치를 기록합니다. 명확한 지원이 없는 필드는 제거합니다.
4. JSON-LD를 해당 페이지에 추가하세요. URL이 의도한 페이지를 가리키고 구문이 구문 분석되는지 확인합니다. 레코드를 렌더링된 콘텐츠와 비교합니다.
5. 편집 후 다시 방문하세요. 페이지, 제품 세부 정보, 작성자 또는 조직 사실이 변경될 때 관련 마크업을 확인합니다.

게시하기 전에 편집자나 제품 소유자에게 신원과 제품 주장을 확인하도록 요청합니다. 이 검토는 수정하기 쉬운 시점에 일치하지 않는 이름과 오래된 설명을 찾아냅니다. 체크리스트를 페이지 노트와 함께 보관하여 향후 편집자가 처음부터 추론을 다시 구축하지 않고도 동일한 검사를 반복할 수 있도록 합니다. llms.txt 구현 방법도 고려 중이라면 해당 작업을 별도로 유지하세요. 파일과 페이지 마크업은 다른 작업을 수행합니다.

구조화 데이터와 AI 플랫폼 간의 경계

구조화 데이터는 페이지에 대한 세부 정보를 더 명확하게 만들 수 있습니다. 그러나 ChatGPT, Perplexity, Google 또는 다른 플랫폼이 정보를 선택하거나 표시하는 방식을 지시할 수는 없습니다. Google의 문서는 구조화 데이터가 콘텐츠를 이해하고 지원되는 검색 표시에 대한 적격성을 평가하는 데 도움이 되는 방법으로 설명합니다. 표시 여부는 Google의 결정입니다. 어떤 스키마 유형도 인용이나 특정 답변을 보장할 수 없습니다.

이 경계는 팀에 유용한 품질 테스트를 제공합니다. 페이지가 실제 독자 요구를 충족하는지, 주장이 뒷받침되는지, 마크업이 표시된 카피를 반영하는지 확인하세요. 데이터가 구문 분석되지만 페이지가 모호한 경우, 더 많은 속성을 추가하기 전에 페이지를 개선하세요. 프로젝트 설명이 변경되면 페이지를 업데이트한 후 관련 레코드를 검토하세요.

변경한 내용과 이유에 대한 메모를 보관하세요. 이렇게 하면 다음 사람이 필드가 실제 페이지 세부 정보를 나타내는지 아니면 오래된 가정을 나타내는지 알 수 있습니다. ChatGPT와 Perplexity가 표시하는 내용을 비교할 때 각 플랫폼이 실제로 표시하는 내용을 기록하세요. 마크업을 언급이나 누락의 원인으로 취급하지 마세요. AI 검색 노출 가이드에서 더 넓은 게재 환경을 다룹니다.

팀이 다시 방문할 수 있는 작은 기록을 유지하세요

간결한 검토 기록은 팀이 페이지 사실, 마크업 점검, 노출 관찰을 분리하는 데 도움이 됩니다. 또한 다음 콘텐츠 업데이트에서 오래된 세부 정보가 남을 가능성을 줄입니다.

각 우선순위 URL에 대해 의도된 유형, 표준 주소, 마지막 검토, 검증 상태를 기록합니다. 페이지가 구조화 데이터에 영향을 줄 수 있는 방식으로 변경될 때 짧은 메모를 추가합니다. 그런 다음 플랫폼 관찰은 별도 장소에 보관합니다: 확인한 질문, 플랫폼, 확인 날짜, 표시된 내용을 기록합니다. 이 메모는 팀이 본 내용을 설명하며, 플랫폼이 특정 출처를 선택한 이유를 확립하지 않습니다.

실제 방문자가 프로젝트에 대해 물을 수 있는 작은 질문 세트를 사용하세요. 페이지를 검토할 때 질문을 반복하고, 답변을 게시된 페이지 내용과 비교하세요. 답변이 중요한 세부 정보를 놓친 경우, 스키마를 변경하기 전에 문구와 출처 정보를 검사하세요. 이렇게 하면 작업이 사람들이 확인할 수 있는 콘텐츠에 기반을 둡니다.

더 넓은 기술 검토를 원한다면 llms.txt 및 AI 크롤러 설정에서 해당 작업의 별도 부분을 설명합니다. 자체 검토를 시작하려면 몇 가지 우선순위 URL, 대상이 묻는 질문, 기존 스키마 내보내기를 수집하세요. 페이지-마크업 일치를 확인하고 팀을 위한 명확한 수정 사항을 반환할 수 있습니다.

이용 방법

1. 우선순위 페이지 나열각 URL의 목적, 주요 엔티티, 표준 주소를 기록합니다.
2. 페이지 유형 선택각 페이지의 표시된 목적을 설명하는 유형을 선택합니다.
3. 사실 추적각 속성을 표시된 콘텐츠 또는 신뢰할 수 있는 프로젝트 출처에 연결합니다.
4. JSON-LD 추가 및 확인설명하는 페이지에 배치하고, 구문을 테스트하고, 사실을 렌더링된 페이지와 비교합니다.
5. 편집 후 검토관련 페이지 콘텐츠 또는 프로젝트 세부 정보가 변경될 때 마크업을 다시 확인합니다.