Gemini 網頁爬蟲實戰指南：程式與無程式碼都能用

多數「gemini web scraping」教學讀起來都像是寫給同一種人看的：已經有 Python 開發環境、Pydantic schema，還對 async 函式庫很有主見的工程師。如果你就是這類人，那太好了——我們等一下就會講到程式碼。但如果你是做業務、行銷或電商營運，只是想從一堆網頁裡拿到結構化資料，卻不想先去搞懂 markdownify 是什麼，那你絕對不是少數。

Gemini 是 Google 的多模態 AI 模型家族，也正快速成為網頁資料擷取的熱門選擇之一。2025 年 Stack Overflow 開發者調查指出， 正在使用或準備使用 AI 工具，而由 LLM 驅動的爬取正是這波趨勢的重要一環。不過，「單一網址的酷炫 Demo」和「能處理分頁、子頁面、防機器人封鎖與凌亂 HTML 的正式流程」之間，差距其實很大。這篇指南會同時涵蓋 Python 程式路線與無程式碼路線，透過實際的 token 計算說明模型怎麼選，帶你處理多頁爬取——這也是很多教學會跳過的關鍵步驟——並誠實說明 Gemini 爬取會在哪些地方失效。看完之後，你會知道哪條路最適合你的工作流程，以及如何避開我看過開發者和商務使用者都踩過的坑。

什麼是 Gemini 網頁爬蟲？

Gemini 網頁爬蟲，指的是把某個網頁的內容——可以是 HTML、Markdown，甚至截圖——送進 Google 的 Gemini AI 模型，讓模型理解頁面內容並回傳結構化資料。沒有 CSS selector。沒有 XPath。也沒有那種網站只要一改版就全壞掉的脆弱規則。

核心流程大致如下：

1. 抓取頁面（可用 requests、無頭瀏覽器或 Chrome 擴充功能）
2. 清理並轉換內容（通常是 HTML → Markdown，以降低 token 成本）
3. 送入 Gemini，並附上描述你想要欄位的 schema
4. 接收結構化 JSON，可直接用於試算表、CRM 或資料庫

這跟傳統使用 BeautifulSoup 或 Selenium 的爬蟲很不一樣：你必須手寫 selector，例如 div.product-title > span.price，還得祈禱網站下週不會改版。Gemini 的讀法更接近人類——它能理解上下文、適應版面變動，並在沒有自訂規則的情況下處理混亂格式。

還有一點值得注意：Gemini 天生就是多模態模型。它能在同一個請求中處理文字、圖片、影片、音訊、PDF 和程式碼。這也開啟了很多其他 LLM 做不到的爬取方式，例如直接送截圖而不是 HTML。我們後面會談到這一點。

為什麼 Gemini 網頁爬蟲對商務團隊很重要？

如果你在想，為什麼行銷經理或電商分析師需要關心 LLM 和網頁爬蟲，答案很簡單：它能省下驚人的時間，而且網站一更新也不會立刻壞掉。

，從 2025 年約 10 億美元一路增長到 2030 年超過 20 億美元，而 AI 驅動的擷取是成長最快的區塊。這不是炒作，而是真實反映了團隊蒐集資料方式的轉變。

以下是 Gemini 爬取在日常商務工作流程中的實際用途：

實際上的好處有兩個。第一，你不用反覆撰寫、測試、除錯解析腳本——模型每次都會重新讀取頁面。第二，網站只要多了一個 <div>，你也不用每次都找工程師來重寫。Gemini 的免費額度幾乎等於零成本試驗，適合小規模任務：，而且不需要信用卡。

該選哪個 Gemini 模型？（Flash Lite、Flash、Pro）

不是所有 Gemini 模型都適合爬蟲。這是我希望每篇教學都會寫清楚的實務比較，因為選錯等級，不是浪費錢，就是拿到一堆垃圾資料。

目前三個 Gemini 2.5 模型都共享 1,048,576 token 的上下文視窗，而且都是多模態。差異主要在成本、速度，以及處理複雜擷取的能力。

