SEO入門實務指南：香港公司網站先做好哪些基本工作

SEO入門先做好三件事：開得到、看得明、知道下一步

先確認重要頁面可以正常讀取，再讓每頁回答一個清楚問題，最後建立可以觀察的查詢紀錄。這是香港公司網站做SEO入門時最值得先處理的次序。未弄清這三件事便大量加文章或改關鍵字，往往只會增加工作，卻不知道真正阻礙搜尋曝光的是甚麼。

搜尋引擎排名不是一個可以在後台打開的開關。網站要提供可供搜尋系統理解的內容，也要令進站的人願意繼續閱讀和採取行動。技術設定、頁面內容與業務接手各自負責不同部分；其中一環有問題，單靠另一環加大投入未必能補回。

老闆不需要先學會所有縮寫，但應能分辨三種問題：搜尋系統沒有取得頁面、取得後未選擇收錄，以及已出現在搜尋結果但未帶來合適查詢。三者需要的證據和處理方向不同，不宜一律稱為「SEO唔得」。

開始時先選幾個與公司業務直接相關的頁面，不必同日改動全站。小範圍檢查比較容易找到原因，也能留下改動前後的紀錄。沒有基準便一次改標題、內容、網址和版面，即使結果有變化，也難以判斷哪項工作產生了影響。

第一個優先項目：確認重要頁面真的可以進入搜尋流程

開到網站，不代表索引設定一定正確

公司同事可以用瀏覽器開到頁面，只證明某次瀏覽成功。搜尋爬蟲可能遇到不同的存取限制、回應或頁面內容。應檢查正式網址是否需要登入、是否被防護規則阻擋，以及主要內容能否被讀取。不要只看首頁正常，就假設產品頁、服務頁和文章頁全部正常。

Google 的搜尋技術要求列出基本條件，包括容許爬取、頁面可正常提供內容，以及內容可供索引；符合條件仍不保證會被收錄。對商戶而言，這提醒我們先排除阻礙，而不是把提交網址當成必然獲得排名的操作。

若重要頁面時常出現錯誤或無法連線，應把發生時間、網址及重現方法交給技術人員，同時核對網站寄存的運行安排。寄存只是其中一層，程式錯誤、資料庫問題及不合適的存取限制也可能影響頁面，不應只憑「慢」或「開不到」就立即更換主機。

分清禁止爬取與禁止索引

robots.txt 主要表達爬取規則；noindex 則用來表達不希望頁面被索引。兩者並非可以互相代替。若希望搜尋爬蟲讀到頁面的 noindex，就不能同時把它的讀取途徑完全封住。測試站和正式站的設定尤其需要核對，避免上線後仍沿用測試時的限制。

這裏不建議老闆自行刪除所有限制。帳戶頁面、內部工具及私人資料本來就有不同存取需要；不想公開的內容應有合適的權限保護，不能只依靠搜尋設定。請技術人員逐類檢查哪些頁面應公開、哪些應排除，並保留修改原因。

Search Console 的網址檢查可協助查看 Google 已知的索引狀態，即時測試則提供另一種當下檢查。兩者時間和用途不同，不能把即時測試成功解讀為已經收錄。當看到未收錄原因，應先閱讀該原因的官方說明，再判斷是否需要處理，而非把所有未收錄網址都當成錯誤。

例如網站本來就有篩選結果或其他重複版本，搜尋系統沒有把每個版本分開展示，不一定是問題。真正值得優先確認的，是有獨立用途、內容完整而且希望客戶找到的正式頁面。把主要頁面清單先列出，排查才有清楚對象。

檢查紀錄最好同時保存輸入的網址和最後到達的網址。若中途經過轉址，讀者看見的頁面可能已不是最初那一頁；若不存在的網址仍顯示一般首頁，亦可能掩蓋入口問題。請技術人員核對實際回應，不能只用瀏覽器最後看到的畫面代替判斷。

第二個優先項目：每頁只承擔一個清楚的主要任務

不少公司網站的問題不是內容太少，而是不同頁面一直說同樣的事。首頁、服務頁和文章頁都重複「專業、可靠、經驗豐富」，讀者仍不知道哪頁可以解答自己的疑問。先把頁面任務分開，通常比再加幾次關鍵字更有實際作用。

服務查詢與知識問題，分配到不同頁面

