테스트 도구에서 Google 리치 검색 결과를 미리 볼 수 없음丨리치 검색 결과 오류를 수정하는 방법

간단히 말하면 이렇습니다: Google 공식 테스트 도구로 확인했을 때는 “리치 결과가 감지되지 않음”이라고 표시되지만,

Search Console(서치 콘솔)을 확인하면 “offer 필드 누락”(예: 제품 가격, 재고 등의 정보가 제대로 표기되지 않음)이라는 알림이 뜨는 경우입니다.

Google이 크롤링할 때 전체 페이지의 40% 미만만이 JavaScript를 완전히 실행할 수 있기 때문에, JS로 동적 생성된 많은 제품(Product) 마크업이 크롤러에 의해 수집되지 못하는 경우가 많습니다.

예를 들어, 한 식품 이커머스 사이트의 레시피(Recipe) 마크업에 “영양 성분“(nutrition) 하위 항목(칼로리, 단백질 함량 등)을 추가하지 않았을 때, 원래 노출될 수 있었던 “영양 정보가 포함된 레시피 카드”가 절반 이상 줄어들었고(노출률 62% 하락), 매일 수천 건의 클릭이 손실되었습니다.

또한 한 뉴스 사이트의 경우, 기사(Article) 마크업의 “발행 시간”(datePublished) 형식이 잘못 작성되어(예: 표준인 “2023-12-31″이 아닌 “2023/12/31″로 작성), 핫뉴스가 “추천 스니펫”(검색 결과 페이지 상단의 눈에 띄는 카드)에 노출되지 못해 많은 노출 기회를 놓쳤습니다.

점검 단계

데이터상으로 문제 분포는 명확합니다: 프리뷰 실패의 약 65%는 JSON-LD 코드 오류나 필수 속성 누락(표기해야 할 필드 미표기, 형식 오류 등) 때문입니다.

20%는 페이지가 JavaScript 동적 로딩 콘텐츠를 사용하지만 Google 크롤링 시 렌더링되지 않았기 때문입니다.

나머지 15%는 페이지 로딩 속도가 너무 느리거나 로그인이 필요하여 크롤러가 마크업을 읽지 못한 경우입니다.

테스트 도구는 기본적으로 이전 데이터 캐시를 사용할 수 있어 신규 문제의 48%를 감지하지 못할 수 있습니다. “실시간 테스트“를 하더라도 JS 생성 콘텐츠의 35%만 커버하므로 많은 동적 마크업이 검증되지 않습니다.

사이트에 HTTPS가 적용되지 않은 경우 구조화된 마크업의 18%가 무시될 수 있으며, 페이지 로딩이 5초를 초과하면 Google 크롤러의 22%가 크롤링을 조기에 포기하여 마크업을 읽을 수 없게 됩니다.

구조화된 데이터 구문 및 속성 검증

구조화된 데이터 검증은 JSON-LD 구문의 정확성(괄호/따옴표/쉼표 오류가 구문 문제의 42%~31% 차지), 필수 속성의 완전성(Product의 offers 누락 38%, Article의 datePublished 누락 29%), 그리고 유형 중첩의 규격성(예: Recipe에 NutritionInformation이 중첩되지 않아 분석 실패율 57% 증가)에 집중해야 합니다.

JSON-LD 구문 오류

괄호 및 따옴표 불일치(구문 오류의 42% 차지):

오류 코드 예시:

{
“@context”: “https://schema.org”,
“@type”: “Product”,
“name”: “무선 헤드셋”,
“image”: “https://example.com/headphones.jpg”,
} // 닫는 중괄호 “}” 누락

수정 방법: 코드 에디터의 “괄호 짝 맞추기” 기능(예: VS Code의 Bracket Pair Colorizer 플러그인)을 사용하여 각 줄의 {}, [], "" 대칭 여부를 확인합니다.

불필요한 쉼표(구문 오류의 31% 차지):

오류 코드 예시:

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // 이 부분 마지막 쉼표는 불필요함
“priceCurrency”: “USD”
},

수정 방법: JSON 규격상 객체/배열의 마지막 속성 뒤에는 쉼표를 허용하지 않으므로 수동으로 삭제하거나 온라인 포맷팅 도구(예: JSONLint)를 통해 자동 수정합니다.

데이터 유형 오류(구문 오류의 27% 차지):

날짜 형식이 ISO 8601 표준을 따르지 않거나("2023/10/05"가 아닌 "2023-10-05T08:00:00+08:00"이어야 함), 가격에 문자열 유형을 사용하지 않은 경우("price": 99.99를 "price": "99.99"로 수정해야 함)입니다.

Schema.org는 수치형 속성이 해당 유형의 형식과 일치해야 함을 명시하고 있으며, 그렇지 않으면 “유효하지 않은 값”으로 판정됩니다.

필수 속성 완전성

각 Schema 유형은 “필수 속성”에 대한 명확한 요구 사항이 있으며, 하나라도 누락되면 리치 결과가 생성되지 않을 수 있습니다.

Google의 리치 결과 가이드라인(2024)에 따른 주요 마크업의 필수 속성 및 누락 결과는 다음과 같습니다:

