網站架構圖難產？因為你把 AI 用在畫圖，而不是思考

盯著空白畫布半小時，一個方塊都沒拉出來；或把「幫我畫一份網站架構圖」丟給 AI，換回首頁、關於、產品、部落格、聯絡五個樣板方塊。這兩種卡關，常被歸因於繪圖軟體不熟、沒有設計底子。歸因錯了。真正卡住的是：網站還沒被講成一個可以被檢驗的結構。發想、檢驗、排版是三種性質不同的思考，硬壓進「畫圖」一個動作，注意力來回切換，結構就長不出來。AI 在這套流程裡的正確位置只有兩個：在源頭把模糊的想法攤開，在終點回頭審查攤開的結果。中間那段畫圖，交給任何順手的白板工具都行。

另一種場景更常見：網站已經上線兩三年，流量卡住了。週一早上打開報表，首頁曝光持平，服務分類頁集體下沉；下午的改版會議上，五個人對「我們網站到底有幾頁」有五種答案。這時候真正的問題不是怎麼畫圖，而是該不該動架構。接下來的內容把這個判斷放在最前面：先分診病因、計結構訊號、定動工範圍，確認結構真是病灶，才進入重建。

快速重點：架構圖難產多半不是工具問題。既有網站先分診病因、計結構訊號、定範圍，確認該動才動；再讓 ChatGPT 產出頁名、搜尋意圖、存在理由、待釐清問題四欄位清單，搬上 Miro 成圖，回貼 AI 逐項審查。可被檢驗的結構先成立，圖只是它的影子。

範圍先畫清楚：這份指南不談主機、不談 CSS，XML 檔只在上線對帳時接一段；它處理的是最上游那張圖，頁面有哪些、掛在哪一層、彼此怎麼連。下游的實作細節，各有各自的路。

一個要先講的提醒：把 AI 的輸出照單全收，會得到一份看起來完整、卻跟生意脫節的架構。模型擅長攤開與檢查，不擅長替你判斷哪個分類值得砍、哪條轉換路徑合理。判斷權留在人這邊，這條分工貫穿整篇的設計。

畫不出架構圖的人，通常不是敗在繪圖工具

難產的根源不在工具。發想要想內容、檢驗要對照證據、排版要處理視覺，三種工作用的腦袋不同；一次做三件事，每件都只能做到表面。順序倒過來就順了：先把結構講清楚、檢驗過，圖跟著長出來。架構圖從來不是工作的目標，它是被講清楚、通過檢驗的結構留下的影子。這也是 AI 位置的原則：它守在攤開與回頭審查兩端，畫圖那一段，誰來畫差別都不大。

把「畫一份架構圖」直接交給 AI，等於要求它在一次輸出裡同時做完那三件事：它會先替你猜一套產業通則，再把通則排成看起來漂亮的層級，中間需要被檢驗的假設一個都沒留下。你拿到的是一張沒有思考痕跡的圖，想改也不知道從何改起。反過來，先要求它交出清單、標注意圖、列出沒想清楚的問題，思考的過程就被攤在紙上；圖只是把這份紙搬個位置。難產與不難產的差別，常常就差在這個順序。

名詞也先分乾淨。「網站地圖」在不同人口中指三種東西：給爬蟲讀的 XML Sitemap 檔案、給使用者看的目錄頁、給團隊對焦的視覺架構圖。三種是同一條流水線上的三站：最上游的視覺架構圖決定該有哪些頁；網站做好之後產出 XML 檔交給搜尋引擎，那是一條獨立的工作線，細節看Sitemap 的產生與提交實作；目錄頁再視需要補給真人。名詞對齊了，會議才不會出現業主說有畫圖、打開卻是機器碼的雞同鴨講。Sitemap 的基礎觀念還不熟的讀者，可以先翻Sitemap 的入門概念再回來。

