AWS網站架構提升SEO成效，工程師與行銷協作新模式

AWS與SEO的模糊邊界：從工程師到行銷怪咖

# 11 種運用 AWS 進行 SEO 的方法

### 探索如何利用 AWS 雲端運算服務來進行 SEO。

![圖片來源：[Vexels]，來自 [FreeImages.com]]

_唉，其實我人在 AWS 做 SEO 的時候，總是會被問到各種雲端工具怎麼跟 SEO 扯在一起。內容純粹個人經驗啦，只能說，每次想到這些，真的有點累。_

嗯，有時候打開社群媒體或論壇，看到不少技術型的 SEO 人員，都愛自己寫什麼爬蟲、然後又搞什麼實體匹配、主題分群啥的，但你很少聽到有人直接提「我們用 AWS 在做這件事」——不知道為什麼，大概他們覺得這好像沒啥新鮮感？（欸，我突然想到上次和朋友討論，他還以為 AWS 是拿來備份照片的。）

回頭講正事，其實工程師們蠻常用 AWS 搞一堆東西的，我以前還沒到現在這家公司前，也斷斷續續摸過幾個 AWS 工具，不過老實說，如果你本身不是工程背景，就會開始懷疑：「蛤？我的網站架在 AWS 上，那到底要怎樣才能真正活用它？」有的人乾脆放棄了。但話說回來，畢竟我現在卡在同時管 SEO 跟一堆 AWS 服務，所以碰觸這塊的次數也多得離譜。啊，有時候想偷懶都難。

反正下面就當作抒發吧，順便整理一些可能把 AWS 拉進日常工作的思路。不一定每個方法都適合你，可是如果願意花點時間自己動手弄（或拉工程夥伴一起），大概公司也可以省下請外包廠商處理類似功能的錢啦。有點碎念——其實連我自己都還在摸索怎麼讓雲端資源幫忙加速 SEO 任務，每天學新的東西真的很不容易，好吧，就先分享到這兒。

Lambda監控標題跟H1，錯誤警報怎辦？

從某種意義上說，網頁工程的那些常見最佳實踐嘛，其實和SEO最佳實踐基本上重疊得差不多啦。嗯，這樣講是不是有點偷懶？但真的，理論上我如果想寫AWS相關的內容，可以把幾乎所有服務都搬出來，然後東扯西拉地說它們怎麼優化網站速度、效率什麼的。唉，有時候會覺得自己是不是在兜圈子。不過話說回來，純粹從SEO角度去思考，好像還是有幾種比較獨特的做法值得聊一聊吧。這篇文章就是想圍繞這塊打轉——就先這樣開始好了。

### AWS Lambda

欸，AWS Lambda其實挺好玩的。有些人會拿它來監控網頁變動，用法有點類似Versionista那種工具啦，也像ScreamingFrog排程爬蟲或ContentKing那些東西，就是負責偵測一些細微的變化（像素級那種）然後發出警報。不過……我是不是講太技術了？先岔個題，我其實很討厭處理通知設置，每次都搞亂七八糟。拉回來，你可以設定用電子郵件通知自己，也可以用Amazon EventBridge定期檢查，再搭配Amazon SNS去發送提醒給團隊。

之前跟資料分析師還有工程師合作時，他們經常搞AWS Lambda加Python腳本，每隔一段時間跑ETL流程。主要是為了確保關鍵頁面模板沒壞掉——無論哪個語言、哪種頁型都一樣，就是要盯著標題標籤、meta描述、H1標籤、canonical標籤還有其他重要文字別莫名其妙消失或錯亂。記得當時遇到超詭異狀況：全部canonical標籤居然自動指向首頁（真的傻眼），還有分區語系後標題突然回到英文版，本來已經翻成日文或西班牙文的又跑回去了；甚至JavaScript連結也忘了帶HTML原本URL裡的地區參數——導致網址根本不對。

