產品型錄網站怎麼規劃?製造業官網產品分類架構指南

業務經理把一本七、八十頁的 PDF 型錄放到會議桌上:「網站就照這本放上去。」這是台灣製造商做官網時最常聽到的一句話,也是整個專案最容易走歪的起點。型錄是照工廠的邏輯編的——依產品線、依料號、依開模的年份;但北美買家上網找供應商,是照他手上的問題在找:他要一款耐高溫的密封件、一種能用在食品接觸場合的潤滑油、一組適合挑高場地的燈具。網站架構要回答的是買家的問題,不是重現你的型錄目錄。

這篇文章只談「資訊架構」:產品該怎麼分類、幾百個型號該拆成多少頁、規格放在哪裡、篩選器會製造出哪些網址、結構化資料怎麼對應到整個型錄。單一產品頁的文案、規格表欄位的寫法與應用情境的寫作,我們在讓 AI 讀懂你的規格頁:產品頁 AEO 指南已經完整拆解,這裡不重複。兩篇的分工很單純:那一篇處理「一頁怎麼寫」,這一篇處理「幾百頁怎麼排」。

先講一個背景。Gartner 的研究指出,75% 的 B2B 買家偏好不需要業務介入的採購體驗。換成製造商的語言:買家在寄出第一封詢價信之前,多半已經自己在你的網站上把型號、規格與適用範圍比對過一輪。如果他在你的分類裡找不到東西,他不會打電話來問,而是回到搜尋結果,點下一家。如果你還在評估整個外銷網站的建置流程,可以先看外銷網站從零到上線,再回來處理型錄這一塊。

一、規劃前先盤點:九個數字決定型錄網站的骨架

直接回答:動手畫選單之前,先把型號數、系列數、規格欄位、應用產業、語系、圖片、PDF、認證文件與舊網址數清楚。 這些數字決定網站要幾層分類、要不要做篩選器、一個型號值不值得獨立一頁,以及翻譯與維護要花多少力氣。沒有盤點就開始設計,就像沒有 BOM 表就開模。

多數型錄網站的問題不是「做得不好看」,而是規劃時沒有人知道到底有多少東西要放。我們在汽車美容化學品製造商 H 的四語系官網重建裡,第一份交付物不是設計稿,而是把舊站 360 個網址完整抓下來,並且把產品頁重新抓過一輪、補齊規格。那次盤點直接決定了新站的規模:118 個產品乘上四個語系,共 472 個產品頁,加上分類頁之後全站約 660 頁。這個數字如果簽約前不知道,報價、時程與後台欄位設計都會估錯。

下面這張清單可以直接複製到試算表,請業務、生管、品保各自填寫自己最熟的那幾列。

型錄網站規劃前的盤點清單

盤點完之後,會得到一個粗略的公式:頁面總數約等於(產品頁+分類頁+應用專題頁)乘以語系數。以 H 製造商為例,光是產品頁就有 472 頁,還沒有算部落格。語系規劃我們在多語系外銷網站架構與 hreflang另外拆解;這裡只要記得,每多一個語系,後面所有架構問題都會多乘一倍。Google 的官方文件也規定,每一個語系版本都必須列出自己以及所有其他語系版本,語系越多,網址規則越要在一開始就定好。

破除一個常見迷思:很多老闆以為「產品頁越多,網站越強」。盤點的目的反而常常是做減法——把停產品、重複品、只差包裝的品項找出來,決定哪些合併、哪些下架、哪些用轉址保留舊網址累積的價值。這一步如果發包時沒寫進需求,廠商通常只會照你給的清單上架。建議參考網站需求規格書與驗收清單,把盤點列為專案的第一個里程碑,而且要求交付一份可以核對的表格,而不是一句「已完成內容整理」。

二、產品分類怎麼切:依類型、依應用、依規格各適合什麼情況

直接回答:主選單通常用「產品類型」當骨架,因為它最穩定;再用「應用產業」做第二入口,接住用問題在找的買家;「材質與規格」則做成篩選條件,不要拿來當主分類。 三種方式不是三選一,而是分工:類型負責結構,應用負責被找到,規格負責縮小範圍。