既有網站的讀者，比新站多一層前置問題：流量卡住時，結構不一定是要動的地方。內容不夠深、外部連結薄弱、市場需求本身在移動，都會造成類似的症狀。「先不動」是合格的結論；之後的章節先教你判斷，再教你動工。

期望也先講明白：這套流程的合理預期，是半個工作天內拿到一份可討論、可修改的結構初稿，實際時間依網站規模浮動（建構式的情境描述，不是保證）。它不承諾排名、不承諾流量、不承諾轉換；它承諾的是，動工之前，你對「網站有哪些頁、彼此怎麼連」有一份寫下來、查驗過的答案。對 ChatGPT 還不熟的讀者，介面與基本操作可以先用ChatGPT 的新手教學暖身。

流量卡住先別怪架構：三種病因的分診台

先分診，再治療。用 Search Console 的報表加上站內觀察，把病因分成三類：內容面（頁面本身的深度或契合度不足）、權威面（外部連結與品牌訊號薄弱）、結構面（頁面存在、卻沒有任何導覽或連結抵達得了）。只有第三種是結構病；前兩種病因，重畫架構治不好。

↔ 左右捲動檢視完整表格

症狀	常見病因	先做的處置
有收錄、曝光往下掉	內容面：主題需求轉移或深度不足	補內容、對照搜尋意圖，先不動結構
曝光持平、點擊率下滑	敘述面的契合問題	改標題與描述，小範圍測試
頁面在搜尋引擎找得到，站內卻繞不到	結構面：導覽與內部連結斷線	進入五訊號檢查，準備立案

判讀順序固定：先看收錄、再看曝光、接著才看點擊與行為。順序跳過，很容易在證據攤開之前，就先把責任推給架構。成因從來不只一個，Ahrefs 在 2023 年 12 月發布的搜尋流量研究顯示，其資料庫中 96.55% 的頁面沒有取得任何 Google 自然搜尋流量；這個數字只能當「成因多元、結構只是其一」的佐證，不能倒過來推論改善結構就會有流量。

誤診的代價不小。架構重整是跨部門專案，選單、網址、內部連結、內容搬移都會被牽動；病因若不在結構，這些投入很難回收。把分診做在前面，是保護專案活下來的第一道閘。

分診本身花不了多少時間：一份報表、一張站內頁面清單、一個下午。它的產出也不只是「要不要動架構」這個結論，還有一份寫下來的病因紀錄；之後不管專案開不開，這份紀錄都是比較的基準線。沒有基準線的團隊，只能在「感覺變差了」跟「感覺還好」之間擺盪。

用一個建構情境示範分診怎麼走：一家工業零件供應商的官網，採購反應在站內找不到材質認證文件，繞了一圈都是從 Google 搜尋直接進到那頁。頁面存在、搜尋引擎也收錄了，站內卻沒有任何選單或連結路徑抵達得了，這是標準的結構面症狀，值得進入下一步的訊號檢查。技術面更完整的檢查框架，可以搭配技術 SEO 的整體指南對照著看。

五個結構訊號，中兩個才值得立案

五個訊號：孤兒頁、搜尋意圖重疊、點擊深度過深、分類命名混亂、收錄膨脹。同時出現兩個以上、而且落在商業頁面（服務、商品、轉換路徑上的頁），才立案處理；只有單一訊號，先用局部修剪應對。這條計數是實務上的經驗法則，不是任何搜尋引擎公布的門檻；用它之前要知道，自己用的是啟停判準，不是官方規則。

