網站上線只是開始

網站不是做完就結束的一次性專案，它比較接近一台需要定期保養的設備。放著不管的網站，通常一到兩年內就會出現各種狀況——外觀還在，但功能壞了、被植入廣告、或搜尋不到了。

這篇整理網站上線後實際需要持續處理的事情，以及各項的責任歸屬。

一、必須按時繳費的項目

其中網域最容易出事，因為一年才一次，且通知信常寄到已離職員工的信箱。詳見網域忘記續約會怎樣。

建議做法：把所有到期日整理成一張表，指定負責人與代理人，並在行事曆設定提前提醒。

二、安全性維護

這是最容易被忽略、後果卻最嚴重的一項。動態網站使用的程式與套件會陸續發現安全漏洞，發布修補版本。不更新就等於門一直開著。

被入侵的典型症狀

• 網站被植入看不見的廣告連結，通常指向博弈或成人網站
• 搜尋自己公司名稱時，出現不是自己放的內容
• 瀏覽器或搜尋結果顯示這個網站有風險的警告
• 網站突然變得很慢

被入侵的損失不只是清理成本。搜尋引擎一旦把網站標記為有風險，恢復需要時間，這段期間的信任損失難以估算。

基本防護

• 系統與套件保持更新
• 後台密碼夠強且不與其他服務共用
• 離職人員的帳號立即停用
• 定期檢視是否有異常的檔案或使用者

三、備份

備份的價值在出事那一天才顯現，但那時候再做就來不及了。

要備份什麼

• 網站檔案——程式、圖片、上傳的檔案
• 資料庫——文章、產品、會員、訂單。這一項最常被漏掉，只備份檔案是不夠的

要問清楚的三個問題

1. 多久備份一次？ 每天、每週，還是根本沒有
2. 備份保留幾份？ 只留最新一份的話，若問題發生在幾天前才被發現，最新的備份可能已經包含問題
3. 備份放在哪裡？ 與網站放在同一台主機的備份，主機出事時會一起消失

最後一點特別重要。真正有意義的備份必須是異地的。

還原演練

沒有測試過的備份等於沒有備份。建議至少做過一次還原測試，確認備份檔案是完整可用的。

四、內容更新

這一項沒有立即的災難後果，但長期影響最大。

搜尋引擎會參考網站是否持續有新內容產出。長期不更新的網站，排名會逐漸被持續經營的同業超過——不是因為被懲罰，而是別人一直在前進。

務實的做法

• 訂一個做得到的頻率。每月一篇做得到，比訂每週一篇然後三個月後放棄好
• 寫客戶實際問過的問題。這是最好的題材來源，而且必然有人搜尋
• 定期檢視舊內容。過時的資訊要更新或下架，例如已停用的服務、已變更的聯絡方式

五、監控與檢查

建議定期做的檢查，多數只需要幾分鐘：

• 每月：實際開一次網站與手機版、送出一次聯絡表單確認收得到信、檢查有無異常內容
• 每季：檢視流量數據、檢查搜尋引擎的異常通知、確認備份正常運作
• 每年：檢視所有到期日、評估內容是否需要大幅更新

另外建議設定網站的異常通知服務，網站無法開啟時能第一時間得知。很多公司是客戶打電話來說「你們網站掛了」才知道，那通常已經過了好幾個小時。

責任歸屬要先講清楚

網站架設簽約時，建議把以下事項明確約定，避免日後互相認為是對方的責任：

• 網域與主機由誰負責續約、費用如何計算
• 系統更新是否包含在維護範圍內
• 備份由誰執行、頻率、保留期間、放置位置
• 網站故障時的回應時間
• 被入侵時的處理責任與費用
• 維護合約包含多少修改工時，超出如何計費

這些事項在合作順利時不會被提起，出狀況時才會發現當初沒講清楚。花十分鐘寫進合約，比事後爭論划算得多。

這個問題的答案，十年前和現在完全不同

早期網頁設計的一大工作量，是處理各家瀏覽器的差異，尤其是舊版 Internet Explorer 的種種特殊行為。當時「支援到 IE 幾」是報價單上會註明的項目。

現在情況簡單很多：主流瀏覽器都採用相近的標準，差異已經小到多數情況下不需要特別處理。

目前需要考慮的瀏覽器

其中最需要實機測試的是 iPhone 上的 Safari。它與其他瀏覽器的核心不同，在表單元件、影片播放、部分版面行為上會有自己的表現方式。用電腦模擬不一定測得出來。

Internet Explorer 已經退場

微軟已終止 Internet Explorer 的支援，Windows 也已改以 Edge 為預設瀏覽器。現在製作新網站不需要再考慮 IE 相容性。