北美買家找東西的方式和你的型錄目錄不一樣。Google 的 SEO 入門指南提醒網站經營者,要預想讀者可能用哪些字詞搜尋,而且懂行的人和新手會用不同的詞——文件裡的例子是有人搜「charcuterie」、有人搜「cheese board」。放到製造業,採購工程師可能直接搜「316 stainless ball valve 1/2 NPT」,而一位負責新產線的廠務經理搜的可能是「valve for food processing washdown」。兩個人都不會搜你的內部料號。

這就是為什麼料號不該是分類名稱,也不該是網址的主體。Google 的電商網址設計文件把「/product/3243」這種網址列為不建議,建議在網址路徑中加入描述性的文字。料號仍然要出現在頁面上——老客戶會拿料號來找、會從舊訂單複製貼上——但它是規格欄位與站內搜尋的查找鍵,不是讓新買家理解你產品線的方式。

三種分類方式對照表

實務上最常見、也最穩定的組合是「類型當骨架、應用當入口、規格當篩選」。舉例來說,一家做金屬沖壓件的工廠,主選單是「支架/墊片/夾具/客製沖壓」;另外做「汽車售後市場」「太陽能支架」「家具五金」三個應用頁,每頁用兩三段文字說明這個產業在意什麼——耐腐蝕等級、公差、認證——然後列出相關產品,連回各自的產品頁;產品列表頁上再提供材質、厚度、表面處理的篩選。應用頁的價值在於它回答了一個產品頁回答不了的問題:「你們懂不懂我的產業?」

應用頁也有它的陷阱。同一個產品可能同時適用五個產業,如果每個應用頁都把完整的產品描述複製一遍,就等於在站內製造五份重複內容。正確的做法是應用頁只寫「這個產業的需求與選型重點」,產品本身的規格與說明只留在產品頁一份,應用頁用連結把買家帶過去。

分類幾層才合理

層數的判斷標準不是美感,而是買家點幾下能到產品頁,以及每一層是否都有實際的連結。Google 的電商網站結構文件說明,它會用「需要跟隨幾個連結才能到達某一頁」以及「有多少連結指向這一頁」來推斷頁面的相對重要性,並建議從選單連到分類頁、從分類頁連到子分類、再從子分類連到所有產品頁。同一份文件也提醒:如果分類頁沒有直接連到所有產品,Googlebot 可能無法只靠爬行找到全部產品,而且 Googlebot 一般不會在站內搜尋框裡輸入關鍵字。

這一句對製造業網站特別重要。很多型錄網站把幾百個型號藏在「請輸入料號查詢」的介面後面,對老客戶很方便,對爬蟲和 AI 卻等於不存在。一般中小製造商的型錄,兩層分類(品類、子品類)加上產品頁就足夠;超過三層,通常代表分類是照工廠內部邏輯切的,值得回頭檢查。

第二層效應:分類的方式也會影響網址資料夾怎麼設計。Google 入門指南提到,網站超過幾千個網址時,用資料夾把主題相近的頁面分組,可以幫助 Google 了解各個資料夾的更新頻率。幾百個型號乘上幾個語系,很快就會跨過這個量級,所以產品放在 /products/、應用專題放在 /applications/、技術文件放在 /resources/,會比所有頁面攤平在根目錄下好管理得多,日後分析哪一類內容有效也方便許多。

三、一個型號一頁,還是一個系列一頁?

直接回答:型號之間只差尺寸、顏色、包裝或少數幾個規格值,就做成一個系列頁,在頁內用規格表列出所有型號;型號有各自不同的用途、認證、圖面,或買家會單獨搜尋它,才值得獨立成頁。 判斷標準是「這一頁能不能提供其他頁沒有的資訊」,而不是「我們有幾個料號」。

