網站健檢:中小企業最常見的 9 個技術問題

2026 年 8 月,我們替一家台灣中小企業做了一次網站技術健檢。那是一個經營多年的 WordPress 網站,屬於教育服務業,累積了大約一千篇部落格文章,首頁做得漂亮,內容量也不算少。老闆的問題很單純:「我們每年花錢寫文章、也在投廣告,為什麼感覺沒什麼效果?」

第一項檢查就卡住了。整個網站只掛著 Universal Analytics 的追蹤碼,從頭到尾找不到 GA4。而 Google 早在 2023 年 7 月 1 日就讓標準版 Universal Analytics 停止處理新資料,並在 2024 年 7 月 1 日永久刪除 UA 的介面與歷史資料。換句話說:這個網站累積了上千篇文章,卻已經大約三年沒有任何流量數據。沒有人知道哪一篇有效、哪一篇沒人看、哪一個頁面帶來了詢問。

先把兩件事講清楚。第一,這篇文章的案例是一個網站,不是一份統計。 我們不會說「多數台灣中小企業網站都這樣」,因為我們沒有做過那種規模的抽樣調查。這只是一次真實健檢的完整記錄,加上一項我們另外補上的普遍性項目,湊成九個值得每個老闆自己檢查一遍的地方。第二,這些問題大多不可怕,也不貴。 九項裡有六項,一個懂一點 HTML 的人一個下午就能修完;真正需要開發資源的只有兩三項。這篇文章的目的不是嚇你,是給你一份可以自己動手跑一遍的清單。

每一項我們都會給你五樣東西:症狀長什麼樣、為什麼有影響、你自己怎麼檢查(用瀏覽器就夠)、怎麼修、大概要多久。文章最後有一張可以列印出來逐項打勾的自我健檢表,以及一張依「影響 × 難度」排的優先順序表。如果你正在猶豫的其實是「乾脆整個重做算了」,那是另一個決策,我們寫在 網站改版還是重做;如果你想先估一下修這些大概要花多少錢,可以對照 網站架設費用與報價單怎麼看。

問題一:全站只有 Universal Analytics,你可能已經三年沒有數據

直接回答:如果你的網站只掛 Universal Analytics(UA- 開頭的追蹤碼)而沒有 GA4(G- 開頭的評估 ID),那麼從 2023 年 7 月起你的網站就沒有再記錄過任何一次瀏覽,而且 2024 年 7 月之後連舊資料都被永久刪除了。 這是我們這次健檢中最貴的一個發現,也是最容易被忽略的一個,因為網站看起來完全正常。

這件事的時間軸值得完整看一遍,因為很多人只記得「UA 要停用」,卻不知道歷史資料也被刪了。

Google 官方說明頁把這件事寫得很直白:標準版 UA 資源在 2023 年 7 月 1 日停止處理命中,而 2024 年 7 月 1 日之後使用者會失去所有現有與歷史 UA 資料的存取權(Google Analytics 說明中心)。產業媒體也在停用當下做了完整記錄(MarTech 的停用觀察)。

為什麼這件事比它看起來嚴重: 沒有數據不只是「不知道流量多少」,而是所有內容決策都變成猜的。這家公司有一千篇文章,如果其中有二十篇帶來了八成的詢問,他們沒辦法知道是哪二十篇,也就沒辦法把資源集中在正確的主題上。更糟的是,他們正在投廣告——廣告的著陸頁表現、跳出率、後續瀏覽路徑,全部是黑箱。

自己怎麼檢查(3 分鐘):

1. 打開你的網站首頁,按 Ctrl+U(Mac 用 Cmd+Option+U)檢視網頁原始碼。
2. 按 Ctrl+F 搜尋 G- 這兩個字元。裝了 GA4 的話,你會看到類似 G-XXXXXXXXXX 的評估 ID。
3. 再搜尋 UA- 。如果只找得到 UA- 而完全沒有 G-,你就是這個狀況。
4. 保險起見,登入 analytics.google.com,看資源清單裡有沒有標示 GA4 的資源,並確認「最近 7 天活躍使用者」不是 0。