• 孤兒頁：把選單、頁尾、分類頁與內文出現的站內連結匯成一張清單，跟全站網址清單比對。出現在後者、不出現在前者的頁面，先列為孤兒候選；連結的來源難保一網打盡，認定前再用爬取清單複核一次。
• 搜尋意圖重疊：在報表裡挑出主要字詞相同或高度相近的頁面，看它們是否各自吃到同一個查詢的曝光。重疊配對的處理思路，看關鍵字蠶食的判斷與處理。
• 點擊深度過深：從首頁沿導覽實際點擊，數到重要頁面的步數。點擊深度是使用者成本與內部連結佈局的代理指標，不是搜尋引擎公布的排名門檻；「三次點擊內」是資訊架構的經驗法則，當提醒用，不當軍規用。
• 分類命名混亂：把全站分類名稱列成一欄，檢查有沒有同義互踩、互相包含、或客人唸不出來的名字。命名問題會直接反映到後面的使用者測試。
• 收錄膨脹：用站內搜尋語法或爬取清單工具，比對被收錄的網址數與實際有效頁數。多出一截，通常代表標籤頁、參數頁或草稿頁外流；意圖重疊常與收錄膨脹同時出現，病灶多在分類層，不在單一頁面。

兩個輔助證據可以加權：搜尋結果裡長期排不上網站連結（Sitelinks），不能直接推給結構，搜尋引擎對階層還沒有穩定理解只是其中一種解讀，查詢與頁面的相關性不足也會有同樣的表現，先當間接線索用，原理與養成方式看Sitelinks 的運作與爭取；爬取資源被大量低價值網址吃掉，是結構失序的另一種帳面證據，概念併著爬取預算的運用一起看。Backlinko 在 2025 年 4 月更新的點擊分布分析顯示，點擊高度集中在搜尋結果前列；這只說明前列版面的效益，不能推論取得 Sitelinks 就會提升點擊。

證據不夠的時候，先記錄、不立案。把五訊號的檢查結果寫進一張表，註明日期，下季重看；累積兩季都落在同一個區塊，立案的正當性自己會長出來。

全站重畫、分區修剪，還是先不動？

診斷成立後，用「商業影響乘以病灶嚴重度」定範圍：越靠近轉換的區塊越優先；已經帶排名的網址，除非病灶明確，只調導覽與內部連結、不動階層。規模切三檔，觸發條件、成本量級與驗收里程碑先寫下來，專案才不會無限膨脹。

↔ 左右捲動檢視完整表格

規模	觸發條件	成本量級	驗收里程碑
先不動	訊號不足，或病因落在內容面、權威面	一場會議與一份紀錄	季度重看報表與訊號表
分區修剪	訊號集中在單一區塊，如服務區的孤兒頁	數週的局部工程	該區導覽路徑補齊、網址不變
全站重畫	多區塊同時中訊號，或品牌定位調整	跨部門專案，以季計	新舊結構對照移轉完成、轉址收尾

骨架的形狀有個機制常識可依：深度換秩序、廣度換觸及。深層結構把同類頁收攏，秩序好、觸及慢；扁平結構什麼都離首頁近，頁面一多選單就爆；軸心放射用一個主題頁帶一群子頁，適合內容權威的經營。成熟網站多半是混合體：服務區深、內容區放射、政策頁扁平地放在頁尾。拿到 AI 的輸出時，先看它在每個區塊長成了哪一種、是不是這個專案要的；同時提防矯枉過正，聽到「不要太深」就把全站壓平，頂層爆炸同樣增加使用者的選擇負擔。

優先序用行銷漏斗定：服務與商品區先動，內容區排後，政策頁放最外圍。內容區的重整走主題叢集的邏輯，一個主題一個支柱、群集文章互連；電商、內容站、在地服務、作品集四種站型的原型差異，當判斷基準線記在腦裡就好，不必逐項套用，長線的經營方法另見內容行銷的策略框架。

防守清單裡最重要的一條：動階層常牽動網址，但不是必然，網址會不會跟著改，取決於分類路徑有沒有寫進網址結構。既有排名是資產，網址真的改了，轉址、站內連結更新、外部連結失效都要一併處理，規則看SEO 網址的規劃原則。沒有明確病灶的網址，不要為了整齊而改。

跨部門的溝通成本常被低估。範圍切越小、里程碑越多，專案越容易活著走完；全站重畫的專案死在半路，多半不是技術問題，是沒有人知道現在做到哪、下一步誰負責。

第一張草稿不是圖：讓 ChatGPT 先交出四欄位清單

