AMP 該不該導入？四道診斷關卡與安全退場時機

週一晨會，老闆滑著手機把一個網址放上投影幕：對手的行動頁面掛著一個閃電圖示，聽說叫 AMP，我們要不要跟？會議室通常會安靜半晌，因為沒有人確定那是什麼，也沒有人敢直接說不需要。

同樣的問題也出現在後台報表前。行動裝置帶走了大宗流量，詢問單卻一直起不來，有人丟一句「是不是該上 AMP」，背後的假設是裝了就會快、快了詢問就會來。這個假設前半段只對了一半，後半段從來沒被驗證過。

第三種人最安靜：接手舊站，發現後台躺著幾年前裝的 AMP 外掛，同一篇文章兩組網址，canonical 指來指去，沒有人敢動，也沒有人說得出口為什麼還留著。三種人問的是同一件事：AMP 到底還要不要？你不缺名詞解釋，缺的是一個能帶進會議室、對老闆與客戶交代的判斷流程。接下來先把 AMP 的禁止清單拆開，再過四道可驗證的關卡，結論自己會浮出來，你可以算出答案，不必背任何人的結論。

快速重點：AMP 的快不是魔法，是一串禁止規則換來的：受控元件、75KB 樣式上限、頁面不得直接執行自訂腳本；紅利分兩步退場，2021 年取消專屬門票與排名優勢，2026 年七月搜尋不再代發快取頁。四道關卡檢核互動、網路、維護與 Core Web Vitals，導入、替代、退場三種結局自然浮現。

開始判斷之前：AMP 不是加速器，是一份禁止清單

AMP 全名 Accelerated Mobile Pages，2015 年由 Google 發起的開源規格，用來規範行動頁面的 HTML 寫法。它最反直覺的地方在這裡：翻遍整份官方規格書，找不到任何一段加速程式碼。它給你的是一張安檢清單：哪些不能帶、哪些不能做；速度是遵守禁令之後的副產物。

清單上有三條鐵則，AMP 官方網站與運作原理說明都寫得明白。第一，頁面不能直接執行作者自寫的 JavaScript：輪播、圖片、影音、嵌入內容原則上全改用官方預先審核過的元件，自訂程式只能走 amp-script 這類在受限沙盒裡執行的例外管道，能力與容量都有上限。第二，自訂樣式集中在一個規格指定的 style amp-custom 區塊，上限 75KB，符合規範的行內樣式另依規則處理，坊間流傳的 50KB 是舊說法，現行規格就是 75KB。第三，外部資源全程受限，廣告、字型、追蹤碼都走受控管道載入。

三條鐵則各有一個實際後果。元件管制等於把頁面能做的事寫死在清單上，清單有的功能做得又快又穩，清單沒有的原則上就是沒有；樣式上限逼你只留真正會被瀏覽器用到的規則，佈景主題裡那些複製貼上來、從來沒人驗收過的 CSS 全要清掉；資源管制則讓廣告與追蹤不能再自行其是，連載入順序都被規格排好。三件事單獨看都不難，難在它們是強制的，你沒有選擇不做哪一條的權利。

把這份規格看成一座入場安檢門，它的歷史就好懂了。前面三條是你自己抄得走的紀律：受控元件、75KB 上限的內聯樣式、擋在門外的自訂腳本。歷史上還有第四層紅利：通過驗證的頁面曾被收進 Google 的 AMP Cache，由 Google 的伺服器預先快取，再從搜尋結果代發，那是當年大批網站衝著導入的主因。這層紅利已經走到終點：2026 年七月起，Google 搜尋不再從 AMP Cache 代發頁面，點擊直接連到發布者自己的網域（Search Engine Journal 的報導記錄下這一轉變）；對排名而言，AMP 自 2021 年起就不再有專屬優勢，快取也更不是決定排名的因素。

退場有明確的時間點。2021 年八月，Google 發布AMP 頁面遷移公告，熱門新聞區塊不再只收 AMP 頁面，任何達到網頁體驗標準的頁面都能進場，AMP 從門票變成眾多路線之一。2023 年十月行動優先索引全面到位，行動版就是所有網站的主版本，特殊規格的存在理由又少了一條。

