技術 SEO 是什麼？14 個優化重點：技術 SEO 完整指南

企業開始做 SEO 時，通常最先想到的是「關鍵字、文章、排名」。

但即使內容寫得很好，如果搜尋引擎無法正常發現、存取、解析與索引網站內容，

這些內容仍然可能無法正常出現在搜尋結果中。

這就是 技術 SEO（Technical SEO） 要處理的問題。

Technical SEO 關注的不是「文章應該怎麼寫」，而是網站本身是否具備良好的搜尋引擎技術基礎。

這篇文章接下來會完整說明：

Technical SEO 是什麼、搜尋引擎如何 Crawling 與 Indexing 網站，以及 Robots.txt、Sitemap、Canonical、Redirect、JavaScript SEO、Structured Data、Core Web Vitals 等重要技術 SEO 項目應該如何理解與檢查。

不需要先成為工程師。

但如果企業希望 SEO 成為長期的搜尋流量來源，就應該至少理解自己的網站是否具備讓搜尋引擎正常工作的技術基礎。

技術 SEO（Technical SEO）是針對網站技術架構進行優化，確保搜尋引擎能夠正常：

發現（Discover）

↓

爬取（Crawl）

↓

渲染（Render）

↓

索引（Index）

↓

在搜尋結果中呈現內容（Serve）

簡單來說，Technical SEO 處理的是：

因此，它與我們前面談過的 SEO 文章寫作有所不同。

SEO Content 關注的是：「我們應該提供什麼內容？」

Technical SEO 則更接近：「搜尋引擎能不能正確處理這些內容？」

假設企業建立了一篇非常完整的 SEO 文章。

內容本身沒有問題，但網站可能出現：

robots.txt 阻擋搜尋引擎 Crawling

↓

Google 無法正常取得內容 或是 頁面被設定為 noindex

↓

Google 可以 Crawling，但被要求不要將頁面加入搜尋索引。

又或者同一份內容存在多個不同 URL

↓

搜尋引擎需要判斷哪一個網址才是主要版本。

這時就可能需要Canonical URL

再例如網站改版/old-page改成：/new-page

如果舊網址直接消失，而沒有建立適當 Redirect，就可能造成：

這些都屬於 Technical SEO 要處理的問題。

Technical SEO 並不是安裝一個 SEO Plugin，或者設定 Sitemap 就完成了。

它通常涉及網站的多個層面，例如：

而且這些項目彼此之間還可能互相影響。

例如 Sitemap 裡即使列出了某個網址，如果這個頁面本身設定noindex

就形成互相矛盾的訊號。

又或者 Canonical 指向：https://example.com/page

但這個網址本身又 Redirect 到：https://example.com/zh/page

那麼 Canonical 就不是指向最終可索引的正式網址。

因此，Technical SEO 真正重要的不是「每個功能有沒有做。」

而是整套網站技術訊號是否一致。

對企業網站而言，Technical SEO 最有效率的做法之一，不是要求每個內容編輯者都懂技術 SEO，而是：

讓網站平台本身建立合理的預設行為。

例如我們目前平台會自動：

內容管理者不需要每建立一篇文章，就重新理解一次Canonical、Sitemap、hreflang 應該怎麼設定。

這些規則更適合由網站系統統一處理。

但這並不代表所有 Technical SEO 都應該完全自動化。

例如：

仍然可能需要 SEO、內容與商業上的判斷。

Technical SEO 最後仍然服務於網站內容與使用者。

例如：

所以 Technical SEO 並不是一套「只有 Google 看得到的 SEO 技巧」。

更合理的理解是：

企業投入 SEO 時，最容易看見的是關鍵字、文章、搜尋排名與流量。

但這些工作都有一個共同前提「搜尋引擎必須先能正確取得與處理網站內容」。

如果網站的 Technical SEO 存在問題，即使內容本身很好，也可能因為技術設定錯誤而無法正常發揮搜尋價值。

Google 必須先發現頁面，才有後續 Crawling、Indexing 與搜尋呈現的可能。

搜尋引擎可以透過不同方式發現網址，例如：

因此，一個頁面即使已經發布，如果：

就可能降低搜尋引擎發現與處理內容的效率。

Technical SEO 的其中一項工作，就是建立清楚而且可以被搜尋引擎發現的網站結構。

找到 URL 之後，搜尋引擎還需要實際存取頁面。

這時就會牽涉：

例如：robots.txt

如果誤把重要內容封鎖，就可能阻止搜尋引擎正常 Crawling。

這也是為什麼 robots.txt 看似只是網站根目錄的一個小檔案，實際上卻是 Technical SEO 很重要的基礎設定。

這是企業很容易混淆的概念。

Google 能夠 Crawling 某個頁面：

不代表這個頁面一定會進入 Google Index。

例如：

頁面可能設定noindex

或者 Google Crawling 完成後，仍然決定不將該頁面加入索引。

因此「Crawling ≠ Indexing」

而「Indexing ≠ 保證取得排名」

Technical SEO 可以協助搜尋引擎正確處理網站，但不能保證「技術設定全部正確，Google 就一定會收錄或排名。」

企業網站很容易因為：

產生多個相似網址。

這時候搜尋引擎可能需要判斷哪一個才是主要版本？

Technical SEO 可以透過：

建立較一致的 URL 訊號。

我們平台目前也採取這個方向，例如 Canonical 會使用正式公開網址，而不是指向之後還會再次 Redirect 的中間網址；Sitemap 同樣輸出正式公開 URL。

這看起來是很小的技術細節，但核心其實是不要讓網站自己同時告訴搜尋引擎多個不同答案。

Technical SEO 在網站改版時尤其重要。

假設原本已經取得排名與外部連結的網址/seo-guide

改版後變成/resources/seo-guide

如果沒有處理舊網址，使用者與搜尋引擎可能直接遇到 404 Not Found

比較合理的做法通常是評估新舊頁面的對應關係，並在適當情況建立永久 Redirect。

因此，網站改版不能只確認「新網站能不能正常打開？」

還需要確認舊網站累積的 URL 與搜尋資產要如何遷移。

這也是為什麼 SEO Migration 本身就是網站改版的重要工作。

小型網站只有十幾個頁面時，很多 SEO 問題可以人工檢查。

但當網站開始出現：

如果每一個 Technical SEO 設定都依靠人工處理，就很容易產生錯誤。

因此，成熟的平台通常應該把可以標準化的事情系統化處理。

例如目前平台在內容 Slug 修改後，會建立舊網址到新網址的永久轉址；Sitemap 也會根據實際發布與索引狀態動態產生，而不是要求管理者手動維護 XML。

這種做法最大的價值不是「SEO 功能比較多。」

而是降低網站長期維護時產生技術 SEO 錯誤的機率。

最後要避免另一個極端：網站 Technical SEO 做得很好，所以內容不重要。

假設：

但網站內容本身沒有真正回答搜尋需求，仍然不代表網站就會因此取得好的搜尋排名。

反過來：非常好的內容 + 嚴重的 Technical SEO 問題

也可能限制內容的搜尋表現。

因此，比較合理的關係是：

兩者不是互相替代，而是 SEO 策略中的不同基礎。

SEO 涉及的工作很多，因此常會看到「Technical SEO、On-page SEO、Off-page SEO」這三個分類。

它們並不是三套彼此獨立的 SEO 方法，而是在處理不同層面的問題。

最簡單的理解方式是：

Technical SEO 主要處理搜尋引擎如何存取與處理網站。

常見項目包括：

例如：

網站有一篇很好的文章，但被錯誤設定成 noindex。

這不是文章內容寫得不好，而是Technical SEO 問題。

又或者網站改版後大量網址改變，卻沒有建立正確 Redirect。

同樣屬於 Technical SEO。

On-page SEO 則主要針對網站頁面中的內容與可優化元素。

例如：

例如使用者搜尋：「SEO 文章怎麼寫？」

但頁面大部分內容都在介紹：「為什麼企業需要 SEO？」

即使 Technical SEO 完全正常，這個頁面仍然可能沒有很好地滿足搜尋意圖。

這就是比較偏向 On-page SEO / Content SEO 需要處理的問題。

Off-page SEO 則發生在自己的網站之外。

最常見的項目就是Backlinks（反向連結）。

