ChatGPT Sites 深入解析：提示詞架站、自訂網域與何時該改用 WordPress

一句提示詞就能生出一個可以分享的網站，在 ChatGPT Sites 上是真的。這是 OpenAI 在 2026 年 7 月 9 日隨 ChatGPT Work 推出的公開測試建站功能，用提示詞建立、預覽、迭代、發佈網站與輕量應用。先記住一件事就夠：每個部署網址都是正式環境，按 Deploy a version 的當下站就已上線，要把它當長期資產，得先看懂它的邊界。

重點先看：ChatGPT Sites 是公開測試功能，Plus、Pro、Business、Enterprise、Edu 方案可用，Free 與 Go 不開放。官方工作流是描述、私人預覽、自然語言迭代、兩階段發佈。

每個部署網址都是正式環境。想先審再上線，用 Save a version 存版本，審完才按 Deploy a version。

自訂網域要先自有網域與 DNS 控制權，官方四步：Add domain、輸入網域、複製 DNS 記錄到供應商、幾分鐘後刷新狀態。

表單可做但要審資料收集，收款要外接第三方支付處理商，SEO 控制項與程式碼匯出的說明本次查證未見。

四個換 WordPress 訊號：長期資產與可搬移、完整 SEO 控制與內容工作流、電商會員多外掛整合、治理與資料落地。

現在就能做：拿可用方案的帳號進 Work 模式，輸入帶 website 的描述，先在私人預覽迭代，存版本審過再部署。

ChatGPT Sites 是什麼，為誰而生

官方給過兩段定義，範圍一致。開發者文件的第一句是 Sites lets ChatGPT create, host, refine, and share websites, web apps, and games，說明中心主文的說法是 create, preview, publish, and share interactive websites and lightweight apps。翻成白話：你描述一個站，ChatGPT 生成它、幫你託管，你用對話改它，再把網址分享出去。它鎖定的情境，是把一段提示詞或相容的既有專案變成託管體驗，不必自己建部署流程。

介面裡會同時出現 Sites 與 Site 兩個字。Sites 是功能名，指整套建站能力。Site 是你建出來的某一個站，站名、網址、版本都掛在 Site 上。讀官方文件遇到指涉不清時，先分清這一層再往下。

託管兩個字是重點。主機、部署流程與執行環境都在 OpenAI 這端，你手上的東西是提示詞、預覽與分享設定。省下這些工作的代價，是執行環境的控制權不在你手上，這條交換貫穿整個產品。

它現在是公開測試。公開測試代表功能對外開放，也代表介面、規則與上限都還在滾動，官方文件自己就提醒 beta 期間用量上限可能變動。所有方案、價格、路徑與限制，以 2026 年 9 月 10 日查證的官方頁面為準，之後可能不同，拿它做正事，養成核對官方文件的習慣比記數字重要。

從外掛預覽到公開測試：時間線

這個功能有前史。Enterprise 與 Edu 版本資訊在 2026 年 6 月 2 日記載，Sites 以預覽形式提供給符合資格的 Enterprise 與 Edu 工作區，形態是外掛，由 Codex 建立、迭代、部署輕量全端 JavaScript 與 TypeScript 網頁應用，附託管網址、Sign in with ChatGPT 存取與資料檔案儲存，存取限工作區內部，兩種工作區都預設關閉。

轉公開發生在一個多月後。ChatGPT 版本資訊在 2026 年 7 月 9 日記載 Introducing ChatGPT Sites in public beta，隨ChatGPT Work一併公告。Business 與 Enterprise 客戶當天起可公開發佈 Sites，Pro、Pro Lite、Edu 滾動開放，Plus 隨後數日跟上，Free 與 Go 不開放。同一條目註明公開發佈與擴大滾動上線時不適用於 EEA、瑞士、英國。

之後有兩個節點。2026 年 8 月 20 日，Site 擁有者在 Plus 與 Pro 可變更既有 Site 的託管網址，不必重新部署。同日 Enterprise 版本資訊記載協作編輯上線，擁有者可把同工作區成員加為編輯者，公開發佈仍由管理員控制。2026 年 9 月 3 日，Site 擁有者可與工作區外的具名人士分享線上 Site，對方能看、不能改，要以獲授權帳號登入。

地區排除要單獨看。EEA、瑞士、英國是上線時點的排除清單，之後會不會調整，要看版本資訊的後續條目。被排除地區的帳號想用，只能等官方更新。