怎麼修: 建立一個 GA4 資源、取得 G- 開頭的評估 ID,透過 Google 代碼管理工具或佈景主題的 header 掛上去,再用瀏覽器擴充功能確認有真的觸發。同時務必把 Search Console 接起來——那是唯一能免費看到「別人用什麼字搜到你」的資料來源,而且 Search Console 的成效資料保留期只有 16 個月(Google 官方說明),晚一個月接,就永久少一個月的歷史。

大概多久: 單純掛碼 1 到 2 小時。要把表單送出、電話點擊、詢價按鈕都設成轉換事件,抓 1 到 2 天。

最痛的一點,也是最該記住的一點:數據不能回補。 你今天裝上 GA4,拿到的是今天以後的資料;2023 到 2026 這三年,永遠是空的。所以這一項不管排在哪個優先順序,實務上都應該今天就做——每晚一天,就多一天永遠拿不回來的空白。

問題二:廣告追蹤參數拼錯一個字母,錢照花但轉換沒進來

直接回答:同一個網站的 Google Ads 追蹤碼裡,增強型轉換的參數被寫成 allow_enchanced_conversions,比正確的 allow_enhanced_conversions 多了一個 c。 參數名稱錯了不會噴錯誤訊息,只會被安靜地忽略——這個功能從掛上去那天起就從來沒有生效過,而他們一直在花錢投廣告。

這類錯誤特別危險,因為它沒有任何外顯症狀。網頁照常運作、廣告照常曝光、後台照常顯示「已安裝代碼」。JavaScript 設定物件裡的鍵值是嚴格比對的,拼錯的鍵不會觸發任何警告,瀏覽器只是把它當成一個沒有人會讀的欄位。Google 的 gtag.js 參數參考文件 列出的每一個參數名稱都必須逐字正確,沒有模糊比對、沒有自動修正。

為什麼有影響: 增強型轉換的作用,是把使用者自願提供的資料(例如結帳時填的 email)雜湊後回傳給 Google Ads,用來補回因為瀏覽器隱私限制而遺失的轉換歸因(Google Ads 說明)。它沒生效的後果不是「少一個功能」,而是你的廣告成效被系統性低估,出價演算法拿到的訊號是殘缺的。你可能因此關掉了其實有效的廣告組合,或者一直覺得「數位廣告對我們沒用」。

自己怎麼檢查(5 分鐘):

1. 檢視網頁原始碼,Ctrl+F 搜尋 enhanced。逐字比對是不是 allow_enhanced_conversions,特別注意 h 前面有沒有多出來的 c。
2. 順便搜尋 gtag、AW- 、conversion,確認轉換代碼真的存在於你以為它存在的頁面上(尤其是感謝頁 / 送出成功頁)。
3. 登入 Google Ads,到「目標 → 轉換 → 摘要」,看每個轉換動作的狀態欄。顯示「沒有最近的轉換」或「代碼未啟用」就是紅燈。
4. 更廣義的檢查:凡是你「相信有裝」的第三方代碼(Meta Pixel、LINE、熱點圖工具),都用同樣方法搜尋一次原始碼。相信和驗證是兩件事。

怎麼修: 改一個字母。真的就是改一個字母,然後在 Google Ads 的診斷頁確認狀態轉綠。

大概多久: 30 分鐘,含驗證。

這裡有一個更大的教訓:沒有人在驗收追蹤碼。 這個網站的每一個技術元件都「有人裝過」,但沒有任何一個環節有人「事後打開來確認它真的在運作」。這正是為什麼我們一直主張把追蹤與轉換事件寫進網站合約的驗收條款裡,而不是當成上線後的附加工作——具體怎麼寫,我們整理在 網站需求規格書與驗收清單。

問題三:語言宣告寫錯,中文網站對外自稱是英文站

直接回答:這個給台灣家長看的繁體中文網站,原始碼的第一行寫著 lang="en-NZ",也就是對外宣告自己是紐西蘭英文網站。 這通常是佈景主題或建站範本的預設值沒改,是所有問題裡最便宜、最快、也最容易被完全忽略的一項。