（價格資料來自 。Batch API 為以上費率的 50% 折扣。）

Gemini 2.5 Flash Lite：快又便宜，但要注意缺漏

Flash Lite 是預算型選擇。非常適合簡單、扁平的資料——像是商品名稱、價格、單層列表——而且可以高吞吐量處理。不過，它在可選欄位、時間戳和巢狀資料上有已知問題。Google 論壇上一位開發者曾，當 schema 包含非必要屬性時，Flash Lite 會「完全失控」，一直輸出重複文字直到達到 token 上限。如果你的 schema 超過兩層巢狀，或某些頁面可能缺少欄位，Flash Lite 會非常耗 token，也會很磨人。

Gemini 2.5 Flash：大多數爬取任務的甜蜜點

如果是我開始做任何真正的爬取工作，我會先從 Flash 下手。它對結構化擷取處理得很好，也能處理分頁邏輯；雖然輸入成本大約比 Flash Lite 高 3 倍，但準確度的提升很值得。在 中，Flash 的表現和 Pro 差距不大，代表它很能應付爬蟲真正需要的推斷、標準化與扁平化工作。

Gemini 2.5 Pro：處理複雜資料時的最高準確度選擇

Pro 是精準型工具。當你要擷取深度巢狀 schema（例如：商品規格包含多組變體，每組又有尺寸、顏色和價格），或任何不能接受虛構欄位的資料（法律、金融、醫療），就該用它。它的輸入成本大約是 Flash Lite 的 12 倍，所以適合把準確度看得比價格更重要的任務。

成本實例：10,000 個商品頁面

假設你先把 HTML 預處理成 Markdown（這一步一定要做，下面會再說明），一般商品頁的 token 量會從原始 HTML 的約 20,000 tokens 降到 Markdown 的約 4,000 tokens。每頁輸出的 JSON 約 500 tokens。

如果不做 Markdown 預處理，而是直接餵原始 HTML（約 2 億 token 輸入），成本會暴增 4–5 倍。預處理是整個流程裡最有槓桿效益的一步。

程式碼 vs. 無程式碼：Gemini 網頁爬蟲的兩條路

這裡就是分岔點。如果你是開發者、要自己打造客製化流程，Python + Gemini API 會給你最大控制權。如果你是商務使用者、現在就要資料，而且不想碰終端機，那無程式碼 AI 爬蟲會更快。

是我們在 Thunderbit 推出的無程式碼方案——一個 Chrome 擴充功能，底層使用 AI（包含 Gemini、ChatGPT、Claude 等）來建議欄位、兩步完成爬取，並匯出到你想用的工具。下面我會把兩條路都講一遍。

如果你是以試算表為中心的使用者，Quadratic 也是值得認識的選項——它是一款 AI 試算表，可以在表格內直接執行 Gemini 驅動的網頁爬取。不過，如果你的工作流程起點是一個已知的網頁（例如商品列表、名錄、名單資料庫），Thunderbit 會更貼近使用者的直覺。

逐步教學：用 Python 做 Gemini 網頁爬蟲

這一段是寫給開發者的。如果你想看無程式碼路線，請直接跳到後面。

開始前須知：

• 難度： 中階（需要熟悉 Python）
• 時間需求： 第一次爬取約 20–30 分鐘
• 你需要準備： Python 3.10+、Google AI Studio 帳號（免費）、目標網址

第 1 步：建立 Python 環境與 Gemini API 金鑰

先建立專案資料夾與虛擬環境，接著安裝所需函式庫：

1mkdir gemini-scraper && cd gemini-scraper
2python -m venv venv && source venv/bin/activate
3pip install -U google-genai requests beautifulsoup4 markdownify pydantic

重要提醒： 到 2026 年唯一正確的 SDK 是 google-genai。舊版 google-generativeai 已在 2025-11-30 結束支援，現在屬於 deprecated。如果你在教學裡看到 import google.generativeai as genai，那段程式已經過時了。

接著前往 取得 API 金鑰。點選「Get API Key」，建立新的 key，並把它存成環境變數：