例如其他具有相關性的網站，在自己的內容中引用你的研究、文章或工具，並建立連結指向你的網站。

除此之外，Off-page SEO 還可能涉及：

但這裡需要特別注意：

Off-page SEO ≠ 大量購買外部連結。

為了操控搜尋排名而購買、交換或大量建立連結，可能涉及 Google 的 Link Spam 政策。

這也是為什麼企業更適合把 Off-page SEO 理解成建立值得被其他網站提及與引用的品牌及內容資產。

而不是想辦法取得最多 Backlinks。

雖然可以把 SEO 分成這三個類型，但實際執行時，它們並不是完全分開的。

例如：

企業建立了一篇很好的研究文章。

On-page SEO → 搜尋需求、內容、Title 與 Heading 都處理得很好。

但是 Technical SEO → 頁面被誤設 noindex。

那麼內容可能根本無法正常出現在搜尋結果。

反過來：

Technical SEO 完全正常，但內容品質很差。

也不代表：「網站技術很好，所以自然會取得排名。」

再例如一篇真正具有原始研究與產業價值的文章，可能因此被其他網站引用，進一步產生：

Off-page SEO 的自然 Backlinks。

所以三者其實存在關係：

這也是分類時很容易遇到的問題。

答案是：兩邊都有關係。

因此，不需要過度糾結：「這個項目到底只能算哪一類？」

SEO 的分類主要是幫助我們理解問題，不是硬性的技術邊界。

不是固定按照：Technical → On-page → Off-page

全部做完一個再做下一個。

比較合理的是先確認：有沒有阻礙 SEO 的重大技術問題。

例如：

這類問題應該優先處理。

確認網站具備基本健康的技術基礎後，就可以持續進行內容、On-page SEO 與 Off-page SEO。

因此，Technical SEO 比較像網站 SEO 的基礎設施。

不是做完一次之後永遠不用再管，而是隨著網站 新增功能、增加內容、改版、換網域、增加語系 持續維護。

要理解 Technical SEO，首先要理解 Google 是怎麼處理網站的。

很多人會把Google 看到網站 → 網站出現在搜尋結果 想成一個步驟。

但實際上，中間包含不同階段。

可以先簡化理解成：

Discovery（發現 URL）

↓

Crawling（爬取）

↓

Rendering（渲染）

↓

Indexing（索引）

↓

Serving（呈現搜尋結果）

這幾個階段處理的問題不同，也對應不同的 Technical SEO 問題。

在 Crawling 之前，Google 首先需要知道：這個 URL 存在。

Google 可以透過不同方式發現網址，例如：

例如企業發布一篇新文章：/blog/technical-seo

如果網站首頁、文章列表、分類頁或其他內容都有正常連結指向它，Google 就有機會沿著這些連結發現新網址。

XML Sitemap 也可以提供網站希望搜尋引擎知道的重要 URL。

因此 Internal Linking 與 Sitemap 都會影響 URL Discovery。

但需要注意 Google 發現 URL，不代表一定會 Crawling；Crawling 也不代表一定會 Indexing。

這幾個概念必須分開。

當 Google 發現 URL 後，Googlebot 可能會嘗試存取這個網址。

這個過程稱為 Crawling（爬取）。

網站伺服器收到請求後，會回傳：

等資源。

這時候 Technical SEO 就開始涉及：

例如：/important-page實際存在，但 robots.txt 禁止 Googlebot Crawling。

Google 就可能無法正常取得這個頁面的內容。

因此，Crawling 階段主要在回答：

傳統 HTML 網站通常可以直接從伺服器取得主要頁面內容。

但現代網站大量使用 JavaScript。

有些網站第一次回傳的 HTML 可能只有很少內容，真正的：

需要瀏覽器執行 JavaScript 後才產生。

這時就涉及：Rendering（渲染）。

Google 可以執行 JavaScript 並渲染網頁，但這不代表企業就完全不需要考慮 JavaScript SEO。

比較重要的是確認：主要 SEO 內容是否能被 Google 正常取得與渲染。

這裡不用先理解所有前端技術，只要知道一個核心差異。

這三種方式都不是「用了哪一種就一定 SEO 比較好」。

真正需要確認的是 Google 能不能穩定取得頁面的主要內容與連結？

目前提昇科技平台使用 Next.js App Router，公開頁面以 Server Component + Client Component 混合架構處理。

主要 SEO 內容，例如：

主要由 Server Component 輸出。

互動功能，例如：

才交由 Client Component 處理。

因此，使用者即使停用 JavaScript，主要文字內容仍然存在於 HTML 中；JavaScript 主要負責互動，而不是把整個 SEO 主體內容留到瀏覽器端才產生。

這是一個很實用的 Technical SEO 原則：重要內容不要在沒有必要的情況下完全依賴 Client-side JavaScript 才能出現。

Google Crawling 並處理頁面內容之後，接下來可能進入：

Indexing（索引）。

Google 會分析頁面，例如：

並判斷如何將頁面納入搜尋索引。

這裡需要再次強調：成功 Crawling ≠ 一定 Indexing。

例如頁面設定：noindex

就是明確告訴搜尋引擎：不要將這個頁面加入搜尋索引。

另外，即使網站允許索引，也不代表 Google 一定會把所有頁面加入 Index。

因此：「Sitemap 已經提交了，為什麼 Google 還沒收錄？」

本身就是錯誤地把Sitemap → Indexing 理解成必然關係。

Sitemap 可以協助 Google 發現與了解 URL，但不能保證頁面被索引。

頁面進入 Google Index 之後，當使用者進行搜尋，Google 才會根據：

決定哪些搜尋結果應該被呈現，以及如何排序。

所以：Indexing ≠ Ranking。

這也是 Technical SEO 很重要的一個界線。

Technical SEO 可以幫助網站建立正確的 Crawling、Rendering 與 Indexing 基礎。

但不能因此推論：Technical SEO 全部做完，Google 一定把網站排第一。

真正的搜尋排名仍然涉及內容、相關性、品質、網站與外部訊號等更多因素。

可以用這個方式快速理解：

因此，當企業發現：「這個頁面 Google 搜不到。」

不應該立刻判斷：「是不是文章 SEO 寫得不好？」

而應該先找出問題到底發生在哪一個階段。

Technical SEO 涵蓋的範圍很廣，但不需要把它理解成一大堆彼此獨立的技術設定。

比較容易理解的方式，是回到前面提到的搜尋引擎流程：

搜尋引擎能不能找到頁面？

↓

能不能正常 Crawling？

↓

能不能取得與理解內容？

↓

應不應該 Indexing？

↓

哪一個 URL 才是正式版本？

↓

網站是否提供清楚、一致的技術訊號？

從這個角度來看，企業網站常見的 Technical SEO 可以整理成以下 14 個重點。

Technical SEO 最基本的第一件事情，就是搜尋引擎能不能正常存取重要頁面。

如果 Googlebot 無法取得頁面，後面的：

都可能無法正常發揮作用。

因此需要確認：

Technical SEO Audit 通常也會先從網站到底能不能正常被 Crawl 開始檢查。

robots.txt 是放在網站根目錄中的檔案，可以告訴搜尋引擎爬蟲 網站哪些路徑允許或不允許 Crawling。

例如：

代表要求一般搜尋引擎爬蟲不要 Crawling /admin/。

但有一個非常重要的觀念：

如果真正希望某個頁面不要進入搜尋索引，通常應該使用：noindex

而不是只依靠 robots.txt。

後面我們會獨立說明這個差異。

XML Sitemap 可以提供搜尋引擎 網站有哪些重要 URL 希望被發現與 Crawling。

例如企業網站可能包含：

這些正式公開頁面可以整理進 Sitemap。

但 Sitemap 並不是：「提交之後 Google 就一定收錄。」

它主要是一種 URL Discovery 與網站資訊提示機制。

我們目前平台也是根據真正發布、允許索引的內容動態產生 Sitemap，而不是把所有系統 URL 全部放進去。

有些網站頁面存在是必要的，但不代表它們都應該出現在 Google 搜尋結果。

例如：

這時可能需要使用：

告訴支援這項指令的搜尋引擎不要將這個頁面加入搜尋索引。

因此：

