페이지에 JSON-LD 코드를 추가했고 google schema testing tool을 열었는데도 “구조화된 데이터가 감지되지 않았습니다”라고 표시된다면, 바로 전체 마크업을 다시 작성할 필요는 없습니다. 이 결과가 반드시 Schema가 유효하지 않다는 뜻은 아니며, 더 흔한 원인은 검사 도구가 가져온 페이지 콘텐츠가 브라우저에서 보이는 내용과 일치하지 않거나, 마크업 배치 방식, 코드 문법 또는 페이지 접근 상태에 문제가 있기 때문입니다.
실제 작업에서 오판을 가장 쉽게 유발하는 경우는 개발자가 테스트 환경에서는 코드가 정상인 것을 확인했지만 배포 후 도구가 이를 크롤링하지 못하는 경우입니다. 또는 웹사이트 관리자에서 이미 제품, 브레드크럼, 글 등의 필드를 저장했지만 프런트엔드 페이지가 실제로 구조화된 데이터를 출력하지 않는 경우도 있습니다. 처리할 때는 먼저 “도구가 가져온 HTML에 마크업이 있는지”를 확인하고, 그다음 마크업이 파싱 가능한지 점검한 후, 마지막으로 유형과 속성이 요구 사항에 부합하는지 판단해야 합니다.
“데이터가 감지되지 않음”과 “데이터는 감지되었지만 경고가 있음”은 두 가지 서로 다른 문제입니다. 전자는 도구가 현재 페이지에서 식별 가능한 Microdata, RDFa 또는 JSON-LD를 파싱하지 못했다는 의미이고, 후자는 마크업이 존재하지만 일부 권장 필드가 누락되었다는 의미로, 기본 인식에 반드시 영향을 주는 것은 아닙니다.
Google의 기존 Structured Data Testing Tool은 유지 관리가 중단되었습니다. 현재 점검 시에는 목적에 따라 리치 결과 테스트 도구를 사용해 페이지가 Google이 지원하는 리치 결과 표시 조건에 부합하는지 확인하거나, Schema Markup Validator를 사용해 Schema.org 문법과 계층 구조를 검사할 수 있습니다. 한 도구에서 결과가 표시되지 않는다고 해서 페이지의 모든 구조화된 데이터가 무효라고 단정하지 마십시오. 도구마다 지원 유형, JavaScript 렌더링 및 검증 규칙에서 중점을 두는 부분이 완전히 같지는 않습니다.
먼저 검사할 URL을 시크릿 창에서 열어 직접 접근 가능하고 정상 페이지를 반환하며 로그인, 인증 코드, 지역 제한 또는 특수 Cookie가 필요하지 않은지 확인하십시오. 테스트 도구는 차단되었거나 리디렉션에 문제가 있거나 접근이 제한된 콘텐츠를 읽을 수 없습니다.
일부 웹사이트는 방문자의 언어, IP 또는 User-Agent에 따라 다른 버전을 반환합니다. 브라우저에서 정상적으로 접속된다고 해서 크롤링 도구가 정상적인 HTML을 가져온다는 의미는 아닙니다. 이 경우 서버 로그, CDN 보호 규칙 또는 페이지 크롤링 결과에서 요청이 차단되었는지 확인해야 합니다.

