我實測了 4 種用 Python 抓取 Amazon Best Sellers 的方法

上週末，我為了用四種不同方法抓取 Amazon 的 Best Sellers 頁面，硬是喝掉了一整壺咖啡。兩種表現超出預期，一種差點害我的 IP 被封，還有一種真的只要點兩下。以下是我完整的實測心得。

Amazon 這個電商巨獸，擁有、，而且 Best Sellers Rank（BSR）每小時更新一次。如果你在做 FBA 選品研究、競品定價分析，或只是想在對手之前先看見趨勢，那 Best Seller 資料絕對是寶藏。

但要把這些資料從 Amazon 拉進試算表，事情就沒那麼簡單了。這正是我測試 requests + BeautifulSoup、Selenium、scraping API，以及（我們自己的免寫程式 AI 網頁爬蟲）的原因——看看哪一種真的能交出成果，又有哪些方法只會把你送進 CAPTCHA 頁面。

Amazon Best Sellers 是什麼？為什麼你應該關注？

Amazon Best Sellers Rank（BSR）是 Amazon 的即時排行榜，依照各分類的銷量來排名商品。你可以把它想成一個每小時更新一次的人氣競賽，綜合近期與歷史銷售表現來決定名次。Amazon 官方的說法是這樣的：

「Amazon Best Sellers 的計算方式是根據 Amazon 銷售資料，並每小時更新，以反映 Amazon 上每個商品的近期與歷史銷售表現。」—

Best Sellers 頁面會顯示每個分類前 100 名商品，分成兩頁，每頁 50 筆。第 1 頁是 #1–50，第 2 頁是 #51–100。Amazon 也已確認，頁面瀏覽量與顧客評論都不會影響 BSR，BSR 完全是由銷售表現決定。

誰會需要這些資料？做 FBA 選品的電商賣家、建立競爭情報的業務團隊、追蹤定價趨勢的營運團隊，以及觀察分類成長的市場研究人員。就我觀察，任何在 Amazon 上銷售，或與 Amazon 競爭的人，最後幾乎都會需要把這些資料整理成試算表。

為什麼要用 Python 抓 Amazon Best Sellers？

手動做商品研究非常耗時。根據一項，員工平均每週有 9.3 小時都花在搜尋與蒐集資訊上。對電商團隊來說，這意味著得花好幾個小時在 Amazon 頁面間點來點去、複製商品名稱和價格，再貼到試算表裡，然後下週整個流程再重來一次。

以下是幾個讓抓取 Best Sellers 很有價值的實際用途：

應用情境	可取得的資料	受益對象
FBA 選品研究	透過 BSR 與評論數找出需求高、競爭低的商品	Amazon 賣家、代發貨商
競爭定價	追蹤你所屬分類熱門商品的價格變化	電商團隊、定價分析師
市場趨勢監測	找出上升中的分類與季節性變化	產品經理、市場研究人員
開發名單	建立暢銷品牌與其產品線清單	業務團隊、B2B 開發
競品分析	將你的產品與類別領先者做基準比較	品牌經理、策略團隊

投資報酬率相當驚人：一份針對 2,700 位商務專業人士的發現，AI 工具平均每週可替電商從業者省下。而使用自動化價格追蹤的賣家，Buy Box 持有率達到，相較之下手動追蹤者只有 42%，等於因為反應更快而帶來 37% 的銷售成長。

用 Python 抓 Amazon Best Sellers 的 4 種方法：快速比較

在進入逐步教學之前，先給你一個我希望自己在測試前就有的並排比較。這張表可以幫你快速選出最適合的方法：

評估 معیار	requests + BS4	Selenium	Scraping API（例如 Scrape.do）	Thunderbit（免寫程式）
安裝難度	中等	高（需 driver、瀏覽器）	低（API key）	非常低（Chrome 擴充功能）
處理延遲載入	否	是（模擬捲動）	是（已渲染 HTML）	是（由 AI 處理渲染）
抗封鎖能力	低（容易被封 IP）	中等（可被偵測）	高（輪換代理）	高（雲端 + 瀏覽器模式）
維護成本	高（選擇器容易失效）	高（driver 更新 + 選擇器）	低	非常低（AI 可適應版面變化）
成本	免費	免費	付費（按請求計）	免費方案 + 付費方案
最適合	一次性抓取、學習用途	JS 密集頁面、需登入頁面	大規模 / 正式環境	非工程人員、快速研究、週期性監測

