VideoObject 구조화 데이터 완벽 가이드
자사 호스팅 영상에 VideoObject 스키마를 적용하는 법과 2026년 9월 추가된 creator·interactionStatistic 속성까지 예시로 정리했습니다.
VideoObject 구조화 데이터는 영상의 제목·썸네일·발행일·재생 시간 같은 정보를 검색엔진이 읽을 수 있는 코드로 정리해, 구글 검색 결과에 영상 썸네일과 재생 시간이 뜨는 비디오 리치 결과를 만들어주는 마크업이다. 유튜브에 영상을 올리고 임베드만 하는 사이트라면 이미 구글이 자동으로 인식하지만, 자사 서버에 영상을 직접 호스팅하는 사이트는 이 마크업 없이는 영상의 존재 자체를 구글이 제대로 파악하지 못할 수 있다.
2026년 9월 24일 구글은 이 구조화 데이터 공식 문서를 업데이트했다. 영상 제작자를 표시하는 creator·author 속성 지원을 문서화하고, interactionStatistic에서 실제로 인식되는 상호작용 유형을 명확히 밝혔다는 것이 골자다. 오래 써 온 마크업이라도 문서가 바뀌면 기존 코드가 낡은 방식일 수 있다는 뜻이라, 지금 점검해 둘 가치가 있다.
영상 콘텐츠를 다루는 사이트라면 이 변화가 남의 이야기가 아니다. 블로그에 영상 강의나 제품 소개 영상을 자체 호스팅으로 올리는 홈페이지, 교육 콘텐츠 플랫폼, 후기 영상을 상품 페이지에 붙이는 쇼핑몰까지 모두 VideoObject 마크업의 적용 대상이다. 텍스트 콘텐츠는 스키마를 꼼꼼히 챙기면서 영상은 그냥 <video> 태그만 붙여두는 경우가 실무에서 의외로 많다.
이 글은 VideoObject의 필수·권장 속성부터 이번 업데이트로 명확해진 부분, Clip과 SeekToAction의 차이, 라이브 스트리밍과 영상 사이트맵과의 관계, 자사 호스팅 영상에 적용할 때 흔히 놓치는 실수까지 실제 마크업 예시로 정리한다.
이 글의 핵심은 다음과 같다.
- VideoObject의 필수 속성은 name·thumbnailUrl·uploadDate 세 가지뿐이다. 나머지는 모두 권장 속성이다.
- 2026년 9월 업데이트로 creator·author 속성 지원이 공식 문서화됐고, interactionStatistic이 인식하는 상호작용 유형(WatchAction·LikeAction·CommentAction·ShareAction)이 명확해졌다.
- 오래된 코드에 남아 있는 interactionCount는 스키마닷오알지가 이미 오래전 폐기한 속성이다. interactionStatistic 구조로 바꿔야 한다.
- 키 모먼트(영상 특정 구간 바로가기)는 직접 타임스탬프를 지정하는 Clip과 URL 패턴으로 구글이 자동 감지하는 SeekToAction 두 방식 중 하나를 고른다.
- 유튜브 임베드가 아닌 자사 호스팅 영상은 contentUrl에 실제 영상 파일 URL을 넣어야 구글이 파일 형식까지 확인할 수 있다.
VideoObject 구조화 데이터란 무엇인가
VideoObject는 웹페이지 안의 영상 하나를 구글에게 설명하는 구조화 데이터 타입이다. 제목·설명·썸네일·업로드 날짜 같은 기본 정보를 코드로 명시하면, 구글은 이 페이지에 영상이 있다는 것과 그 영상이 무엇에 관한 것인지를 본문 텍스트를 추측하지 않고도 정확히 파악한다.
이 마크업이 있으면 구글 검색 결과에서 일반 텍스트 링크 대신 영상 썸네일이 딸린 비디오 리치 결과로 노출될 수 있다. 재생 시간, 업로드 날짜 같은 정보가 함께 표시되기도 하고, 조건이 맞으면 영상 특정 구간으로 바로 이동하는 키 모먼트 링크까지 검색 결과에 뜬다. 클릭 전에 어떤 영상인지 미리 가늠할 수 있으니 클릭률에도 직접적인 영향을 준다.
유튜브에 올린 영상을 그대로 임베드하는 페이지는 구글이 유튜브 쪽 메타데이터를 함께 활용하기 때문에 VideoObject 없이도 어느 정도 인식된다. 하지만 자사 서버에 직접 올린 영상은 이 마크업이 사실상 유일한 설명서다.
구글이 요구하는 자격 조건은 세 갈래다. 첫째 일반 검색 노출을 위한 Search Essentials(검색 필수 요건)를 지켜야 하고, 둘째 구조화 데이터 공통 가이드라인(스팸성 마크업 금지, 실제 페이지 내용과 일치)을 따라야 하며, 셋째 영상 자체가 색인 가능해야 한다. robots.txt로 막혀 있거나 noindex가 걸려 있거나 로그인 뒤에 숨어 있는 영상은 아무리 마크업을 완벽히 채워도 리치 결과로 뜨지 않는다.
필수 속성과 권장 속성은 무엇인가
구글이 실제로 요구하는 필수 속성은 name·thumbnailUrl·uploadDate 세 가지뿐이다. 이 셋이 빠지면 리치 결과 자격을 아예 얻지 못한다.
| 속성 | 구분 | 설명 |
|---|---|---|
name |
필수 | 영상 제목. 페이지 안의 다른 영상과 겹치지 않는 고유한 텍스트 |
thumbnailUrl |
필수 | 해당 영상만의 고유 썸네일 이미지 URL |
uploadDate |
필수 | ISO 8601 형식의 발행 일시(시간대 정보 포함 권장) |
description |
권장 | 영상 설명. 영상마다 고유하게 작성 |
contentUrl |
권장 | 영상 파일 원본을 가리키는 URL(자사 호스팅 시 사실상 필수) |
embedUrl |
권장 | 해당 영상 전용 플레이어 페이지 URL |
duration |
권장 | ISO 8601 형식의 재생 시간(예: PT1M54S = 1분 54초) |
creator / author |
권장(신규 문서화) | 영상 제작자·게시 주체. Person 또는 Organization |
interactionStatistic |
권장(신규 명확화) | 조회수·좋아요 등 상호작용 통계 |
expires |
권장 | 영상이 사라지는 시점(기간 한정 콘텐츠에 한해) |
regionsAllowed / ineligibleRegion |
권장 | ISO 3166-1 국가 코드로 시청 허용·제한 지역 명시 |
나쁜 예와 좋은 예를 비교하면 차이가 뚜렷하다.
나쁜 예 — 필수 속성만 채우고 나머지는 방치:
{
"@context": "https://schema.org",
"@type": "VideoObject",
"name": "영상",
"thumbnailUrl": "https://example.com/thumb.jpg",
"uploadDate": "2026-09-01"
}
제목이 "영상"처럼 의미 없는 문자열이고, 시간대 정보도 없다. 구글이 이 영상을 다른 영상과 구별할 근거가 거의 없다.
좋은 예 — 권장 속성까지 구체적으로 채운 경우:
{
"@context": "https://schema.org",
"@type": "VideoObject",
"name": "홈페이지 제작 비용, 견적서 읽는 법 3분 정리",
"description": "홈페이지 제작 견적서에서 페이지 수·기능별 비용을 확인하는 법을 실제 사례로 설명합니다.",
"thumbnailUrl": "https://iruweb.com/images/videos/quote-guide-thumb.jpg",
"uploadDate": "2026-09-01T09:00:00+09:00",
"duration": "PT3M12S",
"contentUrl": "https://iruweb.com/videos/quote-guide.mp4",
"embedUrl": "https://iruweb.com/videos/quote-guide/embed"
}
제목에 검색 의도가 담긴 구체적인 문구를 쓰고, 시간대까지 포함한 ISO 8601 날짜를 쓴 것이 핵심 차이다.
2026년 9월 업데이트, 무엇이 달라졌나
이번 문서 업데이트에서 구글이 밝힌 목적은 명확하다. creator·author 속성 지원을 문서화하고, interactionStatistic에서 지원되는 상호작용 유형을 명확히 하기 위함이라는 것이다.
첫 번째 변화는 creator 속성이다. 예전에는 영상 제작자를 표시할 공식 방법이 문서에 뚜렷하지 않았지만, 이제는 Person 또는 Organization 타입으로 명시할 수 있다.
"creator": {
"@type": "Person",
"name": "홍길동",
"url": "https://iruweb.com/authors/hong"
}
기업이 발행한 영상이라면 Organization 타입을 쓴다. name 또는 alternateName 중 하나는 반드시 있어야 하고, url은 선택이다.
"creator": {
"@type": "Organization",
"name": "이루웹",
"url": "https://iruweb.com"
}
두 번째 변화는 interactionStatistic이다. 구글은 이번에 WatchAction(조회수)·LikeAction(좋아요)·CommentAction(댓글)·ShareAction(공유) 네 가지 상호작용 유형만 공식적으로 인식한다고 밝혔다. 형식은 다음과 같다.
"interactionStatistic": {
"@type": "InteractionCounter",
"interactionType": { "@type": "WatchAction" },
"userInteractionCount": 5647018
}
나쁜 예는 이보다 훨씬 오래된 방식이다. 스키마닷오알지의 interactionCount는 이미 수년 전 폐기(supersededBy)된 속성으로, 공식 문서에 "interactionStatistic으로 대체됐다"고 명시돼 있다. 그런데도 오래된 템플릿이나 과거 예시 코드를 복사해 쓰다 보면 여전히 이 낡은 필드가 남아 있는 경우가 있다.
"interactionCount": "5647018 UserPlays"
이런 코드가 발견되면 위 InteractionCounter 구조로 바꿔야 한다. 동작 자체가 막 깨지는 것은 아니지만, 구글 문서가 공식적으로 지원한다고 밝힌 형식은 interactionStatistic 쪽이므로 신뢰도 면에서 구식 표기를 남겨 둘 이유가 없다.
여러 개의 상호작용 통계를 함께 보여주고 싶다면 interactionStatistic 값에 배열을 넣어 WatchAction·LikeAction·CommentAction·ShareAction을 각각 하나씩 나열하면 된다. 지원되지 않는 임의의 상호작용 유형을 만들어 넣는 것은 의미가 없다.
Clip과 SeekToAction, 키 모먼트는 어떻게 다른가
영상 검색 결과에서 특정 구간으로 바로 이동하는 링크(키 모먼트)를 만드는 방법은 두 가지다. 어느 쪽을 쓸지는 영상 구간을 직접 지정하고 싶은지, 구글이 자동으로 찾게 둘지에 달려 있다.
| 구분 | Clip | SeekToAction |
|---|---|---|
| 방식 | 시작·종료 시간을 초 단위로 직접 지정 | URL 패턴만 알려주고 구글이 자동 감지 |
| 작업량 | 구간마다 수동으로 마크업 작성 | 한 번만 설정하면 여러 영상에 재사용 |
| 언어 지원 | 모든 언어 | 영어·스페인어·포르투갈어·이탈리아어·중국어·프랑스어·일본어·독일어·터키어·한국어·네덜란드어·러시아어 등 제한 |
| 최소 영상 길이 | 별도 제한 없음 | 약 30초 이상 |
| 적합한 경우 | 강의·튜토리얼처럼 챕터가 명확한 영상 | 스트리밍 플랫폼처럼 영상 수가 많은 경우 |
Clip은 영상 안의 한 구간에 이름을 붙이고 정확한 시작 시점을 지정하는 방식이다.
"hasPart": [
{
"@type": "Clip",
"name": "2. 견적서에서 확인할 세 가지 항목",
"startOffset": 45,
"url": "https://iruweb.com/videos/quote-guide?t=45"
},
{
"@type": "Clip",
"name": "3. 견적이 과한지 판단하는 법",
"startOffset": 120,
"url": "https://iruweb.com/videos/quote-guide?t=120"
}
]
SeekToAction은 개별 구간을 일일이 지정하지 않는 대신, 특정 시점으로 이동하는 URL의 패턴 자체를 구글에게 알려준다.
"potentialAction": {
"@type": "SeekToAction",
"target": "https://iruweb.com/videos/quote-guide?t={seek_to_second_number}",
"startOffset-input": "required name=seek_to_second_number"
}
이 패턴을 등록해 두면 구글이 영상 내용을 분석해 스스로 주요 구간을 찾아내고, 검색 결과에 자동으로 키 모먼트 링크를 만들어 준다. 다만 이 방식은 영상 길이가 짧으면(대략 30초 미만) 적용되지 않고, 페이지에서 실제로 영상을 재생할 수 있어야 한다는 조건이 붙는다.
유튜브 임베드가 아닌 자사 호스팅 영상엔 어떻게 적용하나
유튜브 영상을 그대로 임베드한 페이지와 자사 서버에 직접 올린 영상은 contentUrl을 채우는 방식부터 다르다.
유튜브 임베드라면 embedUrl에 유튜브 임베드 주소를 넣는 것만으로도 상당 부분 인식된다. 반면 자사 호스팅 영상은 contentUrl에 실제 영상 파일(.mp4 등 지원 형식)의 바이트를 직접 가리키는 URL을 넣어야 구글이 파일 형식과 접근 가능 여부까지 확인할 수 있다.
- contentUrl: 영상 파일 자체의 URL. 재생 페이지 URL이 아니라 파일 바이트에 직접 접근되는 주소여야 한다.
- embedUrl: 자체 플레이어가 있다면 그 플레이어 페이지 URL을 함께 제공한다.
- 썸네일: 실제 영상 내용을 반영한 고유 이미지여야 한다. 다른 영상과 썸네일을 공유하면 안 된다.
- 크롤링 가능성: robots.txt에서 영상 파일 경로를 막지 않았는지, 페이지에 noindex가 걸려 있지 않은지 확인한다.
- 지역 제한: 특정 국가에서만 볼 수 있는 영상이라면
regionsAllowed(허용 지역) 또는ineligibleRegion(제외 지역)을 ISO 3166-1 국가 코드로 명시한다.
자사 호스팅 영상은 VideoObject 마크업이 사실상 구글에게 영상의 존재를 알리는 유일한 통로다. 본문 텍스트만으로는 "이 페이지에 영상이 있다"는 사실조차 구글이 확신하기 어렵다.
영상 사이트맵이 있으면 VideoObject는 생략해도 되나
결론부터 말하면 VideoObject·비디오 사이트맵·오픈그래프(OGP) 중 하나만 있어도 구글은 영상을 인식할 수 있다. 구글 공식 문서는 이 세 가지 방법 중 최소 하나를 제공하라고 안내하지, 세 가지를 전부 갖추라고 요구하지 않는다.
그렇다고 아무거나 하나만 고르면 끝이라는 뜻은 아니다. VideoObject는 영상 하나하나를 페이지 단위로 구체적으로 설명하는 방식이고, 비디오 사이트맵은 사이트 전체의 영상 목록을 한꺼번에 구글에 제출하는 방식이다. 성격이 다르다 보니 실무에서는 둘을 함께 쓰는 경우가 많다.
- 영상이 몇 개 안 되고 각 페이지에서 정성껏 설명을 채울 수 있다면 VideoObject만으로 충분하다.
- 자체 호스팅 영상이 수십 개 이상이고 새 영상이 자주 올라온다면 비디오 사이트맵을 함께 운영하는 편이 새 영상의 색인 속도에 유리하다.
- 유튜브 임베드가 중심이라면 두 방법 모두 실익이 크지 않고, 유튜브 자체 최적화가 우선이다.
세 방법 중 하나만 있어도 "인식은 된다"는 것이지, "리치 결과가 보장된다"는 뜻은 아니다. 여러 신호를 함께 주면 구글이 영상을 더 빠르고 정확하게 파악할 뿐이다.
라이브 스트리밍 영상은 VideoObject로 충분한가
실시간 스트리밍 영상은 VideoObject 대신, 혹은 VideoObject와 함께 BroadcastEvent 타입을 쓰는 것이 정확하다. 구글 공식 문서의 비디오 구조화 데이터 페이지 제목 자체가 "VideoObject, Clip, BroadcastEvent"로 세 타입을 함께 다룰 만큼, 라이브 방송은 녹화 영상과 다른 취급을 받는다.
일반 VideoObject 속성에 더해 publication 속성 아래 BroadcastEvent를 넣고, 방송 시작·종료 예정 시각(startDate, endDate)과 현재 방송 중인지 여부(isLiveBroadcast)를 명시하는 방식이다.
"publication": {
"@type": "BroadcastEvent",
"isLiveBroadcast": true,
"startDate": "2026-09-25T20:00:00+09:00",
"endDate": "2026-09-25T21:00:00+09:00"
}
방송이 끝난 뒤에도 다시보기로 페이지를 유지할 계획이라면 isLiveBroadcast를 false로 바꾸는 작업을 잊지 말아야 한다. 방송 종료 후에도 값이 true로 남아 있으면, 실제로는 끝난 방송을 구글이 계속 생방송 중인 것으로 오인할 수 있다.
자주 하는 실수는 무엇인가
실무에서 반복되는 실수는 대체로 패턴이 정해져 있다.
- 썸네일을 재사용하는 경우: 여러 영상에 같은 기본 이미지를 돌려쓰면, 구글이 각 영상을 구별할 단서가 줄어든다. 영상마다 고유한 썸네일이 필요하다.
- duration 형식을 틀리는 경우: "3분 12초"처럼 자연어로 적으면 인식되지 않는다. 반드시 ISO 8601 형식(
PT3M12S)이어야 한다. - contentUrl에 재생 페이지 URL을 넣는 경우: 영상 파일이 아니라 그 영상이 보이는 페이지 주소를 넣으면, 구글이 실제 파일 형식을 확인하지 못한다.
- 30초 미만 영상에 SeekToAction을 기대하는 경우: 짧은 영상은 키 모먼트 자동 감지 조건을 채우지 못한다. 짧은 영상이라면 Clip으로 직접 지정하거나 생략한다.
- robots.txt로 영상 경로를 막아둔 경우: 디자인 단계에서 임시로 걸어둔 차단 규칙이 배포 후에도 남아 있는 사례가 의외로 흔하다.
- 마크업만 있고 페이지에서 실제로 재생되지 않는 경우: 구조화 데이터는 페이지의 실제 콘텐츠를 설명하는 것이지, 없는 기능을 있다고 알리는 용도가 아니다. 페이지에 없는 영상을 마크업으로만 선언하면 스팸성 마크업으로 간주될 수 있다.
마크업을 배포한 뒤에는 구글 서치 콘솔의 리치 결과 상태 보고서에서 오류·경고가 있는지 확인하는 절차를 빠뜨리지 않는 것이 좋다. 구조화 데이터가 문법적으로는 맞아도, 실제 페이지 내용과 어긋나면 경고가 뜨는 경우가 있기 때문이다.
적용한 뒤 확인은 어떻게 하나
마크업을 배포했다고 끝난 것이 아니다. 구글 리치 결과 테스트 도구에 페이지 URL을 넣어 문법 오류가 없는지 먼저 확인한다. 여기서 오류가 없어야 비로소 리치 결과 후보에 오를 자격이 생긴다.
이후에는 구글 서치 콘솔의 리치 결과 상태 보고서에서 실제 배포 페이지들의 유효·경고·오류 개수를 주기적으로 살펴본다. 영상이 많은 사이트라면 서치 콘솔의 동영상 색인 생성 보고서를 함께 확인해, 구글이 실제로 영상을 색인했는지까지 점검하는 것이 안전하다. 마크업 문법은 맞아도 영상 자체가 아직 색인되지 않은 경우가 종종 있기 때문이다.
- 1단계: 리치 결과 테스트 도구로 문법 오류 확인
- 2단계: 배포 후 며칠 지나 서치 콘솔 리치 결과 상태 보고서에서 유효 페이지 수 확인
- 3단계: 동영상 색인 생성 보고서로 영상 자체의 색인 여부 확인
자주 묻는 질문
VideoObject 마크업을 넣으면 반드시 비디오 리치 결과로 뜨나
아니다. 마크업은 자격 조건 중 하나일 뿐이다. 필수 속성을 채우고 페이지가 색인 가능해도, 구글이 최종적으로 리치 결과 노출 여부를 판단한다. 마크업이 없으면 애초에 후보에도 오르지 못하지만, 마크업이 있다고 무조건 뜨는 것은 아니다.
유튜브 영상을 임베드만 해도 VideoObject가 꼭 필요한가
필수는 아니지만 권장된다. 유튜브 쪽 메타데이터로 어느 정도 인식되긴 해도, 자체 마크업을 함께 제공하면 페이지 맥락에 맞는 제목·설명을 구글에 더 명확히 전달할 수 있다.
interactionCount를 그대로 둬도 당장 문제가 생기나
당장 오류가 발생하지는 않는다. 다만 스키마닷오알지가 공식적으로 폐기한 속성이므로, 다음 번 마크업을 수정할 때 interactionStatistic 구조로 옮겨두는 것이 안전하다.
SeekToAction과 Clip을 같은 영상에 함께 쓸 수 있나
가능하다. 다만 실무에서는 관리 부담을 줄이기 위해 한쪽만 선택하는 경우가 많다. 영상 수가 많고 챕터 구분이 명확하지 않다면 SeekToAction, 강의처럼 챕터가 고정돼 있다면 Clip이 더 안정적이다.
자사 호스팅 영상의 파일 형식도 아무거나 괜찮나
아니다. contentUrl에 넣는 영상 파일은 구글이 지원하는 형식이어야 하며, 접근 시 로그인이나 별도 인증을 요구하지 않아야 한다. 형식이 맞지 않으면 마크업이 있어도 영상 자체를 구글이 처리하지 못할 수 있다.
VideoObject 구조화 데이터는 한 번 구조를 잡아두면 이후 발행하는 모든 영상 콘텐츠에 동일하게 재사용할 수 있는 자산입니다. 다만 이번처럼 구글이 문서를 업데이트할 때마다 기존 마크업이 최신 기준을 따르고 있는지 함께 점검해야 놓치는 부분이 없습니다. Article·BlogPosting 스키마 가이드에서 다룬 것처럼, 구조화 데이터는 종류마다 요구 조건이 조금씩 다르기 때문입니다.
이루웹은 SEO 최적화 홈페이지 제작과 검색엔진최적화 컨설팅을 함께 진행하면서, 영상 콘텐츠가 많은 사이트라면 VideoObject 구조화 데이터 설계와 AEO·GEO 최적화까지 함께 점검해 드리고 있습니다. 영상 콘텐츠를 구글 검색과 AI 검색 양쪽에서 제대로 노출시키고 싶으시다면 상담 문의를 통해 현재 사이트 상태부터 살펴보시길 권해 드립니다.
함께 보면 좋은 글
전체 보기구글 9월 스팸 업데이트, 이번엔 무엇이 바뀌었나
구글이 9월 24일 2026년 네 번째 스팸 업데이트를 출시했습니다. 롤아웃이 왜 유독 길어지는지, 지금 무엇을 점검해야 하는지 정리했습니다.
4분 분량서치 콘솔 '멀티모달' 검색 필터, 무엇이 바뀌었나
구글이 서치 콘솔 실적 보고서에 이미지 기반 검색을 따로 보여주는 멀티모달 필터를 추가했습니다. 무엇이 달라졌고 어떻게 확인하면 좋은지 정리했습니다.
4분 분량구글 수동 조치, 확인부터 해제까지 완벽 가이드
구글 수동 조치(매뉴얼 액션)의 종류와 확인 방법, 원인 제거부터 재검토 요청으로 해제하는 절차까지 실제 기준으로 정리합니다.
23분 분량카테고리·필터 페이지 SEO, 패싯 내비게이션 관리법
필터가 만드는 중복 URL, 색인할 조합과 막을 조합을 구분하는 기준과 robots.txt·canonical·noindex 적용법을 정리합니다.
25분 분량