為您的網站建立中繼標籤，代表要產生一組精簡、語法正確的 HTML head 標籤——一個 UTF-8 字元編碼宣告、一個響應式視口標籤、一個 title 元素、一個 description 中繼標籤，以及一個選擇性的作者名稱——用來向瀏覽器、輔助工具和爬蟲描述這份文件。最低必要的元素只有三個：字元集宣告、視口中繼標籤和 title。description 和 author 欄位只有在有實質、正確的內容可發布時才會加入。這些標籤存在於 HTML head 元素內部，位於任何可見的 body 內容之上，並且會在每次載入頁面時被讀取。它們刻意與 canonical 連結、robots 指令、Open Graph 屬性和 Twitter Cards 分開，因為後者承載的是索引與社群分享決策，需要各自獨立的區塊。一個乾淨、已跳脫處理過的基本 head 區塊，是任何網站正確的起點，而且應該在任何專門標籤疊加上來之前，就先撰寫、稽核並插入。
屬於基本 head 區塊的五個標籤
一個全新網站的最小 head 區塊由五個元素組成，WHATWG HTML 標準將它們全部定義為文件層級的中繼資料。第一個是字元編碼宣告，寫成 <meta charset="utf-8">，告訴瀏覽器如何解讀之後的每個位元組。UTF-8 涵蓋完整的 Unicode 範圍，是大多數現代網站唯一應該發布的編碼。第二個是響應式視口標籤，寫成 <meta name="viewport" content="width=device-width, initial-scale=1">，讓排版視口跟隨裝置寬度，同時不禁用使用者縮放。移除或修改這個標籤，是頁面在手機上呈現錯誤最常見的原因之一。
第三個是 <title> 元素，依據 WHATWG HTML 語義規格，它代表文件的標題或名稱。瀏覽器會在分頁、書籤、歷史紀錄及其他介面顯示它。搜尋系統在建構結果連結時，也可能將它當作一項輸入，但也可能自由選用其他可見文字。第四個是 description 中繼標籤，寫成 <meta name="description" content="...">，為想要摘要的消費者提供頁面的簡短說明。第五個是選擇性的 author 中繼標籤，寫成 <meta name="author" content="...">，只有在網站維護一個有意義的作者名稱可發布時，才會描述作者中繼資料。
這五個元素共享一個重要特性：它們描述的都是文件本身，而非其索引政策、社群分享外觀或標準網址。這個區別正是基本區塊在任何特定標籤加入之前，能成為合理基礎的原因。
為什麼保持區塊精簡是較安全的預設做法
許多線上的中繼標籤產生器會在一份冗長的表單中，要求填寫 canonical 網址、robots 指令、Open Graph 屬性、Twitter Card 欄位以及其他十幾項輸入。這看似周全，卻助長了一種特定的失敗模式：同一個頁面不可能只靠一個下拉選單，就同時決定 canonical 網址、robots 規則和社群描述。每一項都是獨立的頁面層級決策，需要各自的工具。當所有詞彙被混進同一個區塊時，很容易複製到互相矛盾或不相關的標記，也讓逐行稽核結果變得更困難。
只產生這五個基礎標籤的工具，是刻意保持範圍精簡的。中繼標籤產生器只處理可以一起檢閱的基本文件中繼資料：字元集、視口、title、description 和選擇性的 author。canonical 連結、robots 中繼標籤、Open Graph 屬性和 Twitter Cards 各自表達獨立的頁面決策，因此被刻意排除，並各自有專屬的工具。先透過一個精簡、瀏覽器端的產生器跑過 title 和 description，就能得到一個可稽核的起始區塊，而同一套極簡邏輯也是取得不含 SEO 膨脹的中繼標籤區塊指南的基礎。在確認基礎層無誤之後，再透過各自的產生器加入專門的標籤。
處理過程也完全留在您的瀏覽器內。這套工具不會將 title、description 或 author 傳送到任何伺服器，這在這些中繼資料包含草稿文案、內部產品名稱或尚未發布的資訊時尤為重要。您可以先在本機反覆調整，再將結果貼入您的 CMS，而這些中繼資料要等到那時之後，才會進入公開網路上的任何地方。
如何為您的網站建立基本的中繼標籤
透過中繼標籤產生器產生一份乾淨的基本 head 區塊，所需步驟簡短且易於檢閱。它們直接對應到這套工具被設計的使用方式。
- 輸入一個正確的文件 title、一段簡潔的頁面 description，以及一個選擇性、由您維護的作者名稱。以與可見頁面標題一致的人類語氣撰寫 title，而不是一串關鍵字。description 應在兩到三個句子內，讓此頁面與同類頁面有所區別，並避免關鍵字列表、在不相關頁面間重複使用相同 description，或做出頁面無法兌現的承諾。除非您為這份文件維護一個有意義的署名欄位，否則請將 author 欄位留空，因為一個虛構或過時的作者名稱只會增加雜訊，不會帶來價值。
- 產生並複製已跳脫處理過的基本 head 區塊，不要額外加入重複的特定中繼資料。產生器會修剪每個值、強制套用長度限制、拒絕控制字元，並依據正確的 HTML context 跳脫「&」、角括號和屬性引號。複製下來的區塊正好包含五行：UTF-8 宣告、視口標籤、title 元素、description 中繼標籤，以及在有提供時的 author 中繼標籤。
- 將它插入文件 head 中，檢查實際送出的原始碼，並移除由佈景主題、外掛或框架所加入的衝突內容。將此區塊放在 head 元素的較高位置，緊接在 CMS 要求的任何結構性標籤之後。發布後檢視頁面原始碼，確認只有一個 <title> 元素，且只有一個 description 中繼標籤。如果佈景主題、外掛、SEO 外掛或部署平台已插入重複的版本，請移除較舊的那一個。
以上就是基本區塊的完整工作流程。您需要的任何 canonical、robots、Open Graph 或 Twitter Card 標籤，之後都會透過該詞彙專屬的工具另行加入。
中繼標籤產生器處理了哪些內容，又省略了哪些
| 標籤 | 在基本區塊中的狀態 | 原因 |
|---|---|---|
| UTF-8 字元集 | 包含 | 定義瀏覽器如何讀取隨後的每個位元組。 |
| 響應式視口 | 包含（固定值） | 在不禁用縮放的情況下匹配裝置寬度。 |
| 文件 title | 包含 | HTML 標準要求；顯示於分頁，並作為一項搜尋輸入。 |
| 頁面 description | 包含 | 規格中為選擇性，但通常作為頁面摘要使用。 |
| Author 中繼資料 | 選擇性 | 只有在提供正確、由您維護的值時才會包含。 |
| Canonical 連結 | 省略 | 承載獨立的索引決策；有其專屬的產生器。 |
| Robots 中繼標籤 | 省略 | 結合索引與摘要控制項；有其專屬的產生器。 |
| Open Graph 屬性 | 省略 | 驅動社群分享外觀；有其專屬的產生器。 |
| Twitter Card 標籤 | 省略 | 驅動 X／Twitter 分享外觀；由社群標籤工具涵蓋。 |
有兩項長度限制規範產生器接受的內容。任何超過上限的值會在區塊產生之前就被拒絕，因此不會有過長的 title 或 description 通過審核。
| 欄位 | 最大長度 | 是否必填 |
|---|---|---|
| Title | 200 個字元 | 是 |
| Description | 500 個字元 | 是 |
| Author | 120 個字元 | 否 |
這些上限的存在是為了將輸出控制在合理範圍內，並非排名目標。實際用於搜索結果片段的 title 與 description 長度通常遠低於這些上限，且搜尋引擎在顯示前可能會改寫其中任一個值。Google 標題連結說明文件說明了搜尋系統如何根據查詢內容及頁面本身，替換、縮寫或省略您的 title。
部署區塊並移除 CMS 中的重複項目
取得基本區塊後，請將它貼入頁面的 <head> 元素中，靠近頂端的位置。區塊中的每個文字值都已依其 HTML context 完成跳脫處理，因此您無需再次編輯「&」、角括號或引號字元。請勿將這些行當作可見的 body 文字貼上，也不要貼到會對標記進行二次跳脫處理的編輯器中——任一作法都會破壞輸出。
下一步是衝突偵測，這也是大多數團隊會略過的部分。在瀏覽器中開啟線上頁面的渲染後原始碼，搜尋 <title> 並確認正好只有一個符合項。搜尋 name="description" 並確認正好只有一個符合項。如果您的 CMS、佈景主題或 SEO 外掛已經插入了 title 或 description，新區塊會與舊的並存，而搜尋系統可能會隨機選用其中之一。請移除較舊的項目——通常是透過編輯佈景主題的 header 模板，或停用衝突的外掛——只保留產生器的輸出。
有兩個特定的陷阱值得留意。第一，某些部署平台會在佈景主題中預先加上全域 title 後綴，導致產生重複而非取代。請停用該後綴，或改寫模板，讓您產生的 title 成為唯一來源。第二，部分 SEO 外掛會儲存一組預設 description，只要個別頁面的 description 為空就會啟用，因此先前空白的欄位在您儲存後可能突然出現值。每次外掛更新後，請重新檢查原始碼。
Verifying your published metadata after launch
The generator produces valid syntax, not a ranking outcome. Once the block is deployed, three post-launch checks confirm that the metadata is reaching the public page the way you intended.
- Inspect the raw source. View the page source from a fresh browser session, not from a logged-in preview, and read the head element line by line. The UTF-8 declaration must appear before any textual content, the viewport tag must use the fixed responsive value, and the title and description must each appear exactly once.
- Check the HTTP response. Use your browser's developer tools, curl, or a header-inspection service to confirm that the server does not declare a conflicting character encoding in its Content-Type header. A conflicting header will override the meta charset and is invisible from the source alone.
- View the page at mobile width. Resize the browser to a phone width or open the page on an actual phone. Confirm that the layout responds to the device width and that user zoom is not disabled. The generator does not add maximum-scale or user-scalable restrictions because those can harm accessibility, so the published viewport should still allow pinch-to-zoom.
After the page has been recrawled, run the URL through your search engine's inspection tools to see which title and description the crawler actually indexed. Those tools sometimes surface a snippet that does not match your source, which is a useful signal that the search engine has chosen to rewrite your metadata based on the visible page content. When that happens, the fix is almost always to align the visible content with the metadata, not to edit the head block again.
If you're weighing options, Extract Sitemap From URL: A Paste-and-Parse Workflow covers this in detail.