這對網站架設的實際影響是正面的：省下的相容處理成本可以投入在實際的功能與設計上，也能使用較新的網頁技術做出更好的版面與效果。

如果公司內部還在用 IE 呢？

少數企業因為內部系統的歷史因素，仍指定用 IE 或相容模式操作某些系統。這種情況請把「內部系統」與「公司官網」分開看待——官網的訪客是外部客戶，不需要為了內部的特殊環境犧牲一般訪客的體驗。

若內部系統確實有此需求，建議的做法是內部另外保留一個瀏覽器專門操作舊系統，日常上網與瀏覽官網使用現代瀏覽器。這同時也是資安考量——已停止更新的瀏覽器不再收到安全修補。

合理的支援政策

我們建議在專案開始時就把支援範圍講清楚，避免驗收時的認知落差。一個務實的寫法是：

• 支援各主流瀏覽器的最新版與前一版
• 手機以主流機型的預設瀏覽器為測試基準
• 已終止支援的瀏覽器不在支援範圍
• 使用比例極低的特殊瀏覽器，若有需求另行評估

「支援所有瀏覽器」這種寫法看似有保障，實際上無法執行也無法驗收，反而是糾紛的來源。

比瀏覽器更該關心的三件事

以現在的實務來說，這三項對訪客體驗的影響，都比瀏覽器相容性更大：

一、手機上好不好用

多數訪客用手機瀏覽，版面在手機上是否好操作，遠比在某個冷門瀏覽器上是否完美重要。詳見RWD 響應式網站是什麼。

二、載入速度

網站在任何瀏覽器上都能開，但要等十秒——這比在某個瀏覽器上有一點樣式偏差嚴重得多。

三、無障礙

字體大小是否可調整、色彩對比是否足夠、鍵盤能否操作。這不只是照顧特定族群，對一般使用者的閱讀體驗也有幫助。公部門與特定產業的網站另有法規要求，需在網站架設前確認。

怎麼確認自己的網站有沒有問題

• 用實機測試——至少要有一支 iPhone 和一支 Android 手機實際開過
• 請不同的同事各自用自己的裝置開一次——最省事也最有效的測試方法
• 看網站的流量分析——實際訪客用什麼瀏覽器、什麼裝置，數據會告訴您該優先照顧誰
• 驗收時明確列出測試環境——把測試過的瀏覽器與裝置寫進驗收文件

最後一項尤其重要。網站架設的驗收若沒有明確的測試範圍，日後任何一台特殊裝置上的顯示問題，都可能變成爭議。

先看一個現實

台灣使用者瀏覽網站，來自手機的比例早已超過電腦，某些行業甚至達到八成以上。而 Google 判斷網站內容時，是以手機版的呈現為主要依據。

所以「手機版一定要做嗎」這個問題，實務上已經不成立——沒有手機版的網站，在多數訪客眼中和搜尋引擎眼中，都是有問題的網站。

RWD 是什麼

RWD（Responsive Web Design，響應式網頁設計）是同一份網頁，依據螢幕寬度自動調整版面的做法。

例如電腦上是三欄並排，平板變成兩欄，手機變成單欄由上往下排列。內容是同一份，只是排列方式改變。

怎麼自己測試

用電腦開啟網站，把瀏覽器視窗慢慢縮窄。如果版面會跟著重新排列、文字不需要左右捲動就能閱讀，那就是 RWD。如果整個畫面只是等比例縮小、文字變得看不清楚，那就不是。

三種手機版的做法比較

另做一個手機版網站是十年前的做法，現在幾乎不採用了——維護要做兩份、內容容易不同步、還要額外處理兩個網址的對應關係。

RWD 不是把電腦版縮小

這是最常見的誤解，也是很多「有做 RWD 但很難用」的網站的問題所在。真正的手機版設計要考慮：

• 手指不是滑鼠——按鈕要夠大、間距要夠，避免點錯
• 沒有滑鼠移過去的效果——依賴移過去才展開的選單，在手機上無法操作
• 資訊優先順序不同——電腦版可以並排的東西，手機上必須決定誰先誰後
• 表單要盡量簡短——手機打字很費力，欄位越多放棄率越高
• 電話號碼要能直接點擊撥出——對服務業來說這一項直接影響來電量
• 圖片不能太大——行動網路的速度與流量都要考慮

速度在手機上更重要

手機的網路條件與運算能力都不如電腦，同一個網站在手機上通常慢得多。而使用者對慢的容忍度很低——多數人在等待數秒後就會離開。

幾個最常見的拖慢原因：

