網站合約怎麼看？企業主簽約前必懂的 8 大條款與常見爭議

網站權利歸屬，不一定等於「誰出錢就是誰的」

網站建置涉及的權利歸屬，通常需要依據雙方的契約約定來判斷。如果合約中沒有明確約定，未來在網站修改、移轉維護、再次利用或終止合作時，雙方可能對權利範圍產生不同理解。與其假設「付錢就一定擁有全部權利」，不如在簽約時就把相關事項寫清楚。

一個網站，可能涉及不同類型的權利

• 視覺設計：版型設計、圖示、視覺元素等。
• 程式開發：前端程式、後端功能、資料庫架構等。
• 文字內容：若由客戶提供，通常由客戶保有權利；若由網站公司代為撰寫，建議於合約中約定使用方式。
• 第三方素材：圖庫照片、字型、外掛套件等，通常受各自授權條款限制。

「網站是誰的」這個問題，實務上很少只有單一答案，而是需要依照不同項目逐一確認。

合約中建議確認的三件事

一、雙方約定的是「權利移轉」還是「使用授權」？
有些網站專案會約定特定成果於付款完成後移轉給客戶；也有些專案採取授權模式，由網站公司保有既有技術與架構，客戶取得一定範圍內的使用權。兩種模式各有適用情境，重要的是雙方都清楚自己拿到的是什麼。建議在簽約前確認：哪些成果屬於客戶所有？哪些屬於網站公司的既有智慧財產？

二、授權範圍與使用條件是什麼？
若採授權模式，建議確認是否可以自行修改、是否可以委託第三方維護、是否有使用期限、以及合作終止後是否仍可持續使用。

三、第三方素材的授權責任如何分配？
若網站中使用商業圖庫、付費字型或第三方外掛，建議確認授權費用由哪一方負擔、授權範圍為何、以及合作終止後是否仍可繼續使用。

「交付網站」不等於「交付原始碼」

乙方「交付網站」的意思，通常是讓網站順利上線、可以正常運作。但原始碼是否一併提供給客戶，應以合約約定為準。如果合約裡沒有明確載明，雙方對於交付範圍的理解可能不同，建議在簽約前就確認清楚。原始碼的交付與否，影響的不只是技術問題，而是你未來對這個網站的處置空間：換廠商維護、自行修改功能、或進行改版，有原始碼和沒有原始碼的彈性差距很大。如果你是 WordPress 網站，可以參考WordPress vs 客製化網站：2026 年企業該怎麼選？了解兩者在原始碼掌控上的差異。

合約中建議確認的三件事

一、原始碼是否列為交付物？
建議確認交付的範圍：前端程式（HTML、CSS、JavaScript）、後端程式、資料庫結構、以及相關設定檔是否都涵蓋在內。

二、交付的時間點是什麼？
交付時間點應該明確寫入合約，避免上線後遲遲收不到檔案，卻沒有依據可以要求對方履行。

三、乙方是否保留既有框架或套件的權利？
很多網站公司會使用自己開發的框架或套件作為基礎來建站。你應該在簽約前了解清楚：哪些部分的原始碼會完整交付？哪些屬於乙方的既有資產、僅提供使用授權？未來換廠商時，這些部分是否會造成障礙？

技術文件，有時比原始碼本身更重要

使用 WordPress 或其他 CMS 建置的網站，通常較容易進行移轉與維護。但如果是乙方自行開發的系統，即使取得了原始碼，新廠商能否順利接手，還取決於文件是否完整、架構是否清晰。

有技術文件、沒有完整原始碼，通常比只有原始碼、沒有任何文件更容易接手。除了確認原始碼的交付，也建議在合約中要求乙方提供基本的技術文件，說明網站的架構與主要功能邏輯。

原始碼的問題，本質上是一個「退場機制」的問題。在合作順利的時候沒有人會在意，但當合作關係出現變化，它會直接決定你能不能順利繼續前進。

帳號歸屬，決定管理權

網域是你的網站地址，登記在哪個帳號下，那個帳號就有管理權。主機是存放網站檔案的伺服器空間，通常以年為單位租用。帳號的擁有者通常具有管理權限，例如變更 DNS 設定、申請移轉、續約或終止服務等。因此，企業應清楚了解這些帳號的歸屬與管理方式。想了解 DNS 的基礎概念，可以參考DNS 是什麼？網站架設與網域管理必懂的基礎概念。

常見的三種情境

情境一：主機和網域都登記在設計公司名下
這是最常見的狀況。合作期間通常沒有問題，但一旦想要換廠商或自行管理，就需要對方配合移轉，過程是否順利取決於雙方關係與合約約定。

情境二：主機和網域登記在客戶名下，委託設計公司管理
這種安排通常能讓企業保有較高的自主性。即使未來更換合作夥伴，也較容易延續網站的營運與管理。