可以 Crawling 和 允許 Indexing 是兩件不同的事情。

當相同或非常相似的內容可能透過不同 URL 存取時，就會涉及：Canonical。

例如：/product?id=123與/products/example 可能呈現高度相似的內容。

透過：

可以向搜尋引擎提供：哪一個 URL 是偏好的主要版本 這項訊號。

但 Canonical 不是 Redirect，也不是要求 Google「一定只能使用這個 URL。」

它是 Canonicalization 的重要訊號之一。

HTTP Status Code 會告訴瀏覽器與搜尋引擎：這次 URL 請求發生了什麼事情。

Technical SEO 最常遇到的包括：

正確的 Status Code 可以幫助搜尋引擎理解：URL 現在到底處於什麼狀態。

當 URL 發生永久變更時，通常需要評估建立 Permanent Redirect。

例如：

/old-seo-guide

↓

/seo-guide

這樣使用者與搜尋引擎進入舊 URL 時，可以被帶到新的正式網址。

我們目前平台在文章、商品或分類修改 Slug 時，就會自動保留舊網址並建立永久 Redirect，而不是讓原網址直接變成 404。

但 Redirect 也不能濫用。

例如：A → B → C → D

形成過長的 Redirect Chain，就代表網站長期 URL 管理可能需要整理。

網站 URL 應該讓使用者與搜尋引擎容易理解網站內容結構。

例如：/resources/seo/technical-seo

通常比：/page?id=93847&type=12

更容易理解。

但 Technical SEO 並不是要求 URL 一定要塞很多關鍵字。

真正重要的是：

Internal Linking 不只是內容 SEO。

它同樣會影響搜尋引擎 如何發現網站頁面，以及如何理解網站資訊架構。

例如：

首頁

↓

SEO 解決方案

↓

SEO 完整指南

↓

SEO 關鍵字研究

↓

SEO 文章寫作

這些正常 HTML Link 可以讓搜尋引擎沿著網站結構發現內容。

因此，重要頁面不應該成為：沒有任何網站頁面連向它的孤立頁面（Orphan Page）。

現代網站大量使用：

因此需要確認 搜尋引擎能不能正常取得 JavaScript 網站中的主要內容與連結。

真正需要關注的不是「用了 JavaScript 就對 SEO 不好。」

而是：重要內容是否過度依賴 Client-side Rendering，以及 Google 能否穩定取得最終內容。

我們平台目前公開內容主要由 Server Component 輸出 HTML，而互動功能再由 Client Component 處理，就是在功能與可索引內容之間做分工。

Google 採用 Mobile-first Indexing，因此網站的行動版內容非常重要。

企業應該確認：

Technical SEO 不只是「手機版看起來沒有跑版。」

還需要確認：行動版本是否仍然提供完整的重要內容。

企業網站應該使用 HTTPS 提供加密連線。

除了安全性之外，也需要避免網站同時存在：http://example.com與https://example.com

兩套可正常瀏覽的正式版本。

通常應該建立一致的 HTTP → HTTPS 轉址與 Canonical 訊號。

我們目前平台的 Custom Domain 也由 Vercel 自動處理 TLS / SSL，並將 HTTP Redirect 到 HTTPS。

Structured Data 可以使用標準化格式，幫助搜尋引擎更明確理解頁面中的實體與資訊。

常見例如：

常見實作格式則是 JSON-LD。

但需要特別注意：Structured Data ≠ 保證 Rich Results ≠ 加了 Schema 就直接提高搜尋排名。

更重要的是 Schema 必須與頁面真正呈現的內容一致。

例如我們平台在商品沒有實際價格、屬於「詢價」模式時，就不會為了 Schema 完整而虛構一個 Offer 價格。

這比「Schema 欄位填得越多越好」更重要。

最後是最常被企業認為等同 Technical SEO 的網站速度。

Google 的 Core Web Vitals 目前主要包括：

網站效能確實值得優化。

但不要把：PageSpeed Insights 100 分

當成 Technical SEO 的最終目標。

真正需要關注的是網站是否提供良好的實際使用體驗，而且不存在嚴重效能問題。

看到這份清單，很容易又把 Technical SEO 變成 14 項 SEO Checklist。

但真正重要的是理解這些設定之間的關係。

例如 Sitemap 說這個 URL 很重要。

但 noindex 又說不要索引。

或者 Canonical 指向 URL A。

但 URL A 又 Redirect 到 URL B。

這些都代表網站自己提供了不一致的技術訊號。

因此 Technical SEO 真正應該追求的是：

robots.txt 是放在網站根目錄中的文字檔案，用來告訴搜尋引擎爬蟲 哪些網站路徑允許或不允許 Crawling。

例如：

意思是：要求所有符合規則的搜尋引擎爬蟲不要 Crawling /admin/ 路徑。

因此，robots.txt 最主要處理的是 搜尋引擎 Crawling 網站的行為。

而不是 控制頁面是否一定會出現在 Google Index。

這兩個概念非常重要。

企業網站可以透過 robots.txt 管理不希望搜尋引擎大量 Crawling 的網站區域。

例如：

同時也可以在 robots.txt 中提供 Sitemap 位置，例如：

搜尋引擎就可以從這裡取得 Sitemap 的位置。

我們目前的平台也是動態產生 robots.txt，預設允許公開內容 Crawling，同時阻擋 /admin/、/api/、/preview/、/_next/ 等系統路徑，並提供 Sitemap URL。

這是 robots.txt 最常見的 SEO 誤解之一。

假設企業有一個頁面：/private-page

然後設定：

這代表的是要求搜尋引擎不要 Crawling 這個 URL。

但不能直接理解成「Google 一定不會把這個 URL 顯示在搜尋結果。」

如果 Google 透過其他地方知道這個 URL，例如外部連結，網址仍有可能被發現。

因此，如果真正希望一個公開可存取的頁面不要進入 Google Index，通常應該使用：

而不是只使用 robots.txt。

這裡還有一個非常重要的 Technical SEO 邏輯。

假設頁面本身設定：

但 robots.txt 同時設定：

可能產生問題。

原因是 Google 必須先 Crawling 頁面，才能看到頁面中的 noindex 指令。

如果 robots.txt 已經阻止 Google Crawling，Google 就可能無法讀取頁面裡的 noindex。

因此，如果目標是「允許 Google 存取，但不要把頁面加入 Index。」

比較合理的是 允許 Crawling + noindex

而不是 Disallow + noindex

這也是為什麼企業需要把 Crawling Control 與 Indexing Control 分開理解。

另一個常見錯誤是把 robots.txt 當成保護私人內容的方法。

例如：

並不代表使用者不能直接輸入：example.com/confidential/ 進入頁面。

robots.txt 本身是公開檔案，任何人都可以查看。

因此，如果內容真的屬於：

應該透過 Authentication、Authorization 或其他真正的存取控制 保護。

而不是依靠 robots.txt。

有些網站為了「不要讓 Google 爬太多東西。」

會大量封鎖 CSS、JavaScript 或其他網站資源。

但搜尋引擎可能需要這些資源才能正確 Rendering 頁面。

因此，不應該單純因為 「這不是文章內容。」就全部 Disallow。

真正需要確認的是 Google 是否需要這些資源才能正確理解與渲染頁面。

對一般企業網站而言，robots.txt 通常不需要非常複雜。

比較合理的原則是：

這四種情況不要混在一起。

最嚴重的情況就是 不小心把整個正式網站封鎖。

例如：

代表要求搜尋引擎 不要 Crawling 整個網站。

這種設定有時候會出現在 Staging / 測試環境

如果網站正式上線後忘記移除，就可能造成嚴重的 SEO 問題。

因此網站上線與改版時，robots.txt 應該列入 Technical SEO 檢查項目。

目前平台的 robots.txt 採用 系統產生合理預設 + 租戶可額外設定規則

的方式。

系統會保留必要的 Technical SEO 規則，例如阻擋後台與 API；使用者則可以額外增加自己的 Disallow / Allow 規則，但不能覆寫系統保護規則。

這樣做的目的不是限制使用者，而是降低 因為錯誤設定 robots.txt 而破壞整個網站 Technical SEO 基礎

的風險。

XML Sitemap 是一份提供給搜尋引擎的網站 URL 清單，用來協助搜尋引擎了解：