為什麼有影響: html 標籤的 lang 屬性是機器判讀網頁語言的第一個訊號。它影響三件事:一是搜尋引擎判斷這個頁面該對哪個語言的使用者呈現,Google 的 多語系網頁說明文件 明確要求語言標示必須與實際內容一致;二是螢幕閱讀器會依照這個屬性選擇發音引擎,宣告成英文的中文網頁,對視障使用者是災難;三是瀏覽器的自動翻譯提示會判斷錯誤——你的中文讀者可能會被問「要不要把這頁翻成中文?」

老實說,這一項對排名的直接影響通常不大,尤其當網站只有單一語言版本、內容本身也明顯是中文的時候。但它是一個非常好的代理指標:一個連 lang 都沒改的網站,幾乎可以確定其他預設值也沒有人動過——範本自帶的 favicon、範本自帶的 meta 描述、範本自帶的頁尾版權年份,通常都還在。健檢時我們把它當成「這個網站有沒有被認真交付過」的試紙。

自己怎麼檢查(1 分鐘): 檢視網頁原始碼,看最上面幾行。你要找的是 html 這個標籤和它後面的 lang 屬性。繁體中文網站應該是 zh-Hant-TW 或 zh-TW;如果你有英文版,英文版頁面應該是 en 或 en-US。中英雙語站還要確認兩個版本互相有 hreflang 標記。

怎麼修: WordPress 在「設定 → 一般 → 網站語言」改成繁體中文即可,大多數佈景主題會跟著輸出正確的 lang。如果佈景主題把它寫死了,就改主題的 header.php,或用外掛覆寫。

大概多久: 5 分鐘。這是全篇投報率最高的一項。

順帶檢查同一區塊的其他預設值: 網頁標題(title)是不是還寫著範本名稱或「首頁」;meta description 是不是空的或還是範本的示範文字;og:image 有沒有設定(沒設的話,別人在 LINE 或 Facebook 分享你的網址時會是一片空白)。這些都在原始碼的同一段裡,一次看完只要多花五分鐘。

問題四:一頁六個 H1,標題階層等於沒有

直接回答:這個網站的首頁有六個 H1,因為 FAQ 區塊的每一個分類標題都用了 H1。 需要先講清楚的是:Google 明確說過多個 H1 不會害你被降權,所以這不是一個「排名懲罰」問題;它是一個結構與可讀性問題,而結構在 AI 摘要時代的權重比以前高。

先把事實擺正,免得你被嚇到。Google 的立場一向是系統會盡量處理它看到的 HTML,一個 H1、多個 H1、甚至完全沒有語意標籤,都能運作;業界對標題標籤的整理也指出,語意正確的階層主要有利於無障礙與內容組織,而不是一個直接的排名因子(Search Engine Journal 的標題標籤指南)。所以如果有人拿「你有六個 H1」來報價要幫你做 SEO 大整修,那是話術。

那為什麼還是要修? 三個實際理由。第一,AI 擷取:ChatGPT、Perplexity 這類系統是整段擷取內容的,標題階層是它判斷「這一段在講什麼、屬於哪個主題底下」的主要線索。六個平行的 H1 等於告訴機器「這一頁有六個同等重要的主題」,結果是沒有一個主題被清楚地歸給你。第二,無障礙:螢幕閱讀器的使用者靠標題快速跳讀,亂掉的階層讓他們無法建立頁面地圖。第三,這是內部紀律的訊號:H1 被當成字級大小在用,代表編輯流程裡沒有人區分「這是標題」與「這只是想放大一點的字」,而同一個習慣通常會蔓延到整個網站的一千篇文章裡。

自己怎麼檢查(2 分鐘): 在你的網頁上按 F12 打開開發者工具,切到 Console 分頁,貼上 document.querySelectorAll('h1').length 然後按 Enter,它會回一個數字。正常應該是 1。想看內容的話,貼 [...document.querySelectorAll('h1')].map(h=>h.innerText) 就會列出每一個 H1 的文字。同樣的方法把 h1 換成 h2、h3 可以看階層是否合理。

怎麼修: 把非主標題的 H1 改成 H2 或 H3,視覺大小交給 CSS 處理。在 WordPress 的區塊編輯器裡,選取標題區塊後在右側面板改「標題層級」即可,不會影響外觀(如果會影響,那是佈景主題的樣式綁在標籤上,請工程師改成綁 class)。

