建站时選子域名還是二級目錄，常被当成個人偏好。但從爬虫和索引的角度看，它决定了你以後怎么分资源、怎么看資料、怎么排查收錄問题。
先明确一件事：索引的單位是 URL
搜尋引擎的索引以 URL 為單位，並不存在“整個站点被收錄了”這種狀態。不過在日常管理里，你看到的資料是被分组的：搜尋控制台按资源划分，a.example.com 和 example.com 往往是两個獨立资源，資料、抓取統計、sitemap 提交都分開。而 example.com/blog/ 這類二級目錄，仍留在同一個资源里。
這带来两個直接後果：
- 子域多了，你要分別看几套資料，驗證方式（DNS 或文件）也要分別做，容易漏掉某個子域的抓取異常。
- 二級目錄少了這层分割，但一個目錄出問题（比如大量參數頁、软 404）會消耗同一资源的抓取配額，影响也會扩散到同域其他目錄。
二級目錄：适合與主站强相關的内容
如果新内容是主站业務的延伸，比如帮助中心、博客、案例库，放在二級目錄通常更省事：
- 内鏈更好组织：主頁、列表頁到内容頁的連結都在同一域名下，爬虫顺着連結就能走進去。
- 配置集中：robots.txt 只有一份，sitemap、canonical、hreflang 都在同一套規則下维護。
- 資料集中：抓取統計和索引报告里能直接看到這個目錄的表現，不用来回切換资源。
需要注意目錄层級。像 /blog/2024/05/post-name/ 這種按時間堆叠的路径，如果年份目錄只做聚合、並没有獨立内容，可以考虑收敛，避免产生大量只有一两條連結的中間层。
子域名：适合獨立运营或技術栈不同的部分
子域並不等于“降權”，它更像一個獨立的站：
- 适合獨立团队、獨立系統（商城、社区、文档站）各自發布，改版时不需要對方配合。
- 風險隔离：某個子域出現大量低质頁面或被入侵，處理起来不至于牵動主域。
- 代價是發現路径容易變弱——主域和子域之間如果只有一個頁脚連結，爬虫和用戶都很难把两者联系起来。
所以使用子域时，跨域的連結和 canonical 要主動补齐：主站導航里给出子域入口，子域 sitemap 單獨提交，同时在各子域的搜尋控制台资源里分別观察索引覆盖情况。
移動站還要不要單獨用 m 子域
現在不建议再做 m 子域分离的移動站。响應式设計下只有一套 URL，不存在跨 URL 的收錄與規范問题；分离方案要维護两套地址、两套規范信号，出問题的环节明顯更多。如果歷史遗留已经是 m 子域，可以先用移動端 URL 與桌面 URL 的對應關系、配合 sitemap 标注来理顺，能合並的尽早合並。
决定前後可以逐項检查的事
- 内容归属：和主站主题强相關吗？强相關優先考虑目錄。
- 维護主体：谁负责發布和改版？如果不是同一個团队，子域的邊界更清晰。
- 發現路径：從主頁到该部分的連結，有没有出現在導航或面包屑里？
- 規范信号：跨子域的 canonical、sitemap 索引文件是否都指向最终地址？
- 資料口径：相關资源在搜尋控制台里是否都已驗證，便于對比抓取與索引資料。
结构一旦确定，尽量不要频繁搬迁。每一次跨子域或跨目錄的迁移，都會留下一批需要跟随的舊 URL，收錄的過渡期也會随之拉長。
结构選擇没有统一答案，判断标准其實很朴素：出問题时你能不能在一處看到它，能不能把改動一次做完。能集中管理的内容就放目錄，需要獨立运营的部分再拆子域，這比纠结哪種形式“更有利于收錄”更實际。