網站有哪些重要頁面希望被發現與 Crawling。

例如企業網站可能有：

這些正式公開而且具有搜尋價值的 URL，都可以包含在 XML Sitemap 中。

常見網址例如：https://example.com/sitemap.xml

前面我們提過，Google 可以透過：

發現新的網址。

因此，Sitemap 最主要的價值之一就是：

特別是網站規模較大、內容更新頻繁，或部分頁面不容易透過網站導航被快速發現時，Sitemap 就更有幫助。

這也是企業非常常見的誤解。

把 URL 放進 Sitemap：

Sitemap 提供的是「這些是網站希望搜尋引擎知道的重要 URL。」

但 Google 仍然會自行決定是否 Crawling、Indexing，以及如何處理這些頁面。

因此，如果 Search Console 顯示：Sitemap Submitted Successfully

不能直接理解成：「SEO 收錄已經完成。」

仍然需要進一步查看實際 Page Indexing 狀態。

一個很實用的原則是：

例如：

適合放入

通常不應該放入：

因為如果 Sitemap 告訴 Google「這是一個重要的正式 URL。」

但頁面本身又告訴 Google「不要 Index。」

網站就提供了彼此不一致的訊號。

假設網站存在 https://example.com/product-a

但這個頁面的 Canonical 是https://example.com/products/product-a

那 Sitemap 比較合理的是放https://example.com/products/product-a

也就是 Canonical URL。

同樣地，如果/old-page

已經永久 Redirect 到/new-page

Sitemap 應該直接放/new-page

而不是繼續保留舊網址。

所以 Sitemap 不只是「把網站所有 URL 列出來。」

而應該是一份網站希望搜尋引擎處理的正式 URL 清單。

XML Sitemap 還可以提供<lastmod>

用來表示頁面最後一次有重大內容更新的時間。

例如：

但 lastmod 不應該變成每次 Sitemap 重新產生，就全部更新成今天。

因為這樣就失去了「內容實際更新時間」的意義。

我們目前的平台也是使用內容真正的 updated_at 產生 lastmod，而不是每次 Request Sitemap 時，把所有頁面日期重新寫成當天。

這是一個很小但重要的實作細節：提供資訊，就應該讓資訊本身具有可信度。

多語網站除了列出不同語言版本的 URL，也可以搭配 hreflang

描述不同語言或地區版本之間的關係。

例如：

它們不是三個毫無關係的頁面，而可能是同一內容的不同語言版本。

我們目前的平台會在 Sitemap 中輸出語言版本資訊，並包含對應的 hreflang 關係。

International SEO 後面會再深入說明。

對現代 CMS 或動態網站來說，我不建議人工維護 Sitemap。

假設企業有：500 篇文章 + 300 個商品 + 3 種語言

如果每次：

都要人工修改 Sitemap，很容易出錯。

比較合理的方式是由網站系統根據實際內容狀態動態產生 Sitemap。

我們的平台目前就是依照：

自動產生 Sitemap。

這類可以明確規則化的 Technical SEO 工作，很適合交由系統處理。

嚴格來說不是所有網站都一定需要 Sitemap 才能被 Google 發現與索引。

如果網站：

Google 仍然可能正常發現網站內容。

因此 Sitemap 不是「沒有就不能做 SEO。」

但對一般企業網站而言，建立 Sitemap 的成本很低，而且可以提供搜尋引擎更清楚的 URL 資訊。

尤其是：

更值得建立。

所以我們實務上的建議仍然很簡單：

重點不是「一定要有才會排名」，而是它是一項成本低、容易標準化，而且有助於搜尋引擎發現重要 URL 的 Technical SEO 基礎。

建立 Sitemap 後，可以將 Sitemap 提交到：

Google Search Console → Sitemaps

之後可以查看 Google 是否能正常讀取 Sitemap。

但仍然要記住：Sitemap 成功讀取 與：網站頁面成功 Indexing 是兩件不同的事情。

真正要判斷索引狀態，還需要搭配 Page Indexing Report 以及 URL Inspection 一起查看。

Canonical URL 用來向搜尋引擎提供訊號：

當多個 URL 存在相同或高度相似內容時，哪一個 URL 是網站偏好的主要版本。

通常會透過 HTML 中的來設定：

這個網址通常稱為 Canonical URL（標準網址／主要版本網址）。

企業不一定刻意建立重複內容。

很多時候，是網站系統自然產生不同網址。

例如：

如果這些 URL 提供相同或非常相似的內容，就可能涉及 Canonicalization。

即使頁面沒有明顯的重複版本，也可以讓正式頁面指向自己。

例如目前正式 URL 是https://example.com/technical-seo

則設定：

這稱為 Self-referencing Canonical。

它可以讓網站更明確地提供「這就是這個頁面的正式 URL。」

目前提昇科技平台也採用這種方式，依據頁面的正式公開網址自動產生 Canonical。

這兩個概念很容易被混淆。

假設存在 URL A 與 URL B

使用者仍然可以進入 A。

但 A 向搜尋引擎表示「B 是我偏好的主要版本。」

使用者進入 A 後，直接被帶到 B。

所以如果 舊 URL 已經永久被新 URL 取代

通常應該考慮 Permanent Redirect。

如果 多個 URL 因為網站功能仍然需要存在，但內容高度相似

則可能適合使用 Canonical。

不能把兩者當成完全相同的工具。

另一個重要觀念是：Google 可能不一定採用網站指定的 Canonical。

Google 會綜合不同訊號判斷主要版本，例如：

因此，在 Google Search Console 中可能看到 User-declared canonical 以及 Google-selected canonical

兩者不一定完全相同。

如果 Google 長期選擇不同 Canonical，就應該檢查網站是不是提供了互相矛盾的訊號。

假設網站指定：/new-page為 Canonical。

但 Sitemap 仍然列出 /old-page

而 Internal Links 大量指向 /old-page

同時 Canonical 又指向 /new-page

這時網站自己就在提供不同答案。

比較理想的是：

Canonical

→ /new-page

Sitemap

→ /new-page

Internal Linking

→ /new-page

如果舊網址已經被永久取代：

Redirect

→ /new-page

讓主要訊號盡量保持一致。

這比單純「有沒有放 canonical tag？」更重要。

這是我們在平台實作時很值得分享的一個細節。

假設真正正式網址是https://example.com/zh-TW/about

但 Canonical 卻寫成https://example.com/about

而 /about 又會 Redirect 到：/zh-TW/about

就形成 Canonical → Redirect → Final URL

更乾淨的做法是 Canonical 直接指向最終正式 URL。

因此，我們目前平台產生 Canonical 時，會直接使用租戶的正式公開網址與 Locale Path，而不是使用之後還會 Redirect 的中間網址。

這個原則同樣適用於：

盡量讓 SEO 訊號直接指向最終正式網址。

這也是很常被設定錯的地方。

例如：

如果這三個頁面是真正不同語言的內容版本，通常不應該把 英文與日文全部 Canonical 到中文版。

否則可能等於告訴搜尋引擎：中文版才是主要版本。

比較合理的做法通常是 每個語言版本 Self-canonical

再透過 hreflang 描述不同語言版本之間的關係。

目前平台也是 Canonical 指向目前語言自己的正式 URL

並另外產生 hreflang + x-default。

後面的 International SEO 章節我們會再詳細處理。

Canonical 很重要，但不要把所有 URL 問題都丟給 Canonical。

例如：

因此 Canonical 是 Canonicalization 工具之一，不是網站重複內容問題的萬用解法。

企業網站可以特別注意：

這些問題的共同核心都是 網站沒有清楚而一致地告訴搜尋引擎哪一個 URL 才是正式版本。

當搜尋引擎 Crawling 一個 URL 時，網站除了回傳內容，也會回傳：HTTP Status Code（HTTP 狀態碼）。

它告訴瀏覽器與搜尋引擎 這次 URL 請求的結果是什麼。

Technical SEO 最常遇到的狀態包括：

這些 Status Code 本身不是「SEO 分數」，但它們會影響搜尋引擎如何理解與處理 URL。

200 OK 代表：伺服器成功回傳這個頁面。

一般正式公開頁面通常應該正常回傳 200。