唉，其實問題就卡在這些東西沒被納入單元測試，而且現成工具也沒辦法精準抓到，所以大家老是忽略它們。那陣子觀察下來，我們自家寫的Lambda+腳本反而比什麼Versionista、ScreamingFrog排程爬蟲或ContentKing之類表現得更貼切，好像真的是「土法煉鋼」勝過商業軟體，大概吧？

Comparison Table:

工具/服務	功能	SEO 影響	注意事項
Amazon CloudFront	內容傳遞網路(CDN)	提升頁面效能和速度，特別是受眾分散時的加速效果	避免快取 robots.txt，以免搜尋引擎獲取舊資料
Amazon EC2	虛擬機器運行環境	快速部署應用程式，適合需要即時算力的場景，如運行 SEO 工具	需留意連線問題，參考官方手冊可降低錯誤率
Amazon CloudWatch	監控和警示系統	幫助監測網站效能指標，如 Core Web Vitals，提高網站可靠性	設計自動化警示以便及早發現問題
Amazon Comprehend	自然語言處理工具	分析文章內容，提煉關鍵字與主題顯著性，有助於優化內容策略	人工檢查 AI 分析結果以確保準確性
AWS Lightsail	簡易網頁託管方案	穩定且高效，非常適合小型專案或初創公司使用，提高管理效率	選擇合適方案以平衡成本與性能

機器學習和關鍵字標註那些年踩過的坑

它完全沒有誤報，說真的這點我還挺意外。其他工具就不一樣了，像是那種只要畫面有個像素改動、或者文字跟庫存狀況、預期內容有差異，就會冒出一堆警示，好煩。想當初，我們大概每季都會遇到一次重大錯誤，害搜尋整個亂掉，但現在？嗯，大約一年多都沒再發生過什麼大問題。欸，我好像講遠了——拉回來，［這篇文章］就是更細緻地去拆解怎麼用 AWS Lambda 監控 SEO 網站的選項。

對了，AWS Lambda 跟 Amazon EC2 到底哪個適合這件事？老實講之前還特別討論過這題。我記得兩者理論上都能提供運算資源啦，可是你如果仔細想一下……EC2 那種標準型，其實是「一直開著」的伺服器，需要自己打理、費用也比較高。Lambda 則完全不需要碰伺服器本身，是無伺服器架構嘛，用戶根本不用在意底層怎麼跑，而且執行一次最多15分鐘，就很靈活。不知道為什麼，每次想到 EC2 要自己維護我就累，所以最後還是覺得 Lambda 比較對味。

### Amazon SageMaker

2021年，我有試過用［AWS SageMaker GroundTruth］，把一堆關鍵字標註成品牌或非品牌，有時候又依照類別分門別類。有趣的是，資料都是靠群眾外包去標註出來，再拿結果丟給模型訓練，希望能抓住那些原始關鍵字集之外的變體。嗯，其實SageMaker GroundTruth 就是在讓群眾幫忙建立數據集之後，可以進一步讓機器學習自動把剩下的資料也貼好標籤——雖然偶爾會懷疑自動化到底穩不穩，但總比全手工輕鬆多吧。

### Amazon Q

最近啊，我又搞了一個新玩意兒，就是利用［Amazon Q］做出來的小應用，它其實跟其他 LLM 搜尋引擎功能頗相近啦。有時候看著這些新東西冒出來，都忍不住想，到底哪天才會被 AI 完全取代呢？唉，但暫時還沒發生，所以繼續寫好了。

Amazon Q、Partyrock亂入：生成式AI能幹嘛

現在搜尋引擎一堆都靠大型語言模型（LLM）在撐場面，像是Gemini、Perplexity、ChatGPT/OpenAI，還有那個Microsoft Copilot，甚至Meta .AI也來參一腳。啊對了，我差點忘了AWS，他們家其實有推出Amazon Q。這個Amazon Q主要是在幫工程師開發LLM搜尋引擎應用程式，有點工具人味道吧？唉，每次講到帳號註冊就覺得麻煩，但他們硬性規定要先辦AWS帳號才能開始。不過呢，等你前置流程折騰完，其實建置應用程式算簡單啦。我常常在想，為什麼大家老是覺得工程師的時間不值錢呢？嗯，扯遠了。