這個問題背後有兩種方向相反的風險。拆太細,你會得到幾百頁幾乎一模一樣、只差一個數字的頁面;併太粗,買家搜特定型號時找不到專屬的落點,你也沒有地方針對單一型號放認證與圖面。

拆太細的風險:重複內容與過薄頁面

先講清楚一件常被誇大的事:Google 的官方文件寫得很明白,網站上有一些重複內容是正常的,而且並不違反 Google 的垃圾內容政策。你不會因為有二十個型號頁長得很像就被「懲罰」。真正的代價是另外三件事。

第一,Google 會自己挑一個代表頁。當一組頁面內容幾乎相同,Google 會從重複的頁面中選出它認為最具代表性的網址作為標準網址,其他頁面通常不會出現在搜尋結果裡。你以為做了二十頁,實際被看見的可能只有一頁,而且未必是你希望的那一頁。

第二,爬行資源被浪費。Google 入門指南指出,重複內容可能造成不好的使用者體驗,搜尋引擎也可能把爬行資源浪費在你根本不在乎的網址上。

第三,大量生成的相似頁面,越過某條線就變成政策問題。Google 的垃圾內容政策把門頁濫用的例子描述為建立大量相似的頁面,而這些頁面更像搜尋結果,而不是清楚、可瀏覽的層級結構;同一份政策也把主要為了操縱排名、而非幫助使用者而大量產生的頁面定義為規模化內容濫用。把一份規格表拆成三百頁、每頁只換一個尺寸,再用 AI 各生一段大同小異的介紹,就是在往這條線靠近。

同樣的邏輯在 B2B 平台上看得更清楚。H 製造商的阿里巴巴國際站上,同一個型號家族被拆成三百多個商品上架,其中真正拿到流量的不到二十個,整個家族累積下來只有一筆詢盤;我們最後立了「同一型號家族線上不超過十支」的規則。平台與官網的運作機制不同,但「同一批東西在搜尋結果裡互相稀釋」的道理是相通的。

併太粗的風險:沒有落點,也沒有證據

反過來,如果把整個系列塞進一頁、所有型號只用一張 PDF 表格帶過,買家搜特定規格時只能落在一個籠統的系列頁。更麻煩的是,若某幾個型號有獨立的認證——例如一個系列十二款裡只有三款通過食品接觸測試——系列頁很難把「哪幾款有、哪幾款沒有」講清楚,買家就得寫信來問,而多數人不會寫。

判斷標準:什麼時候拆,什麼時候併

中間路線:系列頁加上可直接連結的型號

很多時候最好的答案是兩者兼顧:系列頁是主要落點,每個型號在系列頁內有自己的錨點或可預先選取的網址。Google 的產品變體文件就是為這種情況設計的,它用 ProductGroup 表示母產品、用 hasVariant 列出各個變體、用 variesBy 說明變體依哪些屬性而不同,例如尺寸或顏色。文件同時要求每個變體都能用獨立的網址直接預先選取;而電商網址設計文件建議,如果用選擇性的網址參數來表示變體,就把不帶參數的網址設為標準網址。

換成白話:系列頁的網址是正式的那一個,「?size=m8」這類網址讓業務可以把某個型號的連結直接貼給客戶,但它們全部指回系列頁,不會變成幾百個互相競爭的頁面。

至於 H 製造商,我們選的是另一條路:118 個產品各自一頁。原因是汽車美容化學品的每一個品項——洗車水、蠟、鍍膜、內裝清潔——用途和使用方式都不同,本來就不是「只差尺寸」的關係。同樣是型錄網站,答案取決於你的型號之間到底差在哪裡。

四、規格表要做成 HTML,不要只放圖片或 PDF

直接回答:規格要用網頁上的文字與 HTML 表格呈現,因為搜尋引擎與 AI 檢索器擷取、比對、引用的主要是文字;規格若只存在圖片或 PDF 裡,就很難被當成可搜尋的欄位使用。PDF 可以保留下載,但網頁上要有完整的主要內容。