白板先留著，真正要打開的是對話視窗。第一份草稿的形態不是圖，是一張每頁四個欄位的清單：頁名、搜尋意圖、存在理由、待釐清問題。頁名說明這一站有哪些頁；搜尋意圖記下使用者帶著什麼問題上門，供之後的 SEO 判斷對照；存在理由回答「少了這頁會怎樣」，防止清單長出冗餘頁；待釐清問題把還沒想清楚的假設逼出來，寫在紙上而不是留在腦中。四個欄位填完，模糊的想法才變成可逐頁審查、也搬得上白板的材料；骨架定了，成圖與審查才有東西可做。

把變數鎖進指令，模型才不會回退成樣板

生成的品質由鎖進指令的變數決定：角色、產業與受眾背景、商業目標、輸出欄位與限制。變數不鎖，模型回退到產業通則，給你的就是那五個樣板方塊。角色、背景、任務、限制的四段骨架順手好用，背景欄掛上既有網站的診斷訊號之後，輸出會立刻貼近現場：

角色：你同時具備資訊架構與技術 SEO 的實務經驗，習慣先盤點、再給建議。

背景：既有網站，產業是工業零件供應，主要讀者是設備採購與維修工程師。近期的診斷訊號：材質認證文件頁在站內沒有任何導覽抵達；三個服務頁的搜尋意圖高度重疊。

任務：請以四欄位格式逐頁盤點這個網站，欄位為頁名、搜尋意圖、存在理由、待釐清問題；並對每一頁標註保留、合併、刪除或新增的建議，附上理由。

限制：不得發明背景沒提過的服務或產品；階層用縮排呈現、不超過三層；資訊不足的地方，寫進待釐清問題，不要自行補情節。

既有站走逆向清點：把報表匯出的頁面清單與現有網址貼進脈絡，要求模型逐頁標去留與理由，這份輸出同時就是一張現況盤點表，人手一份、會議直接用。新站的情境只是少了「盤點既有頁」這一段，受眾與商業目標照樣先寫清楚；受眾描述得越具體，清單越貼，還沒做過人物誌的讀者，先看Persona 人物誌的建立方法。

輸出格式綁死三件套：縮排階層、每頁意圖標記、結尾的待釐清問題清單。拿到第一版先別急著搬上白板；把待釐清問題逐條回答，再跑第二版，通常兩三輪來回就會收斂。這些問題本身就是收穫，它們標出了你跟團隊還沒想清楚的地方，比一份「看起來很完整」的清單值錢。

第二輪可以餵進兩三個同業網站的結構，要求模型把「產業必要項」跟「可刪冗餘」分開：哪些頁是這一行少了會被客人覺得奇怪、哪些只是行業慣性、哪裡還有結構上的差異化空間。這一步的價值在把通則跟差異剝開，很多頁面拿掉其實不影響生意；判斷的素材模型給得出，採不採納，還是那個最懂自家生意的人決定。

還有一個變數常被漏掉：組織的真實限制。有的站是兩個人維護的，有的內容半年才會更新一次；把這些條件寫進背景欄，模型才不會開出一個需要專職小編餵養的分類體系。清單上的每一頁，都要有人認養維護的責任；沒有維護計畫的頁面，一開始就不要開，開了也只是慢慢長成沒有人敢動的死角。

清單進白板：Miro 把文字草稿變成可共同編輯的圖

文字清單有個先天限制：看不出節點之間的關係，也沒辦法讓一群人同時在上面改。這時才輪到白板上場。Miro 比一般繪圖軟體適合這件事，關鍵不在畫圖功能，在於它為協作與迭代而生：架構圖本來就是一份要被一群人一起改的文件，改的速度比畫得美重要得多。