這段歷史為什麼值得知道？因為它解釋了 AMP 的名聲從何而來。熱門新聞區塊在手機搜尋結果的最上方，是整頁最容易被點擊的位置，對搶時效的媒體來說，進不進得去往往決定一篇文章的第一波流量。當年那個區塊只收 AMP 頁面，等於搜尋引擎開了一條專屬通道，大家是為了門票才導入，不是為了速度本身。門票取消之後，留下來的理由就必須重新算一遍，這正是接下來四道關卡要做的事。

順手修正兩個還在流傳的過時說法。樣式上限是 75KB，不是傳了很久的 50KB；AMP 頁面在任何現代瀏覽器都能開啟，不存在只在 Google 搜尋能用的限制，它是一種頁面格式，不是某家搜尋引擎的專屬通道。

裁決先給你：AMP 是速度工具，不是排名工具。Google 演算法看重的是整體頁面體驗與內容品質，速度只是其中一環，而且不專屬於任何格式；速度如何影響Google 排名，值得先讀懂脈絡再談框架。正因為如此，「要不要 AMP」對多數網站不是知識題，是決策題，答案隨頁面條件而變。判斷的骨架如下：互動複雜度決定你有沒有資格進場，讀者網路決定速度紅利有多大，維護資源決定你付不付得起入場費，Core Web Vitals 實測決定這一切值不值得。想先補速度基礎的，網頁速度與 SEO的關係是另一條主線。

先對號入座：三種最常見的 AMP 糾結

四道關卡有順序，但三種人的起點不同，先對號入座，別把流程走反。

• 被要求跟進：會議裡出現「對手有、我們要不要有」的句式。從關卡一開始，先盤互動功能，再談其他。
• 還在觀望：行動流量大、速度問題有感，但沒人逼你表態。先跳關卡四，用網站速度測試與Search Console把主力頁面的數字看滿，量測會先替你淘汰一半選項。
• 手上已有 AMP：雙版本網址加一套幾乎沒人維護的外掛。不必從頭走，直接以結局 C 的體檢清單起手。

三種人的共通點：不缺名詞解釋，缺一份能放上會議桌的檢核流程。接下來每一關都附判準與證據來源，走完會拿到三張結局卡的其中一張，每張卡上都有一個今天就能做的第一個動作。

關卡一：你的頁面有多少離不開 JavaScript 的互動？

這一關是淘汰制，先看什麼會被擋在門外。購物車與結帳流程、即時試算、地圖客製、互動圖表、會即時驗證的複雜表單，這類功能都靠自由執行的自訂 JavaScript 運作，而頁面直接跑自訂腳本正是 AMP 的第一條禁令；amp-script 雖然開了一道沙盒側門，也只裝得下輕量互動，塞不下整條結帳流程。第三方小工具也一樣：業務窗口給你的那段嵌入碼，只要會注入規格外腳本，整頁驗證就過不了。

能活下來的是受控替代品。圖片、影音、輪播、社群嵌入、部分表單，官方元件庫有對應版本，功能可用，但行為被規格限定，超出清單的互動原則上做不了，僅有的 amp-script 例外也只裝得下輕量邏輯。替代品的行為也和原版有落差：輪播的動畫時間、表單的即時驗證、地圖的客製圖層，細節愈講究的互動，換成元件後失去的部分愈多。判斷方式很具體：把主力頁面的功能逐一列成清單，逐項問「它離得開自訂腳本嗎」，清單上超過一半打叉，這一關就出局；只有一兩項打叉，再看那幾項能不能用單獨的子頁面或外部服務承接，而不是整站陪葬。

互動功能的商業角色要想清楚。報價即時算、規格即時比、尺寸即時換算，這些常是詢問與成交的載體，把它們砍掉換速度，等於拆掉著陸頁轉換的引擎去換輕量。如果你的網站靠表單與詢問單吃飯，先讀提升網站詢問量的結構，再回來考慮要不要為了格式限制動它。

用一個標示為假設的情境示範判讀。假設一間系統家具業者，官網放了一台報價計算機，訪客選完板材、尺寸、五金，頁面即時算出價格區間，大多數詢問單從這台機器進來。換成 AMP，這台機器直接出局，只能改留規格說明、請客戶來信詢問，頁面變快了，詢問的入口也跟著變窄。這一關的答案，取決於你敢不敢賭訪客願意多寫一封信。