• 圖片沒有壓縮——這是最大宗。直接把手機拍的原圖上傳，一張就好幾 MB
• 載入了過多的外掛與追蹤碼
• 字型檔案過多過大
• 首頁塞了大量輪播圖

其中圖片問題最容易改善，效果也最明顯。好的後台應該在上傳時自動壓縮，避免這個問題發生。

常見問答

已經有網站了，要改成 RWD 很麻煩嗎？

取決於原本的架構。如果原本是用表格排版的老式網頁，通常改造的成本會接近重做，這種情況建議直接重新設計。如果原本結構還算合理，調整樣式即可。

做了 RWD 排名就會上升嗎？

不會自動上升，但沒做會明顯不利。可以把它理解為及格門檻而非加分項目——做到只是回到起跑線，排名還是取決於內容品質。

需要另外做 App 嗎？

對絕大多數中小企業，答案是不需要。App 的開發與維護成本高出許多，而且使用者要願意安裝才有機會被看到。RWD 網站在瀏覽器就能開，門檻低得多。

除非有需要頻繁回訪、需要推播、或需要使用手機硬體功能的明確需求，否則先把網站做好比較實際。

要支援到多小的螢幕？

一般以主流手機的寬度為設計基準即可。過度追求支援極舊或極小的裝置，投入的成本與實際受益的人數不成比例。

後台是網站能不能長期經營的關鍵

網站架設完成後，決定它三年後還有沒有價值的，不是當初的設計多漂亮，而是這段期間有沒有持續累積內容。而能不能持續累積，取決於後台好不好用。

後台難用的下場很現實：承辦人每次都要花半小時研究怎麼發一則消息，發了兩次就放棄，網站從此停在上線那天的狀態。

基本必備的功能

內容管理

• 新增、編輯、刪除——最基本的三件事
• 草稿與發布——寫到一半可以存起來，不會直接公開
• 排序與置頂——重要的消息可以固定在最上面
• 上下架控制——過期的活動可以隱藏而非刪除，保留紀錄

編輯器

能不能不寫程式就排版，決定了非技術人員願不願意用。應該具備：文字樣式、插入圖片、插入連結、表格、以及從 Word 貼上時能清除多餘格式——最後這一項最實用，卻常被忽略。

圖片管理

• 上傳時自動縮圖與壓縮，避免使用者直接傳上一張五百萬畫素的原圖拖垮網站速度
• 可重複使用已上傳的圖片，不用每次重傳
• 能填寫替代文字，這對搜尋引擎與無障礙都有幫助

權限管理

多人使用時，應能區分不同層級：有人只能發消息、有人可以改產品、只有主管能動到公司簡介。不要全公司共用一組管理員帳號——出事時無法追查，人員離職時也無法單獨停用。

建議要有的功能

SEO 相關欄位

每一則內容應該能單獨設定標題與描述。這些欄位直接影響搜尋結果的呈現，寫死或自動截取的效果通常不理想。

修改紀錄

誰在什麼時候改了什麼。內容被誤刪或改壞時，這是唯一的救命索。

表單與詢問管理

客戶從網站送出的詢問，除了寄信通知，也應該在後台留一份紀錄。信件容易被誤刪或漏看，後台的紀錄是備援。

基本的流量概況

不必取代專業的分析工具，但至少讓管理者知道哪些內容有人看。

常被要求但要謹慎評估的功能

版面自由拖拉

聽起來很吸引人，實際上有代價：使用者容易拖出破碎的版面、手機版顯示異常、以及整站視覺一致性瓦解。

比較務實的做法是提供數種預先設計好的區塊樣式讓使用者選擇，在彈性與品質之間取得平衡。

完全自訂的欄位

讓使用者自己新增欄位很彈性，但也很容易讓資料結構失控，日後要調整或搬移時非常麻煩。

評估後台時可以問的問題

在洽談網站架設時，這幾個問題可以快速判斷後台的實用程度：

1. 可以請你當場示範發一則消息嗎？ 從登入到發布，看要幾個步驟、要多久
2. 從 Word 貼上一段文字會變成什麼樣子？ 這是實際最常見的操作
3. 上傳一張手機拍的照片會怎麼處理？ 有沒有自動壓縮
4. 可以設定不同人的權限嗎？
5. 手機上能不能用？ 臨時要發布訊息時很重要
6. 有沒有教學文件或影片？ 人員異動時新人怎麼上手

後台的帳號管理建議

• 每人一個帳號，不共用
• 人員離職當天停用帳號，這件事常常被忘記
• 管理員帳號的密碼不要與其他服務相同
• 後台登入網址不要用最常見的路徑，可降低自動化攻擊的騷擾
• 把後台網址、帳號歸屬記錄在公司文件中，不要只存在某個人的瀏覽器