想找製作公司的搜尋者，需要了解服務範圍和合作方式；想知道網站改版要準備甚麼的人，則需要步驟、限制和注意事項。兩者可以互相連結，但不必使用相同的標題和開場。若文章只是一篇加長的服務介紹，便沒有真正回答資訊型問題。

假設一間九龍灣設備公司，有安裝服務和維修服務。前者的讀者可能關心現場條件及施工安排，後者可能需要先辨認設備型號和故障情況。把兩者寫成內容幾乎一樣、只換服務名稱的頁面，無法清楚交代差別。這是假設分頁練習，並非對任何實際公司的評價。

可以先用客戶電話、電郵及同事接單時反覆遇到的問題，整理一份用語清單。此時不必追求每個詞都有搜尋量數字，更不能編造數字來支持選題。先分辨公司是否真的能回答，以及答案應放在哪一頁，再使用可取得的搜尋資料驗證方向。

如果網站仍在製作階段，這份頁面分工應併入網站規劃與確認流程，避免設計完成才發現缺少必要內容。每個新增頁面都要有用途，不能只因為有另一個近義詞，就再建立一頁差不多的文字。

可替每頁加一欄「這頁不處理甚麼」。例如服務頁交代合作範圍，但不深入解釋所有技術故障；教學文處理資料準備，但不冒充正式報價。寫清界線後，同事便知道哪些內容應連去另一頁，哪些需要在本頁補足，減少文章之間反覆爭用同一題目。

第三個優先項目：讓內容足以支持讀者作出下一步決定

把形容詞換成條件、步驟與證據

「服務全面」可以改成清楚列出包括哪些工作、哪些情況需要另行評估；「流程簡單」可以解釋客戶需要準備哪些資料、誰會確認、下一步怎樣進行。這不是刻意增加字數，而是把讀者原本需要另外追問的內容寫清楚。

一篇有用的文章應幫讀者減少不確定性。比較主機時說明管理責任，談網店時交代付款及訂單的關係，講內容準備時則列出誰批准文字和圖片。每篇選擇與主題最相關的問題深入，不必把全部技術名詞都塞進同一頁。

公司的真實資料可以作為內容基礎，但要分清已知事實、公司自述及假設例子。沒有公開許可的客戶名稱和圖片不應直接使用；沒有證據的業績、規模或排名也不應補寫。可以用明確標示的假設場景解釋方法，但不能把它包裝成成功案例。

如果資料來自技術同事的口頭解釋，可以先記錄問題和適用條件，再請他確認整理後的文字。例如「可以備份」仍需要交代備份對象和復原限制；「可以接駁」也要說明依賴甚麼權限。這類確認讓內容保留技術邊界，不會在改寫時變成沒有條件的保證。

寫完後，用讀者需要的資料反過來檢查

例如一篇解釋網頁設計報價的文章，讀者看完應知道怎樣核對功能範圍、資料責任及後續改動，而不是只記得「不要只看價錢」。把結論轉成能執行的動作，才能看出文章是否提供了新理解。若每段只是重複同一提醒，篇幅再長也沒有增加用途。

對公司服務內容有疑問時，應由熟悉實際工作的同事確認，再交由寫作者整理。技術人員可以補充限制，營業同事可以指出常見誤解，營運同事則知道交付後會遇到甚麼。不同資料來源有分工，但最後要有一個人對公開版本負責。

版面也會影響讀者能否用到內容。長步驟可分段，真正需要比較的項目可用表格，重要限制要放在相關段落附近。不要把全部注意事項藏在文章最後，令讀者先形成錯誤理解。若表格在手機難以閱讀，應重新整理欄位，而不是單純縮小字體。

網站的頁面設計與內容安排可以配合這些需要，把服務、證據及行動放在合適位置。設計的作用是協助理解，不能代替缺失的答案；內容亦不能因為版面預留了很多區塊，就重複填入意思相同的句子。

標題、摘要、網址與連結，要讓頁面之間的關係清楚

標題先描述內容，摘要再補充值得閱讀的原因

每頁的 SEO 標題應能辨認該頁用途，避免整站都只有公司名稱加一串服務詞。頁面主標題也要與內容一致。Google 會參考多種來源產生搜尋結果的標題，因此後台填寫的文字不是每次都會原封不動顯示；重點仍是網站本身清楚、一致。

摘要宜說明頁面回答甚麼，以及讀者可以得到甚麼具體幫助，不要把關鍵字用逗號連成一串。搜尋結果摘要可能由頁面內容產生，並會因搜尋問題而不同；設定 meta description 有其用途，但不能把固定展示方式當成可保證的結果。

