修復自家網站後學到的 SEO 經驗
過去幾天，我們以搜尋引擎的角度閱讀自家網站，找出六項值得修復的問題。每一頁都宣告了兩個 FAQ 區塊，Google 把我們裝飾用的背景光暈當作縮圖，一組範本頁面在搜尋那些它們並未回答的問題，而邊緣伺服器還擋住了預發佈環境上一個新的網站區段。這些問題都不算嚴重，但它們一直在悄悄地拖累我們的能見度。
網站概覽
mythex.ai 是一個單頁應用程式，我們在建構時進行預渲染：一個腳本走遍每個路由，為每個路由寫出靜態 HTML 檔案，並注入頁面的標題、描述和結構化資料（即告訴搜尋引擎頁面是什麼的 JSON-LD 區塊，參見什麼是結構化資料）。以下大部分問題都與預渲染步驟有關，因為那才是爬蟲真正讀取的 HTML。
1. 每一頁都聲稱自己是 FAQ 頁面
現象。 我們的 HTML 範本在結構化資料中帶有一個全站適用的 FAQPage 區塊，其網址指向 /faq。預渲染隨後又為每頁加上該頁自己的 FAQPage。結果全站每一頁都有兩個，而我們的私隱政策竟然告訴 Google 它就是 FAQ 頁面。
為何重要。 Google 預期每頁最多只有一個 FAQPage。多出一個並指向別處的標記，可能會令該頁的標記被打折扣，而不只是被忽略。
修復方法。 全站區塊已移除。每頁的 FAQ 標記現在只來自一個地方，包括 /faq 本身，它會從完整的問題清單建構標記。沒有 FAQ 的頁面現在不再宣告任何 FAQ，這才是誠實的做法。此外，如果任何頁面再次出現多於一個 FAQPage，預渲染會令建構失敗。只存在於某人記憶中的規則容易被打破；由建構程式強制執行的規則則不會。
2. Google 用了錯誤的圖片代表我們
現象。 在搜尋結果中，Mythex 的縮圖是我們首頁英雄區塊背後那個柔和跳動的光暈，一張裝飾性的背景圖，而不是我們的分享卡片。
發生原因。 我們從來沒有告訴 Google 哪張圖片代表某一頁，所以它就挑了它找到的那張。
修復方法。 解決同一問題的兩個方面：
- 指明哪張圖屬於該頁。 首頁現在有一個
WebPage節點，其primaryImageOfPage指向分享卡片；每個預渲染頁面的結構化資料都帶有自己的圖片（該頁的分享圖，或預設圖片）。 - 隱藏裝飾圖。 背景圖現在在
robots.txt中被禁止，並以noindex, noimageindex標頭提供，因此不會出現在圖片搜尋或縮圖中。
3. 搜尋引擎只認得我們的標誌
我們的 Organization 標記只有名稱、標誌和一些社交連結，全是品牌資訊，沒有其他內容。搜尋引擎會根據登記式的事實建構公司的知識面板，因此我們加入了商業登記證上的資料：法定名稱、成立日期、創辦人和註冊地址。我們刻意沒有加入電話號碼。
4. 範本頁面回答了錯誤的問題
現象。 Search Console 顯示三個範本頁面有曝光但沒有點擊。其中一頁在「content strategist portfolio」及其變體的搜尋中排名靠前，另一頁針對「best italian restaurant website design」，第三頁則是圍繞「agile board」的一組搜尋——其中一半的搜尋都包含「free」一字。排名由第二十多名到五十多名不等。
原因。 每個頁面回答的都不是搜尋者所問的問題。想看優質意大利餐廳網站設計的人，卻來到了一個向他推銷建構工具的頁面。
修復方法。 這三頁現在各自加入了一個為搜尋而寫、而非為產品而寫的段落，標題和描述也改用人們實際輸入的字詞，並加入了值得其既有標記的 FAQ。
同一次提交還修復了一個較隱蔽的問題。「相關範本」區塊會取某個類別中的前四個範本，結果每個作品集範本都指向同樣的四個作品集，而該類別的其餘範本則完全沒有內部連結。我們把它改為依子類別排序的循環結構：每個範本頁面現在正好有四個入站連結和四個出站連結。預渲染的 HTML 現在也會輸出這些連結——以前它們只在 JavaScript 運行後才存在，而爬蟲可能永遠不會運行 JavaScript。
5. 每次部署新頁面時即時通知 Bing
Google 不理會 IndexNow，這是一個在 URL 變更時通知搜尋引擎的協定。Bing、Yandex 和 Seznam 使用它，而 Bing 的索引正是 ChatGPT 搜尋所讀取的來源。一個 AI 應用程式建構工具若連 AI 助手也找不到，那就是一種特別的失敗。
顯而易見的做法是每次部署都提交整份網站地圖，但這正是令金鑰被限流的做法，而且大多數部署並沒有改變搜尋引擎在意的任何內容。因此，有一個腳本會比較網站目前提供的網站地圖與剛建構好的網站地圖，只提交兩者的差異。
有兩個細節令它得以運作：
- 部署前先拍下快照。 基準必須在新建構上線之前取得。部署之後，「線上」的網站地圖已經是新的，每次比較都會得到空結果。
- 暫時只針對新頁面。 我們的網站地圖沒有
lastmod日期，因此腳本只會通知新頁面，而不會通知內容更新。如果為每個 URL 都加上建構日期，每次部署都會把整個網站標記為已更改——這正是我們一直在避免的垃圾通知。
它只在正式環境部署時運行，而且絕不會令建構失敗：執行到這一步時，網站已經上線，為了搜尋引擎的通知而令部署變紅並不值得。
6. 我們自己的邊緣伺服器回覆「找不到」
當我們推出 /ai 頁面時（詳見為每一種業務而設的著陸頁），預發佈環境對所有這些頁面都顯示「Not found」，而靜態主機其實正常提供它們。
在我們行銷網域前面的服務只會轉發一份允許清單上的路徑，其他一律回傳硬性 404。/ai 是新的，當時還不在清單上。我們加入了 /ai 和 /ai/*，並附上一個斷言它們可以通過的測試。這只是小問題，但正是那種令新網站區段對爬蟲隱形、而無人察覺的錯誤。
我們的心得
- 閱讀爬蟲所讀取的 HTML。 其中大部分問題在瀏覽器中看不見，但在預渲染的檔案中一目了然。
- 把 SEO 規則轉化為建構檢查。 「每頁一個 FAQPage」現在是強制執行的，而不是靠記憶。
- 清楚告訴搜尋引擎你的意思。 如果你沒有說明哪張圖片或哪些事實代表你，它們就會自行猜測。
- Search Console 會告訴你人們問的是哪個問題。 有曝光但沒有點擊，通常代表頁面回答了另一個問題。
- 只提交差異。 只通知有改變的部分，有助於遵守速率限制。
如果你要為自己建構的網站做同樣的事，我們的指南AI 建構網站的 SEO和如何設定 Google Search Console涵蓋了基本內容。