1export GEMINI_API_KEY="your-key-here"

做到這裡，你就已經有一個可用的 Python 環境，依賴套件都安裝好了，API 金鑰也準備完成。

第 2 步：抓取目標頁面的 HTML

使用 requests 抓頁面。這裡以商品頁為例：

1import requests
2url = "https://example.com/product/widget-pro"
3response = requests.get(url, headers={"User-Agent": "Mozilla/5.0"}, timeout=30)
4html = response.text

如果網站大量依賴 JavaScript 渲染，或有防機器人保護，requests.get() 可能只會拿到空殼頁面或 403。這部分的應對方式會在限制章節說明——不過對很多公開網站來說，這樣已經夠用了。

第 3 步：清理 HTML 並轉成 Markdown

這是多數教學會提到、卻很少量化的一步。一般商品頁的原始 HTML 大約有 20,000 tokens。經過 BeautifulSoup 清理和 Markdown 轉換後，通常只剩約 765–4,000 tokens，等於 的 token，實際上能省錢，也能降低幻覺。

1from bs4 import BeautifulSoup
2from markdownify import markdownify
3soup = BeautifulSoup(html, "html.parser")
4main = soup.select_one("main") or soup  # 只抓主要內容區
5markdown_content = markdownify(str(main))

select_one("main") 這行會移除頁首、頁尾、導覽列和腳本，避免浪費 token 也避免讓模型被雜訊干擾。如果網站沒有 <main> 標籤，可以試試 .product-detail、#content，或任何包住實際資料的區塊。

做完這一步，你應該會拿到一段乾淨的 Markdown，只包含該頁有意義的內容。

第 4 步：定義資料 schema 並送給 Gemini

使用 Pydantic 定義你想要回傳的結構。google-genai SDK 可以直接把 Pydantic 的 BaseModel 當作 response_schema：

1from google import genai
2from google.genai import types
3from pydantic import BaseModel
4class Product(BaseModel):
5    name: str
6    price: str
7    sku: str | None = None
8    description: str
9    sizes: list[str] = []
10    colors: list[str] = []
11client = genai.Client()  # 會從環境變數讀取 GEMINI_API_KEY
12response = client.models.generate_content(
13    model="gemini-2.5-flash",
14    contents=f"從這個頁面擷取商品資訊：\n\n{markdown_content}",
15    config=types.GenerateContentConfig(
16        response_mime_type="application/json",
17        response_schema=Product,
18    ),
19)
20product = response.parsed
21print(product)

根據，有幾個坑要注意：

• 不要在送給 Gemini 的 schema 裡使用 Field(default=...)，API 會丟出 ValueError。應該改成在型別層級寫 sku: str | None = None。
• 巢狀層級不要太深（最多 3 層）。太深的 schema 會讓 Flash 和 Flash Lite 產生遞迴輸出或括號未關閉的問題。
• 使用 Flash Lite 時，欄位最好都設為必填，並用空字串這類哨兵值代替省略，因為 Flash Lite 對可選欄位的處理。

做完這步後，你應該就會得到一個解析完成的 Product 物件，裡面是頁面的結構化資料。

第 5 步：匯出並儲存爬到的資料

把結果存成 JSON 或 CSV：

1import json
2with open("products.json", "w") as f:
3    json.dump(product.model_dump(), f, indent=2)

如果要送進 Google Sheets，可以使用 gspread。若是資料庫，則可依你使用的 ORM 進行序列化。Gemini 的結構化輸出很乾淨，通常可以直接接到大多數下游工具。

逐步教學：不用寫程式的 Gemini 網頁爬蟲（使用 Thunderbit）

這條路適合商務使用者，或是不想為了臨時爬蟲腳本花太多時間的開發者。

開始前須知：

• 難度： 初階
• 時間需求： 第一次爬取約 5 分鐘
• 你需要準備： Chrome 瀏覽器、（免費版可用）

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

前往 並點選「加到 Chrome」。用你的 Email 註冊，整個過程不到 1 分鐘。和上面 Python 的 15–30 分鐘設定相比，差很多。

