我做工業儲存與工控類網站的 SEO 已經超過二十年,這個產業有個很尷尬的特性:產品規格頁動輒上千頁,英文站、多語系站全開,但真正能被 Google 好好收錄、又能在搜尋結果裡被點進去的頁面,常常不到一半。老闆看的是展會詢盤,工程師看的是伺服器不要出錯,結果 SEO 卡在中間兩頭不到岸。這篇我把一家工業儲存廠商從索引、TDK、Schema 到多語系收斂的整套處理順序寫下來,順序本身就是重點,做錯順序會白費力氣。
1. 先認清工控網站的權重,不是靠內容量堆出來的
很多工控廠商第一次找我,開口就問「要不要多發文章衝流量」。我通常會先把他們的域名評分和同業擺在一起看,因為這個產業的競爭結構跟一般電商完全不同,搞錯對手你連力氣該花在哪裡都判斷不了。
1.1 域名評分落在 60 到 74 之間,對手其實沒你想的強
我手上這家工業儲存廠商,用 Ahrefs 抓出來的域名評分是 74,同產業前兩名的競品分別是 64 與 62。這組數字告訴我一件事:整個產業的權重天花板並不高,沒有誰是遙不可及的巨人。這跟消費性電子或內容媒體站動輒 80、90 的環境差很多。權重差距只有十幾分的意思是,你把技術債清乾淨、把每一頁的 TDK 寫對,追上甚至超車的機會是實際存在的,不需要靠海量內容硬拚。
我的實務經驗是,B2B 工控站的排名成長,七成來自技術面與結構面的修正,只有三成來自新增內容。這跟大家想像的相反,但如果你的產品頁本身連 Schema、canonical、索引都沒處理好,發再多文章都是往破桶裡倒水。
1.2 我踩過的坑:首頁那個只給爬蟲看的隱藏 H1
接手這家廠商時,我在首頁原始碼裡發現一個 class="crawal-only" 的 H1 標籤,內容是給搜尋引擎看的品牌關鍵字,但對真實使用者是隱藏的。這是十年前很流行的手法,現在則是 Google 品質指南明文禁止的行為。向搜尋引擎和使用者展示不同內容,一旦被判定,受影響的不是單一頁面,而是整站的信任分數。
我當年也做過類似的事,那是我入行前幾年最大的教訓。後來我養成一個習慣:任何「只給爬蟲看」的元素,不管它現在有沒有被抓到,一律移除。H1 應該是頁面上使用者看得見、而且語意最重要的那個標題,沒有例外。這家廠商後來把隱藏 H1 換成真實可見的品牌標語,置於頁面頂部,風險就解除了。
1.3 連隱藏的 div class 都要一起清
同一套模板裡,我還找到 <div class="crawal-only">SUCCESS STORIES</div> 這種隱藏區塊,散落在成功案例頁、技術頁等多個模板。單看它不影響排名,但我還是建議全站移除。理由是搜尋引擎的語意分析越來越依賴 class 與 DOM 結構,今天不影響,不代表下一次演算法更新後不會被納入判斷。清理這種殘留 class 的成本很低,留著的潛在風險卻不對稱,這種取捨我一律選擇清乾淨。
2. 你的 TDK 如果全站長一樣,等於沒寫
這是我在工控站看到最普遍、也最好修的問題。產品分類頁的標題和描述,幾乎每一頁都是同一段公司簡介複製貼上。這種寫法對 Google 來說,等於你自己放棄了每一個分類頁的關鍵字機會。
2.1 通用描述會稀釋掉每一個分類頁
接手時,這家廠商所有產品分類頁的描述都是同一句:「這是一家工業級快閃儲存與記憶體模組的全球領導品牌,擁有先進技術、客製化服務與穩定供貨」。固態硬碟分類、記憶卡分類、記憶體模組分類,通通這一句。問題在哪?搜尋固態硬碟的工程師和搜尋記憶卡的採購,需求天差地遠,但你的每一頁都在講同一段空話,Google 根本分不出哪一頁該對應哪個查詢。
我的原則是:分類頁的 Title 與 Description 必須把「產品線 + 規格 + 應用場景」寫進去。工控採購搜尋時打的是 industrial ssd、ecc dram、cfexpress 這類具體詞,而不是你的品牌宣言。
2.2 分類頁 Title 該長什麼樣
下面這張表是我實際幫這家廠商改的幾個分類頁前後對照,你可以直接感受到差別。左邊是純品類名,右邊把規格與應用寫進去。
| 分類頁 | 原本 Title | 改寫後 Title |
|---|---|---|
| 固態硬碟 | Solid State Drive | Industrial SSD｜Industrial Solid State Drive｜品牌名 |
| USB 與嵌入式儲存 | USB / Embedded | Industrial USB & Embedded Storage｜USB DOM, USB Drive & eMMC｜品牌名 |
| 記憶卡 | Memory Card | Industrial Memory Card｜CFexpress, CFast, SD & microSD｜品牌名 |
| 記憶體模組 | DRAM Module | Industrial Memory｜Industrial DRAM Module｜品牌名 |
改寫的邏輯不是把關鍵字硬塞,而是用「主分類詞｜規格與子產品｜品牌」這個三段式結構,讓一個 Title 同時涵蓋通用查詢與具體型號查詢。Description 也一樣,我會把應用場景一次列滿:嵌入式系統、工業電腦、自動化、監控、運輸、網通、邊緣運算,這些都是工控採購真的會搜的情境詞。
2.3 H1 與 H2 要跟 Title 呼應,別各說各話
改完 Title 只做了一半。我看過太多網站 Title 寫得很到位,H1 卻還是光禿禿一個品類名。這家廠商原本固態硬碟頁的 H1 和 H2 都只是「Solid State Drive」,我改成 H1 用「Industrial Solid State Drive」、H2 用「Industrial SSD Product Lines」。這樣做的目的是讓頁面的可見標題、隱含的關鍵字意圖、跟 Title 標籤三者一致,Google 判讀頁面主題時就不會收到互相衝突的訊號。頁面內部語意一致,是我認為最被低估、但回報最穩定的一項基本功。
3. 讓機器讀懂你:Schema 與社群標籤的實際配置
工控站的內容其實很結構化:產品有型號、有規格、有品牌;新聞有日期、有作者;案例有主題。這些天生就適合用 Schema 標記,偏偏多數工控站一個都沒放,白白錯過在搜尋結果裡顯示豐富摘要的機會。
3.1 六種頁型,對應六種 Schema
我幫這家廠商規劃的 Schema 對照如下。重點是「頁型歸頁型」,不要全站塞同一種,也不要拿 Schema 取代既有的 Organization 區塊,而是額外新增在後面。
| 頁型 | Schema 類型 | 必要欄位 |
|---|---|---|
| 產品頁 | Product | name、brand、sku、image、description、offers |
| 新聞頁 | NewsArticle | headline、datePublished、author、publisher、image、url |
| 成功案例頁 | Article | headline、description、author、publisher、about |
| 技術說明頁 | TechArticle | headline、description、author、publisher |
| 有麵包屑的頁 | BreadcrumbList | itemListElement 的每層 position 與 name |
| 關於我們 / 聯絡 | Organization | name、url、logo、address、telephone、sameAs |
我要特別提醒兩個實務細節。第一,產品頁的 name、sku、description、image 一定要用程式動態帶入各產品的實際資料,不能寫死一組,否則等於全站產品共用一張錯的名片。第二,新聞頁的 headline 與 datePublished 也要動態抓文章實際值。我看過有網站把 Schema 加上去了,卻所有文章都顯示同一個發布日期,這比不加還糟,因為它送出了明顯錯誤的訊號。
3.2 Open Graph 與 Twitter Card,別忘了 robots.txt 那道門
這家廠商原本完全沒有 Open Graph 與 Twitter Card 標籤,結果就是連結被分享到 LinkedIn、Facebook 時,預覽圖、標題、描述全部抓不到,對 B2B 來說 LinkedIn 分享是很重要的曝光管道,這一漏就是白白損失。我的做法是把 og:title、og:description、og:url、twitter:title、twitter:description 全部動態綁定頁面既有的 Title、Description 與 canonical,再上傳一張通用的預設預覽圖當作退路。
但這裡有一個很多人忽略的陷阱:我在檢查時發現他們的 robots.txt 把 facebookexternalhit 這個爬蟲整個 Disallow 掉了。意思是就算你 OG 標籤寫得再完美,Facebook 根本進不來抓,預覽還是一片空白。標籤和爬蟲權限要一起檢查,只做一半等於沒做,這是我每次都會回頭再確認的地方。
3.3 llms.txt 到底要不要做
這兩年很多人問我 llms.txt 要不要跟風做。我的立場是看情況,不是必要。這家廠商的 llms.txt 當時回傳 500 錯誤,我判斷是檔案格式不對或根本沒有這個檔卻被伺服器誤導。如果你決定要做,務必用純文字 UTF-8 格式,放正確的網站摘要資訊,讓 AI 搜尋引擎理解你的產品與服務。但如果你的產品頁 Schema、TDK、索引都還沒處理好,我會建議先別碰 llms.txt,把力氣放在回報更確定的地方。優先序排錯,是我看過最多人浪費預算的原因。
4. 索引沒進去,前面全白做
這一段是我認為工控多語系站最容易失血、卻最少人認真處理的地方。你 TDK 寫得再好、Schema 標得再漂亮,頁面沒被 Google 收進索引,一切歸零。這家廠商在 Search Console 裡的索引問題,是我看過相當典型的一組。
4.1 5xx 與 404 要分開處理,別混為一談
當時 Search Console 報了 14 筆伺服器錯誤 5xx,還有多達 400 筆 404。這兩種問題的處理邏輯完全不同。5xx 代表伺服器在該回應時出了狀況,可能是權限被拒或逾時,這種必須追程式碼與伺服器設定,因為它會讓 Google 認為你的站不穩定。404 則不一定是壞事,Google 官方原則很清楚:頁面若已不存在、也沒有替代內容,回傳 404 或 410 是正常的;只有頁面搬家、有明確替代頁時,才該用 301 永久轉址。
我的處理順序是,先把 400 筆 404 拉出清單,逐一核對哪些是真的該消失的舊頁、哪些是不該壞掉卻壞掉的高價值頁。前者不用理會,後者才去追問題。這種分流工作看起來很笨,但它能讓你把有限的工程時間花在真正影響排名的頁面上。
4.2 en 和 us 兩個版本互相打架,是最貴的內耗
這家廠商同時有 /en/ 和 /us/ 兩套英文內容,而且內容幾乎一模一樣,結果就是 Search Console 判定為重複網頁,Google 選的標準頁跟他們預期的不一致。這種內耗很傷,因為兩個版本在互相稀釋彼此的權重。我給的是二選一的決策框架,不是模稜兩可的建議:
| 方案 | 適用情境 | 做法 |
|---|---|---|
| A:保留 en 與 us | us 真的要服務美國市場、兩邊有不同商業用途 | us 做出差異化:美國聯絡方式、美國業務 CTA、美國供貨資訊、美國地區的 Organization 與 ContactPoint |
| B:只保留 en | us 內容與 en 幾乎相同、沒有美國專屬內容、想集中英文權重 | us 的 canonical 指向 en,或直接 301 轉到 en |
這家最後選了方案 B,把 us 全部 301 到 en,權重就不再分散。我想強調的是,這種決策沒有標準答案,取決於你的市場策略,但你必須做決定,懸而不決才是最糟的狀態。
4.3 多語系網址要收斂到唯一一個
Google 對網址的判定非常嚴格,對它來說 /jp、/jp/、/index.php/jp、以及 http 版本,是四個完全不同的網址,即使它們顯示同一頁內容。這家廠商每個語系都存在這種一頁多址的狀況,權重被切成好幾份。我的做法是每個語系只保留一種標準結構,其餘全部收斂過去。我還遇過同一篇新聞在 /tw/news/標題 和 /index.php/tw/news/標題 兩個網址各自被收錄、互相競爭,最後保留前者、把後者轉址就解決了。網址收斂是苦工,但它是把分散的權重集中回來最直接的方法。
5. 技術細節裡藏著一堆你沒注意的扣分項
前面都是策略層,這一段講的是那些單看很小、加起來卻很傷的技術瑕疵。我做站點稽核時,這類問題往往一抓就是幾十個,而且修起來很快,回報很即時。
5.1 圖片 alt 缺漏與 width/height 格式錯誤
這家廠商首頁有圖片缺 alt 屬性,這會讓 Google 讀不懂圖片內容,也讓螢幕閱讀器的視障使用者無法理解,圖片搜尋的免費流量就這樣漏掉。我的原則是後台能上架的圖片一律補 alt,而且 alt 要描述圖片實際內容,不是塞關鍵字。另外一個更隱蔽的問題是 width 和 height 屬性寫成 80px,這兩個屬性只能填純數字,寫成 80px 在嚴格模式下會被視為無效值,正確寫法是 width="80" height="80"。這種錯誤還會影響瀏覽器預留版位,間接影響版面穩定度。
5.2 標題階層跳級與空標題
我在首頁看到 H1 後面直接接 H3、H2 後面直接跳 H6,還有一個內容只有 <br> 的空 H3。標題階層是給搜尋引擎理解頁面結構用的,不是拿來調字體大小的工具。跳級和空標題都會讓機器對你的內容大綱產生誤判。我的建議很簡單:有標題內容就補文字,沒內容就不要用 heading 標籤,字體大小交給 CSS 處理,別動 heading。
5.3 aria 屬性指到不存在的 ID
無障礙相關的 aria 屬性也是常見地雷。這家的 Modal 用了 aria-labelledby="exampleModalCenterTitle",但頁面裡根本沒有這個 ID 的元素,這是明確的錯誤,要嘛補上對應的標題元素,要嘛移除這個錯誤屬性。還有些 div 用了 aria-labelledby 卻沒有搭配正確的 role,這種就要判斷是否真的需要,不需要就移除。無障礙做對不只是合規,它同時也是搜尋引擎理解頁面語意的輔助訊號,兩件事其實是同一件事。
6. 常見問題
工控 B2B 網站的 SEO,該先做內容還是先做技術?
以我做這個產業二十年的經驗,先做技術與結構。工控站的內容天生就很結構化,問題多半出在索引沒進去、TDK 全站雷同、Schema 沒標。這些修好之前,新增內容的邊際效益很低。把既有的產品頁與分類頁的基礎打對,通常比狂發文章更快看到排名變化。
域名評分不到 70,是不是就很難跟大廠競爭?
不一定,要看你的產業競爭結構。工業儲存這類 B2B 利基市場,同業的域名評分經常也只落在 60 幾分,整體天花板不高。這種情況下,把技術債清乾淨、把每頁 TDK 寫對,追上前段班是實際可行的,不需要跟消費性市場那種 80、90 分的巨頭硬拚。
產品分類頁的 TDK 到底要寫多具體?
要具體到採購真的會搜的詞。用「主分類詞｜規格與子產品｜品牌」的三段式結構寫 Title,Description 則把應用場景一次列滿,例如嵌入式系統、自動化、監控、運輸、邊緣運算。避免全站共用一段公司簡介,那等於放棄每一頁的關鍵字機會。
多語系網站的重複頁,一定要處理嗎?
要,而且越早越好。en 與 us 這類內容雷同的版本會互相稀釋權重,同一頁的多個網址變體也會分散收錄。處理方式是每個語系保留唯一一種標準網址結構,重複版本用 canonical 或 301 收斂過去。懸而不決的狀態對排名的傷害,比做任何一個決定都大。
llms.txt 是不是每個工控站都該做?
不是必要項目。如果你的產品頁 Schema、TDK、索引都還沒處理好,我會建議先別碰 llms.txt。真的要做的話,務必用純文字 UTF-8 格式並放正確的網站摘要。優先序永遠是先把回報確定的基礎做完,再去做這種還在觀察階段的加分項。
Schema 加了之後,排名會立刻上升嗎?
Schema 的直接作用是幫搜尋引擎理解內容、爭取豐富摘要的顯示機會,而不是直接推升排名。它能提高在搜尋結果被點進來的機率,長期對流量有幫助。但前提是欄位要動態帶入各頁真實資料,如果所有產品共用一組寫死的資料,反而會送出錯誤訊號,那比不加還糟。