網站上線後要做什麼?前 90 天檢查表

網站上線那天,通常是整個專案最熱鬧的一天。廠商傳來正式網址,老闆轉發到公司群組,業務把新網址換進 email 簽名檔,大家鬆了一口氣。然後,網站就被放著了。

三個月後,常見的對話是這樣:「我們的新網站怎麼在 Google 上搜不到?」「詢價表單這三個月收到幾封?」「那個 Search Console 是誰在看?」答案往往是:搜得到公司名字,搜不到產品;表單收了幾封沒人知道;Search Console 的帳號在廠商工程師的私人 Gmail 裡。

這不是誰偷懶,而是多數人對網站的想像是「蓋房子」:交屋就結束。但網站比較像開一家店——開幕那天只是營業的第一天。搜尋引擎需要時間發現你、判斷你、把你放進索引;數據需要時間累積;內容需要有人持續補。上線後的前 90 天,是一個網站從「存在」變成「被找到」的關鍵期,也是最容易被忽略的一段。

先講這篇的定位。上線「當下」該驗收什麼——網域在誰名下、表單收不收得到信、sitemap 有沒有提交——我們在網站發包需求規格書與驗收清單已經列了二十八項,這裡不重複。這篇接著講驗收之後:第 1 週、第 2 到 4 週、第 2 到 3 個月,各該做什麼、用什麼工具看、做到什麼程度算完成。所有工具設定與時程說法,都以 Google、Bing 等官方文件為準;凡是官方沒有承諾的事,我們也不會替它承諾。

如果你的網站還在規劃階段,建議先看外銷網站從零到上線的完整架構指南;如果你還在猶豫已經有阿里巴巴國際站,是否還需要自己的官網,可以先看國際站與自有官網要不要兩個都做。

一、上線後 90 天總覽:三個階段,順序不能顛倒

直接回答:新網站上線後的前 90 天分成三個階段——第 1 週讓搜尋引擎找得到你、數據開始收集,第 2 到 4 週看報告修問題,第 2 到 3 個月才開始經營內容。 順序不能顛倒,因為每一個階段都依賴前一階段累積的資料。

為什麼一定要照這個順序?因為大部分報告都有「時間差」。Google 官方說明,新的網頁或網站可能需要一週左右,Google 才會開始檢索並建立索引;Search Console 的資料則是在收集後約 48 小時才會出現在 Search Console 與 Analytics 裡。換句話說,第 1 週你能做的只有「把管道接好」,第 2 週以後才有東西可以看,而內容策略要等你看得到「別人用什麼字找到你」之後才有依據。

90 天三階段總覽表

這張表有一個隱含的前提:網站已經通過上線驗收。 如果你的網域不在公司名下、GA4 管理員是廠商、robots.txt 還留著開發期的封鎖,那麼這 90 天的工作都會建立在沙地上。請先回頭把驗收清單跑完,再開始這份計畫。

什麼情況下不需要做完整的 90 天計畫

持平地說,不是每個網站都需要把三個階段做滿。如果你的網站只是給既有客戶查聯絡方式的電子名片,業務完全靠展會與老客戶轉介,你也沒有打算從搜尋引擎接新客戶,那麼第 1 週的設定仍然要做(那是在保護你的所有權與「看得見」的能力),但第 2 到 3 個月的內容經營可以不做,把預算留給真正帶來訂單的管道。這份計畫是給「希望網站替你開發新客戶」的公司用的。 如果這不是你的目標,先把目標想清楚,比照表操課重要。

另一種情況是網站其實還沒準備好:產品頁只有照片沒有規格、英文版只翻了首頁。這時候與其照著九十天計畫看報告,不如先把內容補到「值得被找到」的程度,因為報告只會忠實地告訴你:沒有人在找一個沒有內容的網站。

二、第 1 週:讓搜尋引擎找得到你

直接回答:第 1 週要完成五件事——在 Google Search Console 驗證網域資源並提交 sitemap、在 Bing Webmaster Tools 從 Search Console 匯入網站、設定 IndexNow、在 GA4 把詢價設成關鍵事件、把 GA4 與 Search Console 連結起來。 這五件事大多不需要寫程式,但決定了你之後九十天看不看得見東西。