還有一條中間路線常被忽略：把重互動的功能搬出去，讓閱讀頁自己變輕。報價工具獨立成一個子頁面，產品頁放一顆按鈕連過去；客製地圖改用外部服務的嵌入或分享連結；即時比較表換成可下載的規格表。這樣調整的用意，是讓兩種頁面各守本位：來讀資料的人拿到輕量版面，要操作的人走完整流程，功能沒有消失，只是換了位置。盤點功能時多問一句「這項互動一定要跟內容長在同一頁嗎」，關卡一的淘汰範圍往往就會縮小一圈。

關卡二：讀者用什麼裝置與網路打開你？

AMP 的速度紅利不是均勻分布的。同一個輕量頁面，在旗艦手機與固定網路下，和一般頁面的差距有限；差距被放大的場景很特定：通勤車廂裡的弱訊號、尖峰時段的擁擠基地台、網路建設較慢的市場。行動裝置約佔全球網頁流量六成（Statista 的長期統計），但六成是平均數，你的讀者落在哪種網路條件，要用自己的資料回答。

證據就在後台。打開GA4 網站分析，看三個數字：行動工作階段占比、熱門時段分布、地理區域分布。流量集中在通勤尖峰、或主力讀者所在區域的網路條件偏弱，慢網路情境就成立，這一關續審；讀者多在穩定網路環境造訪，速度差距本來就小，這一關提前出局，改走結局 B。看資料時把報表期間拉長到三個月以上，單週的波動會誤導判斷；也要記得 GA4 記錄的是造訪發生的當下，不是訪客真正的頻寬條件，把它當方向證據，不要當精準測量。量測容器沒裝好的，先對照GTM 與 GA4 的設定把基礎弄準，再談判斷。

速度問題的觀察指標裡，跳出率常被拿來當代名詞，但它只能告訴你有狀況，說不出原因。行動流量高、跳出高，可能是速度，也可能是內容與搜尋意圖不匹配，先量測再歸因。這一關的紀律只有一條：用資料過關，不用印象過關。

地區資料可以替網路判斷補上第二個證據。後台的區域報表若顯示造訪集中在特定地區，而當地基礎建設普遍較慢，慢網路情境就多了一分把握；讀者多在都會區、又以 Wi-Fi 造訪為主，輕量頁面的邊際效益自然有限。順帶拆掉一個誤讀：流量高峰時段與網路最差的時段未必重疊，通勤尖峰與深夜的頻寬環境是兩回事，把時段、地區與跳出三者對著看，方向才會站穩。這一關的所有判斷都建立在自家報表上，別拿產業平均值替你的讀者發言。

關卡三：誰來長期照顧這套嚴格規格？

AMP 不是裝完就結束的工程。每次改版都要重跑驗證，樣式被迫精簡在 75KB 的單一區塊裡，佈景客製越多的站被砍得越痛；雙版本網址則讓 canonical 維護變成常態工作，標準頁改了版面，AMP 頁要跟著對齊，漏了一步，兩個版本的內容就開始漂移，讀者看到的新聞日期不一樣、價格不一樣，都是雙版本站真實會發生的事。外掛生態也在縮減，投入的社群變小、規格同步變慢、第三方支援跟著退潮，這些風險不會出現在導入當天，會在半年後的某次改版才浮上來。

維護資源的盤點就三問：誰跑驗證？誰解決錯誤？誰在半年後還記得這套規格？三問都答得出具體人名，這一關才過；答案是人人都很忙，這一關直接淘汰。也要把「驗證失敗的代價」算進去：不合法的 AMP 頁面不會被當成 AMP 處理，等於你付了雙版本的維護成本，卻拿不到格式的效果，這種情況在沒人盯的網站上可以默默存在好幾個月。

把維護寫進流程，比仰賴任何人的記性可靠，具體可分三段。部署前在測試環境跑一輪驗證，讓它成為上線檢查表裡的一格；外掛與佈景更新後抽幾個代表頁面複驗，相容性問題多半在更新之後才浮現；每季把驗證結果歸檔，接手的人看得到歷史，不必重新摸索。三段都不難，難在排進行事曆；排不進去，等於承認這套規格沒人照顧，關卡三的答案其實已經寫好了。