一個判斷標準

後台好不好，最終的檢驗方式很簡單：網站上線半年後，公司裡的人還在用嗎？

如果內容停在上線那天，不論當初後台功能列表多長，對這家公司來說它就是失敗的。設計後台的目標不是功能齊全，是讓人願意用。

最直接的差別：能不能自己改

這是最常被問到的問題，而且答案會直接影響網站架設的費用與後續的維護方式。

靜態網頁

每一頁都是一個實際存在的檔案。訪客要求哪一頁，主機就把那個檔案原封不動送出去。內容是什麼，檔案裡就寫死什麼。

適合的情況

• 內容幾乎不會變動的形象網站
• 單頁式的活動網站或產品介紹頁
• 預算有限，且確定不需要自行更新

要注意的代價

「不需要自行更新」這個前提，在實務上往往不成立。公司搬遷、電話變更、新增一項服務、想發一則消息——每一次都要找當初的設計者處理，而且要看對方的排程與報價。

更麻煩的情況是：當初製作的人已經聯絡不上、或已經不做這一行了。這時連改一個電話號碼都得請人重新處理，甚至可能因為程式寫法過舊而建議整站重做。

動態網頁

網頁不是預先存在的檔案，而是訪客要求時，程式才即時去資料庫取資料、組合成頁面送出。

這就是為什麼您在後台新增一則消息，前台馬上就看得到——因為前台每次都是重新去資料庫拿最新的資料。

帶來的能力

• 後台自行新增、編輯、刪除內容
• 會員系統、訂單、表單、留言
• 依條件篩選、排序、搜尋
• 多人協作，可設定不同權限

要注意的代價

• 需要持續維護——程式與套件要更新，否則會出現安全漏洞
• 主機需求較高——需要支援程式執行與資料庫
• 備份更重要——資料在資料庫裡，只備份檔案是不夠的

網址結尾是 .html 就一定是靜態嗎

不一定。早年確實可以用副檔名判斷，但現在很多動態網站會把網址美化成靜態的樣子，這麼做對使用者閱讀和搜尋引擎都比較友善。

所以不能只看網址就判斷。最直接的判斷方式是：問對方「有沒有後台可以自己改內容」。有，就是動態；沒有，就是靜態。

htm 與 html 有什麼不同

沒有實質差別，兩者都是靜態網頁的副檔名。htm 是早期作業系統限制副檔名最多三個字元時的產物，後來限制解除，html 成為通用寫法。

現在新做的網站幾乎都用 html，看到 htm 通常代表這是相當早期製作的網頁。

那該選哪一種

以現在的實務來說，絕大多數企業網站都應該做動態網站，理由是：

1. 內容更新是網站經營的核心。搜尋引擎會參考網站是否持續有新內容，長期不更新的網站排名會逐漸下滑
2. 靜態的省錢是假象。省下的初期費用，往往在兩三次修改後就付出去了，而且每次都要等
3. 主動權在自己手上。想發布消息、調整商品，隨時可以做，不用受制於他人的檔期

例外情況是：確定只是短期的活動頁、或極度單純且真的不會變動的單頁網站。

混合的做法

近年也有把兩者優點結合的做法：在後台用動態方式編輯內容，系統再自動產生靜態檔案供訪客瀏覽。這樣兼顧了編輯便利與載入速度，但架構較複雜，適合內容量大、對速度要求高的網站。

對一般企業網站而言，選擇有良好快取機制的動態網站就足夠了。

四個常被混為一談的東西

「我要做一個網站」這句話裡，實際上牽涉四件各自獨立的東西。用開店來比喻最容易理解：

三者是分開購買、分開管理的，可以來自同一家廠商，也可以來自三家不同廠商。詳細分工可參考網域註冊商、DNS 與主機商是三件不同的事。

網頁是什麼

網頁的本質是一個純文字檔案，裡面用一套標記語言描述「這段是標題」「這段是段落」「這裡放一張圖」。這個檔案本身不好看，是瀏覽器負責讀懂這些描述，再畫成我們看到的畫面。

組成一個網頁通常有三種角色：

• HTML——決定內容與結構，哪些是標題、哪些是段落、哪些是連結
• CSS——決定外觀，字體、顏色、間距、版面配置
• JavaScript——決定行為，點擊後展開、輪播、表單驗證

把它想成蓋房子：HTML 是結構與隔間，CSS 是油漆與裝潢，JavaScript 是電動門和感應燈。三者分工，但最終呈現為一個整體。

為什麼要知道這件事

