正如我本週稍早的文章中所提到的，我們剛完成從 WordPress 遷移到 Jekyll。

我概述了幾個原因，但基本上歸結為偏好、速度以及輕鬆進行變更的能力。

像 Jekyll（或 Astro）這樣的框架並非適合所有人，儘管它們在 AI 普及、Markdown 成為 LLM 的通用語言以及整體趨向於無頭網站的總體環境中更有意義。

大家都知道 WordPress 有多麼不安全，儘管這在與信譽良好的主機合作的情況下在很大程度上得到了緩解。

最大的問題是速度。

作為一家平台公司，我們的行動非常迅速，我們總是覺得 WordPress 的限制很大，而且我們總是受制於是否有可用的 WP 開發人員。

但要為任何框架找到好的開發人員都很困難，尤其是 WordPress。

當你找到一個擅長 WordPress 開發的人時，這意味著他們幾乎擅長他們嘗試做的任何事情，所以讓他們從事 WordPress 工作感覺像是浪費人才。

這就像內建的腦力流失。

隨著 Claude Code 等編碼代理的出現，現在可以通過簡單地遷移到另一個平台來輕鬆繞過這個問題。

我們選擇 Jekyll 是出於我將在下一節討論的原因。

就在上週，Cloudflare 宣布推出一款新的 CMS 框架，他們稱之為 WordPress 的「精神繼承者」。

它基於 Astro，這是目前最受歡迎的靜態網站生成器（SSG）之一。

它看起來很棒，但我們想要一些我們有經驗且成熟的框架。

正如我在上一篇文章中提到的，我們的網站很久以前就運行在 Jekyll 上，所以我們對它很熟悉。

對於不熟悉的人來說：像 WordPress 這樣的 CMS 與 SSG 之間最大的區別在於後者通常沒有資料庫，甚至沒有應用程式伺服器。

你完全在 HTML 模板、包含文件、佈局文件、配置文件以及其他所有內容的 Markdown 中工作。

頁面上的元數據定義為 frontmatter，這是 Markdown 文件頂部 --- 分隔符之間的 YAML 數據。

所以，例如，這篇文章的 frontmatter 如下所示：

其他方面，這些文章只是純 Markdown。

我們將它們放在 _drafts 文件夾中，準備好發布時再將它們移到 _posts 文件夾中。

除了設計之外，花費時間最多的部分是正確遷移現有內容。

該網站本身有超過 15 年的博客文章，但坦白說，我們並不需要所有這些。

所以，我們使用了 DemandSphere 中的 GSC 工具來識別真正有價值的頁面，並利用索引數據來決定哪些頁面可以被排除索引——並在遷移過程中簡單刪除。

WordPress 有一個 XML 導出功能，你可以用它來導出所有內容，所以我們從那裡開始。

幸運的是，我能夠在很大程度上利用 Claude Code 來分析每個頁面的價值，並非常快速地過濾掉我們不需要的內容。

將精選圖片（以及一般圖片）正確遷移過來需要更多的調整，但這基本上也是一個導出和導入的過程。

Claude Code 基本上使我們能夠做我們多年來一直想做的事情。

我們團隊的每個人都非常忙碌，我們永遠沒有時間來妥善完成這次遷移。

聘請外部人員來完成這項工作也沒有意義。

我們大量利用了多次會話、CLAUDE.md 和許多其他 .md 文件來保持項目順利進行。

Claude Code 最有幫助的部分是構建了九個獨立的開發工具，它們直接存在於儲存庫中。

我們能夠利用自定義構建腳本，將這些開發工具保留在生產構建之外。

這篇文章的精選圖片顯示了開發工具儀表板的外觀。

其中大部分工具由專門用於生成所需輸出的單獨審核腳本管理。

例如，我們有一個 lighthouse.js 腳本、一個網站結構腳本等等。

這最初是最有用的工具之一，因為它是一個小型的、內建的 Screaming Frog 式工具。

我們可以輕鬆地發現不在 Sitemap 中的 URL、丟失的 / 重複的元數據等。

它還幫助我們發現屬於不同子文件夾的 URL。

任何有經驗的 SEO 人員都會告訴你，Lighthouse 的作用遠不止於頁面速度和網站性能。

我們進行了許多改進，並且還有更多工作要做。

網站生產環境完全是靜態的，這顯然有幫助。

這是我們將投入更多工作的項目之一，但它是一個很好的工具，可以幫助我們確保我們已經具備了基礎的 Schema 數據。

AEO 審核工具遠非全面，但幫助我們涵蓋了許多基礎知識。

Schema Details 工具幫助我們逐頁分析了在覆蓋範圍方面需要改進的地方。

我經常使用 Open Graph 預覽工具，因為它可以讓我們預覽頁面在社交媒體上分享時的外觀。

在工具中，你可以點擊每個頁面，它會彈出一個查看器，顯示它在 Facebook、LinkedIn、X 和 Slack 中的外觀。

我可以看到，在完成這篇文章後，我已經有一個頁面需要修復了。

遷移完成後，我添加了這個工具，因為我想了解網站的語義聚類。