這條時間線讀出來三件事。開放是漸進的，方案先後有別，當天看不到功能未必是資格問題。企業情境先行，公開發佈、協作、外部檢視這些能力是在公開測試之後陸續補上的。改網址與協作都出現在公開測試一個多月後，邊界還在移動。

官方期待它被拿來做什麼

OpenAI 的公告文把 Sites 與 ChatGPT Work 綁在同一場發表，形容 Sites 適合 live dashboards、project trackers、launch calendars、prototypes、internal portals 與 interactive reports，可以在 ChatGPT 內直接測試、隨底層資訊變動更新。公告同頁給了一組數字：每週超過 500 萬人使用 Codex，其中超過 100 萬人用在軟體開發以外的工作。這組數字講的是 Codex 的使用規模，可以當成 Sites 為誰而生的線索，不是 Sites 的用戶數。

說明中心的建議用途清單同方向：dashboards、project trackers、launch calendars、prototypes、internal portals、reports。共同點是輕量、內部、需要快速分享，不是要長期經營的對外官網。開發者文件另附 Sites showcase，收錄已部署的內部應用範例與完整提示詞，不知道描述怎麼寫時，直接參考它的寫法就好。

showcase 的用法有個訣竅：不要抄題目，抄約束。看範例怎麼定受眾、怎麼要求登入、怎麼說資料要保存，把這些句式搬到自己的需求上，比從零想一段描述快得多。官方建議用途之外的長期對外官網，是另一種需求，判斷標準不一樣。

反過來看，哪些需求不該指望它。要長期 SEO 經營、複雜金流後勤、完整資料主權的站，官方建議用途清單裡都沒有列出。對照清單檢查自己的需求，比試用半天更早得到答案。

誰能用：方案、地區與費用

方案與工作區控制

開發者文件寫得直接：Sites is in public beta and is available with ChatGPT Plus, Pro, Business, Enterprise and Edu plans，方案別用量上限適用。說明中心的常見問答補另一半：Sites is not available on Free or Go，上線時也不適用於 EEA、瑞士與英國。免費帳號與 Go 帳號目前建不了站。

工作區之上還有管理控制。工作區管理員可控制誰能建立與發佈 Sites。Enterprise 工作區的公開發佈預設關閉，要管理員開啟才能把站公開到網際網路。Business 工作區的 Sites 預設啟用。介面裡找不到 Sites 時，官方建議依序確認四件事：方案在不在支援清單、所在地區有沒有被排除、功能是否已經開放到這個帳號、登入的是不是所想的那個工作區。

換到管理員視角，這些預設值是決策素材。Business 預設啟用，管理員沒有主動設限前，成員就能使用 Sites，要管就得自己出手。Enterprise 預設關閉公開發佈，代表可以先內部試用，公開與否交給治理流程決定。

有一個誤讀要擋掉。Enterprise 公開發佈預設關閉是管理控制，不是 Enterprise 不能用 Sites。Enterprise 與 Edu 都在支援方案清單上，差別在 Sites 本身預設關閉、要管理員啟用，公開發佈則是再一個分開的開關。

台灣能不能用，怎麼判讀

官方的地區排除清單只列 EEA、瑞士、英國三個地區，沒有再列其他。台灣不在排除清單上，判讀上屬於可用範圍。這句是從官方清單推出的判斷，OpenAI 沒有為台灣單獨發過確認公告，實際能不能用，以登入當下介面有沒有出現 Sites 為準。

判讀會過期，這點躲不掉。公開測試產品的地區可用性隨版本資訊滾動，前一次查證能用的，下一次未必，反向亦然。要確認最新狀態，看官方版本資訊當週的條目，比看介紹文準。

方案與地區是兩個獨立的關卡，要分開查。方案對了、地區被排除，看不到功能。地區沒被排除、方案不對，一樣看不到。自己查不到功能時，先別下結論說產品不能用，兩個關卡各查一次再說。

公開測試期間的費用怎麼算

Sites 用量在公開測試期間含在方案內，用到方案上限為止，官方文件沒有 Sites 專屬加購價的說明。方案本身的參考價依 ChatGPT 版本資訊記載：2026 年 4 月 9 日的條目列 Plus 每月 20 美元。2026 年 9 月 9 日的條目把 Pro 分成每月 100 美元與每月 200 美元兩檔。

接近上限時會收到通知。到頂之後可能無法建新 Site、無法加儲存，或高用量的 Site 無法維持公開。實際數字在 Sites 介面內顯示，官方文件沒有列出來，beta 期間也可能調整，拿別人文章裡的數字當規格，不如打開自己的介面看。

