網站架構雜亂、頁面載入過慢、Sitemap 設定錯誤、Canonical 指錯標準頁，這些技術 SEO 細節看似不起眼，卻直接決定 Google、ChatGPT、Perplexity 能否順利讀懂您的網站。本文完整解析網站架構、速度優化、行動索引、檢索控制等十二大主題，協助您在 AI 搜尋時代打穩網站技術基礎。本文屬於《新視野 SEO 完整指南》系列，完整框架請參考「SEO 是什麼？完整指南」。
本篇目錄
網站架構規劃與 URL 設計原則
為什麼網站架構是技術 SEO 的基礎
網站架構（Site Architecture）是指網站內頁面的層級關係、分類方式與連結邏輯。它不只是資訊整理問題，更直接影響搜尋引擎是否能順利檢索與理解您的網站。
在 AI 搜尋時代，Google AI Overviews、ChatGPT Search、Perplexity 等工具更依賴清楚的架構訊號，才能準確判讀網站主題並引用內容。
良好的網站架構必須同時滿足兩個核心目標：讓使用者快速找到資訊，並讓搜尋引擎清楚掌握網站主題脈絡。
扁平化架構與三次點擊原則
理想架構應採取扁平化設計，讓使用者或爬蟲在較少點擊內抵達重要頁面，常見指標為三次點擊原則。扁平化的優勢來自三個層面：提升爬蟲發現效率、優化內部權重傳遞、降低使用者跳出率。
反過來說，層級愈深的頁面，愈可能因為入口不足而長期停留在索引邊緣。實務上經常看到的情況是：內容本身品質不差，但被埋在五、六層之下，搜尋引擎幾乎不會定期回訪。
應避免：首頁 → 分類 → 子分類 → 次子分類 → 年份 → 月份 → 文章頁
分類與導覽規劃的三個原則
- 分類具備明確區隔 避免不同分類之間界線模糊。若搜尋引擎難以判斷網站主題分工，使用者也無法快速理解內容定位。
- 站在使用者角度命名 使用市場常見、具有搜尋需求的詞彙，而非企業內部術語或過度抽象的名稱，例如用「網頁設計」而非「品牌數位化解決方案」。
- 主分類控制在 7 至 8 個以內 過多選項會增加選擇負擔，也分散網站主題焦點與內部權重配置。對台灣中小企業官網而言，5 至 7 個主分類通常已足夠涵蓋核心服務。
麵包屑導覽（Breadcrumb）
麵包屑導覽顯示頁面路徑層級，例如：首頁 > 網頁設計 > RWD 響應式設計。對使用者而言，它提供返回上層的便利路徑；對搜尋引擎而言，它有助於理解頁面在整體網站中的角色。
若搭配 BreadcrumbList 結構化資料，搜尋結果中還可能直接顯示麵包屑路徑，提升點擊率。
URL 設計五大原則
URL 是頁面的唯一地址，也是搜尋引擎理解內容的重要輔助訊號。關於 URL 結構與命名的完整原則可參考專文。優良 URL 應具備以下五項特性：
-
簡潔且具描述性
使用者看到網址時應能理解頁面主題。
較佳：
example.com/web-design/responsive-design
較差：example.com/cat/sub-cat/post?id=12847&ref=nav - 統一使用英文小寫與連字號 使用連字號作為單字分隔，避免空格、底線或中文網址。雖然搜尋引擎能辨識中文 URL，但分享與複製時常因編碼問題降低可讀性。
- 反映網站結構 URL 路徑最好與網站分類邏輯一致，讓使用者與搜尋引擎能從網址本身理解頁面所屬脈絡。
-
避免不必要的參數
若大量使用動態參數如
?id=123&sort=date，可能增加重複內容風險。若參數無法避免，應搭配 Canonical 指定標準版本。 - 維持穩定性 URL 一旦被索引，原則上不應頻繁更動。必須修改時，務必同步設定 301 永久轉址。
內部連結是架構策略而非單純連結
內部連結並非單純的「加超連結」，而是一套協助搜尋引擎理解內容關聯的結構策略。重要頁面應獲得更多內部連結支持，主題相近的頁面應形成內容群集（Topic Cluster）。
新發布的內容也應從既有重要頁面導入連結，協助搜尋引擎更快發現。同時應避免出現孤立頁面（Orphan Pages），這類頁面即使存在，也可能因檢索入口不足而難以獲得曝光。
網站速度優化與 Core Web Vitals
速度為什麼會影響 SEO
網站速度早已不是工程議題，而是排名與商業成效的關鍵指標。Google 很早就將速度納入排名考量，而在 Page Experience 更新之後，Core Web Vitals 進一步成為正式的頁面體驗訊號。
實務數據顯示，行動裝置上頁面載入時間每延遲 1 秒，轉換率可能明顯下滑。對台灣中小企業電商而言，速度延遲常直接影響詢價、註冊、購物等轉換表現。
Core Web Vitals 三大指標一覽
| 指標 | 衡量項目 | 良好 | 需改善 | 不佳 |
|---|---|---|---|---|
| LCP | 最大內容繪製速度 | ≤ 2.5 秒 | 2.5 至 4 秒 | > 4 秒 |
| INP | 互動到下一次繪製 | ≤ 200 毫秒 | 200 至 500 毫秒 | > 500 毫秒 |
| CLS | 累計版面位移 | ≤ 0.1 | 0.1 至 0.25 | > 0.25 |
LCP 最大內容繪製
衡量頁面主要內容出現在畫面中的速度，通常是主圖或主視覺區塊完成顯示的時間。常見過慢原因包括伺服器回應過長、圖片過大、CSS 或 JavaScript 阻擋渲染等。
INP 互動到下一次繪製
衡量頁面對使用者操作的反應速度，例如點擊按鈕、展開選單後介面是否快速回應。INP 表現不佳常與主執行緒被 JavaScript 占用、第三方腳本過多、DOM 操作過重有關。
CLS 累計版面位移
衡量頁面載入過程中的版面穩定性。常見成因包括圖片或影片未預留尺寸、字型載入造成跳動、動態插入廣告或嵌入模組等。
換個角度理解：LCP 決定使用者願不願意等，INP 決定願不願意操作，CLS 決定會不會點錯。三者分別對應載入、互動與穩定三種體驗面向，優化方向也各不相同。
網站速度優化的四大方向
常用速度檢測工具
- Google PageSpeed Insights：提供 Core Web Vitals 實測數據與優化建議。
- Google Search Console Core Web Vitals 報告：協助檢查整站效能問題。
- Lighthouse：適合用於單頁效能分析。
- WebPageTest：提供更細緻的瀑布圖與多情境測試。
行動裝置優先索引（Mobile-First Indexing）
什麼是行動優先索引
Google 已將多數網站切換為行動優先索引。也就是說，搜尋引擎會以行動版內容作為主要索引與排名依據，而非桌面版內容。
換言之，即使使用者最終在桌面裝置上搜尋，Google 仍會優先參考手機版頁面的內容品質與結構完整性。手機版少掉的內容，等同於搜尋引擎沒有看過。
行動優先索引的核心原則
行動版內容不可明顯少於桌面版內容。若桌面版保留完整文字、FAQ、表格、結構化資料，但行動版因版面考量大幅刪減，搜尋引擎僅會根據行動版進行評估，進而影響頁面價值判斷。
除了本文內容，結構化資料、Meta 標籤、圖片 ALT、影片資訊都應在行動版完整保留，並與桌面版維持一致。
響應式設計是最佳做法
Google 最推薦的做法是響應式網頁設計（Responsive Web Design），也就是使用相同 HTML 與相同 URL，透過 CSS 依裝置尺寸調整版面。
其優勢包括：避免多版本網址管理的 SEO 複雜度、降低桌機版與手機版內容不同步的風險、維護與開發效率更高。
行動體驗五大檢查重點
- 按鈕與連結是否足夠大，建議至少 48×48 像素，避免誤觸。
- 文字尺寸是否清楚易讀，內文建議至少 16px。
- 是否存在影響閱讀的蓋版廣告或過度干擾的彈出視窗。
- 內容是否不需水平捲動即可完整閱讀。
- 表格、圖表與互動元件在小螢幕上是否仍具良好操作體驗。
<head> 具備 viewport 設定，否則所有響應式斷點都不會生效，Search Console 會直接回報「viewport 未設定」與「內容寬度超出螢幕」。
SSL 與 HTTPS 安全性設定
HTTPS 已是基本門檻而非加分項
Google 早已將 HTTPS 視為排名訊號，而在現今網站環境中，它更接近基本門檻。若網站仍停留在 HTTP，瀏覽器會顯示不安全警示，直接削弱使用者對品牌的信任感。
SSL 憑證類型比較
| 類型 | 驗證範圍 | 適用情境 | SEO 影響 |
|---|---|---|---|
| DV | 網域所有權 | 一般企業官網、部落格 | 無明顯差異 |
| OV | 網域加上企業身分 | 中型企業、會員平台 | 無明顯差異 |
| EV | 完整企業驗證 | 金融、電商高敏感網站 | 無明顯差異 |
從 SEO 角度，這三種憑證沒有明確排名差異。真正重要的是是否穩定、安全且正確地完成 HTTPS 部署。
HTTPS 遷移檢查清單
- 將所有 HTTP 頁面以 301 轉址至 HTTPS 版本。
- 更新網站內部連結。
- 更新 XML Sitemap。
- 確認 Canonical 指向 HTTPS 版本。
- 重新在 Google Search Console 驗證 HTTPS 屬性。
- 更新 robots.txt 中的 Sitemap 路徑。
- 檢查 CSS、JavaScript、圖片資源是否仍引用 HTTP，避免 Mixed Content 問題。
XML Sitemap 建立與提交
XML Sitemap 是什麼
XML Sitemap 是提供給搜尋引擎的網站地圖，用來列出希望被檢索與索引的重要頁面，協助搜尋引擎更有效率地掌握網站內容。對大型網站、新網站、更新頻繁網站或架構複雜網站尤其重要。
Sitemap 主要欄位
<loc>：頁面完整網址，是最重要的欄位<lastmod>：最後修改日期，須反映實際更新<changefreq>：預期更新頻率<priority>：頁面相對重要性
<changefreq> 與 <priority> 的參考價值有限。而 <lastmod> 雖然重要，但前提是日期必須反映實際內容更新，而非為了表面維護頻率而任意更新。
Sitemap 最佳做法
Sitemap 應僅列出真正希望被索引的正式頁面，所有 URL 應正常回傳 200 狀態碼。不應納入以下類型頁面：
- noindex 頁面
- 被 robots.txt 阻擋的頁面
- 404 頁面
- 已 301 轉址的舊網址
若網站超過單一 Sitemap 限制，也就是 50,000 個 URL 或 50MB，建議使用 Sitemap Index，並依內容類型拆分，例如文章、商品、分類頁分別建立。
內容更新頻繁的網站建議由 CMS 自動生成 Sitemap，降低人工維護風險。完成後，應提交至 Google Search Console 並在 robots.txt 中標示路徑。
圖片 Sitemap 與影片 Sitemap
若網站包含大量圖片或影片，可額外建立圖片 Sitemap 或影片 Sitemap，有助搜尋引擎更完整理解媒體資源，提升圖片搜尋或影片搜尋的曝光機會。
robots.txt 設定與檢索控制
robots.txt 的作用
robots.txt 是放置於網站根目錄的純文字檔案，用來告知搜尋引擎哪些路徑可檢索、哪些不建議檢索。搜尋引擎通常會先讀取 robots.txt，再決定後續檢索策略。
基本語法
- User-agent：指定規則適用的爬蟲
- Disallow：禁止檢索某一路徑
- Allow：在限制範圍內允許特定路徑
- Sitemap：告知 XML Sitemap 的位置
常見設定情境
- 管理後台與登入頁面通常不需要被檢索
- 站內搜尋結果頁不建議索引，避免形成大量低品質頁面
- 篩選與排序產生的大量參數頁應視情況控制
- 測試站或開發站應明確阻擋，避免被意外收錄
實務上建議把頁面先分成三類再決定工具：正式頁面用 Sitemap 主動推播，後台與工具頁用 robots.txt 節省檢索資源，短期活動頁或不希望曝光的頁面則用 noindex 控制索引。三者分工不同，不可互相取代。
三大常見錯誤
- 誤擋重要頁面 Disallow 規則設定錯誤，可能使整個重要目錄無法被搜尋引擎檢索。這是改版上線後的常見錯誤，務必檢查確認。
-
將 Disallow 視為 noindex
Disallow 只是阻止爬蟲抓取內容，並不保證頁面不會出現在搜尋結果中。若目的是避免索引，應透過
noindexmeta 標籤處理。 - 阻擋 CSS 或 JavaScript 阻擋這些檔案可能影響搜尋引擎正確渲染頁面內容，進而錯誤判讀網站體驗品質。
Canonical 標籤與重複內容處理
重複內容為什麼需要處理
重複內容是指不同 URL 呈現相同或高度相似的內容。這在實務中十分常見，例如：
- HTTP 與 HTTPS 並存
- 網址有無結尾斜線（
/page與/page/） - 商品篩選參數產生多版本
- 列印頁與正式頁共存
- 改版後新舊網址未整合
若未妥善處理，搜尋引擎可能難以判斷哪一頁才是標準版本，進而分散權重、浪費檢索資源，甚至影響索引判斷。
Canonical 的作用
Canonical 標籤放在 HTML <head> 區塊，用來告知搜尋引擎某頁面的標準版本 URL：
<link rel="canonical" href="https://example.com/page/" />
透過 Canonical，可協助搜尋引擎將相似頁面的訊號集中於指定的正式版本。
Canonical 四大使用原則
- 每個頁面都建議設置 Canonical 即使只有單一版本，也建議採用 self-referencing canonical 指向自己。
- 應指向可索引、可正常開啟的正式頁面 不可指向 404、noindex 或被 robots.txt 阻擋的頁面，否則訊號會被忽略。
-
使用完整的絕對網址
應使用
https://example.com/page/而非相對路徑/page/。 - 同組重複內容應一致指向同一標準頁 否則訊號分散，Canonical 效果會被削弱。
其他處理重複內容的方法
- 若舊網址已不再使用，最直接的方式是設定 301 轉址
- 若頁面不希望出現在搜尋結果中，使用 noindex
- 若問題來自大量參數網址，應從網站架構與參數管理策略上優化
Hreflang 多語系與多地區設定
Hreflang 的用途
Hreflang 用來告知搜尋引擎：同一內容存在不同語言或不同地區版本，協助 Google 將最適合的頁面顯示給相對應的使用者。例如台灣使用者應優先看到繁體中文版，日本使用者應對應顯示日文頁面。
適用情境
- 多語系網站，例如中文、英文、日文三種語言版本
- 多地區但同語言網站，例如 zh-TW 與 zh-HK
- 同時面向多語言與多市場的國際型網站
三大常見錯誤
- 缺少回指標籤（Return Tag） A 頁指向 B 頁，但 B 頁未反向指回 A 頁，導致設定不被完整採納。Hreflang 必須雙向對應。
-
語言碼或地區碼格式錯誤
例如大小寫錯誤、使用底線（
zh_TW）而非連字號（zh-TW），都會導致設定失效。 - Hreflang 與 Canonical 衝突 每個語言版本的 Canonical 應指向自己，而非指向其他語系頁面，否則會削弱該語言版本的存在價值。
x-default 作為預設版本，以便在搜尋引擎無法明確判斷語言或地區時提供對應頁面。
台灣企業常見應用組合
301 與 302 轉址策略與常見錯誤
常見轉址類型比較
| 狀態碼 | 性質 | 適用情境 | 權重傳遞 |
|---|---|---|---|
| 301 | 永久轉址 | 網址永久更換、改版、頁面整併 | 幾乎完整傳遞 |
| 302 | 暫時轉址 | 短期活動、測試、暫時導流 | 不傳遞 |
| 307 | 暫時轉址（嚴謹） | 與 302 相似但 HTTP 方法不變 | 不傳遞 |
| 308 | 永久轉址（嚴謹） | 與 301 相似但 HTTP 方法不變 | 幾乎完整傳遞 |
從 SEO 角度，最重要的是正確區分「永久變更」與「暫時變更」兩種情境。
應使用 301 的情境
- 網站更換網址
- 網站改版後頁面重新對應
- HTTP 遷移至 HTTPS
- 舊頁面下線並導向新頁
- 相近內容頁整併至同一正式頁
可使用 302 的情境
- 短期活動頁導流，例如購物節或週年慶
- A/B 測試
- 暫時性維護
- 短期地區分流
四大常見錯誤
轉址真正的價值在於一次到位：舊網址一對一指向最相關的新頁面，中間不繞路、不迴圈，也不要把大量舊頁草率導回首頁。以下四種寫法是實務上最常見的失分點。
- 永久改址卻使用 302 導致搜尋引擎誤以為舊頁仍是正式版本，延後權重移轉與索引更新。
- 轉址鏈（Redirect Chain） 例如 A → B → C → D。不只增加載入時間，也浪費搜尋引擎檢索資源。理想做法是直接由 A 指向 D。
- 轉址迴圈（Redirect Loop） 例如 A 指向 B、B 又指回 A，造成頁面無法開啟，使用者與爬蟲皆會卡在迴圈中。
- 大量舊頁一律導向首頁 這類做法通常無法有效保留頁面價值，甚至可能被視為軟性 404（Soft 404）。較合理的方式，是將舊頁一對一導向最相關的新頁面。
網站可檢索性診斷與除錯
可檢索性是技術 SEO 的第一步
若搜尋引擎無法順利檢索網站，後續的索引、理解與排名都將失去基礎。可檢索性可說是技術 SEO 的第一道檢查關卡。
常見的可檢索性問題
- 伺服器頻繁回傳 500、502、503，導致 Google 降低檢索頻率
- 大量重要舊網址失效且未妥善轉向，浪費外部連結價值
- robots.txt 設定錯誤，誤擋重要頁面
- 忘記移除測試環境的 noindex 標籤，這是改版上線後最常見的災難
- Canonical 指向錯誤頁面
- 重要頁面缺乏內部連結支持，形成孤立頁面
常用診斷工具
建議的診斷流程
技術 SEO 檢查不宜零散，建議依以下順序系統化進行：
- 確認 robots.txt 是否誤擋重要頁面 這是最常見也最容易修復的問題。
- 檢查 Sitemap 是否正確且可提交 確保所有重要頁面都被列入，且 URL 都回傳 200 狀態碼。
- 查看 Search Console 索引狀態 檢視覆蓋率報告，了解哪些頁面被排除以及排除原因。
- 使用爬蟲工具掃描整站 找出技術層面的細部問題，例如斷鏈、轉址鏈、重複內容。
- 檢查 Core Web Vitals 與結構化資料 從「可被檢索」進階到「可被理解與排名」。
JavaScript SEO 與動態渲染
為什麼 JavaScript 會影響 SEO
現代網站常使用 React、Vue、Angular、Next.js、Nuxt.js 等前端框架，以提供更流暢的互動體驗。然而，這些技術也可能增加搜尋引擎讀取內容的難度。
傳統網站在首次載入時就提供完整 HTML，而 JavaScript 架構網站常需先執行腳本後才生成完整內容。若搜尋引擎無法及時完成渲染，便可能導致內容檢索延遲，甚至部分資訊無法被讀取。
在 AI 搜尋時代，ChatGPT、Perplexity 等工具對 JavaScript 渲染的支援更為有限，純前端渲染的內容很可能無法被引用。
Google 如何處理 JavaScript
Google 具備執行 JavaScript 的能力，但並非毫無限制。其處理流程分為兩階段：
- 第一階段：抓取初始 HTML
- 第二階段：排程執行 JavaScript 進行渲染
這代表若頁面主要內容依賴 JavaScript 動態產生，索引速度往往較慢。此外，JavaScript 渲染需要更多運算資源，並非所有頁面都能在短時間內完整處理。
可參考 Google Search Central 官方文件了解 Googlebot 處理 JavaScript 的最新規範。
四大常見解法
各種解法的差別，關鍵在於內容究竟在哪個階段生成：愈早產出完整 HTML，搜尋引擎與 AI 工具就愈容易讀到；完全依賴瀏覽器端渲染的內容，索引速度最慢也最不穩定。
- 伺服器端渲染（SSR） 由伺服器先產出完整 HTML，再交瀏覽器載入。這是對 SEO 較友善的做法之一，Next.js 與 Nuxt.js 皆支援。
- 靜態網站生成（SSG） 在網站建置階段預先產出靜態 HTML，速度快、穩定性高。適合部落格、品牌官網與知識型網站。
- 增量靜態更新（ISR） 兼顧靜態輸出速度與內容更新彈性，適合希望平衡效能與維護效率的網站。
- 動態渲染（Dynamic Rendering） 針對搜尋引擎與一般使用者提供不同版本，可作為過渡解法，但不建議作為長期依賴方案。
JavaScript SEO 檢查重點
- 重要內容不應完全依賴客戶端 JavaScript 才顯示
- 內部連結應使用標準
<a href>標記，而非依賴 onClick 事件 - Title、Description、Canonical、hreflang 等關鍵標籤應可被搜尋引擎正確讀取
- 結構化資料應在渲染後完整存在
- 透過 Search Console 網址檢測工具或 Rich Results Test，確認搜尋引擎實際看到的內容
Log File 分析
什麼是 Log File 分析
Log File 分析是透過伺服器存取日誌，直接觀察搜尋引擎爬蟲實際造訪網站的分析方式。其重要性在於它並非工具估算，而是真實紀錄。
透過 Log File，可以掌握 Googlebot 何時造訪、造訪頻率、檢索了哪些頁面、遇到哪些錯誤，以及檢索資源實際分配在哪些內容上。
Log File 能協助觀察什麼
- 搜尋引擎爬蟲的檢索頻率是否穩定
- 哪些頁面最常被檢索，哪些重要頁面幾乎沒有被造訪
- 是否存在大量浪費檢索預算的行為，例如爬取 404、參數頁、後台頁等低價值內容
- 新發布內容是否能被搜尋引擎快速發現
- 網站是否存在過多 301、404 或 5xx 狀態碼問題
如何取得 Log File
Log File 存放位置依伺服器環境而異，Apache、Nginx、共享主機、CDN 取得方式都可能不同。若為大型網站，通常由主機商、DevOps 團隊或系統管理人員協助匯出。
對台灣中小企業而言，可直接向網站開發商或主機商索取近 30 天的存取記錄。
分析重點
- Googlebot 檢索量是否有異常升降
- HTTP 狀態碼分布是否健康，200 應占多數
- 是否存在過多 301、404 或 5xx
- 搜尋引擎是否過度消耗資源在低價值頁面
- 重要頁面是否確實被檢索
- 新內容是否能被快速發現與處理
本文重點回顧
技術 SEO 是整體 SEO 策略的基礎工程。網站架構決定搜尋引擎能否順利發現與理解頁面；網站速度與 Core Web Vitals 影響排名與使用體驗；行動優先索引則要求網站在手機版內容與體驗上維持完整性。
XML Sitemap 與 robots.txt 是網站與搜尋引擎溝通的重要工具；Canonical 可協助處理重複內容；Hreflang 是多語系網站不可忽略的技術設定；而正確的轉址策略，關係到權重與流量能否順利承接。
若網站採用 JavaScript 架構，更必須確保搜尋引擎能有效讀取內容；進一步透過 Log File 分析，則能從實際爬蟲行為中掌握技術健康狀態。
技術 SEO 的核心，不在於單一設定是否完成，而在於網站是否真正具備「可檢索、可理解、可載入、可使用」的整體基礎。只有當這些基礎穩定到位，內容策略與外部優化才更容易發揮效果。
在 AI 搜尋逐漸主導使用者行為的當下，Google AI Overviews、ChatGPT Search、Perplexity 等工具對網站技術基礎的依賴只會更加深刻。建立穩固的技術 SEO，等於為未來所有的內容投入奠定可被引用、可被理解的基本盤。
若您想進一步了解整體 SEO 策略，可參考 SEO 完整指南。
常見問答 FAQ
網站架構的三次點擊原則一定要嚴格遵守嗎？
三次點擊原則不需要當成硬性規定，但它是一條很好的警示線。重點在於讓重要頁面能在合理的點擊深度內被抵達，並獲得足夠的內部連結支持，避免關鍵頁面藏得太深，造成檢索效率與權重傳遞變差。
實務上，中小型網站通常兩到三層架構就已足夠；大型電商或內容平台難免出現四到五層，這時關鍵不是層數，而是重要頁面是否獲得內部連結補強。熱門商品即使位於分類深處，只要從首頁、熱門排行、相關推薦等入口都連得到，搜尋引擎依然能有效發現並評估其價值。
網站分類要做多細才算剛好？
原則是能幫使用者快速定位內容，同時不造成層級過深。若分類細到需要四到五層以上才抵達內容頁，通常就會開始影響檢索效率與閱讀體驗。
建議用主分類搭配子分類承接最主要的需求，其餘細節透過標籤、站內搜尋與相關文章模組補足。台灣中小企業的服務型網站，主分類控制在五到七個，每個主分類下再用三到五個子頁面說明細項，通常已能涵蓋大部分需求。判斷方式很簡單：新訪客能不能在十秒內找到他要的服務。
URL 一定要用英文小寫嗎？中文網址可不可以做 SEO？
中文網址搜尋引擎能夠理解，Google 也明確表示支援。但在分享、複製、轉碼與跨平台顯示上，中文網址的可讀性較差，貼到通訊軟體或電子郵件時常被轉成一長串編碼，既不專業也不容易記憶。
實務上仍建議使用英文小寫加連字號的形式。好處包括跨平台顯示穩定、分析報表可讀性高、社群分享時呈現專業，以及網址結構容易與站內導覽維持一致。對台灣中小企業而言，這樣做是為了提升整體網站的可維護性與專業度，而非討好搜尋引擎。
參數網址很多時，應該直接用 robots.txt 擋掉嗎？
不一定。robots.txt 擋掉會讓爬蟲看不到內容，卻不等於不會被索引。使用者透過外部連結進入時，該頁面仍可能出現在搜尋結果中，只是內容顯示為空白，反而傷害品牌呈現。
更有效的做法是組合策略：以 Canonical 指向標準頁集中權重，挑出真正有搜尋需求的參數組合保留索引，純粹排序變化的頁面改用 noindex，並從站內連結上減少低價值參數頁的曝光。對台灣中小型電商來說，這能降低重複內容風險，同時保留有商業價值的長尾搜尋機會。
網站改版需要更換 URL，最關鍵的 SEO 事項是什麼？
最關鍵的有兩件事。第一是301 一對一對應，舊頁要導向最相關的新頁，而不是全部導回首頁，否則容易被視為軟性 404；同時要避免轉址鏈，應該直接由起點指向最終頁面。
第二是同步更新所有 SEO 訊號，包括內部連結、Sitemap、Canonical 與 hreflang。建議改版前先整理好新舊網址對應表，上線後盡快重新提交 Sitemap，並在一到兩週內密切觀察 Search Console 的覆蓋率報告，若出現大量重新導向錯誤應立即排查。改版當天也建議同步確認站內搜尋、麵包屑與側欄推薦連結都已指向新網址。
Core Web Vitals 三大指標中，哪一個對 SEO 影響最大？
三項指標都是排名訊號，Google 並未公開哪一項權重最高。但從實務經驗來看，LCP 與 INP 對使用者感受的影響最直接，也最容易反映在跳出率與後續行為指標上。
LCP 決定使用者願不願意等，主視覺太慢出現就可能直接離開；INP 決定使用者願不願意操作，按鈕點下去沒反應會立刻降低信任感；CLS 較少直接造成跳離，卻會讓人在點擊時誤觸。建議三項都達到良好標準，資源有限時優先處理前兩項。
網站需要同時做桌面版和行動版嗎？還是只做 RWD 就好？
對絕大多數網站而言，做好響應式設計就足夠了，這也是 Google 官方推薦的做法。使用相同 HTML 與相同網址，不會出現桌機版與手機版內容不一致的風險，也不需要管理多套網址。
少數情況可能需要獨立的行動版網站，例如功能差異極大的應用型網站。但這類做法維護成本高，且容易出現兩邊內容不同步的問題。在行動優先索引之下，搜尋引擎只評估行動版內容，兩套版本反而放大了風險。對台灣中小企業官網來說，響應式設計是效率與成效兼顧的選擇。
網站使用 React 或 Next.js 等 JavaScript 框架，SEO 會比較差嗎？
使用前端框架本身不會自動讓 SEO 變差，關鍵在於採用什麼渲染策略。若完全依賴客戶端渲染，搜尋引擎需要兩階段處理，索引速度較慢；ChatGPT 與 Perplexity 對 JavaScript 渲染的支援更有限，可能完全讀不到內容。
較理想的做法是伺服器端渲染或靜態生成：內容頻繁更新的網站適合 SSR，變動較少的品牌官網與產品頁適合 SSG，需要兼顧速度與更新彈性則可考慮增量靜態更新。檢查方式是用網址檢測工具查看 Googlebot 實際取得的 HTML，確認重要內容都已存在。
參考來源
- Google Search Central，〈robots.txt 簡介與指南〉，Google 官方文件。
- Google Search Central，〈Sitemap 總覽〉，Google 官方文件。
- Google Search Central，〈行動裝置優先索引最佳做法〉，Google 官方文件。
- Google，〈Core Web Vitals〉，web.dev 官方文件。
- 新視野網頁設計，〈SEO 是什麼？2026 搜尋引擎優化完整指南〉，本站自有內容。