브라우저의 “요소 검사”에서만 찾지 마십시오. 개발자 도구는 페이지가 JavaScript를 실행한 후의 DOM을 표시하지만, 검사 도구가 반드시 동일한 방식으로 스크립트를 실행하는 것은 아닙니다. “페이지 소스 보기”를 사용하여 application/ld+json, schema.org, itemtype 또는 itemscope를 검색해야 합니다.
JSON-LD의 일반적인 작성 방식은 콘텐츠를 <script type="application/ld+json"> 태그 안에 넣는 것입니다. 소스 코드에 이 내용이 없고 동적 DOM에만 나타난다면, 문제는 대부분 프런트엔드의 비동기 삽입에서 비롯됩니다. 특히 단일 페이지 애플리케이션, 필터링 페이지, 팝업 상품 상세 페이지의 경우 구조화된 데이터가 인터페이스 응답 후에야 생성될 수 있으므로, 크롤링 시점이 다르면 google schema testing tool에서 감지되지 않을 수 있습니다.
더 안정적인 방법은 핵심 페이지의 JSON-LD가 초기 HTML과 함께 출력되도록 하거나, 신뢰할 수 있는 서버 측 렌더링 또는 사전 렌더링 방식을 채택하는 것입니다. 상품 상세, 글 상세, 카테고리 페이지의 주요 정보 자체가 초기 응답에서 우선적으로 읽혀야 하며, 사용자 조작 후에 완전히 의존하여 로드되어서는 안 됩니다.
코드를 복사할 때 전각 따옴표, 후행 쉼표, 이스케이프되지 않은 큰따옴표 또는 불완전한 괄호가 쉽게 포함될 수 있습니다. JSON 파싱에 실패하면 도구는 일반적으로 전체 데이터 블록을 직접 무시합니다. 코드가 Schema처럼 보인다고 해서 유효한 JSON인 것은 아닙니다.
@context가 https://schema.org인지, @type의 철자가 올바른지도 확인해야 합니다. 속성값은 페이지에 표시되는 콘텐츠와 일치해야 합니다. 예를 들어 제품 가격, 재고, 평점, 게시일 등의 정보는 마크업에 장기간 만료되었거나 페이지에 존재하지 않는 정보로 남아 있어서는 안 됩니다. 도구가 파싱할 수 있다고 해서 검색 엔진이 해당 정보를 표시용으로 채택한다는 의미는 아닙니다.
웹사이트 구축 시스템 또는 CMS를 사용할 때 관리자에서 “구조화된 데이터 활성화”를 선택해도 감지되지 않는다면, Schema 유형을 잘못 선택한 것이 아니라 템플릿이 해당 구성 요소를 호출하지 않았기 때문인 경우가 많습니다. 예를 들어 글 템플릿은 제목과 본문을 출력하지만 Article Schema 모듈을 누락했을 수 있습니다. 또는 상품 데이터는 상품 시스템에 입력했지만 현재 상세 페이지가 사용자 지정 템플릿을 사용하여 관련 필드가 전달되지 않았을 수 있습니다.
또 다른 빈번한 문제는 캐시입니다. 페이지 업데이트 후 관리자 설정은 변경되었지만 CDN, 페이지 캐시 및 객체 캐시는 여전히 이전 버전의 HTML을 반환할 수 있습니다. 점검 순서는 다음과 같아야 합니다. 설정을 저장하고 페이지를 게시한 후, 사이트 캐시와 CDN 캐시를 비우고, 최종 공개 URL로 소스 코드를 확인한 다음 다시 검사를 제출하십시오. 관리자 미리보기 페이지에서 새 코드를 보는 것만으로는 온라인 페이지가 업데이트되었음을 증명할 수 없습니다.
일부 웹사이트는 테마 기본 SEO 마크업, 쇼핑몰 플러그인 마크업 및 타사 SEO 플러그인을 동시에 활성화하여 하나의 상품 페이지에 두 개의 Product와 두 개의 Offer가 나타나고, 가격이나 재고도 일치하지 않는 결과를 낳습니다. 이런 페이지는 반드시 “감지되지 않음”으로 표시되지는 않지만, 이후 진단을 혼란스럽게 만들고 마크업의 신뢰도를 낮출 수도 있습니다.
페이지 역할에 따라 주요 엔터티를 유지하는 것이 좋습니다. 글 상세 페이지는 Article 또는 BlogPosting을 중심으로 하고, 상품 상세 페이지는 Product를 중심으로 하며, 탐색 영역에는 BreadcrumbList를 보완할 수 있습니다. 먼저 중복된 소스를 삭제하거나 비활성화한 뒤 다시 테스트하십시오. Organization, WebSite 등의 사이트 전체 엔터티도 이름, 웹사이트 주소, Logo 등의 정보를 일관되게 유지해야 하며, 서로 다른 플러그인이 각각 다른 버전을 생성하게 해서는 안 됩니다.
마지막으로 한 가지 판단 기준을 유지해야 합니다. 구조화된 데이터가 검증을 통과했다는 것은 기계가 일부 페이지 정보를 이해할 수 있다는 의미일 뿐, 반드시 리치 결과 표시를 얻는다는 보장은 아닙니다. 반대로 특정 Schema가 리치 결과 도구에 표시되지 않는다고 해서 마크업에 가치가 없다는 뜻도 아닙니다. “데이터가 감지되지 않음” 문제의 경우, 페이지 접근성, 초기 HTML 출력, JSON 문법 및 캐시 버전을 우선적으로 확인하는 것이 반복적으로 필드를 추가하는 것보다 일반적으로 더 효과적입니다.
관련 기사
관련 제품