價格數字有時效。版本資訊的條目會隨方案調整更新，引用的是 2026 年 9 月 10 日查證當下讀到的內容，付費前以官方方案頁為準。Pro 分成兩檔之後，選哪檔要先想清楚自己的用量與需求，兩檔的詳細差異以官方說明為準。

從一句提示詞到可分享的站

在哪裡建立

網頁版從 Work 模式進，桌面 App 在 Work 或 Codex 視圖。提示詞裡出現 website 這個字，或直接提及 @Sites，就會明確觸發建站流程，不必再找選單。想建站時，用這兩個寫法就能直接觸發。

桌面 App 要用新版。新版 ChatGPT 桌面 App 把 Chat、Work、Codex 三個視圖合在同一個側欄，Sites 就在側欄裡。舊版 ChatGPT Classic App 不支援 Sites，原本獨立的 Codex App 已併入新版桌面 App，還在用舊版的人先更新再找。入口挑平常工作的地方就好，哪邊順手用哪邊。

提示詞要寫什麼

官方建議把四件事寫進描述，受眾是誰、目的是什麼、需要哪些行為、要用哪些資訊。內容、檔案、資料、連結與限制條件可以直接附在描述裡，例如指定站的名稱、色系，或列出不能出現的欄位。開發者文件把整段流程整理成四步：Describe the Site、Review the Site、Refine the Site、Manage and share the Site。

四件事各有一個句型可用。受眾講清楚誰會用，是內部團隊、客戶或公開訪客。目的講清楚站做什麼，追蹤專案、收申請或展示成果。行為講清楚要互動到哪裡，能送出、能篩選、能登入。資訊講清楚內容從哪來，你附的檔案、貼上的文字或給的連結。四項都具體，第一版預覽就會貼近可用狀態。

官方文件的範例提示詞值得整段看一次。內部工具例的譯文是這樣的：為我的營運團隊建一個專案申請儀表板，讓成員提交申請、看到每件申請的負責人、更新狀態、篩選清單，要求大家用工作區帳號登入，並把申請資料保存下來，下次造訪還在。一句描述就把受眾、行為、登入與資料保存都交代了。

兩個變形也常用。手上有相容的既有專案，就說把這個專案用 Sites 部署，檢查相容性、做必要修改、回給部署網址。需要持久資料，就在描述裡點明，例如把玩家分數與頭像上傳加進遊戲，分數與上傳的頭像要在每次造訪之間保存。三種寫法共用的原則：把「誰用、做什麼、資料留不留」說死，來回修改的次數就少。

私人預覽：預設只有擁有者與工作區管理員看得到

送出描述後，ChatGPT 產出私人預覽。新 Site 預設只有擁有者與工作區管理員看得到，改存取權之前不會外流。還沒定案的內容可以在這個階段放進去試，可見性由存取層級擋住，但私人預覽擋的是可見性，不是資料流向，敏感資料不上站的原則這時就適用。等到要給別人看，再動分享設定，順序不要倒過來。

預覽階段值得認真走一遍。資料對不對、連結通不通、表單送出之後東西到哪裡，這些在私人狀態查，出錯的代價只是再改一版。等到部署後才發現，每個修復都要走存版本與部署兩個動作，節奏就慢了。

用自然語言迭代

改站順手的路是回到原對話。從建立該 Site 的對話回來，編輯輸入框會自動帶入這個站的參照，接著說要改什麼就好。也可以從側欄 Sites 檢視找該站，按編輯圖示進去，兩條路都通到同一個編輯回路。

官方把可改的範圍列成清單，文案、版面、資料、樣式、連結、表單、互動行為都在內。改完看更新的預覽，繼續微調，審過才發佈。修改的節奏有差別：一次改一件事，看得出每個指令的因果。一次改一堆，出錯時不知道退哪一步。想看 AI 在網頁設計決策裡還能站到哪個位置，可以讀AI 網頁設計指南。

迭代時保持版本意識。每次修改都是新的候選狀態，直到你存版本、部署，它才變成對外的樣子。這代表可以放心試，改壞了再描述回去就好，刪除整個站則是回不來的動作。

兩階段發佈：先存版本，審過才上線

發佈分兩個動作。Save a version 產生可檢視的部署候選版本，本地專案起站的話，版本會關聯建置用的 Git commit，等於幫這次變更留了指紋。Deploy a version 把已存的版本發佈上線，回報正式網址。

