前面幾篇 Codex 筆記，我一路從 Product Input、Brand DNA、Page Plan、多版本 Strategy、圖片素材，到 Customer-facing Copy、Internal Notes、LOCKED，一層一層把銷售頁生成器拆開來看。
做到這裡，頁面其實已經差不多完成了。
但還有最後一個非常現實的問題：做好的頁面，要怎麼真的放到網站上？
因為 Codex 在專案裡顯示得再漂亮，如果只有我自己在電腦裡看得到，那它還不算真正的網站。
最後還是得把：HTML、CSS、圖片、assets、ZIP 整理好，再放到主機。
而我這一次的做法，不是把頁面塞進 WordPress。
我想做的是：獨立的靜態銷售頁。
所以我最後走的是：Codex → ZIP → cPanel → 前台網址。
而且這次真正成功上線之後，我才發現，這件事其實沒有我以前想像得那麼可怕。
只要先搞懂幾個核心概念：
- index.html 是什麼？
- assets 是什麼？
- CSS 要放哪裡？
- ZIP 裡面應該長什麼樣子？
- 為什麼不能多包一層資料夾？
- cPanel 解壓之後，首頁到底去哪裡找？
這些搞懂之後，其實整個部署流程就很清楚了。
許多人最怕的，其實就是「網站上線」這四個字
因為「做網頁」和「把網頁上線」，在我以前的認知裡，是兩件完全不同的事情。
做網頁還可以交給設計師。
可是只要講到：主機、FTP、DNS、路徑、根目錄、index.html，許多人的腦袋就會自動把它歸到：「工程師的世界。」
但這一次因為我本來就只想做靜態銷售頁，事情反而簡單很多。
我不需要先建立 WordPress、不需要資料庫、不需要安裝外掛、不需要主題，只要頁面的檔案完整，主機能讀，就可以直接開。
這就是靜態頁面讓我開始比較有信心的地方。
第一個要先搞懂：index.html 就是這張頁面的入口
現在把 index.html 理解成：這個網站資料夾的首頁。
例如我今天把網站放在：/public_html/dosha-sunscreen/
如果這個資料夾裡面有：index.html
那麼我打開對應網址時，伺服器通常就會自動讀這個檔案。
也就是說，網址不一定要打成：https://example.com/dosha-sunscreen/index.html
通常直接：https://example.com/dosha-sunscreen/ 就可以看到。
可以理解成：index.html 就像這個資料夾的大門。
只要大門放對地方，網址一進來，就知道要先開哪一頁。
那 styles.css 是什麼？
如果 index.html 是房子的結構，那 CSS 就很像：裝潢與視覺規則。
HTML 決定：哪裡是標題、哪裡是圖片、哪裡是按鈕、哪裡是 FAQ。
CSS 則決定：字多大、間距多少、背景什麼顏色、手機版怎麼排、按鈕長什麼樣子、圖片比例怎麼顯示。
所以如果今天 HTML 有上傳，但 CSS 路徑壞了，會出現一個很經典的狀況：內容還在，但整張網站像完全沒設計過。
這不是 HTML 壞掉。通常是樣式檔沒有正確讀到。
assets 又是什麼？
上一篇我們已經談過圖片。最後真正拿來給網站使用的圖片，通常會整理進：assets/
例如：
assets/
├── product-main.jpg
├── lifestyle-01.jpg
├── texture.jpg
└── hero-bg.jpg
有些專案也可能把：圖片、字型、icon、script 再往下分類。
例如：
assets/
├── images/
├── icons/
└── js/
這都可以。重點不是一定要長一模一樣。
而是：HTML 裡面的路徑，必須和實際檔案位置一致。
最基本的靜態銷售頁結構，可以先長這樣
如果是很單純的一頁式銷售頁，我現在會先把它想成：
dosha-sunscreen/
│
├── index.html
├── styles.css
└── assets/
├── product-main.jpg
├── lifestyle.jpg
└── texture.jpg
這個結構其實已經可以上線。
如果還有 JavaScript，再多一個：script.js 就可以。
所以不用一看到 Codex 專案裡一堆文件，就以為全部都要一起丟到網站。
真正前台網站需要的，通常只是最後輸出的那一包。
工作文件和「真正上線檔案」不要混在一起
這是前面幾篇一路累積下來很重要的觀念。
像：Product Input、Brand DNA、Page Plan、Internal Notes、Strategy 文件，這些都是工作過程的重要資料。
但消費者進網站，不需要讀這些檔案。真正上線時，比較像是把工作成果整理成：
dist/
├── index.html
├── styles.css
└── assets/
也就是我後來會特別把：工作區 和：部署區 分開。
我現在最喜歡的概念：dist 就是「準備上線的成品箱」
很多專案最後會有一個類似：dist/ 的資料夾。
我現在會把它理解成：這裡面的東西，就是準備搬去主機的最終成品。
不再是原始資料、不再是測試筆記、不再是 Prompt，而是前台真的需要的東西。
例如：
dist/
├── index.html
├── styles.css
└── assets/
├── product-main.jpg
├── product-packaging.jpg
└── lifestyle.jpg
只要這裡可以獨立運作，部署就簡單很多。
下一步：把成品打包成 ZIP
這一步其實就是為了方便上傳。
如果網站有二、三十個檔案，一個一個上傳當然也可以，但很麻煩。
所以最簡單就是：整包壓成 ZIP。
例如：dosha-sunscreen-v01.zip 然後一次丟到 cPanel。
但是 ZIP 有一個超級重要的細節
這也是我覺得最容易出錯的地方之一。
假設我要把頁面放進：/public_html/dosha-sunscreen/
我希望 ZIP 解壓後，直接變成：
/public_html/dosha-sunscreen/
├── index.html
├── styles.css
└── assets/
這樣最乾淨。
可是如果 ZIP 裡面又包了一層：dosha-sunscreen-v01/
那解壓之後會變成：
/public_html/dosha-sunscreen/
└── dosha-sunscreen-v01/
├── index.html
├── styles.css
└── assets/
這時候網址：https://example.com/dosha-sunscreen/ 就可能找不到 index.html。
因為真正的首頁被藏在下一層。
特別檢查：ZIP 打開後，第一層是不是 index.html
這是一個我現在一定會做的檢查。下載 ZIP 之後，不要急著上傳。
先打開看。我希望看到的是：
index.html
styles.css
assets/
而不是：
某某資料夾/
index.html
styles.css
assets/
如果是後者，就代表多包了一層。這時可以重新打包，或上傳後再把裡面的檔案搬出來。
我的部署流程：先進 cPanel 的 File Manager
真正開始上線時，我這次使用的是 cPanel。
進入 cPanel 之後，先找：File Manager／檔案管理員。
這裡可以把它理解成：主機版的 Windows 檔案總管。
你會看到一堆資料夾。
如果是主要網站，常見會有：public_html
如果你已經建立好子網域或子資料夾，實際路徑會依主機設定不同。
所以這一步我現在不會亂猜。
我會先確認：這個網址目前對應到哪個 Document Root。
Document Root 是什麼？
我現在會把 Document Root 理解成：這個網址真正去找檔案的資料夾。
例如某個子站：sale.example.com
可能指向：/public_html/sale/
那我要上傳的 index.html，就應該放進：/public_html/sale/
而不是看到 public_html 就全部亂丟。
這也是為什麼：上傳前一定要先知道自己現在在哪個資料夾。
接著就是 Upload ZIP
進到正確資料夾後，我會使用 cPanel 的 Upload 功能，把 ZIP 上傳。
例如：dosha-sunscreen-v01.zip
上傳完成之後，再回到 File Manager。
找到 ZIP。然後選：Extract。解壓。
這一步完成之後，真正的 HTML、CSS、assets 才會出現在主機裡。
解壓完第一件事：不是立刻看漂亮不漂亮，而是先看結構
我現在會先看：
index.html
styles.css
assets/
是不是就在目前資料夾。
如果 index.html 在下一層，我就先處理資料夾結構。因為首頁位置都錯了，再怎麼重新整理瀏覽器都沒用。
然後才開網址測試
如果資料夾沒問題，就可以直接開實際網址。
第一次看到頁面真的從主機跑出來，那個感覺其實很奇妙。
因為前一刻它還只是一堆：HTML、CSS、圖片、ZIP。
下一刻就變成：一個任何人都可以打開的網頁。
我這次第一次成功部署 Tina-Sales-Page-Generator 的輸出時，就是真的到這一步才有：「喔，原來這就是上線！」的感覺。
上線後，第一輪我會檢查哪幾件事？
我現在不會只看：「首頁有沒有出現？」，而是至少會檢查以下幾件事情。
1. 圖片有沒有正常顯示？
如果文字有出現，圖片全部不見，通常第一個先看：assets 路徑。
例如 HTML 裡寫：<img src="assets/product-main.jpg">
那主機裡就真的必須存在：assets/product-main.jpg
2. CSS 有沒有正常讀取？
如果畫面突然變成：白底、字全部靠左、按鈕沒樣式、Section 全部黏在一起。
很可能就是 CSS 沒讀到。
例如：<link rel="stylesheet" href="styles.css">
那 styles.css 就必須和 index.html 在對應位置。
3. 手機版有沒有跑掉？
桌機版正常，不代表手機正常。所以我一定會再用手機，或瀏覽器縮窄畫面看。
特別檢查：
-
-
- 標題有沒有爆版
- 圖片有沒有超出螢幕
- 按鈕是不是太小
- 左右排版有沒有正確變成上下
- FAQ 能不能正常閱讀
-
4. CTA 連結有沒有真的能點？
這個很容易忘。畫面有「立即購買」，不代表網址已經接好。
如果 HTML 還是：href="#" 按了當然不會去哪裡。
所以真正上線前，要確認 CTA 的網址。
5. 有沒有還留著 IMAGE PLACEHOLDER？
如果這是正式要使用的版本，我也會從頭到尾再看一次。
確認有沒有：IMAGE PLACEHOLDER。
如果這個位置本來就還沒準備正式素材，那保留可以。
但如果已經要投廣告、正式導流，就要知道它還沒完成。
另一個常見問題：本機正常，上線卻壞圖
這通常又會回到上一篇講的：絕對路徑 vs 相對路徑。
如果 HTML 還指向：C:\Users\Tina\Desktop\product.jpg
本機可能看得到，主機絕對看不到！因為網站根本沒有我的 C 槽。
所以最後部署版最好使用：assets/product.jpg 這種相對路徑。
還有一個我現在會特別檢查：大小寫
Windows 對某些檔名大小寫不那麼敏感。但是網站主機常常不一樣。
如果 HTML 寫：assets/Product-Main.jpg
實際檔名卻是：product-main.jpg
有些主機就會直接找不到。
所以我現在會盡量統一：小寫英文＋連字號。
例如：dosha-sunscreen-main.jpg
不要一會兒大寫、一會兒中文、一會兒空格。
如果上傳後看到 403、404 或空白頁，我會怎麼查？
現在如果遇到問題，我不會第一時間全部重做。
我會先按順序查。
第一步：確認網址對應的資料夾
Document Root 對嗎？
第二步：確認 index.html 在正確那一層
是不是多包了一層？
第三步：確認檔名
真的叫：index.html 嗎？
第四步：確認 assets 和 CSS 路徑
是不是資料夾位置變了？
第五步：確認檔案權限
如果主機真的有權限問題，再檢查檔案和資料夾權限。
但我現在不會一看到網頁打不開，就立刻跑去亂改權限。
很多時候其實只是：index.html 放錯層。
我這次真正覺得好用的，是「cPanel-first」思考
做到後來，我們甚至開始在 Final QA 裡直接要求：cPanel-first。
也就是從一開始就假設：這個網站最後要靠最簡單的方式：解壓 ZIP 就上線。
那所有路徑、檔案結構、圖片位置，就都朝這個方向設計。
這樣最後就不用：裝一堆環境、跑 build command、進 SSH、設定 Node。
對我這種不是工程師、只是想快速部署銷售頁的人，反而最適合。
Final QA 為什麼很重要？
我後來做 V02 時，我們有特別做 Final QA。
檢查的其實不是只有：「畫面漂亮嗎？」
而是：
-
- ZIP 解壓後 root 是否直接有 index.html
- styles.css 是否存在
- assets 是否完整
- 相對路徑是否正常
- 375px 手機版是否正常
- 768px 平板是否正常
- 1024px 是否正常
- 1440px 桌機是否正常
當這些都通過之後，我才真的比較敢把它當：「可以交付的版本。」
所以部署不是最後一秒才處理的事情
這也是我這次最大的觀念改變之一。
以前我會想：網頁先做漂亮，做完再想怎麼上線。
現在我會反過來。
我會一開始就問：最後準備怎麼部署？
如果最後就是 cPanel 靜態頁，那一開始就應該：
-
- 使用相對路徑
- 檔名簡單
- 不要依賴本機路徑
- assets 整理清楚
- 最終輸出可以直接 ZIP
- index.html 放在 ZIP 第一層
這樣最後會省掉很多麻煩。
我的「無腦部署版」流程
如果把這次經驗濃縮成最簡單的流程，我現在會這樣做：
-
- Codex 完成頁面
- 確認 Final QA
- 打開 dist 資料夾
- 確認第一層有 index.html
- 確認 styles.css 與 assets 都在
- 壓成 ZIP
- 登入 cPanel
- 進入正確 Document Root
- Upload ZIP
- Extract
- 確認 index.html 沒有多藏一層
- 打開網址
- 檢查桌機與手機版
- 測試圖片與 CTA
做到這裡，基本上就完成了。
版本檔名我也開始不敢亂取了
因為後面會有 V01、V02，一直到 V10。
如果 ZIP 全部都叫：website-final.zip
很快就會變成：
website-final-new.zip
website-final-new2.zip
website-final-really-final.zip
這種災難。
所以我現在反而會建議直接版本化。
例如：
dosha-sunscreen-v01.zip
dosha-sunscreen-v02.zip
dosha-sunscreen-v03.zip
如果要再加日期，也可以。
重點是：檔名一看就知道這是哪一版。
如果要更新網站，是不是直接蓋掉就好？
技術上可以，但我現在會比較小心！如果是正式網站，我會先保留上一版。
例如先把舊檔案備份，或先把舊 ZIP 留著，這樣新版本真的有問題時，至少還可以回上一版。
這就是為什麼版本號越到後面會越重要。
最大的成就感
一張網頁從 Codex 裡面出來之後，最後是怎麼變成真正網址的。
整條路徑其實就是：內容與設計 → HTML / CSS → assets → dist → ZIP → cPanel → URL。
現在終於串起來了。
Tina學姐這次學到的重點：部署其實也是工作流程的一部分
我以前會把「網站部署」想成最後一個技術動作。
現在反而覺得：部署方式本身，應該從一開始就被設計進工作流程。
因為如果最後要用 cPanel：那圖片路徑就應該適合 cPanel，檔案結構就應該適合直接解壓。
ZIP 就應該一層打開直接看到 index.html。
Final QA 也應該針對：「上傳之後能不能直接使用」來檢查。
這樣 Codex 做出來的就不只是：「看起來像網站的東西。」
而是：真正可以部署的網站。
寫在最後：第一次真的上線之後，我才覺得生成器開始完整了
一路做到這裡，我覺得 Tina-Sales-Page-Generator 才真的開始有完整的樣子。
因為以前只是：生成文案、生成版面、生成 HTML。
但是現在，它已經開始變成：可以被部署、可以被打開、可以給真正訪客看的東西。
這中間最大的差別就在：最後一公里有沒有走完。
而對我來說，能夠把 ZIP 自己丟進 cPanel，解壓，然後真的看到頁面出現在網址上，這件事其實很有意義。
因為它讓我知道：不需要變成工程師，還是可以把 AI 做出來的東西真正放到網路上。