大概多久: 單頁 15 分鐘。全站要看樣板數量,通常半天到一天。

問題五:84 張圖片有 81 張沒有有效的 alt 文字

直接回答:我們掃描這個網站時,首頁與主要頁面共 84 張圖片,其中 14 張完全沒有 alt 屬性、67 張是空字串,只有 3 張寫了有意義的替代文字。 圖片是這類網站最大宗的內容資產,而它們對機器來說幾乎是完全透明的。

為什麼有影響: alt 文字有三個用途。第一,無障礙——螢幕閱讀器讀不出圖片內容,alt 是唯一的橋樑。第二,圖片搜尋——Google 的 圖片 SEO 最佳做法 直接說明,替代文字是 Google 理解圖片主題的重要依據,對服務業與製造業來說,圖片搜尋常常是被低估的入口。第三,也是 2026 年最現實的一點:AI 讀不到圖片裡的字。如果你把課程時間表、產品規格、價目表做成一張漂亮的 JPG,對語言模型來說那個資訊等於不存在。這是製造業官網最普遍的自殘行為——把整份規格表做成圖片。

這裡要注意一個技術細節:空字串的 alt 不一定是錯的。 純裝飾用的圖片(分隔線、背景色塊、純視覺的圖示)按照無障礙規範本來就該給空 alt,讓螢幕閱讀器跳過它。所以 67 張空字串裡,可能真的有一部分是合理的。問題在於這個網站的比例——84 張裡只有 3 張有內容——這個分布幾乎可以確定不是刻意的設計決策,而是根本沒人填。Moz 對 alt 文字的整理 給了一個好用的判準:如果把這張圖拿掉,你需要用一句話向讀者說明少了什麼,那就該寫 alt;如果拿掉不會少任何資訊,才留空。

自己怎麼檢查(3 分鐘): 在網頁上按 F12 打開 Console,貼上這一行:document.querySelectorAll('img').length ,得到圖片總數;再貼 [...document.querySelectorAll('img')].filter(i=>!i.alt||!i.alt.trim()).length ,得到沒有有效 alt 的數量。兩個數字一比就知道嚴重程度。想快速看是哪幾張,把 filter 後面接 .map(i=>i.src) 就會列出網址。

怎麼修: 不要想著一次補完一千篇文章。按這個順序:先修首頁與主要服務頁(通常 20 到 40 張,一個下午可以寫完),再修流量前 20 名的文章(等你裝好 GA4 才知道是哪些,所以問題一要先做),剩下的排進日常編輯流程,新上傳的圖片一律要求填 alt。寫 alt 的原則是描述圖片內容與脈絡,不是塞關鍵字——「深灰色不鏽鋼閥門特寫,顯示螺紋接口」比「閥門 台灣 製造 工廠 供應商」有用得多,後者還可能被判定為關鍵字堆砌。

大概多久: 重點頁面半天。全站需要納入內容維運流程,以月為單位。

問題六:完全沒有結構化資料,AI 看不懂你在賣什麼

直接回答:這個網站有完整的 FAQ 區塊、有明確的公司資訊、有課程商品,但原始碼裡找不到任何一段 JSON-LD 結構化資料——沒有 FAQPage、沒有 Organization、沒有 Course。 換句話說,人看得懂的東西,機器全部要用猜的。

為什麼有影響,以及一個很重要的但書: 你必須知道 FAQ 結構化資料的現況,不然會被過期的建議誤導。Google 在 2023 年 8 月就把 FAQ 複合式搜尋結果限縮到權威的政府與醫療網站;到了 2026 年 5 月 7 日,FAQ 複合式搜尋結果已完全停止顯示,Google 也在 官方文件掛上了停用通知。所以如果有人跟你說「加了 FAQ schema 就能在 Google 佔更多版面」,那是 2022 年的說法,現在不成立。

那為什麼還要做?因為結構化資料的價值重心已經轉移了。它現在的主要用途不是換取搜尋結果的視覺版面,而是讓語言模型能夠無歧義地解析你的頁面。 Organization schema 告訴機器「這家公司叫什麼、在哪裡、聯絡方式是什麼、社群帳號是哪些」,這是 AI 判斷「你是不是它答案裡該提到的那個實體」的基礎;Course、Product、Service 這類標記則把你的商品從一堆散文裡結構化出來。Google 自己的 複合式搜尋結果總覽 仍然維護著數十種標記類型,其中大多數依然有效。