第 2 步：打開目標頁面並點選「AI Suggest Fields」

前往你要爬取的網站——商品列表、房地產名錄、名單資料庫都可以。點擊瀏覽器工具列上的 Thunderbit 圖示，然後按下 「AI Suggest Fields」。

Thunderbit 的 AI 會自動讀取頁面，並建議欄位名稱與資料類型，例如「Product Name」、「Price」、「Rating」、「Image URL」。你可以調整欄位名稱、刪除不需要的欄位，或是為每個欄位加入自訂 AI 提示詞（例如「分類為 High/Medium/Low」或「翻譯成英文」）。

在真正開始爬取前，你就能先看到已設定欄位的表格預覽。

第 3 步：點選「Scrape」並檢查結果

只要一次點擊。Thunderbit 會自動處理分頁——不管是按「Next」的點擊式分頁，還是無限捲動——並把資料擷取成結構化表格。你可以選擇：

• 雲端爬取： 更快，可同時處理最多 50 頁。適合公開網站。
• 瀏覽器爬取： 在你已登入的瀏覽器分頁中執行。適合需要登入的網站（CRM、限制存取的名錄、內部工具）。

結果會直接顯示在擴充功能側邊欄的表格中。匯出前先快速掃一下，看看有沒有明顯錯誤。

第 4 步：匯出到 Excel、Google Sheets、Airtable 或 Notion

點擊匯出按鈕，選擇你要的格式。Thunderbit 可直接匯出到 Excel、Google Sheets、Airtable 和 Notion，而且免費、不會擋在付費牆後面。圖片欄位也能直接上傳到 Notion 與 Airtable 的圖片庫，對於抓商品照片或頭像特別方便。

不用解析 JSON，不用寫腳本。資料拿到手就能直接使用。

使用 Gemini 做多頁與子頁面爬取

多數教學講到單一網址就悄悄結束了。但真實世界的爬蟲工作不會這麼簡單。

要抓 500 個有分頁、還帶詳細子頁面的商品頁，已經是一項完整任務了——而單一 URL Demo 跟這種實務情境之間的差距非常大。

用 Gemini API 處理分頁（程式路線）

如果是頁碼型 URL（最常見），就用迴圈一路抓到沒有結果為止：

1import time
2all_products = []
3for page in range(1, 101):  # 最多 100 頁
4    url = f"https://example.com/products?page={page}"
5    md = fetch_clean(url)  # 前面做好的 HTML→Markdown 函式
6    response = client.models.generate_content(
7        model="gemini-2.5-flash-lite",  # 列表頁用便宜的就好
8        contents=f"擷取商品名稱與網址：\n\n{md}",
9        config=types.GenerateContentConfig(
10            response_mime_type="application/json",
11            response_schema=list[ListingItem],
12        ),
13    )
14    items = response.parsed
15    if not items:
16        break
17    all_products.extend(items)
18    time.sleep(4)  # 尊重免費額度的速率限制

對於 cursor-based 或無限捲動的網站，你需要先攔截前端呼叫的 XHR API（打開瀏覽器 Network 分頁查看），然後直接對那個 endpoint 做迴圈。這比重複渲染頁面便宜得多，而且只有在欄位需要 LLM 清理時才把資料送進 Gemini。

這裡要特別留意 token 成本——每一頁都會把帳單往上疊。列表頁用 Flash Lite 就好，只有在細節頁面擷取時才升級到 Flash。

用 Gemini 擷取子頁面以取得更豐富的資料（程式路線）

經典的兩階段模式：第一階段先從列表頁抓 URL，第二階段再逐一前往詳細頁抓更完整的資訊。