但 200 ≠ 一定會被 Google Indexing。

例如一個頁面即使回傳 200，仍然可能：

因此 HTTP Status Code 處理的是 URL Request 的狀態。

不是直接決定搜尋排名或索引結果。

當某個 URL 已經永久改變時，可以使用 Permanent Redirect。

例如原本網址：/seo-guide-old

現在正式網址變成：/seo-guide

使用者或搜尋引擎進入舊網址後：

Old URL → Permanent Redirect → New URL

這樣可以清楚表示：這個資源已經永久搬到新的網址。

常見的永久 Redirect Status 包括：301 以及 308。

兩者都可以表達永久轉址；差異主要涉及 HTTP Request Method 的處理方式。

對一般 SEO URL Migration 而言，真正重要的是網站是否使用正確的永久轉址，而且目的地是否合理。

假設企業有一篇已經存在兩年的文章：

/seo-guide改版後變成：/resources/seo-guide

如果直接刪掉舊 URL：/seo-guide → 404

那麼：

都可能進入不存在的頁面。

如果新頁面確實是舊內容的替代版本，比較合理的做法通常是：

舊 URL → Permanent Redirect → 新 URL

這也是 SEO Migration 非常重要的一部分。

目前平台在文章、商品與分類修改 Slug 時，會自動記錄舊 Slug，並建立 308 Permanent Redirect 到新的正式 URL。

這種可以明確判斷的新舊 URL 關係，很適合由系統自動處理。

如果 URL 的變更只是暫時性的，可以使用Temporary Redirect。

常見包括：302與307。

例如某個頁面暫時因活動或維護需要導向另一個網址，但未來仍然預計恢復原網址，就可能使用暫時 Redirect。

因此不要單純按照：「Redirect 都用 301。」

而應該先判斷 這次 URL 變更是永久還是暫時？

404 Not Found 表示 伺服器找不到這個 URL 對應的資源。

很多企業看到 Search Console 出現 404 就會認為「網站 SEO 出問題了，所有 404 都要修掉。」

其實不是。

如果某個頁面：

回傳 404 本身完全合理。

真正需要處理的是 重要頁面不應該意外變成 404。

例如：

這些才是值得優先檢查的情況。

這也是網站改版常見做法。

發現大量舊 URL 不存在後，直接設定：

所有 404 → 首頁

看起來好像「至少使用者不會看到錯誤頁。」

但問題是：

原本：/old-product-a

與首頁可能完全沒有內容關係。

比較合理的 Redirect 應該是：舊內容 → 真正對應的新內容。

如果根本沒有合理替代頁面：讓它正常回傳 404 或 410

通常反而比較清楚。

所以 Redirect 的核心不是「不要出現 404。」

而是「新舊 URL 是否真的存在合理對應關係。」

410 Gone 表示：這個資源以前可能存在，但現在已經被明確移除。

它與 404 的語意稍微不同：

目前平台對已刪除的文章與商品，可以回傳真正的：410 Gone

而不是用一個看起來像錯誤頁的 200 OK 頁面取代。

這也帶出另一個重要問題：Soft 404。

假設使用者進入一個不存在的頁面。

畫面顯示「找不到此頁面。」

但 Server 實際回傳：200 OK

這時就可能形成：Soft 404。

也就是內容看起來不存在，但 HTTP Response 卻告訴搜尋引擎頁面正常。

因此 Technical SEO 不應該只看「畫面有沒有顯示 404。」

還要確認 Server 實際回傳的 HTTP Status Code 是否正確。

5xx 代表伺服器端發生問題。

例如：

偶爾出現短暫 Server Error 不代表網站 SEO 就會立即受到重大影響。

但如果 Googlebot 長期或大量 Crawling 網站時持續遇到 5xx，就代表搜尋引擎無法穩定取得網站內容。

這時真正應該處理的是：

而不是去修改文章 SEO。

假設：

URL A

↓

URL B

↓

URL C

↓

URL D

形成 Redirect Chain。

如果網址長期不斷修改，就很容易累積這種情況。

比較好的做法是：A → D

讓舊 URL 儘可能直接 Redirect 到最終正式版本。

目前平台的 Slug Redirect 機制會查找最終目標，以降低形成 Redirect Chain 的機會。

這也是為什麼 URL 管理不只是：「有 Redirect 就好。」

還需要確認：Redirect 最後到底導去哪裡。

可以先使用這個簡單原則：

真正重要的是：

而不是為了 SEO 讓所有頁面都想辦法回傳 200。

會，但需要先釐清一個很常見的誤解：

因此，不能簡化成：

網站效能真正需要關注的是使用者實際瀏覽網站時，頁面是否快速、穩定，而且具有良好的互動體驗。

Google 使用 Core Web Vitals 衡量網站使用體驗中的幾個重要面向。

目前主要包含三項：

衡量主要內容載入需要多久。

例如企業網站 Hero 區塊中的：

可能成為頁面的 LCP Element。

Google 建議良好體驗的 LCP 為 2.5 秒以內。

衡量使用者操作網站後，頁面多快產生視覺回應。

例如：

如果網站有大量 JavaScript 工作阻塞瀏覽器，即使頁面已經載入完成，操作起來仍然可能感覺卡頓、延遲。

Google 建議良好 INP 為 200ms 以內。

衡量頁面載入過程中的視覺穩定性。

例如使用者正準備點擊某個按鈕，圖片突然載入，把整個畫面往下推。

這就是 Layout Shift。

Google 建議良好的 CLS 為 0.1 以下。

因此 Core Web Vitals 可以簡單理解成：

PageSpeed Insights 很有用，但企業最容易犯的錯誤就是把 Lighthouse Performance Score 當成 SEO KPI。

例如網站目前 92 分

為了追求 100 分

開始：

最後投入很多成本，卻沒有明顯改善真正的使用者體驗或商業成果。

因此，更合理的優先順序是先處理真正影響使用體驗與 Core Web Vitals 的問題。

而不是追求測試工具滿分。

這也是使用 PageSpeed Insights 時很重要的觀念。

網站效能資料大致可以分成：

PageSpeed Insights / Lighthouse 可以協助開發者找出效能問題，但實際使用者可能存在：

因此，如果網站具有足夠資料，Core Web Vitals 的 真實使用者資料（Field Data）會非常值得參考。

企業不應該只因為自己電腦測一次得到：Performance 95

就認定所有使用者的網站體驗都很好。

企業網站很常使用大型 Hero Image。

而 Hero 圖片又很容易成為 LCP Element。

如果這張圖片：

就可能直接影響 LCP。

因此，我們目前平台針對首頁第一個 Hero Image 會提高載入優先級；其他圖片則維持 Lazy Loading，避免所有圖片一開始同時下載。平台同時使用 Next.js Image Optimizer 提供 WebP / AVIF、Responsive Images 與尺寸資訊。

這背後的原則不是「所有圖片都要 Priority。」

而是：

CLS 常見來源包括：

例如圖片如果事先提供 width / height

瀏覽器就可以先預留空間。

目前平台的圖片處理也會提供尺寸資訊，降低圖片載入後造成 Layout Shift 的機率。

因此，很多網站效能問題其實不是 網站完成後再安裝一個「加速工具」才開始解決。

而是在網站架構與元件設計階段就應該考慮。

現代企業網站很容易加入：

每增加一個 Script，都可能增加瀏覽器需要處理的工作。

因此 Technical SEO 與效能優化不能只看 圖片有沒有壓縮。

還需要檢查 網站到底載入了多少 JavaScript，以及這些 JavaScript 是否真的必要。

這也是 INP 特別需要注意的地方。

比較準確的理解是：

Google 將 Core Web Vitals 用於其排名系統，但 Google 同時明確指出：取得良好的 Core Web Vitals 並不能保證頁面取得較高排名。

因為 Google Search Ranking 還會考慮很多其他訊號。

例如：

如果兩篇文章相比：

不能因此推論：B 一定排名比較高。

所以企業不應該把 Technical SEO 變成「網站速度越快 → SEO 一定越好。」

比較合理的是：網站應該提供良好的 Page Experience，但內容相關性與品質仍然是搜尋策略的核心。

企業不需要追求「全網站 PageSpeed 100 分。」

比較合理的方式是：