操作前先畫清楚官方文件的邊界。Miro 官方對 Mind Map 的說明，涵蓋心智圖的建立、調整與匯出方法；官方並未承諾把縮排清單貼上白板就會自動展開成整棵樹。流程因此不建立在自動解析的假設上：以 Return 建立同層節點、Tab 往下降一層，逐層把清單建成樹；或把清單放進提示，請白板內建的 AI 出初稿，再逐項核對層級。把操作範圍錨定在官方說明文件寫明的功能裡，整段工作才不會押在一個不存在的自動化上。

同一份架構在白板上至少有三種畫法，對應三個階段：發散期用 Mind Map，從根節點往外長，頁面多也不怕亂；定稿期換 Flowchart，把轉換路徑與決策點標成粗線；討論期用自由排版，貼參考、放便條、圈問題。挑選標準只有一條：這張圖現在要服務哪個階段的對話。

圖上牆之後，每個節點都變成可以被指認、上色、留言的物件。兩個小動作價值很高：把每頁的搜尋意圖標上顏色，把還沒定案的頁面拖進「待決定」區。這不是美化，是在替下一節的 AI 審查預鋪資料：意圖色塊讓重疊一眼可見，待決定區讓範圍不會默默擴大。版面的秩序感，跟做網頁版面配置時的排版判斷是同一套肌肉。

協作的節奏也設計一下：板面開「討論中、已定稿、下次再議」三個區域，每個節點有人認領、有人拍板；再把新舊兩版清單貼成角落的對照文字框，有人問「這頁為什麼被拿掉」，指著舊版就能說明決策脈絡。有這兩個機制，圖會收斂；沒有，它只會無盡漂浮，開十次會還在改首頁底下掛什麼。

定稿之後的交接也有個小動作：把樹狀圖連同「待決定區」的最終決議一起匯出，附上四欄位清單的原始檔。工程看的是層級與連線，客服看的是命名，客戶看的是全貌；同一份圖餵三種人，比口頭解釋三遍省事。圖在這個階段的身分很單純：一份可以指著講的溝通介面。

免費方案與替代品

成本面：免費方案可編輯的板數量有限制，單跑一份架構圖通常夠用；什麼額度對應什麼價格，以Miro 官方定價頁當下的說明為準，卡到上限再升級，不為了用不到的功能預先付費。

替代品的比較標準也只有一條：能不能接住「生成、視覺化、審查」這三步。團隊已經在 Figma 裡工作，FigJam 順手，操作基礎看Figma 的完整教學；想橫向比對各種 AI 工具的定位，參考AI 工具的總整理。載體可以換，閉環不能斷；陷在挑工具的迴圈裡，比用錯工具更貴。

回馬槍：把定稿清單餵回 ChatGPT 當結構審查官

圖定稿之後、交給工程之前，還有一件報酬率極高的事：把定稿的節點清單回貼給 ChatGPT，配一份列舉式的審查指令。同一個模型，換一組指令，就從生產者切換成審查者。生成、視覺化、審查是一個閉環，回審是第三邊；少了這一邊，前面兩步的產出只是「大家看了都點頭」，沒有被真正檢查過。

以下是定稿的節點清單。請同時以技術 SEO 與資訊架構顧問的身分審查，逐項用表格回覆：

一、哪些頁面從首頁起算、要點超過三次才到得了？列出走過的路徑。

二、哪些節點沒有任何上層分類或選單指向它們？

三、哪些頁面的搜尋意圖彼此重疊？指出配對。

四、哪些分類命名不一致，或對第一次來的使用者沒有意義？

五、從首頁到主要轉換頁經過幾個節點？哪一步可以拿掉？

每個發現請附上你引用的清單原文；清單上沒有的頁面，不要提出。

這組指令有效的原因，是把結構問題拆成可列舉的清單。空泛的問題只換得空泛的答案，具體的問題才換得可以直接動手的具體漏洞。審查結果也不是終點：回饋到四欄位清單重跑一版，流程就從單向流水變成迭代。

失效模式要知道：模型會用產業通則補它沒看到的缺口，發明清單上沒有的頁面、再指認那個假頁面有問題。審查表回來，逐條對照原圖，憑空出現的項目刪掉；成因與更完整的防範思路，看AI 幻覺的成因與防範。人是最終審查關，這條底線不外包。

