Headless CMS 初學者指南
已發表: 2022-02-01無頭 CMS（內容管理系統）刪除了內容數據庫後端與用戶訪問您的網站或應用程序時向用戶提供內容的方式之間的直接鏈接。
這與傳統的“耦合”CMS 相比，其中數據庫和內容的呈現都由同一個CMS 控制。
雖然耦合 CMS 有其優勢——例如編輯數據庫及其在屏幕上顯示方式的單一界面——但無頭 CMS 更強大、更靈活。
對於較大的網站、複雜的數據庫或當多人需要處理您的內容、網站/應用程序和現場 SEO 的不同方面時尤其如此。
什麼是無頭 CMS？
在傳統的 CMS 中，後端內容數據庫和前端網站設計可以在同一個 CMS 儀表板中進行編輯，這就是為什麼這些系統被稱為“耦合”的原因。
無頭 CMS 系統為數據庫和交付使用單獨的系統，API（應用程序編程接口）充當兩者之間的橋樑。
一些最常用的無頭 CMS 包括 Ghost、Prismic、Netlify 和 Contentful，與耦合 CMS 一樣，它們旨在高效運行、提供靈活的功能並在您的數據庫開始增長時快速擴展。
由於復雜性更高，無頭 CMS 可能更昂貴，但它提供了耦合系統無法提供的功能，例如以完全不同的方式為從不同設備訪問您網站的訪問者提供內容的能力。
這反過來又對響應式網站設計等搜索引擎優化 (SEO) 技術產生了一些積極影響，因為您的內容可以以響應更快、平台相關且真正適合移動設備的方式提供。
無頭 CMS 的更多好處
讓我們看一下無頭 CMS 的一些具體好處，這些好處有助於推動這種方法在全球網站上的大規模普及和快速採用：
定制內容
更密切地控制您的內容及其顯示方式意味著您可以在更大程度上自定義您的頁面。 無論您是針對特定用戶組還是針對整個受眾執行此操作，這都為您提供了更多在競爭對手中脫穎而出的方法。
加載速度更快
使用適合設備的 API 和前端可優化不同設備上的加載速度，包括通過移動數據連接訪問您網站的設備。 這也支持您在 SEO 活動中採取的任何行動，以提高您的 Core Web Vitals 性能。
面向未來的靈活性
安裝額外 API 的能力意味著您的數據庫將來可以連接到新的前端。 這可以讓您實現多樣化，例如，從面向桌面和移動訪問者的網站，到提供店內信息屏幕和可穿戴技術。
總之，當您有復雜的前端需求時，無頭 CMS 是理想的選擇，但您希望簡化實際內容的編輯和維護——編輯和更新會立即反映在所有不同的平台上。
如何規劃無頭 CMS
內容建模是實施新的無頭 CMS 之前的關鍵規劃階段。 它類似於您規劃網站的文件夾層次結構、URL 結構和站點地圖的方式，除了在這種情況下您將使用內容類型，而不是單個頁面。
什麼是內容類型？
您定義的各種內容類型包含從數據庫中提取信息的字段。 這可能是 SEO 元數據——如果您使用傳統的耦合 CMS 和 Yoast 等 SEO 插件，您可能已經看過並填寫過元數據字段。
在您的主要內容頁面上，您可能有用於 URL slug 的字段，以及要在頁面上呈現的一個或多個可見內容部分。
您還可以定義媒體資產的內容類型，為您的文件命名、只能在內部看到的描述以及可以訪問文件的位置。
內容類型如何工作？
一旦您定義了所有必需的內容類型，您就構建了一個模塊化的“構建塊”方法，API 可以通過該方法從您的數據庫中提取信息並將其放在一起以用於不同的平台。
API 可以從不同的內容類型請求數據，並以完全獨特的方式構建數據，從而以特定於平台的方式呈現頁面。
如果您將來需要進行更改，例如添加新的 SEO 元標記，您可以更新內容類型以在數據庫中的每個相關項目中創建必要的字段。
如何定義 SEO 要求
在深入開發之前定義無頭 CMS 的 SEO 要求是一種很好的做法，以便您的開發人員知道他們需要實現什麼。
需要考慮的一些要素包括：
- URL slug（可以按頁面添加關鍵字）
- 元數據（例如“標題”、“描述”和“關鍵字”標籤）
- 規範標籤（防止重複內容處罰）
- 元機器人標籤（防止不必要的頁面抓取）
您還可以為一些更現代的方法和特定於服務的驗證創建字段，以幫助支持您的 SEO：
- 微數據、微格式和 Schema.org 標記
- Google Analytics、Search Console 和 Bing 網站管理員工具的驗證標籤
- 社交媒體預覽的標記（例如 Twitter 卡片）
同樣，這些都會影響您的內容如何被發現以及它在不同平台上的顯示方式——在這種情況下，第三方網站和應用程序——因此包括這些字段可以幫助您控制人們如何看待您的內容，無論他們在哪裡找到它。
我需要多少種內容類型？
決定使用多少內容類型是切換到無頭 CMS 的大問題之一，答案是這取決於您要實現的目標。
為了獲得最佳 SEO 性能，您應該定義涵蓋每個單獨參數的字段。 例如，您可能有一個用於 robots follow/nofollow 元標記的字段，以及一個用於 robots index/noindex 的單獨字段。
限制和要求
像 Contentful 這樣的無頭 CMS 還允許您對字段設置字符數限制，因此您可以將標題標籤和其他元數據保留在一定數量的字符內。
最後，您可以將字段設為必填且唯一——因此，如果元數據從另一個頁面複製或完全丟失，編輯器將收到錯誤消息並進行必要的更正。
無論您是使用單個內容類型中的多個字段來執行此操作，還是使用單獨的內容類型以在呈現方面獲得更大的靈活性，部分取決於您需要數據支持哪些功能，部分取決於個人偏好。
把它放在一起
你可以把它想像成建造一個許願井。 磚塊越大，施工就越快、越容易。 但磚越小，圓形就越完美。
內容類型的“正確數量”應該是最適合您的折衷方案，這樣您就可以構建您想要的網站，而不會覺得您正在單獨編輯每個段落、標題和元標記。
前端呢？
正如流行使用的幾種常見的無頭 CMS 後端一樣，也有一些很棒的前端框架可供選擇。
最好的兩個是 React 和 Vue，這些現代框架再次被設計為高效工作、快速加載內容並為您的網站訪問者提供最佳用戶體驗。
記住要考慮技術因素。 例如，預渲染您的內容可以確保它對搜索引擎爬蟲完全可見，如果在客戶端使用 JavaScript 渲染它可能無法“看到”內容。
最後的考慮
實施無頭 CMS 後，請確保由知名的 Web 開發人員，尤其是 SEO 專家對其進行適當的審核，以確保您沒有錯過可能影響搜索排名的技術性問題。
一個在 API 中很常見的例子是動態 URL 的擴散，例如電子商務類別、產品的不同尺寸和顏色以及結果的分頁。
通過使搜索引擎機器人可以看到所有這些 URL，您可能會在他們在您的網站上找到更有價值的靜態 URL 內容之前消耗他們的抓取預算。
[案例研究] 管理 Google 的機器人抓取
閱讀案例研究鼓勵您的開發人員在可能的情況下實施靜態 URL，並使用在無頭 CMS 中實施的機器人元標記來阻止爬蟲訪問不需要的動態頁面。
展望未來
通過考慮以上所有因素，您可以創建複雜而全面的網站數據庫，這些數據庫可以通過物聯網。
未來的開發工作可以在您發布數據的許多不同設備和平台上產生即時更新，從而從您的 SEO 和內容活動中獲得更快、更積極的投資回報。
就像 2000 年代早期級聯樣式表 (CSS) 帶來的內容和設計分離一樣，無頭 CMS 為您提供了一種更精細的方式來定義、編輯和呈現您的內容——幫助您實現 SEO 和電子商務目標在未來數月和數年內構建數據庫時，這是一種更易於管理的方式。