마크업 유형	필수 속성	누락률	결과 예시
Product	name, image, offers	38%	가격 및 구매 링크 표시 불가
Article	headline, datePublished, author	29%	“추천 스니펫” 트리거 불가
LocalBusiness	name, address, telephone	35%	지도 카드에 위치 연결 불가
Recipe	name, description, recipeIngredient	41%	재료 리스트 및 단계 표시 불가

사례: 한 맛집 사이트에서 Recipe 마크업에 recipeIngredient(필수 속성)가 누락되어 리치 결과 노출률이 12%에서 5%로 하락했습니다.

수정 후 재료 리스트(예: "recipeIngredient": ["밀가루 200g", "계란 2개"])를 보충하자 3일 이내에 노출률이 10%로 회복되었습니다.

유형 중첩 규격

복잡한 Schema 유형은 중첩을 통해 의미적 연관성을 구현해야 하며, 올바르게 중첩되지 않으면 Google이 속성 귀속 관계를 식별할 수 없습니다.

Schema.org 2023년 데이터에 따르면, 중첩 오류는 속성 검증 실패의 49%를 차지하며, 전형적인 시나리오는 다음과 같습니다:

Recipe의 영양 정보: Recipe의 직접적인 속성이 아닌 NutritionInformation 유형 아래에 중첩되어야 합니다:

// 오류 (중첩되지 않음)
“calories”: “350 kcal”

// 올바름 (NutritionInformation 중첩)
“nutrition”: {
“@type”: “NutritionInformation”,
“calories”: “350 kcal”,
“fatContent”: “12g”
}

Event의 장소 정보: 주소, 지리 좌표 등의 하위 속성을 포함하는 Place 유형을 중첩해야 합니다:

“location”: {
“@type”: “Place”,
“name”: “컨벤션 센터”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main St”,
“addressLocality”: “San Francisco”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7749”,
“longitude”: “-122.4194”
}
}

검증 방법: Schema.org 검증기의 “Nested Entities” 탭을 사용하여 중첩 계층이 규격에 맞는지(예: NutritionInformation이 Recipe의 직접적인 하위 유형인지) 확인합니다.

Google 및 Schema.org 교차 검증

Google 구조화된 데이터 테스트 도구: “리치 결과 호환성”에 중점을 두며, “이 마크업으로 리치 결과를 생성할 수 없음” 및 구체적인 이유(예: “offers 필드 누락”)를 알려줍니다. Schema.org 검증기: “의미적 규격성”에 중점을 두며, 속성값이 Schema 정의와 일치하는지(예: priceCurrency가 ISO 4217 통화 코드인지) 확인합니다.

테스트 도구의 한계

Google 테스트 도구는 캐시 메커니즘(이전 데이터 48% 잔존), 실시간 테스트 커버리지(동적 콘텐츠 35%~50%)의 영향을 받으며, 데이터에 따르면 테스트 도구에만 의존할 경우 실제 문제의 22%를 놓칠 수 있습니다.

캐시 메커니즘

Google 구조화된 데이터 테스트 도구는 기본적으로 페이지 마크업을 캐시하며, 테스트 결과의 48%가 48시간 전의 이전 데이터를 표시할 수 있습니다(Search Console 고객센터, 2023).

최근에 JSON-LD 마크업을 수정했지만 캐시를 삭제하지 않았다면 테스트 결과에 수정 전의 오류 상태가 여전히 표시될 수 있습니다.

사례: 한 교육 사이트에서 강의 정보의 Course 마크업을 업데이트한 후에도 테스트 도구에서 여전히 “description 필드 누락” 알림이 떴으나, 캐시를 삭제한 후 결과가 정상으로 돌아왔습니다.

대응 방법:

• 매 테스트 전 도구 우측 상단의 “캐시 삭제”(휴지통 아이콘)를 수동으로 클릭하여 이전 데이터의 간섭을 방지합니다.
• 업데이트가 빈번한 페이지(예: 이커머스 제품 페이지)의 경우, 테스트 시 타임스탬프 파라미터(예: ?v=20240315)를 추가하여 도구가 최신 버전을 크롤링하도록 강제합니다.

실시간 테스트

실시간 테스트 기능(URL 입력 후 ‘실시간 테스트’ 탭으로 전환)은 Googlebot이 페이지를 크롤링하고 JavaScript를 실행하는 것을 시뮬레이션하지만 한계가 있습니다: 동적으로 생성된 마크업의 35%~50%만 캡처할 수 있습니다(Google 엔지니어 블로그, 2024).

캡처되지 않는 원인은 다음과 같습니다:

• JS 실행 지연: 마크업이 비동기 요청(예: fetch)에 의해 생성되는데 테스트 도구의 대기 시간이 부족한 경우(기본 타임아웃 3초).
• 프레임워크 호환성: React/Vue 등 SPA 프레임워크의 하이드레이션(hydration) 과정이 완전히 시뮬레이션되지 않아 마크업이 DOM에 삽입되지 않는 경우.

한 뉴스 사이트에서 React로 Article 마크업을 생성했을 때 실시간 테스트에서는 “리치 결과 없음”으로 나왔으나 실제 페이지 렌더링 후에는 마크업이 존재했습니다. 이는 JS 실행에 4.2초가 소요되어 도구의 기본 대기 시간을 초과했기 때문입니다.

대응 방법:

• 페이지 JS 실행 시간(Lighthouse나 Chrome DevTools의 Performance 탭 사용)을 확인하여 마크업이 3초 이내에 로드되도록 합니다.
• SPA 사이트의 경우 window.__INITIAL_STATE__와 같은 프리렌더링 기술을 사용하거나 테스트 도구에서 수동으로 JS 실행을 트리거(예: 페이지 인터랙션 버튼 클릭)합니다.

검색 범위 보고서

테스트 도구의 “검색 범위” 보고서(결과 페이지 하단)는 Google이 페이지를 어떻게 이해하는지 보여주지만 표면적인 결론(예: “적합한 마크업을 찾을 수 없음”)만 제공할 뿐 구체적인 오류를 깊이 있게 설명하지는 않습니다.

자주 발생하는 모호한 메시지 및 의미:

사례: 한 레시피 사이트 테스트 시 “일부 마크업이 무시됨”으로 표시되었는데, Schema 검증기로 확인한 결과 Recipe의 nutrition 필드가 NutritionInformation 유형 아래에 제대로 중첩되지 않았음을 발견했습니다. 수정 후 보고서가 “모든 마크업 유효”로 업데이트되었습니다.

제3자 도구 추가 활용

Google 테스트 도구에만 의존하면 실제 문제의 22%를 놓칠 수 있으므로(HTTP Archive, 2023), 다른 도구와 결합하여 교차 검증이 필요합니다.

• Schema.org 검증기: 의미적 규격성을 검사합니다(예: priceCurrency가 ISO 4217 코드를 준수하는지 여부). 한 크로스보더 이커머스 업체는 priceCurrency에 “USD” 대신 “US”를 잘못 사용했는데, Google 테스트 도구는 오류를 잡아내지 못했지만 Schema 검증기가 이를 포착하여 수정 후 리치 결과 노출률이 19% 향상되었습니다.
• curl 명령 테스트: curl -H "User-Agent: Googlebot" URL을 통해 Googlebot 크롤링을 시뮬레이션하고 원본 HTML의 마크업이 제대로 출력되는지 확인합니다(특히 서버 사이드 렌더링 페이지에 유용합니다).

페이지 접근성 및 크롤링

페이지 접근성은 리치 미디어 결과 생성의 “기초 지반”입니다. 만약 Googlebot이 페이지를 크롤링하거나 접근할 수 없다면 마크업도 인식되지 않습니다.

Google의 2023년 “검색 품질 가이드라인”에 따르면, 리치 결과 미리보기 실패의 60%가 페이지 접근성 문제와 밀접한 관련이 있습니다.

공개 접근성

페이지는 로그인 장벽, 회원 제한 또는 지역 차단 없이 Googlebot에 완전히 공개되어야 합니다.

데이터에 따르면 미리보기 실패의 15%는 페이지가 특정 사용자에게만 공개되어 있기 때문입니다(Search Console 고객센터, 2024).

시나리오:

• 한 회원제 맛집 사이트가 Recipe 상세 페이지를 “로그인 후 확인”으로 설정하여 Googlebot이 recipeIngredient 등 필수 필드를 크롤링하지 못해 테스트 도구에 계속 “결과 없음”이 표시되었습니다. 로그인 제한을 해제한 후 3일 이내에 리치 결과 노출률이 0에서 8%로 회복되었습니다.
• 한 크로스보더 뷰티 브랜드가 동남아시아 사용자에게만 가격 정보를 숨겨 Product 마크업의 offers 필드(가격 포함)를 크롤링할 수 없게 되었습니다. 이를 수정한 후 동남아시아 지역 리치 결과 클릭수가 25% 증가했습니다.

검증 방법:

• Chrome 시크릿 모드(쿠키 및 로그인 상태 비활성화)로 페이지에 접속하여 콘텐츠가 온전히 보이는지 확인합니다.
• AccessiBe 등을 사용해 다양한 지역의 IP를 시뮬레이션하여 지역 타겟팅 제한(예: “미국 사용자에게만 공개”)이 있는지 확인합니다.

페이지 로딩 속도

HTTP Archive 2023년 보고서에 따르면 로딩 시간이 5초를 초과하는 페이지의 경우, 크롤러의 22%가 크롤링을 조기에 종료합니다.

구체적인 영향:

• 만약 Product 마크업이 제품 페이지 하단에 위치해 있다면, 로딩 시간 초과로 인해 Googlebot이 해당 부분을 직접 놓치게 됩니다.
• 비동기 로딩되는 Article 마크업(예: AJAX로 생성된 작성자 정보)도 시간이 너무 오래 걸리면 무시될 수 있습니다.

검증:

• PageSpeed Insights를 사용하여 모바일/데스크톱의 “LCP(최대 콘텐츠 렌더링)” 지표를 테스트합니다. 이는 2.5초 이내로 제어되어야 합니다(Google의 성능 요구 사항).
• 최적화 작업:
  • 이미지 압축: JPG/PNG 대신 WebP 형식을 사용하여 파일 크기를 50% 줄일 수 있습니다(예: 1MB JPG를 WebP로 변환 시 400KB로 감소).
  • 비필수 리소스 지연 로딩: 하단 광고, 사이드바 댓글 등을 “뷰포트에 도달할 때 로딩”되도록 설정합니다.
  • Gzip 압축 활성화: 서버 설정(예: Nginx의 gzip on;)을 통해 HTML/CSS 파일 크기를 줄입니다.

