網域還是網址？一套分層判斷流程，避免 SEO 分析範圍設錯

週一晨會，主管把上週的搜尋報表投上螢幕，問了一句：「我們網域的自然流量為什麼往下掉？」你把圖表重看一遍，越看越不對勁：當初設定報表時，貼進工具欄位的不是網域，而是一整條網址，連路徑和追蹤參數都一起帶了進去。比較基準從源頭就設錯，這份數字回答不了「整個網站」的問題，只反映其中一頁的世界。（情境為示意改寫）

出錯的人不是不細心，是判斷方法停在「數符號」：掃一眼開頭有沒有 https://、找找字串裡有沒有斜線或問號，靠這幾個記號決定手上是網域還是網址。這套方法應付課本裡的標準例子勉強夠用，遇到邊界案例會同時失準。語言又再補一刀：中文口語的「網址」一詞，同時涵蓋 domain 和 URL 兩層，對話講得通，一站到英文介面的工具前，觀念就被壓扁，整條字串貼錯欄位的錯誤於是反覆發生。

先把答案說清楚。一條網址由協定、主機名稱、路徑與參數組成，網域是主機名稱裡那段向註冊商按年登記來的名字；兩者是上下階層，不是平行選項。層級分對，分析範圍才會對；層級貼錯，工具回給你的數字就是另一個世界。接下來先給一個反直覺的結論：在規格層級，網址甚至可以完全不含網域。然後依序拆解析、命名、生成、工具、搬遷五個層面，收在一張任務歸位表和一套五分鐘檢查。

快速重點：網域是命名系統裡按年登記的名字，網址是解析後指向單一資源的完整字串。判斷順序只有兩步：先認出手上那串字屬於哪一層，再宣告這次要分析的範圍。不數符號，不猜。

符號檢查的極限：肉眼看字串為什麼經常誤判

多數人判斷「這是網域還是網址」的方式，是檢查字串表面的記號：開頭有沒有協定、中間有沒有斜線、找不找得到問號或井字號。這些記號確實常見，但它們只是解析結果的旁證，不是本體。旁證在標準案例上湊巧齊全，一到邊界案例就一起失去鑑別力，誤判從這裡開始。

三種現場可以說明失準的樣子。第一種，整條帶參數的網址被貼進要求網域的欄位，報表的涵蓋範圍當場縮成一頁，看的人卻以為自己在看全站。第二種，以 IP 位址開頭的網址，例如 http://203.0.113.24/setup，從頭到尾沒有網域這個成員，掃協定、找名字全都落空。第三種，短連結服務回給你的那串字，外觀近似一個裸名字，實際上是一條會轉址的網址，真正的目的地要等轉址發生才揭曉，相關討論收在短網址的原理與風險。

符號之所以看起來可靠，是因為它們多半是解析的痕跡：協定固定出現在開頭、路徑一定跟在第一個斜線後面、參數掛在問號之後。痕跡與本體在標準案例上高度重疊，久了就被當成同一件事。問題出在重疊不是必然：規格允許的形式比日常經驗多，當一條網址以你沒見過的形式出現，記號就集體失效，這時需要的不是更銳利的眼睛，是把字串交給規格切開。還有一個記號常被賦予它扛不動的意義：協定。https 承諾的只有這段連線經過加密，並不背書站點的身份；申請憑證的門檻早已很低，仿冒站一樣用得起，要認組織，看的仍是主機名稱裡那段註冊名字，是否真的登記在該組織名下。

把這些案例放在一起看，問題不在眼力，在方法。符號檢查想回答的是「這串字是哪一種」，一個分類題；真正需要回答的是「解析之後，網域落在哪一格，我接下來的動作作用在哪一層」，一個定位題。分類題找特徵，定位題找層級，兩者需要的工具完全不同。往下就換掉這套肉眼方法，改用規格與機制來定位。

反直覺的核心答案：從屬關係，外加一個規格層級的例外

直接回答「網域跟網址是什麼關係」：在常見的 HTTPS 網址裡，整條字串是協定加主機名稱加路徑加參數的組合，網域是主機名稱的一部分，兩者不是二選一的並列，而是整體與其中一員的從屬。「網域等不等於網址」本身就是假問題；「網域落在哪裡、涵蓋到哪裡」才是真問題。