這樣比較符合企業真正的成本效益。

而不是為了 SEO 工具分數投入無限工程時間。

使用 React、Next.js、Vue 等 JavaScript 技術，本身不代表網站的 SEO 會比較差。

真正需要確認的是：

因此，JavaScript SEO 的核心問題不是：「網站有沒有使用 JavaScript？」

而是：「哪些重要內容依賴 JavaScript，以及搜尋引擎是否能可靠取得這些內容？」

傳統網站在搜尋引擎請求頁面時，Server 通常就會直接回傳包含主要內容的 HTML。

例如：

Googlebot 取得 HTML 時，就能直接看到主要內容。

但某些 Client-side Rendering 網站第一次回傳的 HTML 可能只有：

接著需要：

下載 JavaScript → 執行 JavaScript → 呼叫資料 → 建立 DOM

之後才出現真正內容。

Google 可以處理 JavaScript，但這增加了Rendering

這個需要考慮的環節。

從 SEO 角度，可以先簡單理解三種方式。

Server 先提供基本頁面架構。

之後由瀏覽器執行 JavaScript，產生主要內容。

流程比較接近：

HTML Shell → JavaScript → API / Data → Content

如果主要 SEO 內容完全依賴 CSR，就需要特別確認搜尋引擎是否能正常 Rendering。

使用者或搜尋引擎請求頁面時，由 Server 先產生包含主要內容的 HTML。

因此初始 Response 就可能包含：

之後 JavaScript 再接手網站互動。

頁面在 Build 或其他產生階段就先建立 HTML。

當搜尋引擎或使用者進入網站時，可以直接取得已經建立好的頁面內容。

不能直接這樣判斷。

真正重要的是最終網站是否能讓 Google 正常取得重要內容。

Google 可以 Rendering JavaScript，因此 CSR ≠ 不能做 SEO。

同樣地 SSR ≠ SEO 自動變好。

如果 SSR 網站：

一樣會有 SEO 問題。

因此 Rendering Strategy 是 Technical SEO 的基礎條件之一

而不是 搜尋排名技巧。

對具有搜尋價值的公開頁面，尤其應該確認：

能否被搜尋引擎可靠取得。

而一些純互動功能，例如：

則通常沒有必要為了 SEO 全部 Server Rendering。

這也是現代網站很常採用 Server + Client 混合架構 的原因。

目前提昇科技平台使用：Next.js App Router。

公開頁面的主要內容主要由 Server Component 處理，例如：

而：

等互動功能，再交由 Client Component 處理。

根據目前實作盤點，即使停用 JavaScript 主要文字內容仍然存在於 HTML。

這背後的原則不是「JavaScript 越少越好。」

而是 讓 JavaScript 負責真正需要互動的事情，不要讓重要搜尋內容在沒有必要的情況下完全依賴 Client-side Rendering。

JavaScript 網站另一個常見問題是：畫面看起來可以點，但搜尋引擎不一定看到正常的連結。

例如重要導航如果只是 JavaScript onclick Event

卻沒有真正可解析的 href，就可能影響搜尋引擎發現頁面的方式。

因此重要 Internal Links 比較合理的做法仍然是提供正常：

現代 Framework 可以使用自己的 Routing Component，但最後仍應該產生搜尋引擎可以理解的連結。

目前平台的主要導航、Footer、文章與內容連結使用 Next.js <Link> 或 <a href>，而不是只靠 JavaScript Event 進行導航。

SPA 或 Client-side Navigation 還可能產生另一類問題。

使用者點擊頁面時，網站沒有進行傳統整頁重新載入，而是透過 JavaScript：切換 Route → 更新內容。

這本身沒有問題。

但仍然需要確保不同 URL 具有正確的：

不能只是 畫面內容變了，但搜尋引擎看到的頁面資訊沒有正確改變。

因此 JavaScript SEO 不能只檢查「Google 看不看得到文字？」

還要檢查 每一個可索引 URL 是否真的代表一個完整而正確的頁面。

企業不一定需要自己研究網站 Framework。

比較實際的是檢查 Google 到底取得了什麼？

例如可以透過 Google Search Console 的 URL Inspection 查看頁面索引與 Crawling 狀態。

工程端則可以進一步確認：

這比單純問：「我們網站是不是 Next.js？」更有意義。

Structured Data（結構化資料）是一種使用標準化格式描述網頁內容的方法，讓搜尋引擎更容易理解：這個頁面中的資訊代表什麼。

例如頁面上出現：提昇科技

搜尋引擎可以從文字內容理解它，但透過 Structured Data，網站可以更明確描述：這是一個 Organization。

同樣地：

這些 Schema Type 可以協助搜尋引擎理解頁面的內容與實體。

談 Structured Data 時，通常會遇到兩個名詞：

例如一篇文章可能包含：

這不是額外寫一份文章給 Google 看，而是用結構化方式描述 頁面本來就存在的資訊。

最主要的價值是：幫助 Google 更明確理解頁面內容，並讓符合資格的內容有機會使用特定 Search Appearance。

例如 Google 支援不同類型的 Structured Data 搜尋功能。

但這裡有兩個很重要的觀念：

即使 Schema 完全正確，Google 仍然會自行判斷是否以及如何在搜尋結果中呈現。

因此，不應該把 Structured Data 當成「加了之後排名就會提高的 SEO 技巧。」

這是實作 Structured Data 最重要的原則之一。

例如商品頁沒有真正提供：價格

就不應該為了讓 Product Schema 看起來完整，隨便產生：

因為：0 元

代表商品免費。

不代表：請聯絡我們詢價。

目前我們的平台就有這個實際情境。

如果商品具有實際價格，Product Structured Data 可以產生對應的 Offer。

但如果商品採：詢價模式

沒有真正價格，就不會為了填滿 Schema 而產生假的 Offer。

這個原則其實比「Schema 填得越完整越好。」更重要。

另一個重要原則是：不要在 Structured Data 裡描述使用者實際看不到或頁面不存在的內容。

例如頁面沒有：

卻在 JSON-LD 裡加入這些資訊，只是希望取得更好的搜尋呈現，就不是合理做法。

Structured Data 的角色應該是描述頁面內容。

而不是另外創造一套只有搜尋引擎看得到的內容。

不同網站不需要全部 Schema 都做。

應該根據實際頁面內容決定。

目前我們的平台依照頁面類型支援：

因此，比較合理的做法不是每個頁面塞進所有 Schema。

而是頁面是什麼，就提供相對應的 Structured Data。

如果企業網站有 300 篇文章 + 500 個商品

要求內容編輯者每次發布內容都自己撰寫 JSON-LD，顯然不容易長期維護。

比較合理的是：

CMS Content

↓

頁面類型

↓

系統產生對應 Structured Data

例如文章發布時，系統已經知道：

就可以利用這些既有資料產生 Article Structured Data。

目前平台也是採取這種方式，由頁面資料與 CMS 內容自動產生對應 JSON-LD。

這可以降低畫面內容更新了，但 Structured Data 忘記一起修改的風險。

這與前面 Canonical 的原則相同。

假設正式網址是：https://example.com/zh-TW/product-a

Structured Data 裡卻使用：https://example.com/product-a

而後者還會 Redirect。

雖然最後可能仍然能被理解，但網站其實沒有必要製造這種不一致。

因此比較好的做法是：

都盡量使用最終正式公開網址。

目前平台也依循這個原則。

FAQPage 是過去非常熱門的 SEO Structured Data。

但企業不能因為「FAQ Schema 可以增加搜尋結果版面。」

就大量建立 FAQ。

Google 已經限制 FAQ Rich Results 的顯示範圍，目前主要針對符合條件的知名政府與健康網站。

因此，企業文章仍然可以建立真正有幫助的 FAQ。

但不要把 FAQ Schema 當成一般企業網站一定能取得 FAQ Rich Result 的方法。

這也再次說明：Structured Data 的價值首先是正確描述內容，而不是追求 SERP 特效。

完成 Structured Data 後，可以使用 Google 的 Rich Results Test

檢查 Google 支援的 Structured Data 是否存在：

也可以透過 Search Console 查看部分 Structured Data / Search Appearance 相關報告。

但測試通過仍然只代表 技術格式符合相關要求。