至於 meta keywords，Google 不把它用作搜尋排名。若 CMS 因管理需要保留這個欄位，可以正常填寫，但不用把大部分時間花在增加詞語數量。把同義詞自然用在清楚的句子中，比追求某個沒有依據的關鍵字密度更合理。

同一份內容有多個網址時，先找原因

網址參數、分類路徑或不同版本可能令同一內容出現多個網址。canonical 是用來表達偏好的代表網址，而不是隨意把所有頁面指向首頁。Google 仍會綜合其他訊號選擇代表版本；如果站內連結、轉址和 canonical 互相矛盾，便應由技術人員整理。

網站地圖可以幫助搜尋系統發現希望公開的網址，但不是保證收錄清單。應核對其中沒有放入未發佈、錯誤或明確不希望索引的頁面。正常導航及正文連結仍然重要，不能只把頁面加進 Sitemap，卻讓讀者在網站內完全找不到。

內部連結應出現在真正需要延伸理解的位置。寫寄存比較時可以連管理責任的說明，介紹服務流程時可以連相關服務頁；不用每一段都放同一個網址。連結文字要交代去向，避免大量「按此」或一整句毫無重點的連結。

檢查連結時，可從網站選單實際走到主要頁面，記錄哪一步需要猜測。若某篇文章只有後台網址，公開列表和相關頁面都沒有入口，便應安排合適的導航或正文連結。新文章若涉及排程，亦要等目標文章公開後才連過去，避免讀者先遇到不存在的頁面。

若要更改已有網址，先查是否已有外部引用、搜尋流量或營運文件使用，再安排合適轉址。不能只因為新網址看起來較好看，便刪掉原有入口。沒有業務需要時，保留穩定網址通常比反覆改名容易管理。

手機體驗與效能，先修阻礙閱讀和操作的問題

Google 採用流動裝置版本的內容作為索引及排名的主要依據，這不只是把桌面版縮細。手機版本應保留重要服務資料、標題、圖片說明和必要連結。若桌面有完整內容，手機卻只剩幾句介紹，兩邊提供的理解基礎便不同。

把可見問題分成載入、互動與版面穩定

Core Web Vitals 包括 LCP、INP 和 CLS，分別關注載入表現、互動回應及版面穩定。這些量度有助定位使用體驗問題，但不能把單一分數當成網站搜尋表現的總評。工具中的模擬測試與真實使用資料也有差別，應先知道正在看哪一種。

對老闆而言，可以先做具體操作：打開主要服務頁、閱讀規格、填寫查詢表格，再記錄何時看不到內容、按鈕何時沒有反應，或哪些元素突然移位。把現象及裝置交給團隊，比只要求「做到滿分」更容易排定真正有影響的修正。

修正後要重做同一組測試，並檢查主要業務功能有沒有受到影響。例如快取設定改動後，公開內容可能更快，但登入或個人化頁面需要另外處理。效能工作應與程式行為一同驗證，不能只追求某項數字改善而忽略正確性。

若網站流量較少，某些工具可能沒有足夠真實使用資料。這是資料條件，不代表體驗一定好或一定差。可以先用可重現的測試和實際操作找問題，再持續觀察；不要為了填報告而自行編造百分比或預計提升幅度。

用Search Console和查詢紀錄，判斷下一輪應改甚麼

先分開曝光、點擊和真正業務結果

Search Console 可以觀察搜尋曝光、點擊和查詢等資料；網站內的提交紀錄則幫助了解訪客是否完成某個動作。兩類資料用途不同，也不一定能逐筆直接配對。不要把搜尋點擊等同客戶，更不要把按下 WhatsApp 按鈕當成對方已經發送訊息。

可以先建立一份簡單週期檢視：哪些服務頁開始出現相關查詢、哪些頁面有曝光但少點擊、哪些頁面帶來不合適的查詢。每個問題都要回到頁面和業務條件判斷，而不是單看平均排名升跌。搜尋結果會受查詢、地區及裝置等因素影響。

如果公司同時做搜尋廣告與網上推廣，應分開來源和目的。付費廣告的即時點擊不能當作自然搜尋排名改善的證據；自然搜尋文章帶來的早期研究讀者，也未必在同一次瀏覽就提交查詢。量度要配合內容任務，避免用一個指標判斷所有頁面。