台灣製造商最常見的做法,是把型錄那一頁的規格表截圖,直接放在產品頁上。對人來說看得到,對機器來說這是一張圖。Google 的圖片文件說明,它是結合替代文字、電腦視覺演算法與頁面內容來理解圖片的主題——重點是「理解圖片在拍什麼」,而不是把圖裡的每一個公差數值變成可以被搜尋、被比較的欄位。你不能指望一張規格圖裡的耐溫範圍,被當成文字比對到買家的搜尋。

AI 檢索器的情況也類似,而且多一個陷阱。Vercel 在 2024 年 12 月分析自家網路的爬蟲流量後發現,主要的 AI 爬蟲目前都不執行 JavaScript,包括 OpenAI、Anthropic、Meta、字節跳動與 Perplexity 的爬蟲,並建議把關鍵內容改用伺服器端渲染。這代表規格表不只不能是圖片,也不能是頁面載入之後才用 JavaScript 從後台撈資料畫出來的表格。檢查方法很簡單:在瀏覽器按「檢視網頁原始碼」,搜尋一個規格數字;搜得到,機器就讀得到。

無障礙規範的結論也一樣。W3C 的 WCAG 2.2 成功準則 1.4.5 規定,只要使用的技術能達到相同的視覺呈現,就應該用文字、而不是文字圖片來傳達資訊。同一條規則,對搜尋引擎、AI 與無障礙三方面同時成立。

從架構層面設計規格欄位

單一產品頁的規格表怎麼寫,產品頁 AEO 指南有完整說明。從架構的角度,你要多做一件事:同一個分類底下的所有產品,使用同一組規格欄位、同一套單位與同一個欄位順序。這不是美觀問題,而是三個後續功能的前提:

• 篩選器要能運作,欄位名稱和值必須一致;「不鏽鋼 304」「SUS304」「304SS」在系統裡是三個不同的值。
• 比較表要能成立,兩個產品必須有同樣的欄位可以並排比較。
• 結構化資料要能批次產生,規格必須是資料庫裡的欄位,而不是寫死在每一頁內文裡的段落。

Baymard Institute 2025 年針對 170 多個大型電商網站的評測發現,58% 的桌機網站與 78% 的行動網站,產品列表的使用體驗落在「差」到「普通」之間;同一份研究也指出,有 14% 的網站不允許在同一類篩選條件裡複選。這些是消費性電商的數據;B2B 型錄網站連規格都很少被整理成可篩選的欄位,需要補的功課只會更多。

面對北美買家還要多想一步:單位。美國工程師習慣英制,許多產業同時使用公制。與其讓買家自己換算,不如在資料結構裡同時存兩套單位,或至少在表頭清楚標示。這件事在建資料庫的階段做很便宜,上線後回頭補,就是逐頁修改。

H 製造商搬家時,我們把產品頁重新抓過一輪、補齊規格,原因就是舊站的規格散落在不同格式裡。不先整理成一致的欄位,後面的多語系、篩選與結構化資料都做不起來。

PDF 型錄怎麼處理:保留下載,但主要內容要在網頁上

先說句公道話:PDF 並不是搜尋引擎讀不到的格式,Google 的文件把 Adobe PDF 列在可以索引的檔案類型裡。PDF 的問題不在「能不能被收錄」,而在它不是一個好的落點:一份八十頁的型錄只有一個網址,買家搜某個型號進來,看到的是封面;PDF 裡沒有網站選單、沒有詢價按鈕、沒有相關產品連結;規格一更新,就要重新排版、重新上傳,舊檔案還可能被別人存下來繼續流傳。

所以處理原則是三句話:

1. 型錄裡的每一個在售品項,都要有對應的網頁內容——至少在系列頁上有完整的規格文字。
2. 整本型錄保留為下載檔,放在資源頁或各系列頁,給習慣列印、轉寄給主管的買家使用。
3. 單品規格書與產品頁內容重複時,告訴 Google 哪一個是正本。Google 的文件說明,如果同樣的內容以 PDF 或 Word 等格式放在不同網址,可以回傳 rel="canonical" 的 HTTP 標頭,告訴 Googlebot 這些非 HTML 檔案的標準網址是哪一個。