如果你想學 Python 抓取的基本功，可以從方法 1 或 2 開始；如果你需要正式環境的穩定性，就選方法 3；如果你想兩下點完就拿到結果、不想寫程式，那就直接跳到方法 4。

開始之前

難度： 初學到中階（依方法而定）
所需時間： Thunderbit 約 15 分鐘，Python 方法約 45 分鐘
你需要準備： Python 3.8+（方法 1–3）、Chrome 瀏覽器、（方法 4）、以及一個目標 Amazon Best Sellers 分類網址

方法 1：用 requests + BeautifulSoup 抓 Amazon Best Sellers

這是最輕量、也最適合初學者的做法——不用瀏覽器自動化，只靠 HTTP 請求和 HTML 解析。不過，它也讓我第一次真正體會到 Amazon 的反爬防線有多強。

步驟 1：建立環境

先安裝必要套件：

1pip install requests beautifulsoup4 pandas

接著匯入套件：

1import requests
2from bs4 import BeautifulSoup
3import pandas as pd
4import random
5import time

步驟 2：帶上逼真的標頭送出請求

Amazon 會阻擋看起來像機器人的請求。最基本的防線，就是加上模擬真實瀏覽器的 User-Agent 標頭。以下範例包含一組目前常見、較逼真的 User-Agent 字串（來源：，2026 年 3 月）：

1USER_AGENTS = [
2    "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36",
3    "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",
4    "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:149.0) Gecko/20100101 Firefox/149.0",
5    "Mozilla/5.0 (Macintosh; Intel Mac OS X 15.7; rv:149.0) Gecko/20100101 Firefox/149.0",
6    "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",
7]
8headers = {"User-Agent": random.choice(USER_AGENTS)}
9url = "https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/"
10response = requests.get(url, headers=headers)
11print(response.status_code)  # 應該是 200

如果你看到 200 狀態碼，代表成功了；如果是 503，或被轉向 CAPTCHA 頁面，就表示 Amazon 已經把你的請求標記為可疑流量。

步驟 3：用 BeautifulSoup 解析商品資料

先用瀏覽器的 DevTools 檢查 Amazon 頁面的 HTML 結構（右鍵 → 檢查）。商品容器使用的是 gridItemRoot 這個 ID。在每個容器裡，你可以找到商品名稱、價格、評分和 URL。

1soup = BeautifulSoup(response.text, "html.parser")
2products = []
3for item in soup.find_all("div", id="gridItemRoot"):
4    title_tag = item.find("div", class_="_cDEzb_p13n-sc-css-line-clamp-3_g3dy1")
5    price_tag = item.find("span", class_="_cDEzb_p13n-sc-price_3mJ9Z")
6    link_tag = item.find("a", class_="a-link-normal")
7    title = title_tag.get_text(strip=True) if title_tag else "N/A"
8    price = price_tag.get_text(strip=True) if price_tag else "N/A"
9    url = "https://www.amazon.com" + link_tag["href"] if link_tag else "N/A"
10    products.append({"Title": title, "Price": price, "URL": url})

警告： _cDEzb_ 開頭的 class 名稱其實是 Amazon 重新產生的 CSS module 雜湊值，會不定期變動。相對來說，gridItemRoot 這個 ID 和 a-link-normal class 比較穩定，但在實際執行前，還是要先用 DevTools 確認選擇器是否有效。

步驟 4：匯出成 CSV

1df = pd.DataFrame(products)
2df.to_csv("amazon_best_sellers.csv", index=False)
3print(f"已抓取 {len(products)} 筆商品")

實際效果與可能踩雷的地方

