Facebook 的分享預覽爬蟲不會讀取數值型的 Page ID；它會從你頁面的 HTML head 讀取 Open Graph 標籤。對大多數分享預覽來說，透過 Graph API 查詢 Page ID 是錯誤的方向 —— Open Graph Protocol 中並沒有 og:page_id 屬性，Facebook 的爬蟲也從來不會向你頁面請求這項資料。爬蟲實際請求的是四個必要的 Open Graph 屬性：og:title、og:type、og:image 與 og:url，以 meta 元素的形式放在標準頁面的 head 內。Open Graph Generator 正是依據這個協定，從安全輸入產生完全符合規範的區塊，且整個流程都在覽器中執行，不需要應用程式註冊、存取權杖或 Graph API 呼叫。唯有當你想透過程式發布貼文、讀取留言或管理 Facebook 粉絲專頁時，才會需要數值型的 Page ID —— 這些動作屬於需要驗證的 Graph API 呼叫，與分享預覽無關。如果目標是在 Facebook、LinkedIn、Slack、Discord 或任何其他支援 Open Graph 的平台上產生分享預覽，正確做法是在自己的頁面上提供格式正確的 Open Graph metadata，並在部署後透過各平台的除錯工具進行驗證。
為什麼 Graph API Page ID 並非分享預覽所讀取的內容
當 URL 被貼到 Facebook 的發文框時，平台會派出一個爬蟲前往目的地。該爬會抓取頁面、解析 HTML head，並讀取所有找到的 og:* meta 元素。四個必要的 Open Graph 屬性 —— og:title、og:type、og:image 與 og:url —— 共同描述了可分享的 graph object，這就是預覽所顯示內容的完整合約。協定端並沒有任何欄位接受 Facebook Page ID；這個協定刻意採用以頁面為導向的設計，讓任何網站（無論是否擁有 Facebook 帳號）都能產生分享預覽。
Graph API 的端點，例如 /{page-username}?fields=id 或 /{page-id}?fields=link，雖然會回傳數值型識別碼，但這些數字無法塞進 meta 標籤中。它們適合用於應用程式權杖、貼文自動化、留言抓取與粉絲專頁管理 —— 這些都不是分享預覽會用到的功能。將查詢 Page ID 視為分享預覽的入口，是一種分類上的錯誤，會浪費時間在應用程式審查、存取權杖與爬蟲根本不會讀取的權限上。
Open Graph Protocol 真正要求的內容
Open Graph Protocol 定義了四個必要的基本屬性，而產生器每次都會以固定的順序優先輸出它們：
- og:title —— 為分享物件命名。經過修剪、長度限制，並針對 HTML 屬性進行跳脫處理，確保 &、"、<、> 等字元不會破壞 meta 元素。
- og:type —— 為物件分類。產生器刻意將此限制為 website 或 article；music、video、profile 等其他結構化類型需要額外的類型專屬欄位，這份精簡表單並未提供。
- og:image —— 提供代表性的圖片。必須是不含內嵌認證資訊或片段（fragment）的絕對 HTTP 或 HTTPS URL。
- og:url —— 識別永久物件。同樣必須是絕對的 HTTP 或 HTTPS URL，不能包含片段或認證資訊。
缺少任何必要值時，輸出會被封鎖，而不會產生不完整的預覽區塊。協定生態系允許更多類型與更多屬性，但那些屬於專門實作的範疇。有效的 Open Graph 區塊仍無法保證貼文實際呈現的方式 —— 分享系統可能會裁切圖片、截斷文字、忽略欄位、選擇快取資料，或套用帳號層級的政策。應將各平台的除錯工具（而非僅看協定規格）視為呈現方式的最終依據。
使用 Open Graph Generator 建立分享預覽 metadata
產生器在瀏覽器中完成所有工作，於執行階段驗證輸入，並以固定的順序回傳基於屬性的 meta 區塊。請依照下列三個步驟部署可正常運作的預覽。
- 輸入正確的物件文字、選擇 website 或 article，並提供不含片段、公開可存取的頁面與圖片 URL。瀏覽器的 URL parser 會將其正規化；此工具不會實際抓取任何端點。不含片段的物件 URL 可避免同一資源因前端錨點不同而分散於多則分享中；拒絕認證資訊則可避免將使用者資訊複製到公開的 metadata 中。
- 產生必要與選用的 Open Graph 屬性，然後將僅含協定的區塊複製到標準頁面的 head 中。產生器會先輸出四個必要屬性，接著是你提供的任何選用屬性，例如 og:description、og:site_name 與 og:locale。選用文字會經過修剪、長度限制、含控制字元時予以拒絕，並針對 HTML 屬性進行跳脫。物件類型會在執行階段重新驗證，即使表單使用的是 select 控件也是如此，因此被竄改或透過程式送入的輸入無法帶不支援的類型。
- 檢查實際部署的原始碼，並使用每個目標平台目前的預覽除錯工具來確認抓取存取、圖片處理與快取更新。建置工具可能會重新排序、覆寫或新增衝突的屬性，因此已部署的 HTML head 才是最終的檢查依據。在平台的爬蟲首次讀取頁面後，即使 metadata 之後更新，它仍可能繼續顯示較舊的快取預覽 —— 每個服務都會記載各自的快取更新行為。
必要與選用屬性一覽
下表彙整產生器輸出的內容、輸出順序，以及每個值的處理方式。所有屬性值皆經過跳脫，所有 URL 皆經過正規化，四個必要屬性會排在任何選用屬性之前。
| 屬性 | 是否必要 | 用途 | 產生器行為 |
|---|---|---|---|
| og:title | 必要 | 為分享物件命名 | 經修剪、長度限制、HTML 跳脫 |
| og:type | 必要 | 為物件分類 | 僅限 website 或 article；執行階段重新檢查 |
| og:image | 必要 | 代表性圖片 | 絕對 HTTP(S)，不含認證與片段；不會實際抓取 |
| og:url | 必要 | 標準物件 URL | 絕對 HTTP(S)，不含認證與片段 |
| og:description | 選用 | 預覽摘要文字 | 經修剪、拒絕控制字元、HTML 跳 |
| og:site_name | 選用 | 標示所屬網站 | 經修剪、長度限制、HTML 跳脫 |
| og:locale | 選用 | language_TERRITORY（例如 en_US） | 保守的兩字母語系加兩字母地區代碼 |
語系驗證器刻意只接受「兩字母語系 + 兩字母地區」的保守格式。替代語系與 script 子標籤需要額外的協定屬性與編輯決策，已超出這份精簡表單的範圍，因此產生器會拒絕任何更複雜的輸入，而不是產出表面上看似正確、實際上錯誤的值。
驗證抓取存取、圖片處理與快取狀態
產生器無法驗證 HTTP 狀態、MIME 類型、圖片尺寸、位元組大小、長寬比、重定向、robots 規則、認證或平台快取狀態。每個社群服務都有自己的圖片要求；即使你的協定區塊通過驗證，也無法說明平台另一端會如何呈現。請將分享預覽流程視為兩個階段：你部署的頁面，以及每個平台保留的快取。
在 meta 區塊放入標準頁面的 head 之後，請開啟每個目標平台目前的預覽除錯工具，貼上頁面 URL 並要求重新抓取。將呈現出的預覽與已部署的原始碼進行比對 —— 標題、說明、圖片與 URL。若預覽仍顯示舊內容，代表平台快取了較舊的版本；請參考該服務的說明文件以了解其快取更新行為，並在支援時手動觸發更新。若預覽為空白或不正確，最常見的原因包括爬蟲被封鎖、圖片回傳非 2xx 狀態、圖片 MIME 類型錯誤，或圖片不符合該平台的最低尺寸。協定區塊在建構上即為正確；平台預則是另一個獨立的驗證步驟。
導致預覽失效的常見錯誤
大多數預覽失敗來自通過產生器驗證、卻在真實爬蟲存取真實頁面時才暴露出問題的輸入。請特別留意以下情況：
- URL 中包含片段或認證資訊。og:url 或 og:image 中的 #section 或 ?token=... 會被產生器正規化移除；如果你繞過產生器、手動撰寫 meta 標籤，片段會保留下來，破壞標準訊號。
- 圖片無法從公開網路抓取。產生器只驗證 URL 格式，不會實際抓取。需要登入、防盜連、robots 封鎖或回傳非 2xx 的圖片，都會通過表單驗證，卻在平台爬階段失敗。
- 圖片尺寸或 MIME 類型錯誤。每個平台都有自己的最低限制。在協定端通過驗證的 og:image URL 並不代表滿足該平台的位元組大小、長寬比或檔案格式規則。
- 快取過期。即使 metadata 已更新，平台仍可能持續顯示舊的預覽。每個服務都有自己的更新週期與手動發機制。
- 內容具有誤導性。標題、說明或圖片若與頁面實際內容不符，可能吸引點擊卻讓使用者失望。請撰寫能真實反映頁面內容的 metadata。
若你在發布頁面前打算透過 Graph API「取得 Page ID」，請先停下來：API 路線適用於發文與管理，Open Graph metadata 路線才適用於分享預。只要透過 Open Graph Generator 跑一次，再搭配各目標平台的除錯工具檢查，就能解決 Page ID 查詢從未打算處理的問題。若你想更精確地了解是否仍需要 API 權杖，請參考 Graph API 存取權杖取得教學。