Google Search Console:選「網域資源」,確認公司是擁有者

Search Console 有兩種資源類型。網域資源(例如 example.com)會涵蓋所有子網域,以及 http、https 等所有通訊協定,但必須透過 DNS 記錄驗證;網址前置字元資源則只包含特定前綴底下的網址。對大部分中小企業來說,建議直接建網域資源:www 與非 www、http 與 https、甚至之後加開的子網域,資料都會收在同一個地方,不會因為網址寫法不同而漏看。依 Google 的驗證說明,網域名稱供應商(DNS 記錄)是驗證網域資源的唯一方式,所以這一步需要能登入網域註冊商後台的人——這也是為什麼網域帳號一定要在公司手上。

接著確認權限。Search Console 的擁有者分為「已驗證擁有者」與「委派擁有者」兩種,而且每個資源至少要有一位已驗證擁有者,否則沒有人能存取這個資源。實務上最常見的問題是:當初驗證的人是廠商工程師,用的是他自己的 Gmail。某一天工程師離職、或你換了廠商,你就失去了看見自己網站數據的能力。建議做法是用公司的共用帳號當已驗證擁有者,廠商與行銷同事用「完整使用者」權限加入,之後需要時再調整。

提交 sitemap:它是一份清單,不是開關

在 Search Console 的 Sitemap 頁面提交你的 sitemap 網址。這件事很多人以為是「按下去 Google 就會收錄」,其實不是。Google 的新手指南寫得很明白:提交 sitemap 不是必要的,更重要的是先讓人知道你的網站存在;Google 主要還是透過其他頁面的連結來發現新網頁。sitemap 的價值在於它是一份「我有哪些網頁」的完整清單,特別適合頁數多、內部連結還不完整的新網站。

sitemap 裡有兩個欄位常被誤用。Google 的官方文件說明,Google 會忽略 priority 與 changefreq 這兩個值,而 lastmod 只有在「一致且可驗證地準確」時才會被採用,而且應該反映主要內容、結構化資料或連結的重大更新——更新頁尾的版權年份不算。所以如果你的網站每天把所有頁面的 lastmod 都改成今天,效果正好相反:Google 會學到你的 lastmod 不可信。另外要知道,舊式的 sitemap「ping」網址,Google 已在 2023 年宣布停止支援;如果你的外掛還在呼叫它,不會出錯,但也不會有任何作用。

網址檢查工具:只對最重要的幾頁要求索引

上線當週,用 Search Console 的網址檢查工具,對首頁、主要產品分類頁、聯絡頁這幾頁按「要求建立索引」。但請調整期望:Google 官方說明檢索可能需要幾天到幾週,同一個網址重複要求並不會比較快,而且要求檢索不保證一定會被收錄;這個功能也有配額限制。大量網址請交給 sitemap,這個工具留給真正重要、或剛修正過問題的頁面。

Bing Webmaster Tools:從 Search Console 匯入,按幾個按鈕就完成

很多台灣企業完全跳過 Bing,理由是「大家都用 Google」。如果你的客戶在台灣,這句話大致成立;但外銷網站的讀者在海外。依 StatCounter 的統計,2026 年 8 月美國整體搜尋市占中 Bing 約佔 9%,在桌上型電腦上約為 12.8%——而北美的採購人員,很多是在上班時間用公司電腦查供應商。同一個月台灣的數字則是 Google 78.5%、Yahoo 12%、Bing 8.5%,可以看出兩個市場的結構並不一樣,不能用台灣的經驗推論海外買家。

設定 Bing 幾乎沒有成本。Bing Webmaster Tools 支援直接從 Google Search Console 匯入網站,匯入的網站會自動完成驗證,一次最多可匯入 100 個網站,之後 Bing 會定期與你的 Search Console 同步確認所有權。也就是說,只要第一步的 Search Console 做對了,Bing 只是多按幾個按鈕,連 sitemap 都會一起帶過去。

還有一個 2026 年的新理由。Bing 在 2026 年 2 月推出 AI Performance 公開預覽版,可以看到你的內容在 Microsoft Copilot 與 Bing 的 AI 摘要中被引用的次數、被引用的網址,以及 AI 擷取內容時使用的關鍵片語。這是目前少數由搜尋引擎官方提供的「AI 引用」數據來源,光是為了它,Bing 就值得設定。

