官網與小程式一體化怎麼選：四個判斷點，一個不小的代價
把官網和小程式拆給兩家做，多花的錢不是兩份報價的差，是兩套內容口徑以後每次改價都要人工對一遍。
一體化這三個字在報價單上很曖昧。同一個詞，可能是視覺統一，也可能是真的內容同源，價格差出兩三倍。先把它拆成三檔再談錢。2026 年 10 月新浪新聞一篇服務商盤點稿裡，「官網與小程式內容打通」「一處後台兩端同步」「原始碼可選」已經是標準賣點（2026-10-26）——賣點都齊了，差別只在於做到哪一檔。
一、「一體化」有三檔，價格差在哪
視覺統一：同一套 logo、配色、字體規範，官網和小程式各做各的，後台不通。最便宜。代價是營運每次發新品要發兩遍，兩邊的參數、活動時間、聯絡方式都有機會不一致。內容更新頻率低於每月一次的小團隊，這一檔夠用。
內容同源：一個後台存內容，官網透過伺服器端渲染取數輸出成 HTML，小程式透過 HTTPS 介面取同樣的資料。中小企業性價比最高的一檔，代價全在前置：內容模型要先設計好，欄位得同時餵飽兩端。具體的卡點有幾處——富文字編輯器產出的 HTML，小程式端沒有 DOM，只能用 rich-text 元件並受限於它支援的標籤；圖片要按端出多套尺寸，官網首屏上 AVIF 或 WebP，小程式有包體和頻寬限制；表格類內容在小程式裡基本得改成卡片式。內容模型定錯，後面每加一個欄位兩端都要改，這才是這一檔的真實成本。
程式碼同源：用 Taro、uni-app 這類框架一套程式碼編譯到小程式和 H5。省的是重複開發，邊界要清楚：跨端框架產出的網頁對 SEO 不友善，首屏常是用戶端渲染，爬蟲拉到的是空殼；即便補了預渲染，路由和 head 管理也比 Next.js 這類方案彆扭。通行做法是官網走 SSR 或靜態生成、小程式走原生或跨端，兩端共用內容介面，而不是硬把官網塞進跨端框架。
還有一層容易被忽略：後台的角色權限與發布流程。一體化之後一次誤改會影響兩個入口，營運、審核、管理員得分開，發布時間戳要統一，不然誰改了哪個端說不清。
判斷順序：內容更新頻率、有沒有多語言、小程式要不要承擔獲客。三個都低，第一檔；有一個高，進第二檔；只有官網和小程式頁面高度重合、且官網不指望搜尋流量時，第三檔才有意義。
補一句關於小程式的現實：小程式的頁面在通用搜尋裡基本不可見（微信內的搜尋是另一套邏輯），所以一體化專案裡，官網承擔全部可累積的搜尋資產。預算上把兩端當同等流量入口，通常要失衡。
二、SEO 能力在選型階段就能驗，三件事
供應商都會說「我們做 SEO」。選型階段不用看方案簡報，讓對方給你三個可驗證的東西。
首屏 HTML 裡有沒有正文。 要一個已上線的內頁網址，用 curl 拉下來數 HTML 裡的正文漢字，再和瀏覽器裡看到的比對。數得出來、內容一致，說明是伺服器端渲染或靜態生成；拉回來只有 <div id="root"></div> 加一堆 script，就是首屏靠 JS 拼出來的。後者不一定不能做 SEO，但要額外上預渲染，成本和風險都往上走。
URL 規則能不能自訂。 分歧點在詳情頁：語意化路徑 /products/xxx 和參數路徑 /product?id=123 對爬蟲、對分享、對統計是三件事。參數路徑常見問題是被統計工具切成一堆重複頁面、分享丟參數、canonical 收斂不了。順帶問結尾斜線和大小寫策略——上線後 /About 和 /about 同時回 200，就是兩份重複內容。
head 能不能逐頁設定。 title、description、canonical、hreflang、JSON-LD 要按頁面類型分別輸出，不是全站一個變數。這條最容易在驗收時翻車：模板寫死了，改一頁等於改程式碼，營運永遠追不上。
三件事都能當場示範。不能示範的，等於承諾。
三、多語言：子目錄優先，hreflang 三條硬要求
做外貿和出海，第一件事是定 URL 結構，不是翻譯。
| 方案 | 範例 | 代價 | 適合誰 |
|---|---|---|---|
| 子目錄 | example.com/en/ | 一套程式碼、一份憑證、一個統計帳號 | 多數 B2B 外貿站、品牌站 |
| 子網域 | en.example.com | 搜尋引擎基本當新站，權重繼承弱，維運多一套 | 各國團隊獨立營運 |
| 獨立網域 | example.de | 地區訊號強，成本與註冊主體要求高 | 當地有實體、長期深耕 |
| URL 參數 | example.com?lang=en | 統計被切碎、分享丟參數 | 不建議 |
中小團隊預設選子目錄，理由不是「大家都這麼做」，是維護面小。選子網域之前先問自己有沒有第二套維運人力。
hreflang 有三條最容易踩：href 必須是絕對網址，不能寫相對路徑；每個語言頁都要有指向自己的那一條，缺了自引用可能整組被忽略；x-default 要嘛每頁都寫，要嘛都別寫，半套設定等於沒設。
還有一條反著來的：別用 IP 或瀏覽器語言做自動跳轉。Googlebot 一般從美國發起抓取、不帶 Accept-Language 標頭，你用 JS 按語言跳一下，它可能永遠抓不到 /en/ 和 /de/。正確做法是給每個語言獨立 URL，在頁首頁尾放切換連結。這條的代價很實在——預設語言的首页會出現在不合適的市場，所以首頁預設語言要按主要市場定，別按公司註冊地定。
四、GEO 不是獨立專案
GEO（生成式引擎最佳化）現在被包裝成一種獨立服務。剝開看，AI 檢索要的東西和傳統搜尋大量重疊：頁面能被抓取、正文是語意化 HTML、關鍵事實以完整句子寫出來、結構化資料與頁面可見內容一致。
真正的差異有兩處。一是抓取策略：主流 AI 爬蟲各有 UA（GPTBot、ClaudeBot、PerplexityBot 等），CDN 和 WAF 的預設機器人防護常把「非 Google/Bing」的 UA 一併攔掉，網站在 AI 側就完全不可見。上線前要專門查 robots.txt 和 WAF 規則。二是內容形態：抽取式回答偏好「一個問題一段完整回答」，帶明確口徑和出處的數字比模糊表述更容易被引用。
【待核實：llms.txt 目前是否被主流 AI 爬蟲實際讀取，還是停留在社群倡議；這決定交付清單裡要不要加這一項。】
所以 GEO 的開法應該是追加進技術 SEO 清單，別單獨買「AI 最佳化包」。單獨買的結果，通常是幾篇廣編稿加一批目錄提交。
五、原始碼與帳號：比功能清單更影響退出成本
不交付原始碼有幾種常見包裝：只給編譯產物；給「授權原始碼」但核心模組加密或編譯成二進位檔；以雲端代管名義不給建置腳本和部署文件。三種情況在正常營運期間都看不出問題，要換供應商或做二次開發時才知道代價——等於重建。
該拿到手的是：程式碼儲存庫權限和提交歷史、建置與部署腳本、環境變數清單，以及第三方帳號的所有權（網域、SSL、物件儲存、簡訊、支付、小程式的主體與開發者權限）。驗收時按清單逐項登入核對，不接受「我們幫你管著」這種說法。
清單核對時最容易漏的是小程式開發者權限和主體管理員。主體資訊如果在乙方名下，移轉相當於重新註冊，歷史使用者和評價都帶不走。
萬楓科技在這一塊是把原始碼全部交付、帳號一併移交寫在驗收節點上的，此後 3 個月免費維護；這套安排本身不複雜，難的是寫進合約而不是留在口頭。
六、報價和排期怎麼核
一體化專案的報價單容易糊成一整塊。讓對方拆成：資訊架構與 URL 規劃、內容模型與介面契約、官網頁面、小程式頁面、SEO 與 GEO 技術項、測試上線、上線後 90 天監控。拆不開的報價單，後面一定靠變更單找回來。
排期同理。內容模型設計如果只給了兩天，基本可以判斷沒打算認真做兩端共用，而這是整條鏈路裡最容易返工的一段。
一條最低成本的驗法：選型階段讓對方 curl 一個內頁給你看 HTML。這一條驗不了，後面所有 SEO 承諾都是待定。