IKENSA暫定名 · 開發預覽

CMS 選型與 SEO 能力

能不能改 title/canonical/schema 是底線

f07檢核 人工基礎建置在互動地圖中開啟 →

CMS 像廚房設備——菜單(內容)再好,廚房不能調火候(title、canonical、schema),大廚也做不出該有的味道。

03為什麼是現在學

選型是一次性的,但它決定之後每一項 SEO 工作「做得到/做不到」。健檢案遇到做不到的 CMS,報告再漂亮都只能寫「建議搬家」。

04白話理解(對客戶簡報可直接引用)

不管用 WordPress、自建系統還是 SaaS 建站平台,底線清單是固定的:每頁能自訂 title 與 meta description、能設 canonical、能放結構化資料、能控制 noindex、網址能自訂、圖片能寫 alt、能生成 sitemap。任何一項做不到,就是先天缺陷——之後所有優化都會卡在這裡。

05工具箱

  • CMS SEO 能力檢查表(上列八項) — 選型會議直接逐項打勾
  • 各平台官方文件 — 「能不能」以文件與實測為準,不聽業務說

06怎麼做 · SOP 3 步(每步標產出物)

  1. 1用八項底線清單逐項實測候選 CMS選型評估表
  2. 2確認內容匯出能力(哪天要搬家,資料帶不帶得走)資料可攜性評估
  3. 3決策與理由書面化選型決策紀錄(ADR)

07場景應用(實戰經驗)

  • 常見踩雷:某些拖拉式建站平台 title 綁死頁名、schema 不能自訂——內容再好都拿不到複合式搜尋結果。

08⚠️ 常見誤區

  • 用「後台好不好看」選 CMS,忘了問「搜尋引擎看到什麼」。
  • 被平台鎖死:內容匯不出來,搬家等於重寫。
口訣

八項底線先打勾,再談好不好用。

10里程碑 · 完成標準(可驗證)

  • 八項底線全數通過實測
  • 資料匯出方式確認
  • 選型決策有書面紀錄

學習者勾自己的進度;顧問勾客戶專案的交付——同一份標準,兩種用法。

12檢核方式與依據出處

人工判定:需要顧問訪談與專業審閱——這一段是顧問收費的理由。

依據等級決定計分權重(🟢×3/🔵×2/⚠️×1)——權重量的是「依據有多硬」, 不是「我們覺得多重要」。查無權威文件的判準,誠實標「業界慣例」。

← 上一節點
正式/測試環境隔離
下一節點 →
robots.txt 規則