同樣的預算還有別的買法。把工程時間換成WordPress 快取外掛、WP Rocket 這類整合型工具，或把主機類型往上提一階，對多數中小網站的速度改善更直接，而且完全不動你的互動功能。條件式比較很簡單：當替代方案用一半的維護成本達到接近的速度，AMP 的入場費就貴了。哪些工具值得放進基礎建設，可以對照WordPress 必備外掛的挑選原則再決定。

關卡四：規則書與計分板，Core Web Vitals 及格了嗎？

進這一關之前，先分開兩個常被當成同一件事的名詞。

把層級關係一次講清楚：AMP 是一份技術規格，角色像規則書，規定頁面能用哪些材料、不能帶哪些東西進場；Core Web Vitals 是一組使用者體驗指標，角色像計分板，量的是訪客實際感受到的載入速度、互動反應與版面穩定。規則書管蓋法，計分板量結果，兩者層級不同；照規則書蓋完的頁面，計分板仍然可能不及格，完全沒照規則書蓋的頁面，計分板也可以全綠。

計分板上的三個數字先認識（定義與門檻見 web.dev 的指標說明）：LCP 最大內容繪製，量主要內容載完的速度，門檻 2.5 秒；INP 互動到下一次繪製，量點擊後的反應靈敏度，門檻 200 毫秒；CLS 累計版面位移，量頁面跳動的程度，門檻 0.1。想系統性弄懂，Core Web Vitals 完整教學是比任何框架都值得先讀的地圖。

量測入口就在手邊。Search Console 的 Core Web Vitals 報表直接把站上頁面按紅黃綠分組，實戰讀法可對照Search Console 使用技巧；先看顏色，再決定要不要考慮框架。量到的數字比任何框架名稱可靠，規格合法也不等於體驗及格。

讀報表還要分清楚兩種資料。實場資料來自真實訪客的造訪，反映的是實際網路與裝置下的表現；實驗室資料來自工具的模擬環境，變因固定、好重現，但不等於任何一位真實訪客的經歷。判斷要不要導入、要不要替代，以實場資料為準；找具體病因、修單一頁面，用實驗室資料反覆量。兩種資料混著讀，是這一關最常見的錯誤。

三個數字背後各有常見病因，先記方向就夠。LCP 慢，多半是大圖、慢主機、快取失效；INP 慢，多半是主執行緒被一堆腳本佔住；CLS 高，多半是圖片沒標尺寸、字型替換時版面跳動、動態插入的內容把版面推開。病因清單和 AMP 沒有綁死，標準網頁一樣會犯，這正是結局 B 那張對照表的由來。

補一個實務細節：複測時挑中階手機，別只用桌機或旗艦機。分組報表來自真實訪客，使用的裝置光譜很寬，開發者手上的設備往往落在光譜最好的一端，修復成果若只在旗艦機上看得到，等於只照顧了少數訪客；找一台兩三年前的中階機實際打開頁面點一輪，得到的感受會比報表上的綠色更誠實。

速度本身值得經營，證據一直都在。Google 從 2018 年就把速度納入行動搜尋訊號，2020 年再以網頁體驗評估把體驗指標正式納入排名參考；產業研究也一再指向同一件事，手機頁面載入拖長，訪客跳出的機率跟著上升（Think with Google 的行動速度基準整理了這組資料，web.dev 對速度與流失的說明寫得更直白）。這些數字講的是趨勢，不是對單一網站的保證，但方向一致：速度先影響訪客去留，訪客去留再影響一切。

如果你的起點是觀望，走到這裡多半已經有答案：多數網站這一關的結論會指向結局 B，把預算直接花在計分板上。往下一節走，對照三張結局卡確認。

關卡走完，你是哪種結局：導入、替代，還是退場？

四道關卡的本質，是在算一個淨值：殘餘收益減去維護成本。AMP 還給得起的收益剩三項，輕量廣告生態、慢網路下的載入差距、架構級防呆；成本是互動彈性、長期維護、雙版本的隱性帳。算式的兩邊都不是固定數字，會隨你的頁面條件浮動，所以不該有任何一張產業標籤直接替你回答。把四關結論放進來對照：