「涵蓋到哪裡」值得展開。說網域涵蓋網址，精確的意思是依賴關係：掛在同一個註冊名字底下的網址，共享這個名字的持有狀態與 DNS 指向；名字到期，全部受影響；名字移轉，全部跟著換手。說網址涵蓋網域，指的是組成關係：在常見形式裡，名字是主機名稱的一段，主機名稱是整條字串的一段。一個講依賴，一個講組成，兩個方向都對，混在一起就會打架。

從屬關係還有一個規格層級的例外，談它之前先把詞彙校準。IETF 的 RFC 3986 定義的是 URI 的通用語法，也就是識別字串的大家族，而網址是這個家族裡以定位方式指到資源的那個子集。這份語法把一條字串切分為 scheme、authority、path、query 等成員，並允許 authority 填入網域名稱以外的形式，IP 位址就是常見的一種。於是『每條網址都攜帶一個註冊網域』在規格上站不住；多數人熟悉的包含關係，是統計上的常態，不是規格的強制。

例外的實際長相並不神祕。內部系統常用 IP 直接定位主機，測試環境與部分舊服務尤其如此；這類字串照樣以定位方式指到資源，是不折不扣的網址，只是主機那一格填的是數字。另一種邊界更要留意：像 mailto: 這樣標記信箱的字串，遵守同一套 URI 語法，卻連位置都不提供，嚴格說屬於 URI 而不算網址。把這條線畫清楚，「網址包不包含網域」的討論才不會把整個 URI 家族都拖進來；對網址本身，比較務實的態度是：網域是常見成員，不是必要成員。

對 SEO 工作者來說，這個例外不只是冷知識。它決定了工具如何解讀你輸入的字串：貼一條以 IP 開頭的網址去查表現，工具找不到對應的註冊網域，行為可能出乎預期；把這條字串當成「打錯的網域」手動修改，反而破壞了原始資料。規格層的認識，用的時候就是在擋這類自作主張。

這個例外正是觀念的支點。既然網址可以不含網域，把兩者當成平行類別去「區分」，起點就偏了；正確的動作是解析那串字，確認網域在不在、在哪一格，再決定這次的判斷要落在哪一層。帶著這個定位框架，進到下一節的實際拆解。網址層的整體優化思路，可以對照SEO 網址優化指南。

照規格拆解字串，網域落在六個部件中的哪一格

要認出網域的位置，最直接的做法不是背口訣，而是親手把一條網址拆開看一次。拿一條示意網址當樣本：https://www.whoops.tw/guides/site-migration?from=edm#step1，整串先照規格切開，再逐格檢查網域落在其中哪一格。WHATWG 維護的 URL Standard 定義了瀏覽器實際採用的解析規則，下面六個部件的命名與切法都對齊這份規範。

六格裡沒有任何一格叫「網域」，這是刻意的：網域不是獨立部件，它住在主機名稱裡。主機名稱可以拆成子網域加註冊網域，www.whoops.tw 裡的 www 是子網域，whoops.tw 才是向註冊商登記的那段名字。而 www 常被誤當成網域的一部分，實際上它只是預設的子網域層，這層從屬關係的設定取捨，展開在www 與不加 www 的差異比較。

表格裡的連接埠平常看不見，因為 https 有預設值，省略不寫就是走 443；一旦站方指定了非預設的埠，它會以冒號加數字的形式出現在主機名稱後面。把這一格放進來，是為了讓拆解與規格完全對齊，也順帶回答「為什麼我看的網址沒有這一段」的疑惑。

再從控制權的角度讀一次這張表，層級感會更具體。協定與連接埠跟著主機設定走，搬一次主機可能就換一套；主機名稱跟著網域與 DNS 記錄走，站方最有主導權；路徑、查詢、錨點跟著網站結構走，是內容團隊每天在動的部分。六個部件對應三種控制節奏，誰能改、何時會改，回頭看表格右側就清楚。