IndexNow:通知 Bing 等引擎,但 Google 不在名單上

IndexNow 是一個開放協定:網站在新增、更新或刪除網頁時,主動通知搜尋引擎,而不是被動等它來爬。依 IndexNow 官方的常見問題,目前參與的搜尋引擎包括 Amazon、Bing、Naver、Seznam.cz、Yandex 與 Yep;送到其中一個端點的通知,會分享給所有參與的引擎,每次最多可送出 10,000 個網址。

Google 不在這份名單上。 2021 年 Google 曾對外表示會測試 IndexNow,但到今天,官方參與名單裡仍然沒有 Google。對 Google 來說,管道仍然是 sitemap(搭配準確的 lastmod)與網址檢查工具。也請不要被「用 Google Indexing API 快速收錄」的說法誤導:Google 的文件明確寫著,Indexing API 只能用於含有 JobPosting(徵才)或直播 BroadcastEvent 結構化資料的網頁,一般的產品頁與文章並不適用。

設定方式依 Bing 的 IndexNow 入門說明是四步:產生一組金鑰、把金鑰檔放在網站上、送出網址、到 Bing Webmaster Tools 確認收到。它也提醒兩件事:只送出「有變動」的網址,不要把整站舊網址反覆送;而且使用 IndexNow 並不保證網頁一定會被檢索或收錄。很多建站平台或外掛已經內建這個功能,問你的廠商有沒有開、是在什麼時機送出——這個「時機」很重要,第六節會講我們自己踩過的坑。

GA4:把「詢價」設成關鍵事件,並連結 Search Console

GA4 在第 1 週要做的不是看報表,而是先告訴它「什麼算成功」。Google 已經把 GA4 裡原本叫「轉換」的東西改了名:對業務重要的事件現在稱為「關鍵事件」(key events),「轉換」則保留給廣告成效衡量使用。對外銷網站來說,最重要的關鍵事件幾乎一定是「送出詢價」。

設定上有兩條路。GA4 的加強型評估可以自動記錄 form_start 與 form_submit 兩個表單事件,但 form_submit 只代表訪客按下了送出,不代表信件真的寄達;比較可靠的做法是讓表單送出成功後導到一個感謝頁,再依 Google 的說明以感謝頁的瀏覽建立新事件,並標記為關鍵事件。Google 的建議事件清單裡,也有專為名單開發設計的 generate_lead 事件可以使用。表單本身該怎麼設計才會有人願意填,是另一個題目,可以參考B2B 詢價表單設計那一篇。

另外兩個設定順手做掉。第一是資料保留期間:標準版 GA4 的使用者層級資料與關鍵事件資料,保留期間可以設成 2 個月或 14 個月。這個設定影響的是探索報表與漏斗報表,不影響標準彙總報表;但如果你之後想做「過去一年哪些訪客最後送出詢價」這類分析,就要一開始設成 14 個月,因為已經被刪除的資料,事後改設定也補不回來。第二是連結 Search Console:連結後可以在 GA4 裡看到自然搜尋的查詢字詞與到達網頁;要注意 Search Console 只保留最近 16 個月的資料,而且這組報表在 GA4 裡預設是未發布的,要自己到「媒體庫」把它發布出來。

如果你的舊網站還停在 Universal Analytics,請知道它已經在 2023 年 7 月 1 日停止收資料、2024 年 7 月 1 日刪除歷史資料。這也是我們在網站健檢的九個常見問題裡排在第一個的項目。新網站上線,正好是把追蹤一次做對的時機。

三、第 2–4 週:看數據、修問題

直接回答:第 2 到 4 週的工作是「讀報告、修會擋住收錄的問題」——先看網頁索引報告確認重要頁面都被收錄,再處理自己連出去卻 404 的網址,接著量測網站速度與手機體驗。 這個階段不要急著看排名,排名要等收錄與數據都穩定了才有意義。

網頁索引報告:不是每一頁都該被索引

