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