註冊網域本身還能再切一刀：前半段的 whoops 是名字，結尾的 .tw 是後綴，兩段合起來才是登記的單位。這一刀在續約、移轉、議價時都用得到，是下一節的伏筆。各部件更細的設計討論，分散在兄弟篇：網址組成部件的拆解看整體結構，路徑設計對 SEO 的影響看斜線之後的走向，查詢參數與檢索浪費看問號之後的代價，HTTPS 在協定層的意義看第一格的選擇。

給這張表一個十秒的讀法：由前往後，先問連線（協定、連接埠），再問對象（主機名稱），再問內容（路徑、查詢、錨點）。網域卡在中間第二關，這也解釋了它的尷尬地位：它不是字串的起點，也不是字串的重點，卻是外人辨識「這是誰」的唯一依據。理解了它的位置，就理解了為什麼品牌討論都在這一格打轉。

三問定位：手上那串字，先判斷它是哪一層

拆解是理解用的，判斷要快。拿到任何一串字，照三個問題依序過一遍，十秒內可以定位它是註冊網域、主機名稱，還是完整網址；三問同時決定了你該怎麼回答別人的提問。

1. 第一問，照表切開：拿上一節的部件表當尺，把字串逐格對進去，看它實際佔了幾格。只落在「名字加後綴」一格的，屬名字層；從協定一路排到路徑與參數的，屬整條網址層。這個動作是對照規格，不是掃記號，也不必背口訣。
2. 第二問，看主機那一格：字串落在整條層時，再檢查主機名稱的形式：是註冊名字（含子網域），還是一串 IP？前者網域成員在場，後者不在場，正是前一節那個規格例外的日常版。
3. 第三問，對方語意：口語裡的「網址」指哪一層？同事說「把網址給我」，可能要整條字串，也可能只要名字；先確認對方要回答的問題在哪一層，再決定給整串或給名字。

三問的順序有講究：先切成員、再看主機形式、口語歧義放在收尾，因為前兩問的答案會直接限縮第三問的選項。示範一次：面對 whoops.tw，第一問只佔名字一格，屬名字層，第二問用不上，第三問看情境；面對 https://www.whoops.tw/guides/site-migration?from=edm#step1，第一問整排成員都在，是整條網址，第二問主機那格是 www.whoops.tw，網域是其中的 whoops.tw；面對 http://203.0.113.24/setup，同樣是整條網址，但主機那格填的是 IP，網域成員不在場。

第三問在團隊溝通裡最值得刻意練習。收到「幫我查一下這個網址」的訊息，回一句「你要看的是這一頁，還是整個名字底下的表現」，十秒鐘就能省下後續半小時的誤工；開會時聽到有人把名字和整條字串混著講，先在白板上把兩行字寫開再繼續討論，爭論常常自己消掉。把「名字層」「整串層」兩個詞寫進報表範本的欄位命名，是新進成員最快對齊的方法，看久了，不需要任何人解釋，欄位自己會教。定位做得順的人，不是記了很多規則，是把確認層級變成反射。

定位不是終點，是為了宣告範圍：知道手上是哪一層，才知道下一步的動作該作用在哪一層。網域層的完整觀念，包含命名、後綴選擇與持有成本，整理在網域觀念總覽。

名字如何變位址？IP、網域、網址的上下關係

三問定位了字串，往上還有一層問題：網域自己站在什麼上面？答案是一串數字。機器的世界以 IP 位址定址，這個家族 v4 與 v6 並存，品牌名在其中不具任何意義。名字與座標的對應寫在 DNS 記錄上：記錄多半指到位址，但也有 MX、TXT 這類與位址無關的用途；對應關係又可一對多、多對一，一個名字可以輪替多個位址，一個位址也可以同時服務多個站點，CDN 是後者的日常。人記不住數字，於是有了命名系統：向註冊商登記一個名字，再用 DNS 把名字解析到記錄指向的目標。網址則在這之上，是指向單一資源的完整地址。

這個分層解釋了一件常被問的事：換主機、換 IP，網域不用跟著換。名字與數字的對應寫在 DNS 記錄裡，記錄改指向新 IP，訪客手中的名字依然有效；切換期間的風險來自快取與設定錯誤，不來自名字本身。DNS 的運作細節與常見故障，整理在DNS 原理與排錯。

