大型網站 SEO 分工：SEO 改不了程式碼時，需求怎麼提、怎麼驗、怎麼盯

太長不看版： 在上萬頁的內容站做 SEO↗，大部分時間不是在改網站，是在寫需求、等排期、驗收、再複查。我們的做法有幾個固定動作：提需求前抽樣至少 50 頁看分布，不拿 2 頁下結論。模板問題給開發，逐篇內容給內容團隊。每張需求單都寫齊「示例連結、現況原始碼、問題、修改後、例外、優先級、驗收標準」。標了「已完成」的項目照樣要回頭查，2026 年就查到過被改回去的。測試環境逐字比對，資料不夠驗的寫「上線後驗」而不是打勾。監控分每日 6 項和每週一的基線對比，抽樣結論只能說是抽樣。最後，「暫不調整」是正式方案，前提是寫清楚為什麼不改、看什麼、看多久、什麼條件才動。

大型網站的 SEO，大部分工作是推需求

大型網站的 SEO 多半沒有程式碼權限，主要工作是把改動寫成需求單、推動開發或內容團隊排期，再負責驗收與複查。

我們接手過的大型內容站有一個共同點：網址量大到不可能逐頁處理，而且 SEO 手上沒有程式碼權限。一個 1 萬多篇的影音內容站、一個 8 萬篇文章的內容站、一個 sitemap 列了 45.8 萬網址的站，改 robots、改 canonical、改模板，全部要寫成需求單，交給開發或內容團隊排期。

這種分工下，SEO 的產出不是「我改了什麼」，是「我推動了什麼、驗收了什麼」。需求寫得模糊，開發照字面做完，問題還在。需求寫得太多，排期塞不下，真正要緊的被擠到後面。所以流程本身就是 SEO 工作的一部分，不是行政雜事。

還有一件事是我們一開始低估的：別人執行的改動，會在你不知道的時候被改回去。後台升級、模板重構、換外包，任何一次都可能把半年前驗收過的設定洗掉。這篇後面講的複查與監控，都是為了應付這個狀況。

先驗證，再分責任方

SEO 提需求之前要先抽樣至少 50 頁看分布，再依問題性質分責任方：模板與全站設定交給開發，逐篇內容交給內容團隊。

第一條規則是抽樣要夠大。只看 2 頁就下結論，很容易把模板問題誤判成內容問題。我們在 2026 年 9 月就踩過一次：後來把樣本拉到 60 頁，某個文字欄位 60 頁全部剛好 130 字。數字整齊到不自然，代表是模板設定，不是每篇文章各自寫成這樣。如果照 2 頁的觀察直接提給內容團隊，對方逐篇去改，問題也不會消失。

所以我們固定抽樣 50 頁以上看分布。分布告訴你問題的性質：集中在某一類頁、某個欄位、某個字數，通常是模板。散落各處、長短不一，才比較可能是逐篇內容的問題。

判斷出性質之後，責任方就清楚了。模板和全站設定交給開發。逐篇內容（標題、正文、圖片說明）交給內容團隊。技術上做不做得到心裡沒把握的，先私下問開發，問完再寫需求，不要先丟一張單過去讓對方評估。

牽涉使用者動線的事情又是另一類。例如鏡像網域要不要全部 301 到主網域：這類站的鏡像常常是刻意留給打不開主站的使用者，SEO 單方面判斷「鏡像分走了收錄，應該導走」，可能直接斷掉一批使用者。這種業務決策我們會先帶著證據開會，確定方向才提需求。鏡像與多網域的細節在大型網站索引管理那篇有完整的處理順序。

最後一個提單前的動作：先翻過去的需求文件，看這件事有沒有人提過。提過但沒修好的，不要重開一張，在原本那條寫「仍未修復，已 N 天」。重複提單會讓開發以為是新問題，也讓真正的拖延時間消失在紀錄裡。

一張需求單該寫什麼

SEO 需求單固定八個欄位、順序不變，包含需求、示例連結、現況、問題、修改後、例外、優先級與驗收標準。

我們的需求單固定八個欄位，順序也固定：

「修改後」和「例外」是最常被省略、也最常出事的兩欄。只寫「標籤頁加 noindex」，開發可能連有實際內容的標籤一起加。寫明「文章數少於多少的標籤加 noindex，以下這幾類不套用」，才不會誤傷。標籤頁的門檻怎麼訂，可以參考標籤頁治理那篇。

現況一定要附證據：curl 結果、瀏覽器裡真實渲染出來的 DOM、搜尋平台後台的截圖，並寫明抓取時間。網站隨時在變，沒有時間戳的截圖，過兩週誰都說不清楚那是改之前還是改之後。