自己怎麼檢查(3 分鐘):

1. 最快的方法:打開 Google 複合式搜尋結果測試工具,貼上你的網址,按測試。有偵測到什麼、有什麼錯誤,一目瞭然。
2. 更原始的方法:檢視網頁原始碼,Ctrl+F 搜尋 ld+json。完全找不到,就是零結構化資料。
3. 進階:在 Search Console 左側選單看有沒有「強化」區塊的報表。什麼都沒有,通常也代表什麼都沒標。

怎麼修: 優先順序是 Organization(全站一份,放在首頁)、你的核心商品型別(課程用 Course、產品用 Product、服務用 Service)、然後才是 FAQPage(現在只為了給 AI 讀,不為了版面)。WordPress 有現成外掛可以產生大部分標記;客製網站就請工程師在樣板裡輸出 JSON-LD。唯一的鐵律是:標記的內容必須與畫面上看得到的內容完全一致,標了畫面上沒有的東西是違反 Google 政策的。完整的實作步驟與範例,我們寫在 AEO 技術實作手冊。

大概多久: Organization 加核心商品型別,2 到 4 小時。全站型別覆蓋 1 到 2 天。

問題七:1,700 字的文章只有一個 H2

直接回答:我們抽樣了三篇 1,500 到 1,750 字的文章,每一篇都只有 1 個 H2。 一千五百字配一個小標,意思是讀者要面對一整片沒有路標的文字牆,而機器要從裡面切出可引用的段落也同樣困難。

為什麼有影響: 這一項和問題四是同一個病的兩面。標題階層是內容的目錄,它同時服務三種讀者。人類讀者在手機上是掃讀的,沒有小標就沒有掃讀的著力點,跳出率會反映這件事。搜尋引擎用標題理解段落主題,Google 的 SEO 入門指南 建議用標題建立內容的階層結構,讓人和機器都能掌握頁面重點。語言模型則是整段擷取的——它需要一個標題來判斷「這段話在回答什麼問題」,才會在生成答案時把這段挑出來當引用。一篇一個 H2 的長文,對 AI 來說就是一大塊難以定位的內容。

實務上的判準很簡單:每 200 到 300 字應該有一個小標。 一篇 1,700 字的文章,合理是 5 到 8 個 H2,必要時再往下分 H3。而且每個小標本身就要能說清楚它底下在講什麼——「三、進階應用」是壞標題,「毛胚件公差怎麼影響後段加工成本」是好標題,因為後者被單獨抽出來時仍然成立。

自己怎麼檢查(2 分鐘): 隨機打開三篇你自己的文章,按 F12 到 Console 貼上 document.querySelectorAll('h2').length。或者更土法煉鋼:把文章列印預覽,看有沒有明顯的段落分隔。如果你捲三個螢幕高度都看不到一個小標,就是這個問題。

怎麼修: 不需要重寫,只需要重新切段。把既有內容依主題切開,替每一段補一個能單獨成立的小標,順便在文章開頭加一段 40 到 60 字的直接回答。這是編輯工作不是寫作工作,一篇熟練後 15 到 20 分鐘。同樣地,先修流量最高的那批文章就好——這又回到問題一,沒有 GA4 你連該修哪幾篇都不知道。

大概多久: 單篇 15 到 20 分鐘。挑 20 篇重點文章,約一週的零碎時間。

問題八:網站速度沒有人量過

直接回答:速度不是「感覺很慢才算問題」,它有明確的量化標準——最大內容繪製(LCP)應在 2.5 秒內、與下一次繪製的互動(INP)應在 200 毫秒內、累計版面配置位移(CLS)應在 0.1 以內,而且是看真實使用者的第 75 百分位(Google web.dev 的 Web Vitals 定義)。 大多數中小企業網站從來沒有人量過這三個數字。