因為它解釋了一個常見疑問：為什麼搜尋引擎「看得到」文字，卻「看不到」圖片裡的文字。 搜尋引擎讀的是 HTML 這份純文字描述，圖片對它而言只是一個檔案。把重要的標題、說明做成圖片，等於對搜尋引擎隱藏了這些內容——這也是我們不建議整站大量使用圖片替代文字的原因。

網站是什麼

網站是一群網頁的集合，透過連結串在一起，並放在同一個網域底下。

典型的企業網站會包含這些網頁：首頁、關於我們、產品或服務、最新消息、聯絡我們。每一頁都是獨立的網頁，但共用同一套外觀與導覽。

網站不是只有「看得到」的部分

一個能長期經營的網站，實際上分成三層：

• 前台——訪客看到的部分
• 後台——管理者登入後編輯內容的介面
• 資料庫——實際存放文章、產品、訂單等資料的地方

前台呈現的內容是即時從資料庫取出來的。這也是為什麼您在後台修改一則消息，前台立刻就會更新。詳見靜態網頁與動態網頁差在哪。

從輸入網址到看到畫面，發生了什麼

1. 您在瀏覽器輸入網址
2. 系統查詢這個網址對應到哪一台主機（這一步靠 DNS）
3. 瀏覽器向該主機要資料
4. 主機把網頁檔案送回來，若是動態網站，還會先去資料庫取資料組合成頁面
5. 瀏覽器解讀這些檔案，畫成畫面

整個過程通常在一兩秒內完成。任何一個環節出問題，網站就打不開——這也是為什麼「網站壞了」需要先判斷是哪一層的問題，而不是直接怪罪某一家廠商。

幾個常見的誤解

「網站放在 Google 上」

不是。網站放在您租用的主機上，Google 只是把您的網站登記在它的索引裡，讓別人搜尋得到。兩件事完全獨立——您的網站可以正常運作但完全搜尋不到，也可以在 Google 有紀錄但實際已經關站。

「有粉絲專頁就不用做網站」

粉絲專頁是租來的空間，版面、功能、觸及率都由平台決定，規則隨時可能改變，帳號也可能被停用。網站是自己的資產，內容、結構、資料都在自己手上。兩者角色不同，通常是互補而非取代。

「網站做好就不用管了」

網域要續約、主機要續約、SSL 憑證要更新、系統要修補安全漏洞、內容要持續更新。放著不管的網站，通常一兩年後就會出現各種狀況。

為什麼要自己查

網站或信箱出問題時，最耗時的往往不是修復，而是判斷問題出在哪一層。會用查詢工具，可以在幾分鐘內確認 DNS 是否正常，把範圍縮小。

這篇整理最基本、也最實用的幾個指令。不需要背，用到時查一下即可。

工具的取得

• Windows——內建 nslookup，在命令提示字元或 PowerShell 直接使用
• macOS 與 Linux——內建 dig，功能較完整，輸出也較清楚
• 沒有指令環境——用線上的 DNS 查詢服務也可以，部分還能同時查詢多個地區的解析結果

基本查詢

查 IP（A 記錄）

nslookup example.com

dig example.com A +short

+short 只顯示結果，不顯示完整的查詢資訊，日常使用比較方便。

查郵件伺服器（MX 記錄）

nslookup -type=mx example.com

dig example.com MX +short

信箱有問題時第一個要查的。重點是確認只有現行服務商的記錄，沒有殘留的舊記錄。

查名稱伺服器（NS 記錄）

nslookup -type=ns example.com

dig example.com NS +short

這是最該優先學會的一個。 它告訴您這個網域實際由誰管理，也就是您該去哪裡改設定。改了半天沒效果，多半就是改錯地方。

查 TXT 記錄（SPF、DKIM、DMARC）

nslookup -type=txt example.com

dig example.com TXT +short

查 SPF 就看回傳結果中以 v=spf1 開頭的那一筆，如果出現兩筆，那就是問題所在。

DMARC 記錄放在特定的子名稱下：

dig _dmarc.example.com TXT +short

指定用哪個解析器查詢

這是排查擴散問題的關鍵技巧。在指令中指定解析器，就能看到不同解析器目前拿到的答案：

dig @8.8.8.8 example.com +short

nslookup example.com 8.8.8.8

用途：

• 比對不同解析器的結果是否一致，判斷擴散進度
• 若各家解析器答案已一致、只有自己看到舊的，那就是本機快取或 hosts 檔的問題

直接問權威伺服器

如果想跳過所有快取，直接問存放資料的源頭，可以先查出 NS，再指定該 NS 查詢：

dig @ns1.example.com example.com +short