優先級的分級只有在大多數單不是 P0 的時候才有意義。我們會把 P0 留給「正在讓整批頁面掉出索引」或「整站狀態碼出錯」這種事。標題寫法、結構化資料↗補欄位，通常是 P2、P3。

「已完成」不等於還在線上：複查與測試環境驗收

標記「已完成」的 SEO 需求仍可能被改回去，所以要每日複查，測試環境則逐字比對 TDK、H1、robots。

這是我們最想提醒的一點。2026 年 10 月複查時，一個站在 2 月標記完成的「分頁 /page/2/ 加 noindex」，現在又變回 index。另一個站 3 月 9 日標記完成的 VideoObject 結構化資料，現在整段不見了。兩張單在文件上都是「已完成」，如果不回頭查，會一直以為問題早就解決。

複查因此不是偶爾做的事，而是排進每日巡檢：舊需求有沒有上線、有沒有被改回去，跟狀態碼、robots、canonical 一起看。發現被改回去的，照前面的規則，在原需求下寫「已回退」和發現日期，不要開新單。

測試環境驗收也一樣不能打折。我們會拿需求文件逐字比對 TDK、H1、robots，一個字一個字看。2026 年 10 月 10 日驗收的一批需求，13 項裡只有 8 項通過。沒過的項目要分開處理：確定沒做對的退回。測試環境資料不夠、根本驗不了的，寫「上線後驗」，不算通過，上線當天再補驗。

驗收方法本身也會出錯。播放器和部分內容是 JavaScript 掛上去的，我們曾經用 fetch 加 DOMParser 判斷「頁面沒有播放器」，結果是誤報。現在的做法是：看瀏覽器裡的真實 DOM，結構化資料也用瀏覽器確認。某些網站的防火牆會擋非瀏覽器的 User-Agent，要用 Googlebot 的 UA 才看得到 Google 看到的版本。自動化驗影片能不能播的時候，背景分頁會被瀏覽器降速，背景跑出來的「不能播」要拿前景分頁再驗一次。

還有兩件看起來是行政、其實是驗收前提的事。第一，接新站的第一天就盤點權限：需求文件、Search Console、GA4↗、Yandex、Bing，缺什麼一次申請完，不要等到要驗收才發現看不到報表。第二，有些站從本機連不上，要從目標地區的主機抓，不然你驗的是錯誤頁。

每日與每週：監控節奏怎麼排

SEO 監控分每日 6 項巡檢與每週一基線對比，狀態碼、robots、sitemap 等直接 curl 正式站。

每天的巡檢我們固定看 6 項：

15 條抽查的組成是固定的：首頁 1 條、最新文章 5 條、隨機舊文 9 條。新文章 Google 一兩天內還沒收錄是正常的，舊文掉出索引才是訊號，所以舊文佔多數。GA4 按主機名拆開，是因為鏡像和主網域的流量常常方向相反，加總看會看錯。主機名這個維度怎麼用，可以對照 GA4 的維度與指標說明↗。

每週一做三件事：跟基線對比流量。把索引抽查的樣本累計到 50 條以上，才下收錄率的結論。看標籤頁和核心頁的跌幅分布、noindex 數、新增標籤數。

監控有一條底線：狀態碼、robots、canonical、sitemap 一律直接 curl 正式站。Search Console、Bing、Yandex 的報表有幾天到幾週的延遲，拿來判斷「現在」網站長什麼樣子，會把已經修好的當成還壞著，或反過來。報表用來看趨勢，線上用來看現況。

另一條是：只有一個搜尋引擎出狀況，就只做那個引擎的專項，不動全站結構。Bing 回 5xx 而 Google、Yandex 正常，就是 Bing 那邊的問題，照 Bing 網站管理員指南↗和它的後台報表做專項。為了它改全站模板，會把另外兩個引擎一起拖下水。各引擎對 robots 指令的支援也不完全一樣，Google↗ 和 Yandex↗ 的說明值得分開讀。

抽樣和全量要分開講

我們犯過的最典型錯誤，是把 15 條抽查當成全站。一個影音內容站的網址檢查抽了 15 條，只有首頁是已收錄，看起來像整站被踢出索引。可是同一時間 Search Console 的索引報表寫的是已收錄 15.3k、未收錄 88.2k。情況確實不好，但跟「只剩首頁」是完全不同的嚴重程度，對應的方案也不同。

所以我們的規則是：抽樣結論只能寫「抽樣顯示」，下結論前拿全量報表對照。需求單和對外報告裡的數字，優先用全量報表，抽樣只用來發現問題。