這件事的商業意義,在舞台燈光貿易商 G 的案例裡看得最清楚。客戶手上有一份七十幾頁的 PDF 型錄,裡面不少品項從來沒有上架過——型錄是給展會和老客戶看的,沒有人想過那同時也是一批可以被搜尋到的商品。我們把型錄整理成商品草稿、圖片透過 API 批次上傳,店鋪的上架數量從三百多增加到五百出頭。那個案例發生在阿里巴巴國際站而不是官網,但道理相同:只躺在 PDF 裡的產品,在搜尋上幾乎等於不存在。

五、篩選器與網址參數:faceted navigation 的陷阱

直接回答:篩選器讓買家依材質、尺寸、認證縮小範圍,但每一種篩選組合都可能產生一個新網址。不需要被搜尋到的篩選網址,Google 建議用 robots.txt 禁止爬行,或改用網址片段(#);真的有人會搜的組合,就做成有內容的正式分類頁。

這是型錄網站最常見、也最隱形的技術債。Google 為此寫了一份專門處理 faceted navigation 的官方文件(最近一次更新為 2025 年 12 月),開頭就指出:以網址參數實作的篩選器最常見,但它可能產生無限的網址空間,並造成兩種傷害:

• 過度爬行:因為篩選網址看起來都是新的,爬蟲在確定這些網址沒有用之前,通常會先爬過非常大量的篩選網址。
• 新內容被發現得更慢:爬行時間花在沒用的網址上,爬蟲花在新的、有用網址上的時間就變少了。

算一下就知道規模。假設一個分類有 5 種材質、12 種尺寸、4 種表面處理、3 種認證,每一類篩選只能選一項或不選,組合數就是 6×13×5×4,共 1,560 種;這還沒乘上排序方式、每頁筆數、複選與語系。而這個分類裡真正在賣的產品,可能只有八十個。

篩選網址的五種處理方式

表格裡每一列都有官方依據。Google 的文件建議,如果不需要篩選網址被收錄,就用 robots.txt 禁止爬行篩選網址,或改用網址片段來指定篩選條件,並說明很多時候沒有好理由讓爬蟲爬篩選後的結果,只要開放個別產品頁,加上一個不套任何篩選、列出全部產品的列表頁即可。至於 rel="canonical" 與 rel="nofollow",文件直接說它們長期而言通常不如前述方法有效。

noindex 的限制來自另一份文件。Google 的爬行預算指南寫道:不要用 noindex 管理爬行,因為 Google 仍然會請求該頁,看到 noindex 之後才丟棄,等於浪費爬行時間。而在標準網址的文件裡,Google 也不建議在同一個網站內用 noindex 來選定標準網頁,因為那會讓該頁完全無法出現在搜尋結果,而且不要用 robots.txt 來處理標準化。這幾句話合起來的意思是:「擋爬行」「不收錄」「選正本」是三件不同的事,要用對工具。

下面是一個 robots.txt 的寫法示意。參數名稱請換成你網站實際使用的,而且前提是產品頁本身與未篩選的列表頁都能被正常爬到:

User-agent: *
Disallow: /*?*material=
Disallow: /*?*finish=
Disallow: /*?*sort=

如果某些篩選組合真的需要被搜到

有些組合確實有搜尋需求,例如「食品級不鏽鋼球閥」。這時不要讓參數網址去排名,而是做一個正式的分類頁或應用頁,給它固定網址、自己的標題,以及一兩段說明文字。如果你堅持要讓篩選網址被收錄,Google 列了幾條最佳做法:使用業界標準的「&」作為參數分隔符號;如果篩選條件寫在網址路徑裡,篩選的邏輯順序要固定,而且不能出現重複的篩選條件;以及篩選組合沒有結果時回傳 404 狀態碼,而不是轉到一個共用的錯誤頁。

分頁是同一類問題。產品列表超過一頁時,Google 建議每一頁都有獨立的網址,不要把分頁序列的第一頁設為標準網頁,而是讓每一頁有自己的標準網址。不少套版網站把第二頁、第三頁全部指回第一頁,結果排在後面的產品反而更難被找到。

說實話:三百個型號的網站,爬行預算不是主要問題

這裡要替讀者踩一下煞車。Google 的爬行預算指南一開頭就說,如果你的網站沒有大量快速變動的頁面,或頁面通常在發布當天就會被爬到,就不需要讀這份指南;保持 sitemap 更新、定期查看索引報告就足夠了。這份指南主要針對擁有 100 萬個以上不重複頁面、或 1 萬頁以上且內容每天變動的網站。

一家有三百個型號的台灣製造商,離這個量級很遠。那為什麼還要管篩選網址?因為對中小網站來說,真正的代價不是「爬不完」,而是三個比較實際的問題:Search Console 裡出現一大堆重複或未收錄的網址,讓你看不出真正的問題在哪裡;分析報表裡同一個分類被拆成幾百個網址,數據被切得零碎;以及篩選頁偶爾被選為代表頁,搜尋結果裡出現一個「查無結果」的頁面。對小網站而言,管好篩選網址是整潔與可觀測性的問題,而不是生死問題。

平台選擇也會影響你能管到什麼程度。W3Techs 2026 年 9 月的調查顯示,WordPress 佔全部網站的 40.7%,不少 WordPress 型錄網站的篩選功能來自外掛,網址格式由外掛決定;各家託管型建站平台能調整的範圍也不一樣。發包前請把「篩選網址格式、robots.txt 與標準網址能不能自訂」列進評估項目,平台之間的差異可以參考WordPress 與 SaaS 建站平台比較。

六、Product 結構化資料:欄位重點,以及沒有公開價格怎麼辦

直接回答:製造商的產品頁可以加 Product 結構化資料,但要先知道:Google 的產品摘要要求除了名稱之外,還要有評論、評分或 offers 三者之一,而 offers 必須有價格。B2B 不公開價格、又沒有真實評論時,就不符合產品複合式結果的資格;這時該做的是誠實標註名稱、品牌、料號與規格,絕不捏造價格或評論。

先釐清 Google 的分類。Google 把產品結構化資料分成兩類:產品摘要用於「使用者無法直接購買產品」的產品頁,商家資訊則用於「顧客可以向你購買產品」的頁面。多數製造商官網採詢價制,屬於前者。

產品摘要的必要欄位很少,但很明確。根據 Google 的產品摘要文件(2026 年 9 月更新),Product 必須有 name,並且必須包含 review、aggregateRating、offers 三者之一;若使用 offers,Offer 的必要欄位是 price 或 priceSpecification.price。

這就是 B2B 的尷尬之處:價格要看數量、材質與交期,本來就不公開;工業品也很少有公開的產品評論。那能不能填一個 0 元,或放幾則「客戶好評」當評論?不行。 Google 的結構化資料政策要求結構化資料必須真實反映頁面內容,而且不要標註讀者在頁面上看不到的內容,也不要標註假評論這類誤導性內容。一個需要詢價的產品標成 0 元,等於把錯誤資訊餵給搜尋引擎。

H 製造商的舊站就是反面教材:稽核時發現,產品頁的結構化資料只做了大約四分之一,圖片網址指向一個早就失效的測試網域,還留著幾則空的假評論。這種標記不只拿不到任何好處,一旦被搜尋引擎讀到,傷害的是整個網站的可信度。

沒有複合式結果,Product 標記還值得做嗎?

值得,但要調整期待。不符合產品摘要資格,不代表標記沒有用。schema.org 的 Product 類型本來就有很多適合工業品的欄位,能為搜尋引擎與其他系統提供明確、機器可讀的描述:這一頁是一個產品、誰製造的、料號是什麼、規格有哪些。最重要的一條規則是:標記裡的每一個值,都必須在頁面上看得到。

欄位定義可以直接查 schema.org 的 Product 頁面,例如 mpn 的定義是「製造商料號」,sku 是「商家專屬的庫存識別碼」,additionalProperty 則用來表示產品特性的屬性與數值。系列頁可以用前面提到的 ProductGroup 與 hasVariant 串起各型號;分類頁適合搭配麵包屑與 ItemList。技術實作的細節——JSON-LD 放在哪裡、如何驗證——可以參考 AEO 技術實作指南。

還有一個架構層面的建議:結構化資料要從產品資料庫自動產生,不要每一頁手寫。幾百個型號乘上幾個語系,手寫的標記一定會和頁面內容慢慢脫節——頁面改了規格,JSON-LD 還停在舊版。這也是為什麼第四節要求規格必須是資料庫欄位:同一筆資料同時產生規格表、篩選器與結構化資料,三者就永遠一致。

七、案例:兩種型錄搬家,兩個教訓

直接回答:H 製造商的教訓是「搬家之前先完整盤點,搬家過程逐筆驗證」;G 貿易商的教訓是「PDF 型錄裡的產品,不做成可搜尋的頁面,就幾乎等於不存在」。 兩個案例一個在自有官網、一個在 B2B 平台,處理的卻是同一件事:把工廠手上的產品資料,變成買家找得到的結構。

案例 H:四語系、472 個產品頁的型錄重建

H 製造商是汽車美容化學品製造商,同時經營自有品牌與 OEM/ODM。舊站的問題很典型:沒有 canonical、沒有 Open Graph,英文版 sitemap 直接回 404,還有十幾個中文頁面根本沒有對應的英文版。我們的做法依序是:

1. 先把舊站完整搬下來:抓了 360 個網址、成功率 100%,產品頁重新抓一輪補齊規格,內容頁轉成結構化文件,PDF、影片嵌入與表單規格全部保存。
2. 四語系重建:118 個產品乘上英文、繁體中文、西班牙文與阿拉伯文,共 472 個產品頁,加上分類頁後全站約 660 頁;阿拉伯文需要完整的右至左版面。
3. 逐筆驗證轉址:約三百筆轉址逐一確認落點是正常頁面,不是 404,也不是繞了好幾層的轉址鏈。
4. 交給客戶自己維護:接上 CMS 之後,客戶在後台按下發佈,網站兩到三分鐘內自動重建上線;下架幾個型號,sitemap 也會跟著同步。

對型錄架構而言,第 4 點最常被低估。型號會停產、也會新增,架構規劃必須包含「下架一個型號時,網站會發生什麼事」:產品頁要轉到哪裡、分類頁的數量會不會變、sitemap 會不會留下死連結。Google 的電商網址文件也建議,分類裡沒有任何產品時使用 noindex,若系統會自動移除空分類,可以考慮回傳 404。

另一個細節和效能有關:H 製造商的產品圖經過批次去白邊與正方化,圖檔總量從 58.10MB 降到 15.98MB。型錄網站的列表頁一次要載入幾十張產品圖,圖片重量會直接影響使用體驗;Google 的 Core Web Vitals 以 LCP 在 2.5 秒以內為良好,並以第 75 百分位評估。

案例 G:七十幾頁 PDF 型錄裡從未上架的品項

G 貿易商經營舞台燈光與特效設備,在阿里巴巴國際站上有曝光、卻長期零詢盤。除了關鍵字與詳情頁的重建,其中一項工作就是處理那份七十幾頁的 PDF 型錄:裡面不少品項從來沒有上架過,我們整理成商品草稿、圖片透過 API 批次上傳,上架數量從三百多增加到五百出頭。我們也重寫了一批詳情頁,把規格、材質、適用場景、認證與交期逐項寫清楚,並清掉屬性欄位裡的髒資料、補建缺漏的規格。

整個專案期間店鋪沒有投放任何廣告,自然曝光從每天 690 次增加到 752 次,點擊率從 1.67% 提升到 2.21%。這是所有改動合計的結果,不能單獨歸功於型錄上架;但它說明了一件事——把產品資訊整理成結構化、可搜尋的形式,是一項可以被量測的工作。平台店鋪與自有官網該怎麼分工,可以參考有阿里巴巴了還需要官網嗎。

八、什麼情況不需要大改架構

直接回答:產品少於二、三十個,現有網站的產品頁已經正常被收錄,買家也找得到東西時,不需要為了「架構完美」而重做網站。 架構調整本身有成本與風險,尤其是更動網址。

誠實列出幾種不必大動的情況:

• 型號很少:二、三十個產品、兩三個分類,一個產品列表頁加上產品頁就夠了,不需要篩選器,也不需要應用專題頁。硬做篩選只會產生沒有人用的網址。
• 現有結構運作正常:如果 Search Console 顯示產品頁大多已被收錄、搜尋流量穩定,分類名稱稍微不理想不是改版的理由。先補內容——規格文字、應用說明——不要動網址。
• 網站的主要任務不是被搜尋到:如果你的客戶全部來自少數長期合作的代理商,官網只是讓對方確認你確實存在,架構投資的優先順序可以往後放。
• 沒有人能維護:規劃了六種語系、五百個型號頁,但公司裡沒有人負責更新,上線一年後網站就會充滿過期規格。架構規模要配合維護能力。

如果真的要改分類或網址,改版還是重做的決策框架可以幫你界定範圍。Google 的標準網址文件把轉址列為讓目標網址成為標準網頁的強烈訊號,rel="canonical" 同樣是強烈訊號,sitemap 則是較弱的訊號。搬家時,舊網址一對一轉到最接近的新頁面,並且逐筆驗證,是最可靠的做法。

九、上線後怎麼檢查架構有沒有做對

直接回答:上線後用 Google Search Console 的「網頁索引」報告看三類狀態——重複網頁的標準網址問題、已找到但尚未建立索引、已檢索但尚未建立索引。 這些狀態集中出現在哪一類網址,就代表哪一層架構需要調整。

Google 的說明文件對這幾種狀態有明確定義。「這是重複網頁;使用者未選取標準網頁」代表這一頁與另一頁重複,而且沒有指定偏好的標準網頁;「這是重複網頁;Google 選擇的標準網頁和使用者的選擇不同」代表你指定了標準網頁,但 Google 認為另一個網址更適合。如果這類狀態集中在同一系列的型號頁,通常代表型號頁拆得太細;如果集中在篩選網址,代表篩選網址沒有被管住。「已找到,目前尚未建立索引」代表 Google 已找到網頁,但尚未進行檢索;如果新上線的產品頁大量停在這個狀態,先確認分類頁有沒有直接連到每一個產品。

上線當週可以做的快速檢查:

• 在三個產品頁「檢視網頁原始碼」,確認規格數字出現在 HTML 裡。
• 用 Google 的複合式搜尋結果測試驗證 Product 標記沒有錯誤;沒有 offers 或評論時不符合產品摘要資格,這是預期中的結果。
• 抽查三個篩選網址,確認 robots.txt 規則有生效。
• 抽查三個舊網址,確認都轉到正確的新頁面。

上線後前三個月該追哪些數字,外銷網站上線後的前 90 天有完整的檢查節奏;產品頁上的詢價按鈕與表單怎麼設計,可以看 B2B 詢價表單設計;其他常見的技術問題,則整理在中小企業網站常見技術問題自我檢查。

結語:型錄網站首先是一個資料專案

型錄網站做得好不好,大部分在設計稿出來之前就決定了:盤點有沒有做、分類是不是照買家的找法切、規格是不是資料庫欄位、篩選網址有沒有管住、結構化資料是不是和頁面一致。這些都不是版型問題,而是資料問題。

如果你正準備做或重做官網,手上有幾十到幾百個型號,不確定該從哪裡開始,HappyCXO Studio 的網站架設服務會從產品盤點與架構規劃做起,而不是從挑版型開始。無論最後找誰做,都建議先把第一節那張盤點表填完——它會讓之後每一次討論都更具體。