不代表 Google 一定顯示 Rich Result。

Google Search Console 不只是查看 關鍵字、曝光、點擊與排名。

對 Technical SEO 而言，它更重要的用途之一是：

因為網站程式碼「看起來設定正確」，不代表 Google 實際處理結果一定符合預期。

因此 Technical SEO 檢查不能只看網站後台，也需要回到 Search Console 查看 Google 實際看到的結果。

首先可以查看：Indexing → Pages

這裡可以了解 Google 已知的網站頁面，以及：

等不同狀態。

但看到 Not indexed 不要立刻認為：「網站 SEO 出問題了。」

因為有些頁面本來就不應該被索引。

例如：

真正需要確認的是：

如果發現某個重要頁面沒有出現在 Google Search，可以使用 URL Inspection（網址審查）查看特定 URL。

例如：https://example.com/technical-seo

可以確認：

這對 Technical SEO 特別重要。

例如網站明明設定 Canonical → URL A

但 Search Console 顯示 Google-selected Canonical → URL B

就代表值得進一步檢查：為什麼 Google 判斷 B 才是主要版本？

在 Indexing → Sitemaps 可以提交 Sitemap，例如：https://example.com/sitemap.xml

並確認 Google 是否能正常讀取。

如果 Sitemap 發生問題，可以進一步檢查：

但仍然要記住：Sitemap Success ≠ 所有 URL 已經 Indexing。

Sitemap Report 與 Page Indexing Report 應該搭配查看。

Search Console 也提供 Core Web Vitals Report。

它可以協助企業查看網站是否存在：

並以：

等 Core Web Vitals 指標判斷實際使用體驗。

這裡很重要的一點是：Search Console 的 Core Web Vitals 使用的是實際使用者資料，而不是單次 Lighthouse 測試結果。

因此，如果 PageSpeed Insights Lab Test 看起來很好，但 Search Console 仍然顯示大量 Poor URLs，就值得進一步調查真正使用者遇到的問題。

Search Console 也可以協助查看 Google 對網站 HTTPS 狀態的判斷。

正常企業網站應該確保主要正式頁面透過：HTTPS 提供。

如果網站同時存在：http://example.com 與 https://example.com

也應該建立一致的正式版本與 Redirect。

目前平台的 Custom Domain 由 Vercel 處理 TLS / SSL，HTTP 也會導向 HTTPS。

因此實作層面有處理是一回事，Search Console 則可以再從 Google 實際看到的網站狀態 進行驗證。

如果網站使用 Google 支援的 Structured Data，Search Console 可能提供相關報告。

可以協助發現：

但這裡同樣不要把 沒有 Rich Result 直接判斷成 Structured Data 做錯。

Structured Data 正確只代表頁面符合相關技術條件之一，最終是否以及如何呈現在搜尋結果，仍由 Google 決定。

Technical SEO Audit 很容易變成 看到紅色 → 全部修掉。

但這不是最有效率的做法。

例如：

網站有：500 個 404 看起來很多。

但如果全部都是：

優先級可能沒有那麼高。

反過來，如果只有 1 個重要服務頁被 noindex

數量雖然只有一個，商業影響卻可能非常大。

因此 Technical SEO 的優先級應該看：

而不是單純 哪個報告錯誤數最多。

企業不需要每天檢查所有報告。

可以先按照：

這樣比漫無目的地查看所有 Search Console 報告更有效率。

網站改版是 Technical SEO 特別容易出問題的階段。

因為改版通常不只是 「把網站設計換新。」

還可能同時改變：

如果這些項目沒有一起處理，就可能出現新網站正常上線了，但原本累積的搜尋流量開始下降。

因此，有既有 SEO 流量的網站進行改版時，Technical SEO 應該被視為正式的 Migration 工作，而不是上線後才補做。

這是網站改版最常見的問題之一。

例如舊網站原本有：/blog/seo-guide

新網站改成：/resources/seo-guide

如果直接讓舊網址消失 舊 URL → 404

原本指向舊 URL 的：

都會失效。

如果新頁面確實是舊頁面的替代版本，就應該建立：舊 URL → Permanent Redirect → 新 URL

而且 Redirect 最好直接指向最終 URL，避免：A → B → C

這類不必要的 Redirect Chain。

網站改版時，有些團隊為了快速處理大量舊網址，會直接：所有舊 URL → Homepage

這不是好的 Migration Strategy。

例如：/products/machine-a

如果已經沒有這項產品，而且新網站也沒有對應內容，把它 Redirect 到首頁並沒有真正回答：

「這個舊頁面現在搬到哪裡？」

比較合理的是：

Redirect 應該建立 內容之間真正的新舊對應關係。

而不是單純消滅所有 404。

網站改版時很容易只搬 畫面看得到的內容。

卻忘記原本頁面的：

例如舊網站原本已經針對每個服務頁設定不同 SEO Title。

新網站上線後卻全部變成 公司名稱｜官方網站

這就不是設計問題，而是 SEO Metadata Migration 沒有完成。

因此正式改版前，應該先盤點舊網站的重要 SEO 資料，再確認新網站是否正確遷移。

網站架構改變後，Canonical 也需要重新確認。

常見錯誤包括：

特別是：Staging Domain 被帶進正式站

是網站 Migration 很值得檢查的項目。

正式上線後應確認：Canonical → 正式 Domain + 最終正式 URL

而不是只確認頁面可以正常開啟。

網站開發期間，為了避免測試站被 Google Indexing，可能會使用：noindex

或其他 Crawling / Indexing 限制。

這本來是合理的。

真正危險的是 正式上線後忘記移除。

結果網站看起來：

但重要頁面仍然告訴搜尋引擎 不要 Index。

因此正式上線 Checklist 一定應該包含 重新檢查 robots.txt、robots meta 與實際 Indexing 設定。

網站改版後：Sitemap 應該反映新的正式網站狀態。

例如不應該繼續包含：

同時新的：

也應該正常出現在 Sitemap。

如果 Sitemap 是由 CMS 根據正式內容自動產生，這類問題通常比較容易控制。

目前我們的平台就是根據正式發布、允許索引的內容動態產生 Sitemap，並使用正式 Canonical URL。

即使已經設定：Old URL → Redirect → New URL

網站內部連結仍然不應該長期依靠 Redirect。

例如文章 A 還寫著：/old-seo-guide

雖然最後可以 Redirect 到：/seo-guide

但更乾淨的方式仍然是：直接把 Internal Link 更新成 /seo-guide。

因此網站 Migration 完成後，應該重新 Crawling 網站，檢查：

確保網站自己的 Internal Linking 已經使用新的正式 URL。

有時候網站改版沒有刪除任何內容，URL 也沒有改。

但網站導航結構發生巨大變化。

例如原本：首頁 → 服務頁

改版後變成：首頁 → 解決方案 → 產業 → 分類 → 服務頁

重要頁面變得更難被使用者與搜尋引擎發現。

因此 Migration 不只是 URL Mapping。

還要重新檢查 網站資訊架構與 Internal Linking。

尤其是原本具有搜尋流量與商業價值的重要頁面，不應該在改版後突然成為難以發現的孤立內容。

網站可能從：WordPress

改成：React / Next.js / Headless CMS

或者反過來。

這時即使畫面與內容完全相同，搜尋引擎取得內容的方式也可能已經改變。

需要重新確認：

因此：

「Google 以前收得到舊網站。」不能直接推論：「新網站內容一樣，所以一定沒問題。」

Rendering Architecture 改變後仍然需要重新驗證。

International Website 改版尤其需要注意。

例如舊網站：

改成：

這時除了 Redirect，還涉及：

如果只把頁面搬過去，卻沒有重新建立不同語言版本之間的關係，就可能產生 International SEO 問題。

如果既有網站已經有 SEO 流量，我們不建議：

新網站做完 → 上線 → 發現 404 → 再開始補 Redirect。

比較合理的是在上線前先整理：

Old URL

↓

New URL

↓

Action

例如：

這份 URL Mapping 可以成為 Migration 的核心依據。

根據目前平台實作，系統已經可以處理：

因此，除了系統可以自動處理內容 Slug 變更之外，網站管理者也可以透過 Redirect Manager 管理其他 URL 的轉址需求。

這對網站改版尤其重要。