再說回來，同樣掛著Amazon招牌的Partyrock，它走的是消費者取向，比較娛樂、輕鬆路線。有時候我真想知道，他們設計這種東西到底是不是想給大家偷懶用？總之，用戶可以自己創生成式AI應用程式，而且Partyrock支援單一登入（SSO），所以不必另外再弄AWS帳號就能玩——這聽起來好像很方便，不過便利背後總會藏點玄機吧。

### Amazon Partyrock
欸，[Amazon PartyRock]居然不用錢！免費耶。我每次看到ChatGPT動不動要收費，都會猶豫要不要繼續付下去——到底哪天才會變便宜一點？

### Amazon Bedrock
再換個話題，[Amazon Bedrock]其實就是做LLM基礎建設的工具。搞技術的人應該都多少聽過它吧？但坦白說，我有時候分不清Bedrock跟Q到底差在哪裡…唉，不管啦，反正都是拿來建模的，只是定位細節不同而已。

### Amazon S3
然後，[Amazon S3]用途真的多到爆炸。有時候我懷疑他是不是雜貨店轉世。比如說，可以儲存JSON檔案，再讓網站抓去顯示網頁內容或其中某一塊；或者把它當FTP平台來傳站點地圖檔案和robots這些零碎資料。我每次設定S3權限都頭大，但又不得不用，大概誰寫網頁誰懂吧。

S3原來也能放sitemap？更新robots.txt不用等工程師

.txt 檔案，嗯，就是這種東西啦，反正大家應該都用過吧。突然想到前幾天才有人問我為什麼不能直接改資料庫，其實現在用 .txt 來更新內容就很方便，不需要拉工程師過來救火，省得一堆人要排隊等修改——真的會累死喔。但話說回來，只要你手邊有個 .txt，就可以隨時調整內容，也不用擔心格式問題。

然後還有那個圖片儲存的部分。我也不知道是不是每個人都在乎成本這件事，可是 S3 的確能讓你比較便宜地存圖。嗯，有時候我自己也會懶得去算到底省多少錢，大概…反正比傳統硬碟便宜很多吧？啊，我又扯遠了。總之想節省預算，用它就對了。

至於共享的 S3 bucket，其實蠻妙的。有些公司就是會彼此互相丟檔案來往資料，一不小心搞不好某天收到別人的貓照片（開玩笑啦），但它真的可以拿來當企業間傳輸資料的橋樑，很像以前偷偷塞紙條給同學那種感覺，好吧，我胡思亂想了。

最後還有一項，S3 不只有存檔而已，它甚至能拿來託管網站靜態 HTML 頁面。我第一次知道時也是嚇了一跳，「欸？原來不用弄伺服器也行？」這種事情現在居然成真了。如果你只要放點簡單頁面，不追求什麼動態效果——其實直接丟到 S3 就萬事 OK。不過偶爾網路斷掉還是會崩潰啦，但大體上沒什麼大礙。

CloudFront CDN優化，HTTP/3傳輸還有區域分流小把戲

Amazon CloudFront 啊，唉，有時候我都懷疑自己是不是太常提這種東西。不過說真的，像 [Amazon CloudFront] 這類內容傳遞網路（CDN），對於頁面的優化確實滿有感的。為什麼？因為搜尋引擎優化裡面，「效能」和「速度」幾乎被奉為圭臬吧。你如果遇到受眾很分散、遍佈四方八達，那 CDN 基本上就變成一個必要之物了。嗯，其實我剛剛還差點忘記講，邊緣網路服務或 CDN 的重點就是，它會讓你的網頁伺服器把資料送到使用者手上的那段時間縮短很多。