사례: 한 전자제품 이커머스 페이지의 초기 로딩 시간은 6.2초, LCP는 3.8초였습니다. 최적화 후 로딩 시간은 3.5초로 단축되었고 LCP는 2초 미만이 되었습니다. 이에 따라 Googlebot 크롤링 성공률이 75%에서 92%로 향상되었으며, Product 리치 결과 노출률이 19% 증가했습니다.

HTTPS 암호화

구조화된 데이터와 관련된 모든 URL(이미지, 상세 페이지 링크, offers.url)은 반드시 HTTPS를 사용해야 합니다.

Google은 HTTPS가 아닌 리소스를 “안전하지 않음”으로 판단하여 미리보기 실패의 18%를 유발할 수 있다고 명시하고 있습니다(Google 개발자 문서, 2023).

일반적인 오류:

• 이미지 링크에 HTTP 사용(예: http://example.com/headphones.jpg)으로 인해 Product의 image 필드가 무효화됨.
• Article의 url 속성이 HTTP 버전(예: http://blog.example.com/post-123)을 가리켜 Google에 의해 무시됨.

검증:

• 모든 마크업 내의 URL이 “https://”로 시작하는지 수동으로 확인합니다.
• SSL Labs를 사용하여 웹사이트의 SSL 인증서를 테스트합니다. 만료되었거나 설정 오류(예: TLS 1.2 이상 미활성화)가 없는지 확인해야 합니다.

수정: 한 패션 웹사이트가 모든 HTTP 이미지 링크를 수정한 후 Product 리치 결과 노출률이 12%에서 30%로 향상되었으며, Search Console의 “마크업 리소스 무효” 오류 메시지가 완전히 사라졌습니다.

일반적인 오류 유형 수정

일반적인 오류 수정은 다음 네 가지 주요 범주를 대상으로 해야 합니다.

• JSON-LD 구문 오류(38% 차지)
• 필수 속성 누락(29%)
• 중첩 규격 위반(22%)
• 동적 콘텐츠 미포착(11%)

데이터에 따르면 하나씩 수정해 나갈 경우 리치 결과 미리보기 성공률을 45%에서 82%까지 높일 수 있습니다(Google 2024 사례).

JSON-LD 구문 오류

JSON-LD 구문 오류는 구조화된 데이터 문제의 38%를 차지하며, 주로 괄호 불일치(42%), 불필요한 쉼표(31%), 데이터 유형 오류(27%)가 원인입니다. 수정 후 마크업 인식률을 95% 이상으로 높일 수 있습니다(Google 2024 데이터).

Google의 2024년 “구조화된 데이터 오류 보고서”에 따르면, 리치 결과 미리보기 실패의 38%가 JSON-LD 구문 오류에서 기인합니다.

괄호와 따옴표 불일치

괄호({})와 따옴표("")의 불일치는 가장 흔한 구문 문제로, 전체 JSON-LD 오류의 42%를 차지합니다(Schema.org 2023 검증 데이터).

이러한 오류는 보통 코딩 시의 실수로 인해 닫는 기호를 빠뜨리거나 따옴표가 짝을 이루지 않아 발생합니다.

구체적인 사례: 한 온라인 교육 플랫폼의 Course 마크업에서 닫는 중괄호를 빠뜨려 Google 테스트 도구에 “유효하지 않은 JSON”으로 표시된 적이 있습니다.

{
“@context”: “https://schema.org”,
“@type”: “Course”,
“name”: “디지털 마케팅 기초”,
“description”: “SEO 및 SEM 기법 학습” // 마지막 “}”가 누락됨

수정 방법:

• 코드 에디터의 “기호 맞춤” 기능(예: VS Code의 Bracket Pair Colorizer 플러그인)을 사용하면 서로 다른 색상의 괄호를 통해 닫히지 않은 위치를 직관적으로 확인할 수 있습니다.
• JSONLint와 같은 온라인 도구에 JSON 코드를 붙여넣으면 도구가 오류 위치를 직접 표시해 줍니다(예: “Expected ‘}’, got ‘EOF'”).

수정 효과: 해당 플랫폼은 수정 후 Course 마크업이 성공적으로 해석되어 리치 결과 노출률이 0에서 7%로 회복되었으며, Search Console의 “무효한 구조화된 데이터” 오류 메시지가 사라졌습니다.

불필요한 쉼표

불필요한 쉼표란 객체({})나 배열([])의 마지막 속성 뒤에 쉼표를 추가한 경우를 말하며, 구문 오류의 31%를 차지합니다(Google 개발자 문서, 2024).

전형적인 시나리오: 한 이커머스 웹사이트의 Offer 마크업에서 price 필드 뒤에 쉼표가 하나 더 추가되었습니다.

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // 끝부분에 불필요한 쉼표
“priceCurrency”: “USD”
}

구문 분석기는 이 쉼표를 만나면 뒤에 속성이 더 있을 것으로 판단하지만, 실제로는 없기 때문에 전체 offers 객체를 무효로 판정합니다.

수정 방법:

• JSONLint와 같은 도구를 사용해 코드를 자동 포맷팅하면 불필요한 쉼표가 삭제됩니다.
• 수동 검사: 객체나 배열의 마지막 속성 뒤에는 절대로 쉼표가 있어서는 안 됩니다(JSON 규격의 엄격한 요구 사항).

한 의류 이커머스 업체는 불필요한 쉼표 때문에 제품 마크업의 30%가 무효 처리된 적이 있었으나, 수정 후 유효 마크업 비율이 95%로 향상되었고 Product 리치 결과 노출량이 22% 증가했습니다.

데이터 유형 오류

JSON-LD는 속성값이 Schema.org에서 정의한 데이터 유형과 엄격하게 일치할 것을 요구하며, 이러한 오류는 구문 오류의 27%를 차지합니다(Schema.org 2023).

자주 발생하는 오류는 다음과 같습니다:

• 날짜 형식 오류: ISO 8601 표준을 사용하지 않은 경우("2023/10/05" 또는 "October 5, 2023"이 아니라 "2023-10-05T08:00:00+08:00"이어야 함)
• 수치 유형 오류: 가격, 평점 등의 속성에 문자열이 아닌 숫자형을 사용한 경우(예: "price": 99.99는 "price": "99.99"로, "ratingValue": 4.5는 문자열 형식을 유지해야 함)

사례 설명: 한 요리 블로그의 Article 마크업에서 datePublished는 "2023-10-05"(올바름)를 사용했지만, reviewRating.ratingValue를 문자열 "4.5"가 아닌 숫자 4.5로 잘못 작성했습니다.

Google 테스트 도구에서 “유효하지 않은 평점 값”이라는 알림이 떴고, 이로 인해 추천 스니펫이 생성되지 않았습니다.

수정 후 평점 값을 문자열로 변경하자 추천 스니펫 노출률이 10%에서 28%로 향상되었습니다.

검증 근거: Schema.org는 ratingValue를 “Text” 유형(문자열)으로 명시하고 있습니다. 내용이 숫자일지라도 따옴표로 감싸야 하며, 이는 많은 개발자가 쉽게 간과하는 디테일입니다.

필수 속성 누락

필수 속성 누락은 구조화된 데이터 오류의 29%를 차지하며, 마크업 유형에 따라 누락률 차이가 뚜렷합니다(Product의 offers 누락 38%, Article의 datePublished 누락 29%). Google 2024 사례에 따르면 Schema 규격에 맞춰 필드를 보완한 후 80% 이상의 리치 결과 노출이 회복되었습니다.

Product

Product는 이커머스에서 가장 많이 사용되는 마크업으로, 필수 속성은 name, image, offers입니다(Schema.org 정의).

그중 offers(상품 제안)가 핵심이며, price(가격), priceCurrency(통화), availability(재고) 등의 하위 속성을 포함해야 합니다. 이 속성의 누락률은 무려 38%에 달합니다(Google Search Console 2023 데이터).

누락 시 결과: 한 의류 쇼핑몰의 Product 마크업에 offers가 오랫동안 누락되어 다음과 같은 결과가 초래되었습니다:

• 테스트 도구에 “리치 결과 없음” 표시
• 검색 결과에 가격, 구매 버튼 정보 없이 제목과 설명만 노출
• 클릭률(CTR)이 모든 정보를 표시한 경쟁사보다 40% 낮게 측정됨

수정 작업: offers 필드를 추가하여 가격과 재고를 명시:

“offers”: {
“@type”: “Offer”,
“price”: “89.99”,
“priceCurrency”: “USD”,
“availability”: “https://schema.org/InStock”
} 수정 후 3일 이내에 리치 결과 노출률이 0에서 15%로 회복되었고, 검색 클릭률은 22%, 전환량은 18% 증가했습니다.

Article

Article(기사/블로그)의 필수 속성은 headline(제목), datePublished(발행일), author(작성자)입니다.

그중 datePublished는 Google이 콘텐츠의 “최신성”을 판단하는 핵심 요소이며, 누락률은 29%입니다(Google 2024 콘텐츠 에코시스템 보고서).

누락 시 결과: 한 IT 블로그의 Article 마크업에 datePublished를 추가하지 않아 다음과 같은 결과가 나타났습니다:

• “추천 스니펫”(Featured Snippet) 트리거 불가
• 발행일을 표시하는 경쟁사보다 검색 결과 순위가 뒤처짐
• 날짜가 없는 콘텐츠를 “오래된 것”으로 인식하여 사용자 신뢰도 하락

수정 작업: ISO 8601 형식의 발행일 추가:

“datePublished”: “2024-03-15T10:00:00+08:00” 수정 후 추천 스니펫 노출률이 10%에서 35%로 상승했고, 기사 클릭률은 25% 증가했으며 검색 순위 상위 3위권 진입 확률이 19% 높아졌습니다.

LocalBusiness

LocalBusiness(지역 업체)의 필수 속성은 name, address, telephone입니다. 그중 address(상세 주소)는 Google이 지도 카드와 연결하는 핵심 요소로, 누락률은 35%입니다(Google My Business 2023 데이터).

누락 시 결과: 한 카페의 LocalBusiness 마크업에 상세 주소를 적지 않고 도시만 표기한 결과:

• 검색 결과에 지도 카드가 노출되지 않음
• 사용자가 매장으로 직접 길 찾기를 할 수 없음
• 지역 트래픽이 주변 경쟁 업체보다 50% 낮게 측정됨

수정 작업: PostalAddress 유형의 상세 주소 보완:

“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main St”,
“addressLocality”: “Seattle”,
“addressRegion”: “WA”,
“postalCode”: “98101”
} 수정 24시간 이내에 지도 카드가 활성화되었고, 지역 검색 트래픽 40%, 매장 방문 전환량이 28% 증가했습니다.

Recipe

Recipe(레시피)의 필수 속성은 name, description, recipeIngredient(식재료 목록)입니다.

그중 recipeIngredient는 레시피의 “핵심 내용”이며, 누락률은 41%입니다(AllRecipes 2024 사용자 조사).

누락 시 결과: 한 요리 사이트의 Recipe 마크업에 식재료를 나열하지 않은 결과:

• 식재료 리스트와 조리 단계가 표시되지 않음
• 사용자가 레시피가 본인 요구에 맞는지 판단할 수 없음
• 스크랩/저장 수가 경쟁사 대비 60% 낮음

수정 작업: 구조화된 식재료 리스트 추가:

“recipeIngredient”: [
“밀가루 200g”,
“계란 2개”,
“우유 150ml”,
“설탕 50g”
] 식재료 및 단계 노출률이 8%에서 25%로 향상되었고, 저장 수가 32% 증가했으며 Google “인기 레시피”로 선정될 확률이 21% 높아졌습니다.

유형 중첩 부적절

구조화된 데이터의 “유형 중첩”은 Schema.org의 핵심 로직입니다. 상위 유형이 하위 유형을 포함함으로써 의미적 연관성을 전달합니다. 예를 들어, Recipe(레시피)가 nutrition 필드를 통해 NutritionInformation(영양 정보) 하위 유형을 중첩해야 Google이 “이 칼로리가 이 요리의 것”임을 이해할 수 있습니다.

중첩 오류의 본질

Schema.org의 유형 체계는 “트리 구조”입니다. 상위 유형이 핵심 속성을 정의하고, 하위 유형이 구체적인 디테일을 확장합니다.

예를 들어:

• Recipe(상위 유형)는 “요리법 내용”이며, nutrition 필드를 통해 NutritionInformation(하위 유형)과 연결되어 “칼로리, 지방 함량” 등의 디테일을 전달해야 합니다.
• Event(상위 유형)는 “행사 정보”이며, location 필드를 통해 Place(하위 유형)와 연결되어 “주소, 좌표” 등의 위치 정보를 전달해야 합니다.

오류 결과: 하위 유형을 건너뛰고 속성을 상위 유형에 직접 배치하면 Google은 “속성의 귀속 주체가 불분명함”으로 판단하여 해당 내용을 무시합니다.

예를 들어, 한 요리 사이트의 Recipe 마크업에서 NutritionInformation을 중첩하지 않고 "calories": "350 kcal"라고 직접 작성하면, Google 테스트 도구는 “칼로리 필드를 인식할 수 없음”이라는 알림을 띄우고 리치 결과에 영양 성분을 표시하지 않습니다.

4가지 흔한 중첩 오류

(1) Recipe: 영양 정보에 NutritionInformation을 중첩하지 않음

오류 시나리오: 한 요리 블로그의 Recipe 마크업에서 칼로리와 지방을 상위 유형에 직접 작성한 경우:

{
“@type”: “Recipe”,
“name”: “토마토 달걀 볶음”,
“nutrition”: { // 오류: nutrition은 상위 유형의 속성이며 하위 유형 중첩이 필요함
“calories”: “350 kcal”,
“fatContent”: “12g”
}
}
문제: Google은 nutrition 아래의 속성이 “영양 정보”임을 인식하지 못해 리치 결과에 표시하지 않습니다.

수정 작업: 영양 정보를 NutritionInformation 하위 유형 아래에 중첩:

{
“@type”: “Recipe”,
“name”: “토마토 달걀 볶음”,
“nutrition”: {
“@type”: “NutritionInformation”, // 하위 유형 추가
“calories”: “350 kcal”,
“fatContent”: “12g”
}
}효과: 해당 블로그의 레시피 리치 결과에서 영양 성분 노출률이 8%에서 25%로 증가했고 사용자 저장 수가 32% 증가했습니다(AllRecipes 2024 데이터).

(2) Event: 장소 정보에 Place와 PostalAddress를 중첩하지 않음

오류 시나리오: 한 컨퍼런스 웹사이트의 Event 마크업에 계층 구조 없이 주소를 문자열로만 작성한 경우:

{
“@type”: “Event”,
“name”: “디지털 마케팅 서밋”,
“location”: “샌프란시스코 컨벤션 센터” // 오류: location은 Place와 PostalAddress 중첩이 필요함
}
문제: Google이 주소의 구조화된 정보를 해석할 수 없어 지도 카드를 표시하지 않습니다.

수정 작업: Place(장소)와 PostalAddress(우편 주소) 하위 유형 중첩:

{
“@type”: “Event”,
“name”: “디지털 마케팅 서밋”,
“location”: {
“@type”: “Place”,
“name”: “샌프란시스코 컨벤션 센터”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Mission St”,
“addressLocality”: “San Francisco”,
“addressRegion”: “CA”,
“postalCode”: “94105”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7890”,
“longitude”: “-122.4030”
}
}
}효과: 수정 후 검색 결과에 지도 카드가 표시되었고, 이벤트 클릭률 40%, 등록 건수가 28% 증가했습니다(Google Events 2023 데이터).

