網站架構雜亂、頁面載入過慢、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），這類頁面即使存在，也可能因檢索入口不足而難以獲得曝光。
五種架構模型與權重配置邏輯的完整比較，請見網站架構規劃 5 大模型；錨點文字寫法與 Hub Link 配置，請見內部連結 SEO 戰術。
網站速度優化與 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 未設定」與「內容寬度超出螢幕」。
行動裝置友善成為排名訊號的來龍去脈，請見Mobilegeddon 行動裝置友善更新。
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 問題。
憑證種類、申請與安裝步驟，請見SSL 憑證是什麼；用 .htaccess 把全站 HTTP 轉到 HTTPS 的寫法，請見.htaccess 將 HTTP 轉向 HTTPS。
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，有助搜尋引擎更完整理解媒體資源，提升圖片搜尋或影片搜尋的曝光機會。
免費製作 Sitemap 與提交 Search Console 的完整步驟，請見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 阻擋這些檔案可能影響搜尋引擎正確渲染頁面內容，進而錯誤判讀網站體驗品質。
robots.txt 的完整設定範例請見robots.txt 阻止搜尋引擎爬取；頁面層級的索引控制請見Robots Meta 指令；要擋掉惡意訪客與 AI 訓練爬蟲，請見.htaccess 阻止不想要的訪客與AI 爬蟲是什麼。
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）。較合理的方式，是將舊頁一對一導向最相關的新頁面。
301 與 302 的差別與常見錯誤，請見轉址是什麼；各狀態碼對檢索與排名的影響，請見HTTP 狀態碼完整指南。
網站可檢索性診斷與除錯
可檢索性是技術 SEO 的第一步
若搜尋引擎無法順利檢索網站，後續的索引、理解與排名都將失去基礎。可檢索性可說是技術 SEO 的第一道檢查關卡。
常見的可檢索性問題
- 伺服器頻繁回傳 500、502、503，導致 Google 降低檢索頻率
- 大量重要舊網址失效且未妥善轉向，浪費外部連結價值
- robots.txt 設定錯誤，誤擋重要頁面
- 忘記移除測試環境的 noindex 標籤，這是改版上線後最常見的災難
- Canonical 指向錯誤頁面
- 重要頁面缺乏內部連結支持，形成孤立頁面
常用診斷工具
建議的診斷流程
技術 SEO 檢查不宜零散，建議依以下順序系統化進行：
- 確認 robots.txt 是否誤擋重要頁面 這是最常見也最容易修復的問題。
- 檢查 Sitemap 是否正確且可提交 確保所有重要頁面都被列入，且 URL 都回傳 200 狀態碼。
- 查看 Search Console 索引狀態 檢視覆蓋率報告，了解哪些頁面被排除以及排除原因。
- 使用爬蟲工具掃描整站 找出技術層面的細部問題，例如斷鏈、轉址鏈、重複內容。
- 檢查 Core Web Vitals 與結構化資料 從「可被檢索」進階到「可被理解與排名」。
主機所在地與回應速度對檢索的影響，請見網站主機選擇指南；Bing 與 Yahoo 奇摩的收錄和 IndexNow 提交，請見Yahoo 奇摩搜尋與 Bing SEO。
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 完整指南。
搜尋引擎檢索、索引與排名的運作原理，請見搜尋引擎運作原理；結構化資料的類型與概念，請見Schema 是什麼。
常見問答 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 搜尋引擎優化完整指南〉，本站自有內容。
