多數人做網站影片，只在意內容夠不夠精彩、剪輯順不順，很少有人會想到「Google 看得懂這支影片嗎」這個問題。實際上，Google 的爬蟲對著一支影片檔案，能自動判讀的資訊非常有限，它看不出畫面裡在演什麼，也聽不出旁白講了什麼，頂多從檔名、頁面周邊文字這類間接線索猜個大概。真正能讓一支影片被正確收錄、出現在影片專屬版位、甚至被 AI 系統引用的，是放在影片旁邊那段肉眼看不到的結構化資料。
不少網站在文字內容上早就把標題、meta 敘述、schema 標記都做好了，影片卻常常還停在「上傳完就結束」的階段。這篇要講的 VideoObject 結構化資料，正是用 schema.org 定義的標準格式，把一支影片的標題、縮圖、時長、重要片段講清楚，讓搜尋引擎不用真的「看」影片也能懂它在講什麼。做法本身不難，難的是很多人不知道有這組欄位存在，或者填了卻漏了幾個關鍵屬性，結果整段標記形同白做。
搜尋引擎讀不到影片本身的內容
Google 在「影片（VideoObject、Clip、BroadcastEvent）結構化資料標記」文件裡把這件事講得很直白：「雖然 Google 會嘗試自行理解影片的相關詳細資料，您仍可用 VideoObject 標記影片，以影響影片在搜尋結果中顯示的資訊，例如說明、縮圖網址、上傳日期和時間長度。」換句話說，就算什麼都不做，Google 也會嘗試用畫面周邊的文字去猜這支影片在講什麼，只是猜出來的結果通常粗糙，標題可能取錯支影片，縮圖也可能抓到一張模糊的截圖。加上結構化資料之後，等於自己把這些資訊直接交給搜尋引擎，不用讓它用猜的。
同一份文件也列出影片能出現的介面，不只是傳統的網頁搜尋結果，還包括影片模式（專門收錄影片內容的搜尋分頁）、Google 圖片，以及 Google 探索這個以資訊流形式推播內容的介面。少了 VideoObject 標記，影片多半只會被當成頁面的附屬元素處理，很難單獨出現在這幾個版位裡。
而近年生成式 AI 系統加入搜尋生態之後，這件事又多了一層意義。AI 系統本質上跟傳統搜尋引擎一樣，「看」不到影片畫面，也「聽」不到聲音，能拿來理解一支影片的，同樣是文字化的中繼資料，而不是靠自己去看、去聽。文字內容做足 SEO 的網站不少，影片內容卻還是全站最容易被漏掉的一塊。
VideoObject 是什麼？在 JSON-LD 裡描述一支影片的標準格式
schema.org 把 VideoObject 定義成很單純的一句話：「一個影片檔案」（A video file）。它不是憑空生出來的獨立詞彙，而是掛在一整條屬性繼承鏈上，VideoObject 繼承自 MediaObject，MediaObject 又繼承自 CreativeWork。這代表一支影片在 schema.org 的世界裡，同時是一份創作內容，也是一個媒體檔案，兩層屬性都能用，像影片本身的作者、發布日期算 CreativeWork 那層，檔案時長、位元組網址則屬於 MediaObject 那層。
要把這些屬性寫進網頁，schema.org 允許三種語法，JSON-LD、Microdata、RDFa，但 Google 官方文件明確建議優先用 JSON-LD，理由也很直接。JSON-LD 是一段獨立的<script type="application/ld+json">，可以整段貼進頁面的任何位置，不必像 Microdata 那樣把屬性拆散到一堆 HTML 標籤的屬性裡，對維護跟除錯都輕鬆很多。一個最基本的 VideoObject 範例大致長這樣：
{
"@context": "https://schema.org",
"@type": "VideoObject",
"name": "示範影片標題",
"description": "這支影片在講什麼的完整說明文字",
"thumbnailUrl": [
"https://example.com/videos/thumbnail.jpg"
],
"uploadDate": "2024-03-31T08:00:00+08:00",
"duration": "PT1M54S",
"contentUrl": "https://example.com/videos/file.mp4",
"embedUrl": "https://example.com/videos/embed"
}Code language: JSON / JSON with Comments (json)這段程式碼裡的每一個欄位都對應到前面提過的某個屬性，name是標題、thumbnailUrl是縮圖、uploadDate是上傳時間、duration是片長，contentUrl跟embedUrl則分別指向影片檔案本身與播放器頁面，這兩個是整組標記裡最容易被搞混的欄位。這段標記必須放在使用者實際能觀看這支影片的那個頁面上，不是隨便找一頁塞進去就有效，光是語法寫對還不夠，能不能生效，得先看這個頁面本身夠不夠格。
先符合觀賞頁面資格，影片功能才會生效
Google 官方把這類頁面稱為「觀賞頁面」，簡單說就是這個頁面存在的主要目的就是要讓使用者看這支影片。算數的例子包括影片到達網頁、劇集播放器頁面、新聞影片觀賞頁面、體育賽事精華頁面、活動短片頁面，這幾種頁面的核心內容本來就是影片本身。
但反過來，有些頁面雖然嵌了影片，卻不算觀賞頁面。Google 官方點名的反例包括內嵌一支影片當輔助說明的部落格文章、含產品 360 度展示影片的產品頁、列出一整排同樣顯眼影片的影片分類頁，以及只嵌了一支預告片的電影評論頁面，這幾種頁面的重點都是影片以外的內容，影片只是配角，不是主體。把 VideoObject 標記加在這種頁面上，搜尋引擎的判讀邏輯本來就跟預期不一樣，標記大概率不會被當成該頁的核心內容。
就算頁面性質對了，還有幾個門檻要跨過。這個觀賞頁面本身要先被 Google 建立索引，而且必須在搜尋中有一定的成效，影片才有機會一併被編入索引；影片必須是真的嵌入在這個頁面裡，不能被其他版面元素擋住或蓋住；縮圖也要能透過一個穩定網址持續取得，不能今天有明天連結失效。這些前提沒處理好，標記寫得再工整，Google 也不會理它。
確認頁面資格沒問題之後，才輪到標記本身，先看哪三個欄位是「不填就等於沒做」的必要屬性。
缺一就抓不到影片資訊的三個必填欄位
Google 官方文件把name、thumbnailUrl、uploadDate列為必要屬性，並且講得很重：「如果您未提供必要屬性，Google 可能無法擷取任何影片相關資訊。」也就是說，這三項不是填了加分，是沒填等於整段標記作廢的等級。
name是影片標題，規則是站上每一支影片都要有一個專屬、不重複的標題。常見的錯誤是直接沿用頁面的標題標籤當作影片標題，兩者看起來省事，實際上如果同一頁放了兩三支影片，標題全部一樣，搜尋引擎根本分不出哪支是哪支。
thumbnailUrl指向影片專屬的縮圖檔案，同樣要求每支影片獨立，不能共用一張站上的預設圖，格式與尺寸另外有一整套規格要注意。
uploadDate是影片首次發布的日期時間，採 ISO 8601 格式，官方建議一定要附上時區資訊。這一項最容易被漏掉的地方是時區。沒有附時區，系統會用 Googlebot 所在的時區去推算，對台灣網站來說，等於讓對方用一個猜不到的時區去判斷「首次發布」的那個時間點。實務上直接把+08:00寫進去就好，例如2024-03-31T08:00:00+08:00，不要讓系統自己猜。
縮圖有具體規格，格式、尺寸和網址都不能隨便
Google 官方「影片 SEO 最佳做法」文件把縮圖規格整理成一張表，支援的格式包括 BMP、GIF、JPEG、PNG、WebP、SVG 跟 AVIF，涵蓋範圍相當廣，一般網站常用的圖檔格式幾乎都在清單裡。
尺寸規定是至少 60×30 像素，但這個數字容易讓人誤會，它其實是技術上能通過檢查的最小值，不是建議尺寸。官方原文緊接著就補一句「Google 偏好較大的縮圖」，實務上 60×30 像素這種比例接近一枚郵票，就算符合規格，顯示在搜尋結果裡也不會好看，真的要用就該用大上許多倍的圖檔。
透明度規定比較少人注意到，縮圖裡至少 80%的像素，其 Alpha（透明）值必須大於 250。白話來說就是這張圖不能大面積透明，如果縮圖是去背後的 PNG，四周留白一大片透明區塊，反而可能不符合這條規則。
存取規定同樣重要，縮圖檔案必須讓 Googlebot 與 Googlebot 圖片都能存取到，不能用robots.txt擋住，也不能設登入門檻，而且要用一個穩定網址持續提供。這裡有一個實務上常忽略的細節，如果同一支影片同時在 Sitemap 跟結構化資料裡各自指定了縮圖，兩邊給的網址一定要一致，一邊指向新圖、一邊還留著舊圖網址，等於自己給 Google 兩種說法。
提高複合式結果機會的建議屬性
必填的三項確認好之後，Google 官方還列出一組建議屬性，這些欄位不填不會讓標記直接失效，但官方講得明白，補齊能替內容「增添更多相關資訊，提供更優質的使用者體驗」，也是提高複合式結果出現機會的關鍵。
description是影片的文字說明，同樣要求每支影片各自撰寫，不能整站共用一段罐頭文案；duration則是影片時長，用 ISO 8601 格式表示，例如PT1M54S代表 1 分 54 秒，這種格式一開始看會覺得陌生，但只要記住 P 代表期間、T 分隔日期與時間、後面接數字加單位字母，套進去就對了。
最常被寫錯的是contentUrl跟embedUrl這一組。contentUrl指向的是影片檔案實際內容位元組的網址，也就是那個檔案本身，不是影片所在的網頁；embedUrl則是指向該影片播放器的網址，同樣不是網頁本身。兩者意義不同，Google 官方文件甚至特別提醒「請勿連結至影片所在的網頁」，這兩個欄位錯填成同一個網頁網址，是這組標記裡最容易踩的坑之一。這兩個屬性至少要填一個，才能讓 Google 有辦法真正存取影片內容。
expires是影片到期日期時間，只有真的有時效性的影片才需要填，一支長期都能觀看的影片不該加這個欄位，加了反而暗示它會消失。interactionStatistic則用來標記觀看次數，寫法是巢狀的InteractionCounter，用來包一個互動類型跟一個計數值。至於影片檔案本身的格式，Google 支援的類型相當廣，包括 3GP、3G2、ASF、AVI、DivX、M2V、M3U、M3U8、M4V、MKV、MOV、MP4、MPEG、OGV、QVT、RAM、RM、VOB、WebM、WMV、XAP，但明確不支援 data URL 這種把整個檔案編碼塞進網址字串的做法。
YouTube 嵌入和自架影片，能填的欄位並不相同
多數台灣網站放的影片其實是嵌入 YouTube，不是自己伺服器上的影片檔案，這跟前面講的規格會出現一個明顯落差。嵌入 YouTube 的影片，通常填不出contentUrl，因為 YouTube 不對外開放影片檔案本身的直接位元組網址，能拿到的只有嵌入播放器的網址。這種情況下，contentUrl這欄留空是合理的，不是漏做，把可以填的embedUrl填好就夠，通常就是youtube.com/embed/加上影片 ID 這種格式。
Google 官方在「使用第三方嵌入式播放器」一節講得直白：「如果您的網站嵌入了 YouTube、Vimeo 或 Facebook 等第三方平台的影片，Google 可能會在您的網頁和第三方平台的相應網頁上將影片編入索引。」而且即使嵌入的是第三方播放器，官方仍建議照樣補上結構化資料。這代表複合式搜尋結果的縮圖跟導流，有可能指向 YouTube，而不是自己的網站，這是選擇嵌入第三方平台之前就該知道的取捨，不是設定沒做好才發生的結果。
如果網站本身沒有自架影片的能力、只能用第三方嵌入，除了結構化資料之外，還有一件同樣重要的事可以做，就是在影片周邊寫清楚跟影片內容相關的文字，包括標題與上下文段落，幫助 Google 理解這支影片在講什麼。這件事跟有沒有結構化資料是兩回事，兩者都做才算把能做的都做了，不能因為填了embedUrl就以為文字說明可以省略。
重要時刻功能，讓使用者跳到自訂片段
Google 搜尋有一項叫「重要時刻」的功能，把一支長影片拆成像書本章節一樣可以逐段跳轉的片段。Google 官方講得很清楚：「您不必採取任何行動，Google 搜尋就會自動嘗試偵測影片中的片段，並向使用者顯示重要時刻。」也就是說，就算什麼都不做，這個功能可能已經在網站的影片上運作。但同一份文件緊接著補了一句更關鍵的話：「我們會優先採用您透過結構化資料或 YouTube 說明設定的重要時刻。」換句話說，自己標記的優先權比 Google 自動偵測的結果高。
不論用哪一種手動標記方式，都要先符合幾個共通門檻。影片必須具備深層連結，能導向影片開頭以外的特定時間點，例如網址加上?t=30就能直接跳到第 30 秒；VideoObject 結構化資料必須加在使用者能實際觀看影片的那個頁面上，呼應前面講過的觀賞頁面資格；影片總長度必須至少 30 秒；而且影片本身要具備前面提過的那幾個必要屬性，少了name、thumbnailUrl、uploadDate任何一個，重要時刻也標不出來。
如果完全不想要這個功能出現，包含 Google 自動偵測顯示的部分，做法是加上nosnippet這個 meta 標記，但這等於把所有片段預覽都關掉，對大部分想提高曝光的網站來說，通常不會這麼做。
自己標出片段起訖時間的 Clip 屬性
Clip 的寫法是在hasPart底下巢狀放一個或多個Clip物件，每一段代表影片裡的一個片段。必要屬性有三個，name是這段片段的描述性標題，startOffset是這段片段從影片開頭起算的秒數，url則是指向這個起始時間的網址。
這裡有個容易忽略的規則，url必須指向跟影片相同的網址路徑，只是額外多帶一個代表時間點的查詢參數，不能是另一個獨立的網址。Google 官方用網址舉例，https://example.com/video?t=120代表這支影片從 2 分鐘的位置開始播放。建議屬性endOffset則是這段片段的結束時間，補上之後 Google 更清楚片段的邊界在哪裡。整段結構大致長這樣：
{
"@context": "https://schema.org",
"@type": "VideoObject",
"name": "示範影片標題",
"hasPart": [
{
"@type": "Clip",
"name": "示範片段標題",
"startOffset": 30,
"endOffset": 45,
"url": "https://example.com/video?t=30"
}
]
}Code language: JSON / JSON with Comments (json)有一條限制務必守住，同一個頁面裡，同一支影片底下不能有兩個片段的起始時間重複。標了好幾段 Clip，記得檢查每段的startOffset都是獨立的數字，重複的話等於同一個時間點被標記了兩次，不符合規範。
SeekToAction，把網址規則交給 Google 自動判讀
跟 Clip 逐段手動標記不同，SeekToAction 的邏輯反過來，不用列出每一段片段在哪裡，而是告訴 Google 網址結構長什麼樣子、時間戳放在哪個位置，剩下的由 Google 用機器學習自動判斷重要片段，自己生成連結。做法是在potentialAction底下巢狀一個SeekToAction，帶target（一個含有{seek_to_second_number}佔位字串的網址樣板）跟startOffset-input（固定寫required name=seek_to_second_number）。
範例結構大致是這樣：
{
"@context": "https://schema.org",
"@type": "VideoObject",
"name": "示範影片標題",
"potentialAction": {
"@type": "SeekToAction",
"target": "https://example.com/video?t={seek_to_second_number}",
"startOffset-input": "required name=seek_to_second_number"
}
}Code language: JSON / JSON with Comments (json)比起 Clip 要一段一段手動維護，SeekToAction 省事很多，影片重新剪輯之後也不用回頭改標記，代價是實際會被標出來的片段由 Google 自己決定，無法指定哪一段要被推播。這個做法有個前提，Google 必須能夠擷取影片內容檔案，也就是contentUrl要能被存取到，這正是前面提過的落差所在，YouTube 內嵌的影片因為填不出contentUrl，沒辦法用 SeekToAction 這條路，只能靠 Clip 手動標記，或乾脆放給 Google 自動偵測。另外有一個台灣讀者會在意的細節，這項功能目前支援的語言清單裡包含中文，跟英文、西班牙文、葡萄牙文、義大利文、法文、日文、德文、土耳其文、韓文、荷蘭文、俄文並列，用繁體中文製作的內容，一樣用得上這個功能。
AI 讀懂影片靠的是逐字稿與描述文字
前面提過，不論是傳統搜尋引擎還是新一代的 AI 系統，面對一支影片能實際處理的都是文字，不是畫面或聲音本身。schema.org 在 VideoObject 的屬性清單裡，剛好就有一個專門處理這件事的欄位，transcript，官方定義寫得很直接：「如果這個 MediaObject 是 AudioObject 或 VideoObject，這裡放的是該物件的逐字稿。」這個欄位的存在本身就說明了一件事，把影片內容轉成文字，在結構化資料的世界裡本來就是被正式承認的做法，不是土法煉鋼硬湊出來的變通方案。
前面提過的description欄位同樣是純文字，而且不論傳統搜尋還是 AI 系統都會讀取這一欄。這代表它不該隨便複製頁面標題交差，而是要寫成一段真正描述這支影片在講什麼的完整摘要，內容愈具體，AI 在整理答案時愈有機會正確引用這支影片，而不是含糊帶過或乾脆跳過不用。
逐字稿可以有兩種呈現方式，而且建議兩種一起做。一種是把逐字稿當成頁面上看得見的文字內容，例如放在影片下方的一個文字稿區塊；另一種是透過transcript屬性明確標記給搜尋引擎讀。兩者不衝突，同時做等於把同一份素材，分別交給人類讀者跟機器兩邊都看得到。
逐字稿跟字幕的準確度，會直接影響 AI 判讀的正確性。自動產生的字幕在專有名詞、中英夾雜的內容上特別容易出錯，一段沒校正過的逐字稿，反而可能讓 AI 從一開始就理解錯這支影片在講什麼；真正乾淨、能拿來用的素材，是人工校正過的文字稿，而不是語音辨識吐出來就直接貼上去的版本。
上線前後驗證要用的複合式搜尋結果測試與影片報表
標記寫完不代表工作結束，Google 官方把驗證流程拆成上線前跟上線後兩個階段。上線前，先用複合式搜尋結果測試工具驗證程式碼本身有沒有問題，修正所有被標為重大的錯誤，這類錯誤會直接擋下複合式結果的顯示資格；工具也可能標出一些非重大問題，官方建議照樣修正，理由是這有助於提升結構化資料的整體品質，只是不修也不會擋資格。
上線之後，改用網址檢查工具確認 Google 實際轉譯這個頁面的結果，重點是確保頁面沒被robots.txt擋掉、沒被設成noindex，也沒有登入限制擋住 Googlebot 存取，這幾個問題常常不是標記本身寫錯，而是頁面層級的權限設定沒抓對，標記寫得再對也沒用。
長期則靠 Search Console 的三份報表持續盯。「影片索引報表」看有多少觀賞頁面裡的影片真的被建立索引、沒被索引的原因是什麼；「影片複合式搜尋結果報表」專門檢查並修正 VideoObject 標記的導入問題；「成效報表」則可以用影片搜尋外觀篩選器，單獨看影片在 Google 搜尋裡的曝光、點擊與排名表現。
另外建議提交影片 Sitemap，讓 Google 能更快掌握新增或異動的影片內容，不用完全依賴重新爬取整個頁面才發現有更新。
標記能提高的是曝光與點擊，不是排名保證
加了標記能帶來什麼實際效果，Google 自己就提供過一個具體案例。印尼影音平台 Vidio 在導入 VideoObject 標記後的一年內，影片曝光次數增加了大約 3 倍，影片點擊次數也增加了將近 2 倍。特別要注意的是，同一段期間他們發布的影片數量只增加了大約 30%，曝光跟點擊的成長幅度遠遠超過影片數量本身的成長，說明真正的推力是標記讓影片有資格出現在更多版位，而不是單純多發了片子。
但誠實地說，結構化資料不是排名因子。Backlinko 分析過 1180 萬筆 Google 搜尋結果，發現首頁的網頁裡大約 72.6%都用了結構化資料，可是結構化資料的有無，跟排名高低之間沒有相關性。這跟 Google 官方一貫的說法一致，結構化資料只影響一支內容有沒有資格出現複合式結果，不是直接把排名往上推的因素。
真正會提高的是曝光跟點擊的機會。Milestone Research 分析超過 452 萬組查詢、27 億次曝光的資料發現，複合式搜尋結果平均可以拿到 58.2%的點擊率，一般純文字結果只有大約 41%；其中影片類複合式結果本身的點擊率是 61.6%，又比整體平均高出一截。加了 VideoObject 標記不會直接讓影片衝上第一名，但確實能讓已經出現在搜尋結果裡的影片，被更多人看見、被更多人點進去。
影片的畫質、剪輯、腳本這些，決定的是人願不願意看下去；VideoObject 結構化資料決定的，是搜尋引擎跟 AI 系統願不願意先讓人看到它。兩件事同樣重要，卻經常只有前者被重視。把必填的三個欄位填齊、把 contentUrl 跟 embedUrl 分清楚、把逐字稿準備乾淨，這幾件事做起來不需要工程團隊，一支影片、一段 JSON-LD，就能讓原本被埋在頁面裡的內容，重新被搜尋引擎跟 AI 讀懂。