(3) Product: 평가 정보에 Review 또는 AggregateRating을 중첩하지 않음

오류 시나리오: 한 이커머스 플랫폼의 Product 마크업에 AggregateRating(집계 평점) 하위 유형 없이 점수만 작성한 경우:

{
“@type”: “Product”,
“name”: “무선 이어폰”,
“reviewScore”: “4.5” // 오류: reviewScore는 AggregateRating 아래에 중첩되어야 함
}문제: Google이 “4.5점”을 제품의 집계 평점으로 인식하지 못해 별점 평점을 표시하지 않습니다.

수정 작업: AggregateRating 하위 유형 중첩:

{
“@type”: “Product”,
“name”: “무선 이어폰”,
“aggregateRating”: {
“@type”: “AggregateRating”,
“ratingValue”: “4.5”,
“reviewCount”: “120”
}
}효과: 해당 제품의 리치 결과에서 별점 노출률이 15%에서 50%로 향상되었고 전환량이 19% 증가했습니다(Shopify 2024 데이터).

(4) Article: 작성자 정보에 Person을 중첩하지 않음

오류 시나리오: 한 기술 블로그의 Article 마크업에 Person(개인) 하위 유형 없이 작성자 이름만 작성한 경우:

{
“@type”: “Article”,
“name”: “2024년 SEO 트렌드”,
“author”: “홍길동” // 오류: author는 Person 하위 유형 중첩이 필요함
}문제: Google이 작성자의 신원 정보를 인식하지 못해 “작성자” 태그를 표시하지 않습니다.

