編輯型部落格或出版站點

編輯型網站正是 EmDash 發揮價值的場景：集合、分類法、可擴充性等 WordPress 風格能力都能保留，同時不必背負 PHP 託管與外掛氾濫。你依然擁有熟悉的編輯基礎能力，但前端是 Astro 原生、內容模型為強型別，並且在真正需要瀏覽器內編輯之前都可以維持靜態部署。

「做得好」是什麼樣

先定義你的出版站點真正需要的內容結構：文章、作者、分類、標籤，以及可選的系列或期號。把這些映射到 EmDash 的集合與分類法中，確保 URL、RSS 與站內連結都可預測。再搭配將版面與 MDX 分離的主題結構，讓作者專注內容本身、設計師專注頁面外觀。

落地步驟

1. 盤點現有技術棧。 從 WordPress（或目前 CMS）匯出一批示例文章，記錄必須保留的 URL 規則，並列出首日不能下線的整合項（留言、電子報、分析）。

2. 先上線靜態核心路徑。 優先交付流量最高的模板：首頁、文章頁、分類頁、標籤頁、作者頁。及早接好導覽與 RSS，讓訂閱者與搜尋引擎感知到連續性。

3. 分階段遷移。 先遷移常青內容，再遷移時效性較高的歸檔內容。對變更 URL 設定重新導向，並保留遷移紀錄，方便向利害關係人解釋排名或分析數據波動。

4. 只在解決明確問題時引入外掛。 例如，編輯團隊每天貼富媒體時再啟用 Embeds；需要不依賴第三方表單服務的名單收集時啟用 Forms；留言或投稿量成長後再啟用 AI Moderation。

5. 有規劃地升級執行環境。 當非技術編輯確實需要瀏覽器內工作流、受驗證媒體，或不需重建的即時更新時，再引入 Workers、D1、R2，而不是在上線第一週預設全開。

示例：每週發佈節奏

週一：在 Git 分支或既有審查流程完成大綱與初稿。週二：基於 MDX diff 進行同儕審查。週三：定稿圖片與嵌入內容。週四：安排建置並部署到 Cloudflare Pages。週五：在社群與分發渠道推廣。無論你長期維持檔案化流程，或後續導入 EmDash 完整後台，這套節奏都適用。

結果

你可以交付更快、更安全的發佈體系，並保有從靜態交付平滑走向完整 CMS 能力的清晰路徑，同時不必假設每個團隊第一天就需要資料庫。