我們使用 all-MiniLM-L6-v2 模型對整個網站進行了向量化，這是一個不錯的 384 維嵌入模型，完全在本地運行，來自 @xenova/transformers。

對於第一次運行來說，它已經足夠了。

嵌入還實現了更多子工具的創建。

首先是一個主題表。

這個還需要更多的調整和參數設置，但它為我們提供了所涵蓋的主要主題的良好概述。

我們還生成了一個內容相似性報告，以便我們可以返回並合併過於相似的內容，或者花時間使它們更具差異性，如果這有意義的話。

在我看來，語義核心概念是理解任何網站的關鍵之一，因為它與 LLM 和搜索引擎如何總體上理解你的網站有關。

內部鏈接審核，當你擁有網站的嵌入時，是你可以運行以幫助搜索引擎理解哪些主題和頁面最相關的最佳流程之一。

我從來不喜歡 WordPress 上可用的工具，所以我們很高興現在有了這個。

然而，我們在這裡還有很多優化工作要做。

Redirects 工具在確保我們沒有錯過任何重要內容方面非常有價值。

正如我們在其中每一個中都可以清楚看到的，在為網站做最後潤飾方面，我們的任務還遠未結束，但我們處於一個更好的位置來修復剩餘的問題，並確切地知道要關注什麼。

Jekyll 在構建時會生成一個 /search.json 文件。

它是一個 JSON 數組，包含標題、URL、內容（最多 400 個字符）、標籤、日期和類型索引在文件中的每個頁面和帖子。

搜索頁面獲取單個 JSON 文件，在瀏覽器中執行子字符串匹配。

它對元數據的每個元素進行評分（例如，標題 10 倍，標籤 5 倍等）並設置權重，並將返回的結果限制在 30 個。

這使我們能夠擁有完整的網站索引和搜索功能，而無需 Algolia、Elastic、Lunr.js 或服務器 API。

目前的統計數據是 398 個條目，在我們需要進行任何優化之前，這很容易擴展到 2,500-3,000 個頁面。

我們估計即使在 5,000 個頁面時，搜索延遲仍將保持在 3 毫秒以下，所以我們很長一段時間內都沒問題。

我們希望從第一天起每個頁面都有結構化數據。

網站上的每個頁面都有 JSON-LD Schema - 所有頁面都有 Organization 和 WebSite，除了主頁以外的所有頁面都有 BreadcrumbList，任何包含 FAQ 內容的頁面都有 FAQPage，博客文章有 BlogPosting，產品頁面有 SoftwareApplication。

FAQ Schema 是從 front matter 自動生成的。

我們將 faq_schema 塊添加到 YAML 中，模板會處理其餘部分。

無需手動編輯 JSON-LD。

這就是我們如何在不花費太多時間的情況下，在 128 個頁面上實現了 470 多個 FAQ 條目。

Canonical 標籤、Open Graph 元數據和 RSS feed 都使用 site.url，以便它們在不同環境中正確解析。

robots.txt 也具有環境感知功能 - Staging 阻止所有機器人，除了 Screaming Frog 和 Sitebulb，Production 允許所有機器人。

Sitemap 由 jekyll-sitemap 插件處理，該插件僅從構建輸出生成它。

無需手動維護。

我沒想到會花時間處理的一件事是內容安全策略（CSP）標頭。

每次部署時，都會出現新的問題：首先是 Cloudflare 自帶的分析信標被阻止，然後是 Google Ads 轉化跟踪，然後是國際 SEO 頁面上的 Leaflet 地圖庫。

在一切順利之前，我們經歷了大約六輪 CSP 更新。

我們在 Cloudflare Pages 上從同一個儲存庫運行兩個環境。

主分支是生產環境，任何其他分支都部署為預覽。

build.sh 腳本會檢查 CF_PAGES_BRANCH 環境變量並相應地設置 JEKYLL_ENV。

生產構建會移除 dev-tools 目錄並保留 sitemap。

Staging 構建會移除 sitemap 並添加 noindex 標頭。

DNS 轉移很直接，因為我們已經在 Cloudflare 中管理我們的 DNS。

將 www.demandsphere.com 添加為 Pages 項目的自定義域名，自動將 CNAME 從 Kinsta 更改為 Pages。

轉移後，我們運行了 Screaming Frog 爬取，發現了一些需要修復的問題。

我們還發現我們的 favicon 在 Google 搜索結果中沒有顯示。

兩個問題：根目錄的 /favicon.ico 返回 404，因為我們沒有將它複製到根目錄，我們的 PNG favicon 只有 32x32 像素。

Google 要求至少 48x48。

我們添加了一個 96x96 的 PNG、一個 48x48 的 PNG、一個 Web Manifest 和一個正確的多尺寸 ICO 在根目錄。

Google 的 favicon 緩存更新緩慢，但技術設置現在是正確的。

我們有大約 65 張超過 100KB 的圖片需要優化。

我們 288 篇遷移的博客文章中的大部分只有一個通用的「Blog」標籤，並且需要適當的分類。

總體而言，它運行良好，我們對這次遷移非常滿意。

我們現在能夠比以往任何時候都更快、更高質量地執行新的內容創意。