AMP真的還能改變SEO遊戲規則嗎？
AMP到底還是不是SEO圈裡的那把無敵鑰匙？Jot總會在討論時突然拋出這種問題，Mina聽了也只能苦笑。近幾年，好像大家都覺得只要掛上AMP，排名就會跟著飛升，可是，是不是太理想化了？有人說競爭者一窩蜂導入後，紅利其實沒剩下多少；但也有人認為，只要速度快一點，用戶不跑掉，本來就是賺。可是，如果只是追求表面速度，忽略了內容該有的靈魂，那還算什麼優勢嗎？更別提Google演算法好像每隔一陣子就有新花樣，到底AMP現在的地位在哪裡——或者早已不是過去那個萬用答案？這種問題真的很難一下子講清楚。
隨著技術普及，AMP的優勢是否仍然明顯？
Jot其實早就注意到，2023年那一輪AMP測試資料裡，行動頁面載入速度確實快了不少，尤其是在網路不太穩的時候，用戶要離開的機率明顯降下去，大概少了將近一半這麼多。但另一方面，有些數據又讓人有點摸不著頭緒。像是Google Top Stories區塊，原本以為AMP普及會帶來更多曝光，可後來成長反而停在原地，有幾個月甚至還往下掉了一些。這種現象不是只有Jot遇到，好幾個內容團隊的成效報告也出現類似走勢——速度提升沒錯，搜尋結果裡的能見度卻沒有預期中拉高。有人猜跟演算法微調、大家都用AMP有關，也許優勢被稀釋掉了吧。當然，這樣的變化到底能不能直接歸咎於AMP本身，其實很難說清楚，只是數字擺在那裡，又不得不正視。
Comparison Table:
| 步驟 | 描述 |
|---|---|
| 整理舊網址 | 將所有舊有網址進行整理，避免漏掉邊角料頁面。 |
| 加上雙向標記 | 使用 rel=`amphtml` 和 rel=`canonical` 互相對應，確保正確的上下行方向。 |
| 樣式隔離 | 利用 Critical CSS inliner 等工具抽取關鍵樣式，但需注意小地方的修正。 |
| 路由分流 | 依據不同裝置與情境設定策略，Cloudflare Workers 可協助進行路由分流。 |
| 搜尋引擎收錄檢查 | 定期檢查搜尋引擎的收錄狀態，有時需手動推送索引或調整快取設定。 |
強制結構化規範讓內容失去個性了嗎？
說起AMP，Jot總會想到那些年寫文件、調整版型時的無數小插曲。有一回，他印象特別深刻——好像是某個下午，團隊裡將近一半人都在對著console發愁。官方文檔只輕描淡寫提過結構規範，但實際上，那種千篇一律的框架讓每個頁面幾乎複製貼上，用戶很難分得清這是哪家的內容。Mina那時還試過加自定義元件，不過最後不是被強制移除，就是顯示怪異。真要說副作用，大概就是原本有點味道的文章變成了流水線產品吧。偶爾有人問，是不是快樂地用AMP？其實也談不上，反正換來的是速度，但失去了辨識度。不知怎麼，這事兒後來也沒誰再主動提起，只剩下技術債在那裡靜靜堆積——大概就是這樣混亂又真實的一段經歷。
追求速度的代價：用戶互動體驗如何受到影響？
如果要把AMP形容成什麼，大概就像那種速食店吧。餐點端上來特別快，幾乎不用等，不知怎地，大家一陣子都覺得這樣最好。不過仔細想，其實每個顧客拿到手裡的漢堡、薯條，好像都長得差不多，有時候還會搞錯是哪家的。你說吃得快好不好？可能有些人本來就只是路過，要趕車或忙著滑手機，他們當然開心。但慢慢地，好像也有人開始覺得——是不是太沒特色了啊？桌面乾淨但冷清，用餐區裡幾乎沒人久留，話題一下子就散掉。速度是有了，可回頭看，那種味道、記憶，大概只剩下那張收據還在口袋裡。
五年回顧後，業界對於速度的信念是否過於理想化？
五年過去，Jot偶爾會回想當時業界幾乎一窩蜂擁抱AMP的熱潮。那陣子「速度等於勝利」這種說法，幾乎沒有人懷疑過。後來的情勢似乎有點變了──原生網頁技術悄悄進步，甚至在某些指標上追平或超車AMP，有些人可能覺得很突然，但也不是完全沒有跡象。其實一開始大家對維護成本預估太樂觀，直到後來才發現每多維護一組AMP版本，開發與營運上的瑣事就像雪球越滾越大，有團隊形容比起省下的那些首屏秒數，背後多花了將近一半的人力在處理各種兼容和調整問題。有意思的是，那些Web Components應用場景本來被寄予厚望，但為了配合AMP很多都被犧牲掉。現在回頭看，不免要問——是不是我們當年把它神話了一點？
如何有效解決AMP與傳統頁面共存時的樣式衝突問題？
說到讓傳統頁面和AMP版本能夠不打架地共存，Jot和Mina好像有點各自的步驟，雖然順序常常記錯。首先，大概得先把所有舊有網址整理出來，這個動作有時候容易漏掉邊角料頁面。然後應該是加上雙向標記，就是那種rel="amphtml"跟rel="canonical"互相對應，不過細節常常有人搞混上下行方向。第三步差不多是在樣式上做隔離——大致就是Critical CSS inliner之類的工具幫忙抽取關鍵樣式，但偶爾會發現有些小地方還是跑版，好像永遠修不完。第四步，其實要考慮路由分流，Cloudflare Workers這類東西派上用場，有時候還得因應不同裝置判斷切換，不一樣的情境下策略也變來變去。最後一步，通常是針對搜尋引擎收錄狀態定期檢查，有時候必須手動推送索引或調整快取設定，也不是每次都能第一時間發現問題。有的人會覺得這流程太繁瑣，但其實只要抓住大致脈絡就不太會失控，剩下就是反覆調整而已。
混合架構能否真正滿足不同終端用戶的需求？
其實，對於AMP的這些利弊，Jot和Mina也不是沒有猶豫過。好像每次討論到這裡，總會有那種「難道就真的只能二選一嗎」的感覺。雖然大家都說速度很重要，但只要稍微觀察一下，有些網站流量提升幅度有限，大概只是比原本多了七十多的曝光而已，不見得值得那麼大陣仗改版。而且，有時候資料顯示AMP在行動端跳出率確實下降，可是用戶反饋卻又沒什麼明顯變化，這點還滿讓人困惑。等到技術紅利逐漸被消耗殆盡，原本那些亮眼的數據也慢慢平淡下來。可是話說回來，就沒有辦法同時兼顧速度與體驗嗎？混合式方案似乎悄悄地浮現成為折衷路線，或許，比起單一路徑，這種彈性調整更符合現實需求，只是怎麼做才不會兩頭落空，又是一門學問了。
遇到收錄異常，我們該怎麼應對才能不慌張？
AMP頁面偶爾就是會搞出奇怪的收錄狀況，像是那種本來好好的頁面突然在Google索引裡消失，Jot說這問題其實不少工程師都遇過。據說有些人會先調整緩存時間設定，但也不是每次都靈驗，有時候得靠手動推送一次站點地圖才會慢慢恢復。還有人用一套小工具，把重複的canonical標記修正掉，大概能挽回七成左右的異常案例吧。Mina提到，其實這幾個急救包不見得完全有效，不同網站情境下差距挺大。不過大家碰到收錄消失，好像也只能暫時先這樣應急，等後台數據穩定下來再說。
AB測試在尋找最佳方案中有多重要，不妨來看看！
「可是我們流量主要來自社群啊！」Mina突然插話，她說這句時，Jot好像也微微點頭。那次AB測試，印象裡是把一組頁面保留傳統格式，另一組上了AMP，結果有段時間數字變動特別詭異——社群來源的點擊率大概有將近一半落在非AMP那邊，反而Google搜尋進來的跳出明顯降低了。Jot皺著眉補一句：「可能跟瀏覽器快取和分享機制有關吧？」Mina好像想說什麼又沒講出口，只丟下一句：「每個平台規則都不太一樣，有時候重複測幾次還會跑出新花樣。」場面靜了一下，大概誰也說不準哪種才穩定。
技術選擇背後，其實是人心的微妙變化，你準備好了嗎？
深夜的辦公室裡，燈光總是比外頭亮一些。桌上散落著幾杯沒喝完的咖啡，螢幕邊緣還貼著前陣子忘了撕掉的小紙條。Google Search Console那條曲線有時像心電圖，起伏不定，有一兩次甚至跳到將近一半又突然掉下來。旁邊Jot隨手翻動手機，好像在查什麼參考資料，其實注意力大多還停留在那個圖表上。偶爾有數字閃過，七十多、八十不到的那種增長幅度，但也只是過眼雲煙。空氣裡瀰漫著機械運轉的聲音，有點像某種低頻白噪音。有時候Mina會喃喃自語，不確定是和自己對話還是在回想哪個案例——大部分時間，只剩下曲線與時間交錯流動而已。