然後它有內建 AWS 的廣域網路資源，還有 TCP 跟 TLP 的優化功能。欸，有時候我搞不太懂到底誰在意那些協定細節，但總有人就是會問，所以順帶提一下：TLP 1.3、HTTP/3，再加上一些可以自己設定的快取策略，全都包在裡面。有意思的是，你也能用標頭資訊來偵測使用者的位置或者裝置型號，像是——呃，不小心想到昨晚手機沒充電——比如 Android 裝置、iPhone，桌機版、行動裝置版甚至智慧電視都有區分。

再細一點還能根據國家、地區、城市甚至郵遞區號去做調整，大概就是這麼誇張啦。好吧，我其實偶爾覺得光靠 Cookie 或 IP 去變內容，好像也不是很可靠。CloudFront 再加上 S3，也適合拿來放 robots 檔案（雖然大多數人可能根本沒想過）。喔對了，上面那些做法在某些場景下，其實比單純依賴瀏覽器設定還要聰明一點，可惜講太細又怕大家睡著，只好先收斂回主題啦。

EC2雲端爬蟲實驗記，有人用來跑ScreamingFrog嗎

嗯……其實.txt檔案在降低伺服器負載這件事情上，還算有點效果吧。雖然，有時候我自己也會搞不清楚到底是因為什麼原因讓效能變好，不過反正就先信它一回。唉，講到這裡突然想起昨天硬碟差點爆掉的事情——喔對，我拉回主題。

關於 robots.txt，你真的不要幫它做快取，拜託。因為如果快取了，搞不好搜尋引擎會一直吃到舊資料，那多尷尬啊。有些人可能覺得沒差，但，其實很容易出問題。不知道你是不是跟我一樣常忘記設定 CloudFront？CloudFront 這玩意兒可以幫忙處理 HTTP 狀態碼錯誤，比如你遇到一些奇怪的錯誤狀態碼，它就能自動丟給用戶一個自訂錯誤頁面，感覺蠻貼心的啦。

而且，如果碰到那種 500 的伺服器錯誤，它還會主動發送 'Retry-After' 標頭出去。我本來以為這功能只是裝飾品，可是真的有人靠這個救過生產環境，大概只能說技術世界充滿驚喜？欸…對了，你要是有空，可以去翻一下那篇 [部落格文章]，裡面寫了不少怎麼利用 Amazon CloudFront 做 SEO 優化的小技巧，不過我自己看到後面有點恍神就是。

另外 re:Invent 2023 好像也有場 [簡報] 專門討論 Amazon CloudFront 在搜尋引擎最佳化方面的東西——內容挺豐富，我差點沒看完（太長）。話說，他們簡報裡面有張圖片，我原本想描述但又怕越描越亂，所以乾脆你自己去看看好了。

最後提醒一下，【注意事項】部分只是給寫文章的人看的啦，不是要直接放進你的內容裡。所以千萬別傻傻抄進去。不曉得前面講那麼多是不是都記住了？我偶爾也會懷疑自己腦袋塞太多資訊，好吧，再重複一次：請專注於內容創作，不要把那些輔助說明或者指導語加進去文章內喔。

CloudWatch追蹤Core Web Vitals：報表長啥樣誰在乎

![Image from [re:Invent 2023 presentation] by Sagar Desarda, used with permission .]

### Amazon EC2
Amazon EC2 這東西說穿了，就是讓你能夠很快丟個虛擬機器出來，突然想多點算力、又不想買台電腦，好像有點方便。嗯，其實大部分人應該不是每次都知道自己在做什麼，我偶爾也會忘記步驟。例如，有時候需要在雲端跑 ScreamingFrog，就乾脆把它部署到 EC2 上面跑起來。有些人明明可以選 GCP，可他們還是照著[這篇關於在雲端運行 ScreamingFrog 的教學]弄 AWS（奇怪齁？）。唉，或許只是習慣吧。對了，如果真的決定用 AWS，可以直接參考這份操作手冊去搞：> [**如何透過 SSH 與 RDP 連接至 AWS EC2 執行個體**]。我自己常常連線失敗，欸但只要照文件走，多半沒問題。