在我的測試中，這個方法只抓到大約 30 筆商品，不是程式有 bug，而是 Amazon 的延遲載入機制造成的。初始頁面只會渲染約 30 筆商品，其餘內容要捲動後才會出現，而 requests 無法執行 JavaScript，所以看不到後面那些資料。

其他限制還包括：

如果沒有代理輪換，很快就會被封 IP（我大約連續請求 15 次就被擋了）
Amazon 只要更新頁面版面，CSS 選擇器就可能失效，而且他們確實常常這麼做
預設不處理分頁

如果你是想學 Python 抓取，這方法很適合；但要拿來正式使用，穩定度就不夠了。

方法 2：用 Selenium 抓 Amazon Best Sellers

Selenium 的做法是直接開一個真實瀏覽器來處理延遲載入問題——設定起來比較重，但它可以把每頁 50 筆都抓完整。

步驟 1：安裝 Selenium

1pip install selenium pandas

好消息是，從 Selenium 4.6+ 開始，你不再需要 webdriver-manager。Selenium Manager 會自動處理 driver 下載。

1from selenium import webdriver
2from selenium.webdriver.chrome.options import Options
3from selenium.webdriver.common.by import By
4from selenium.webdriver.common.keys import Keys
5import time
6import pandas as pd
7options = Options()
8options.add_argument("--headless=new")
9options.add_argument("--window-size=1920,1080")
10options.add_argument("--disable-blink-features=AutomationControlled")
11driver = webdriver.Chrome(options=options)

--headless=new 這個參數（Chrome 109+ 才有）使用和有視窗模式相同的渲染流程，比較不容易被 Amazon 偵測出來。

步驟 2：捲動頁面以突破延遲載入

這就是 Selenium 值得多花一點設定時間的原因。Amazon Best Sellers 一開始只載入約 30 筆商品，其餘內容要在捲動後才會出現。

1def scroll_page(driver, scrolls=5, delay=2):
2    for _ in range(scrolls):
3        driver.find_element(By.TAG_NAME, "body").send_keys(Keys.PAGE_DOWN)
4        time.sleep(delay)
5driver.get("https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/")
6time.sleep(3)
7scroll_page(driver)

捲動後，DOM 裡應該會完整出現 50 筆商品。我測試時發現，連續按 5 次 Page Down、每次間隔 2 秒就足夠，但實際情況還是要視你的網路速度調整。

步驟 3：擷取商品資料

1items = driver.find_elements(By.ID, "gridItemRoot")
2products = []
3for item in items:
4    try:
5        title = item.find_element(By.CSS_SELECTOR, "div._cDEzb_p13n-sc-css-line-clamp-3_g3dy1").text
6    except:
7        title = "N/A"
8    try:
9        price = item.find_element(By.CSS_SELECTOR, "span._cDEzb_p13n-sc-price_3mJ9Z").text
10    except:
11        price = "N/A"
12    try:
13        url = item.find_element(By.CSS_SELECTOR, "a.a-link-normal").get_attribute("href")
14    except:
15        url = "N/A"
16    products.append({"Title": title, "Price": price, "URL": url})

每個欄位都包在 try/except 裡很重要，因為有些商品可能缺貨或欄位不完整，你不會希望其中一個壞元素直接讓整個抓取流程崩掉。

步驟 4：處理分頁

Amazon 會把 100 筆 Best Sellers 分成兩頁，網址結構也不同：

1urls = [
2    "https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/",
3    "https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/ref=zg_bs_pg_2_electronics?_encoding=UTF8&pg=2"
4]
5all_products = []
6for url in urls:
7    driver.get(url)
8    time.sleep(3)
9    scroll_page(driver)
10    # ... 如上方擷取商品資料 ...
11    all_products.extend(products)
12driver.quit()

實際效果

在我的測試裡，Selenium 成功抓到每頁完整 50 筆商品，明顯勝過 requests + BS4。缺點是速度慢很多——每頁大約要 45 秒（包含捲動等待時間），而且如果沒有代理輪換，跑太多次還是會被標記。即使加了反偵測參數，Selenium 仍可能被 Amazon 的機器人偵測系統識別；如果你要大規模使用，還得再加上其他措施（見下方的防封鎖策略）。