情境三：主機和網域分屬不同帳號
這種情況在移轉時最容易產生混亂，建議在合約中把兩者的歸屬和管理方式都寫清楚。

一個值得注意的實務細節

有些設計公司提供「包含主機的套裝方案」，主機費用已含在年費裡，但主機帳號不會另外開給客戶。這個方案的本質是「租用」而非「擁有」，一旦停止合作或停繳費用，網站可能無法繼續運作。如果你希望保有較高的控制權，可以在簽約時討論是否改為自行申請主機和網域，再授權設計公司管理。這種方式通常能讓企業在維持委外管理便利性的同時，也保留較高的決策彈性。

維護費用涵蓋的範圍，遠比你想像的複雜

常見的維護項目大致分成幾個層次：

• 基礎運作層：主機正常運作、網站可以正常開啟、SSL 憑證有效、定期備份。這些通常是維護費用的基本保障。關於 SSL 憑證，可以參考SSL 憑證比較（免費 vs 付費）：有什麼差別？哪一種適合你？
• 內容更新層：修改文字、更換圖片、新增或刪除頁面內容。有些廠商包含在月費內，有些按次計費，也有些方案設定每月固定工時或修改額度，差異很大。
• 功能維護層：系統更新、外掛升級、程式除錯、資安修補。技術門檻較高，費用計算方式也更複雜。
• 功能開發層：新增頁面、調整版型、開發新功能。這類工作通常不在維護範圍內，屬於另外報價的專案。

想了解網站維護費用的市場行情，可以參考網站維護費每月到底在維護什麼？企業主必懂的維護項目全解析。

合約中建議確認的三件事

一、維護費用具體包含哪些服務項目？
合約中應逐項列出維護費涵蓋的服務內容，而不是只寫「網站維護」四個字。建議確認：主機與備份是否包含？內容修改每月有幾次或幾個工時？程式更新與除錯是否在範圍內？

二、緊急狀況的定義與回應時間
網站當機、被駭、表單失效——「緊急」的定義因廠商而異。建議在合約中約定：什麼情況算緊急？緊急狀況的回應時間為何？是否有 24 小時支援，或只在工作時間處理？

三、超出維護範圍的工作如何計費？
維護範圍之外的需求，應有明確的計費方式。是按小時計算、按次報價，還是另簽專案合約？這個機制若沒有事先約定，容易在追加需求時產生費用認知落差。

一個常見的模糊地帶

「幫我改一下首頁的文字」——這句話聽起來很簡單，但實際上可能涉及不同的判斷：這算內容修改還是版型調整？這個月的修改次數用完了嗎？解決方式不是把每一種情況都寫進合約，而是確保合約中有一個清楚的「超出範圍如何處理」的機制，讓雙方在遇到邊界情況時有共同的依據可以討論。

維護內容寫得越具體，雙方對服務範圍的期待通常越一致，也有助於降低後續溝通成本。

常見的分期結構

網站專案沒有一定的付款比例，不同公司可能依專案規模、執行方式與合作模式採用不同安排。以下是幾個常見的付款節點，供參考：

• 簽約款：合約簽訂後支付，代表專案正式啟動。
• 設計確認款：視覺稿或設計方向確認後支付。關鍵是「確認」的定義是口頭說好，還是書面確認？
• 開發完成款：網站功能開發完成、進入測試階段時支付。要特別注意「開發完成」的定義。
• 上線尾款：網站正式上線後支付。尾款的支付條件，直接連動到下一節要談的驗收標準。

一個常見的誤解

有些企業會將付款節點理解為「時間到了就付款」，但實務上，付款通常是與特定成果綁定的。反過來說，如果某個階段的成果尚未達成雙方約定的內容，也應該先釐清原因與後續處理方式，而不是單純依照日期推進。

合約中建議確認的三件事

一、每個付款節點對應的交付物是什麼？
建議在合約中逐一列出：這筆款項代表哪個階段完成？完成的標準是什麼？

二、客戶端延遲提供素材，時程與費用如何處理？
網站專案的時程不只取決於設計公司的執行速度，也取決於客戶提供素材的速度。如果客戶端延遲提供，是否會影響原訂時程安排？是否會產生額外費用？想了解網站製作時程的規劃方式，可以參考網站建置時程怎麼抓？不同類型網站製作時間與排程模板一次看懂。

三、付款後某些內容是否視為已確認並進入下一階段？
你應該清楚：哪個付款節點之後，哪些內容進入這個狀態？之後如果還想調整，流程和費用是什麼？

一個值得注意的實務細節

比較好的做法是在合約中明確定義「尾款支付條件」：網站已依合約約定範圍完成、客戶確認驗收、並於約定期間內支付尾款。此外，若驗收後一定期間內未提出書面異議，是否視為驗收完成，也建議在合約中事先約定——這個細節在實務上很常被忽略，卻往往是後續爭議的起點。

