修正自家網站的 SEO 心得

我們花了幾天時間，以搜尋引擎的方式閱讀自家網站，找出六件值得修正的事。每個頁面都宣告了兩個 FAQ 區塊，Google 把一張裝飾用的背景光暈當成我們的縮圖，一組範本頁面排名在它們並未回答的搜尋上，而網站新增的一個區段在預發佈環境中被我們自己的邊緣伺服器擋住。這些都不是戲劇性的問題，但它們悄悄地在損害我們的能見度。

網站的概況

mythex.ai 是一個單頁應用程式，我們在建置時會將它預先渲染（prerender）：一支腳本走訪每一條路由，為每一條路由寫出靜態 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/*，並寫了一個測試來確認它們能通過。這是個小 bug，但正是那種會讓新區段對爬蟲隱形、而且沒有人察覺的問題。

我們從中學到什麼

• 讀取爬蟲所讀取的 HTML。 其中大多數問題在瀏覽器中看不到，但在預渲染檔案中一目了然。
• 把 SEO 規則變成建置檢查。 「每頁只能有一個 FAQPage」現在是強制執行的，而不是靠記憶。
• 明確告訴搜尋引擎你的意思。 如果你不說明哪張圖或哪些事實代表你，它們就會自行猜測。
• Search Console 會告訴你人們問的是哪個問題。 有曝光但沒有點擊，通常代表頁面回答的是另一個問題。
• 只提交差異。 只通知有變動的部分，能讓你保持在限流規則之內。

如果你要為自己建置的網站做同樣的事，我們的指南 AI 建置網站的 SEO 與 設定 Google Search Console 涵蓋了基礎內容。