例如企業從舊網站遷移到新平台時，可以先建立：舊網站 URL → 新網站 URL 的 URL Mapping，再將需要保留的舊網址建立永久 Redirect。

不過，即使平台已經具備 Redirect Manager，如果既有網站累積了大量搜尋流量，仍然不建議直接搬站。

比較完整的流程仍然應該是 舊網站 URL Audit → URL Mapping → Redirect 設定 → 新網站上線 → Search Console / Crawling 驗證

因為 Redirect Manager 解決的是「如何執行 Redirect」，而哪些舊網址應該導向哪些新網址，仍然需要根據實際內容與 SEO 價值判斷。

Technical SEO 的問題很多時候不是「完全沒有做 SEO」，而是：

網站已經有 Sitemap、Canonical、robots.txt、Structured Data 等設定，但不同設定之間彼此衝突。

因此，Technical SEO Audit 的重點不是單純確認「這個功能有沒有？」

而是確認「它有沒有設定正確，而且與網站其他 SEO 訊號保持一致？」

以下是企業網站最常見、也最值得優先檢查的 Technical SEO 問題。

最嚴重的情況之一，就是正式網站的重要內容被 robots.txt 阻擋。

例如：

如果這項規則出現在正式網站，就等於要求搜尋引擎不要 Crawling 整個網站。

另一種情況則比較不明顯：

但 /products/ 恰好就是企業最重要的商品內容。

因此網站 正式上線、改版或調整 robots.txt

之後，都應該重新確認重要頁面是否仍然允許 Crawling。

另一個常見問題是重要頁面可以正常瀏覽，但被設定成 noindex。

這種問題使用者通常完全感覺不到。

網站：

但搜尋引擎卻收到 不要將這個頁面加入 Index 的指令。

特別是從 Staging 搬到正式環境時，要注意測試期間使用的 noindex 是否已經正確移除。

Sitemap 應該主要提供 網站希望搜尋引擎處理的正式 URL。

因此，如果 Sitemap 裡大量存在：

就代表 Sitemap 與網站其他 Technical SEO 訊號不一致。

例如 Sitemap：這是重要 URL

但 Meta Robots：不要 Index

這就是沒有必要的矛盾。

Canonical 很容易因為自動化設定錯誤而影響大量頁面。

常見問題包括：

因此不能只確認 HTML 裡「有 canonical tag。」

還需要確認它到底指向哪裡。

網站修改：

之後，如果舊 URL 已經累積：

卻直接變成 404，就可能造成不必要的搜尋資產損失。

如果新舊內容存在明確對應關係，應該建立適當的永久 Redirect。

因此，URL 不應該被視為 可以隨意修改的文字欄位。

它本身就是網站長期累積的搜尋資產之一。

有 Redirect 不代表 Redirect 就一定處理得很好。

例如：

/page-a

↓

/page-b

↓

/page-c

↓

/page-d

這代表網站歷經多次 URL 修改後，不斷把新的 Redirect 接在舊規則後面。

比較乾淨的結果應該盡量是 /page-a → /page-d

因此網站進行 URL Migration 時，也應該定期檢查 Redirect 最後是否直接指向正式 URL。

網站內部如果存在大量 Internal Link → 404

不只影響使用者體驗，也代表網站自己的內容架構已經失去一致性。

常見原因包括：

因此，即使舊 URL 已經設定 Redirect，也建議逐步把網站自己的 Internal Link 更新成 最終正式 URL。

不要長期依賴 Redirect 修補內部網站架構。

Soft 404 是一個很容易被忽略的問題。

例如頁面畫面顯示 「找不到此內容。」

但 Server 實際回傳：200 OK

這就可能讓搜尋引擎收到矛盾訊號：畫面說內容不存在，但 HTTP 卻說頁面正常。

因此 404 不只是設計一個 漂亮的 404 頁面。

更重要的是 Server 必須回傳正確的 HTTP Status Code。

JavaScript 網站常見的 Technical SEO 問題不是「用了 React。」

而是 重要內容完全依賴 Client-side JavaScript，但搜尋引擎無法可靠取得。

例如：

沒有出現在初始內容，而且 Rendering 又發生錯誤。

因此 JavaScript 網站應該實際確認 搜尋引擎最後取得了什麼內容。

而不是只看瀏覽器畫面 「我這邊看得到，所以 Google 應該也看得到。」

Structured Data 最常見的錯誤之一，是 為了 Schema 而創造頁面不存在的資料。

例如：

這種問題不能靠「Schema Validation Passed」判斷是否正確。

因為技術格式正確 ≠ 資料內容正確。

Structured Data 最終仍然必須反映使用者真正看到的內容。

另一個常見的 Technical SEO 誤區是 把所有工程資源投入 PageSpeed Insights。

網站效能很重要。

但 Technical SEO 還包含：

如果一個重要服務頁被 noindex：

即使 PageSpeed 是：100 分

也沒有解決真正的 SEO 問題。

因此 Technical SEO 應該先按照 實際搜尋影響

決定優先順序，而不是：哪一個工具的分數最容易看到。

最後，也是企業網站影響範圍最大的問題之一：網站改版只處理設計與內容，沒有處理 SEO Migration。

結果可能出現：

因此，如果網站原本已經具有搜尋流量：

而不是網站上線後發現流量下降，才開始補救。

企業不需要看到問題就全部同時處理。

比較合理的是先問：「這個問題是否阻止重要頁面被 Crawling 或 Indexing？」

如果是：→ 最高優先。

接著確認：是否造成大量重要 URL、Canonical、Redirect 或網站架構錯誤？

如果是：→ 優先處理。

最後才是：改善幅度較小、沒有直接阻礙搜尋引擎處理網站的優化項目。

因此 1 個重要服務頁誤設 noindex

可能比 500 個沒有任何價值的舊 404 URL 更值得優先處理。

Technical SEO 涵蓋很多技術細節，但企業不需要每天逐項檢查。

比較實際的做法，是在網站上線、網站改版、SEO Audit，或發現搜尋收錄異常時，按照一份固定 Checklist 檢查。

以下可以作為企業網站 Technical SEO 的基礎檢查清單。

核心問題只有兩個：

「Google 能不能取得重要內容？」以及「真正重要的內容是否允許被索引？」

對使用 CMS 的企業網站而言，Sitemap 最好由系統根據實際內容狀態自動維護，而不是人工修改 XML。

真正的目標不是：「每頁都有 canonical tag。」而是「網站對正式 URL 的判斷保持一致。」

目前我們的平台除了 Slug 變更自動 Redirect，也已經具備通用 Redirect Manager，可以管理其他舊 URL → 新 URL 的轉址需求。

Internal Linking 不只是內容 SEO，同時也是搜尋引擎理解網站資訊架構的重要基礎。

重點不是：

「網站不能使用 JavaScript。」而是「重要搜尋內容必須能被搜尋引擎可靠取得。」

Schema 不需要越多越好。

正確比數量重要。

效能優化的核心仍然是：「改善真正的使用者體驗。」

如果是既有網站改版，再額外確認：

最後要特別注意：

Technical SEO Checklist 是檢查工具，不是 SEO 評分表。

不同網站的：

都不同。

一個只有 20 個頁面的企業形象網站，和擁有數萬商品的電商平台，需要處理的 Technical SEO 深度自然不同。

因此，比較合理的原則仍然是：

Technical SEO 的目的不是讓 SEO Audit 工具全部變成綠色。

而是不要讓網站本身成為搜尋成長的障礙。

Technical SEO 看起來涉及很多技術名詞

但這些項目最後其實都回到同一件事情：

企業做 SEO 時，內容仍然是非常重要的核心。

你需要了解：

Technical SEO 並不會取代這些工作。

它處理的是另一個問題當企業已經建立好的內容之後，網站本身是否具備正確的技術基礎，讓這些內容可以正常參與搜尋。

因此 Technical SEO 是一套需要隨網站持續維護的技術基礎。

如果這個基礎建立得好，企業就不需要每新增一篇文章，都重新處理一次 Canonical、Sitemap、Structured Data 等底層問題。

而可以把更多時間投入真正重要的事情了解搜尋需求、建立專業內容、改善使用者體驗，並持續累積網站的搜尋價值。