付款條件的設計，本質上是在建立一套雙方都能理解的合作節奏。當交付內容、確認方式與付款節點被清楚定義時，每一筆款項代表的就不只是金額，而是一個階段的共識。

為什麼「完成」很難定義

網站不像製造業的產品，沒有完全一致的驗收標準。一個網站是否「完成」，涉及幾個不同層次的判斷：

• 功能層面：所有約定的功能是否正常運作、是否符合合約約定的功能規格？「客戶以為包含會員系統、乙方認為不在範圍內」這類認知落差，在這個層面最常發生。
• 設計層面：視覺呈現是否符合當初確認的設計稿？這個層面的判斷相對主觀。
• 內容層面：若網站架構、設計與功能均已完成，但部分內容尚待客戶提供，是否影響驗收進度？這類情況也建議事先約定處理方式，以避免專案長期停滯。
• 效能與技術層面：如果專案包含 SEO 基礎建置、行動裝置優化或效能優化，也建議將相關驗收標準寫入合約，例如是否完成 Sitemap 設定、是否完成基本結構化資料配置等。關於網站上線前的完整檢查，可以參考網站上線前必看！你的網站準備好了嗎？完整檢查清單。

合約中建議確認的三件事

一、驗收的項目清單是什麼？
建議在合約中附上或約定一份驗收項目清單，涵蓋主要功能、設計符合度、以及雙方最可能產生爭議的環節。

二、驗收期間與提出異議的方式
合約中應約定：網站交付後，客戶有多少時間進行驗收？應透過什麼方式提出問題？驗收期間結束後若未提出異議，是否視為驗收完成，應依雙方約定辦理。

三、驗收未通過時，修改的範圍與次數如何界定？
哪些屬於「應修正的缺失」，哪些屬於「超出原始範圍的新需求」？這條界線應該在合約中有基本的界定原則。在專案初期建立清楚的需求文件，往往比驗收階段反覆協商更有效率。關於需求訪談的重要性，可以參考網站製作流程第一步：需求訪談如何決定網站架構與 SEO 成效？

一個常見的模糊地帶

「我覺得這個顏色不太對」、「這個排版看起來怪怪的」，這類主觀感受，在驗收階段非常常見。如果當初設計稿已經過客戶書面確認，設計稿本身就是驗收的基準。在設計階段就建立書面確認的習慣，往往能讓後續的驗收過程順暢很多。

驗收標準的本質，不是在製造障礙，而是在專案開始之前，就讓雙方對「終點」有共同的理解。當完成的定義被事先說清楚，驗收才能成為專案的里程碑，而不是新的起點。

修改有兩種，性質完全不同

缺失修正：若網站成果與雙方原先約定的內容存在落差，通常應依合約約定進行修正。

需求調整：客戶在過程中改變想法、追加功能、或提出當初需求訪談沒有討論到的內容—，這類修改屬於範圍變更，通常需要另外討論費用。

合約的作用，不是避免修改，而是在專案開始之前，就先約定修改與需求變更的判斷原則。

合約中建議確認的三件事

一、免費修改的次數或範圍是什麼？
合約中應明確說明：免費修改的定義是什麼？是以「次」計算、以「工時」計算、還是以「修改類型」區分？需要特別注意的是口頭承諾，任何承諾，只要沒有被記錄下來，未來都可能出現不同的解讀。

二、超出範圍的需求，如何判斷與計費？
雙方應依據需求文件、設計確認紀錄及合約約定，共同判斷是否屬於需求變更。比較好的做法是要求乙方在執行前提供書面估價，客戶確認後才進行，避免執行完成後雙方對費用產生認知落差。

三、需求變更的確認流程是什麼？
每一次需求變更，都應該有書面紀錄——不論是 Email 確認、專案管理工具的留言、還是正式的變更單。

一個容易被忽略的情境

「這個功能我們之前不是有提過嗎？」在網站專案中，雙方可能曾經討論過某個想法，但最終未被納入需求文件。等到開發後期再次被提出時，便容易出現「我以為有包含」與「我們當初沒有確認」的落差。需求文件與會議紀錄的存在，不只是管理工具，更是雙方共同的依據。

一個值得注意的實務細節

有些合約會寫「無限次修改」。這句話聽起來對客戶很有利，但實際上仍需要進一步界定適用範圍：是指設計調整，還是也包含功能開發？是在專案期間有效，還是上線後也適用？與其追求「無限」，不如追求「清楚」。

需求被定義得越清楚、確認過程越完整，雙方花在協調認知差異上的時間就越少，也越能把心力放在把網站做好。

終止合作時，需要移交的東西有哪些