其他痛點還有：

WebDriver 版本不一致的情況偶爾還是會發生，雖然 Selenium Manager 已經讓這件事少很多
Amazon 一改 DOM 結構，CSS 選擇器就要重寫
記憶體用量高——每個瀏覽器實例大約吃掉 200–400MB RAM

方法 3：用 Scraping API 抓 Amazon Best Sellers

Scraping API 就是「把麻煩的部分外包出去」的做法。像 Scrape.do、Oxylabs、ScrapingBee 這些服務，會幫你處理代理輪換、JavaScript 渲染和反機器人措施；你只要送出網址，就能拿回 HTML 或 JSON。

運作方式

你把目標網址送到 API 端點，API 會在它們的基礎設施上用真實瀏覽器渲染頁面、輪換代理、處理 CAPTCHA，然後回傳乾淨的 HTML。接著你再用 BeautifulSoup 解析回來的 HTML 就好，流程和方法 1 類似。

價格現實檢查

以下是幾家主流 API 以最佳方案計算，每 1,000 次 Amazon 請求的成本：

供應商	每 1,000 次請求成本	備註
Scrape.do	約 $0.19	固定費率，不額外倍增
Oxylabs	約 $1.80	JavaScript 渲染有 5 倍倍率
ScrapingBee	約 $4.90	進階功能倍率約 5–25 倍
Bright Data	$5.00 以上	資料最完整（每商品 686 個欄位），但速度最慢（約 66 秒/請求）

優缺點

優點： 穩定性高（Amazon 上頂級供應商約有）、不用自己維護 driver、會自動處理反機器人機制、擴充性好。

缺點： 按請求付費，量一大成本會快速累積；你還是得自己寫解析程式；CSS 選擇器失效的風險依舊存在。若以每月 100,000 頁來算，自建與外包的總成本差異非常驚人：自行開發三年約需 ——相當於省下 71%。

通常每月請求量落在 50 萬到 100 萬之間時，會是損益平衡點；低於這個範圍，API 節省的時間通常遠遠大於成本。

方法 4：用 Thunderbit 抓 Amazon Best Sellers（不用 Python）

先說清楚：我在 Thunderbit 工作，所以這段請自行帶著脈絡看。不過我真的把四種方法連續實測了一遍，從開始到拿到資料的時間差異非常明顯。

是一款以 Chrome 擴充功能形式運作的 AI 網頁爬蟲。核心概念很簡單：你不用寫 CSS 選擇器或 Python 程式，AI 會直接讀取頁面，自己判斷要抓哪些資料。針對 Amazon Best Sellers，Thunderbit 甚至提供可直接使用的預建範本，一鍵就能跑。

步驟 1：安裝 Thunderbit Chrome 擴充功能

前往並點選「加到 Chrome」。接著註冊免費帳號——免費方案就有足夠的額度讓你先試用。

步驟 2：打開 Amazon Best Sellers 頁面

在 Chrome 中開啟任一 Amazon Best Sellers 分類頁，例如： https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/

步驟 3：點選「AI Suggest Fields」

打開 Thunderbit 側邊欄，點擊「AI Suggest Fields」。AI 會分析頁面結構，並自動建議欄位：Product Name、Price、Rating、Image URL、Vendor、Product URL 和 Rank。我的測試中，它大約 3 秒就正確辨識出所有相關欄位。

你可以重新命名、刪除或新增欄位。你甚至可以為每個欄位加自訂 AI 提示詞，例如輸入「分類為 Electronics/Apparel/Home」，讓每個商品自動加上分類標籤。

步驟 4：點選「Scrape」

按下「Scrape」按鈕後，Thunderbit 會把頁面上的商品資料整理成結構化表格。在雲端模式下，它可以同時平行處理最多 50 個頁面，自動處理延遲載入與分頁。

步驟 5：免費匯出

點選「Export」，選擇你要匯出的地方：Excel、Google Sheets、Airtable 或 Notion。所有方案的匯出都是免費的，沒有任何隱藏費用。