為什麼有影響: 這裡要破除一個常見迷思——很多老闆以為速度只影響排名,所以「反正我排名還可以就算了」。速度的主要影響其實在轉換與體驗,排名只是附帶。手機使用者在等待時流失,是最貴的一種流失,因為那是你已經付費買來的流量。特別是有投廣告的公司:著陸頁多花兩秒,你買的每一次點擊的實際到達率就往下掉一截,而這件事不會出現在廣告後台的任何一個欄位裡。

第二個常見誤解是「速度慢一定要重做網站」。多數情況不是。中小企業網站最常見的三個拖慢原因都不需要重做:過大的未壓縮圖片(一張 4MB 的原始照片直接上傳當背景圖,是最常見的元兇)、塞太多外掛與第三方腳本(每一個追蹤碼、每一個聊天視窗、每一個字型服務都是額外的網路請求)、沒有啟用快取或 CDN。這三項處理完,通常就能把分數拉進可接受的範圍。

自己怎麼檢查(5 分鐘): 到 PageSpeed Insights 貼上你的網址,先看行動裝置分頁(不要只看電腦版,那會給你虛假的安慰)。頁面上半部若有「實際使用者體驗」區塊,那是真實資料,優先看它;下半部的實驗室分數是模擬值,用來看改善建議。把 LCP、INP、CLS 三個數字抄下來,對照上面的門檻。順便量一次你的三大競爭對手,你會立刻知道自己在什麼位置。

怎麼修: 依序處理:圖片壓縮並轉成新一代格式、移除沒在用的外掛與追蹤碼、開啟快取外掛與 CDN、把非必要的腳本改成延後載入。如果做完這些還是不行,才需要討論佈景主題或架構層級的問題——那時候才輪到 改版還是重做 那個決策,或者重新評估 WordPress 與 SaaS 建站平台 的取捨。

大概多久: 圖片與外掛清理半天到一天。架構層級的優化屬於專案,以週計。

問題九:HTTPS 與手機版的基本設定

直接回答:這兩項是及格線,不是加分題。 網址列沒有鎖頭的網站,瀏覽器會直接對訪客顯示「不安全」警告;而自 2024 年 7 月 5 日起,Google 只用行動版 Googlebot 檢索網站,手機上打不開的內容等於不會被索引。

先講 HTTPS。Google 早在 2014 年就宣布 HTTPS 是排名訊號,但 2026 年真正的問題已經不是排名,而是信任:主流瀏覽器會在非 HTTPS 的頁面上、尤其是有表單欄位的頁面上顯示明顯的不安全提示。一個要客戶留電話的詢價表單,旁邊掛著「不安全」三個字,這件事的轉換損失遠大於任何排名差異。常見的變形是「憑證有裝但沒裝好」——首頁是 https 但部分圖片或腳本仍走 http(混合內容),鎖頭一樣會消失。

再講手機版。Google 的 行動優先索引說明文件 已經把它列為基本要求:桌機版與行動版的內容必須一致,行動版少掉的內容就是索引不到的內容。中小企業網站最常見的失誤不是「沒有 RWD」,而是行動版偷偷藏掉了東西——為了版面乾淨,把規格表、認證清單、聯絡資訊在手機上隱藏起來。對 Google 來說,那些內容從此不存在。

自己怎麼檢查(5 分鐘):

1. 用你自己的手機,用行動網路(不要用公司 Wi-Fi)打開自己的網站首頁、主要服務頁、聯絡頁。看鎖頭在不在、看字會不會太小、看按鈕點不點得到、看表單填不填得完。
2. 在電腦上按 F12,點開發者工具左上角的手機圖示切換成行動裝置模式,對照桌機版看有沒有內容消失。
3. 檢查憑證:點網址列的鎖頭看有效期限。順便確認 http:// 的網址會不會自動轉址到 https://。

怎麼修: SSL 憑證現在幾乎所有主機商都提供免費的 Let's Encrypt,開啟後再設定全站強制轉址。混合內容問題可用資料庫搜尋取代把舊的 http 連結一次改掉。手機版隱藏內容則要請設計師改成折疊展開,而不是直接不輸出。

大概多久: SSL 半小時到 2 小時。混合內容清理半天。手機版內容一致性視情況,通常 1 到 3 天。

自我健檢表:九項逐條打勾