1# 第一階段：用便宜的 Flash Lite 收集 URL
2class Listing(BaseModel):
3    product_urls: list[str]
4listing = client.models.generate_content(
5    model="gemini-2.5-flash-lite",
6    contents=f"擷取商品網址：\n{listing_md}",
7    config=types.GenerateContentConfig(
8        response_mime_type="application/json",
9        response_schema=Listing,
10    ),
11).parsed
12# 第二階段：用 Flash 擷取詳細資料
13class ProductDetail(BaseModel):
14    name: str
15    price: str
16    specs: dict[str, str]
17    reviews: list[str]
18for url in listing.product_urls:
19    md = fetch_clean(url)
20    detail = client.models.generate_content(
21        model="gemini-2.5-flash",
22        contents=f"擷取商品詳細資訊：\n{md}",
23        config=types.GenerateContentConfig(
24            response_mime_type="application/json",
25            response_schema=ProductDetail,
26        ),
27    ).parsed
28    # 儲存 detail...
29    time.sleep(0.5)

這種做法可以運作，但周邊工作不少：URL 去重、錯誤處理、速率限制、重試機制、把原始 HTML 快取起來以便 schema 改動後不用重新抓。50 頁還算可控，但 5,000 頁就已經是在建基礎設施了。

無程式碼替代方案：Thunderbit 內建分頁與子頁面爬取

Thunderbit 會自動處理點擊式與無限捲動式分頁，不用你自己寫迴圈。若要補強子頁面，"Scrape Subpages" 功能會自動前往列表中每個詳細頁，並把更深入的欄位補進原始表格。只要點一下，不用寫腳本。

雲端爬取模式可同時處理最多 50 頁，對於抓商品目錄或房地產名錄這種大規模任務差很多。對於不想管理 Python 迴圈和重試邏輯的人來說，這會是最實際的選擇。（若想了解更多，我們另外有完整教學。）

截圖爬取：Gemini 的多模態捷徑

這裡有一個大多數教學完全忽略的做法：把網頁的截圖送到 Gemini 的 vision API，而不是直接送 HTML。有開發者，單張截圖只要約 258 tokens——跟即使已經清理過的 Markdown 相比，也便宜得多。對簡單擷取來說，這是一個很大的成本優勢。

如何使用 Gemini Vision API 做網頁爬取

先用 Playwright 擷取截圖、編碼，再送給 Gemini：

1from playwright.sync_api import sync_playwright
2from google import genai
3from google.genai import types
4from pydantic import BaseModel
5class Product(BaseModel):
6    title: str
7    price: str
8with sync_playwright() as p:
9    page = p.chromium.launch().new_page()
10    page.goto("https://example.com/product/widget-pro")
11    page.wait_for_load_state("networkidle")
12    png_bytes = page.screenshot(full_page=False)  # 只抓首屏
13client = genai.Client()
14resp = client.models.generate_content(
15    model="gemini-2.5-flash",
16    contents=[
17        {"inline_data": {"mime_type": "image/png", "data": png_bytes}},
18        "請把商品標題和價格擷取成 JSON。",
19    ],
20    config=types.GenerateContentConfig(
21        response_mime_type="application/json",
22        response_schema=Product,
23    ),
24)
25print(resp.parsed)

根據 Google 的，若圖片長寬都 ≤ 384 像素，成本是 258 tokens。更大的圖片會被切成 768×768 區塊，每塊 258 tokens。短的首屏截圖（258–1,600 tokens）很划算——但如果是很長的整頁截圖（約 5,000 tokens），反而可能比乾淨的 Markdown（約 765–1,200 tokens）更不划算。

截圖爬取的限制

• 表格密集時精度較低： 多欄版面、小字體、元素重疊時，容易只讀到一部分——不是幻覺，而是標籤漏讀、欄位對不齊。
• 不能點連結： Vision 會回傳文字，不會回傳可點擊的超連結。無法做分頁，也無法抓子頁面。
• 解析度上限： 小於約 10px 的文字常常會辨識錯誤。Google 會將長邊縮到約 1,568 px。
• 擷取成本較高： Playwright 啟動加上等待 network idle，每頁約要 2–5 秒，量大時會累積不少時間。

截圖爬取特別適合 JS 很重的頁面、被機器人封鎖的網站（requests.get() 會拿到 403，但瀏覽器能正常顯示），以及資料藏在圖表或圖片中的頁面。若是長篇、文字很多的頁面，Markdown 仍然更適合。

