我的 Amazon 評論爬蟲曾經連續六週都跑得很穩；直到某天早上，它回傳了 200 OK，卻只剩下一整頁空白。沒有錯誤、沒有 CAPTCHA，原本有幾百則評論的地方，只剩空白 HTML。
如果這聽起來很熟悉，你並不孤單。到了 2025 年底，Amazon 開始把完整評論頁面擋在登入牆後面，導致大量 Python 爬蟲腳本一夜之間失效。過去幾個月，我在 Thunderbit 一邊開發我們的 AI 爬蟲，一邊維護自己的 Python 評論資料管線，所以我想把當初希望有人早點寫給我的這份指南整理出來。這篇文章會帶你走過真正可用的方法：基於 Cookie 的驗證、能撐過 Amazon CSS 混淆的穩定選擇器、突破 10 頁分頁上限的技巧、反機器人防護，以及加碼的情緒分析，幫你把原始評論文字轉成真正有用的商業洞察。如果你讀到一半心想：「我實在不想維護這麼多程式碼」，我也會示範 Thunderbit 如何在大約兩分鐘內、完全不寫 Python 就完成同樣的工作。
什麼是 Amazon 評論爬取？為什麼它很重要？
Amazon 評論爬取，指的是透過程式化方式，從 Amazon 商品頁面擷取顧客評論資料——像是星等評分、評論文字、作者名稱、日期、是否購買過的標記等。由於 Amazon 早在 2010 年就已經把評論內容從 Product Advertising API 移除，而且之後也沒有恢復，所以網頁爬蟲成了取得這些資料的唯一程式化途徑。
數據也支持這件事。95% 的消費者在購買前會先看評論，而且94% 的人把 Amazon 當成產品評論的第一來源。在商品頁上只顯示 5 則評論，就可能讓轉換率提升 270%。而系統性分析評論情緒的公司，客戶留存率可提升最高 15%。這不只是抽象的資料科學，而是競爭情報、產品改善訊號與行銷文案靈感，全都直接寫在 Amazon 的伺服器上。
為什麼要用 Python 爬 Amazon 評論
Python 依然是這類工作的首選語言。它是 2024 Stack Overflow 開發者調查中最受期待的第 1 名語言，而且它的生態系——requests、BeautifulSoup、pandas、Scrapy——讓即使不是全職開發者，也能相對輕鬆地做網頁爬取。
不同團隊會把這些資料用在不同地方：
| 團隊 | 使用情境 | 擷取內容 |
|---|---|---|
| 產品 / 研發 | 找出反覆出現的抱怨，優先處理修正項目 | 1–2 星評論文字、關鍵字出現頻率 |
| 業務 | 監控競品產品情緒 | 評分、評論量趨勢 |
| 行銷 | 從顧客用語中找廣告文案靈感 | 正向評論片語、功能提及 |
| 電商營運 | 追蹤自家產品的情緒變化 | 星等分布、已驗證購買比例 |
| 市場研究 | 比較同類商品在不同功能上的表現 | 多個 ASIN 的評論資料集 |
某個廚具品牌分析負面評論後發現 22% 的人提到「不沾塗層會脫落」，於是重新配方，並在 60 天內拿回 #1 Best Seller 的排名。某家智慧手環公司從評論文字中挖出「錶帶刺激皮膚」，找出乳膠過敏問題，推出低敏版本，退貨率因此降低 40%。這類 ROI，足以讓工程投入變得很值得。
登入牆：為什麼你的 Amazon 評論爬蟲突然失效了
2024 年 11 月 14 日，Amazon 開始要求登入才能查看完整的產品評論頁面。這項變更也被 社群論壇 和 爬蟲服務商部落格 證實。當你在無痕視窗中訪問 /product-reviews/{ASIN}/ 時，看到的會是登入頁，而不是評論資料。
症狀很隱晦：你的腳本拿到的是 200 OK，但 HTML 主體裡放的是登入表單（name="email"、id="ap_password"），不是評論。沒有錯誤碼，沒有 CAPTCHA，只有一片……毫無用處的空白。
Amazon 這麼做，是為了反機器人與區域合規。實際執行並不一致——有時候剛開啟的新瀏覽器視窗還能先載入幾則評論，尤其是第一頁，但很快就會被擋下來。不過對任何規模化爬蟲來說，你都應該假設登入牆一直存在。
不同 Amazon 國家站點（.de、.co.uk、.co.jp）各自獨立執行這個限制。就像論壇使用者說的：「每個國家都需要各自登入一次。」你的 .com Cookie 不會在 .co.uk 上有效。
精選評論 vs. 完整評論：不登入時還能看到什麼？
Amazon 商品頁（/dp/{ASIN}/ URL）仍會顯示大約 8 則「精選評論」，而且不需要驗證。這些是 Amazon 演算法挑選出來的內容，適合快速看一下整體情緒，但不能排序、篩選或分頁。
完整評論頁（/product-reviews/{ASIN}/）則支援依最新排序、按星等篩選，以及跨數百則評論分頁瀏覽，但必須登入。
如果你只需要幾則評論快速了解狀況，抓商品頁就夠了；如果你要幾百或幾千則，就得處理驗證。
開始前要準備什麼：Python 環境與套件
在寫程式之前，先確認這些設定：
- 難度： 中等（熟悉 Python、了解基本 HTML）
- 所需時間： 完整流程約 45 分鐘；基本爬取約 10 分鐘
- 你需要： Python 3.8+、Chrome 瀏覽器、有效的 Amazon 帳號
先安裝核心套件：
pip install requests beautifulsoup4 lxml pandas textblob
選配（進階情緒分析用）：
pip install transformers torch
什麼是 ASIN？ 這是 Amazon 的 10 位商品識別碼。你可以在任何商品網址中找到它——例如在 amazon.com/dp/B0BCNKKZ91 裡，ASIN 就是 B0BCNKKZ91。這個值就是你要放進評論網址的關鍵。
步驟 1：用 Cookie 驗證通過登入牆
最穩定的方法，是先在瀏覽器裡登入 Amazon，然後把 Session Cookie 複製出來，注入到 Python 的 requests.Session()。這樣可以避免 Selenium 登入自動化常遇到的 CAPTCHA 與簡訊雙重驗證。
你需要這 7 個 Cookie：
| Cookie 名稱 | 用途 |
|---|---|
session-id | 會輪替的 session 識別碼 |
session-id-time | session 時間戳記 |
session-token | 會輪替的 session token |
ubid-main | 使用者瀏覽識別碼 |
at-main | 主要驗證 token |
sess-at-main | session 範圍內的驗證資訊 |
x-main | 與使用者 email 綁定的識別碼 |
如何從 Chrome DevTools 匯出 Cookie
- 在 Chrome 登入 amazon.com
- 打開 DevTools（F12，或按右鍵 → 檢查）
- 前往 Application → Storage → Cookies →
https://www.amazon.com - 在表格中找到每個 Cookie 名稱，複製其值
- 把它們整理成以分號分隔的字串，供 Python 使用
像這樣建立你的 session：
import requests
session = requests.Session()
# 把你的 Cookie 值貼在這裡
cookies = {
"session-id": "YOUR_SESSION_ID",
"session-id-time": "YOUR_SESSION_ID_TIME",
"session-token": "YOUR_SESSION_TOKEN",
"ubid-main": "YOUR_UBID_MAIN",
"at-main": "YOUR_AT_MAIN",
"sess-at-main": "YOUR_SESS_AT_MAIN",
"x-main": "YOUR_X_MAIN",
}
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36",
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8",
"Accept-Language": "en-US,en;q=0.5",
}
session.cookies.update(cookies)
session.headers.update(headers)
重點： 後續所有請求都要沿用同一個 session 物件。這樣 Cookie 才能保持一致，也比較像真實瀏覽器操作。Cookie 通常可以撐幾天到幾週；如果之後又開始被導向登入頁，就重新從瀏覽器更新一次。
對於非 .com 的站點，Cookie 名稱會略有不同——amazon.de 用的是 at-acbde，amazon.co.uk 用的是 at-acbuk，依此類推。每個站點都需要各自獨立的 session。
步驟 2：建立請求並用 BeautifulSoup 解析評論 HTML
Amazon 評論網址長這樣：
https://www.amazon.com/product-reviews/{ASIN}/ref=cm_cr_arp_d_viewopt_srt?sortBy=recent&pageNumber=1
核心函式：
from bs4 import BeautifulSoup
import time, random
def get_soup(session, url):
time.sleep(random.uniform(2, 5)) # 禮貌性延遲
response = session.get(url, timeout=15)
# 偵測登入牆
if "ap_email" in response.text or "Amazon Sign-In" in response.text:
raise Exception("偵測到登入牆——請更新你的 Cookie")
if response.status_code != 200:
raise Exception(f"HTTP {response.status_code}")
return BeautifulSoup(response.text, "lxml")
有個小技巧很有用：在打開評論頁之前，先訪問商品頁。這會讓 session 的瀏覽行為更自然。
# 先訪問商品頁（模擬真實瀏覽）
product_url = f"https://www.amazon.com/dp/{asin}"
session.get(product_url, timeout=15)
time.sleep(random.uniform(1, 3))
# 再訪問評論頁
reviews_url = f"https://www.amazon.com/product-reviews/{asin}/ref=cm_cr_arp_d_viewopt_srt?sortBy=recent&pageNumber=1"
soup = get_soup(session, reviews_url)
步驟 3：使用穩定選擇器擷取評論資料（別再依賴 CSS 類名）
這是 2022–2023 年大多數教學失效的地方。Amazon 會混淆 CSS class 名稱——它們會週期性變動，就像某位挫折滿滿的開發者在論壇留言說的：「這些 span 標籤的 class 名稱完全沒有固定規律。」
解法是：Amazon 在評論元素上使用 data-hook 屬性，而且這些屬性非常穩定。它們是語意化識別碼，也是 Amazon 前端程式本身依賴的資訊，所以不會被隨機改掉。
| 評論欄位 | 穩定選擇器（data-hook） | 脆弱選擇器（class） |
|---|---|---|
| 評論文字 | [data-hook="review-body"] | .review-text-content（會變） |
| 星等評分 | [data-hook="review-star-rating"] | .a-icon-alt（不夠明確） |
| 評論標題 | [data-hook="review-title"] | .review-title（有時可用） |
| 作者名稱 | span.a-profile-name | 相對穩定 |
| 評論日期 | [data-hook="review-date"] | .review-date（依地區而異） |
| 已驗證購買 | [data-hook="avp-badge"] | span.a-size-mini |
使用 data-hook 選擇器的擷取程式如下：
import re
def extract_reviews(soup):
reviews = []
review_divs = soup.select('[data-hook="review"]')
for div in review_divs:
# 星等
rating_el = div.select_one('[data-hook="review-star-rating"]')
rating = None
if rating_el:
rating_text = rating_el.get_text(strip=True)
match = re.search(r'(\d\.?\d?)', rating_text)
if match:
rating = float(match.group(1))
# 標題
title_el = div.select_one('[data-hook="review-title"]')
title = title_el.get_text(strip=True) if title_el else ""
# 內文
body_el = div.select_one('[data-hook="review-body"]')
body = body_el.get_text(strip=True) if body_el else ""
# 作者
author_el = div.select_one('span.a-profile-name')
author = author_el.get_text(strip=True) if author_el else ""
# 日期與國家
date_el = div.select_one('[data-hook="review-date"]')
date_text = date_el.get_text(strip=True) if date_el else ""
# 格式："Reviewed in the United States on January 15, 2025"
country_match = re.search(r'Reviewed in (.+?) on', date_text)
date_match = re.search(r'on (.+)$', date_text)
country = country_match.group(1) if country_match else ""
date = date_match.group(1) if date_match else ""
# 已驗證購買
verified_el = div.select_one('[data-hook="avp-badge"]')
verified = bool(verified_el)
reviews.append({
"author": author,
"rating": rating,
"title": title,
"content": body,
"date": date,
"country": country,
"verified": verified,
})
return reviews
我用這組選擇器跑多個 ASIN 好幾個月了，data-hook 屬性一次都沒變過。反觀 CSS 類名，在同一段時間內至少輪替了兩次。
步驟 4：處理分頁與 Amazon 的 10 頁上限
Amazon 將 pageNumber 參數限制為每個篩選組合最多 10 頁、每頁 10 則評論，也就是每種組合最多大約 100 則評論。到了第 10 頁之後，「下一頁」按鈕就會消失。
最基本的分頁迴圈：
all_reviews = []
for page in range(1, 11):
url = f"https://www.amazon.com/product-reviews/{asin}/ref=cm_cr_arp_d_viewopt_srt?sortBy=recent&pageNumber={page}"
soup = get_soup(session, url)
page_reviews = extract_reviews(soup)
if not page_reviews:
break # 這一頁沒有更多評論
all_reviews.extend(page_reviews)
print(f"第 {page} 頁：{len(page_reviews)} 則評論")
如何抓到超過 10 頁的 Amazon 評論
解法是利用篩選分桶。每一組 filterByStar 和 sortBy 的組合，都會有自己獨立的 10 頁視窗。
星等篩選值： one_star、two_star、three_star、four_star、five_star
排序值： recent、helpful（預設）
把 5 種星等篩選 × 2 種排序方式全部組合起來，你最多可以存取 100 頁，也就是每個商品約 1,000 則評論；而且如果產品的星等分布不平均，通常能接近完整評論集。
star_filters = ["one_star", "two_star", "three_star", "four_star", "five_star"]
sort_orders = ["recent", "helpful"]
all_reviews = []
seen_titles = set() # 簡單去重
for star in star_filters:
for sort in sort_orders:
for page in range(1, 11):
url = (
f"https://www.amazon.com/product-reviews/{asin}"
f"?filterByStar={star}&sortBy={sort}&pageNumber={page}"
)
soup = get_soup(session, url)
page_reviews = extract_reviews(soup)
if not page_reviews:
break
for review in page_reviews:
# 用標題 + 作者名稱做去重 key
key = (review["title"], review["author"])
if key not in seen_titles:
seen_titles.add(key)
all_reviews.append(review)
print(f"[{star}/{sort}] 第 {page} 頁：{len(page_reviews)} 則評論")
print(f"唯一評論總數：{len(all_reviews)}")
不同分桶之間會有重疊，所以去重很重要。我通常會用「評論標題 + 作者名稱」組合作為 key——不是百分之百完美，但可以抓到絕大多數重複資料。
步驟 5：閃避反機器人防護（輪替、限速、重試）
Amazon 使用 AWS WAF Bot Control，而且比以前積極很多。單一層級的對策（只換 User-Agent、只加延遲）已經不夠用了。
| 技巧 | 實作方式 |
|---|---|
| 輪替 User-Agent | 從 10+ 組真實瀏覽器字串中隨機挑選 |
| 指數退避 | 遇到 503 時採用 2 秒 → 4 秒 → 8 秒重試延遲 |
| 請求限速 | 每頁之間等待 random.uniform(2, 5) 秒 |
| 代理輪替 | 在住宅代理之間循環切換 |
| Session 指紋 | 每個 session 維持一致的 Cookie + Header |
| TLS 模擬 | 生產環境改用 curl_cffi，不要只用原生 requests |
適合正式環境的重試包裝函式：
import time, random
USER_AGENTS = [
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36",
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36",
"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:149.0) Gecko/20100101 Firefox/149.0",
"Mozilla/5.0 (Macintosh; Intel Mac OS X 15_7_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Safari/605.1.15",
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36",
]
def scrape_with_retries(session, url, max_retries=3):
for attempt in range(max_retries):
try:
session.headers["User-Agent"] = random.choice(USER_AGENTS)
time.sleep(random.uniform(2, 5))
response = session.get(url, timeout=15)
# 偵測封鎖
if "validateCaptcha" in response.url or "Robot Check" in response.text:
wait = (2 ** attempt) * 5
print(f"偵測到 CAPTCHA，等待 {wait} 秒...")
time.sleep(wait)
continue
if response.status_code in (429, 503):
wait = (2 ** attempt) * 2
print(f"被限流（{response.status_code}），等待 {wait} 秒...")
time.sleep(wait)
continue
if "ap_email" in response.text:
raise Exception("登入牆——Cookie 已過期")
return BeautifulSoup(response.text, "lxml")
except Exception as e:
if attempt == max_retries - 1:
raise
print(f"第 {attempt + 1} 次嘗試失敗：{e}")
return None
關於代理：Amazon 會在網路層封鎖已知資料中心 IP 範圍（AWS、GCP、Azure、DigitalOcean）。如果你要爬超過幾百頁，住宅代理幾乎是必需品——視流量而定，通常每月要花 50–200 美元以上。對小型專案（每天少於 100 次請求）來說，只要從家用 IP 做適當限速，通常也能正常運作。
Amazon 也會檢查 TLS 指紋。Python 原生的 requests 套件有一個眾所周知的 JA3 hash，WAF 常常會先行封鎖。如果是正式爬蟲，建議考慮 curl_cffi，它可以模擬真實瀏覽器的 TLS 堆疊。若只是教學規模的爬取（幾百頁以內），搭配良好 headers 的 requests 通常就夠了。
步驟 6：把抓到的 Amazon 評論匯出成 CSV 或 Excel
抓完評論後，把資料整理成可用格式其實很簡單，用 pandas 就行：
import pandas as pd
df = pd.DataFrame(all_reviews)
df.to_csv("amazon_reviews.csv", index=False)
print(f"已匯出 {len(df)} 則評論到 amazon_reviews.csv")
範例輸出：
| author | rating | title | content | date | country | verified |
|---|---|---|---|---|---|---|
| Sarah M. | 5.0 | 今年最值得的一次購買 | 電池可以撐一整天，螢幕也很漂亮... | January 15, 2025 | 美國 | True |
| Mike T. | 2.0 | 用了兩週就失望了 | 充電孔壞掉了... | February 3, 2025 | 美國 | True |
| Priya K. | 4.0 | CP 值很高 | 我需要的功能都有，重度 App 會有一點延遲... | March 10, 2025 | 美國 | False |
匯出 Excel 可用：df.to_excel("amazon_reviews.xlsx", index=False)（需要 openpyxl）。
如果要匯入 Google Sheets，gspread 雖然能用，但要走至少 8 個 Google Cloud 設定步驟——建立專案、啟用兩個 API、產生 service account 憑證、分享工作表。若這個設定流程比實際爬蟲還麻煩，那你沒有想錯。（這也是為什麼像 Thunderbit 這種可以一鍵匯出到 Google Sheets 的工具，會顯得特別吸引人。）
加碼：用 5 行 Python 替你的評論加上情緒分析
大多數爬蟲教學只做到 CSV 匯出，但真正能把資料變成商業決策的，是情緒評分。
最快的基準作法是用 TextBlob：
from textblob import TextBlob
df["sentiment"] = df["content"].apply(lambda x: TextBlob(str(x)).sentiment.polarity)
這會為每則評論產生一個介於 -1.0（非常負面）到 +1.0（非常正面）的 polarity 分數。範例輸出：
| content（截斷） | rating | sentiment |
|---|---|---|
| "Battery lasts all day, screen is gorgeous..." | 5.0 | 0.65 |
| "The charging port stopped working after..." | 2.0 | -0.40 |
| "Does everything I need, minor lag on..." | 4.0 | 0.25 |
| "Absolute garbage. Returned immediately." | 1.0 | -0.75 |
| "It's okay. Nothing special but works." | 3.0 | 0.10 |
最有趣的是那些不一致的列——例如 3 星評論卻是正面語氣，或 5 星評論卻出現負面措辭。這些落差常常能揭露星等分數看不出的細膩顧客意見。
如果要追求生產等級的準確度，建議使用 Hugging Face Transformers。VADER 是拿推文訓練的，不是產品評論，而且相比詞典型工具，transformer 模型在評論分類上的準確率可超過 98%。nlptown/bert-base-multilingual-uncased-sentiment 甚至能直接預測 1–5 星評分：
from transformers import pipeline
clf = pipeline("sentiment-analysis",
model="nlptown/bert-base-multilingual-uncased-sentiment")
df["predicted_stars"] = df["content"].apply(
lambda x: int(clf(str(x)[:512])[0]["label"][0])
)
Amazon 評論通常呈現 J 型分布——5 星有一個大高峰、1 星有一個較小高峰，中間則是低谷。這也意味著平均星等常常無法真實代表產品品質。建議把 1 星群組單獨切出來，挖掘裡面的重複主題——通常真正可修正的缺陷就藏在那裡。
誠實的取捨：自己寫 Python vs. 付費爬蟲 API vs. Thunderbit
我維護過 Amazon 的 Python 爬蟲，所以我講得直接一點：它們真的會壞。選擇器會變、Cookie 會過期、Amazon 會加新一層 bot 偵測，然後你的週六早上就不是在分析資料，而是在修爬蟲。論壇使用者也有同樣的挫折——那些「上個月還能跑」的 DIY 腳本，現在都得一直補丁式修修補補。
下面是三種主要做法的比較：
| 比較項目 | DIY Python（BS4/Selenium） | 付費爬蟲 API | Thunderbit（無程式碼） |
|---|---|---|---|
| 建置時間 | 1–3 小時 | 30 分鐘（API key） | 2 分鐘 |
| 成本 | 免費（另加代理費） | 每月 50–200+ 美元 | 有免費方案 |
| 登入牆處理 | 手動管理 Cookie | 通常已處理 | 自動處理 |
| 維護成本 | 高（選擇器常壞） | 低（由服務商維護） | 幾乎零（AI 自動適應） |
| 分頁處理 | 需要自己寫 | 內建 | 內建 |
| 多國站支援 | 每個網域要分開 session | 通常支援 | 透過瀏覽器 = 你的所在地區 |
| 情緒分析 | 自己加程式碼 | 有時內建 | 匯出到 Sheets，去哪裡都能分析 |
| 最適合誰 | 學習、需要完全控制的人 | 重視穩定度的生產管線 | 快速拉資料、非技術團隊 |
Python 給你完全控制權，也確實是理解網頁爬蟲底層原理的最好方式。付費 API（像 ScrapingBee、Oxylabs、Bright Data）則很適合重視穩定運作、願意付費的生產管線。而如果你的團隊需要評論資料，但又不想承擔開發維護成本——例如電商營運每週監控競品、行銷團隊要抓顧客用語寫文案——還有第三條路。
如何用 Thunderbit 爬 Amazon 評論（免寫程式、免維護）
我們打造 Thunderbit，就是為了處理這類「維護 Python 爬蟲太大材小用」的情境。流程大致如下：
- 安裝 Thunderbit Chrome 擴充功能
- 在瀏覽器中打開 Amazon 商品評論頁（你已經登入了，所以登入牆根本不是問題）
- 點選「AI Suggest Fields」——Thunderbit 會讀取頁面並建議欄位，例如 Author、Rating、Title、Review Text、Date、Verified Purchase
- 點選「Scrape」——資料會立即擷取完成，還內建分頁處理
- 匯出 到 Excel、Google Sheets、Airtable 或 Notion
最大的優勢是，Thunderbit 的 AI 每次都會重新理解頁面結構。沒有 CSS 選擇器要維護、沒有 Cookie 管理、沒有反機器人程式要寫。當 Amazon 改變 HTML 時，AI 會自動適應。對想要程式化存取、但又不想全手寫的人，Thunderbit 也提供 Extract API，可透過 API 進行結構化資料擷取，並由 AI 自動辨識欄位，不需要維護選擇器。
如果你想更深入了解 Amazon 資料，也可以參考我們關於如何爬取 Amazon 商品與評論以及擷取並分析 Amazon 銷售資料的指南。
使用 Python 大規模爬 Amazon 評論的技巧
如果你要跨很多 ASIN 抓評論，以下幾個做法可以幫你少很多麻煩：
- 批次處理 ASIN，而且商品與商品之間也要加延遲，不只是頁面與頁面之間。我通常會在不同 ASIN 間停 10–15 秒。
- 積極去重。 當你把多個星等篩選與排序組合併在一起時，會有重複評論。可以用
(title, author, date)元組當作去重 key。 - 記錄失敗項目。 追蹤哪些 ASIN + 頁碼 + 篩選組合失敗，這樣重試時就不用全部重抓。
- 大型專案建議存進資料庫。 簡單的 SQLite 比一直增長的 CSV 檔更能擴充：
import sqlite3
conn = sqlite3.connect("reviews.db")
df.to_sql("reviews", conn, if_exists="append", index=False)
- 排程定期爬取。 若要長期監控，可以設定 cron job，或使用 Thunderbit 的 Scheduled Scraper 功能——只要描述 URL 和排程，剩下的不用伺服器也能自動處理。
如果你想看更多做法，我們的最佳自動化網頁爬蟲工具與將網站資料爬到 Excel也有更多選項。
關於法律與倫理的快速提醒
Amazon 的使用條款明確禁止「使用任何機器人、蜘蛛程式、爬蟲或其他自動化方式存取 Amazon 服務」。不過，近年美國法院對公開資料爬取的判例相對友善。在 Meta Platforms v. Bright Data（2024 年 1 月）一案中，聯邦法院裁定：若爬取的是公開可存取資料，且爬蟲並非登入狀態的「使用者」，則不構成違反服務條款。
但這裡有個關鍵差異：登入後的爬取（也就是本教學涵蓋的內容）會進入合約法範疇，因為你在建立帳號時就已同意 Amazon 的使用條款。爬取公開可見的精選評論，法律風險通常比登入牆後面的完整評論低。
實務上的建議是：不要把抓來的資料拿去商業性再散布，不要擷取超出公開顯示範圍的個人資料，尊重 robots.txt，若是大規模或商業用途，請諮詢法律專業人士。這不是法律意見。若想了解更多法律面向，可參考我們的網頁爬蟲法律影響概覽。
結論：用 Python 爬 Amazon 評論，或直接跳過程式碼
快速回顧一下這篇指南涵蓋了什麼：
- 登入牆確實存在，但可以透過 Cookie 驗證解決——從瀏覽器複製 7 個 Cookie，注入
requests.Session() - 擷取時請使用
data-hook選擇器，不要依賴每幾週就變一次的 CSS 類名 - 結合星等篩選與排序方式，突破 10 頁分頁限制，每個商品可取得 500+ 則評論
- 情緒分析可用 TextBlob 快速建立基準，或用 Hugging Face Transformers 追求生產級準確度
- 反機器人防護要持續維護：限速、輪替 User-Agent、指數退避，以及在規模化時使用住宅代理
Python 給你完全控制，也最適合理解底層到底發生了什麼。不過，如果你的需求是「我這週五前要把競品評論資料放進試算表」，而不是「我要打造一套正式的資料管線」，那麼自建爬蟲的維護成本可能就不划算了。
Thunderbit 能用幾個點擊就處理驗證、選擇器、分頁與匯出——你可以先試試 免費方案，看看是否符合你的工作流程。隨著 Amazon 持續加強反機器人措施，能即時適應的 AI 工具，將會從「加分項」逐漸變成「必需品」。
你也可以到我們的 Thunderbit YouTube 頻道觀看各種爬取流程的影片教學。
常見問題
1. 不登入也能爬 Amazon 評論嗎？
可以，但只能抓到商品詳情頁（/dp/{ASIN}/）上顯示的約 8 則「精選評論」。截至 2024 年底，帶有排序、篩選與分頁功能的完整評論頁都需要登入。對大多數商業用途來說，你還是得處理登入牆。
2. 爬 Amazon 評論合法嗎？
Amazon 的使用條款禁止自動化爬取。不過，美國近期判例（Meta v. Bright Data，2024；hiQ v. LinkedIn）對公開資料爬取較為支持。登入後的爬取因為你已同意 Amazon 使用條款，所以法律風險較高。商業用途請諮詢法律專業人士。
3. 每個商品最多可以抓多少則 Amazon 評論？
Amazon 把每個排序與星等篩選組合的評論頁數限制在 10 頁。若使用 5 種星等篩選 × 2 種排序，你每個商品最多可存取 100 頁，也就是大約 1,000 則評論。若再加上關鍵字篩選，理論上上限會更高，但重複資料也會很多。
4. 用 Python 爬 Amazon 評論，最好的套件是哪個？
requests + BeautifulSoup 是最常見、也最穩定的靜態 HTML 解析組合。若需要 JavaScript 渲染，Selenium 很有用。如果你想要一個無程式碼替代方案，而且能自動處理登入牆與分頁，可以試試 Thunderbit。
5. 要怎麼避免在爬 Amazon 時被封鎖？
從 10+ 組真實瀏覽器 User-Agent 中輪替、在每次請求之間加入 2–5 秒隨機延遲、遇到 503/429 時做指數退避、規模化時使用住宅代理（資料中心 IP 通常會先被封）、並在整個請求流程中維持一致的 session cookie。若想完全不用維護，Thunderbit 會透過你的瀏覽器 session 自動處理反機器人防護。
延伸閱讀