• 四關全過，結局 A：頁面幾乎純閱讀、讀者網路偏弱、有明確維護人力，而且 Core Web Vitals 還沒及格。少數站會落在這裡。
• 關卡一或關卡三出局，結局 B：互動砍不得，或沒有人能長期照顧規格。把禁止清單抄回家自己做，多數站在這裡。
• 手上已有 AMP 版本，結局 C 起手：無論當年為何導入，先體檢標準頁，再決定去留。

三張卡各附第一個動作：A 是跑相容性測試，B 是建立三指標基準線，C 是標準頁體檢。無論抽到哪張，網站的長期競爭力都不繫在單一框架上，而在整體技術 SEO的體質，這是三張卡背面同一行字。

結局 A：仍值得導入的少數站，與入場費明細

通過四關的站通常長同一個樣：內容以閱讀為主、營收靠廣告、讀者網路條件偏弱，而且團隊養得起維護人力。對這些站，AMP 還給得起三樣東西：AMP Ads 輕量廣告格式讓廣告本身也走輕量載入；慢網路條件下的載入差距；以及架構級防呆，讓頁面不會被失控的外掛拖垮。

入場費從網址形態算起，這是最多人輕忽的決策。官方AMP 外掛用「幾組網址」來分模式：Standard 是整站單一版本，沒有雙版本問題，前提是佈景與所有外掛完全相容，一個不相容功能就掛；Reader 另生一套獨立 AMP 外觀，官方把它留給佈景高度不相容、沒有技術資源處理相容性、或只想用簡化流程快速產出的站，代價是 AMP 版外觀與標準版脫鉤，等於多養一個網站；Transitional 同一佈景輸出兩組網址，是漸進路線，但雙版本的隱性帳全數保留，canonical 設錯的風險、多一份頁面吃爬取預算、GA4 與 GTM 的追蹤維度受限。形態由相容性測試決定：在測試環境把佈景與外掛全開跑一輪，逐頁檢查表單、結帳、輪播、追蹤事件有沒有壞，能全相容才談 Standard，否則 Transitional，再不行就回到不導入。第三方AMP for WP主打一鍵生成與現成行動版面，設定負擔小，代價是規格同步較慢、複雜佈景下出狀況的機會較高，兩者是條件式取捨，不是誰取代誰。全球超過四成的網站使用 WordPress（W3Techs 的統計），這段形態選擇因此是多數站長實際會遇到的版本。

雙版本的隱性帳值得攤開來看。搜尋引擎面對同一篇文章的兩組網址，需要靠 canonical 與連結標記理解誰是正本，設定錯一次，收錄與流量就開始分岔；爬取預算被兩套頁面分食，頁數多的站感受更明顯；分析工具在 AMP 頁上要改用規格內的計數方式，事件、維度、再行銷名單都可能有缺口，行銷團隊拿到的報表因此出現盲區。這些成本都不會出現在安裝外掛的當下，會在第一波活動檢討時才被發現。

第一次導入不必把全站押上去。挑一種內容類型試行，例如只做文章頁，商品頁與結帳流程維持原樣，跑一個月再攤開數據：兩個版本的載入表現、跳出與停留，有廣告收益的站再加一欄收益對照。試行的價值在於把爭論變成紀錄，一個月後團隊看的是同一份報表，討論自然回到數字上。數字不理想就停在試行規模，損失有邊界；數字支持再擴大，推進的節奏也站得住。

驗證是入場後的例行工作，按生命週期分三段。開發階段，在頁面網址後面加上 #development=1，打開瀏覽器的開發者工具，驗證結果直接列在主控台，適合邊改邊查。上線前，把網址交給官方驗證器，取得完整違規清單。上線後，用 Search Console 的 AMP 報表長期監控，被排除的頁面會在報表現形，搭配WordPress 的 Search Console 設定與網址檢查工具排查更快。要點破一件事：驗證器驗的是規格，不是速度，規格全綠和訪客覺得快是兩件事。

初次導入最常撞的錯誤就三種：圖片標籤沒換成官方元件、樣式超過 75KB 上限、頁面裡殘留規格外腳本，第三種多半來自某段第三方嵌入碼。三種錯誤的排查成本不同：前兩種自己改完就過，第三種要回頭跟每一個提供嵌入碼的窗口確認有沒有規格內版本，等於把別人的時程排進你的上線計畫。抓錯照這三種順序走，能省下大半時間。兩件小事順道提醒：AMP 頁面上的結構化資料要符合官方指定的 Schema 格式；廣告與電子報另有 AMP 產品線，AMP for Email 支援可互動的郵件元件（見 Google 的 AMP for Email 說明），那屬於廣告與電子報行銷的應用，不是網站加速的議題，別混進這次的決策。