抽樣還有另一個陷阱：換了一批樣本，問題數就會跳。我們看過巡檢報告寫「新增 50 個問題」，查下去是抽到另一批頁面，問題總數其實持平。這類「看起來是問題、其實不是」的情況，流量下降診斷那篇整理了一張對照表。

大型網站的抓取額度本來就有限，Google 對大型網站抓取預算的說明↗也是這個前提。收錄率天生偏低的站，抽樣看到「大部分沒收錄」不一定是新問題，要跟上週、上個月的全量數字比，才知道是不是在變差。

結論怎麼寫：原因分四級，「暫不調整」也是方案

SEO 結論先寫資料變化與範圍，最後才下判斷。「暫不調整」要寫清為什麼不改、看什麼、看多久、何時才動。

寫結論的順序我們是固定的：數據變化、變化範圍、具體頁面、具體詞、頁面現況，最後才是判斷。先有結論再去找數據，幾乎一定會找到支持自己的那幾條。

原因分四級寫：

「演算法波動」「內容深度不足」這種寫法我們不收，因為它沒有證據，也沒有下一步。分級的用處是讓讀報告的人知道哪些可以直接排進需求、哪些還要再觀察。Google 對流量下降的除錯說明↗也是先拆範圍再找原因，思路一致。

判斷影響要看絕對流量，不只看比例。搜尋結果頁 -50% 可能只少 500 次點擊，文章頁 -10% 可能少 2 萬。只看百分比排優先級，會把人力花在最不值錢的地方。

最後是「暫不調整」。在需求排期有限的情況下，很多問題的正確答案就是先不動，但它要寫成一個方案，而不是一句「再看看」。我們要求寫清楚四件事：為什麼現在不改、觀察什麼指標、觀察多久、指標到什麼程度才動手。寫得出這四件事，「暫不調整」就跟其他方案一樣可以被追蹤、被複查。寫不出來，通常代表還沒想清楚。

產出節奏：每 2 週一批，每批 2–4 項

SEO 需求單每 2 週提一批、每批 2–4 項，多出來的放進 backlog，讓每張單都能被做完、驗收與複查。

需求單我們是每 2 週提一批，每批 2–4 項。每天巡檢一定會看到更多問題，多出來的放進 backlog，不急著全丟出去。

理由很實際：開發和內容團隊同時在做別的專案，一次丟十幾張單，他們只能挑容易的先做，最重要的那張反而被拖延。2–4 項的批次，讓每張都有機會被認真做完、被驗收、被複查。這也讓 SEO 的產出跟團隊的節奏對齊，不會變成單方面一直催。

排進批次的順序，我們會參考前面幾篇的框架：索引層的問題先處理（索引管理），再處理大量低價值內容（內容剪枝），最後才是單頁的標題與結構化資料。整體的 SEO 日常要怎麼排，SEO 作業系統那篇有更完整的說明。robots 的寫法則可以看 robots.txt 與收錄指南。

如果你手上的站也是這種「SEO 只能提需求」的結構，我們在站群與大型網站 SEO 服務裡做的就是這一整套：寫需求、驗收、複查、盯監控。

這篇是大型網站 SEO 指南的其中一章，六個工作面的全貌和接手第一週的處理順序都整理在那裡。

常見問題

SEO 沒有程式碼權限，還能做什麼？

能做的其實很多：判斷問題性質、寫出開發看得懂的需求單、驗收、複查、監控。改動由別人執行，但「改什麼、改到什麼程度算完成」是 SEO 決定的。需求單寫得越具體，執行方越不需要猜。

需求單一次要提幾項比較好？

我們的節奏是每 2 週一批、每批 2–4 項，其餘放 backlog。項目太多，執行方只會挑簡單的先做，最重要的反而被延後。

標記「已完成」的需求，為什麼還要複查？

因為常被改回去。我們在 2026 年 10 月就查到兩個站的已完成項目回退：一個是分頁的 noindex 變回 index，一個是 VideoObject 結構化資料消失。後台升級或模板重構都可能洗掉舊設定。

抽查 15 條網址，可以代表全站收錄嗎？

不行。抽樣只用來發現問題，下結論要拿全量報表對照。我們遇過抽查 15 條只有首頁收錄，但全量報表是已收錄 15.3k、未收錄 88.2k 的情況，嚴重程度差很多。

「暫不調整」要怎麼寫才不像在拖？

寫清楚四件事：為什麼現在不改、觀察什麼、觀察多久、到什麼條件才動。四件都寫得出來，它就是一個可以被追蹤、被複查的方案。

---

了解我們的廣告策略與投放服務 →