打開 Search Console 的「網頁」索引報告,你會看到兩個數字:已建立索引、未建立索引。第一次看的人通常會被後者嚇到。Google 官方的說法是:大多數網站都會有一些未建立索引的網頁,但所有重要的網頁都應該被索引;重複的網址本來就不該被索引,被標為「重複」通常是好事,代表 Google 找到了正式版本並收錄了它。

所以讀這份報告的正確方式,是逐一看「未建立索引」的原因,判斷它是「應該的」還是「有問題的」。下面這張表整理最常見的幾種原因:

修完問題後可以按「驗證修正」,Google 會重新檢查。官方說明這個流程可能需要數天甚至更久,過程中會用 email 通知進度。驗證期間不要反覆改同一批頁面,不然你分不清是哪一次修改生效。

404:先分清楚「該修的」和「正常的」

404 是新網站前幾週最常讓人緊張的報告,尤其是改版網站——一堆舊網址會出現在這裡。先講結論:404 本身不是懲罰。 Google 在官方部落格說得很直接:404 是網路上完全正常的一部分,而且當你刪掉一個網頁時,他們反而希望你回傳正確的 404 或 410,而不是用軟性 404 敷衍。Google 的狀態碼文件也說明,回傳 4xx 的網址不會被索引,原本已索引的會逐漸被移除。

那哪些要修?Google 在索引報告的說明裡給了很實用的原則:一般來說,只需要修正你自己有連結、或列在 sitemap 裡的 404;如果網頁搬家了,應該回傳 3xx 轉址到新網頁。換成操作語言就是三條:

1. 你的網站內部有連到它 → 修連結或補回頁面。
2. 你的 sitemap 裡有它 → sitemap 的產生邏輯有問題,修 sitemap。
3. 它是改版前的舊網址,而且有新網頁可以對應 → 補一條 301 轉址。

第三條是改版網站上線後第一個月最重要的工作。我們在 H 製造商的四語系官網重建裡,事先把舊站 360 個網址完整盤點,約三百筆 301 轉址逐筆驗證落點——確認每一筆的落點是正常頁面,不是 404,也不是繞好幾層的轉址鏈。即使上線前做到這個程度,上線後的前幾週仍然值得每週看一次 404 清單,因為其他網站的連結、舊的 email 簽名、展會文宣上印的網址,往往是盤點時沒想到的來源。改版與轉址的取捨,在網站改版還是重做的判斷框架有更完整的說明。

多語系網站要多看一件事:每一種語言的 sitemap 都要能正常開啟。H 製造商的舊站就是一個反例——英文 sitemap 直接回 404,而且 sitemap 列出的網址裡沒有任何一筆英文頁面,對一家主力外銷的公司來說,等於在買家使用的語言裡查不到。多語系的網址結構與 hreflang 該怎麼規劃,請看多語系外銷網站架構與 hreflang。

Core Web Vitals 報告:新網站常常「沒有資料」

Core Web Vitals 是 Google 用來衡量使用者體驗的三項指標,良好門檻是 LCP 在 2.5 秒以內、INP 在 200 毫秒以內、CLS 在 0.1 以下,並以第 75 百分位的造訪來判斷。

新網站最常遇到的狀況是:Search Console 的 Core Web Vitals 報告一片空白。這不是壞掉。這份報告的資料來自 Chrome 使用者體驗報告(CrUX),也就是真實使用者的實地資料;Google 的說明指出,如果資源是新建立的,或 CrUX 裡沒有足夠資料,就會顯示「沒有可用的資料」。資料不足的網址群組會被併到整個來源層級一起看,連來源層級都不夠時,就不會出現在報告裡。對流量還小的外銷網站來說,前幾個月看不到資料是很常見的。

資料出來之前,用 PageSpeed Insights 量首頁、主要分類頁與幾個代表性產品頁的行動版,把結果截圖存檔,當作基準值。等實地資料出現後,再用 Search Console 的報告看整體。如果修好了某個問題,按下「開始追蹤」後,Search Console 會進行為期 28 天的監測,這段期間都沒有再出現才算修好——所以速度問題的驗證是以「月」為單位的,這也是它必須在前 4 週就開始的原因。

行動裝置問題:Search Console 的「行動裝置可用性」報告已經下架