開發者文件用一句話標記這件事的分量：Every deployment URL is a production deployment。每個部署網址都是正式環境，沒有測試環境這層緩衝。想先審再上線，做法就固定了：先存版本，審完，才部署。把審查點放在存版本這一步，是部署上線前的最終把關。

正式環境四個字的實際含義，是部署出去的網址會出現在別人的瀏覽器、書籤與分享訊息裡。存取層級決定誰看得到，部署本身則是對外承諾的起點。存版本後多看一眼再部署，成本很低，省的是事後解釋。

部署時 ChatGPT 產生 Site URL。官方文件沒有直書這個網域的完整格式，實際格式以介面產生的網址為準，不要把任何第三方轉述的格式當規格。

託管網址與自訂網域：兩件分開的事

ChatGPT 給的網址，官方文件稱託管網址，跟自訂網域是兩個分開的功能。改託管網址不影響自訂網域，綁了自訂網域之後照樣能改託管網址，兩邊各自獨立運作。先把這條邊界畫清楚，兩種網址才不會混。

Change URL：改託管網址的規則

2026 年 8 月 20 日起，可用地區的 Site 擁有者可以在 Plus 與 Pro 變更既有 Site 的託管網址，過程不產生新部署。新名稱有硬規則：至少 5 個字元，以小寫字母開頭，只能用小寫字母、數字與單一連字號，結尾不能是連字號，也不能連續兩個連字號。

拿規則套例子，myhub 有 5 個字元、全小寫，合格。my-hub 用了單一連字號，同樣合格。-myhub 以連字號開頭，不合格。myhub- 以連字號結尾，不合格。my--hub 連續兩個連字號，不合格。名稱想好再送出，規則不通過就換一個。

舊網址會自動轉址到新網址，路由與查詢參數都跟著帶過去。改了網址之後，別人存下來的舊連結仍會被帶到新位置，不會直接失效。轉址由官方處理，站主不用自己架重新導向。

什麼時候會想改網址，常見的情況有兩種。建站時先求快，名字隨手取，站要長期用了想換個可辨識的名稱。或者站的角色變了，從個人草稿變成團隊工具，名稱要跟著對外露出。兩種情況適用同一組規則，差別只在動機。

綁自訂網域前要準備什麼

Sites 不代你註冊網域。要用自訂網域，前提是已經擁有一個網域，而且能改它的 DNS 記錄。apex 網域與子網域都可以綁，常見的分法是把主網域留給品牌官網，子網域給工具站，各自分開管理。

DNS 控制權的檢查很樸素，你登得進網域商的後台，找得到加記錄的頁面，就過關。網域在公司行號名下、DNS 交給代理商管的，先問清楚誰能改再開始綁，否則走到加記錄那一步就會卡住。

方案別有一個限制要記住，Enterprise 工作區上線時不支援自訂網域。官方文件用 Where custom domains are available 的寫法，沒有逐一列出各方案的開放範圍，實際以設定頁出現的選項為準。對照託管網址的規則看，兩者的開放範圍本來就不同步，別假設一邊能用另一邊就一定能用。

官方四步綁上網域

官方步驟照介面走，四步依序是：

• 開 Site 的設定，按 Add domain。
• 輸入要用的 apex 網域或子網域。
• 把 Sites 提供的 DNS 記錄與數值加到網域供應商。
• 等幾分鐘，回設定刷新網域狀態。

綁網域這段也能找 ChatGPT 幫忙。它可以協助把網域指到 Site。啟用瀏覽或電腦操作功能後，你登入網域供應商，它能陪你照著介面逐步完成，遇到不熟的控制面板特別有用。

狀態刷新是第四步的重點。DNS 記錄加好後，官方給的說法是等幾分鐘再回設定刷新狀態。重新整理幾次狀態還沒過，回網域商核對記錄是否與官方給的數值一字不差。

ChatGPT Sites 的能力邊界：能做、需外接與官方尚未說明

把想做的事對到 Sites 現況，比背功能清單有用。常被問的七件事，依據以 2026 年 9 月 10 日查證的官方說明中心與開發者文件為準。

想做的事	Sites 現況	依據
收集表單回應	可以做。官方提醒分享前審查表單與開放文字欄位的資料收集	說明中心編輯指令與分享前檢查清單
看流量表現	內建分析，總不重訪客與總瀏覽量含時間趨勢。Enterprise 工作區擁有的站目前沒有這頁	開發者文件 Analytics 說明
存結構化資料	D1 關聯式資料庫，每個 Site 10 GB	開發者文件儲存說明
放圖片與檔案	R2 物件儲存，無固定儲存上限	開發者文件儲存說明
站內收付款	要外接第三方支付處理商，金流與訂單責任在站主	說明中心電子商務說明
控制 sitemap、robots、meta	本次查證未見官方提供這類控制項的說明	2026 年 9 月 10 日查證兩份官方文件
一鍵匯出程式碼	本次查證未見官方說明	2026 年 9 月 10 日查證兩份官方文件

