工控與工業儲存類網站做 SEO，順序比努力更重要：先把索引、TDK、Schema 這些技術與結構面清乾淨，再談新增內容，否則發再多文章都是往破桶裡倒水。這個產業有個很尷尬的特性，產品規格頁動輒上千頁、英文站多語系全開，但真正能被 Google 好好收錄、又能在搜尋結果裡被點進去的頁面，常常不到一半。這篇我們把一家工業儲存廠商從索引、TDK、Schema 到多語系收斂的整套處理順序寫下來，順序本身就是重點，做錯順序會白費力氣。
1. 先認清工控網站的權重，不是靠內容量堆出來的
很多工控廠商第一次找我們，開口就問要不要多發文章衝流量。我們通常會先把他們的域名評分和同業擺在一起看，因為這個產業的競爭結構跟一般電商完全不同，搞錯對手你連力氣該花在哪裡都判斷不了。
1.1 域名評分落在 60 到 74 之間，對手其實沒你想的強
我們手上這家工業儲存廠商，用工具抓出來的域名評分是 74，同產業前兩名的競品分別是 64 與 62。這組數字告訴我們一件事：整個產業的權重天花板並不高，沒有誰是遙不可及的巨人。這跟消費性電子或內容媒體站動輒 80、90 的環境差很多。權重差距只有十幾分的意思是，你把技術債清乾淨、把每一頁的 TDK 寫對，追上甚至超車的機會是實際存在的，不需要靠海量內容硬拚。根據我們的服務經驗，B2B 工控站的排名成長，多數來自技術面與結構面的修正，只有少部分來自新增內容。這跟大家想像的相反，但如果你的產品頁連 Schema、canonical、索引都沒處理好，發再多文章都是往破桶裡倒水。
判斷對手強弱時，我們不會只看單一域名評分，還會看對方的產品頁到底有沒有被好好收錄、TDK 有沒有寫對。很多工控競品的評分看起來比你高幾分，但點進去會發現它的分類頁 Title 也是一片空白、產品頁也沒上 Schema，代表它的分數是靠年資與外部連結撐著，內功其實跟你在同一個起跑線。這種對手是最值得優先超車的，因為你只要把結構面做得比它到位，就能在具體規格詞上壓過它。看清楚對手的底子，比盲目追一個評分數字有用得多。
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 也一樣，我們會把應用場景一次列滿：嵌入式系統、工業電腦、自動化、監控、運輸、網通、邊緣運算，這些都是工控採購真的會搜的情境詞。要注意一個順序：最重要的規格詞要放在 Title 前段，因為搜尋結果頁會從左邊開始顯示，太後面的字容易被截掉而看不到。Description 也是同理，把最能打中採購需求的規格與應用放在前半段，確保就算被 SERP 截斷，關鍵資訊也先露出來。我們幫客戶改完這類分類頁後，最先動的往往不是排名，而是點擊率，因為採購在搜尋結果頁一眼就看到你有他要的東西，這種領先感受用數據看得很清楚。
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，把力氣放在回報更確定的地方。優先序排錯，是我們看過最多人浪費預算的原因。換個角度說，llms.txt 做得再好，也救不了一個連基本索引都沒進去的站；但索引、TDK、Schema 都到位的站，就算暫時沒做 llms.txt，AI 搜尋引擎一樣能靠結構化資料理解你。先後有別，不能本末倒置。
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 拉出清單，逐一核對哪些是真的該消失的舊頁、哪些是不該壞掉卻壞掉的高價值頁，前者不用理會，後者才去追問題。這種分流看起來笨，卻能讓有限的工程時間花在真正影響排名的頁面上。我們在核對清單時，特別會留意那些帶流量、有外部連結指入、卻回了 404 的頁，這種最可惜，通常是改版時網址變了卻沒設轉址造成的，補一條 301 指到最相近的現有頁就能把流失的權重接回來。反過來，那些本來就是測試頁、參數頁、早該下架的舊頁，放著讓它維持 404 反而乾淨，硬要全部轉址到首頁只會製造一堆軟 404，讓 Google 更難判斷。
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，這種就要判斷是否真的需要，不需要就移除。無障礙做對不只是合規，它同時也是搜尋引擎理解頁面語意的輔助訊號，兩件事其實是同一件事。我們在做這類稽核時，通常會把這些小瑕疵整理成一份清單，按「修起來多快」和「影響多大」兩個維度排序，先清掉又快又有效的，例如批次補 alt、修正 width/height 寫法，這些一個下午就能處理一大批，而且圖片搜尋流量回得很快。把這種低成本高回報的技術項先收掉，團隊的信心和動能就建立起來了，後面再去處理需要工程排程的大項目。
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 的直接作用是幫搜尋引擎理解內容、爭取豐富摘要的顯示機會，而不是直接推升排名。它能提高在搜尋結果被點進來的機率，長期對流量有幫助。但前提是欄位要動態帶入各頁真實資料，如果所有產品共用一組寫死的資料，反而會送出錯誤訊號，那比不加還糟。正確的順序是先確保頁面本身有實際內容，再讓 Schema 去呼應它。