命名一致性的檢查，順便對齊實體思維：一頁對應一個講得清楚的實體，名稱、內容、連結指向同一個概念，機器與人才不會錯認，觀念看實體 SEO 的經營。而圖上的每一條線，上線後都要有內部連結的實作對應，佈法看內部連結的建立。

五條紅線，AI 可以列單、不能簽名

有五項判斷，AI 只能產生待辦清單，簽核權在你：懂自己的生意、也懂 SEO 後果的人。架構規劃的完整觀念，網站架構圖的規劃總覽另有一篇；這裡只列簽核的動作。

↔ 左右捲動檢視完整表格

紅線	檢查動作	通過標準	常見誤判
點擊深度	從首頁沿導覽實點重要頁面	重要頁有合理導覽與內鏈；三次點擊是經驗法則	機械計數，把政策頁也拉上頂層
內鏈與麵包屑	圖上每條線對照一條實體連結或麵包屑	沒有連結指向的頁，結構上等於不存在	只查選單，漏掉頁尾與內文連結
網址呼應階層	網址逐段對照節點層級，以純文字核對	網址段落與節點層級對得起來	以為搬方塊等於改結構
意圖重疊處置	對審查輸出逐配對做判斷	合併、區隔或擇一，理由寫下來	把處置整包交給模型決定
收錄與爬取	對照收錄清單與爬取報告	帶流量的舊頁都還在結構內	期待重複內容自動被處罰或加分

意圖重疊的處置是商業判斷，不是技術判斷：兩頁合一頁，還是切成兩個受眾各寫各的，模型只能標記候選。搜尋引擎不會因為內容重複就自動處罰網站，但可能只挑一個標準版本，或讓訊號分散。雙向的風險都要看：壓平過頭，選單爆炸；拉深過頭，底層被埋。頂層數量與深度沒有通用門檻，回到自己的內容量與使用者任務決定。

簽核的形式不用複雜：一張表、五列、每列一個名字與日期。重點是「誰為這個判斷負責」被寫下來了。AI 的審查輸出可以直接貼在表旁當附件，但它不出現在簽名欄；名字進了簽名欄，代表那個人看過原圖、對照過資料，而不是只看過模型的結論。

簽核前，把既有收錄與帶流量的舊頁攤在圖旁對照一次，確認重畫沒有砍掉既有資產。站內結構的優化原則，跟網站結構的優化這篇互補著看；紅線清單是那些原則的手動簽核版。

交給工程前，先請目標使用者迷路一次

企劃與模型一起磨出來的分類，畢竟是從經營者角度長出來的；真的要在上面找資料的，是第一次走進來的人。低成本的做法是找五位到八位貼近人物誌的受眾，做一輪探索性的樹測：給對方一個任務，讓他在拿掉所有視覺裝飾、只剩文字的分類樹上找頁面，沿途記下他在哪個節點迷路、在哪一層猶豫，再回頭調整分類與命名。一趟走完，圖上畫的連線是不是真的通，才有第一手的答案。

執行上不用市調公司：表單或簡單原型就能做探索性驗證。邊界要守住：小樣本適合找問題，不適合估成功率；通過率是觀察，不是可以寫進簡報的精確數字。依錯誤模式決定要不要加樣本，多數人卡在同一個節點，那個節點就是答案。

任務的設計有個訣竅：從使用者的目的出發，不從你的分類出發。「我想找適合食品廠產線的密封件規格」是好任務，因為它模擬真實的疑問；「請點進產品分類」是壞任務，因為它已經替受測者指了路。每個任務配一小段情境，受測者一面找、一面把當下的想法講出來，你記下的就不只是對錯，還有猶豫的原因：名字看不懂、兩個分類都像、以為再點一層會有更多。這些碎片，就是分類要改的證據。