結局 B：把禁止清單抄回家，按三個指標分組執行

多數站拿到的是結局 B：不導入，把三條鐵則逐條翻成標準網頁的做法。AMP 逼你做的事，你自己也做得到，差別只在沒有安檢門強迫你。

↔ 左右捲動檢視完整表格

AMP 的限制	它逼你做什麼	標準網頁的對應做法	殘餘差距
互動只能用受控元件	腳本全面減量	移除用不到的外掛、追蹤碼瘦身、非必要腳本延後載入	紀律靠自律維持，沒有驗證器把關
樣式內聯且上限 75KB	樣式只留必要	合併與精簡 CSS、清掉沒用到的規則	沒有數字上限，樣式容易慢慢胖回去
外部資源全程受限	資源逐項過秤	圖片改現代格式並壓縮、字型本地化、加上快取與 CDN	每次改版要自己重盯一輪

抄完之後，真正抄不走的只剩兩樣：歷史快取層（已退場）與 AMP 廣告生態（只對廣告營利站有意義）。對非廣告營利的網站，這張表最右欄其實沒有實質損失。

執行順序按計分板分組，弱項先做。LCP 組：圖片是最大嫌疑，改用現代格式並壓縮，工具挑選看圖片壓縮工具與Smush 這類 WordPress 外掛的比較，圖片的搜尋層處理再對照圖片 SEO 優化；主機回應與網站快取、CDN（觀念可見 Cloudflare 的 CDN 解釋）是第二順位。INP 組：JavaScript 瘦身，移除、延後、非同步三招輪流用，配合延遲載入把非必要腳本挪出關鍵路徑。CLS 組：圖片明確標示寬高、字型本地化，版面就不跳。每做完一組就回測一次，數字沒動再修下一項，形成閉環；整套工程在WordPress 速度優化與網站速度優化指南有完整展開，舊站慢的病因排查則看網站速度慢的修復。

這張表還有一個長期用途：當成改版的驗收單。AMP 的價值在於規格逼你守住底線，自家的版本沒有安檢門，就用表上的欄位自己設關卡，每次新增外掛、換佈景、加追蹤碼之後，把三個指標重測一遍，退步就回頭檢查。紀律是可以設計的，不一定要靠一套框架替你執行。

自組版本有兩個常見陷阱值得點名。一個是只挑軟的做：圖片認真壓了一輪，腳本一個沒動，LCP 進步、INP 停在原地，就下了「優化無效」的結論；另一個是把快取當萬靈丹：瀏覽器快取照顧的是同一訪客的重複造訪，共享 CDN 快取雖能讓初次上門的人拿到別人暖好的內容，主機回應與腳本數量仍決定第一口速度，這筆帳終究要清。控制變因的做法很樸素：一次只動一項，動完就複測，數字記進同一份表；兩三輪之後，哪個手段對你的站真正有效會自己浮出來，不必照別人的心得照單全收。

同一張表，不同網站走出的順序不同。假設一家食記部落格與一間接單客製的烘焙工作室同時用它：部落格的文章頁照片多、互動極少，LCP 組先做，圖片壓縮加快取，分數就有感；工作室官網頁數少、圖也不多，首頁卻有客製詢問表單與作品輪播，INP 組反而先做。情境是假設的，示範的是讀表方式：先量測、按弱項排序，不照別人的清單順序照抄。

速度是地基，鋪好地板還要能互動。響應式網頁設計、可點擊元素的間距、避免蓋版橫幅，這些行動版體驗的細節把速度的地基變成真正的往來，做完這層，結局 B 的收益才算收滿。

結局 C：既有 AMP 站的退場評估與拆除順序

退場這件事，原則只有一條：先證明標準頁離開 AMP 也站得住，再談拆除。

在拆掉 AMP 之前，先檢查標準頁的功能、速度、索引與 canonical，並用 Core Web Vitals 的實測資料比較兩個版本，而不是憑 AMP 版的成績想像標準頁的體質。跳過體檢直接停用外掛、刪掉頁面，常見的代價是舊網址失效、canonical 指向錯亂、重新導向沒有接好；退場後若流量下降，先回頭比較索引數、查詢表現與頁面體驗資料，找出真正的原因，別把帳記在拆除這個動作上。