表單做得到，資料收集要自己審

表單是站內能力。官方的編輯指令清單裡有 forms，分享前檢查清單同樣列了 forms，加上收集個人資訊的開放文字欄位、留言板與登入功能。訊息很明確：表單做得到，放出去之前先看它收集什麼、回應誰看得到。這層審查官方交給站主自己把關。

實際檢查就三個問題，欄位是不是都必要、收到的姓名、Email、電話放在哪、誰有權限讀。答不出來的欄位先刪，上線後再補，比出事後回收資料容易。

內建分析看什麼，例外在哪

Sites 自動記錄流量，不必另裝分析工具。分析頁顯示總不重訪客與總瀏覽量，兩者都有時間趨勢，日期範圍與粒度可以調整。路徑在 Sites 檢視的 More actions > Analytics。看分享出去的連結有沒有人造訪、活動期間流量如何變化，這兩個指標派得上用場。

兩個指標的解讀要分開。總瀏覽量計頁面被載入的次數，總不重訪客計不同訪客的數量，兩者都附時間趨勢。少數人重複載入也會把瀏覽量撐高，對外活動頁兩個都看比較準。

例外要記住，分析目前只適用非 Enterprise 工作區擁有的 Sites。Enterprise 工作區擁有的站，現在沒有這頁分析。企業帳號起站的人，流量觀測要另想辦法，這是方案差異直接影響工作的地方。

資料放哪：D1 與 R2

開發者文件用 Site shapes 表把儲存對到需求。純內容網站不需要持久應用狀態。要保存記錄、進度或分數，用 D1 關聯式資料庫放結構化資料。要上傳圖片、文件、影音，用 R2 物件儲存放檔案。上傳檔案要帶可搜尋中繼資料，就 D1 放中繼資料、R2 放檔案。內部站要工作區身分就走 workspace 身分，公開站要會員功能就用 authentication-enabled Site，登入這段由 Sign in with ChatGPT 承接。

上限直接抄官方表格：D1 資料庫儲存每個 Site 10 GB，R2 物件儲存無固定上限。暫時性的呈現狀態，像主題偏好或已關閉的橫幅，官方提醒不需要動用持久儲存。

判斷要用哪種儲存，回到資料的壽命。訪客當下看了就丟的狀態，放前端就夠。下次造訪還要找回來的，進 D1 或 R2。把 D1 當萬用倉庫什麼都塞，10 GB 會比想像中快見底。反過來，圖片這種大檔案該進的是 R2。

執行環境有自己的邊界。Sites 跑在支援的 Sites runtime，部分框架、私人網路、資料庫、背景服務與託管模式不支援。HTTP、HTTPS 與 WebSockets 支援，原始 TCP 連線進出不支援。本地專案與託管端的連動資訊記在 .openai/hosting.json，內容是 project_id 與 D1、R2 的綁定名。

賣東西：平台不碰金流

想在 Site 上賣東西，可以，平台不碰金流。說明中心的寫法：收款要透過第三方支付處理商，串接、設定與維護是站主的責任，OpenAI 不負責經其處理的款項，訂單履行、交付、退款、客服、商品保證與稅費計收繳納，全部歸站主。翻成採購語言：Sites 提供店面，金流與訂單後勤自己帶。

責任清單很長，邏輯只有一條：平台提供站，交易的一切後勤在你。賣實體商品要處理庫存與寄送，賣數位內容要處理交付與退款，稅務兩種都要面對。評估要不要在 Site 上開賣，先算這些後勤自己接不接得住。

開發者文件的 Don't 清單列了 enable financial transactions，與說明中心合起來讀，結論是：站內不能自行處理交易，收款走第三方支付處理商就可以。支付卡資料只能經由第三方支付處理商處理，卡號不要進站，這條同時寫在敏感資料禁令裡，屬於硬紅線。

SEO 控制項：查證未見官方說明

控制項的說明缺席，不等於站一定不會被搜尋引擎收錄，但想調 sitemap、robots、meta，目前沒有官方文件可循。

