讀完這一章，你會知道如何把 Lovable 專案從 preview（預覽） 變成可以交給真實使用者的 production（正式上線）website。你會理解 Publish 的快照模型、project（專案）access 和 website access 的差異、custom domain 和 branded workspace（工作區）URL 的取捨、DNS 和 SSL 的基本流程，以及發布前後應該跑哪些安全、SEO、金流、登入與整合檢查。
這章的重點不是「按下 Publish」。真正的目標是：
把上線變成可驗證、可回報、可更新、可收回的版本發布流程。
Lovable 讓上線變得很快，但越快的工具越需要清楚的發布紀律。你可以在幾分鐘內把 app 推到 live URL，也可以在幾分鐘內把未驗證的付款流程、錯誤的 SEO metadata（中繼資料）、未鎖好的 dashboard（儀表板） route 和壞掉的 OAuth redirect 一起推到 live。
正式上線不是結束。它是產品開始接受外部流量、搜尋引擎、付款、登入、客服、錯誤回報和資料責任的第一天。
很多 Lovable 新手會把三個狀態混在一起：
這三件事不是同一件事。
Preview（預覽） 是開發與審查環境。你用它和 Lovable Agent 溝通，檢查畫面，測試流程，請團隊回饋。
Publish 是把當下專案狀態部署到 live URL。使用者可以透過網址看到這個版本。
Production（正式上線） 是一組更高標準：有正確網域、正確 access policy、通過必要安全檢查、SEO metadata（中繼資料） 完整、第三方服務可用、金流測試完成、錯誤處理可接受、資料權限不外洩。
對 LaunchNote 來說，一個「可以 publish」的版本可能只是首頁能開、dashboard（儀表板） 能登入、pricing 看起來像樣。但一個「可以 production（正式上線）」的版本還需要：
Lovable 幫你把 deployment 門檻降得很低。這章要做的是把 release 標準拉回 production（正式上線）應有高度。
Lovable 的 Publish 可以用這個模型理解：
專案狀態
-> 在 Preview 中檢查
-> 發布快照
-> 正式網站
當你按下 Publish，Lovable 會部署目前專案的一個 snapshot。之後你在 editor 裡繼續修改，不會自動更新 live site。要讓 live site 看到新版本，你需要再次進入 Publish 並執行 Update。
這個快照模型很重要，因為它讓你可以把開發中的變更和 production（正式上線）使用者看到的版本分開。
你應該養成這個習慣：
編輯
預覽
測試
檢查掃描結果
發布或更新
對正式網站執行冒煙測試
記錄版本資訊
不要把 Publish 當成「完成了」。Publish 之後的 live smoke test 才是 release 的收尾。
Lovable 有兩種不同 access：
這兩者是獨立的。
常見誤解是：我把 project（專案）設成 Restricted，所以網站應該也不會公開。這不一定成立。Project（專案） access 管的是 builder workspace（工作區）裡的專案，不等於 live website 的訪問規則。
另一個常見誤解是：我把網站公開，所以別人可以看到我的 提示詞、source code 或 chat history。這也不成立。Publishing 只讓使用者拜訪已發布的網站，不會公開 editor、source code、chat 或 project（專案）。
你在上線前要明確回答：
誰可以編輯這個專案？
誰可以看到正式網站？
這個網站是公開產品、內部工具，還是客戶示範？
Free 和 Pro 的網站通常是 anyone with link 可以拜訪。Business 和 Enterprise 可以把 website access 限制在 workspace（工作區）或特定成員與群組。這會影響你能不能用 Lovable 直接發布內部工具。
進入正式上線前，請先確認這些條件：
如果上面有一半還答不出來，先不要急著按 Publish。請 Lovable 幫你整理 readiness report。
提示詞：
請檢查 LaunchNote 是否已具備正式發布條件。
背景：
- LaunchNote 是為小型軟體團隊設計的 SaaS。
- 它有公開行銷頁面、公開更新日誌頁面、身分驗證、儀表板、Paddle 帳務、Resend 信件和 AI 摘要功能。
- 我們正準備發布到自訂網域。
請檢查：
- 建置錯誤。
- 身分驗證和路由保護。
- Supabase RLS 假設。
- Paddle 結帳和 Webhook 狀態。
- 信件發送狀態。
- AI 功能的失敗備援行為。
- 公開頁面的 SEO 中繼資料。
- Sitemap 和 robots 設定假設。
- 行動裝置易用性。
- 明顯的安全風險。
請回傳：
- 發布前的阻礙。
- 發布前的重要修正。
- 可接受於發布後處理的改善。
- 建議的正式網站冒煙測試檢查清單。
圖 17-1：Publish 流程會把目前專案快照部署到 live URL，發布前應先完成安全與內容檢查。
Lovable 的 Publish dialog 不只是部署按鈕。它也是上線前最後一個設定與檢查入口。
第一次發布時，請不要直接從聊天裡叫 Agent publish。聊天發布很方便，但正式 production（正式上線）release 需要你親自看過設定。
你應該在 Publish dialog 裡確認：
Website address 預設會是類似：
project-name.lovable.app
這適合 demo、內部測試、短期分享。正式產品建議使用 custom domain。
Website info 會影響：
不要讓 production（正式上線）site 帶著預設 favicon、模糊截圖或不精準 description 上線。這會讓社群分享、搜尋結果和第一印象都顯得未完成。
提示詞：
請準備 LaunchNote 的發布設定。
請提出：
- 網站標題。
- 不超過 155 個字元的 Meta Description。
- Open Graph 標題。
- Open Graph 說明。
- 建議的分享圖片內容。
- Favicon 方向。
- 哪些頁面應公開並可建立索引。
- 哪些頁面應設為私密並排除在 Sitemap 之外。
請使用這段定位：
LaunchNote 協助小型軟體團隊發布清楚的產品更新和更新日誌。
Lovable 在 Publish flow 裡會自動跑基本安全掃描。這個掃描會檢查常見資料庫安全問題，例如 RLS（Row Level Security，列層級安全） 和 schema access 風險。
如果 workspace（工作區）owner 或 admin 啟用了 publishing control，critical findings 可能會直接阻止發布。這不是麻煩，而是 production（正式上線）guardrail。
你要把 findings 分成三類：
提示詞：
請檢查 LaunchNote 的安全掃描發現。
把每個發現分類為：
- 發布前阻礙。
- 上線前必須修正。
- 上線後追蹤。
針對每個阻礙，請說明：
- 可能發生的問題。
- 受影響的使用者資料或商業流程。
- 最小且安全的修正方式。
- 發布前如何在 Preview 驗證修正。
如果 Basic scan 通過，你可以視情況跑 Deep scan。Deep scan 比較適合有會員、資料庫、付款、內部管理功能的 app。LaunchNote 有 auth（驗證）、subscription、team data 和 AI 功能，因此正式上線前值得跑一次。
網站訪問權限要配合產品階段。
LaunchNote 的 marketing site、pricing、public changelog pages 應該公開。
設定方向：
專案存取權限：Restricted 或 Workspace
網站存取權限：Anyone
這代表只有你或團隊可以編輯專案，但任何人可以拜訪公開網站。
如果你做的是客戶 demo，可以讓 project（專案）access 限制在團隊，但 website access 仍然 anyone with link。這樣客戶不用加入你的 workspace（工作區）也能看 demo。
風險是連結可能被轉傳。不要在 demo 裡放真實敏感資料。
如果 app 是內部工具，而且你的方案支援 workspace（工作區）-restricted website access，才適合直接在 Lovable 上限制 live website 只能給 workspace（工作區）members。
如果方案不支援限制 website access，你不能只靠 project（專案）restricted 來保護 live app。你需要 app 內登入與權限，也可能需要 Business 或 Enterprise 的發布權限控制。
提示詞：
請協助我選擇這個應用程式的發布存取設定。
應用程式類型：
- 公開 SaaS 行銷網站。
- 需要身分驗證的儀表板。
- 付費訂閱功能。
- 公開更新日誌頁面。
請建議：
- 專案存取權限。
- 網站存取權限。
- 哪些路由必須要求應用程式層級身分驗證。
- 哪些路由可以公開。
- 哪些路由不應建立索引。
- 有人轉傳正式 URL 時的風險。
圖 17-2：Custom domain 讓正式產品使用自己的品牌網址，並需等待 DNS 與憑證狀態完成。
lovable.app 網址很適合快速分享，但正式產品應該使用 custom domain。
原因很簡單：
對 LaunchNote 來說，你可以先用：
launchnote.example
www.launchnote.example
app.launchnote.example
常見配置：
www 或 root domain 放 marketing site。app 放登入後 dashboard（儀表板）。docs 或 help 放文件與支援內容。status 放狀態頁。不過第一版不要過度拆。Lovable 專案通常先用一個 custom domain 承載 public pages 和 authenticated app，再透過 routes 區分內容。
Lovable 文件裡有三種網域路徑：
你要先決定你想讓 Lovable 管多少事。
這是最簡單的路徑。
適合：
透過 Lovable 買的 domain 屬於 workspace（工作區），不是單一 project（專案）。這個設計很合理，因為同一個 domain 可能未來會接到不同 projects 或子網域。
Lovable 會處理註冊、DNS 記錄、SSL，並可協助把 root 和 www 一起設好。你仍然要填寫註冊資料、確認 auto-renew、保管 workspace（工作區）權限。
如果你已經在其他 registrar 買了 domain，就走 connect。
你需要：
Lovable 可能提供自動化設定，也可以手動複製 DNS records。手動設定時，不同 DNS provider 對 root host 的寫法可能不同，有的是 @，有的是空白，有的是完整 domain。
不要靠猜。設定後回 Lovable 檢查 domain status。
圖 17-3：網域轉移與單純連接網域是不同作業，執行前應確認註冊商、DNS 與服務中斷風險。
Transfer 的意思是 Lovable 會變成 registrar。這不是單純把 DNS 指過來。
適合：
常見條件包含：
轉移通常需要幾天。轉移期間，domain 會繼續使用原本 DNS，完成後要檢查所有 records 是否保留正確。這一步對已經有 email、網站、驗證記錄的 domain 特別重要。
提示詞：
請協助我為 LaunchNote 選擇網域設定方式。
選項：
- 透過 Lovable 購買新網域。
- 連接其他服務商的既有網域。
- 把既有網域轉移到 Lovable。
背景：
- 這是一個新的 SaaS。
- 我們需要正式環境自訂網域。
- 我們會使用 Paddle、Resend、Supabase Auth 和 Google Search Console。
- 我們希望避免破壞信件或 DNS 驗證紀錄。
請回傳：
- 建議方式。
- 原因。
- 設定檢查清單。
- 風險。
- 如何在上線前驗證網域已準備完成。
Domain setup 不是即時魔法。DNS propagation 和 SSL issuance 都需要時間。
你會看到類似這些狀態：
正式上線時，你要等 domain 變成 Live，不要只看 registrar 那邊顯示已設定。
檢查清單：
www 是否 live。Lovable hosting 的 primary domain redirect 是可調整的 temporary redirect。這對早期產品很實用，因為你可能會改 primary domain。不要把它當成完整 SEO migration 工具。如果你需要複雜永久轉址策略，必須另外規劃。
Business 和 Enterprise 可以設定 branded workspace（工作區）URLs，格式類似：
https://app-name.workspace-subdomain.lovable.app
它的用途不是取代 custom domain，而是讓 workspace（工作區）裡的已發布 apps 使用一致品牌化的 Lovable URL。
適合：
Custom domain 仍然優先於 branded workspace（工作區）URL。對公開產品、SEO 和長期品牌，請用 custom domain。對內部或多專案展示，branded workspace（工作區）URL 很方便。
不要把 branded workspace（工作區）URL 當成 SEO 主域名。上一章已經說過，長期 search presence 應該建立在你控制的 custom domain 上。
Publish 成功只代表部署完成，不代表產品可用。
你需要在 live URL 上重新測一次最重要流程。不要只測 preview（預覽），因為 production（正式上線）domain、OAuth redirect、cookie、CORS、email link、payment return URL 都可能和 preview（預覽） 不同。
LaunchNote 的 live smoke test：
提示詞：
請為 LaunchNote 建立發布後的正式環境冒煙測試檢查清單。
請包含：
- 公開頁面。
- 身分驗證。
- 儀表板路由保護。
- Paddle 結帳。
- Webhook 訂閱更新。
- Resend 交易型信件。
- AI 摘要功能。
- 行動版版面。
- SEO 基礎設定。
- 錯誤狀態。
請用檢查清單格式回傳，並包含：
- 步驟。
- 預期結果。
- 失敗代表的問題。
- 是否阻擋上線。
有些 SEO 檢查必須在 live published site 上才準確，例如 indexing、performance、accessibility、AI-search readiness、Google Search Console setup。
因此流程應該是：
發布
連接或確認自訂網域
執行正式環境冒煙測試
執行 SEO 審查
驗證 Google Search Console
提交 Sitemap
記錄發現
修正高影響問題
發布更新
再次執行審查
如果你先用 lovable.app 發布，之後才接 custom domain，請在 domain live 之後再跑一次 SEO review。因為 canonical、sitemap、OG URL、GSC property 都可能因 host 改變而需要重新檢查。
不要把 sitemap 提交到錯的 domain。不要讓 search results 指向你短期使用的 staging-like URL。
Lovable 的好處是改很快。風險也是改很快。
當 live site 已經有人使用後，你每次 Update 都應該有 release 節奏：
1. 定義變更範圍。
2. 請 Lovable 檢查受影響的流程。
3. 在 Preview 中測試。
4. 審查安全或 SEO 影響。
5. 發布更新。
6. 對正式環境執行冒煙測試。
7. 記錄變更內容。
對 LaunchNote 來說，如果你改了 billing logic，就不能只測畫面。你要測 Paddle checkout（結帳）、subscription status、feature gating、webhook（事件回呼）retry、customer email。
如果你改了 auth（驗證），就要測 login、logout、redirect、protected routes、session refresh。
如果你改了 public page templates，就要測 SEO metadata（中繼資料）、canonical、sitemap、OG image、mobile layout。
提示詞：
我們正在準備 LaunchNote 的正式環境更新。
變更範圍：
- 更新價格方案頁文案。
- 變更 Paddle 方案對應。
- 新增 AI 摘要使用量限制。
請建立：
- Preview 測試計畫。
- 安全考量。
- 帳務考量。
- SEO 考量。
- 發布更新後的正式環境冒煙測試。
- 發生問題時的回復或緩解計畫。
Lovable 可以 unpublish 專案。Unpublish 之後，live website 會不可用，但 project（專案）本身仍然存在。
這在一些情況有用：
但 unpublish 不是理想的 rollback。它會讓整個網站下線。對公開 SaaS 來說，這是最後手段。
更好的 release discipline 是：
提示詞：
請協助我判斷是否要取消發布 LaunchNote。
事故：
在這裡描述問題。
請評估：
- 使用者影響。
- 資料暴露風險。
- 是否能快速修正並發布更新。
- 是否有必要取消發布。
- 服務無法使用時應向使用者顯示的訊息。
- 事故後追蹤檢查清單。
Lovable Cloud 已經提供 production（正式上線）hosting、custom domains、automatic SSL、preview（預覽） environments、AI debugging、managed auth（驗證）、database、file storage、安全掃描與合規基礎。多數團隊不需要一開始就搬出去。
外部部署適合有明確限制的團隊：
如果你要把 production（正式上線）frontend（前端）放到外部平台，Lovable 文件的前提是先連 GitHub。外部平台會從 GitHub build 和 deploy。
常見設定：
建置指令：npm run build
輸出目錄：dist
Node 版本：22
如果 app 使用 Lovable Cloud / Supabase backend（後端），外部平台通常需要設定：
VITE_SUPABASE_URL
VITE_SUPABASE_PUBLISHABLE_KEY
VITE_SUPABASE_PROJECT_ID
你還要處理：
重點是：一旦 production（正式上線）frontend（前端）不在 Lovable Cloud 上，Lovable 就不能替你監控或 debug 那個 production（正式上線）infrastructure。
所以對本書主線，LaunchNote 預設留在 Lovable Cloud。只有在真實限制出現時，才把外部部署當成架構決策。
這個練習把前面章節的 LaunchNote 推到 production（正式上線）-ready release。
讓 LaunchNote 使用 custom domain 上線，並完成安全、SEO、auth（驗證）、Paddle、email、AI 的 live smoke test。
提示詞：
請為 LaunchNote 建立正式上線報告。
請包含：
- 目前發布狀態。
- 網域狀態。
- 安全掃描摘要。
- SEO 審查摘要。
- 身分驗證準備狀態。
- Paddle 準備狀態。
- 信件準備狀態。
- AI 功能準備狀態。
- 行動版準備狀態。
- 上線阻礙。
- 上線檢查清單。
請 Lovable 先修 blocker，不要一次混進大量優化。
提示詞：
只修正正式上線報告中的上線阻礙。
規則：
- 不要重新設計無關的使用者介面。
- 除非為了解決阻礙，否則不要修改價格方案文案。
- 未說明原因前，不要修改資料庫 Schema。
- 保留既有路由。
- 變更後，精確列出修改內容和驗證方式。
準備：
提示詞：
請檢查 LaunchNote 的發布網站資訊。
請確認：
- 標題。
- 說明。
- Favicon。
- Open Graph 圖片。
- 所有公開頁面是否有路由專屬中繼資料。
- 私密路由是否排除在搜尋之外。
請建議上線用的最終值。
等 domain status 變成 Live。確認 HTTPS 正常。再進行 live smoke test。
請 Lovable 幫你產生結果紀錄：
請摘要 LaunchNote 的正式環境冒煙測試結果。
針對每個已測試區域：
- 通過。
- 失敗。
- 未測試。
- 證據或觀察。
- 必要的後續處理。
區域：
- 公開頁面。
- 身分驗證。
- 儀表板保護。
- Paddle 帳務。
- 信件。
- AI 摘要。
- SEO 和 GSC。
- 行動版。
- 錯誤處理。
Preview（預覽） 不等於 live domain。金流回跳、OAuth redirect、cookie、GSC、SEO、email links 都可能在 live domain 才暴露問題。
你在 editor 裡修好了，不代表 live site 已更新。要按 Publish Update，然後在 live site 重測。
Project（專案） restricted 不等於 live website restricted。上線前要分別檢查。
lovable.app 當長期 SEO domain正式產品應該使用 custom domain，並把 sitemap、canonical、GSC 都集中在那個 domain。
DNS propagation、ownership verification 和 SSL 都需要時間。請等 Lovable 顯示 Live，並用 browser 實際確認 HTTPS。
Paddle、OAuth provider、Resend、GSC 都可能需要正式 domain 設定。只改 Lovable domain 不夠。
部署成功不是流程成功。使用者只在乎 live site 能不能完成任務。
Unpublish 會讓網站不可用。它是緊急停止，不是日常 release 策略。
www 或主要子網域是否 Live？讀完本章後，建議用自己的專案情境繼續追問 Lovable 或本書作者：
嗨！我是 Wolke，曾任 Google Developer Expert（GDE，2019–2023） 與 LINE API Expert。我熱衷於研究 AI Agent、n8n 自動化工作流及全端開發架構，致力於將 AI 技術轉化為實際的生產力工具。
如果你喜歡這篇文章，歡迎透過以下方式與我交流，獲取更多技術實戰內容：
📚 技術著作：《實用的 Gemini API 開發點子書》，帶你運用 Gemini App、Google AI Studio、Gemini CLI 與 Antigravity IDE，打造 AI Agent 與實用產品。
📝 技術部落格：歡迎追蹤我的 Medium，我會持續分享 Agentic Automation、架構設計與實際開發的踩坑心得。
🎤 技術講座：我持續受邀至技術社群及研討會，分享 AI Agent、自動化工作流、DevOps 與全端開發實戰。曾於 2026 年 6 月 26 日的 DevOpsDays Taipei 2026 主講「不再只是寫腳本！讓 AI 代理人成為你的 SRE 最佳夥伴」工作坊。
如果你的企業、社群或學校正在尋找相關主題講者，歡迎私訊與我聯繫、洽談講座合作！
🎁 免費送 Lovable 額度給讀者！
我每個月會開放 10 個名額，每人 50 點 Lovable 額度，讓大家實際動手打造自己的網站或 App。
參加方式：
確認後，我會邀請你加入 Lovable workspace 並設定 50 點額度。名額有限，送完為止！
iThome鐵人賽
看影片追技術