• 網站檔案：原始碼、資料庫備份、媒體檔案，若合約約定屬於移交範圍，建議以雙方約定的格式與方式提供。
• 帳號與存取權限：網域管理帳號、Google Analytics、Google Tag Manager、Google Search Console 等第三方工具的存取權限。
• 第三方服務的管理權：電子報系統、金流串接等第三方服務，如果是由乙方代為申請，終止時應一併確認如何移轉或重新申請。
• 技術文件：若乙方在專案期間有建立相關文件，應一併納入移交範圍。

合約中建議確認的三件事

一、終止的條件與通知方式
合約應載明：哪些情況下合約可以終止？需要提前幾天通知？是否有違約金或費用結算的約定？終止條款不應預設只有一方會提出終止，應對甲乙雙方都有清楚的規範。

二、移交的內容、格式與時間
合約應明確列出終止後應移交的項目清單，以及移交的時間期限。移交應在終止後幾個工作天內完成？帳號移交的方式是直接轉移擁有權，還是提供帳號密碼？

三、費用如何結算
已執行的工作如何計費？已付的款項是否有退款機制？若是乙方提出終止，與甲方提出終止，費用結算方式是否不同？

終止條款是保護雙方，不是防著對方

很多企業主在簽約時，不太願意認真看終止條款，總覺得談終止是在預設合作會出問題。但終止條款的存在，恰恰是因為合作中沒有人能預測未來。當業務方向改變、預算調整、或雙方找到更適合的合作模式，一個清楚的終止機制能讓雙方以最小的摩擦各自前進，而不是在最後一個環節留下不必要的誤解與爭議。

著作權與授權

☐ 哪些成果的著作財產權會移轉給我？哪些屬於乙方既有資產、僅提供授權使用？
☐ 授權的範圍是否包含修改、再授權給第三方維護廠商？
☐ 第三方素材（圖庫、字型、外掛）的授權費用由誰負擔？合作終止後是否仍可繼續使用？

原始碼與技術文件

☐ 原始碼是否列為交付物？交付範圍涵蓋哪些部分？
☐ 交付時間點是什麼？是上線時、付清尾款後，還是其他節點？
☐ 是否有技術文件說明網站架構與主要功能邏輯？

主機與網域

☐ 主機和網域登記在誰的帳號下？帳號資訊是否會提供給我？
☐ 續約費用由誰負擔？到期前如何通知？
☐ 合作終止後，移轉流程與時間如何約定？

維護範圍

☐ 維護費用具體包含哪些服務項目？
☐ 緊急狀況的定義與回應時間是什麼？
☐ 超出維護範圍的工作，計費方式為何？

付款條件

☐ 每個付款節點對應的交付物是什麼？
☐ 客戶端延遲提供素材，是否影響時程與費用？
☐ 尾款支付條件是什麼？驗收後多久未提出異議視為完成？

驗收標準

☐ 驗收項目清單涵蓋哪些內容？功能、設計、效能是否都在其中？
☐ 驗收期間是多久？異議應透過什麼方式提出？
☐ 若專案包含 SEO 基礎建置，相關驗收標準是否已寫入合約？

修改與追加費用

☐ 免費修改的定義與次數或工時為何？
☐ 需求變更的判斷原則與書面確認流程是什麼？
☐ 口頭承諾是否都已轉為書面紀錄？

合約終止

☐ 終止條件、通知方式與期限為何？
☐ 終止後應移交的項目清單是什麼？移交時間期限為何？
☐ 費用結算方式是否對甲乙雙方都有清楚規範？

大多數糾紛，都是因為理解不同

網站專案的爭議，絕大多數不是簽約前沒寫，也不是因為客戶刻意刁難。而是因為雙方在專案開始時，對某些事情的理解不一樣，只是當時沒有人發現，直到問題浮現才開始各說各話。合約的作用，就是在這些細節還沒變成問題之前，把它們說清楚。

對甲方是保障，對乙方也是保護

一份寫得清楚的合約，對設計公司同樣重要。清楚的驗收標準，讓設計公司知道做到什麼程度算完成。清楚的修改範圍，讓設計公司不會陷入無止境的需求變更。清楚的付款節點，讓設計公司可以按照約定推進專案。好的合約不是甲方對乙方設下的防線，而是雙方共同建立的工作框架與合作方向。

簽約前，值得花的時間

審閱一份合約，可能需要三十分鐘到一個小時。不需要把每一條都變成談判，但每一條都值得理解。如果有任何條款看不懂，在簽名之前提出來討論，永遠比簽名之後爭議更容易處理。

如果你正準備啟動網站專案，除了比較價格與作品集，也別忽略合作模式與合約內容。畢竟，好的網站不只是做出來，更需要一段好的合作關係來支撐。如果對網站規劃、合作流程或合約內容有疑問，也歡迎與 前網數位 交流，我們很樂意分享多年來累積的實務經驗。