影響要分情境看。活動頁、prototype、內部工具這類靠分享連結流動的站，影響有限，網址會有人主動轉傳。要靠搜尋流量長期成長的站，這點缺席要認真看待，因為基礎的收錄狀態沒有可操作的說明可循。想認真比一比 AI 架站工具在 SEO 上的表現，可以先讀AI 網站生成工具的完整盤點再決定力氣放哪。

決策可以更早做。一個內容資產如果走搜尋成長路線，從第一天起就該住在可控的系統裡，因為網址、標題與內容結構都是累積出來的，事後搬要付重建與轉址的成本。靠分享與內部流動的站沒有這個負擔，用 Sites 起站速度是優勢。

程式碼匯出：查證未見，本地專案例外

一鍵匯出程式碼的功能，到查證日為止沒有見到官方說明。本地專案起站的，可編輯的原始碼留在本地，部署仍會把程式碼與生成 artifacts 送到託管環境。哪些東西在雲、哪些在本地，換站前要自己盤一次，這份清單直接當搬移評估的起點用。

對開發者還有一條線索，本地專案起站的路徑本來就存在，走這條路的人原始碼在自己機器上，託管端靠 hosting.json 對齊。純提示詞起站的人有沒有對應的取得方式，本次查證未見官方說明，判斷搬移需求時，先盤點自己手上有哪些檔案與資料。

分享層級與多人協作

四個存取層級怎麼選

存取權在 Who has access 設定，四層：擁有者與工作區管理員、選定的使用者或群組含具名外部檢視者、工作區內任何人、網際網路上的任何人。新 Site 預設落在第一層，第四層只有公開發佈已啟用時才能選。

分享前把層級對一次受眾，是官方檢查清單裡的動作。給全工作區的內部工具，選工作區層。只想給幾位同事或外部特定人士看，用具名層。要公開到網際網路，先確認工作區允許公開發佈，再按 Share。

每個層級對應誰看得到、適合哪種站，對照下表選。

層級	誰看得到	適合的站
擁有者與工作區管理員	預設層級，新建的站都在這層	還在做的站、含敏感內容的站
選定的使用者或群組	指定帳號，可含具名外部檢視者，視支援情況	給特定同事或外部人士審的站
工作區內任何人	工作區成員，視支援情況	內部入口與團隊工具
網際網路上的任何人	公開發佈啟用後才開放	對外的活動頁與公開儀表板

層級的變更時點也值得想。預設第一層的設計，把公開的決策留在人工這一步。做完再開，比開了再補審安全，因為收回去的可見性，別人可能已經留了連結或截圖。

分享給工作區外的具名檢視者

2026 年 9 月 3 日起，Site 擁有者可與工作區外的具名人士分享線上 Site。對方以獲授權帳號登入，能使用、不能編輯或發佈，邀請也不會讓對方進工作區。適合把站寄給外部利害關係人看，又不交出編輯權。

具名檢視者的價值在可控的回饋。把站寄給外部顧問、客戶或合作方，對方登入看得到、動不了，意見回到你手上再統一改。這比公開後收各方意見乾淨，也比截圖來回寄準確。

這個能力有管理開關。Enterprise 由管理員在 Workspace settings > Permissions & roles 控制 Allow members to invite external visitors to sites。Business 沒有獨立開關，前提是 Sites 已啟用且該帳號已開放這項功能。邀請外部檢視者與公開發佈是分開的兩個控制，一個開了不代表另一個跟著開。

Sign in with ChatGPT：公開站的選擇性登入

公開站可以保持開放，同時提供選擇性登入，用來存進度、做個人化、留個人記錄。登入登出的路徑是 /signin-with-chatgpt 與 /signout-with-chatgpt。登入後，Sites 透過 request headers 把身分傳給站，oai-authenticated-user-email 帶 email，oai-authenticated-user-full-name 可能帶姓名。

什麼時候會用到選擇性登入，官方給的三個例子是存進度、個人化、個人記錄。判斷標準很簡單：訪客之間的差異要不要被記住。要，就開登入。不要，站保持全開放，訪客少一道登入手續。

授權決策要留在 server-side 程式碼，不要只靠前端判斷。這是開發者文件明寫的邊界，也是把會員功能做對的第一條規則。

協作編輯：首次發佈限擁有者

Site 擁有者可給同工作區的活躍成員 Can edit。編輯者可改內容、可存版本。第一次發佈必須由擁有者執行，之後編輯者可以把後續版本發佈到同一個網址，不需要擁有者逐次核准。團隊分工因此很自然：擁有者把關首次上線，後續迭代交給做事的人。