Thunderbit 的圖片與 PDF 爬取也採用類似的 AI vision 方法——直接丟圖片或 PDF，它就能回傳結構化表格，不需要自己處理截圖腳本或 base64。可延伸閱讀：。

Gemini 網頁爬蟲失效時怎麼辦？

Gemini 是擷取引擎，不是抓取引擎。如果你無法先把頁面內容送到 Gemini，它也幫不上忙。就是這麼直接。

有幾種常見情況會讓整個方法失敗，而大多數教學都把它們當附註帶過。我寧可直接講清楚。

這裡有幾點值得多補充。

防機器人現在已經會針對 LLM 進行辨識。 Cloudflare 從 2025 年 7 月起，前五個月就擋下 4160 億次 AI bot 請求。Datadome 也在 2025 年加入 LLM 專用偵測，並看到 LLM bot 流量成長四倍。對受 Datadome 保護的網站來說，單純 requests.get() 加 Gemini 幾乎等於失效。問題不只是 IP，而是指紋；就算你換 IP，只要 TLS 指紋一看就是「Python requests」，還是會被擋。

幻覺問題很隱性。 受過「要幫助使用者」訓練的 LLM，往往會把可選欄位補成看似合理的內容，而不是回傳 null。我看過模型從 URL slug 推測品牌、從 TLD 猜貨幣，甚至從 skeleton loader 寫出看似合理但其實是假的評論數。可行的防護方式包括：嚴格的 Pydantic schema、帶驗證回饋的重試迴圈、檢查擷取值是否真的出現在來源 HTML 裡的 grounding 驗證器，以及（Flash 擷取，Pro 抽樣驗證）。

1M 上下文視窗不代表可以真的用到 1M。 與其他研究都指出，推理品質會在遠低於 token 上限時就開始下降。對結構化擷取來說，實務上的上限應該抓在約 200K–300K tokens。

決策樹：你該用哪個工具？

• 低量 + 簡單頁面 + 開發者 → Gemini API 免費額度 + Python
• 中量 + 複雜 schema + 開發者 → Gemini 2.5 Flash 付費版 + Python + 結構化輸出 + 預處理
• 任何量 + 非開發者 + 需要登入或分頁很多 →
• 超大量 + 強防機器人 + 關鍵任務 → 託管式爬蟲基礎設施（代理服務）+ Gemini 作為擷取層

Gemini 網頁爬蟲：省時省錢的小技巧

不管你是寫 Python 還是點按鈕，以下技巧都能幫你少走很多冤枉路。

1. 在送進 Gemini 前，一律先把 HTML 預處理成 Markdown。 通常可省 ，若再搭配 BeautifulSoup 先做裁切，省 95% 也有可能。
2. 只用 google-genai。 不要再用已停用的 google-generativeai 套件。
3. Flash Lite 只適合扁平 schema 才開始用。 一旦出現巢狀結構或可選欄位，立刻升級到 Flash。
4. 不要在傳給 Gemini 的 Pydantic schema 裡使用 Field(default=...)。 改成在型別層級寫 sku: str | None = None。
5. Pydantic + response_schema 很關鍵。 它既是契約，也是避免幻覺的防線。
6. 超過 1,000 頁的任務要用 。 可打 50% 折扣，而且不會占用即時 RPM。
7. 擴大量產前，先人工抽查 10–50 筆樣本。 準確度漂移往往在正式看資料前根本看不出來。
8. 把原始 HTML 快取到磁碟。 schema 一改，不需要重新抓頁面。
9. 每一列都保留來源 URL。 這樣之後只要重抓單頁，不必整批重跑。
10. 如果你是無程式碼使用者：在 Thunderbit 的每個欄位使用自訂 AI 提示詞，把 prompt engineering 直接搬到試算表層級——可針對欄位做翻譯、分類、摘要。

還有一點：不要把免費額度直接上線到正式環境。 2025 年 12 月限額已經下修 50–80%，未來也可能在沒有通知的情況下再次調整。

結語