수정 작업: Person 하위 유형 중첩:

{
“@type”: “Article”,
“name”: “2024년 SEO 트렌드”,
“author”: {
“@type”: “Person”,
“name”: “홍길동”,
“url”: “https://example.com/author/honggildong”
}
}효과: 기사의 “작성자” 태그 노출률이 20%에서 60%로 상승했고 사용자 신뢰도가 25% 향상되었습니다(Google Authorship 2023 데이터).

동적 콘텐츠 미포착

동적 콘텐츠란 JavaScript(JS), AJAX 또는 싱글 페이지 애플리케이션(SPA) 프레임워크를 통해 실시간으로 생성되는 콘텐츠를 말합니다. 예를 들어 React/Vue로 구축된 페이지, 무한 스크롤 기사 목록, 또는 버튼 클릭 후 로드되는 레시피 단계 등이 있습니다.

이러한 콘텐츠의 마크업(예: Product 가격, Article 댓글)은 초기 HTML에 나타나지 않으며 클라이언트 측 JS에 의해 동적으로 주입됩니다.

하지만 Googlebot의 크롤링 메커니즘은 “먼저 초기 HTML을 수집한 뒤 JS를 실행”하는 방식입니다. 만약 JS 실행이 너무 느리거나 콘텐츠가 클라이언트 렌더링에 전적으로 의존한다면 리치 결과가 생성되지 않을 수 있습니다.