協作的實際節奏是一個人起站與首次發佈，幾個人分頭迭代，擁有者管存取與網域這類結構性設定。首次發佈的門檻設在擁有者身上，等於給公開動作留了一個明確的責任人。

有些動作只有擁有者能做，包括管理存取、改站名或網址、轉移擁有權、設定 secrets、綁自訂網域。開發者文件補了一條挑隊友的標準：編輯者可讀該站 live database 的資料，只邀信任的人。權限給出去之前，先想過這條。

下架、刪除與強制移除

下架有兩種力道。限縮存取走 Share 設定，把層級調回去就能收回可見性。永久刪除走 Sites 檢視的 Delete site，輸入 Site slug 確認，按 Permanently delete，刪除不可還原，按之前想清楚。

兩種下架對應兩種需求。暫時收回用 Share 設定，站與資料都還在，改天可以再開。永久刪除是清空，輸入 Site slug 的確認步驟是刪除前的防呆設計，名字輸對了才刪得掉。

平台側也有強制力。OpenAI 可移除或限制有違反政策風險的 Site，誤刪可循通知信連結或 intake form 申訴，檢舉走 content reporting form。Business 與 Enterprise 的站，自家管理員也能從 Workspace settings > Sites 停用。站的存在權有兩層，平台一層，工作區一層。

治理：訓練資料、資料落地與敏感資訊

建站對話會不會變成訓練資料

對話遵循既有的資料控制設定。Business、Enterprise 與 Edu 預設不用你的對話或 Sites 資訊訓練模型。Free、Go、Plus、Pro 的帳號，在 Improve the model for everyone 設定開啟時，OpenAI 可能用你的對話訓練模型，範圍含建立、設計、編輯、管理 Site 的對話。請 ChatGPT 編輯已發佈的 Site 或從中取資訊時，相關內容會被帶進對話。

對個人與小團隊，動作很具體：上站之前，去帳號設定看 Improve the model for everyone 的狀態，按站內資料的敏感度決定開或關。這個設定管的是對話層，跟分享層級是兩件事，兩邊要各看一次。

商務帳號也別跳得太快。預設不訓練是方案層的承諾，成員若用個人帳號建公司站，資料流向就跟著個人方案的設定走，這是從方案規則推出的判斷。用哪個帳號建站，本身就是治理決策。

資料落地與敏感資料的紅線

上線時不支援 data residency 與 inference residency，範圍含已部署的 Sites、Site 程式碼、D1 與 R2 的資料與檔案儲存、生成 artifacts、日誌。公司治理要求資料落地或資料主權時，這條是硬限制，不是設定能繞過的。

敏感資料的紅線列得很白，不得處理受保護健康資訊與支付卡資料，支付卡資料只能經由第三方支付處理商。不得針對 13 歲以下或當地數位同意年齡以下的兒童。禁散布惡意軟體、釣魚、冒充個人或組織。使用 Sites 時須遵守 OpenAI 使用政策與 ChatGPT Sites 條款。

紅線的效力寫在條款層，使用政策與 ChatGPT Sites 條款是同一份約束的兩面，違反的處置平台側有強制力。拿不定某類資料能不能放，先查條款原文，不要靠感覺。

站上線前，把要放的資料對一次這張清單。受保護健康資訊、卡號這類支付資料、針對未達數位同意年齡兒童的服務，任一命中就不要上站，改走能負擔這類資料的環境，這不是調整提示詞能解決的事。

用量觸頂之後還能做什麼

用量以帳號所有 Sites 合計，計入方案別上限。觸頂之後，既有 Sites 仍可編輯與管理，不必急著刪站，先降用量或等工作區安排。上限數字在 Sites 介面內顯示，beta 期間可能變動，這也是官方文件自己標注的滾動性。站、資料與編輯權都還在，處置的時間比想像中多。

何時該換 WordPress：四個訊號

Sites 的強項是速度與分享：一段描述、幾輪迭代、一個網址。WordPress 的強項在另一側：開源、可自架主機或租主機、主題與外掛資源多、內容與資料可匯出搬移、SEO 控制項完整。這些是常識級的對照，不引數字。要並排比較幾種架站方法的人，可以搭配網站架設方式的完整比較一起看。

出現四個訊號，代表需求長到 Sites 的邊界外了。訊號出現不等於馬上搬，先做最小搬移評估。

訊號一：站是長期資產，內容要能搬走

第一個訊號是資產屬性。站要長期累積內容、網址要自己持有、資料要跟著公司走，這時內容能不能整包帶走變成關鍵問題。Sites 的託管、資料與檔案都在平台內。WordPress 內容與資料可匯出，搬到哪台主機自己決定，資產在自己手裡。

