一個可運作的 open graph 產生器範例會展示四個必要的 og: 屬性 — og:title、og:type、og:image 和 og:url — 以穩定順序作為以 property 為基礎的跳出後 meta 元素輸出在 HTML head 內部。Open Graph 通訊協定將這四個定義為分享服務辨識一個頁面為可分享 graph 物件所需的最低資料，而任何輸出少於四個的產生器都會產生不完整的 metadata。一個完整的範例還包含三個選用屬性 — og:description、og:site_name 和 og:locale — 它們在出現時能豐富預覽內容，並會套用精確的 HTML 跳出，使得值內部的 & 符號、引號和角括號無法破壞 meta 元素。輸出是一段可複製貼上的 meta 標籤區塊，您將其放置在標準頁面的 head 內;它不是 script，不是 JSON-LD 酬載，也不是可見的 body 元素。當四個必要輸入都有效時，以下的範例就是一個 open graph 產生器範例應該產生的內容:一個絕對頁面 URL、一個絕對圖片 URL、一個非空白的標題，以及一個來自刻意精簡清單中已辨識的物件類型。
有效 Open Graph 區塊的剖析
當您執行一個專注的 Open Graph 產生器時，結果是一小段依序排列的 meta 標籤，使用 property 屬性而非更常見的 name 屬性來撰寫。Open Graph 通訊協定記載於 ogp.me，並明確要求使用以 property 為基礎的語法;使用 name="og:title" 而非 property="og:title" 是「可運作」區塊在分享服務上無聲失敗的最常見單一原因。區塊也必須放置在文件的 head 內，而不是呈現為可見文字或同時被佈景主題和外掛重複輸出。
對於 og:type 為 website 或 article 的情況，四個必要屬性已足夠。一旦您切換到更豐富的類型，例如 music.song、video.movie 或 profile，通訊協定會預期額外的結構化屬性(例如 music:duration 或 profile:first_name)，而通用產生器無法從簡短表單中提供這些屬性，這就是為何那些類型被刻意省略的原因。您可以將此類精簡且有效的範例透過 Open Graph 產生器 執行，然後將結果直接貼入您的標準頁面。
一個正確構成的範例區塊在您以原始 HTML 預覽時看起來像這樣:
| 屬性 | 範例值 | 出現位置 |
|---|---|---|
| og:title | How to Validate Open Graph Tags | 分享預覽中的標題 |
| og:type | article | 物件的分類器 |
| og:image | https://example.com/static/og.png | 由服務擷取的代表視覺圖片 |
| og:url | https://example.com/guides/open-graph-validation/ | 物件的永久識別碼 |
| og:description | A short summary of the guide. | 標題下方的輔助文字 |
| og:site_name | Example Docs | 命名較大的網站 |
| og:locale | en_US | 保守的兩字母形式中的語言與地區 |
必要與選用屬性
將七個支援的屬性拆分為必要與選用欄位，可讓任何 open graph 產生器範例的合約明確清楚。缺少任何必要值會完全封鎖輸出，而非產生部分預覽區塊，而選用欄位在留空時則會直接省略。
| 類別 | 屬性 | 留空時的行為 |
|---|---|---|
| 必要(永遠優先輸出) | og:title、og:type、og:image、og:url | 在每個值通過驗證之前，輸出會被封鎖 |
| 選用(僅在出現時輸出) | og:description、og:site_name、og:locale | 標籤會從產生的區塊中省略 |
| 刻意排除 | Twitter Card 標籤、JSON-LD 區塊、music/video/profile 擴充 | 由獨立的專門工具產生 |
這種拆分就是為何一個小型瀏覽器端產生器能保持可稽核的原因:四個必要欄位會進行執行階段檢查，即使表單使用 select 控制項，而每個選用欄位都有保守的形狀(有限長度、已修剪、拒絕控制字元)，以防止表單無聲地輸出格式錯誤的 HTML。
三步驟產生 Open Graph 標籤
- 輸入物件文字、選擇類型，並提供兩個絕對 URL。提供一個能命名物件的非空白標題，從類型選擇器中選擇 website 或 article，並貼上一個絕對 HTTP 或 HTTPS 頁面 URL 加上一個絕對圖片 URL。兩個 URL 都必須不含片段，且不得包含內嵌認證資訊，例如 user:pass@。
- 產生區塊並複製僅含協定的輸出。只在您有真實值要提供時才新增選用欄位 — 一段簡短描述、一個真實網站名稱，以及一個保守的 locale，例如 en_US。複製產生的 meta 區塊，不要將其重新編碼為 script，或包裝在另一個範本中。
- 將區塊貼入標準頁面的 head。將標籤放置在區塊所描述之標準 URL 的 head 內部。檢查已傳送的原始碼，以確認建置管線並未重新排序、覆寫或重複輸出屬性，然後使用每個目標平台目前的預覽除錯工具來檢查擷取存取、圖片處理與快取重新整理。
瀏覽器負責跳出、驗證與排序工作;頁面負責放置工作。這兩步之間的任何操作 — 重新格式化區塊、將 property 換成 name，或將標籤分散到 head 與外掛 — 就是大多數「我複製了範例但它仍然無法顯示」回報的來源。
決定區塊是否運作的 URL 規則
四個必要屬性中有兩個是 URL，而 URL 規則比大多數表單輸入所接受的更嚴格。一個有效的 open graph 產生器範例只有在頁面與圖片位址同時通過以下所有檢查時才會產生輸出:
- 僅限絕對 HTTP 或 HTTPS。相對路徑、file://、data: 和 javascript: URL 會在區塊產生之前被拒絕。人們在社群平台上看到的灰色預覽圖示中，有一半來自分享服務無法解析的相對圖片路徑。
- 不含片段。標準頁面 URL 上結尾的 #section 會防止同一資源的分享在用戶端錨點之間分裂;剖析器會在標準化過程中移除片段。
- 不含內嵌認證資訊。任一 URL 中的 user:password@ 區段會被拒絕，使得使用者資訊無法洩漏到公開的 metadata 中。
- 對爬蟲為可公開存取。產生器不會擷取任一 URL。認證、robots 控管、重新導向、MIME 類型、位元組大小、長寬比和 HTTP 狀態都會在部署時單獨驗證。關於產生可呈現圖片 URL 的配套指南詳細說明了該驗證步驟在實務上的實際樣貌。
這些規則刻意比瀏覽器在其他地方接受的 URL 文法更為嚴格。重點並非為了限制而限制 — 而是為了防止產生器輸出看似有效、但在分享服務首次爬取時悄悄出錯的區塊。
檢查已傳送的原始碼與平台除錯工具
一個有效的 open graph 產生器範例能證明區塊可以被產生;但無法證明區塊能完整送達分享服務。三個檢查點可以彌補這個落差:
- 在標準 URL 上檢視原始原始碼。確認 meta 元素出現在 head 內部、使用的是 property 而非 name，且沒有被佈景主題、外掛和 CDN worker 重複輸出。
- 直接擷取圖片 URL。檢查 HTTP 狀態、內容類型、位元組大小與尺寸。分享服務會發布各自的圖片需求，若不符合這些需求，將會退回、裁剪或拒絕該資產。
- 執行每個平台目前的除錯工具或分享檢查工具。將其顯示的標題、描述、圖片與 URL 與您的預期進行比對。由於快取的關係，即使區塊成功，仍可能呈現較舊的預覽，直到服務重新整理;請將此延遲納入考量，而非假設新 metadata 失敗。
在每個檢查點上，metadata 都必須與頁面的可見內容相符。誤導性的標題或圖片或許能換來一次點擊，但會在下次分享時侵蝕信任，而大多數平台保留降低持續誤導其爬蟲之頁面排名的權利。當頁面移動或身分變更時，請同時更新標準區塊、圖片資產與平台上的即時預覽，而不是逐一追趕。
Open Graph metadata 也與 Twitter Card metadata 不同。相同的 Open Graph 屬性在某些平台上可作為後備，但服務專屬的標籤與驗證規則仍是不同的合約。將協定分開處理，正是讓複製的區塊能保持可稽核，並防止一個被假設為跨平台欄位的屬性冒充為標準需求的原因。如需進一步了解該協定本身，ogp.me 上的標準參考文件記載了標準所公開的每個屬性，而 WHATWG HTML meta 元素規格則說明了這些標籤所依賴的屬性文法。
如果您正在權衡選項，避免在以範例產生 llms.txt 時犯錯對此有詳細說明。