從單一 URL 的 Gemini Demo，到正式可用的生產流程，兩者之間的距離比大多數教學說的都大。

Python + Gemini API 路線，讓開發者可以完全掌控模型選擇、預處理、分頁與 schema 設計。無程式碼路線——像是 這類工具——則讓商務使用者不用碰終端機，也能拿到同樣的結構化資料擷取能力。

我會整理成以下幾點：

• 模型選擇很重要。 Flash Lite 適合大量任務，Flash 適合平衡，Pro 適合複雜場景。不要只選最便宜的，然後再納悶資料為什麼錯。
• 多頁與子頁面爬取，才是教學常跳過、但真實工作真正會遇到的部分。 這篇涵蓋的兩條路線都有補上這個缺口。
• 誠實面對限制，才能省時間。 如果網站會擋 API 請求，再好的 prompt engineering 都沒用。要選對工具，而不是選看起來最炫的工具。
• 把 HTML 預處理成 Markdown，是最有槓桿效益的優化。 它不只可把成本降低 75% 以上，還能減少幻覺。

如果你想試試無程式碼路線， 讓你可以先爬幾個頁面，直接看看成果。如果你偏好寫程式，Gemini 的免費 API 額度也足夠你在一個下午內做出原型。無論哪一種，都會比手動複製貼上快得多。如果你想進一步了解 或 ，我們部落格裡也有更完整的整理。

常見問題

使用 Gemini 做網頁爬蟲要多少錢？

Gemini API 有免費額度，大約是 Pro 每天 100 次、Flash 每天 500 次、Flash Lite 每天 1,000 次（以 2026 年初為準；這些限制在 2025 年 12 月已下調）。在付費方案下，若先把 HTML 預處理成 Markdown，抓 10,000 個商品頁大約要花 $1.50（Flash Lite）、$6（Flash）或 $25（Pro）。如果不做預處理，成本會跳高 4–5 倍。Batch API 也提供非即時任務 50% 折扣。

Gemini 可以爬需要登入的網站嗎？

Gemini API 本身不能登入網站——它只會處理你送給它的內容。你必須自己用已登入的 session 抓到 HTML（例如透過無頭瀏覽器與已保存的 cookies）。Thunderbit 的瀏覽器爬取模式可以原生處理這件事：它會在你已登入的 Chrome 分頁中執行，所以你在瀏覽器裡看得到的網站，Thunderbit 通常也能爬。

用 Gemini 網頁爬蟲合法嗎？

是否合法，要看網站的服務條款、資料類型，以及你所在的司法管轄區。在美國，hiQ v. LinkedIn 和 Meta v. Bright Data 之後，對公開可存取資料、且未登入狀態下的爬取，一般被認為是可接受的——但每個案例都要看具體事實。登入後頁面的爬取法律風險更高。歐盟使用者的個人資料，不論網站是否公開，都受 GDPR 規範。請務必遵守 robots.txt 和服務條款，並避免在沒有合法依據的情況下抓取個資。

我可以用 Gemini 爬動態、JavaScript 很重的網站嗎？

可以，但你必須先把 JavaScript 渲染完成——可透過無頭瀏覽器（Playwright、Puppeteer）或直接攔截網站的 API endpoint。拿到渲染後的 HTML 之後，再像平常一樣清理並送給 Gemini。或者你也可以改用 Gemini 的 vision API 做截圖爬取——只要瀏覽器看得到，Gemini 就看得到。Thunderbit 在 Cloud 和 Browser 兩種模式下，都能自動處理 JavaScript 渲染頁面。

用 Gemini 做爬取，和用 Thunderbit 這類專門工具有什麼差別？

Gemini 是擷取引擎——它負責理解內容並回傳結構化資料。它不會自己上網、處理分頁、管理驗證，也不會直接匯出到試算表。你仍然需要某個工具把頁面內容送給 Gemini，還要有工具把輸出結果變成有用的東西。像 這類專門工具，則把抓取、渲染、AI 擷取、分頁、子頁面補強與匯出整合成一套，不需要自己搭管線。

延伸閱讀