WordPress SEO 與網站技術優化
香港大部分中小企網站建於 WordPress。問題通常不在「內容寫得不夠多」，而在外掛與主題拖慢頁面、taxonomy 製造重複頁、模板不一致令每頁的標題與結構化資料各自為政。這些問題由開發員直接處理，不需要經第三方轉達。
WordPress 網站常見的 SEO 瓶頸
外掛衝突與臃腫主題拖慢頁面
多功能主題往往載入大量用不著的 CSS 與 JavaScript；SEO、快取、頁面編輯器等外掛各自注入資源，互相重複。結果是手機開啟需要數秒，而多數搜尋來自手機。
taxonomy 失控，製造重複頁與 crawl waste
tag、category、author、date archive 預設全部可索引，內容近乎相同的頁面因而大量產生。搜尋引擎把抓取預算花在這些頁上，真正重要的服務頁反而更新得慢。
內容模型混亂，每頁各自為政
沒有統一的 template，標題層級、meta、結構化資料由不同人在不同時期以不同方式加入。搜尋引擎與 AI 都難以判斷這個網站的主題與層級。
改版或遷移導致排名流失
換主題、改網址結構或搬主機時，若沒有完整的 URL 對照與 301 規劃，累積多年的排名可能在數週內流失，而且不容易復原。
WordPress 技術審計清單
每個 WordPress 項目由同一份清單開始。以下是實際檢查的項目，不是概括說法。
- 全站爬取：URL 結構、狀態碼、重定向鏈、孤兒頁
- 索引狀態：robots.txt、meta robots、canonical、被索引頁數 vs 應被索引頁數
- taxonomy 審視：tag / category / author / date archive 的索引策略
- 重複內容：分頁、篩選參數、附件頁、近似模板頁
- 標題與層級：每頁單一 H1、H2/H3 是否反映內容結構
- 結構化資料：現有 schema 是否與可見內容一致、有否重複或失效標記
- 外掛盤點：每個外掛的資源負擔、功能重疊、是否仍在維護
- 主題負擔：未使用的 CSS/JS、字型載入方式、圖片格式與尺寸
- Core Web Vitals：field data（真實用戶）與 lab data 分開評估
- 多語設定：hreflang 是否互指、canonical 是否指向自身
- 內鏈圖：重要頁面的內鏈數量與深度
- 伺服器與快取：TTFB、快取層級、資料庫體積與 autoload 資料
- CDN / WAF 規則：確認防護設定沒有連搜尋引擎爬蟲一併阻擋
速度優化實作
速度優化不是安裝一個快取外掛。順序通常是：先量度真實用戶數據（Core Web Vitals field data），找出是載入、互動還是版面偏移的問題，再對症處理 —— 因為三者的成因完全不同。
常見的實際工作包括：移除或替換重疊的外掛、清走主題未使用的資源、圖片改為現代格式並設定正確尺寸與 lazy loading、字型改為本機託管並預先載入、抽出 critical CSS、延後非必要 JavaScript、設定合適的快取層級，以及清理長年累積的資料庫與 autoload 資料。
每一項改動都會記入 change log，並在改動前後比對數據。如果某項優化沒有帶來可量度的改善，我們會如實說明，而不是計入「已完成項目」。
保留 WordPress、轉 headless、還是重建？
我們不推薦特定平台，我們推薦你的團隊維護得到的平台。以下是實際的判斷準則 —— 多數情況下，答案是留在 WordPress 並修好它。
| 判斷準則 | 留在 WordPress | 考慮重建 |
|---|---|---|
| 團隊維護能力 | 非技術同事需自行改內容 → 留在 WordPress | 有開發資源或由我們持續維護 → 可考慮重建 |
| 更新頻率 | 每週多次更新內容 → WordPress 後台較直接 | 內容穩定、甚少改動 → 重建的維護成本較低 |
| 現有網站狀況 | 結構清晰、只是速度與 schema 有問題 → 優化即可 | 資料模型混亂、外掛積累多年難以拆解 → 重建可能更划算 |
| 功能需求 | 需要表單、會員、電商等成熟生態 → WordPress 有優勢 | 需要客製介面或特殊效能要求 → 重建較合適 |
| 預算與時間 | 預算有限、想逐步改善 → 優化可分階段進行 | 有一次性預算、想重設基礎 → 重建一步到位 |
我們自己的網站建於 Next.js，因為它由同一個團隊開發與維護，沒有非技術同事需要改內容。這是我們的情況，未必是你的情況 —— 平台選擇應該由維護者決定，不是由服務商的偏好決定。
如需重建：網站建置由 HKD 8,800 起（一次性）；加入 6 個月或以上 SEO 方案的客戶費用全免。優化現有網站則計入月費方案範圍內。
零損失遷移清單
遷移或改版最貴的錯誤，是沒有轉址規劃。以下是我們每次遷移都會執行的步驟。
- 1遷移前完整爬取舊站，記錄所有 URL、標題、狀態碼與內鏈
- 2匯出 Search Console 的查詢與頁面數據，作為對照基準
- 3建立 URL 對照表：每一條舊網址對應新網址，不留空白
- 4設定單步 301，避免重定向鏈
- 5確認內容對等：新頁不可比舊頁少內容或少內鏈
- 6staging 環境設 noindex，避免測試站被索引
- 7上線後即時重新爬取，比對狀態碼與 canonical
- 8檢查伺服器 log，確認搜尋引擎實際抓取到新結構
- 9提交新 sitemap，並在 Search Console 觀察索引狀況
- 10保留 rollback 方案，至少維持到數據穩定為止
沒有做這份清單，實際會發生什麼
一間多倫多的醫學美容診所，網站由前一間服務商改版。改版本身完成了，但三件事沒有處理：舊網址沒有對照與轉址，產生大量 404；沒有設置 301，累積多年的排名訊號無法傳遞到新頁；語言結構由中英混合改為子目錄後，hreflang 沒有正確設定，兩個語言版本互相干擾。
結果是流量自 2025 年底起明顯下跌，而且不會自行恢復 —— 這類問題不會隨時間變好，只會持續流失。我們於 2026 年 5 月接手，先處理 404 與 301、修復失效內部連結、解決頁面之間的關鍵字重疊，之後才進行競爭對手內容與差距分析。流量正逐步回升，復原仍在進行中。
值得強調的是：這些都不是罕見錯誤，而是改版時最常被略過的三項。清單存在的原因，就是它們一旦漏掉，代價由客戶承擔，而且要數個月才修得回。
改版之後流量流失。舊網址沒有導向、hreflang 設定錯誤 —— 我們接手修復。
看這個案例另一種情況：補救措施本身造成損害
一間多倫多的醫學美容診所遭受 DDoS 攻擊：大量惡意機械人在短時間內發送請求，伺服器超出負荷，頁面出現 404、無法正常存取。升級伺服器並不能從根本解決 —— 攻擊流量會跟著漲。
為了止血，網站一度透過 CDN 採取嚴格的全面封鎖。攻擊是擋住了，但同時擋住了 Google 等搜尋引擎的爬蟲 —— 網站無法被檢索與建立索引，自然流量隨之下跌。換言之，真正令 SEO 受損的不是攻擊本身，而是補救措施。
我們接手後先分析攻擊來源與被針對的頁面，改為精準規則：只封鎖惡意來源與受攻擊路徑，重新開放正常流量與搜尋引擎爬蟲，再全站掃描確認可抓取、可索引，並監察索引恢復情況。
這正是為什麼技術審計要檢查 CDN / WAF 規則。安全設定與可被檢索之間的取捨，需要同時懂兩邊的人來判斷 —— 純內容型的 SEO 服務商通常不會看到這一層。
防 DDoS 的封鎖規則把 Google 爬蟲一併擋住，網站在搜尋結果中消失。
看這個案例交付內容
- 技術審計報告：按上述清單逐項檢查，附優先級與預期影響
- 改動記錄（change log）：每項改動的內容、日期與前後數據
- 速度優化實作：不只提交建議，改動由我們執行
- Schema 部署：只按可見內容標記，不濫用
- 遷移或重建（如適用）：附完整 URL 對照表與 rollback 方案
- 每月數據報告：Search Console 與 Core Web Vitals 對照基準
適合／不適合
適合
- 網站建於 WordPress，速度慢或排名長期停滯
- 改版或遷移後流量下跌，想找出原因
- 有內容但技術基礎拖慢成效
- 需要有人直接改網站，而不是交一份建議報告
不適合
- 想要保證排名或保證流量 —— 我們不提供這種承諾
- 只想加大量近似頁面覆蓋關鍵字變體
- 網站仍在規劃階段、尚未有內容 —— 應先處理內容與結構