不是每個靜態網站一上傳，就適合公開給整個網路。
客戶預覽可能還有臨時文案。作品集中的某個案例可能只想給特定招募方看。內部文件對團隊有用，但不應該出現在搜尋結果裡。上線頁也可能需要先讓相關方確認，再綁定正式網域或開始推廣。
這就是密碼保護有用的地方。它不是完整的身分系統，而是在靜態內容前面加一道共享密碼門，讓內容在被查看前多一層簡單控制。
密碼保護適合什麼情境
靜態網站常常會經過一個私密的中間階段。網站已經建置完成，檔案存在，連結也能打開，但訪問對象仍然需要控制。
| 情境 | 密碼門為什麼有用 |
|---|---|
| 客戶審閱 | 相關方可以在公開上線前檢查真實 URL。 |
| 內部文件 | 團隊可以分享靜態筆記、手冊或專案頁，而不是直接開放給所有人。 |
| 私密作品集 | 只把選定案例發給招募方、客戶或面試官，不必公開全部素材。 |
| 學生或團隊專案 | 審閱者能打開專案，同時團隊還可以決定哪些內容保留公開。 |
| 活動上線前檢查 | 在推廣前檢查文案、追蹤連結、素材和行動版面。 |
| PDF 或資料包 | 用一個靜態頁面把文件、檔案和參考資料放在同一個訪問步驟之後。 |
這裡的目標不是抵禦有意攻擊的人，而是避免作品在審閱、修正和批准過程中被意外公開傳播。
密碼門、noindex 和完整驗證的差異
這些工具解決的問題不同。混為一談會帶來錯誤預期。
| 工具 | 它能做什麼 | 它不能做什麼 |
|---|---|---|
| 密碼保護 | 在網站被提供前，用共享密碼阻止一般訪問。 | 不建立使用者帳號、角色、稽核記錄或 SSO。 |
noindex | 請求搜尋引擎不要把頁面顯示在搜尋結果裡。 | 不阻止知道 URL 的人打開頁面。 |
robots.txt | 向爬蟲公開說明某些路徑的抓取規則。 | 檔案本身是公開的，不應當作保護機制。 |
| 完整應用程式驗證 | 管理使用者、工作階段、權限和身分流程。 | 需要應用程式邏輯，而不只是靜態託管。 |
| 網路存取控制 | 依身分提供方、裝置、IP 或組織政策限制存取。 | 對多數客戶預覽來說過重。 |
Google 把 noindex 作為索引控制來說明。它適合讓頁面不出現在搜尋結果裡，但不是隱私邊界。Cloudflare Access 和 Vercel Deployment Protection 則在另一端，提供更強的應用程式或部署存取控制。簡單的密碼門位於中間。
保護整個靜態體驗，而不只是首頁
靜態網站不只是 index.html。
如果只有首頁被保護，但圖片、腳本、PDF 或深層連結仍然公開，預覽內容還是可能外流。實用的密碼保護應該放在整個發佈體驗前面，包括那些讓頁面真正有意義的檔案。
分享受保護連結前，建議檢查這些路徑：
| 路徑類型 | 檢查內容 |
|---|---|
| 首頁 | 第一次訪問會要求輸入密碼。 |
| 深層連結 | 專案頁、文件頁或活動子路徑同樣需要存取權限。 |
| 資源檔案 | 圖片、PDF、腳本和下載檔不會透過明顯直連暴露。 |
| 表單 | 如果存在表單，授權後仍能正常工作。 |
| 錯誤頁 | 404 或 fallback 頁面不會暴露敏感文案或檔名。 |
這對作品集和客戶專案尤其重要。如果未發佈截圖仍然能透過 /assets/client-redesign-final.png 打開，那麼首頁遮蔽的意義就很有限。
選擇合適的密碼工作流
共享密碼操作簡單，但仍然需要紀律。
| 情況 | 實用做法 |
|---|---|
| 一次短審閱 | 使用強共享密碼，並在審閱後更換。 |
| 多個客戶團隊 | 如果訪問對象不應重疊，使用不同專案或不同審閱連結。 |
| 連結被轉發太廣 | 更換密碼，只把新密碼發給目標審閱者。 |
| 專案正式公開 | 最終批准並上線網域後關閉密碼保護。 |
| 內容仍然敏感 | 公開頁面保留遮蔽版本，細節只分享給被批准的人。 |
不要給客戶預覽使用容易猜到的玩笑密碼。密碼應足夠長，並透過符合專案敏感度的管道分享。
密碼保護不夠用的地方
密碼保護有用，是因為它輕量。它的限制也來自這種輕量。
如果你需要以下能力，應使用真正的應用程式驗證模型：
- 依個人建立帳號或邀請。
- 不同訪問者有不同權限。
- 透過 Google Workspace、Microsoft Entra、Okta 等身分提供方做 SSO。
- 記錄誰看過什麼的稽核記錄。
- 法律、合約或合規層面的存取要求。
- 只撤銷某一個人的訪問，而不影響其他人。
- 敏感客戶資料、付款資料、健康資料或受監管記錄。
對於靜態預覽，共享密碼經常是合適的控制力度。對於客戶入口網站、內部系統或受監管流程，它就不夠了。
受保護靜態預覽的常見錯誤
多數問題不是大事故，而是小的營運失誤。
| 錯誤 | 更好的做法 |
|---|---|
| 保護啟用前就發出連結 | 先打開密碼門，再用隱私視窗測試。 |
| 忘記檢查深層連結 | 直接打開專案頁、文件頁、資源檔和 PDF。 |
| 一個密碼長期不變 | 在審閱、上線或意外轉發後更換密碼。 |
把 noindex 當隱私保護 | noindex 用於搜尋行為，不用於存取控制。 |
| 發佈了機密細節 | 上傳前遮蔽名稱、指標、截圖和內部路徑。 |
| 上線後忘記關閉密碼門 | 決定最終站點是公開、保護，還是拆成公開和私密版本。 |
受保護的預覽仍然需要像公開網站一樣做內容檢查。密碼能降低意外暴露，但不能讓粗心發佈變得安全。
如何放進靜態部署流程
密碼保護最好作為部署流程的一部分，而不是最後臨時補上。
一個實用流程是：
- 建置或匯出靜態網站。
- 上傳資料夾、ZIP、HTML 輸出、框架 build 產物、作品集或帶 PDF 的頁面。
- 分享預覽前啟用密碼保護。
- 把連結和密碼發給審閱者。
- 修正文案、檔案、行動版面和素材。
- 訪問對象變化時更換密碼。
- 最終發佈時決定移除或保留保護。
這樣審閱就接近真實網站。審閱者看到的是之後公開版本會使用的相同路由、資源和響應式行為。
DeployPages 如何處理這個情境
DeployPages 圍繞靜態發佈建構，所以密碼保護面向靜態預覽和私密分享，而不是後端驗證系統。
你可以發佈靜態資料夾、ZIP、HTML 專案、作品集、文件匯出、AI 生成網站或包含 PDF 資源的頁面，並在目前工作區方案包含該能力時，在專案控制中啟用密碼保護。訪客需要先輸入專案密碼，才能查看已發佈網站。同一個專案還可以使用 流量分析、自訂網域、即時回復 和 CLI 部署。
流程很直接：上傳網站，在審閱期加上密碼門，然後決定最終版本繼續私密，還是遷移到公開網域。
分享前檢查清單
發送受密碼保護的靜態網站前：
- 在隱私視窗打開連結，確認出現密碼頁面。
- 測試一個深層連結，不只測試首頁。
- 嘗試直接訪問重要 PDF、圖片、腳本和下載檔。
- 刪除機密名稱、內部指標、內部評論和草稿路徑。
- 使用強共享密碼，並保存在團隊能更換的位置。
- 如果內容敏感，連結和密碼分開分享。
- 決定何時移除、輪換或保留保護。
- 替換已審閱版本前保留回復路徑。
密碼保護不是為了讓靜態網站變複雜。它是為了讓作品在被評估、修正和批准的私密階段少一點風險。