元伸科技
「網站做完之後，我能改什麼？」——這是客戶在 客製化網頁設計 簽約前最常問也最關鍵的問題之一。CMS 權限開得太緊，客戶連改個首頁文案都要找開發商；開得太寬，客戶誤改一個 padding 整個版面跑掉，再回頭找開發商「修 bug」並爭執保固範圍。權限的設計是一門平衡藝術——太鬆與太緊都會引發後續糾紛。本文拆解 5 個權限層級的取捨原則，幫你在簽約前就跟開發商把這件事談清楚。
5 個權限層級的範圍與風險
層級 1：檢視層（View）— 風險：無
只能讀取資料、不能改。包含：訂單列表、表單詢價、流量數據、會員列表、報表 dashboard。這是任何角色都該有的最低權限。誰需要：業務主管看訂單、行銷看流量、財務看金額——他們不需改資料，只要看得到。
層級 2：內容層（Content）— 風險：低
修改網站可見的「文字與圖片」，不動結構或版面。包含：文章發佈與編輯、產品上下架、首頁 banner 圖片更新、最新消息、表單內容調整。這是多數中小企業客戶真正需要的權限——日常營運的更新都在這層。
層級 2 的好處：誤改風險低（最壞情況是「文案不通順」，刷新就能改回來）、不影響 SEO 結構（meta 與 URL 結構保留設計階段的配置）、不會破壞版面（按鈕、卡片、版型都被鎖住）。建站時應該為層級 2 設計直覺的編輯介面，例如所見即所得（WYSIWYG）但限制只能用預設樣式，不開放自由 CSS。
層級 3：結構層（Structure）— 風險：中
新增頁面、調整選單順序、改 URL slug、設定 meta title / description、SEO 關鍵字、Schema 欄位填寫。這層開不開要看客戶是否有專責人員：
- ✅ 適合開：客戶有行銷或內容專員，理解 SEO 概念
- ❌ 不適合開：客戶只有助理或老闆兼著管後台
層級 3 的常見災難：URL slug 改完忘記設 301 redirect，舊 URL 直接 404，Google 排名暴跌；新增頁面忘記填 meta description，Google 自動抓的描述很怪；選單順序改完手機版選單壞掉。建議在 CMS 中內建警告與限制（例如改 URL slug 時自動產生 301、強制填 meta description、選單調整後跳出「請檢查手機版」提醒）。
層級 4：版面層（Layout）— 風險：高
改顏色、字型、版型結構、區塊順序、可見區塊（如「首頁要不要有輪播圖」）。這層多數中小企業不該直接擁有，因為視覺設計是專業領域，輕微改動可能讓整站視覺一致性崩潰。
例外狀況：
- 客戶有專業設計師
- 開放有限的「主題色切換」「字型切換」（從預設選項中選，而非自由輸入）
- 用「區塊開關」而非「區塊編輯」（可隱藏 / 顯示首頁某區塊，但不能改設計）
如果客戶堅持要層級 4，標準做法：提供 staging 環境讓客戶實驗，由開發商審核後才同步到 production。這個流程能擋住 95% 的版面災難。
層級 5：技術層（Tech）— 風險：極高
直接改 CSS、HTML、JavaScript、Schema JSON、robots.txt、伺服器配置。99% 的客戶不該擁有這層權限——這層的誤改可能讓網站當機、被搜尋引擎降權、產生資安漏洞、或 XSS 風險。
唯一適合的客戶：內部有前端工程師團隊，且開發商願意提供 git 或版本控制流程。其他情況一律建議：客戶想動技術層，提需求 ticket 給開發商，由開發商執行（這也是維運合約的合理範圍）。
開放過多 vs 過少的雙向風險
| 問題 | 過度開放（層級 4-5 都給） | 過度限制（只給層級 1） |
|---|---|---|
| 客戶體感 | 「網站好複雜，不敢動」 | 「改個文案都要等開發商，太麻煩」 |
| 上線後 1 個月 | 客戶亂改一通，產生 bug | 客戶完全不更新，網站變死網站 |
| 上線後 6 個月 | 開發商被叫去修「客戶自己改壞」 | 開發商接到一堆「幫忙改個字」小單 |
| 保固爭議 | 「這是客戶改壞的不是我們的 bug」 | 「為什麼這個不能自己改？要再付費？」 |
| 推薦做法 | 用 staging 隔離 + 教育訓練 | 至少開到層級 2，必要時部分層級 3 |
最佳平衡點通常落在「層級 1 全開、層級 2 全開、層級 3 部分開（指定欄位）、層級 4 用主題切換代替、層級 5 不開」。這也是元伸科技 企業形象網站方案 的標配權限結構。
角色 × 權限矩陣（中小企業推薦版）
| 角色 | 層級 1 檢視 | 層級 2 內容 | 層級 3 結構 | 層級 4 版面 | 層級 5 技術 |
|---|---|---|---|---|---|
| Admin（老闆 / IT 主管） | ✅ | ✅ | ✅（含警告） | ⚠️（限主題切換） | ❌ |
| Editor（行銷 / 編輯） | ✅ | ✅ | 部分（不含 URL） | ❌ | ❌ |
| Viewer（業務 / 主管） | ✅ | ❌ | ❌ | ❌ | ❌ |
| Developer（外包 / 內部） | ✅ | ✅ | ✅ | ✅ | ✅（git workflow） |
這個矩陣的核心邏輯：權力與責任綁定——能改什麼，就要對該層的後果負責。Editor 可以改文章，但 URL 改錯造成 SEO 問題不是 Editor 的責任（因為他沒被授權改 URL）。
延伸閱讀：CMS 比較指南 與 CMS 選擇指南 幫你選擇適合的 CMS 系統，Headless CMS 指南 介紹更彈性的後台架構選項。
建站時把權限矩陣寫進規格書
簽約前讓開發商提供「權限矩陣」作為規格書一部分，是避免上線後爭議的關鍵。一份完整的權限矩陣應該包含：
- 角色定義：每個角色的職責與適用對象
- 欄位級權限：每個資料表的每個欄位誰能讀 / 寫
- 動作級權限：刪除、發佈、審核、匯出各動作的權限
- 審計記錄：誰在什麼時間改了什麼（後續追責用）
- 緊急覆寫機制：admin 在哪些情況可以覆寫所有限制
把這些寫進 客製化網頁設計流程 的「資訊架構」階段就確認的規格中，後台開發階段就照著做，上線後的權限問題能減少 80%。
結語：CMS 權限是「責任分配」而非「技術設定」
CMS 權限的本質不是「給多少功能」，而是「誰對什麼後果負責」。權限太鬆，客戶誤改後責任歸屬模糊，雙方都受傷；權限太緊，客戶失去自主性，把開發商當「免費小編」濫用。
建站階段花 1-2 小時把權限矩陣討論清楚，未來 5 年可以省下無數封「為什麼這個不能改？」「這個改壞了你們要免費修嗎？」的 Email 與 LINE 訊息。元伸科技 24 年 客製化網頁設計 服務累積的經驗：清楚的權限矩陣 = 順暢的長期合作關係。如果你正在規劃網站，建議在需求訪談階段就主動提出「我們公司有幾個人會用後台、各自的職責是什麼」，讓開發商依此設計適合的權限結構。