名字也不是買斷的。以 ICANN 說明的典型頂級網域生命週期為例：到期後先進入寬限期，這段時間補續約即可；寬限期一過進入贖回期，取回名字的手續更貴、時間更長；贖回期結束，名字被釋出公開，任何人都能登記，而各階段的實際天數與處理方式，依後綴類型與註冊商而異。掛在這個名字底下的網址，會在同一刻全部失去依附。經營上因此有三個基本動作：自動續約要開、到期通知的信箱要有人收、註冊商帳號的權限要有人管。

持有名字的成本不高，好名字的競爭卻一直都在。Verisign 每季整理的網域產業簡報長年追蹤頂級網域的註冊量，規模維持在數億等級，意味著好讀、好記的名字持續有人登記，命名決策不宜無限期拖延。

名字的持有狀態也會流動。同一個名字可以從一家註冊商移轉到另一家，移轉有冷卻期與確認信流程，防的就是被冒名搬走；持有人的聯絡信箱換人時，註冊資料要跟著更新，否則重要的通知會寄進沒有人開的信箱。這些細節平常看不見，出事時全部一次浮上檯面，而浮上檯面的那一天，通常就是網址集體失蹤的那一天。

把三層疊起來，長期性的推論就浮出來：網域層的決策，名字、後綴、持有安排，一旦確定，所有網址都跟著走；要改，代價也在所有網址上結算。這是網域值得謹慎對待的機制理由，不是情懷。搜尋引擎評估站點時累積的信任，很大一部分掛在網域這個實體上，這個觀點的完整討論在E-E-A-T 指南；登記、續約與移轉的實務步驟，整理在網域申請與續約攻略。

網址的生產機制：站方每天都在製造新的識別字串

網域按年持有，網址是另一種存在方式：流程的產物。內容管理系統每發一篇文章、每開一個分類、每次套上篩選條件或追蹤參數，都會組出一條新的網址。沒有人核准，沒有數量上限，站方營運的每一天都在生產識別字串。稀缺性這個概念，在網址層不成立。

增生最快的是參數。一個商品列表頁掛上三種篩選器，每種五個選項，能組合出的字串數量就以乘法累積；再疊上排序、分頁、追蹤來源，同一份內容背後可能站著幾十條網址。檢索系統把發現的字串逐一登記進待辦，登記不等於立刻抓取，但清單越長，每一條分到的注意就越薄，重複的版本一多，真正重要的頁面最先被排擠。這也是參數治理被歸在網址層的原因：問題在字串的生成，解法也在字串的收斂。

同一份內容掛多條網址，是生產機制的直接延伸：參數版本、分頁版本、行動版路徑，都可能指向同一頁內容。這是重複內容與檢索浪費的來源，屬於網址層的問題，用網址層的工具解：以 canonical 指定主要版本，讓重複內容的判斷與處理有明確的收斂規則，具體作法展開在canonical 設定指南。

永久連結是生產紀律裡最重要的一條。它本質上就是網址，差別在於站方承諾它長期不變；承諾的價值在累積，外部連結、書籤、檢索結果都指向這條字串，改一次，累積就斷一次。WordPress 站的對應設定，整理在永久連結設定教學。

「改網址有成本」的機制理由也在這裡：網址一旦被外部連結與索引引用，更動就產生對應的負債，每一條被引用的舊網址，都需要一條轉址或一次放棄的決定。這個負債觀念，直接鋪往搬遷的主題。

負債也可以量化成一個簡單的問題：這條網址被多少人依賴？外部連結算一份，書籤與分享算一份，檢索結果裡的位置算一份。依賴越多，改動前要安排的接手動作越多；依賴趨近於零的新頁面，改起來幾乎沒有感覺。把「要不要改網址」換成「這條網址有多少人依賴」，決策會自動浮出尺度。

工具欄位是範圍宣告：三個提問者，三種正確層級

觀念落地的地方，是每天在用的工具。把工具的欄位理解成「範圍的宣告」，分層判斷就有了施力點：同一個網站，老闆問品牌整體、同事問某一頁、工程師問主機設定，三個人該看的是三個層級，填進欄位的字串也跟著不同。