這裡回傳的是最新、未經快取的真實設定值。若這裡是對的、外面是錯的，那就純粹是等擴散；若這裡也是錯的，那就是設定沒存進去。

看完整的查詢路徑

dig example.com +trace

會顯示從根伺服器一路往下查到權威伺服器的完整過程。用於診斷 NS 設定錯誤、或委派層級出問題的情況。日常用不到，但架構有異常時很有用。

清除本機快取

確認外面都正常、只有自己不對時：

• Windows：ipconfig /flushdns
• macOS：需執行對應的清除快取指令（版本間略有差異）
• 瀏覽器：用無痕視窗測試，或清除瀏覽紀錄
• 檢查 hosts 檔：測試期間手動加的指定會蓋掉一切，這是最容易忘記還原的設定

常見情境的排查順序

網站打不開

1. dig example.com NS +short — 確認由誰管理
2. dig example.com A +short — 確認有回傳 IP，且是預期的 IP
3. 若 IP 正確，問題不在 DNS，往主機端查
4. 若沒有回傳或 IP 不對，直接問權威伺服器，判斷是設定錯誤還是擴散中

信箱收不到信

1. dig example.com MX +short — 確認記錄正確且沒有殘留
2. 確認 MX 指向的名稱有 A 記錄
3. 往主機或郵件服務端查容量與過濾規則

寄信被當垃圾信

1. dig example.com TXT +short — 確認 SPF 只有一筆且涵蓋所有寄信來源
2. dig _dmarc.example.com TXT +short — 確認 DMARC 存在
3. 檢視實際收到信件的原始標頭，看驗證結果

詳細的處理方式見公司信箱收不到信或被當垃圾信怎麼查。

一個實用習慣

在做任何 DNS 變更之前，先把現有記錄查一次並存下來：

dig example.com ANY

部分伺服器已不完整回應 ANY 查詢，較保險的做法是逐一查詢 A、CNAME、MX、TXT、NS 並各自留存。這份紀錄在出問題要還原時，價值極高。

第三方 DNS 服務在做什麼

把網域的名稱伺服器指向第三方服務（Cloudflare 是最常見的一家），DNS 查詢就改由對方處理。多數這類服務同時提供 CDN、防護與加速功能，等於在使用者與您的主機之間加了一層。

運作方式的差別在於：

• 只做 DNS——單純提供解析服務，使用者仍直接連到您的主機
• 加上代理（CDN）——使用者連到的是服務商的節點，由節點回主機取資料。此時您的主機 IP 對外是隱藏的

這兩種模式在同一個服務裡通常是逐筆記錄可切換的，不是全有全無。

可能的好處

速度

靜態檔案（圖片、CSS、JS）由鄰近使用者的節點提供，減少往返時間。對台灣客群、主機也在台灣的網站，改善幅度有限；但如果主機在國外、或有海外客群，差異會很明顯。

穩定性

主機短暫故障時，部分服務可以繼續提供快取版本的頁面，不至於完全開不了。

安全

• 隱藏主機真實 IP，降低被直接攻擊的機會
• 提供分散式阻斷服務攻擊的緩解
• 可加上網站應用程式防火牆規則

管理便利

DNS 管理介面通常比註冊商或主機商的好用，變更生效也快。

要付出的代價

多一層可能出錯的環節

網站打不開時，除了主機和 DNS，還要多查一層代理設定。對排查問題的人來說，架構複雜度是有成本的。

快取造成的困惑

更新了網站內容或圖片，但使用者看到的還是舊版——因為節點快取還沒更新。需要在服務商後台手動清除快取。這件事如果沒人知道，會被誤判為網站故障。

SSL 設定容易搞錯

啟用代理後，加密其實分成兩段：使用者到節點、節點到主機。如果第二段設定不當，可能出現看似有鎖頭、實際上後半段未加密的情況，或產生無限重新導向的錯誤。設定時務必選擇兩段都加密的模式。

需要交出 DNS 控制權

名稱伺服器必須改指向該服務商。這代表該帳號的安全性等同於整個網域的安全性——帳號被盜，等於網站與信箱都被接管。務必啟用兩步驟驗證。

郵件容易出事

最常見的意外：把郵件相關的記錄也開啟代理。MX 記錄不能被代理，指向郵件伺服器的 A 記錄也應維持直連，否則信件會無法送達。設定時要逐筆確認代理的開關狀態。

什麼情況建議用

• 主機在國外，或有海外客群
• 網站曾經遭遇攻擊，或屬於容易被攻擊的類型
• 流量較大、圖片較多的網站
• 需要在多個主機之間做流量調度
• 有人懂得管理，出問題時知道怎麼查

