返回文章庫

SEO

2026 香港企業網站重整清單

真正有用嘅重整清單唔係驗收顏色、動畫同頁數;係逐項確認舊網站累積嘅客戶入口、語言關係、證據、追蹤同營運責任冇在上線一刻消失。

清單全綠。表格沒有寄到。差的就是這種「小事」。

01 / 先講答案

重整唔係換皮,而係重新分配信任

企業網站重整最常失敗嘅位置係『交界』:設計話內容由客戶提供,客戶以為 agency 會重寫;開發話追蹤由 marketing 處理,marketing 以為舊設定會自動搬;每個人都完成自己嗰份,整體卻冇人擁有。

最重要先分清:每個供應商都交咗功課,但客戶整段旅程冇人負責。

02 / 資產盤點

第一步先保存網站已經擁有的資產

情境示例,並非實際客戶案例:一間香港專業服務公司準時上線,桌面版亦通過驗收。兩星期後先發現簡體頁 canonical 指返繁體、WhatsApp 事件冇記錄、舊案例全部改咗 URL,而表格電郵落入垃圾郵件。項目冇一個『大 bug』,但四個細交界足以令新站失去查詢。

客戶唔係在一個頁面內作決定;佢係帶住你個頁面,走入另一個決策環境。

驗收清單必須有失敗条件,而唔係全部打勾

「手機版完成」並非驗收條件。真正條件可以係:在指定手機及瀏覽器,由一個舊搜尋入口進站,切换語言後仍停留在同一項服務,填錯資料有清楚提示,成功送出後收件人真的收到,而測量只記一次成功。每一項都有可以重做的路徑同可觀察結果。

先畫清流程,才知道重整要保留甚麼。
先畫清流程,才知道重整要保留甚麼。 Jakub Żerdzicki / Unsplash · Unsplash License

03 / 2026 要求

2026 的網站要同時被人、搜尋與 AI 理解

Google 嘅網站搬遷文件將 URL 對應、伺服器重定向、內部連結、驗證同持續監測視為完整過程;多語言文件亦要求語言版本互相回指。呢啲唔係上線後先補嘅技術附件,而係重整範圍本身。

網站其實同時服務三套系統:客戶要理解同採取行動;搜尋及 AI 系統要抓取、辨認同連接資料;公司內部要收件、跟進、更新同負責。只驗收畫面,等於只驗收其中三分一。

04 / 管理誤判

清單愈長,愈容易漏掉責任人

最常見清單有幾十項,但全部係『有冇』:有 logo、有 SSL、有 sitemap、有手機版。真正風險在於『啱唔啱』同『邊個負責』。有表格但寄錯人、有 hreflang 但互相唔回指、有備份但從未還原測試,勾咗剔都冇意思。

「應該沒問題」最好不要成為上線前最後一句話。(它也不是測試紀錄。)

紙上流程圖可以把分支和交接變得可討論。
紙上流程圖可以把分支和交接變得可討論。 Kelly Sikkema / Unsplash · Unsplash License

05 / 九層清單

由商業目標倒推驗收項目

  1. 商業層:逐頁寫明目標客戶、要解答嘅風險同下一個可量度動作。
  2. 資產層:匯出 URL、流量、查詢、外鏈、案例、圖片及三語對應,標記保留或合併。
  3. 技術層:驗證狀態碼、重定向、canonical、hreflang、索引、schema 同實際手機速度。
  4. 營運層:實測表格、WhatsApp、電話、CRM、垃圾郵件、權限、備份同故障責任。
  5. 上線層:保留基線,安排 24 小時、7 日、30 日巡查,並列出可回退條件。
驗收層一定要實測不能只問
客戶可否理解、比較、聯絡畫面靚唔靚
機器可否抓取、對應、索引裝咗插件未
營運收件、分派、回覆、備份電郵地址填咗未
搬遷舊 URL 到新 URL新頁全部存在未

上線前分清必須阻止發布的故障,同可以稍後改善的瑕疵。收不到查詢、重要頁面被 noindex、付款異常或大量錯誤轉址,應列為阻擋;一個低流量頁的圖片位置不完美,可以排期。若所有問題同一優先級,團隊通常先修最易展示嗰啲,而唔係最傷生意嗰啲。

06 / 遷移流程

一個不會在上線日失控的流程

重整前先為每個檢查項目指定負責人、驗收證據及失敗後處理方法。沒有 ownership 的清單,只會在上線前夕變成互相假設。

  1. 盤點商業目標、受眾、核心服務及現有高價值 URL。
  2. 鎖定語言、內容、元資料、Schema、追蹤與轉址規格。
  3. 在真實手機、表單、付款、WhatsApp 及不同權限下測試。
  4. 準備回滾、監察及上線後八星期的問題處理節奏。
原型適合提早驗證資訊次序與手機使用路徑。
原型適合提早驗證資訊次序與手機使用路徑。 Alvaro Reyes / Unsplash · Unsplash License

07 / 成效衡量

用上線前後兩套基線驗收

觀察層要記錄甚麼管理上代表甚麼
上線完整度表單、語言、追蹤、轉址及索引測試通過率確定基本功能冇漏
資產保留高價值頁的流量、連結及查詢保持避免換版抹走歷史
可持續性團隊完成一次內容更新所需時間證明新系統真的更易營運

交接亦要測試。由非開發人員在測試環境改一個課程日期、還原舊版本、更新三語資料,再檢查快取後顯示。網站唔只需要上線嗰日正常;下個月同事自行更新時,仍要能維持資料一致。沒有這一關,重整只是把維護成本延後。

08 / 常見問題

重整項目最常見三個問題

應否一次過全部上線?

若網站大、多語言或有交易功能,分階段通常較易隔離問題;小型網站亦要有回滾方案。

驗收只看設計稿夠唔夠?

不夠。要在真實網址、真實裝置、真實表單及真實權限下完成端到端測試。

上線後幾耐先算完成?

至少等主要頁被重新處理、追蹤穩定、舊 URL 無大批錯誤,而且團隊完成一次日常更新。

上線驗收要包含實際功能測試,而不只看設計稿。
上線驗收要包含實際功能測試,而不只看設計稿。 Alicia Christin Gerald / Unsplash · Unsplash License

09 / 限制與結論

真正完成,是團隊可以繼續改

清單唔可以取代判斷。五頁本地顧問網站同五萬產品電商嘅風險完全不同;受監管金融內容亦要加入審批、紀錄同聲明。應按最昂貴嘅失敗排序,而唔係追求所有項目一次滿分。

重整完成唔係新首頁出街嗰一刻;係三十日後,舊入口仍然到得到、新查詢接得住、三種語言互相對得返,而團隊知道下一次修改要搵邊個。

重整完成唔係新首頁出街嗰一刻;係三十日後,舊入口仍然到得到、新查詢接得住、三種語言互相對得返,而團隊知道下一次修改要搵邊個。

一個月後,同事改日期仍然不用求救,才叫真的交得出去。

10 / 資料註腳

資料與延伸閱讀

以上資料只用作理解機制及建立測試假設,並不代表任何海外結果會在香港企業自動重現。

只有結論,沒有推銷。

一篇有用的商業文章,即使沒有帶來購買,也應該令讀者作出更好的決定。

WhatsApp 聯絡 Locke Lee