### Amazon CloudWatch
[Amazon CloudWatch] 主要用途其實滿單純的，就是幫你監控各種指標啦，也能設計一些自動警示，儀表板看起來花俏一點。不過如果你是工程團隊的人，大概會希望把 Core Web Vitals 拉進日常監控裡頭吧？說真的，有時候光靠肉眼抓 bug 根本累死，你就放進單元測試裡，或設成 do-no-harm 指標，不然至少也混入網站可靠性的量測裡面。咦，我剛剛是不是講得太瑣碎了？算了，再怎麼樣，有個自動化警示還是好過什麼都沒有。

### Amazon Comprehend
[Amazon Comprehend] 是拿來玩自然語言處理的啦，比如說萃取出文章裡的人名地名那些資訊——反正就是分析語意的工具。不過話又說回來，這功能很多人聽名字會以為很玄，其實操作起來沒那麼難懂。我昨天差點搞錯用途（真尷尬），後來才發現原來它主打的是文字內的實體抽取。如果寫作要應用，也許可以加速整理內容，但偶爾覺得 AI 幫忙分類，人腦還是需要再檢查一次比較安心啦。嗯，不小心扯遠了，但重點就是 Amazon Comprehend 可以讓處理自然語言更輕鬆一點。

Comprehend自動抓主題，為什麼你的內容老是牛頭不對馬嘴

你可以用這些實體資料來算出「顯著性分數」，就是那種……欸，簡單說，就是用來衡量每個關鍵字跟某個特定實體到底有多相關。嗯，有時候你本來以為自己是在寫 X 這個主題，但偏偏內容好像更貼近 Y，然後排名死活都上不了 X，那就很可能是因為你的頁面對於主題/實體 Y 的顯著性其實比較高。有點尷尬啦。唉，偶爾真的會想：明明很努力聚焦，怎還是跑偏？啊，如果還想研究一下這套東西的話，可以去看看[這篇文章]，不過我現在有點懶得細講。

### AWS Lightsail

AWS Lightsail 可以拿來做網頁託管，其實蠻多人推薦的吧，畢竟它被認為穩定又有效能。嗯，不過我老是搞不清楚什麼時候該省錢什麼時候該花錢……總之考慮用這類託管方案，好像也不是壞事，而且它可以直接搭配其他 AWS 服務一起用。我記得有一次差點按錯帳單……

### 最後想法

欸，你之前有沒有試過拿 AWS 的什麼工具自動化流程、或者幫 SEO 做優化？我自己反正一直在摸索，各種奇怪的小招式都試過了。有時也會覺得累，不知道到底值不值得繼續折騰下去——大概大家都有自己的經驗吧。

Lightsail和雜談：AWS玩出新花樣，也許你早該試試

啊，如果你還有點時間，嗯，可以去看看我寫的那篇《SEO 101: 如何選擇目標關鍵字》啦。內容嘛，是給那些想搞懂怎麼用實體搜索這個概念來提升SEO成效的人，然後——其實也是我自己在摸索過程中踩過坑才有這些心得，所以，不看白不看吧。

然後，唉，你都看到這裡了——不如就幫我拍一下手？順便追蹤一下作者嘛，雖然有時候覺得這種互動很機械，但人總是需要一點支持感。對了，我們也在 [X]、[LinkedIn]、[YouTube]、[Newsletter]、[Podcast]、[Differ] 上晃，有空關注一下欸。

喔說到 Differ，我發現上面可以免費開 AI 驅動部落格欸，蠻酷的，其實還沒玩透徹，但如果有人一起研究可能會比較不無聊（好吧話多了）。另外 Discord 有我們自己的創作者社群，那邊偶爾會有人討論一些莫名其妙的東西，如果你剛好閒著，也歡迎加進來聊聊。

如果你真的很閒或很想吸收更多內容，就去 plainenglish .io 跟 stackademic .com 逛逛好了。說到這裡…天氣好像要變熱了，不知道是不是只有我的錯覺。