在 GitHub 上以「zillow scraper」為關鍵字搜尋，目前會跳出 409 個 repository。數字看起來很豐盛，但把時間軸拉開就沒那麼樂觀了：其中 264 個 已經超過一年沒有任何 push。
我把這些 repo 一個一個看過，clone 下來拿真實的 Zillow 頁面測試，順便翻了各家的 GitHub issues 和 Reddit 上的討論串，想知道開發者這一輪又是卡在哪裡。結果幾乎是同一套劇本：某個 repo 在能跑的那幾個月衝出一波 stars，等到 Zillow 換掉 DOM 結構、把反機器人防線再拉高一階，或是悄悄停掉某個內部 API 端點，它就無聲無息地躺平。有位 Reddit 使用者的講法很精準：「爬取專案需要持續維護，因為頁面或 API 會變動。」
以下這份審查，就是我當初第一次 clone Zillow 爬蟲 repo 之前會想看到的東西——2026 年哪些真的還能回傳資料、哪些早就壞了、壞在哪個環節，以及什麼時候應該直接放棄 GitHub 這條路，改用 Thunderbit 這類現成工具比較划算。
Zillow 爬蟲 GitHub 專案在做什麼？什麼人在找它
「Zillow 爬蟲」泛指任何能自動從 Zillow 網站蒐集房源資料的腳本或工具。抓的欄位通常是價格、地址、床數、衛浴數、坪數、Zestimate、刊登狀態、上架天數，能力好一點的還會往詳情頁鑽，把價格歷史或稅務紀錄一起帶回來。
會跑到 GitHub 找方案的人，理由都差不多：免費、開源、可以自己改。fork 一份、把欄位調成自己要的樣子、輸出接進既有的資料流程——聽起來確實是最理想的組合。
實際的使用族群大致有四種：
- 房地產投資人：跨郵遞區號盯著交易機會，靠降價幅度、Zestimate 差距和上架天數篩掉不值得看的物件
- 經紀人：整理開發名單，需要房源網址、仲介聯絡資訊，以及刊登狀態的變化
- 市場研究員與分析師：要的是能比較的結構化資料——地址、每平方英尺價格、成交價與開價比、庫存數量
- 營運團隊：固定頻率監控不同市場的價格與庫存水位
這幾種人要的東西其實是同一件：可重複取得的結構化資料，而不是一次性的複製貼上。爬蟲吸引人的地方在這裡；repo 一失效、維護成本立刻反噬的痛點，也在這裡。
2026 年 Zillow 爬蟲 GitHub Repo 審查：誰還活著
我把 star 數與 fork 數最高的 Zillow 爬蟲 repo 撈出來，逐一確認最後一次 commit 的日期、讀完 open issues，再拿實際的 Zillow 頁面跑一遍。判定標準訂得很單純：在 2026 年 4 月的測試裡，能從 Zillow 搜尋結果頁或詳情頁回傳正確房源資料的，標成「可用」；跑得動但資料缺漏、翻沒幾頁就被擋的，算「部分可用」；完全跑不出東西，或維護者自己已經公告專案死亡的，就是「已失效」。
結論並不好看：十二到十八個月前還被推薦得很勤的那批 repo，多數現在已經默默壞掉。
精選比較表：Top Zillow 爬蟲 GitHub Repo
| Repo | 語言 | Stars | 最後 Push | 方法 | 2026 狀態 | 主要限制 |
|---|---|---|---|---|---|---|
| johnbalvin/pyzill | Python | 96 | 2025-08-28 | Zillow 搜尋／詳情擷取 + proxy 支援 | 部分可用 | README 寫著「請使用輪替住宅代理」。issues 包含 Cloudflare 封鎖、透過 proxyrack 出現 403，即使有 proxy 也會碰到 CAPTCHA。 |
| johnbalvin/gozillow | Go | 10 | 2025-02-23 | 針對房源 URL／ID 與搜尋方法的 Go 函式庫 | 部分可用 | 與 pyzill 同一位維護者，但採用度低、issue 也很少，可信度較低。 |
| cermak-petr/actor-zillow-api-scraper | JavaScript | 59 | 2022-05-04 | 使用內部 Zillow API 遞迴抓取的託管 actor | 部分可用（風險高） | 設計很巧妙——透過遞迴切分地圖邊界來繞過結果上限。但 GitHub repo 自 2022 年後就沒再 push。某個 issue 標題就是：「這個還能用嗎？」 |
| ChrisMuir/Zillow | Python | 170 | 2019-06-09 | Selenium | 已失效 | README 直接寫明：「截至 2019 年，這段程式對大多數使用者已不再可用。」Zillow 會偵測 webdriver，然後不斷送出 CAPTCHA。 |
| scrapehero/zillow_real_estate | Python | 152 | 2018-02-26 | requests + lxml | 已失效 | issues 包含「回傳空資料集」、「.csv 檔沒有輸出」以及「這個 repo 還有更新嗎？」 |
| faithfulalabi/Zillow_Scraper | Python/notebook | 30 | 2021-07-02 | 寫死的 Selenium | 已失效 | 教學性專案，硬編碼到德州 Arlington 的租屋，不是通用型爬蟲。 |
| eswan18/zillow_scraper | Python | 10 | 2021-04-10 | 爬蟲 + 處理流程 | 已失效 | Repo 已封存。 |
| Thunderbit | 無程式碼（Chrome 擴充功能） | N/A | 持續更新 | AI 讀取頁面結構 + 預建 Zillow 範本 | 可用 | 不需要維護 GitHub repo。Zillow 版面一改，AI 也會自動適應。提供免費方案。 |
把整張表看完，會發現 GitHub 生態並非全然死寂，只是活著的程式碼被大量教學範例、歷史遺跡，以及包在 proxy 服務外面的薄薄一層包裝給淹沒了。
「可用」「部分可用」「已失效」的界線在哪
這三個標籤比 star 數重要得多，所以定義要講清楚：
- 可用：測試當天能從 Zillow 搜尋頁和／或詳情頁穩定回傳正確資料，維護者也沒有把專案標成停止支援
- 部分可用：跑得動，但資料有缺、翻幾頁後被擋，或只在特定頁型有效——通常還得自備 proxy 基礎設施並持續調校
- 已失效：抓不到資料、直接拋錯，或維護者與社群已明確標示不可用
一個 170 顆 stars 卻已失效的 repo，價值遠不如一個只有 10 顆 stars 但真的吐得出資料的 repo。人氣紀錄的是過去，不是現在的品質。
Zillow 爬蟲會壞在哪：五種反覆出現的失效模式
搞懂 Zillow 爬蟲為什麼壞，比把每份 README 讀完更省時間。原因清楚了，才好判斷要投資在更耐用的架構上，還是乾脆承認這筆維護成本划不來。
一、DOM 改版（Zillow 的 React 前端）
Zillow 前端是用 React 寫的，改版節奏很快。class 名稱、元件結構、data attributes 常常說換就換，不會有任何預告。今天靠 div.list-card-price 抓價格的爬蟲，明天這個 class 可能就不存在了。一則 Stack Overflow 回答 就指出，Zillow 的 class name 會因頁面而異。
比較麻煩的是失效方式：腳本照跑不誤，只是欄位全空。整整一週都在收集空值卻毫無察覺，是很常見的狀況。
二、內部 API 與 GraphQL 端點改動
比較聰明的 repo 會跳過 HTML，直接打 Zillow 的內部 GraphQL 或 REST API。像 actor-zillow-api-scraper 就是明確走內部 API，並用遞迴切分 map bounds 的方式繞開結果數量上限。設計相當漂亮，問題是 Zillow 會定期重構這些端點；一重構，爬蟲拿到的就是 404 或空白 JSON，而且不一定伴隨錯誤訊息。
程式本身沒有壞，壞的是目標搬家了。這種失效更難察覺。
三、反機器人與 CAPTCHA 一路加碼
Zillow 的機器人偵測還在持續升級。以我 2026 年 4 月的實測為例，直接用 requests.get() 打 zillow.com 與 zillow.com/homes/Chicago,-IL_rb/，即使補上像 Chrome 的 user-agent 和 Accept-Language header，回來的仍是 CloudFront 的 403。社群回報也對得上：有使用者提到自己逆向工程出來的 API 流程，大約在 100 次請求 之後就開始吃 403。
換句話說，小流量測試沒事，不代表放大之後還沒事。當你要盯著三個郵遞區號、兩百筆房源時，這種驚喜代價不小。
四、高價值資料躲在登入牆後面
Zestimate 詳情、稅務紀錄、部分價格歷史，這些欄位都被登入驗證擋著。開源爬蟲很少處理登入流程，所以這幾欄常常整片空白。使用情境一旦建立在價格歷史或稅賦評估價上，很快就會撞牆。
五、相依套件腐爛與長年失修
scrapehero repo 的 issues 裡躺著 No module named 'unicodecsv' 這種安裝階段就掛掉的問題。eswan18 repo 也記錄了手動裝 driver 與 GIS 相依套件的折騰。Python 函式庫一升版，相容性很容易斷。超過半年沒更新的 repo，往往還沒摸到 Zillow 的反機器人防線，就先死在 pip install 這一步。
2026 年的 Zillow 反機器人防線：實際要面對的東西
「掛個 proxy、輪替一下 headers 就好」，這種建議放在 2022 年勉強成立，放在 2026 年已經不夠用。
擋的不只是 IP：TLS 指紋與 JS 挑戰
Zillow 擋的遠不只 IP。社群回報指出，Zillow 背後有 Cloudflare，並搭配 指紋辨識與機器人偵測，早就不是單純的速率限制。TLS 指紋看的是客戶端協商加密的方式，等於一組「數位握手」特徵，可以辨識出非瀏覽器的請求。就算你換了全新的 proxy，只要握手特徵不像真的 Chrome，一樣會被標記。
JavaScript 挑戰是另一層。JS 執行不完整的 headless browser，或是把自動化痕跡暴露出來的瀏覽器（例如 navigator.webdriver = true），都很容易被抓。
搜尋頁與房源詳情頁的防護等級不同
Zillow 的頁面難度並不一致。Apify 的房地產 schema 就直接把跳過詳情頁的「Fast Mode」和資料更完整的「Full Mode」分成兩個選項。Thunderbit 的 Zillow 指南 同樣把初始清單抓取與「抓取子頁面」的詳情補強拆成兩段處理。
實務上很常見的情境是：搜尋結果頁抓得好好的，一進單一房源頁就開始失敗。因為越有價值、越常被抓的資料，Zillow 的防護就疊得越厚。
堅持只用 HTTP 的那群人
有一批開發者刻意只走 HTTP——不碰 Selenium、Playwright、Puppeteer。理由很務實：瀏覽器自動化慢、吃資源，大規模部署也更難管。
不過話要講明：到了 2026 年，沒有進階的 header 與指紋管理，純 HTTP 對付 Zillow 的空間越來越窄。從社群累積的經驗看，面對 Zillow 這種等級的目標，瀏覽器渲染正在從例外變成標配。
針對 Zillow 的防封鎖做法
如果還是決定自己動手，下面這幾件事確實有效，也順帶說明哪些沒那麼有效：
- 請求節奏隨機化，模擬真人瀏覽的樣子——不是固定延遲，而是帶有 session 行為的變動間隔
- header 要做得真，包含
Accept-Language、Sec-CH-UA系列 headers 與正確的 referer 鏈——但這是必要條件，不是充分條件 - 輪替 session——不要拿同一組 proxy 與 cookie 配對硬跑好幾百次請求
- 抓準改用瀏覽器渲染的時機——HTTP-only 流程如果在 50 次請求後就一路 403，繼續調 header 只是在打一場贏不了的仗
任何暗示「只要換上某組神奇 header，2026 年的 Zillow 就迎刃而解」的文章，都不必當真。
Thunderbit 的雲端抓取 把這一整層攬了下來——基礎設施在美國／歐洲／亞洲之間輪替，渲染與反機器人由系統處理，使用者不用一頭栽進 proxy 設定。差別其實不在技術有多神，而在營運負擔落在誰身上。
自建 Zillow 爬蟲時，怎麼讓它活久一點
決定走 GitHub／DIY 這條路的話，下面幾項做法就是「撐得住幾個月」和「幾天就報廢」的分水嶺。
別讓 selector 綁在脆弱的 class 名稱上
repo 一旦依賴 Zillow 自動產生的 CSS class 名稱，就該視為紅旗。那些名稱變動頻繁，有時甚至每週都在動。改用這幾種定位方式會穩很多：
- 以
aria-label、data-*屬性，或鄰近的標題文字定位元素 - 盡量採用依文字內容判斷的 selector
- Zillow 在頁面原始碼裡提供結構化資料時，優先解析 JSON，而不是硬啃 HTML
把健康檢查自動化
Zillow 抓取要當成正式的生產監控來管，不是寫完就丟的一次性腳本。設一個 cron job 或 GitHub Action，每天固定做三件事：
- 對一筆已知房源跑一次爬蟲
- 驗證輸出 schema，確認預期欄位都在、而且不是空的
- 格式錯誤或資料為空就立刻發警示
這樣問題會在 24 小時內浮出來，而不是幾週後才發現資料早就斷了。
鎖版本、用虛擬環境
Python（或 Node）相依套件務必鎖在特定版本，並且跑在 virtual environment 或 Docker container 裡。這次審查的舊 repo 已經示範得很清楚：安裝環境腐爛的速度非常快，壞掉的相依套件常常是第一個絆倒你的東西，根本還輪不到 Zillow 的反機器人出手。
抓取量保守一點
那個 大約 100 次請求的門檻 未必是硬性數字，但它提醒了一件事：抓取量一變，測試階段看起來沒問題的爬蟲，行為也會跟著變。請求要分散到不同 session、加上隨機延遲，不要想著一次撈一萬筆房源。
什麼時候該承認 DIY 不划算
當你花在維護爬蟲的時間，已經多過分析資料的時間，這筆帳就翻轉了。這不是能力問題，只是該換成受管方案的訊號。
GitHub 自建 vs. 無程式碼工具：一份誠實的取捨表
搜尋「zillow scraper github」的人大致分兩種：想掌握程式碼的開發者，以及只想把資料弄進試算表的房地產從業者。兩種需求都合理，差別在取捨的位置。
並排比較表
| 比較項目 | GitHub 爬蟲（Python） | 無程式碼工具（例如 Thunderbit） |
|---|---|---|
| 設定時間 | 30–120 分鐘（環境、相依套件、proxy） | 約 2 分鐘（安裝擴充功能、點擊抓取） |
| 維護成本 | 持續性——Zillow 一改版就會壞 | 幾乎沒有——AI 會自動適應頁面版型 |
| 反機器人處理 | 手動（proxy、headers、延遲） | 內建（雲端抓取、輪替基礎設施） |
| 資料欄位 | 自訂——您寫什麼就抓什麼 | AI 建議或範本化 |
| 匯出選項 | 透過程式匯出 CSV／JSON | Excel、Google Sheets、Airtable、Notion——免費 |
| 成本 | 免費（程式碼）＋proxy 成本（住宅代理約 $3.50–$8/GB） | 有免費方案；超出後採點數制 |
| 自訂上限 | 無上限（程式碼由您掌控） | 很高（欄位 AI 提示、子頁面抓取），但仍有邊界 |
代理成本這筆帳要算進去
把 proxy 費用攤開來看，「免費 repo」的吸引力會掉一大截。目前主要供應商的公開報價如下：
| 供應商 | 定價（截至 2026 年 4 月） |
|---|---|
| Webshare | 1 GB 為 $3.50/GB，購買更大方案會更便宜 |
| Decodo | 約 $3.50/GB，按量付費 |
| Bright Data | 名目價格 $8/GB，使用目前優惠為 $4/GB |
| Oxylabs | 起價 $8/GB |
repo 本身免費沒錯，但一條依賴 proxy 的 Zillow 流程通常不是。
適合走 GitHub repo 的情況
- 你本來就喜歡寫程式，也不排斥長期維護
- 你需要很特定的客製功能，例如自訂資料轉換或串進私有流程
- 你有時間、也有能力處理突發故障
- 你願意自己管理 proxy 基礎設施
適合改用 Thunderbit 的情況
- 你今天就要能用的資料，不想設定也不想維護
- 你的身分是房地產經紀人、投資人或營運人員，不是開發者
- 你想直接 匯出到 Google Sheets、Airtable 或 Notion，不必自己寫匯出程式
- 你需要子頁面抓取，用詳情頁資料補強房源，而且不想額外設定
- 你希望用平常講話的方式描述排程抓取
實作流程：不碰 GitHub，用 Thunderbit 抓 Zillow
無程式碼流程跟 GitHub 的設定體驗差距很大，實際跑一遍就知道。
步驟 1：安裝 Thunderbit Chrome 擴充功能
到 Chrome 線上應用程式商店 安裝 Thunderbit 並註冊帳號，有免費方案可用。
步驟 2：打開 Zillow，叫出 Thunderbit
開啟任一 Zillow 搜尋結果頁，例如某個郵遞區號的待售房源清單，接著點擊瀏覽器工具列上的 Thunderbit 圖示。
步驟 3：套用 Zillow 即時爬蟲範本，或讓 AI 建議欄位
Thunderbit 內建 Zillow 預建範本，不用設定，點一下就好。範本涵蓋的是標準欄位：地址、價格、床數、衛浴數、坪數、仲介名稱、仲介電話、房源網址。
想要更彈性，就點「AI 建議欄位」，讓 AI 讀完頁面再推薦。以我的使用經驗，它通常抓得出 20 多個欄位，Zestimate 也在裡面。
步驟 4：按下抓取，檢查結果
點「抓取」之後，分頁、反機器人、資料結構化都由 Thunderbit 處理。回來的是一張結構化的結果表，沒有 403、沒有整片空欄位，也沒有 proxy 要設定。
步驟 5：用子頁面資料補強（選用）
點「抓取子頁面」，Thunderbit 會逐筆進到房源詳情頁，把價格歷史、稅務紀錄、土地面積、學區評分等欄位補齊。同樣的事情放在 GitHub 架構下，等於要再寫一套 selector 與反機器人邏輯、跑第二輪抓取；這裡是一個按鈕。
步驟 6：免費匯出資料
Excel、Google Sheets、Airtable、Notion 都能免費匯出，也可以下載 CSV 或 JSON。匯出程式不用自己寫。
跟 GitHub 使用者的路徑對照一下就很明顯：那邊的起點是環境設定，終點常常是排查 403。
拿到 CSV 之後，資料要怎麼變成判斷
多數指南寫到「這是你的 CSV」就收尾了。但抓取只是第一步，真正產生價值的是後面那幾段。
第一步：抓取——把房源資料蒐集起來
搜尋結果頁的核心欄位：價格、床數、衛浴數、坪數、地址、Zestimate、刊登狀態、上架天數、房源網址。
第二步：補強——用子頁面抓取拉詳情頁資料
房源詳情頁能補上的欄位有價格歷史、稅務紀錄、土地面積、HOA 費用、學區評分、仲介聯絡資訊。Thunderbit 的子頁面抓取一鍵完成；GitHub 架構則要另外做一輪抓取，再多寫一套 selector 和反機器人邏輯。
第三步：匯出——送進你慣用的平台
- Google Sheets：快速分析與分享
- Airtable：做迷你 CRM 或交易追蹤器
- Notion：團隊儀表板
- CSV／JSON：接自訂流程
第四步：監控——排程重複抓取
這是多個論壇討論串反覆提到、卻始終沒被好好解決的痛點。你要的不只是今天這份資料，而是降價、狀態變化（active → pending → sold）以及新上架房源。
Thunderbit 的排程爬蟲可以用平實語言描述間隔，例如「每週二和週五上午 8 點」。GitHub 架構下，這代表你要自己建 cron job、處理驗證狀態持久化，還要管失敗復原。
第五步：行動——篩出機會、推動開發流程
資料到這一步才會轉成決策：
- 投資人：篩出 30 天內降價超過 5%、上架超過 90 天、開價低於 Zestimate 的房源
- 經紀人：標記符合買方條件的新房源，把過期／下架房源整理成開發名單
- 研究員：計算每平方英尺價格趨勢、成交價與開價比、庫存周轉速度
一個實際場景：投資人盯著三個郵遞區號、兩百筆房源
同一批欄位在不同使用情境下的權重並不一樣：
| 資料欄位 | 投資 | 經紀人名單 | 市場研究 |
|---|---|---|---|
| 價格 | ✅ 核心 | ✅ | ✅ |
| Zestimate | ✅ 核心（差距分析） | ✅ | |
| 價格歷史 | ✅ 核心（趨勢偵測） | ✅ | |
| 上架天數 | ✅ 核心（動機訊號） | ✅ | ✅ |
| 稅賦評估價 | ✅（估值交叉驗證） | ✅ | |
| 刊登狀態 | ✅ | ✅ 核心 | ✅ |
| 刊登日期 | ✅ | ✅ | |
| 仲介姓名／電話 | ✅ 核心 | ||
| 每平方英尺價格 | ✅ | ✅ 核心 | |
| 成交價 vs. 開價 | ✅ 核心 |
投資人每週對三個郵遞區號跑一次抓取，匯到 Google Sheets，對降價幅度與 DOM 異常值套條件式格式。經紀人匯到 Airtable，接成開發流程。研究員匯進試算表做趨勢分析。抓取那一段完全相同，後面接的卻是三種工作流程。
抓取 Zillow 的法律與倫理界線
這段不長，但不能略過。
Zillow 的使用條款 明文禁止自動化查詢，範圍包含畫面擷取、爬蟲、蜘蛛，以及繞過類 CAPTCHA 的防護措施。robots.txt 也擋掉了大片路徑，/api/、/homes/ 與 query-state URL 都在內。
但另一邊，美國的網頁爬取法律也不能簡化成「爬取一律違法」。在 CFAA 的框架下，hiQ v. LinkedIn 這條判例線對公開資料爬取相當關鍵。Haynes Boone 在 2026 年 4 月的一份摘要 中提到，第九巡迴法院再度駁回 LinkedIn 阻止他人抓取公開會員檔案的主張。不過這不會消滅合約、隱私或反規避等其他面向的爭點，也不代表 Zillow 的使用條款可以無視。
實務上要記住這幾點：
- 針對公開頁面的爬取，在 CFAA 論點上的基礎比很多網站宣稱的更穩
- 但 Zillow 在合約層面確實是明文禁止
- 繞過技術門檻會拉高法律風險
- 商業用途或高流量用途，請先取得法律意見
- 不論法律環境如何，都要負責任地抓取：尊重速率限制、不要壓垮伺服器、不要拿個資去發垃圾訊息
怎麼替自己的 Zillow 工作流程挑工具
2026 年的 Zillow 爬蟲 GitHub 生態，比表面數字薄得多。大多數搜尋得到的 repo 已經過時、脆弱或完全失效。少數還撐著的——最具代表性的是 pyzill——前提是你願意持續維護 proxy 與反機器人對策。
所以真正要選的並不是開源或封閉原始碼，而是控制權與營運負擔之間怎麼分配。
- 想要完整掌控、也享受維護爬蟲這件事，GitHub repo 依然很有力——只是請把 proxy 管理、selector 更新與健康監控的時間先預留好
- 想今天就拿到穩定資料、不想維護任何東西，Thunderbit 的 Zillow 範本 幾分鐘就能從搜尋頁走到試算表。它的 AI 每次執行都重新讀一次頁面結構，不吃硬編碼 selector 那套
兩條路都成立，端看你的時間值多少。
比較糟的情況只有一種：花好幾個小時把一套 GitHub 爬蟲架起來，最後才發現它上個月就壞了，而且 README 上沒人提。
想先看看無程式碼流程長什麼樣，可以 試用 Thunderbit 免費方案，大約兩下點擊就能抓 Zillow 房源，並匯進團隊已經在用的平台。偏好看實際操作的話，Thunderbit 的 YouTube 頻道 上有完整教學。
試用 Thunderbit 進行 Zillow 抓取 Get Started Free
常見問題
2026 年 GitHub 上還找得到能用的 Zillow 爬蟲嗎？
有幾個仍屬於部分可用，最具代表性的是 johnbalvin/pyzill，目前還抓得到資料，但需要輪替住宅代理與持續調校。star 數高的那幾個——包括 170 顆 stars 的 ChrisMuir/Zillow 與 152 顆 stars 的 scrapehero/zillow_real_estate——都已經因為 Zillow 的反機器人變更與 DOM 更新而失效。詳細狀態可以回頭看上面那張審查表。
Zillow 偵測得出 GitHub 爬蟲嗎？
偵測得出來。Zillow 用的手段包含 IP 封鎖、TLS 指紋辨識、JavaScript 挑戰、CAPTCHA 與速率限制。實測中，即使帶著 Chrome 風格 headers 的一般 HTTP 請求，也會從 CloudFront 拿到 403。沒有住宅代理、真實 headers、瀏覽器渲染這類反偵測配套的 GitHub 爬蟲很快就會被擋，常常在 100 次請求內就失效。
從 Zillow 可以抓到哪些資料？
常見欄位有價格、地址、床數、衛浴數、坪數、Zestimate、刊登狀態、上架天數、房源網址與仲介聯絡資訊。加上詳情頁抓取，還能取得價格歷史、稅務紀錄、土地面積、HOA 費用與學區評分。實際能拿到多少，取決於爬蟲本身的能力，以及你抓的是搜尋結果頁還是單一房源頁。
抓取 Zillow 合法嗎？
要看情境。依 hiQ v. LinkedIn 這條判例線，抓取公開可見資料在法律上有較強的立足點，但 Zillow 的使用條款明確禁止自動化存取。繞過 CAPTCHA、速率限制這類技術門檻會額外增加風險。個人研究的風險通常較低；商業或高流量用途請先諮詢法律顧問。無論如何，抓取行為本身都要負責任。
Thunderbit 為什麼抓 Zillow 比較不會壞？
Thunderbit 每次執行都用 AI 重新讀取頁面結構，不依賴 Zillow 前端一改版就失效的硬編碼 CSS selector 或 XPath。它同時內建 Zillow 即時爬蟲範本，一鍵就能擷取。雲端抓取那一側會處理反機器人並使用輪替基礎設施，使用者不必自己設 proxy 或管理瀏覽器渲染。Zillow 一改版，AI 會自動跟上，不需要更新 repo。
延伸閱讀
