Meta Tag Generator 會根據你在三個本地欄位中輸入的文字，完整地建立基本的 HTML head 標記——包括 meta description。這三個欄位分別是:文件標題、頁面描述，以及選填的作者姓名。它不會擷取 URL、不會爬取遠端頁面，也不會聯絡任何伺服器，這代表輸出內容中每一行的實際措辭，都是你自己撰寫的文字，而非工具透過解析他人 HTML 所猜測的內容。產生的區塊恰好包含五個元素:UTF-8 字集宣告、響應式 viewport 標籤、title 元素、description 中繼資料，以及在有提供時的 author 中繼資料。在複製出來的區塊中，沒有 canonical link、沒有 robots 指示、沒有 Open Graph 屬性，也沒有 Twitter Card，因為每一項都代表一個獨立的頁面決策，而這些在 Lizely 上各自都有專屬的工具。這樣的分離是有意為之:把所有 SEO 與社群用的詞彙混雜在同一個冗長的表單中，容易複製到相互矛盾或不相關的標記。本文將說明這個產生器會產生什麼、為何本地產生器通常比擷取 URL 的替代方案更安全，以及如何確切地把這個區塊實際應用在運作中的文件 head 中。
Meta Tag Generator 會建立什麼
這個工具輸出的區塊刻意保持精簡。當你輸入三個文字值並點選 generate 之後，你會得到一個可複製的程式碼片段，其中包含 UTF-8 編碼宣告、響應式 viewport 標籤、title 元素、description 中繼資料，以及選填的 author 元素。字集宣告放在最前面，以確保 head 的其餘部分會以所宣告的編碼進行解析，而 viewport 則固定為 width=device-width, initial-scale=1，這讓 layout viewport 能夠跟隨裝置寬度，同時不會停用使用者的縮放功能。
你所輸入的每個值都會經過修剪、長度限制、檢查控制字元，並針對其所在的 HTML 內容進行跳脫處理。& 符號、角括號，以及會影響屬性的引號都會進行編碼，因此將這個區塊貼入文件中不會破壞標記。根據 WHATWG HTML living standard,title 元素代表文件的標題或名稱，而 description 中繼資料則為相容的消費者提供簡短的頁面摘要。這個工具會正確地產生這兩者;但它並不保證任何特定的搜尋引擎會以任何特定方式顯示它們。
為何本地產生通常比 URL 爬取更安全
許多「meta description from URL」工具聲稱會造訪一個頁面並擷取現成的中繼資料。這種做法有三個可預見的問題:它會把你的目標 URL 傳送到第三方伺服器、當頁面被設限、重新導向或受地理限制時就可能失敗，並且傾向於擷取發布者碰巧寫下的任何描述——而這往往塞滿了關鍵字、在不同頁面之間重複，或根本完全缺失。本地產生器則能完全避開這三個問題。
由於 Meta Tag Generator 完全在你的瀏覽器中執行，因此不會有任何文字被傳送到 Lizely，也不需要任何 URL 可供連線。你並不是在編輯別人的描述，而是從頭撰寫自己的描述，這正是 Google 的標題連結說明文件等搜尋指引所建議的做法。你也能避開那種「擷取來的描述所參照的內容，實際上並未出現在目前頁面上」的不一致情況。
第二個好處是可審核性。輸出是一個具有固定元素集合的可審核區塊，讓審查、版本控管與推理都變得容易。擷取 URL 的工具通常會輸出一長串猜測出來的標籤——canonical、robots、Open Graph、Twitter Card，有時還包含 schema——你必須手動清理。Meta Tag Generator 明確地排除這些標籤，讓每一個索引或社群相關的決策都保持是有意識的選擇，而不是某個核取方塊的預設值。
如何產生 Meta Description 區塊
- 輸入一個準確的文件標題。請輸入 head 將描述的頁面標題，而不是行銷標語或關鍵字字串。根據 WHATWG 標準，HTML title 元素代表文件的標題，而它是搜尋系統可能用來組成結果連結的其中一項輸入。
- 撰寫簡潔的頁面描述。用一、兩句平實的句子摘要這個頁面所提供的內容，語氣與頁面上可見的文字一致。避免列出關鍵字，也避免在不相關的頁面之間複製貼上相同的描述，因為這兩者都很容易產生出一份會被搜尋系統以其他內容取代的描述。
- 加入選填的作者姓名。除非該網站確實為這個頁面維護一個有意義的作者署名字串，否則請將此欄位留空。author 中繼資料是一個姓名，不是已驗證的身分、版權聲明，也不是 rel=author 或結構化資料署名資訊的替代品。
- 產生並複製這個區塊。使用 Meta Tag Generator 來產生已跳脫的 head 區塊，然後複製完整的程式碼片段。請勿逐行編輯;如果你需要修改，請編輯表單中的值並重新產生，如此才能維持正確的跳脫處理。
- 將區塊貼入文件 head 之中。將這個程式碼片段插入 <head> 與 </head> 之間。請勿將它貼入 body，也不要貼入會再次跳脫標記的所見即所得編輯器中，否則將會在頁面上產生可見的角括號。
- 檢查實際部署的原始碼中是否有重複。開啟該頁面、檢視其原始 HTML，並確認 title 元素與 description meta 標籤各自僅有一個。主題、外掛與框架(例如 SEO 套件)經常會注入自己的版本，任何衝突都必須透過停用或覆寫那些預設值來解決。
欄位限制、跳脫規則與被排除的內容
這個產生器會套用嚴格的上限，以維持輸出內容的可審查性。title 最多接受 200 個字元、description 最多 500 個、選填的 author 最多 120 個。這些是語法上的最大值，並非排名目標。控制字元會被直接拒絕，而每個留存下來的值在跳脫為其所屬的 HTML 內容之前，都會先進行修剪。
| 元素 | 欄位限制 | 輸出時機 | 套用的跳脫處理 |
|---|---|---|---|
| <meta charset> | 固定值 | 永遠 | UTF-8 常數字串 |
| <meta name="viewport"> | 固定值 | 永遠 | width=device-width, initial-scale=1 |
| <title> | 200 characters | 永遠 (必要) | 對 & 符號與角括號進行編碼 |
| <meta name="description"> | 500 characters | 永遠 (必要) | 對屬性值中的引號與 & 符號進行編碼 |
| <meta name="author"> | 120 characters | 僅在有提供時 | 對屬性值中的引號與 & 符號進行編碼 |
被排除的內容與納入的內容一樣重要。下表列出這個工具刻意省略的標記類別，每一項在 Lizely 上各自有專屬的產生器或工作流程。
| 被排除的標籤 | 它為何不在這個區塊中 |
|---|---|
| rel="canonical" | 每個頁面只有一個 canonical URL，屬於獨立的頁面決策 |
| meta name="robots" | 索引指示屬於頁面特有的決策 |
| Open Graph 屬性 | 社群分享詞彙使用的是另一套獨立標準 |
| Twitter Card 標籤 | 屬於平台特有的分享格式，並非基本 head 中繼資料的一部分 |
| JSON-LD 結構化資料 | 使用其獨立的 script 元素，與 name 與 http-equiv 類型的 meta 標籤分開 |
Meta Tag Generator 同時也不會在 viewport 中加入縮放限制，因為省略 maximum-scale 與 user-scalable 能讓依賴瀏覽器縮放功能的讀者保有可存取性。關於如何讓產生的標記保持可審核的配套工作流程，記錄於這篇關於在不含 SEO 冗餘的情況下組合標籤區塊的逐步說明中。
驗證已部署的原始碼與 HTTP 標頭
產生正確的語法是工作的一半。另一半則是確認訪客實際接收到的內容，與你所產生的區塊一致。以下三項檢查能抓出大多數的部署錯誤。
首先，檢視上線頁面的原始 HTML，並計算 title 與 description 元素的數量。兩者應該各自恰好只有一個。如果主題或 SEO 外掛加入了重複的版本，請停用該外掛的中繼資料功能，或為這個頁面移除其輸出，以確保實際部署的是產生器所產生的那幾行。
其次，在 HTTP 層確認文件的字元編碼。產生器會將 UTF-8 宣告放在 head 的最前面，但如果伺服器正在傳送一個相衝突的 Content-Type 標頭(例如 text/html; charset=ISO-8859-1)，瀏覽器將會採用標頭的設定。兩者必須一致。
第三，以行動裝置的寬度檢視頁面，並確認其能正確縮放。固定的 viewport 值會跟隨裝置寬度，但不會停用使用者縮放;然而實際的響應式行為仍然取決於 CSS、媒體查詢與元件佈局。Meta Tag Generator 並不會衡量點擊率、關鍵字品質、像素寬度或搜尋需求;這些屬於內容與產品的問題，而非語法驗證的範疇。一旦部署的原始碼是乾淨的，就可以在重新檢索後，使用相關的 search-console 檢查工具，來查看搜尋系統實際選擇顯示的內容。
延伸閱讀:Meta Robots Generator Explained: From Toggles to Deployed Tags。