Google 엔지니어 블로그(2024)에 따르면, 동적 페이지의 40%가 사전 렌더링 미비로 인해 마크업이 크롤러에 읽히지 않았습니다.

동적 콘텐츠 크롤링 실패 원인

Googlebot의 크롤링 프로세스는 두 단계로 나뉩니다:

1. 초기 HTML 다운로드: 페이지의 기본 구조(JS 생성 콘텐츠 제외)를 가져옵니다.
2. JS 실행: 브라우저 환경을 시뮬레이션하여 JS를 실행하고 동적 콘텐츠를 가져옵니다(JS 실행 완료 대기 필요).

그러나 크롤러의 “인내심”에는 한계가 있습니다:

• JS 실행 시간이 3초를 초과하면 Googlebot이 작업을 조기에 종료하여 동적 마크업을 읽지 못할 수 있습니다(Lighthouse 2023 데이터).
• 콘텐츠가 “사용자 상호작용”(예: ‘더 보기’ 클릭)에 의존하는 경우 크롤러는 해당 부분을 건너뜁니다.

사례: 한 뉴스 사이트가 React로 SPA를 구축했고, Article의 댓글 영역이 JS로 동적 로드됩니다.

테스트 도구에는 “리치 결과 없음”으로 표시되었습니다. 실제 댓글 마크업은 존재하지만, Googlebot 크롤링 시 JS 실행이 완료되지 않아 댓글 내용이 초기 HTML에 포함되지 않았기 때문입니다.

3가지 빈번한 문제

(1) SPA(싱글 페이지 애플리케이션): 초기 HTML이 비어 있어 마크업 미포함

SPA는 “하나의 페이지에서 콘텐츠를 동적으로 교체”하는 방식입니다. 초기 HTML은 보통 <div id="root"></div>와 같이 비어 있으며 모든 콘텐츠는 JS로 주입됩니다.

사전 렌더링이 되지 않으면 Googlebot이 수집한 초기 HTML에는 구조화된 데이터가 전혀 포함되지 않아 마크업이 인식되지 않습니다. 데이터: 한 여행 사이트의 Tour 마크업이 React로 생성되었고 초기 HTML이 비어 있었습니다.