Search Console 用兩種資源類型把範圍畫給你看：網域資源涵蓋註冊網域下全部子網域與兩種協定，驗證走 DNS；網址前置資源則以你填入的前綴為精確邊界：協定固定一種，多一個前綴都不行。Google 官方對資源類型的說明把這條邊界寫得很明白。整個安裝與設定流程，展開在Search Console 設定教學。

兩種資源不是二選一，多數認真經營的站兩種都會有：網域資源看全貌，網址前置資源做單點驗證與特定協定的追蹤。真正要避免的，是以為設了一種就等於看到全部；範圍的邊界不會自己跳出來提醒你，它只會在數字對不起來的時候，隱約讓你覺得哪裡怪。

Ahrefs 的 Site Explorer 把範圍宣告做成了模式選單：以 whoops.tw 為例，*.whoops.tw/*、whoops.tw/*、Prefix、URL 四個選項，前兩個的差別在子網域算不算進來，後兩個在於比到哪一段為止，Ahrefs 對分析模式的說明把每個選項的邊界逐一畫明。名字最像的兩個網域類選項，反向連結的帳面可以差一截，這也是把模式選單當成範圍宣告來讀、而非視為普通按鈕的理由。觀念與查法，先看反向連結基礎攻略。

模式切換還有一條容易被輕忽的紀律：同一份報告裡的數字，必須來自同一個層級。把網域模式的連結總數和精確模式的單頁點擊放在同一張投影片比較，數字都對，結論一定錯；在報表上標註資料範圍的習慣，跟數字本身一樣值錢。養成在每張表頭寫下範圍的動作，跨層混用的事故會少一大半。

一個情境說明代價。（情境為示意改寫）某電商站的行銷把一整條帶參數的網址貼進該填網域的欄位，報表從此只反映一頁的世界，團隊卻拿它當全站體質討論了兩個月，結論全數失真。補救只有一句話：重新宣告範圍，重新跑數字。

「索引的單位是網址」是同一條線的推論：檢索預算按網址一條條消耗，配置思路在檢索預算的分配邏輯；單一網址的索引狀態與修復，用網址檢查工具逐條進行。解讀排名走勢與站內行為時，同樣先確認指標作用的層級，分別對照排名數據的解讀方法與行為指標的判讀。

搬家那天：一條網址對一條網址，不是一個名字換一個名字

搬家當天最容易漏掉的一件事：換名字只是行政作業，逐頁搬遷才是工程。名字指向新位置，幾個小時就會生效；但每一條舊網址都必須指定一條新網址、各自掛上 301，訪客與檢索器才走得回來。這條逐頁對應的路徑，就是搬遷日真正要驗收的工程。

轉址本身不是懲罰。Google Search Central 在網站搬移的官方指引裡說明：301 這類永久轉址不會自行損失 PageRank，搬移完成的時間依網站規模與重新檢索的速度而定，沒有固定時程；指引同時要求仍有對應內容的舊頁面各自指向新頁面，避免全部導向新首頁。會讓表現受傷的不是轉址工具，而是沒有做完的對應。

實務上的排序因此很清楚：先盤點有流量與有外部連結的網址，優先為它們建對應，再往下處理長尾頁面。大型搬遷專案裡，新舊網址對應表的建置是最花工時、也最不能省的一步，它決定了前一段提的負債會被清償，還是直接違約。完整的搬遷戰略，從風險盤點到驗收，整理在網站搬遷攻略。

對應表本身不需要複雜，需要的只是完整。四個欄位就夠：舊網址、新網址、轉址類型、驗收狀態；來源用兩份資料交會比對，檢索紀錄裡出現過的網址一份，外部工具查到有連結進來的網址一份，兩邊聯集減去重複，就是需要處理的全集。漏掉任何一條，那一條就會在搬遷後變成訪客眼裡的斷點，而且是無聲的斷點：沒有人會回報，人只會離開。

新單元上線前，掛子網域還是子目錄？

結構選擇最常見的版本：新的部落格、文件站或會員區，要掛在子網域還是子目錄？這個問題的本質，是把新單元放進結構裡的哪一層。而它經常被一個未經證實的前提綁架：子目錄會自動繼承整個網域的表現。

官方立場先擺上桌。Google Search Central 在檢索與索引的常見問題裡表明：對子網域與子目錄的索引和排名沒有偏好。這一句話拆掉了爭論的前提，決策不該由假想的檢索器偏好決定，而該回到組織與維運的現實條件。

把現實條件整理成四條檢核，逐條回答比風向辯論有用：這塊內容由同一個團隊經營嗎？它需要與主站共用導覽與數據分析嗎？它的部署節奏或系統需要獨立嗎？品牌上有明確切割的需求嗎？前兩條偏向子目錄，後兩條偏向子網域，權重由組織現況決定。兩種結構的完整比較，展開在子網域與子目錄的取捨分析。

四條檢核的答案不同，後續的負擔也不同。選子目錄，導覽、權限、分析可以整套共用，代價是新單元的技術債直接算在主站頭上，部署節奏被綁在一起；選子網域，部署與權限乾淨切割，代價是內部連結要刻意維護、數據要分開合併。沒有一邊免費，把負擔講清楚，選擇才會踏實。

多語系網站是同一組抉擇的高頻場景：不同語言的版本要放子目錄、子網域還是各自的位置，牽動 hreflang 標記與數據歸屬，可以對照hreflang 標記方式與多語系網站的結構規劃。

任務歸位表與誤判現場：數字沒錯，是範圍錯了

把全文的判斷收斂成一張歸位表。遇到任何 SEO 任務，先判斷它屬於哪一層，再決定第一個動作；表按報表解讀、風險控管、結構規劃三類分組，涵蓋最常見的提問。

顯示層還有一個值得知道的角落：搜尋結果頁上以網域加路徑呈現的麵包屑，是站方少數能主動提供結構資料、有機會爭取到的版面位置，提不提供、怎麼呈現，最終仍由搜尋引擎決定。Backlinko 在 2025 年 4 月更新的Google 點擊率分析顯示，點擊率隨排名位置急遽下滑，每個位置的能見度都值得爭；同系列的排名因素分析也印證分層的讀法：因素本來就分成網站層級與單頁層級兩群，看任何建議時先分辨它落在哪一群。結果頁版面的運作，延伸看SERP 的組成。

三個誤判現場，都是範圍設錯的實例。（以下情境為示意改寫，站點已匿名）其一，某電商站把整條網址貼進網域欄位，報表被當成全站體質用了半年，補救動作是重設工具模式、以正確層級重跑數字。其二，某媒體站只驗證了主網域的資源，子網域上聲量最大的頻道整個消失在報表外，補救是補設涵蓋完整的資源類型。其三，某零售站拿網址前置資源的數據回答品牌整體的問題，跨期間比較全部失真，補救是重建比較區間並標明範圍。

三個現場的數字都沒有錯，錯的是範圍。工具忠實回答了被問到的問題，只是那個問題從來不是提問者心裡的問題；範圍一修正，同樣的數字立刻從誤導變成線索。這也是分層判斷的實際價值：它不給你新的數據，只讓既有的數據回到能回答問題的位置上，而多數時候，你缺的從來不是數據，是位置。

五分鐘分層檢查，把兩個提問固化成流程

觀念要能重複執行才有價值。把它固化成兩個提問加三個步驟，每次開工具前跑一遍，五分鐘內結束。

兩個提問是核心。遇到一串字，先問：解析之後，網域落在哪一格？要做一個 SEO 動作，再問：這個動作作用在網域層還是網址層？第一問防止貼錯欄位，第二問防止用錯工具。

1. 開表前寫下層級。叫出任何報表前，先用一句話寫下這次看的是哪一層；寫不出來，表示問題本身還沒定義清楚。
2. 盤點資源涵蓋範圍。確認 Search Console 的資源類型真的涵蓋這次的分析範圍，子網域與協定有沒有漏在門外。
3. 抽查三條重要網址。挑流量或連結最高的三條，確認 canonical 指向與轉址狀態；索引單位是網址，問題也會在網址上現形。

兩層的關係不是對立，是互相放大：網域層的體質決定上限，網址層的紀律決定兌現，缺了哪一層，另一層的努力都會漏氣。分層判斷是 SEO 的底層手感，手感養成之後，註冊、驗證、報表、搬遷這些場景會自然各就各位。還在從零起步的讀者，可以先走過從零開始架站的流程；要把分層放進更大的地圖，就接著讀SEO 完整指南。