1. 量測並補強標準頁：用實測工具跑標準版網址，三項指標先過門檻；沒過就先把圖片、快取、腳本的基本功補齊，別急著拆。
2. 整理訊號：確認標準頁的 canonical 指向自己，檢查方式見canonical 網址設定；amphtml 宣告與連結標記列出清單，下一步一併移除。
3. 停用並轉址：停用 AMP 外掛，把 AMP 網址 301 轉向對應的標準版，同時把 sitemap 裡的 AMP 網址清乾淨再重新提交，XML sitemap的設定與sitemap 教學可對照檢查。
4. 監控兩到四週：盯Search Console 索引報表的收錄變化與點擊趨勢，AMP 網址的數量應該逐步歸零、標準頁的收錄應該接手；發現異常排除，先查轉址與訊號，再找其他原因。

監控期的判讀有先後。先看 AMP 網址有沒有從索引退乾淨，再看標準頁的曝光與點擊有沒有接上，整體流量數字排在第三順位；順序顛倒，容易把搬遷期的正常波動誤判成事故。兩到四週的長度不是隨機定的，索引更新的節奏需要時間，太早下結論只會逼團隊做無謂的回滾。

日曆也該排進退場計畫。搬遷期就算一切順利，數字仍會抖一陣子，避開流量最旺的時段再動刀，解讀壓力會小很多：電商避開購物檔期，媒體避開大事件週，季節性明顯的站挑淡月處理。時機挑得好，波動落在可解釋的範圍，團隊不必在雜訊裡做決定，這是成本最低的風險管理。

拆除的細節以 Google Search Central 的「移除 AMP 網頁」文件為準：重點是三個操作，移除標準頁上的 amphtml 宣告、把 AMP 網址重新導向到標準版、確認 canonical 指向收乾淨。官方同時提醒，退場後要持續觀察索引與流量；這份文件給的是搬遷步驟，不是排名不變的保證，數據要自己盯到平穩為止。

退場的副作用清單也先給你。雙版本時期留下的重複內容疑慮、多一份頁面消耗的爬取預算、轉址漏接產生的404 頁面，三項都處理掉，退場才算乾淨。照順序走的退場通常過程平穩，跳過第一步就動刀的站出狀況機會較高；這是作業上的經驗觀察，不是結果保證。索引狀態的確認，收尾用Google 索引檢查再點一遍。

把結論帶回會議室，也帶走一把尺

決策要能帶出會議室才算完成。做一頁摘要：三項指標的基準線、四道關卡的結論、下一步與期程，帶數據不帶形容詞。三個常見的反對意見，各配一句回應：

• 「別人的網站有用 AMP」：回對方的網站條件，不回框架名稱；拿對方的互動功能與自家實測數字對照，條件不同，結論本來就會不同。
• 「快就是好，裝了不吃虧」：快有代價，代價是互動彈性與維護工；把關卡三的盤點結果放上桌，成本就不再是形容詞。
• 「拆了排名會不會掉」：官方文件寫的是搬遷步驟，不是保證；體檢先過、轉址接好、數據盯滿，風險就有邊界。

帶走的那把尺是三個問題：它強迫你做什麼？哪些你能自願做？剩下不能複製的部分值多少？多數效能框架的魔法，拆開後都是你可以自己做的基本功；Backlinko 的排名因素研究也指向同一個趨勢，整體頁面體驗、內容品質，比任何單一技術規格都更能解釋排名差異（研究觀察的是相關趨勢，不是因果保證）。同樣的判斷法，比記住任何外掛名字耐用。

回到開場三種人。被要求跟進的，把主力頁面的功能清單列出來，用關卡一逐項打勾；還在觀望的，打開測速工具與 Search Console，把三個數字記成基準線；手上有 AMP 舊站的，從標準頁體檢開始，照結局 C 的順序走。答案不會來自框架，會來自你自己的量測；量測做完，該導入、該替代、該退場，你會比會議室裡任何人都清楚。之後無論走哪條路，頁面 SEO 優化與點擊率優化都會是下一批值得排進行事曆的工作。