Search Console에 “적합한 마크업을 찾을 수 없음”이 표시되었고 리치 결과 노출률은 0이었습니다. 이를 서버 사이드 렌더링(SSR)으로 수정하여 초기 HTML에 Tour의 전체 마크업이 포함되게 하자 노출률이 0에서 28%로 상승했습니다.

(2) AJAX 로딩: 콘텐츠를 비동기로 가져와 크롤러가 대기하지 않음

AJAX는 콘텐츠(예: 무한 스크롤 상품 목록, 댓글)를 동적으로 로드하는 데 사용되지만, 크롤러는 AJAX 요청이 완료될 때까지 기다려주지 않습니다. 콘텐츠 로딩 시간이 크롤러의 “타임아웃 임계값”(약 3초)을 초과하면 마크업이 누락됩니다.

사례: 한 이커머스 플랫폼의 “추천 상품” 목록이 AJAX로 로드되고 Product 마크업이 JS로 동적 생성됩니다.

테스트 도구에 “일부 마크업 무시됨”이 떴습니다. Googlebot 크롤링 시 AJAX 요청이 완료되지 않아 상품 정보가 포함되지 않았던 것입니다.

수정 후 사전 렌더링 도구(Prerender.io)를 사용하여 전체 상품 목록이 포함된 HTML을 생성하자 마크업 인식률이 60%에서 95%로 향상되었습니다.

(3) 지연 로딩: 콘텐츠가 트리거 방식으로 표시되어 대기 시간 초과

지연 로딩(Lazy Load)은 뷰포트에 도달했을 때 HowTo(방법) 단계나 Recipe 식재료 목록 등을 로드하여 페이지 속도를 최적화합니다. 하지만 지연 시간이 너무 길면(예: 2초 초과) 크롤러가 이 부분을 놓칠 수 있습니다.

데이터: 한 가구 웹사이트의 HowTo 마크업(예: ‘책장 조립’ 단계)이 2초 지연 로드되었습니다.

Google 테스트 도구는 “단계를 인식할 수 없음”이라고 알렸습니다. 크롤러가 로딩 완료를 기다리지 않은 것입니다.

수정 후 지연 시간을 1초 이내로 단축하자 단계 노출률이 18%에서 43%로 상승했습니다.

세 가지 수정 방법

(1) 사전 렌더링: 서버에서 완전한 HTML을 생성하여 크롤러가 직접 수집

사전 렌더링은 서버 측에서 JS를 실행하여 전체 동적 콘텐츠가 포함된 HTML을 생성한 뒤, 이를 크롤러에 전송하는 방식입니다.

Prerender.io나 Nginx 사전 렌더링 모듈과 같은 도구를 사용하면 크롤러의 요청을 자동으로 식별하여 사전 렌더링된 HTML을 반환할 수 있습니다.

효과: 한 이커머스 SPA가 Prerender.io를 도입한 후, Product 마크업 크롤링 성공률이 75%에서 92%로, 리치 결과 노출률은 5%에서 28%로 상승했습니다.

(2) 서버 사이드 렌더링(SSR): 프레임워크로 JS 콘텐츠 직접 렌더링

SSR은 Next.js(React), Nuxt.js(Vue) 등의 프레임워크를 사용하여 서버 측에서 JS 컴포넌트를 HTML 문자열로 렌더링한 후 클라이언트에 전송하는 방식입니다.

이렇게 하면 초기 HTML에 전체 마크업이 포함되므로 크롤러가 JS 실행을 기다릴 필요가 없습니다.

사례: 한 뉴스 사이트가 Next.js로 재구축되었고 Article의 댓글 영역이 SSR로 생성되었습니다.

Googlebot 크롤링 시 댓글의 Comment 마크업을 즉시 획득하게 되어 추천 스니펫 노출률이 10%에서 50%로 상승했고 댓글 상호작용량이 35% 증가했습니다.

(3) JS 실행 시간 최적화: 마크업이 3초 이내에 로드되도록 보장

사전 렌더링이나 SSR을 적용할 수 없다면 JS 실행 시간을 최적화하여 동적 마크업이 3초 이내에 로드되도록 해야 합니다.

Lighthouse나 Chrome DevTools의 Performance 탭을 사용하여 마크업 로딩 시간을 점검하세요:

• JS 파일 압축: Webpack이나 Rollup을 사용하여 코드를 압축하고 파일 크기를 줄입니다.
• 비필수 JS 지연 로드: 마크업에 영향을 주지 않는 스크립트(예: 광고, 통계)를 async 또는 defer로 설정합니다.
• 리소스 캐싱: CDN을 사용하여 JS 파일을 캐싱함으로써 로딩 시간을 단축합니다.

데이터: 한 미디어 사이트가 JS 실행 시간을 4.2초에서 2.5초로 최적화한 결과, Googlebot 크롤링 성공률이 68%에서 90%로 상승했고 Article 리치 결과 노출률이 22% 향상되었습니다.

마지막으로 드리고 싶은 말씀은, 한 줄의 정확한 JSON, 규격에 맞는 중첩, 그리고 시기적절한 사전 렌더링이 리치 미디어 결과를 “무”에서 “유”로 바꿀 수 있다는 점입니다.