直接回答:以下這張表是為了列印出來用的。 九項全部只需要瀏覽器與兩個免費線上工具,一個人可以在半天內跑完,不需要任何開發背景。建議把它印出來,對著自己的首頁、一個主要服務頁、一篇文章各跑一次。

一個實務建議:跑這張表的時候把螢幕截圖留下來。 這不是儀式感,是為了兩件事——第一,你之後要驗收廠商的修復成果,需要一個修復前的對照組;第二,如果你打算換廠商或發包,這份截圖就是最有說服力的需求說明,比口頭描述「我覺得網站怪怪的」有效一百倍。要把這些發現轉成正式的發包文件,可以直接套用 網站需求規格書與驗收清單 的格式。

修哪個先?依「影響 × 難度」排優先順序

直接回答:如果你只能做一件事,做問題一(裝 GA4);如果你有一個下午,做問題一、二、三;如果你有一週,把前六項做完。 排序的邏輯不是「哪個最嚴重」,而是「哪個的損失會隨時間累積且不可回復」。

注意第 8 項和第 9 項的位置。它們不是不重要,而是它們的投報率必須先由數據決定。在沒有 GA4 的情況下優化速度,你不會知道改善了多少;在沒有流量數據的情況下重寫一千篇文章的標題,你有 98% 的力氣會花在沒有人看的文章上。這就是為什麼「裝追蹤碼」永遠排第一——它本身不產生任何價值,但它決定了後面每一項工作的命中率。

還有一個排序上的例外要提醒:如果你正在投放廣告,第 2 項應該提到第 1 項旁邊同時做。 廣告是唯一「你每天都在真金白銀支出」的項目,追蹤失效的每一天都是直接的金錢損失,而不只是資訊損失。

三個關於網站健檢的常見誤解

直接回答:健檢不等於改版、分數不等於成效、外包不等於免驗收。 這三個誤解決定了大多數中小企業在收到健檢報告後,會做出昂貴而錯誤的反應。

誤解一:「有這麼多問題,乾脆重做一個新的。」 這是最貴的錯誤反應。上面九項裡,只有速度優化在最壞的情況下可能牽涉到架構,其餘八項全部是在現有網站上就能修的設定與內容工作。我們健檢的那個網站,九項全修完的成本遠低於重建一個同等規模網站的費用,而且不會失去一千篇文章累積的網址與權重。重做的理由應該是策略性的(商業模式變了、內容架構根本不對、平台已經無法維護),而不是「問題看起來很多」——這個判斷怎麼做,改版還是重做的決策框架 有完整的評估流程。

誤解二:「PageSpeed 分數 90 分以上才算及格。」 分數是手段不是目的。Google 自己的 Web Vitals 標準是看真實使用者的第 75 百分位,而不是實驗室分數;一個 65 分但 LCP 實測 2.1 秒的網站,體驗好過一個 92 分但真實使用者 LCP 4 秒的網站。更重要的是,把分數從 85 推到 95 的邊際成本通常非常高,而那十分對詢問量的影響接近於零。先把 60 分以下的頁面拉到 75 分,再去追求完美。

誤解三:「這些是廠商的事,我付錢就好。」 這次健檢裡最刺眼的一項——拼錯的追蹤參數——正好證明了相反的事:每一個元件都有人裝過,但沒有任何人在事後打開來確認它在運作。中小企業老闆不需要會寫程式,但需要會做三件事:知道要檢查什麼、知道怎麼自己看一眼、知道驗收該在合約的哪一條。 這篇文章的自我健檢表就是為了第一件和第二件事寫的;第三件事在 網站需求規格書與驗收清單 裡。如果你的網站是製造業官網,還可以再對照一次 製造業官網 SEO Checklist 的產業專屬項目。

最後回到那個網站。健檢報告交出去之後,他們先做了什麼?裝 GA4、改那個拼錯的字母、把 lang 改成 zh-Hant-TW。三件事加起來不到一個工作天,沒有花任何一毛開發費。三年的數據回不來了,但從那天起,他們終於開始有資料可以判斷下一步該做什麼——而這正是一次健檢真正的價值:不是列出問題,是讓你重新拿回做決定的依據。