從開啟頁面到拿到完整試算表，整個流程大約只花我 90 秒。相比之下，方法 1 約花 20 分鐘（還包含排除延遲載入問題）、方法 2 約花 35 分鐘（包含 Selenium 設定）、方法 3 約花 15 分鐘（包含 API 帳號設定）。

為什麼 Thunderbit 特別適合 Amazon

因為 AI 每次都會重新讀取頁面，所以它能自動適應版面變化——完全不需要維護 CSS 選擇器。這正好解決了抓取社群裡最常見的抱怨之一：「一般網頁爬蟲根本不夠用，你得為元素變動加一堆例外處理。」當 Amazon 的 DOM 改版時（而且它確實常改），你不需要手動更新任何東西。

雲端爬取模式也會透明地處理代理輪換、渲染與反機器人措施。對於想要「開了就能用」的人來說，這等於直接省掉整套防封鎖焦慮。

防封鎖實戰手冊：如何避免被 Amazon 擋下來

Amazon 的機器人偵測非常兇。我在測試時 IP 曾被暫時封鎖，論壇用戶也回報過類似情況：「到處都報錯，Amazon 甚至開始把我導回首頁。」如果你打算走 Python 路線（方法 1–3），這段非常重要。

以下是分層式策略，從基礎到進階：

1. 輪換 User-Agent 字串

一直送出同一組 User-Agent 會很可疑。請使用方法 1 範例中那 5 組以上的字串，每次請求隨機挑一個：

1headers = {"User-Agent": random.choice(USER_AGENTS)}

2. 在請求之間加入隨機延遲

固定延遲很容易被偵測出規律；隨機延遲比較安全：

1time.sleep(random.uniform(2, 5))

我發現每次請求間隔 2–5 秒，對小批次任務（少於 50 次請求）還算安全。若是更大規模的任務，建議提高到 3–7 秒。

3. 使用代理輪換

這是最關鍵的一步。顯示，住宅代理在 Amazon 上平均成功率約 94%，而資料中心代理只有約 59%，相差 35 個百分點。Amazon 的偵測機制包含 TLS 指紋辨識、行為分析與每個 IP 的速率限制，所以一般資料中心 IP 往往幾秒內就會被標記。

住宅代理雖然比較貴（依供應商不同，每 GB 約 $2–$12），但穩定性高很多。程式範例如下：

1proxies = {
2    "http": "http://user:pass@residential-proxy.example.com:8080",
3    "https": "http://user:pass@residential-proxy.example.com:8080"
4}
5response = requests.get(url, headers=headers, proxies=proxies)

4. 強化 Selenium 的瀏覽器指紋

1options.add_argument('--disable-blink-features=AutomationControlled')
2options.add_experimental_option("excludeSwitches", ["enable-automation"])
3options.add_experimental_option('useAutomationExtension', False)
4# 初始化 driver 後，移除 navigator.webdriver 標記
5driver.execute_cdp_cmd('Page.addScriptToEvaluateOnNewDocument', {
6    'source': "Object.defineProperty(navigator, 'webdriver', {get: () => undefined})"
7})

5. 管理 Session 與 Cookies

在多次請求之間保留 cookies，能讓爬蟲看起來更像真實使用者的瀏覽 session：

1session = requests.Session()
2# 先造訪首頁，取得較自然的 cookies
3session.get("https://www.amazon.com", headers=headers)
4time.sleep(2)
5# 再抓目標頁面
6response = session.get(target_url, headers=headers)

6. 什麼時候乾脆別折騰了

如果你不想自己管理這些細節，Thunderbit 的雲端爬取會自動處理代理輪換、渲染與反機器人措施。Scraping API 也大多會自動幫你處理上述問題。以我的經驗來看，光是除錯防封鎖問題所花的時間，常常比寫真正的抓取程式還長，所以「開了就能用」的方案確實有實際 ROI。

子頁面補強：抓取商品詳情頁，取得更豐富的資料

Best Sellers 列表頁只會顯示基本資訊——標題、價格、評分、排名。但如果你是做 FBA 研究，真正有價值的資料其實在每個商品的詳情頁。只抓列表頁，你會少掉這些重要欄位：