什麼情況不必用

• 單純的企業形象網站、客群集中在台灣、主機也在台灣——多這一層的效益很有限，反而增加複雜度
• 公司內部沒有人熟悉這類設定，且配合的廠商也不熟
• 網站有大量動態內容，快取效益不高

我們的實際建議是：不要為了「聽說很好」而導入。 網站慢的原因多半是圖片沒壓縮、程式沒最佳化、主機規格不足，這些問題不會因為加一層 CDN 就消失。先把根本問題處理好，才是有效的做法。

如果決定導入，請注意

1. 先完整備份現有的所有 DNS 記錄。匯入時系統會自動掃描，但不保證抓得完整，尤其是 TXT 記錄容易遺漏
2. 逐筆核對匯入後的記錄與原本是否一致，特別是 MX 與 SPF、DKIM、DMARC
3. 先只做 DNS，不開代理，觀察數天確認一切正常
4. 再逐步為網站相關的記錄開啟代理，郵件相關記錄維持直連
5. 啟用後完整測試網站與收發信
6. 為帳號啟用兩步驟驗證

切換名稱伺服器同樣有擴散時間，作法與注意事項參考改了 DNS 要多久才生效。

子網域是什麼

在主網域前面加一段名稱，就形成子網域，例如 shop.example.com、blog.example.com、test.example.com。

技術上，開一個子網域不需要另外付費、不需要另外註冊，只要在 DNS 加一筆記錄即可，數量通常也沒有實質限制。這是它最大的優勢——成本幾乎為零。

怎麼開一個子網域

情況一：指向自己的主機

新增一筆 A 記錄，主機名稱填子網域名稱（例如 shop），值填主機 IP。接著在主機端建立對應的網站目錄與設定。

情況二：指向外部服務

新增一筆 CNAME 記錄，值填服務商提供的位址。常見於使用外部電商平台、客服系統、活動報名平台的情況。

注意 CNAME 的限制：同一個名稱上有 CNAME 就不能再有其他記錄。如果服務商同時要求 CNAME 和 TXT 驗證放在同一個子網域名稱下，就會衝突，此時需請服務商提供替代方案。

情況三：萬用字元

用 * 作為主機名稱，可以讓所有未特別指定的子網域都指向同一處。適合會動態產生大量子網域的系統（例如每個客戶一個網址的平台）。

但一般企業網站不建議使用——它會讓任意輸入的子網域都能開啟，容易被利用於釣魚或產生無意義的頁面被搜尋引擎收錄。

SSL 憑證怎麼處理

這是最常被忽略的一步。主網域的 SSL 憑證不會自動涵蓋子網域，子網域用 https 開啟會出現憑證錯誤警告。

三種處理方式：

• 為每個子網域各自申請憑證——子網域不多時最單純，多數主機面板都支援自動申請與續期
• 申請萬用字元憑證——一張涵蓋所有子網域，適合子網域較多的情況，但申請時通常需要以 DNS 方式驗證
• 由外部服務提供——若子網域是 CNAME 指向外部平台，憑證通常由該平台負責

另外請確認憑證的自動續期有正常運作。子網域的憑證過期是很常見的疏忽，因為平常沒人會去開那個網址。

三種常見用途與規劃建議

測試站

網站改版期間，新版通常先放在 test.example.com 或 dev.example.com 供客戶驗收。兩件事一定要做：

• 加上密碼保護——用主機的目錄密碼或程式端的登入限制，不要讓測試站公開可存取
• 阻擋搜尋引擎收錄——測試站被收錄後，會與正式站產生重複內容互相競爭，而且客戶搜尋公司名稱時可能搜到未完成的版本

阻擋方式建議兩層都做：robots.txt 設定不允許檢索，同時在頁面加上 noindex 標記。單靠 robots.txt 不保證不被收錄。

最重要的提醒：正式上線時務必解除這些設定。 測試期間的封鎖設定被帶到正式站，導致整個網站不被搜尋引擎收錄，是網站改版最常見也最嚴重的失誤，詳見網站改版或更換網域，SEO 排名怎麼保住。

購物站

如果購物功能是用外部平台，通常只能用子網域（CNAME 指向平台）。如果是自建，建議優先考慮放在子目錄而非子網域，權重集中效果較好。兩者的取捨詳見子網域、子目錄還是另外註冊網域。

活動網站

短期行銷活動常用 event.example.com 或 2026.example.com。規劃時請一併決定活動結束後怎麼處理：

• 直接刪除 → 產生 404，累積的連結與流量全部消失
• 301 轉向到主站相關頁面 → 建議做法
• 保留為封存頁面並加上活動已結束的說明 → 若內容仍有參考價值