很多網路教學還會叫你去看 Search Console 的「行動裝置可用性」報告,但它已經不存在了。Google 在官方部落格註明,行動裝置相容性測試與行動裝置可用性報告已於 2023 年 12 月 1 日停用。停用不代表手機版不重要,正好相反:Google 在 2023 年 10 月宣布行動版優先索引已全面完成,現在所有能在手機上正常運作的網站,主要都是用行動版爬蟲來檢索。

所以第 2 到 4 週的手機檢查,改用兩種方式:一是用 Chrome 內建的 Lighthouse 對主要頁面跑行動版檢測;二是拿真的手機,模擬買家的真實情境——例如在展會現場掃 QR code 進產品頁、用手機填一次詢價表單。工具會告訴你字太小、按鈕太近;真人測試才會告訴你「規格表在手機上根本看不完」。

成效報告:前幾週先看曝光,不要急著看點擊

最後才是成效報告。Search Console 的成效報告預設顯示最近三個月,而最新的資料是初步數據,幾個小時內可能還會變動。新網站的前幾週,點擊通常很少,這時候該看的是「曝光」:Google 開始把你的哪些頁面、在哪些查詢字詞下展示給人看。

B2B 網站還有一個特別要知道的限制:匿名查詢。Google 說明,在兩到三個月內沒有被超過幾十位使用者搜尋過的查詢字詞,為了保護隱私不會出現在表格裡,但會計入圖表的總數。外銷製造業的關鍵字常常非常長尾——一個特定規格的零件型號,可能一整季只有少數人搜尋——所以你會看到「圖表上有曝光,表格裡卻沒幾個字詞」。這是正常的,不是報告壞掉,也不代表沒有人在找你。

四、第 2–3 個月:從「被找到」到「被選擇」

直接回答:第 2 到 3 個月的重點是建立一個能維持一年的內容更新節奏、把內部連結補齊、把買家真正會問的問題整理成常見問答,並做好 AEO 基礎。 從這個階段開始,網站之間的差距不再是技術設定,而是內容與經營。

內容更新節奏:穩定比衝量重要

上線後第二個月,很多公司會有一股衝動:一口氣上架幾十篇文章,或把所有頁面的日期改成最新,好讓網站「看起來很新」。Google 的官方文件把這兩件事都列為負面的自我檢查題:你是否為了讓頁面看起來新,在內容沒有實質變動時修改日期?你是否為了讓網站顯得新鮮而大量新增或刪除內容?答案是:不會有幫助。

比較實際的做法,是挑一個你能維持十二個月的節奏。對大部分中小製造商來說,每個月固定產出少量但有實質內容的文章或應用案例,就已經是需要認真排程的工作量。內容來源不用外求:業務每週回覆的詢價問題、工程師解釋給客戶聽的材料差異、品管遇到的客訴原因,都是買家真的想知道、競爭對手又寫不出來的內容。

我們在 J 製造商的海外英文品牌站看到的軌跡很典型:首次交付 21 個頁面,第二階段才把內容擴充到 39 篇文章加 25 則結構化常見問題,並補上應用產業頁面、讓 sitemap 完整涵蓋。對一個剛成立的海外品牌來說,上線時的頁數只是起點,真正讓網站開始被找到的,是上線之後持續累積的內容。 產品與分類頁該怎麼規劃結構,才能讓內容越加越有秩序,可以參考製造商產品型錄網站的結構規劃。

還有一個組織上的現實要先講:內容節奏最常斷掉的原因不是沒題目,而是「沒有人被指定負責」。業務很忙、工程師不愛寫、老闆想到才催。所以與其定一個很有企圖心的篇數,不如先指定一位負責人、定一個固定的發布日,再決定每個月寫什麼。

內部連結:每一頁都要有人指向它

內部連結是新網站最便宜、也最常被忽略的工作。Google 的連結最佳做法寫得很清楚:每一個你在意的網頁,都應該至少有一個來自網站內其他網頁的連結;錨點文字要具描述性、簡潔,並與前後文和目標頁相關,避免「點這裡」這種寫法;而且連結要用標準的 a 標籤加上 href,用 JavaScript 點擊事件做出來的「按鈕式連結」不一定能被爬蟲辨識。