欄位	列表頁	商品詳情頁
商品名稱	✅	✅
價格	✅	✅
評分	✅	✅
BSR 排名	✅	✅（含子分類排名）
品牌	❌	✅
ASIN	❌	✅
首次上架日期	❌	✅
尺寸 / 重量	❌	✅
賣家數量	❌	✅
項目式特色描述	❌	✅
Buy Box 擁有者	❌	✅

其中「首次上架日期」特別有價值——它能告訴你商品在市場上已經存在多久，這對競爭分析是非常重要的訊號。而了解賣家數量與 Buy Box 擁有者，則能幫助你判斷某個商品利基市場值不值得進場（如果 Amazon 自己握有超過 30% 的 Buy Box 份額，競爭通常非常困難）。

Python 做法：逐一走訪商品網址

在從列表頁蒐集到商品 URL 後，你可以加上延遲，逐一前往每個商品頁：

1for product in products:
2    time.sleep(random.uniform(3, 6))
3    detail_response = session.get(product["URL"], headers={"User-Agent": random.choice(USER_AGENTS)})
4    detail_soup = BeautifulSoup(detail_response.text, "html.parser")
5    # 擷取品牌
6    brand_tag = detail_soup.find("a", id="bylineInfo")
7    product["Brand"] = brand_tag.get_text(strip=True) if brand_tag else "N/A"
8    # 從頁面原始碼或 URL 擷取 ASIN
9    # 從商品資訊表格擷取首次上架日期
10    # ... 其他欄位 ...

提醒一下：如果你一次打 100 個商品詳情頁，封鎖風險會大幅提高。記得把代理輪換與更長的延遲納入預算。

Thunderbit 做法：一鍵抓取子頁面

當你把列表頁抓成表格後，在 Thunderbit 裡點選「Scrape Subpages」，AI 就會逐一造訪每個商品 URL，並自動補上更多欄位——品牌、ASIN、規格、特色等。完全不用再寫程式、選擇器或額外設定。這對需要完整採購資訊、但不想自己維護詳情頁解析器的電商團隊尤其實用。

自動化週期性抓取：長期監測 Best Sellers

一次性抓取當然有用，但真正的競爭優勢來自持續監控。追蹤哪些商品在上升或下滑、提前發現趨勢、觀察數週或數月的價格變化——這些才是把「隨手查資料」變成「數據驅動決策」的關鍵。

Python 做法：用 Cron 排程

在 Linux / Mac 上，你可以用 cron 排程 Python 腳本。以下是每天早上 8 點抓一次的 crontab 範例：

10 8 * * * /usr/bin/python3 /home/user/amazon_scraper.py >> /home/user/logs/scrape.log 2>&1

如果你要每週一早上 9 點抓取：

10 9 * * 1 /usr/bin/python3 /home/user/amazon_scraper.py >> /home/user/logs/scrape.log 2>&1

在 Windows 上，可以用工作排程器完成相同事情。如果你想全天候排程，又不想讓筆電一直開著，可以部署到 VPS 或 AWS Lambda——但這會增加基礎設施的複雜度。

另外也建議加上日誌與錯誤通知，避免任務失敗卻沒人發現。沒有什麼比兩週後才發現爬蟲早就壞掉更糟的了。

Thunderbit 的 Scheduled Scraper 讓你直接用自然語言描述間隔——輸入「每週一早上 9 點」或「每天早上 8 點」，AI 就會理解排程。任務會在 Thunderbit 的雲端伺服器上執行（不需要瀏覽器或電腦一直開著），資料也能自動匯出到 Google Sheets 或 Airtable。這就等於建立了一個即時監控儀表板，而且完全不用管伺服器，對想長期掌握狀況、又不想承擔 DevOps 成本的營運團隊來說非常理想。

抓 Amazon 時的法律與倫理考量

我不是律師，以下內容也不是法律建議。但如果在教學中完全不提法律風險，那就太不負責任了——論壇用戶也明確提到 ToS 風險，而且這是有原因的。

