- 首頁
- 知識庫
- Sharing AI 架站平台教學
- 自有網域怎麼綁定網站？DNS 設定、SSL 生效與常見錯誤
Sharing AI 架站平台教學
自有網域怎麼綁定網站？DNS 設定、SSL 生效與常見錯誤
作者：JamXu更新日期：2026-10-08
綁定自有網域，就是到管理網域 DNS 的地方，把網域（@）與 www 指向網站平台的主機，再讓平台確認網域、核發 SSL 憑證。順序是：先盤點並備份現有 DNS 記錄，刪掉會衝突的舊記錄但保留信箱用的 MX，依平台後台提供的值新增記錄，等待生效後確認 https 與 www 兩個版本都正常。
綁定網域時，你其實在設定三個地方
很多人以為「買了網域、在網站後台填進去」就結束了，結果卡在網站打不開，或是網站好了、公司信箱卻收不到信。原因是綁定網域牽涉三個不同的角色，各自在不同的後台設定，彼此之間又互相依賴。先把這三者分清楚，後面每一步在做什麼就很好理解。
| 角色 | 負責什麼 | 你會在哪裡操作 |
|---|---|---|
| 網域註冊商 | 你向它購買、續約網域，網域的所有權登記在這裡 | 購買網域的網站，例如國內外的網域註冊服務 |
| DNS 代管 | 保存網域的各種記錄，回答「這個網址要連到哪台主機、信要寄到哪裡」 | 通常就是註冊商的 DNS 管理頁；若改用 Cloudflare 等服務代管，就在那一邊 |
| 網站平台 | 真正存放網站內容的主機，並負責為你的網域提供 SSL 憑證 | 例如 Sharing AI 後台的網域設定 |
一句話說明三者的關係：網域是門牌，DNS 是登記門牌對應地址的通訊錄，網站平台則是房子本身。綁定網域，就是在通訊錄裡把門牌改寫成新房子的地址，再請房子的主人確認「這個門牌確實歸我管」，並為它掛上安全連線的鎖。
最容易出錯的地方，是搞不清楚 DNS 究竟由誰代管。網域在 A 公司買的，DNS 卻可能早就被前一任網站廠商改到 B 服務代管；這時在 A 公司後台怎麼改都不會生效。判斷方法是查看網域的名稱伺服器（NS 記錄）：名稱伺服器指向哪一家，DNS 記錄就要到哪一家修改。多數註冊商的網域管理頁都會直接顯示目前使用的名稱伺服器。
動手之前：五項準備，避免網站與信箱同時中斷
改 DNS 是一件「改錯了不一定立刻發現、發現時已經影響顧客」的工作。花半小時做好下面五項準備，可以避開大部分的事故。
- 確認你登得進「真正管 DNS 的後台」：找出名稱伺服器屬於哪一家，並確認帳號密碼、雙重驗證手機都在公司手上，而不是只在離職同事或外包廠商那裡
- 把現有 DNS 記錄完整截圖或匯出：包含每一筆記錄的類型、名稱、值與 TTL，萬一改錯，才有辦法照原樣復原
- 標出不能動的記錄：MX（公司信箱收信）、與信箱寄信驗證有關的 TXT（例如 SPF），以及 Search Console、Meta 等服務的驗證用 TXT
- 決定主要網址：要讓訪客最後停在 www.你的網域，還是不帶 www 的版本；兩個版本都要能開，但只能有一個是主網址（後文說明）
- 挑一個影響最小的時段：避開活動、廣告投放高峰與月底結帳，並預留至少一兩天觀察期
第二項特別重要。很多網域在註冊商的預設設定下已經有好幾筆記錄，有些是停放頁、有些是轉址，也可能是前一個網站留下的。沒有備份就直接刪，一旦把信箱用的記錄一起刪掉，往往要等到客戶說「寄給你們的信被退回」才會發現。
提早把 TTL 調低（選擇性）
每一筆 DNS 記錄都有一個 TTL（存留時間），單位是秒，意思是「其他 DNS 伺服器可以把這筆答案記住多久」。Google Workspace 說明中心在介紹 TXT 記錄時就以 1 小時（3600 秒）作為設定範例。如果舊記錄的 TTL 設得很長，可以在切換前一兩天先把要更改的記錄調短，等舊的長效快取過期後再正式切換，生效速度會比較一致。不熟悉這個設定的話，維持預設也可以，只是要多預留等待時間。
看懂 DNS 記錄：綁定網站會碰到的六種類型
打開 DNS 管理頁，第一眼通常是一張寫滿縮寫的表格。綁定網站其實只需要動其中兩三種，但認得其他類型，才不會誤刪重要的記錄。
| 類型 | 用途 | 綁定網站時怎麼處理 |
|---|---|---|
| A | 把名稱對應到一組 IPv4 位址 | 最常用來把不帶 www 的網域（@）指向網站主機 |
| AAAA | 把名稱對應到一組 IPv6 位址 | 平台沒有要求就不新增；舊主機留下的 AAAA 要一併確認，否則部分訪客可能被帶回舊網站 |
| CNAME | 把一個名稱設成另一個網域名稱的別名 | 常用於 www 這類子網域；同一個名稱有 CNAME 時，不能再有其他記錄 |
| TXT | 存放一段文字，用於驗證網域擁有權或寄信防偽 | 驗證用的 TXT 通常要保留，不要順手刪掉 |
| MX | 指定這個網域的電子郵件要送到哪台郵件伺服器 | 與網站無關，綁定網站時不要動 |
| NS | 指定由哪一家的名稱伺服器回答這個網域的查詢 | 決定你要在哪個後台改 DNS；換代管服務時才會改 |
名稱欄位的 @ 與 www 是什麼意思
DNS 管理頁的「名稱」（有些後台叫主機、Host 或別名）指的是網域前面的那一段。依 Google Workspace 說明中心的 A 記錄設定步驟，代表網域本身時，名稱欄位要留白或填入 @；填 www 則代表 www.你的網域。所以「@ 的 A 記錄」設定的是不帶 www 的網址，「www 的 CNAME」設定的是帶 www 的網址，兩者都要設定好，訪客不論輸入哪一種都能連上。
為什麼網域本身不能用 CNAME
新手常問：既然 CNAME 那麼方便，為什麼網域本身（@）不直接用 CNAME？依照 DNS 的規範文件 RFC 1912，CNAME 記錄不能和同名稱的其他資料並存；而網域本身一定帶有 NS 等必要記錄，所以標準做法是用 A 記錄。Cloudflare 的技術文件也說明，它提供的「CNAME 攤平」功能，正是為了讓網域根部也能使用 CNAME 而設計的變通方式。實務上照平台要求的類型設定即可：要求 A 就填 A，要求 CNAME 就只用在 www 等子網域。
在 Sharing AI 綁定自有網域：四個階段逐步做
使用 Sharing AI 架站平台時，網域相關的操作集中在後台「設定 → 基本」頁面上方的「網域」分頁。分頁頂端用四個階段顯示進度：送出申請、設定 DNS、系統驗證、網域上線。照著這四個階段走，就能清楚知道自己卡在哪裡。
階段一：送出申請
在「網域」分頁填入要使用的網域並送出。新網站在開通時會先有一組平台提供的免費子網域，可以先用它把網站做好、檢查完，再申請換成正式網域；官方價格頁也說明，已有自備網域的用戶可以請服務團隊免費協助串接設定。網域填寫時不要加上 https:// 或結尾的斜線，並確認拼字與你購買的網域完全一致。
階段二：設定 DNS
到真正管 DNS 的後台，依平台提供的記錄值修改。Sharing 的官方網域教學把這一步分成兩件事：先清理會衝突的舊設定，再新增指向 Sharing 主機的記錄。要清理的通常是以下幾類：
- 網域本身（@）原有的 A 記錄：舊主機或註冊商停放頁的位址，留著會讓部分訪客連到舊的地方
- www 原有的 CNAME：通常指向註冊商的預設頁或舊網站
- 註冊商內建的網址轉址或停放頁設定：它會攔在 DNS 前面，把訪客導到別處
- 部分網域商自動建立的連線輔助記錄：例如 GoDaddy 預設的 _domainconnect CNAME，官方教學建議一併移除
清理完成後，依後台或客服提供的值新增記錄：一般是為網域本身（@）新增 A 記錄，www 則依指示使用 A 或 CNAME。清理時請對照先前的備份截圖，MX 與驗證用的 TXT 記錄保持不動；它們和網站主機無關，刪掉只會讓信箱或其他服務出問題。
階段三：系統驗證
DNS 改好之後回到後台等待驗證。系統要確認你的網域確實已經指向平台，並為網域取得 SSL 憑證，這段時間無法手動加速。Sharing 官方教學的說法是一般在 24 小時內完成，切換過程中網站可能會有一段時間連不上，所以前面才建議避開重要檔期。
階段四：網域上線
看到「網域上線」與綠色的「已通過，含 SSL」後，代表網域與憑證都已就緒。這時請用手機與電腦分別開啟 https://你的網域 與 https://www.你的網域，確認兩個版本都能正常顯示、網址列有鎖頭圖示，並且最後都停在你選定的主網址。之後若要更換網域，同一個分頁也有「申請變更網域」的按鈕，設定遇到問題則可以從頁面下方聯絡客服。
網域商後台怎麼填：欄位對照與一張設定表
各家網域商的介面不同，但新增 DNS 記錄時要填的欄位幾乎都一樣，只是名稱不同。下表整理常見的欄位說法，對照起來就不怕換了一家後台看不懂。
| 欄位意義 | 常見的名稱 | 填寫方式 |
|---|---|---|
| 記錄類型 | Type、類型 | 從下拉選單選 A、CNAME 或 TXT 等 |
| 名稱 | Name、Host、主機、別名 | 網域本身填 @ 或留白；子網域只填前綴，例如 www |
| 記錄值 | Value、Points to、指向、目標 | A 記錄填 IP 位址；CNAME 填主機名稱 |
| 存留時間 | TTL | 用預設值即可；正在切換時可設短一些 |
| 代理狀態 | Proxy status（Cloudflare 才有） | 見後文「Cloudflare 代管時」一節 |
有些後台在名稱欄位會自動補上網域，例如你填 www，畫面顯示 www.example.com；若你自己又填了完整的 www.example.com，最後可能變成 www.example.com.example.com 這種錯誤的名稱。新增後務必回到列表確認顯示的結果。
建議整理一張「網域設定表」
設定完成後，把結果整理成一張表，存放在公司共用的文件裡。日後換網站廠商、加開信箱或發生問題時，這張表會是最快的參考依據。
| 欄位 | 要記錄的內容 |
|---|---|
| 網域與到期日 | 網域名稱、註冊商、到期日、是否開啟自動續約 |
| 帳號與負責人 | 註冊商與 DNS 代管的登入帳號由誰保管、雙重驗證綁在哪支手機 |
| 名稱伺服器 | 目前 NS 指向哪一家 |
| 網站記錄 | @ 與 www 的記錄類型、值、TTL，以及設定日期 |
| 信箱記錄 | MX 與寄信驗證相關的 TXT，註明「勿刪」 |
| 驗證記錄 | Search Console、廣告或社群平台的驗證用 TXT 與用途 |
| 變更紀錄 | 每次修改的日期、內容與執行人 |
DNS 生效要多久？快取原理與三種檢查方法
改完 DNS 最常見的焦慮，是「我明明改好了，為什麼打開還是舊網站」或「同事看得到新網站，我卻看不到」。這通常不是設定錯，而是快取還沒過期。
全世界的網路服務商、公司網路與你的電腦，都會把查過的 DNS 答案暫存一段時間，長短由記錄的 TTL 決定。你改了記錄，但別人手上的舊答案還沒到期，就會繼續連到舊位址。Google Workspace 說明中心在 A 記錄的設定步驟中提醒，記錄變更最多可能需要 72 小時才會完全生效，但通常不會這麼久；Sharing 官方教學則說明網域一般在 24 小時內完成更新。兩者並不衝突：一個是 DNS 本身最長的等待時間，一個是平台實務上常見的完成時間。
方法一：用不同的網路開開看
用手機關掉 Wi-Fi 改用行動網路，或請不同地點的同事幫忙打開網址。不同網路使用不同的 DNS 伺服器，如果多數人都已看到新網站，只剩少數還是舊的，通常只要再等一等。
方法二：用指令直接查記錄
在電腦的命令提示字元或終端機輸入 nslookup 你的網域 8.8.8.8，可以向 Google Public DNS 查詢目前的 A 記錄，看看回傳的位址是不是後台提供的值。要查 www，就把網域換成 www.你的網域。查到的是新值，代表 DNS 已經更新；查到的還是舊值，就先檢查是不是有舊記錄沒刪乾淨。
方法三：請公共 DNS 清除快取
Google Public DNS 提供「清除快取」工具，可以要求它重新查詢某個網域的記錄；它的說明文件也提到，若網域的註冊商或 DNS 代管剛更換過，應先清除主網域，再處理子網域。不過這個工具只影響 Google 自己的 DNS 服務，其他網路服務商的快取仍要等 TTL 到期。
SSL 憑證怎麼生效？從「系統驗證」到網址列的鎖頭
SSL 憑證（現在的技術名稱是 TLS）讓瀏覽器與網站之間的連線加密，網址列才會顯示 https 與鎖頭。沒有有效憑證的網站，瀏覽器會顯示「不安全」或直接擋下連線，訪客多半會立刻離開。
為什麼一定要等 DNS 生效，憑證才會核發
憑證機構在核發憑證之前，必須確認申請者確實控制這個網域。以公開說明驗證方式的 Let’s Encrypt 為例，常見的做法有兩種：一種是在網站上放一個指定的檔案，由憑證機構透過 80 埠連線讀取（HTTP-01）；另一種是在 DNS 新增一筆 _acme-challenge 開頭的 TXT 記錄（DNS-01）。不論哪一種，只要網域還沒正確指向平台，驗證就無法通過。所以平台把「系統驗證」排在「設定 DNS」之後，順序不能顛倒。
CAA 記錄：少見但會讓憑證卡住
CAA 是一種指定「哪些憑證機構可以為這個網域核發憑證」的 DNS 記錄。Let’s Encrypt 的說明指出，沒有 CAA 記錄時，任何公開的憑證機構都可以核發；一旦設了 CAA，沒有列在記錄中的機構就不能核發。如果你的網域以前被設過 CAA（常見於曾購買付費憑證的網域），而平台使用的機構不在名單上，驗證就會一直卡住。遇到這種情況，把 CAA 記錄的截圖提供給平台客服確認即可，不要自行亂加。
鎖頭出現之後，還要檢查混合內容
網址已經是 https，網址列卻顯示警告，常見原因是「混合內容」：頁面本身用 https 載入，但頁面裡的圖片、影片或程式碼仍從 http 網址載入。web.dev 的說明指出，這會削弱整個頁面的安全性，瀏覽器也可能自動升級或封鎖這些資源。最常見的來源是早期貼進內文的圖片網址、嵌入碼或外部按鈕，把它們改成 https 版本即可。
HTTPS 也與搜尋有關。Google 搜尋中心的網頁體驗說明把「網頁是否以安全的途徑提供？」列為自我評估的問題之一；在處理重複網址時，Google 也會優先選擇 HTTPS 網頁作為標準網址，除非憑證無效或有其他相衝突的訊號。網域與憑證設定正確，是被搜尋引擎正確收錄的基本條件。
Cloudflare 代管（橘色雲朵）時，要特別注意的四件事
不少企業把網域的 DNS 交給 Cloudflare 代管，以取得加速與防護功能。這時情況比一般網域商多一層：Cloudflare 的每一筆網站記錄都有「代理狀態」，畫面上用雲朵圖示表示。橘色雲朵代表「已代理」，訪客的連線會先經過 Cloudflare 再轉到你的網站主機；灰色雲朵代表「僅限 DNS」，Cloudflare 只負責回答記錄，不經手網站流量。
| 比較項目 | 已代理（橘色雲朵） | 僅限 DNS（灰色雲朵） |
|---|---|---|
| DNS 查詢回傳的位址 | Cloudflare 自己的共用位址，不是網站主機的位址 | 你填入的網站主機位址 |
| 網站流量路徑 | 訪客 → Cloudflare → 網站主機 | 訪客 → 網站主機 |
| 瀏覽器看到的憑證 | 由 Cloudflare 提供的邊緣憑證 | 由網站平台提供的憑證 |
| 可以設定的記錄 | 只有 A、AAAA 與 CNAME 能開代理 | 所有類型；MX、TXT 一律是這個狀態 |
一、驗證卡住時，先確認代理狀態
依 Cloudflare 對代理狀態的技術說明，已代理的記錄在 DNS 查詢時回傳的是 Cloudflare 的共用位址，而不是你填入的值。這代表從外部查詢時，看不到你填的平台位址；用前面的 nslookup 檢查也會得到 Cloudflare 的位址，這是正常現象，不代表設定錯誤。若平台的系統驗證遲遲不通過，請依平台官方的 Cloudflare 設定教學操作，或把 Cloudflare 的記錄畫面提供給客服確認，不要自行猜測切換。
二、加密模式不要選「彈性」
代理開啟後，連線分成兩段：訪客到 Cloudflare、Cloudflare 到網站主機。Cloudflare 對 SSL/TLS 加密模式的說明指出，「彈性」（Flexible）模式只加密訪客到 Cloudflare 這一段，Cloudflare 連到主機時用的是未加密的 http；官方強烈建議使用「完整」（Full）或「完整（嚴格）」模式。若網站平台本身會把 http 自動導向 https，「彈性」模式還會造成重新導向迴圈：Cloudflare 用 http 連線、主機要求改用 https、Cloudflare 又用 http 連線，瀏覽器最後顯示「重新導向次數過多」。
三、MX 與 TXT 不受代理影響
同一份技術說明也寫明，只有 A、AAAA 與 CNAME 能開啟代理，MX 與 TXT 一律是「僅限 DNS」。所以搬到 Cloudflare 代管時，信箱與驗證用的記錄照原樣搬過去即可，不需要為它們調整雲朵。真正要注意的是搬遷當下有沒有漏抄：搬完之後，把 Cloudflare 上的記錄和你事前的備份逐筆對照，確認每一筆都在。
四、AI 爬蟲流量報表需要流量經過 Cloudflare
在 Sharing AI 後台，「AI 爬蟲流量」報表要統計 AI 爬蟲的造訪，需要網站流量經過 Cloudflare 才能統計，這是官方對這份報表的使用條件。如果你想使用這份報表，網站記錄就要維持已代理的狀態，並依官方的 Cloudflare 設定教學完成設定。以本站為例，網域就是透過 Cloudflare 代理，瀏覽器看到的是 Cloudflare 提供的邊緣憑證，網站與報表都能正常運作。
www 還是不帶 www？選定一個主網址
https://www.example.com 與 https://example.com 對訪客來說像是同一個網站，對搜尋引擎而言卻是兩個不同的網址。兩個版本都能開、內容又完全一樣，就形成重複網址；如果再加上 http 與 https 的組合，同一頁最多可能有四個版本。
Google 搜尋中心對整合重複網址的說明指出，永久重新導向是告訴 Google 哪個網址才是標準版本最強的訊號之一，而 Google 在條件相同時會優先選擇 HTTPS 網頁作為標準網址。因此正確的做法是：選定一個主網址，讓其他版本用 301 永久轉址導過去，並在網站內部連結、社群資料與廣告中一律使用這個主網址。
| 比較項目 | 使用 www | 不帶 www |
|---|---|---|
| 網址長度 | 多 4 個字元 | 較短，名片與口頭較好記 |
| DNS 設定彈性 | www 可以使用 CNAME，日後更換服務較方便 | 網域本身通常只能用 A 記錄（或代管商的攤平功能） |
| 常見情境 | 大型網站、子網域較多的企業 | 品牌網站、中小企業官網 |
| 搜尋表現 | 沒有先天差別，重點是全站一致 | 沒有先天差別，重點是全站一致 |
選哪一個都可以，真正重要的是「選定之後不要再變」。以本站為例，主網址是不帶 www 的版本，開啟 www 或 http 的網址都會被 301 轉到 https://sharing-pro.com/。完成綁定後，你可以用同樣的方法檢查：分別輸入四種組合，確認最後都停在同一個網址。
主網址確定後，記得在 Search Console 建立涵蓋所有版本的網域資源，這樣不論訪客從哪個版本進站，資料都會集中在同一處。網域資源需要用 DNS 的 TXT 記錄驗證，Google Search Console 教學一文整理了選擇資源類型與新增 TXT 驗證的完整步驟。
常見錯誤排查表：看症狀找原因
下表整理綁定網域時最常遇到的狀況。先對照症狀，再依「先看這裡」欄位檢查，大部分問題都能在幾分鐘內找到方向。
| 症狀 | 常見原因 | 先看這裡 | 處理方式 |
|---|---|---|---|
| 瀏覽器顯示找不到網站（DNS_PROBE 或 NXDOMAIN） | 名稱拼錯、記錄還沒生效，或在錯的後台修改 | 名稱伺服器屬於哪一家、記錄名稱是否正確 | 到正確的 DNS 後台補上記錄，等待 TTL 到期 |
| 有時是新網站、有時是舊網站 | 舊的 A 或 AAAA 記錄沒有刪乾淨，或快取尚未過期 | 同一個名稱是否有多筆 A／AAAA | 刪除指向舊主機的記錄，只留下平台要求的值 |
| 不帶 www 正常，www 打不開（或相反） | 只設定了其中一個名稱 | @ 與 www 是否都有記錄 | 補上缺少的記錄，再確認兩者都轉到主網址 |
| 瀏覽器顯示憑證錯誤或「不安全」 | 憑證尚未核發完成，或 CAA 擋住核發 | 後台是否已顯示「已通過，含 SSL」 | 等待系統驗證；超過一天仍未完成，附上 DNS 截圖洽客服 |
| 重新導向次數過多 | Cloudflare 使用「彈性」模式，或網域商轉址與平台轉址互相衝突 | Cloudflare 加密模式、網域商是否還有轉址設定 | 改用「完整」或「完整（嚴格）」，並移除網域商的轉址 |
| 網站正常，但公司信箱收不到信 | 清理記錄時把 MX 一起刪除 | 對照備份，MX 是否還在 | 依備份或郵件服務的說明補回 MX，信件恢復需要等待生效 |
| 網址是 https，網址列仍有警告 | 頁面中有 http 開頭的圖片或嵌入碼（混合內容） | 瀏覽器開發人員工具的警告訊息 | 把資源網址改成 https，或改用平台上傳的圖片 |
| 網站突然整個打不開 | 網域到期未續約，或 DNS 代管服務被變更 | 註冊商的網域狀態與到期日 | 立即續約並開啟自動續約，確認名稱伺服器未被更改 |
如果對照後仍找不到原因，請準備三樣東西再聯絡平台客服：DNS 管理頁的完整截圖、你看到的錯誤畫面，以及開始修改的大約時間。資訊越完整，客服越快能判斷問題在網域端還是平台端。
從舊網站換到新網域或新平台：保住既有的搜尋流量
如果網域原本就有網站，只是改用 Sharing AI 重新製作，綁定網域的同時還要處理一件事：舊網站的網址在 Google 已經累積了收錄與排名，新網站的網址結構若不同，舊網址就會變成找不到的頁面。
Google 搜尋中心的網站遷移說明建議，網址改變時使用伺服器端的永久重新導向（例如 301），事先建立舊網址到新網址的對照，並依對照更新內部連結與 Sitemap；重新導向一般要保留至少 1 年。如果連網域名稱都要更換，還要在 Search Console 針對舊網域提出「網址變更」要求。遷移期間能見度可能出現短暫波動，屬於正常現象。
- 綁定前：列出舊網站流量最高、外部連結最多的網址，作為對照表的優先項目
- 為每個舊網址指定新網址；沒有對應內容的，導向主題最接近的頁面，而不是一律導回首頁
- 切換網域後：逐一開啟對照表中的舊網址，確認都以 301 導到正確的新頁面
- 在 Search Console 檢查網頁索引與 Sitemap，觀察舊網址是否陸續被新網址取代
- 更換網域名稱時：舊網域續約保留，並在 Search Console 提出網址變更要求
在 Sharing AI 平台內修改頁面網址時，平台會自動建立 301 轉址；但從其他平台搬過來的舊網址，需要另外整理對照。如果你還在評估要不要趁換網域一起改版，公司網站什麼時候該改版整理了判斷時機與改版時最容易流失搜尋價值的地方。
綁定完成後：上線檢查與長期維護
看到「已通過，含 SSL」不代表工作結束。用下面這份清單做一次完整檢查，並把長期維護的責任交代清楚。
當天的上線檢查
- https 與 http、www 與不帶 www 四種組合，最後都停在同一個主網址
- 手機與電腦的網址列都顯示鎖頭，沒有混合內容警告
- 寄一封信到公司信箱、再從公司信箱寄一封出去，確認收發都正常
- 首頁、主要服務頁與聯絡表單都能開啟，表單通知寄到正確的信箱
- Search Console、GA4 等服務的驗證狀態沒有因為修改 DNS 而失效
- 名片、社群簡介、廣告與 Google 商家檔案上的網址，都更新為新的主網址
網站其他部分的上線前檢查，例如手機版、各頁標題描述與公開設定，可以搭配用 Sharing AI 架站上線前的檢查清單一起確認；若網站還在準備內容階段，也可以先看架站前要準備哪些品牌素材，把網域資訊列進公司資訊資料表。
長期維護：三件事交給專人
第一是續約。網域到期未續，網站與信箱會同時停擺，所以要開啟自動續約，並確認付款方式不會因為信用卡換卡而失效。第二是帳號安全。註冊商與 DNS 代管的帳號掌握了整個網域，務必開啟雙重驗證，並由公司內部至少兩人知道如何登入。第三是變更紀錄。每次修改 DNS 都記在前面的網域設定表上，下一個接手的人才知道每筆記錄的用途。
下一步：讓網站以正式網域開始累積
把這篇的順序濃縮成一句話：先備份，再清理，保留信箱，依後台值設定，耐心等待，最後四種網址組合逐一檢查。第一次操作大約只需要半小時，真正花時間的是等待生效，這段時間就用來更新名片、社群與廣告上的網址。
網域上線後，接著可以依照 Sharing AI 架站平台教學的學習路線，設定行銷代碼、規劃選單與頁面，並在 Search Console 提交 Sitemap。想先比較平台方案與功能，Sharing AI 架站平台介紹列出了各方案的差異；若希望由團隊協助完成網域串接、網站規劃與上線檢查，也可以參考分享家的網站設計服務，或直接與我們聯絡。