保留改動紀錄很重要。記下何時改了標題、補充內容、調整導航或修正技術設定，才有基礎理解之後的變化。若只看某天排名低了便立即再改，容易把短期波動與真正問題混在一起。觀察期間應按資料量和改動性質決定，不承諾固定日數見效。

看搜尋資料時，也應把公司名稱相關查詢和一般服務查詢分開理解。原本已認識公司的客戶搜尋品牌，與首次尋找服務的讀者，對頁面的期望不同。若品牌查詢增加，不能直接推斷所有服務詞都已改善；先按查詢和頁面範圍細看，才知道內容是否接觸到目標讀者。

比較時亦要注意季節、營業安排和服務供應是否改變。假設公司暫停某項服務，查詢減少未必由網站造成；假設市場需求改變，原有文章的問題設定也可能需要更新。數據是尋找原因的線索，不是替所有原因作單一解釋。

建立可以持續執行的內容安排，AI工具也要有核實責任

內容計劃應從公司真正能回答的問題出發，指定每篇文章的主要任務、資料來源及確認人。題目可以由客服問題、銷售溝通及產品更新取得，但不需要把每一個問題都寫成長文。先判斷是否有獨立答案，或應補進既有頁面，避免相似文章不斷增加。

更新舊內容與新增文章，需要不同判斷

若讀者問題沒有變，只是資料過時，更新原頁通常較容易保留清楚的入口；若問題對象或決策階段不同，才考慮新增頁面。更新時應查看相關連結及摘要是否仍合適，不要只換年份而保留舊內容。沒有實際改動，也不應把日期變新當成內容工作。

AI 工具可以協助整理訪綱、分類問題或檢查語句，但公司事實、技術限制及例子仍需核實。產生了流暢文字，不代表其中的年份、服務條款或案例存在。尤其涉及公司能力和客戶成效，應回到可提供的證據，而不是讓工具自行補全。

Google 對AI搜尋功能的說明仍強調既有 SEO 基礎，並沒有要求網站為 AI Overviews 加入某種專用標記。中小企可以先把重要資料寫清楚、讓正式頁面可被讀取，並核對公開內容的可靠性；不要把特殊檔案或文字格式當成曝光保證。

編輯時也要控制主題範圍。一篇回答公司電郵設定的文章，不需要為了湊長度大談所有網站設計服務；一篇主機比較亦不應變成沒有來源的品牌排行榜。內容深度來自把相關問題說透，而不是把更多關鍵字放進同一頁。

可以在每篇交稿時加一個內部問題：「讀者看完，能否說出下一個具體動作？」若答案只是「找專業人士」，內容可能仍太空泛。即使最後需要服務團隊協助，也應先讓讀者知道要準備甚麼資料、怎樣描述問題，以及哪些條件會影響選擇。

把工作排成下一輪可完成的清單

第一輪先檢查主要頁面及最重要的查詢動作。不要一開始便要求全站每頁都重寫，或同時追逐所有搜尋詞。選出與公司實際服務最接近的頁面，確認技術狀態、內容答案和行動路線，再決定下一輪投入。

1. 列出主要服務頁及希望訪客完成的動作。
2. 核對正式網址、索引設定和頁面可讀性。
3. 為每頁寫下一個主要問題，合併沒有獨立用途的重複內容。
4. 補齊影響決定的條件、流程及真實資料。
5. 實測手機操作和查詢提交，保存問題紀錄。
6. 建立搜尋與有效查詢的觀察方法，記錄每次改動。

分工可以很簡單：業務同事確認問題與事實，內容人員整理答案，技術人員核對設定，負責人決定先後。兩人的小團隊也可以按角色輪流處理，重點是每件事有人確認，而不是一定需要很多人。沒有資源做的項目先標示，不要用未核實內容填補。

每次工作完成後，留下修改了甚麼、為甚麼修改、由誰確認，以及下一次要觀察甚麼。若結果與預期不同，先檢查原來假設，而不是立即把全部設定回復。這份簡單記錄能幫公司累積自己的判斷，日後更換負責人時也不用從猜測開始。

當有人建議大量改動時，可以先請他說明正在解決哪個已觀察到的問題、需要甚麼證據，以及完成後如何檢查。這樣能把討論從「聽說某招有效」拉回網站本身。可靠的工作安排應能被理解和覆核，不能只依賴模糊的排名承諾。

Black Media 提供網站製作及網上廣告推廣相關服務。若你已列出最想改善的頁面和目前遇到的情況，可以提出網站搜尋問題，先核對需要處理的技術或內容環節，再安排合適的下一步。