第 2 到 3 個月可以做一次簡單的盤點:把網頁索引報告中「已找到 - 目前未建立索引」的網址拉出來,逐一看有沒有其他頁面連到它。實務上,製造業網站最有效的內部連結結構,是把「應用、產品、規格、常見問題」互相串起來:應用案例頁連到用到的產品,產品頁連到相關應用與規格說明,每一篇新文章至少連到一個產品或分類頁。這樣做的好處是雙向的:爬蟲沿著連結找得到每一頁,買家也沿著連結從「我有什麼問題」走到「你有什麼產品」。

常見問答:寫給買家和 AI 看,不是為了 Google 版面

常見問答(FAQ)在過去幾年常被當成「多佔 Google 版面」的技巧,但這個理由已經不存在了:Google 已經在 2026 年 5 月 7 日完全停止顯示 FAQ 複合式搜尋結果。FAQPage 結構化標記現在的價值,是讓 AI 答案引擎與其他搜尋引擎更容易解析你的問答內容。

所以 FAQ 的寫法要回到本質:用買家真的會打的句子當問題,用兩到四句話給出完整答案。 問題從哪裡來?第 2 到 3 個月的成效報告會開始出現一些查詢字詞,其中以 how、what、can、difference 開頭的英文問句,就是現成的 FAQ 題目;業務信箱裡重複出現的問題,也是。產品頁的規格、材料與應用怎麼寫,才能被 AI 正確引用,產品頁 AEO 寫法那篇有逐欄的範例。

AEO 基礎:Google 說這仍然是 SEO

AEO(答案引擎優化)是這兩年最多人問的題目,也是最多誇大說法的地方。先看 Google 自己怎麼說。Google 在 2026 年 7 月更新的生成式 AI 搜尋優化指南寫得很直接:從 Google 搜尋的角度,為生成式 AI 搜尋做優化,就是為搜尋體驗做優化,因此仍然是 SEO;llms.txt 這類檔案,Google 搜尋本身不使用;生成式 AI 搜尋也不需要特別的結構化資料,但繼續使用結構化資料仍有助於取得複合式搜尋結果的資格;也不需要刻意把內容切成小塊。

那第 2 到 3 個月的 AEO 基礎該做什麼?我們建議三件事,全部都是「看得見、可驗證」的:

1. 打開 Search Console 的生成式 AI 成效報告。 Google 說明,這份報告已於 2026 年 8 月 31 日開放給全球所有網站,可以看到你的網頁在 AI 摘要(AI Overviews)與 AI 模式中獲得的曝光。流量還小時可能看不到資料,但先知道它在哪裡。
2. 打開 Bing Webmaster Tools 的 AI Performance。 這是第 1 週設定 Bing 的回報:你會看到 Copilot 引用了你的哪些網址。
3. 確認 robots.txt 對 AI 檢索器的設定是你想要的。 以 OpenAI 為例,它的官方說明指出 OAI-SearchBot 與 GPTBot 是兩個獨立的設定:你可以允許 OAI-SearchBot,讓網站出現在 ChatGPT 的搜尋結果中,同時不允許 GPTBot 把內容用於模型訓練。很多網站其實是被主機商或外掛的預設值擋掉,而不是自己做的選擇。

至於 llms.txt 要不要做:它對 Google 搜尋沒有作用,但對其他服務可能有用,做了也不會傷害排名。各家 AI 檢索器的設定方式與技術細節,我們整理在 AEO 技術實作手冊。重點是不要把預算押在「AI 專用技巧」上,而是把內容本身寫到值得被引用。

五、新網站多久會有排名?只看 Google 官方怎麼說

直接回答:Google 官方沒有給任何「幾個月上首頁」的時間表。官方的說法是:新網站可能需要一週左右才開始被檢索與索引,修改的效果從幾小時到幾個月都有可能,一般要等幾週才能評估,而且沒有人能保證在 Google 排名第一。 任何比這更確定的承諾,都不是來自 Google。

這一題值得單獨一節,因為網路上的答案太多、太篤定。「新網站 SEO 三個月見效」「保證關鍵字上首頁」這類說法,在推銷電話與廣告裡隨處可見。我們只整理 Google 自己寫下來的東西:

• 收錄的時間: Google 的索引報告說明寫著,新的網頁或網站可能需要一週左右,Google 才會開始檢索並建立索引。要求重新檢索的文件則說檢索可能需要幾天到幾週。
• 看見效果的時間: Google 的新手指南說,有些變更幾小時內就會生效,有些可能需要好幾個月;一般來說,你會想等幾週再評估成效。
• 保證: Google 在「你需要 SEO 嗎」這份文件中寫著沒有人能保證在 Google 排名第一,並提醒要小心宣稱保證排名、宣稱與 Google 有「特殊關係」,或能「優先提交」的業者。
• 常被引用的「4 個月到 1 年」: 這句話出自 Google 官方 Search Central 頻道 2017 年的影片〈How to hire an SEO〉,講者表示在多數情況下,SEO 人員需要四個月到一年,來協助企業先實施改善、再看到潛在效益。請注意它的脈絡:這是談聘請 SEO 顧問的合作時程,而且是 2017 年的影片;目前的「你需要 SEO 嗎」文件已經沒有列出任何時間範圍。

常見承諾 vs Google 官方說法

90 天內可以合理期待什麼

把官方說法整理起來,新網站 90 天內能合理期待的是這幾件事:重要頁面已被索引;搜尋品牌名稱找得到你;開始有一些非品牌字詞的曝光;追蹤數據完整、可信。至於特定產品關鍵字的排名,要看競爭程度、內容品質、網站累積的信任,沒有人能給你一個日期。

Search Console 在 2025 年 11 月推出、2026 年 3 月開放給所有符合資格網站的品牌字詞篩選器,可以把「已經知道你的人」與「透過搜尋第一次找到你的人」分開看——後者的曝光開始成長,才是網站真的在替你開發新客戶的訊號。不過 Google 也說明,這個篩選器只提供給頂層資源、而且查詢與曝光量足夠的網站,新網站可能要等一段時間才看得到。

破除一個常見迷思:很多老闆以為「沒排名就代表網站做壞了」。 事實上,前 90 天的主要任務是讓網站「具備被排名的條件」:被收錄、沒有技術障礙、數據看得見、內容開始累積。排名是這些條件累積一段時間之後的結果,不是上線附贈的禮物。反過來說,如果 90 天後連品牌名稱都搜不到你,那才是真正需要追查的警訊——通常是索引被擋住,而不是「還要再等等」。

六、上線後常見的坑:我們自己也踩過

直接回答:上線後最常見的坑不是大錯,而是「以為做了、其實沒生效」——例如自動化工具讀到快取的舊清單、發布前先打開新網址讓錯誤頁被快取、開發期的封鎖設定在後續更新時被帶回來、表單事件有記錄卻沒真的寄達。 每一個都要靠「讀回來驗證」才抓得到。

坑一:IndexNow 讀到快取的 sitemap,漏送剛發布的文章

這是本站自己踩過的坑。我們的網站在發布新文章後,會用 IndexNow 通知 Bing 等搜尋引擎。最初的做法是讓腳本直接去讀 sitemap,把裡面的網址全部送出。聽起來很合理,問題是:為了控制主機成本,我們的 sitemap 設了一天的快取,剛發布的文章要等快取更新後才會出現在 sitemap 裡。結果就是,在發布當下送出的,是一份不含新文章的舊清單——工具回報「成功」,但最需要被通知的那幾篇,一篇都沒有送到。

修正方式很簡單:發布之後,直接把新網址當作參數交給送出工具,中英文版本各送一次,不要依賴 sitemap。一般化來說,只要你的網站有任何一層快取(CDN、靜態產生、頁面快取),任何「自動從 sitemap 抓網址」的工具都可能慢一拍。上線後第一次發布新內容時,到 Bing Webmaster Tools 的 IndexNow 報告確認新網址真的有被收到,是很值得花的一點時間。

坑二:發布前先打開新網址,反而讓錯誤頁被快取

同樣和快取有關。很多人在按下發布之前,會先在瀏覽器打開「之後會用的網址」確認一下。如果網站有頁面快取,這一下可能讓「找不到網頁」的結果被快取住,發布之後一段時間內,訪客與爬蟲看到的仍然是錯誤頁。我們的做法是:新網址在發布前不要在正式站上請求,發布後再檢查,必要時手動清除快取或重新部署。建議直接問你的廠商三個問題:網站有沒有快取?多久更新一次?發布後要怎麼強制更新?

