完善網站與部署上線
補齊網站頁面和正式環境設定，部署 PDF Worker 與主站，並完成上線驗證。
前面已完成核心功能、額度限制和付款串接。這篇會補齊頁面與正式環境設定、部署服務，並在正式網域驗證主要流程。
完善頁面與元件
目前網站基本功能已完成，接著要調整頁面與元件，讓網站更美觀、專業。
這部分取決於個人審美和需求。Saavo 已提供大部分頁面與元件，依需要調整即可。多數時候，可以請 AI 改善外觀，再由人工審查確認。
以下是需要調整的頁面與內容：
- 首頁
- Pricing 頁面
- 關於頁面
- Terms、Privacy、Cookie 頁面
- Affiliate 頁面
- 部落格內容
- 文件內容
- 使用者後台的產品頁面
- public 目錄中的圖示、OG 圖片、favicon 等資源
- llms.txt 檔案內容
完善頁面後，如果新增或修改了元件，最好再使用 saavo-localize-components 處理國際化，確保元件支援多語言。
除了頁面內容，也要補齊每個頁面的 SEO 資訊。可以請 AI 依頁面內容，使用 useSeoMeta 和 useSchemaOrg 等 hook 函式，產生對應的 SEO 內容。
發布前準備
前面只是完成了功能，正式上線前還差最後一步：將開發階段的測試設定換成正式環境設定。這裡最容易出問題的通常不是程式碼，而是網域、回呼網址或金鑰填錯。
上一篇已設定 Stripe，剩下的服務建議依以下順序處理。詳細操作位於選用服務章節，這裡只說明 WebpageToPDF 上線前的工作。
決定正式網域
先決定網站正式使用的網域。Worker 部署後，再依網域設定處理解析與綁定。workers.dev 網址適合暫時測試，正式上線仍應使用自己的網域。
最好先確定網域，因為後面的 Turnstile 和 OAuth 都會用到。WebpageToPDF 使用 webpagetopdf.dev，以下回呼網址也以它為例。如果你的專案使用其他網域，請全部替換成自己的。
設定 Resend
註冊驗證、密碼重設和安全通知都需要透過電子郵件寄送。依設定 Resend完成寄件網域驗證、建立 API Key，並將 RESEND_API_KEY、寄件者地址和客服信箱寫入正式環境設定。
部署後，最好使用實際信箱完整測試一次註冊和密碼重設。能寄出郵件只是第一步，還需檢查寄件者名稱、內文連結，以及是否被當成垃圾郵件攔截。
設定 Turnstile
Turnstile 用來攔截大量註冊和自動化請求。依設定 Turnstile為正式網域建立網站設定，並在正式環境填入 CLOUDFLARE_TURNSTILE_SITE_KEY 和 CLOUDFLARE_TURNSTILE_SECRET_KEY。
本機開發的測試金鑰只適合驗證流程，無法提供實際防護，上線前務必換成正式金鑰。
設定 GitHub OAuth
如需支援 GitHub 登入，依設定 GitHub OAuth建立 OAuth App，將正式回呼網址設為 https://webpagetopdf.dev/api/auth/oauth2/github。再將取得的 GITHUB_CLIENT_ID 和 GITHUB_CLIENT_SECRET 寫入正式環境設定。
部署後，分別使用新帳號和已註冊帳號登入一次，確認不會重複建立使用者，也不會因電子郵件地址相同而登入失敗。
設定 Google OAuth
如需支援 Google 登入，依設定 Google OAuth建立 Web 應用程式用戶端。授權來源填入 https://webpagetopdf.dev，回呼網址填入 https://webpagetopdf.dev/api/auth/oauth2/google，再將 GOOGLE_CLIENT_ID 和 GOOGLE_CLIENT_SECRET 寫入正式環境設定。
如果也啟用了 Google One Tap，部署後需在正式網域另外測試。瀏覽器隱私權設定、第三方 Cookie 和 HTTPS 都可能影響顯示，不能只檢查一般 Google 登入是否正常。
整理業務資源與正式環境設定
以上金鑰和網址都應寫入 .env.production，不要提交到 Git，也不要只在 Cloudflare 管理介面手動修改。先準備齊全，部署時再統一同步到 Cloudflare。
WebpageToPDF 另有一個獨立的 PDF Worker。部署前，需整理好它的部署指令、Service Binding 名稱和環境變數。通用的 Saavo 部署流程無法自動判斷這部分業務相依服務，後續部署時需要另外處理。
最後，分別以匿名、註冊和 Pro 使用者身分完成主要功能流程，確認三種轉換模式、免費體驗、額度扣除和付費權限，都符合前面的產品設計。轉換失敗時是否扣除額度，也要依既定規則檢查一次。
到這裡，產品功能與上線設定已準備完成，接著開始部署。
部署上線
前面已完成 Stripe、Resend、Turnstile 和第三方登入設定，對應的正式金鑰也已寫入 .env.production。這裡不再重新建立商品、Webhook 或 OAuth 應用程式，只處理尚未完成的 Cloudflare 部署。
部署 PDF Worker
WebpageToPDF 使用獨立的 PDF Worker，Saavo 部署指令碼不會自動建立這項業務服務。如果尚未部署，請先發布到同一個 Cloudflare 帳戶，再確認主專案的 Service Binding 名稱與實際 Worker 一致。如果前面移植功能時已部署，檢查無誤後即可略過。
確認 Cloudflare 帳號
先在專案目錄檢查 Wrangler 目前登入的帳號：
npx wrangler whoami如果尚未登入，或顯示的不是準備部署 WebpageToPDF 的帳號，再執行：
npx wrangler login正式網域、R2 和剛才的 PDF Worker，最好都放在這個使用者可存取的同一個帳戶，後續建立資源與繫結服務會方便許多。
完成首次部署
確認帳號後，執行：
npm run deploy:init專案在本機開發時只執行過 saavo:init，尚未建立遠端資源，因此這裡使用 deploy:init。指令碼會讀取現有 .env.production，補齊缺少的部署設定，再建立並繫結 D1、KV、R2 和 Queue、初始化遠端資料庫、部署 Worker，最後檢查網站是否能存取。
已填入的 Resend、Turnstile 和 Stripe 設定，不需要重新輸入，依終端機提示確認即可。也不要到 Cloudflare 後台手動建立另一組同名資源。完整的終端機操作，可參考首次部署。
首次部署使用 workers.dev 網址。終端機提示成功後，先開啟該網址檢查首頁，確認沒有 500 錯誤，再綁定正式網域。PDF 轉換等完整業務流程，可以等網域切換後再測試。
切換到正式網域
WebpageToPDF 的正式網址是 https://webpagetopdf.dev，執行以下指令切換：
npm run domain:set -- https://webpagetopdf.dev指令會更新正式環境的網站網址，替 Worker 加入 Custom Domain，並重新驗證與部署。執行前，請確認 webpagetopdf.dev 已加入目前的 Cloudflare 帳戶，詳細步驟可參考網域設定。
核對第三方服務
網域生效後，再次檢查各平台的正式網址：
| 服務 | 正式網址或主機名稱 |
|---|---|
| Stripe Webhook | https://webpagetopdf.dev/api/webhooks/stripe |
| GitHub OAuth | https://webpagetopdf.dev/api/auth/oauth2/github |
| Google OAuth | https://webpagetopdf.dev/api/auth/oauth2/google |
| Turnstile | webpagetopdf.dev |
這些內容前面已設定，這裡只核對，不要重複建立 Stripe Webhook 或 OAuth 應用程式。如果修改了 .env.production 中的金鑰，再執行一次：
npm run deploy:update如果只修改 GitHub、Google 或 Stripe 後台的回呼網址，沒有更動專案程式碼和環境變數，就不需要為此重新部署。
上線驗證
最後，在正式網域完成主要流程：
- 使用新的電子郵件地址，完成註冊、電子郵件驗證、登入和密碼重設。
- 分別測試 GitHub 和 Google 登入，如果啟用 Google One Tap，也一併檢查。
- 以匿名、註冊和 Pro 使用者測試三種 PDF 轉換模式，確認額度扣除與權限限制符合前面的設計。
- 確認已在 Stripe 測試模式完成購買、Webhook 回呼和使用權益授予。若需在正式模式驗證，應使用經允許的小額商品完成交易，再依流程退款。
- 登入管理後台，檢查使用者、訂單、工作記錄，以及 Queue 是否異常。
更完整的項目可參考上線驗證。這些流程都正常後，就可以正式開放 WebpageToPDF 給使用者。
日後修改程式碼或正式環境設定，直接使用 npm run deploy:update 更新，不要在同一個專案重複執行 deploy:init。上線後的記錄、排程工作和資料備份，可繼續參考發布後的檢查事項。
本篇檢查
完成上線驗證後，就走完本教學的產品開發流程。後續可以在這個基礎上持續改進功能。