判斷的方法很簡單，問自己這個站是要用一陣子，還是要留很久。答案是不確定或否定，Sites 的速度優勢讓它仍是好起點。答案是肯定，內容累積的第一天就該住在搬得走的系統裡。

搬移盤點從三張清單開始，內容、資料、連結各一張。內容指頁面文字與圖，資料指 D1 與 R2 裡的東西，連結指別處指向這個站的網址。三張清單開得出來，搬移就有譜。開不出來，站還沒準備好當資產。

訊號二：需要完整 SEO 控制與內容工作流

要長期經營搜尋流量，就需要自己設 sitemap 與 robots、改 meta 與標題結構、安排發文與修訂流程。Sites 這端的控制項，前面查證的結果是說明缺席，WordPress 側控制項完整。從第一篇文章開始養站的流程，可以看WordPress 部落格的起步教學。控制項要交給外掛處理的，先讀WordPress SEO 外掛的比較。

工作流的判斷標準是節奏。每週固定發文、每季回頭修舊文的團隊，需要修訂歷史、排程與權限分層這些內容工作流的骨架。這套節奏在 Sites 裡好不好做，拿自己的發文頻率對一次就知道。

訊號三：功能長出電商、會員與多外掛整合

需求長出購物車、會員制度、行銷自動化或要串多個服務時，就跨出套裝 AI 架站工具的典型範圍了，Sites 這端收款要外接、治理紅線要自己守。WordPress 的外掛資源讓複雜功能用組合的方式長出來。要的東西若已經是品牌官網等級的設計與轉換流程，也可以直接評估網頁設計公司，不必自己從頭組。

判斷的時點也重要。第一個購物需求出現時就開始評估，還來得及規劃。等到好幾個外掛需求疊上來才想搬，站已經長成平台的形狀，搬移成本跟著膨脹。

訊號四：治理要求超出公開測試現況

公司治理要求資料落地、資料主權或合約層級的保證時，公開測試產品的現況接不住。Sites 上線時不支援資料落地，訓練預設也依方案而定。這類要求源於法規或客戶合約，站長自行取捨的空間很小。WordPress 可自架主機，資料放在自己控制的環境，責任歸屬清楚。

治理訊號的特色是它不由站長定義。法規要求、客戶合約、產業規範，任何一紙文件都可能把資料落地變成硬條件。遇到這種要求，對照官方文件確認現況，把結論寫進評估，不要賭公開測試產品很快補上。

訊號出現之後：先做最小搬移評估

四個訊號整理成一張表，自問的問題比工具名稱重要。

訊號	自問的問題	WordPress 側的對應
長期資產與可搬移	內容與資料能整包帶走嗎	內容與資料可匯出，主機自己選
SEO 控制與內容工作流	需要 sitemap、robots、meta 與發文流程嗎	SEO 控制項完整，工作流成熟
電商會員多外掛整合	功能已經長出購物、會員、多服務串接嗎	外掛資源多，複雜功能用組合長出來
治理與資料落地	法規或合約要求資料存放地嗎	可自架主機，資料在自己環境

任一訊號出現，先做最小搬移評估：列要帶走的內容清單，確認哪些資料能匯出或轉換、哪些流程需要重建，再決定全站搬移或雙軌並行。訊號一個都沒出現，站就留在 Sites，速度是它的優勢。

評估的另一端是成本。搬移要時間、要重練的操作、要重建立的連結。訊號不明確時先列清單不動手，訊號明確時這些成本反而不再是理由。

雙軌並行指的是 Sites 站先留著做快速回應，新開一個 WordPress 站承接長期內容，兩邊並存一段時間，流量與工作流逐段搬。比起一次全搬，這種做法每一步都可回頭，特別適合還在漲需求的團隊。

下一步

依現在的位置選一個動作。還在評估的人，用可用方案的帳號進 Work 模式，拿官方範例提示詞的結構寫一段描述，走完私人預覽與兩階段發佈，親手跑一次流程比只讀介紹看得準。

已經有站的人，做三個檢查：Who has access 的層級對不對、Improve the model for everyone 的狀態、表單收集的欄位有沒有踩到敏感資料紅線。三件事各自獨立，做完一件算一件。

訊號已經出現的人，做最小搬移評估，從WordPress 快速架站指南開始估時間與成本。先跑一次，再決定這個站要住哪裡。搬過去之後若想延續 AI 起站的速度，可以看在 WordPress 裡用 AI 快速起站的問卷式流程。