命名建議

• 短、好念、語意明確——shop、blog、news、event 這類通用字最好
• 避免使用員工姓名或專案代號——人員異動後沒人知道那是什麼
• 測試站的名稱要一望即知——test、dev、staging，避免用 new、v2 這種日後會混淆的名字
• 不要用 www 以外的變體當主站——例如 web.example.com 當主網址，使用者不會這樣輸入

維護提醒

子網域開起來很容易，但每一個都是需要維護的資產。建議建立一份清單，記錄每個子網域的用途、指向何處、由誰負責、SSL 到期日。

已經廢棄的子網域請把 DNS 記錄刪除。 留著指向已經不存在的服務，可能被他人接管該服務位址後冒用您的子網域，這是實際存在的資安風險。

為什麼要用外部郵件服務

不少中小企業的公司信箱是附在虛擬主機方案裡的，等於「買網站空間送信箱」。這在早期沒什麼問題，但現在有幾個現實的限制：

• 空間小，信件累積幾年就滿
• 手機同步、多裝置使用體驗較差
• 共用主機 IP，容易受同一台主機上其他人的寄信行為影響而進黑名單
• 缺乏完整的防垃圾郵件與防釣魚機制
• 主機一旦出問題，網站與信箱同時停擺

把郵件搬到專門的服務（Google Workspace 或 Microsoft 365 是最常見的兩個選擇），可以讓網站與信箱互不影響——這一點在網站搬家或主機故障時特別有價值。

兩者怎麼選

對網站架設而言兩者沒有差別，DNS 設定的邏輯完全相同，只是填入的值不同。實際選擇請以團隊慣用的辦公軟體為主。

設定流程（兩者通用）

第一步：驗證網域所有權

服務商會要求您證明這個網域是您的，通常是在 DNS 加一筆指定的 TXT 記錄，或上傳一個檔案到網站根目錄。

TXT 驗證是比較單純的做法。驗證通過後這筆記錄請不要刪除，部分服務會定期重新檢查。

第二步：建立使用者帳號

在服務商後台建好所有要使用的信箱帳號。這一步要在改 MX 之前完成——否則 MX 改過去了，帳號還沒建，信件會直接被退。

第三步：搬移舊信件（如果需要）

兩家服務都提供從舊伺服器匯入信件的工具。建議在切換 MX 之前先做一次匯入，切換後再補做一次增量，可以把落差降到最低。

第四步：修改 MX 記錄

• 刪除所有舊的 MX 記錄
• 新增服務商提供的 MX 值，優先權數字照抄不要自行調整
• 切換前一兩天先把 MX 的 TTL 調低，加快生效速度

具體的 MX 值請以服務商後台的設定精靈當下顯示的為準。 這些值兩家都調整過，網路上找到的舊教學可能已經過期，照抄會設錯。

第五步：設定 SPF、DKIM、DMARC

• SPF——加入服務商指定的內容。若同時還有其他寄信來源（例如網站的表單通知信），必須合併在同一筆記錄裡
• DKIM——需在服務商後台先產生金鑰，再把提供的值加到 DNS，最後回後台按下啟用
• DMARC——先設為僅觀察模式

第六步：其他記錄

部分服務會要求額外的 CNAME 記錄以支援自動設定或行事曆等功能，依後台指示新增即可。

最容易出錯的五個地方

1. 舊 MX 沒刪乾淨——信件時而收得到時而收不到，最難查的問題
2. SPF 設了兩筆——原本主機的 SPF 留著，又加了一筆服務商的。結果是兩筆都失效
3. DKIM 只加了 DNS 沒回後台啟用——兩邊都要做，缺一不可
4. 帳號還沒建就改 MX——切換空窗期的信件全部退回
5. 忘記網站的表單通知信——網站是從主機寄信的，這個來源要一併納入 SPF

切換後的驗證

• 從外部信箱寄一封到公司信箱，確認收得到
• 用公司信箱寄一封到 Gmail，檢查是否進垃圾郵件匣
• 檢視收到信件的原始標頭，確認 SPF 與 DKIM 都顯示通過
• 從網站的聯絡表單送出一次，確認通知信正常且未進垃圾桶
• 手機與電腦的收信設定都測試一次

若出現異常，排查方式參考公司信箱收不到信或被當垃圾信怎麼查。

一個實務建議

不要把郵件搬遷和網站搬家排在同一天。 兩件事都牽涉 DNS，同時進行時一旦出問題，很難判斷是哪一邊造成的。建議至少間隔一週，先完成一項並確認穩定，再處理另一項。