坑三:開發期的封鎖設定,在之後的更新中被帶回來

上線驗收時,你確認過 robots.txt 沒有全站封鎖、頁面也沒有 noindex。但網站會持續更新——廠商在測試環境改完功能,整包部署到正式站時,測試環境的封鎖設定也可能一起被帶了上去。這種事不會有任何錯誤訊息,只會在幾週後讓網頁索引報告裡「已由 noindex 標記排除」或「已遭 robots.txt 封鎖」的數字突然增加。所以網頁索引報告要每週看,而不是看一次就好。

坑四:表單事件有記錄,但詢價沒有寄到

GA4 顯示的表單送出次數,和業務實際收到的詢價信對不起來,是很常見的狀況。原因通常有三個:記錄的是「按下送出」而不是「成功送出」;表單通知寄到的信箱設定錯誤,或進了垃圾郵件匣;或是垃圾訊息也被算了進去。第 1 週用感謝頁建立關鍵事件,就是為了降低第一種誤差;另外兩種,每個月拿 GA4 的關鍵事件數,和實際收到的詢價信數量對一次帳就會發現。

坑五:所有帳號都在同一個人手上

網域、主機、Search Console、GA4、Bing Webmaster Tools、IndexNow 金鑰——上線後三個月,這些帳號常常散落在廠商、前任行銷同事、老闆個人信箱之間。任何一個人離開,你就失去某一塊的控制權。第 3 個月結束前,做一份帳號清冊:每個服務的擁有者是誰、用哪個信箱、誰有什麼權限。這份清冊比任何一篇文章都重要,也是換廠商時唯一能讓交接順利的文件。

七、90 天檢查表(可列印)

直接回答:下面這張表把前 90 天的工作拆成二十四項,依時間排序,每一項都寫了「怎麼確認完成」。 建議印出來貼在負責人的座位旁,每完成一項就記下日期。

這張表刻意沒有「排名進入前十名」這種項目,原因在第五節已經說明:那不是 90 天內可以被控制、也不是任何人能保證的結果。你能控制的,是讓這二十四項全部打勾。如果到了第 90 天還有幾項沒完成,不需要自責,把它們移到下一季的待辦就好——重要的是每一項都有人知道、有人負責。

八、誰負責:一次性設定與持續工作怎麼分工

直接回答:上線後的工作分兩類——一次性的設定(驗證、sitemap、事件、連結)適合由廠商或外包在第 1 週完成,但帳號擁有權必須留在公司;持續性的工作(看報告、寫內容、對帳)則要有一位內部同事負責,外包只能協助,不能代替。 分工的原則是:看得見數據的權力留在內部,需要技術的執行可以外包。

什麼該留在內部,什麼可以外包

判斷的標準只有一個:這件事如果負責的人明天消失,你會不會失去看見或控制網站的能力? 會的,就留在內部。帳號擁有權、每週看一眼索引報告、每月對一次詢價帳,這三件事都不需要技術背景,一位細心的行政或行銷同事,每週固定排一小段時間就能做到。

反過來說,速度優化、結構化資料、轉址規則、AI 檢索器設定這些需要技術、而且規則常變的工作,外包通常比內部從零學起更划算。內容則是混合:產品知識只存在你的工程師與業務腦中,外包的角色是訪談、撰寫、排程與發布,而不是憑空生產。台灣中小企業最常見的錯誤,是反過來做:把帳號交給外包,卻讓內部同事自己摸索技術設定。

如果你沒有內部人力、上線後的前 90 天也想有人一起走完,這正是我們網站架設服務在上線後會陪客戶做的事:第 1 週把設定做完並交接帳號,之後每月一起看報告、決定下一步要寫什麼。但即使你選擇自己來,這篇的檢查表也足夠讓你在 90 天後知道網站的真實狀況。

最後說一句持平的話。網站上線後的 90 天,沒有任何一項工作是困難的;困難的是「持續」。大部分網站不是輸在技術,而是輸在上線之後就沒有人再打開 Search Console。只要有一個人、每週固定一段時間、照著這張表走,你的網站就已經比多數同業的網站更有機會被海外買家找到。