卡片分類從反方向再驗一次：把頁面與內容主題寫成卡片，讓受測者自由分組、命名組別（開放式），或塞進你預設的分類（封閉式）。多數受測者的歸組跟企劃分類對不上，就是分類違反直覺的警訊。招募對準人物誌，五個對的人，勝過五十個路人。

三道關由此成形：機器抓結構漏洞、人抓紅線、使用者抓命名與預期落差。AI 審查跟真人測試不互相替代，一個看圖的內部一致性，一個看圖跟外部的契合度。

從圖到後台：分類、選單與上線後的對帳

藍圖不走樣的對照邏輯是固定的：頂層節點對應主選單、第二層對應分類、葉節點對應頁面，跨層連線以手動內部連結實作。在圖上逐項標註後台落點（分類、選單、頁面編號），交接與驗收才有依據。WordPress 的分類階層與排序，看WordPress 分類的排序與調整；主導覽的組成，看WordPress 選單的設定。

分類數量要克制。後台分類沒有固定篇數門檻，看三件事：它是否代表一個清楚的需求、現有內容撐不撐得起、後續會不會真的擴充。每類只有兩三篇的分類頁，沒有導覽價值，只是選單上的雜訊。

「改圖不等於改結構」也要寫進團隊的語彙：動到層級與連線才是結構調整，只搬方塊是美編。一個常見的偏移場景（建構情境）：邊架邊改的網站，作品頁掛錯到「關於」底下、聯絡表單被埋進第三層，沒有人記得圖上原本怎麼畫。這類漂移通常無聲，靠對帳抓回來。

上線不是結束。每季把後台實際的分類重畫回白板，跟原圖並置比對，分辨兩種解讀：生意方向調整了，架構該跟著進化，這是該發生的；沒人注意的情況下被改歪了，這是要抓回來的。再用報表的既有收錄對照新架構，確認帶流量的頁面沒有掉出結構；XML 檔的產出與提交，接在這一步的尾巴。

帶得走的判斷流程：九步一條線

整套方法收攏成一條線：症狀分診、訊號計數、範圍決策、四欄位清單、白板圖、AI 審查、紅線簽核、使用者迷路測試、後台落地。九步，每步有輸入、有產出、有停止條件；任何一步過不了，退回上一步修正，不硬往下走。

↔ 左右捲動檢視完整表格

步驟	輸入材料	產出	停止或退回條件
症狀分診	報表與站內觀察	病因歸屬	病因不在結構：記錄後離場
訊號計數	五訊號檢查結果	訊號清單與落點	少於兩個：先局部修剪
範圍決策	商業影響與嚴重度	先不動、分區或全站	共識不足：縮小範圍再回來
四欄位清單	既有頁面、受眾與目標	文字版結構草稿	待釐清未清：回答後重跑
白板圖	定稿清單	可共同編輯的圖	節點無人認領：留在討論區
AI 審查	節點清單與審查指令	漏洞清單	出現清單外的頁面：刪除再核
紅線簽核	五條紅線檢查	簽核紀錄	任一紅線未過：回清單修正
迷路測試	文字分類樹與任務	迷路節點紀錄	多數受測者迷路：回範圍決策
後台落地	圖與後台對照	分類、選單、內鏈、XML 檔	季度對帳發現漂移：重啟分診

啟動與放棄的條件並列在表裡：「先不動」是合格結論，診斷不出結構病，就不立專案。兩個建構情境對照收尾：前述的零件供應商官網，分診落在結構面、五訊號中兩個且集中在服務區，走到分區修剪就停，補齊導覽與內鏈、網址不動；一家手作保養品電商，商品區結構健康，問題集中在內容區分類長歪，於是商品區不動、只做內容區的主題重整。同一套流程，兩種範圍，兩種結局。

不承諾排名與流量；承諾的是一套可以重跑的判斷。把對產業與受眾的第一手判斷，跟模型的攤開與審查產能結合，這個組合比任何一方單獨做事都可靠。本季就能跑的第一步：打開報表，把症狀分診那一格填掉。