Amazon 的 robots.txt： 截至 2026 年，Amazon 的 robots.txt 含有 80 多個特定 Disallow 路徑，但 /gp/bestsellers/ 並沒有被標示為一般使用者代理的明確封鎖路徑。不過，35+ 個 AI 專用 user agents（例如 ClaudeBot、GPTBot、Scrapy 等）則會直接被套用 Disallow: /。沒有被特別禁止，不代表 Amazon 就默許你抓取。

Amazon 的服務條款： Amazon 的（2025 年 5 月更新）明確禁止在未經書面許可的情況下，「使用任何自動化程序或技術來存取、取得、複製或監控 Amazon Website 的任何部分」。這不是紙上談兵——Amazon 已於 2025 年 11 月對，指控其未經授權進行自動化存取，且已獲得初步禁制令。

hiQ v. LinkedIn 先例： 在（第九巡迴法院，2022）一案中，法院認定抓取公開可得資料，可能不違反《電腦詐欺與濫用法》（CFAA）。但 hiQ 最終仍和解並同意停止抓取——即使你在 CFAA 上勝訴，也不代表就不會面臨違反合約的主張。

實務建議：

只抓公開可得資料（價格、BSR、商品標題——不要碰個資）
尊重速率限制，不要對伺服器造成負荷
將資料用於正當的競爭情報分析
大規模抓取前，先諮詢自己的法律顧問
注意現在已有具備完整的隱私法規

Thunderbit 的雲端爬取使用的是標準、類似瀏覽器的請求模式，但你仍應先和自己的法律顧問確認合規性。

你該選哪一種方法？快速決策指南

簡單版如下：

「我正在學 Python，想做一個週末小專案。」 → 方法 1（requests + BeautifulSoup）。你會學到很多關於 HTTP 請求、HTML 解析和 Amazon 反機器人防線的知識。
「我需要抓 JavaScript 很重的頁面，或要處理登入狀態。」 → 方法 2（Selenium）。它比較重，但能處理動態內容。
「我要跑的是正式環境，而且規模不小。」 → 方法 3（Scraping API）。讓別人幫你管代理與渲染吧。當每月請求低於 50 萬時，通常更偏向 API。
「我不是工程師，只想兩分鐘內看到資料。」 → 方法 4（）。不用寫程式、不用選擇器、也不用維護。
「我需要長期監測，但不想管伺服器。」 → Thunderbit Scheduled Scraper。設定一次就能持續跑。

結論與重點整理

經過一整個週末的測試，真正留下來的結論是這些：

requests + BeautifulSoup 很適合學習，但受到延遲載入限制（50 筆商品只抓到約 30 筆）以及脆弱 CSS 選擇器的影響，不適合正式使用。

Selenium 解決了延遲載入問題，也能抓完整每頁 50 筆，但速度慢、吃記憶體，而且仍可能被 Amazon 的機器人防護偵測。

Scraping API 在正式規模抓取上提供了最佳穩定性——Amazon 上約有 ——但成本會累積，而且你還是需要自己寫解析程式。

Thunderbit 在拿到資料的速度上，明顯快了一大截。AI 可以自動處理版面變動、延遲載入、分頁與反機器人措施，幾乎不用任何設定。對非技術使用者，或需要持續拿資料、但不想承擔 DevOps 負擔的團隊來說，這是最實際的選擇。

最大的教訓是：Amazon 的反機器人機制和頻繁改版，意味著免維護方案在長期來看最省時間。你花在除錯壞掉選擇器、輪換代理上的每一小時，都是少掉真正分析的時間。

如果你想試試免寫程式的方法？提供的額度，足夠你抓幾個 Best Sellers 分類，親眼看看結果。比較偏好 Python 路線？上面的程式範例應該足以讓你上手。無論哪種方式，你都能把 Amazon Best Seller 資料放進試算表，而不是一直盯著瀏覽器分頁發呆。

想了解更多網頁爬蟲做法，可以參考我們的指南：、、以及。你也可以在觀看逐步教學影片。

延伸閱讀

我實測了 4 種用 Python 抓取 Amazon Best Sellers 的方法，結果竟然是……

試試 Thunderbit