網站的 meta 標籤產生器會建立一個跳脫過的 HTML head 區塊，包含五個基礎元素:UTF-8 字元集、響應式 viewport、標題、描述，以及選用的作者中繼資料。Meta Tag Generator 是為了一個刻意精簡的工作而設計:輸入準確的頁面事實、產生基本區塊、將其放入文件 head 中，並稽核輸出的原始碼是否有重複或衝突。標準連結、robots 指令、Open Graph 屬性以及 Twitter Cards 表達的是各自獨立的頁面層級決策，因此它們不會包含在此區塊內。這種區隔讓輸出更容易檢視，並有助於避免互相矛盾的指示被一起複製貼上。處理過程都在瀏覽器中完成，輸入的文字不會傳送到 Lizely。產出結果僅是基礎語法，並非對索引、排名、行動版佈局或搜尋引擎摘要的保證。這個工作流程適合想要一個精簡、可稽核的基礎架構，而不是一堆混雜的選用指令的開發人員、編輯人員與網站擁有者。它讓中繼資料的建立與最終部署檢查保持分開。
產生的 head 區塊包含什麼
輸出內容刻意精簡，僅整合可以一起檢視的基本文件決策。它會準備每個文字值以符合其 HTML 上下文，同時將專業的 SEO 與社群中繼資料留給其他工具處理。
| 產生的元素 | 定義的輸出 |
|---|---|
| UTF-8 字元集 | 宣告文件編碼，並出現在文字中繼資料之前。 |
| 響應式 viewport | 使用固定的 width=device-width 與 initial-scale=1 基準，且不加入縮放限制。 |
| 文件標題 | 以一個跳脫過的 title 元素輸出必要的文件標題。 |
| 頁面描述 | 以跳脫過的 description 中繼資料輸出必要的頁面摘要。 |
| 作者 | 僅在有填寫選用的 author 欄位時，才加入跳脫過的作者中繼資料。 |
固定的順序讓複製的區塊易於稽核。UTF-8 宣告也必須出現在實際文件 head 的前段，而伺服器回應不應宣告衝突的編碼。產生的區塊無法檢查 HTTP 標頭、範本佈局，或在 CMS 插入後的最終位元位置。
準備準確的頁面輸入
從訪客實際在頁面上看到的內容開始。標題應該準確標示該文件，而描述則應總結其獨特用途，不要放關鍵字清單、無法兌現的承諾，或從不相關頁面複製貼上的措辭。
| 欄位 | 必要性 | 字元上限 | 撰寫目標 |
|---|---|---|---|
| Title | 必填 | 200 | 提供一個準確的文件標題或名稱。 |
| Description | 必填 | 500 | 撰寫簡潔、人類可讀的頁面摘要。 |
| Author | 選用 | 120 | 使用網站有在維護的具意義作者名稱。 |
每個送出的文字值都會被去頭尾空白。「&」與角括號會被編碼，引號在可能影響屬性的地方會被編碼，控制字元會被拒絕。必填欄位不能留空。字元上限是用來限制輸出的長度，並不是建議的排名長度，也不是對標題或描述在搜尋結果中顯示方式的承諾。
產生並安裝基本的 head 區塊
- 輸入頁面事實。 新增一個準確的文件標題和一段簡潔的頁面描述。僅在網站有在維護一個具意義的作者值時，才填寫選用的作者欄位。請確認文字描述的是目的地頁面，而不是某個分類、範本或搜尋查詢。
- 產生並複製乾淨的區塊。 建立輸出並在其行格式未被打亂時複製這個跳脫過的基本 head 區塊。不要為了讓區塊看起來更完整而附加 canonical、robots、Open Graph 或 Twitter Card 標記。
- 將其放入 head 中並驗證。 將產生的數行插入文件 head 中。儲存後檢查實際送出的頁面原始碼，然後移除由佈景主題、外掛、框架或部署平台所引入的重複或衝突的中繼資料。
請將產生的數行放入單一個 HTML head 中，而不是把它們當成可見的 body 文字貼上。避免使用會對標記再做第二次跳脫的編輯器或欄位，因為瀏覽器將會收到像角括號這樣的字元，而不是有效的元素。當發佈系統有提供原始碼層級或專屬的 head 欄位時，請使用它。
將專業的中繼資料分開處理
標準化網址、robots 指令、Open Graph 屬性或 Twitter Card 所回答的問題，與文件標題和頁面描述是不同的。標準化與 robots 的選擇應屬於專屬的產生工作流程，因為它們表達的是各自的頁面決策。社群屬性同樣需要為其特定的分享情境審核過的值。把這些詞彙排除在基本產生器之外是一種設計選擇，目的是讓複製的區塊保持精簡且易於檢視;這並不代表這些決策在任何情況下都是不必要的。
檢查送出原始碼中的衝突
請檢視原始的公開原始碼，而不是只依賴 CMS 編輯器內看到的內容。確認該文件包含一個 title 元素，且沒有重複的 description 中繼資料。檢查是否佈景主題、外掛、框架或平台插入了另一個不同措辭的版本。移除衝突的版本，讓該頁面擁有一組明確的基本中繼資料。
也要驗證實際 head 中的字元編碼宣告，並檢查 HTTP 回應標頭是否有衝突的宣告。產生器無法為你執行這兩項檢查。它跳脫過的輸出是一個正確的起點語法，並不能證明 CMS 已將該段程式碼放在正確的位置，也不能證明伺服器送出了預期的編碼。
了解標題、描述和作者的作用
WHATWG HTML 語意 將 title 元素描述為代表文件的標題或名稱。瀏覽器可以在分頁、書籤和其他介面介面中顯示它，而搜尋系統在建立結果標題時可能會將它當作其中一個輸入。Google 的標題連結指南也反映出標題連結可以由頁面標題和其他頁面訊號組成。因此，所產生的標題並非對搜尋系統會顯示完全相同文字的承諾。
描述中繼資料為相容的消費者提供簡短的摘要。搜尋引擎可以在它有助於描述結果時使用它，但也可以改為選擇頁面上其他可見的文字。請讓摘要保持準確且獨特，避免在不相關的頁面之間重複使用，也不要描述目的地頁面無法達成的結果。
選用的 author 欄位僅用於描述作者身分中繼資料。它並非已驗證的身分、版權聲明的替代品、rel=author 關係的替代品，也不是結構化資料。當網站沒有具意義的值可維護時，請將其省略。文章、人物與組織也可能需要準確的可見署名以及適當的結構化資料。
驗證響應式與部署後的行為
產生的 viewport 使用 width=device-width 與 initial-scale=1。它不會加入 maximum-scale 或 user-scalable 限制，因為縮放限制可能損害無障礙性。響應式行為仍然取決於 CSS、媒體查詢與可用的元件佈局，因此請在發佈後以行動版寬度測試該頁面。
為了做最終驗證，請檢查原始的公開原始碼與 HTTP 標頭、以行動版 viewport 檢視頁面，並在重新抓取後使用相關的搜尋控制台檢查工具。一個乾淨的原始碼區塊能支援中繼資料的正確交付，但無法保證索引、排名、某個特定結果標題或某個特定的搜尋摘要。
讓產生過程與 SEO 判斷分開
這個產生器不會測量關鍵字品質、像素寬度、點擊率或搜尋需求。這些問題取決於內容、產品、受眾與搜尋情境，而非語法驗證。它也不會擷取即時頁面、更新 CMS、檢查回應標頭，或發佈變更。
請用它來建立一致且可稽核的基本 head 區塊。然後將專業的中繼資料決策分開處理，將每個說明與實際送出的頁面進行比對，並在將中繼資料視為完整之前驗證最終的原始碼。
如果你正在權衡選項，Robots.txt Generator: Build the File Locally in Your Browser 有詳細說明。