搜尋「爬蟲」，結果頁會同時冒出兩種長相完全不同的東西，一種是 Google 這類搜尋引擎用來蒐集網頁的程式，另一種是工程師寫來批次抓價格、抓文章的小程式。兩種都叫爬蟲，卻幾乎沒有共通點，光看字面，很容易讀了半天才發現讀錯了方向。
對經營網站的人來說，這個差別更實際。搜尋引擎的爬蟲沒有走到你的頁面，那些頁面就沒有機會出現在搜尋結果裡；而資料爬蟲一旦失控，又會讓伺服器多出一堆沒有人在看的流量。更麻煩的是，爬蟲只是搜尋引擎運作的第一關，被它讀到，不代表會被收錄，更不代表排得上去。
不過在分辨這些之前，得先弄清楚爬蟲本身在做什麼。
爬蟲是什麼？
爬蟲是一種自動走訪網頁的程式。它從一批已知的網址出發，Cloudflare 的說明把這批起點稱為種子網址（seed）。每讀到一個頁面，爬蟲就把頁面裡的連結抽出來，排進待走訪的清單，再依序去讀清單上的下一個網址，一路往外延伸。
這個走訪動作在英文裡叫 crawl（爬行），所以爬蟲也常被稱為 spider（蜘蛛）或 bot（機器人）。「蜘蛛」這個名字的由來很直白，爬蟲在 World Wide Web 這張網上爬行，就像蜘蛛在蛛網上移動。Google 的中文文件則把這類程式稱為「檢索器」，有時也寫成「漫遊器」或「自動尋檢程式」，指的都是自動探索與掃描網站的程式。換句話說，爬蟲、spider、bot、檢索器是同一類東西的不同叫法。
爬蟲不會、也不需要走完全部的網頁。網路上的頁面多到數不完，爬蟲得決定先走哪些、隔多久回頭看一次。Cloudflare 的說明指出，這類決定通常會參考幾件事，包括頁面的相對重要性（有多少頁面連到它、有多少訪客）、頁面更新後要不要重新造訪，以及先查看網站的 robots.txt。所以在同一個網站裡，常被連結、常更新的頁面，通常比冷門頁面更常被爬蟲光顧。
爬蟲的用途很廣，但最常被提到的，是替搜尋引擎蒐集網頁。Google 的說明提到，Google 搜尋是全自動化的搜尋引擎，用稱為網路檢索器的軟體定期探索網路，搜尋結果裡大多數的網頁並不是網站主動提交的，而是檢索器在探索過程中找到、自動加入的。沒有爬蟲，搜尋引擎就沒有東西可以搜尋。至於爬蟲拿到頁面之後，是拿來建立搜尋索引，還是只取走其中幾個欄位，就是兩種不同的爬蟲了。
搜尋引擎爬蟲與資料爬蟲，目的和行為都不同
同一個詞底下的兩種程式，目的、走訪範圍和跟網站的關係都不一樣。搜尋引擎爬蟲為了替整個網路建立可搜尋的索引，會沿著連結持續往外走；資料爬蟲則是為了取得特定資料，通常只鎖定幾個網站或幾種頁面，抓完要的欄位就收工。
另一個容易混在一起的詞是 scrape（擷取）。crawl 偏向「找出有哪些頁面」，scrape 則是「把頁面上的特定資料取走」，實務上常是先 crawl 找到頁面，再 scrape 取出欄位。Cloudflare 的說明也提到，scraper 通常比 crawler 更有針對性，可能只找特定的頁面或網站，而 crawler 會持續跟著連結爬。兩者沒有好壞之分，只是用途不同。
| 面向 | 搜尋引擎爬蟲 | 資料爬蟲 |
|---|---|---|
| 目的 | 替整個網路建立可搜尋的索引 | 取得特定的欄位或內容 |
| 走訪範圍 | 沿連結持續擴張，範圍廣 | 鎖定特定網站或頁面，範圍窄 |
| 抓回來的東西 | 分析後存進索引，用來回應搜尋 | 取出欄位，存成表格或資料庫供分析 |
| 與站方的關係 | 多數網站希望被收錄，因此歡迎 | 站方未必事先知情或同意 |
| 對 robots.txt 的態度 | 主要搜尋引擎的爬蟲多半會遵守 | 是否遵守，由程式的作者決定 |
搜尋引擎爬蟲，為建立索引而廣泛走訪
搜尋引擎爬蟲的工作，是替搜尋建立資料庫。Cloudflare 的說明提到，搜尋引擎把搜尋演算法套用在爬蟲蒐集到的資料上，才產生使用者在 Google 或 Bing 輸入搜尋後看到的網頁清單。它沿著連結一個接一個走，不針對某個欄位，也不會走一次就結束，而是會定期回頭看頁面有沒有更新。
這也解釋了為什麼多數網站其實希望爬蟲來。Cloudflare 的說明指出，網站若想從搜尋得到自然流量，就不應該封鎖搜尋引擎爬蟲，因為沒被爬到，就無法被索引，也不會出現在搜尋結果裡。主要搜尋引擎的爬蟲通常也會遵守 robots.txt，並控制請求的速度，避免把網站拖垮。
資料爬蟲，為取得特定資料而鎖定頁面
資料爬蟲的目標，是把頁面上特定的內容取出來，存成可以使用的資料，例如商品價格、文章標題、表格裡的數字。它不負責建立搜尋索引，範圍通常也很窄，多半是為了單一目的寫出來的程式，抓完需要的欄位就結束。
常見的用途像是價格監測、整理公開資料、研究資料蒐集。資料爬蟲跟搜尋引擎爬蟲最大的差別不在技術，而在抓回去做什麼，以及站方事先有沒有約定。Cloudflare 的說明也指出，這類程式可能不顧對伺服器造成的負荷，主要搜尋引擎的爬蟲則較可能遵守 robots.txt，並限制請求量。
AI 爬蟲，為訓練模型與 AI 服務蒐集內容
近年多了一類為 AI 服務而來的爬蟲。Cloudflare 的說明把它視為與傳統爬蟲「獨立但相關」的一類，並歸納出三種用途，包括蒐集內容來訓練大型語言模型、替 AI 助理即時取得外部資訊，以及替自己的 AI 服務建立索引。
不少搜尋業者同時營運搜尋爬蟲與 AI 爬蟲，各家 AI 服務也各有自己的爬蟲。對網站來說，這表示可以針對不同用途的爬蟲分別開放或限制，不需要一刀切。
爬蟲只負責搜尋引擎三階段中的第一關
很多人把「被爬到」當成「排得上去」，但兩者之間還隔著好幾道程序。Google 的說明把搜尋的運作分成三個階段，依序是檢索、建立索引、提供搜尋結果。檢索是用自動化程式，把網路上找到的網頁下載下來，包括文字、圖片和影片；建立索引是分析這些內容，把資訊存進稱為 Google 索引的大型資料庫；提供搜尋結果則發生在使用者搜尋的時候，系統傳回相關的資訊。爬蟲只負責第一階段。
Google 也說明，並非所有網頁都會經歷每個階段。被爬過的頁面可能沒有進索引，進了索引的頁面也不一定出現在搜尋結果裡。Google 還明確表示，不接受以付費方式增加檢索某個網站的頻率或提高排名；即使網頁符合基礎入門做法，也無法保證一定會被檢索、建立索引或出現在搜尋結果中。所以「請 Google 多爬幾次」這件事，既買不到，也不等於排名會變好。
爬蟲先找出網址，再由演算法決定檢索範圍與頻率
爬蟲怎麼知道有哪些頁面存在？世界上並沒有一個統一登記所有網頁的地方，Google 必須持續尋找新網頁，再加入已知網頁的清單，這個程序稱為「網址搜尋」。其中一條路是從已知的頁面擷取連結，例如分類頁這類中心頁面，常會連到新發表的文章；另一條路是網站提交的 Sitemap，同樣能讓 Google 找到其他網頁。
找到網址不代表全部都會抓。Google 用來擷取網頁的程式名為 Googlebot，由演算程序決定要檢索哪些網站、多久一次，以及從每個網站擷取多少頁。檢索器也設計成避免速度過快而讓網站超載，會依網站的回應調整，例如收到 HTTP 500 這類回應，就會視為「放慢速度」的信號。
Googlebot 也不會檢索找到的所有網頁。有些頁面被站方禁止檢索，有些需要登入才看得到。可見 crawl 本來就是有選擇的過程，並不是把整個網路複製一遍。
JavaScript 內容要等轉譯後才讀得到
檢索到網址後，Google 還會像瀏覽器一樣「轉譯」頁面，也就是執行頁面裡的 JavaScript。Google 的 JavaScript SEO 說明把這類網頁的處理分成檢索、轉譯、建立索引三步，轉譯時使用沒有畫面的無頭 Chromium 瀏覽器，所以靠 JavaScript 才產生的內容，也有機會被看到，並用來建立索引。
不過轉譯不是即時的。Googlebot 會把網頁排進檢索佇列與轉譯佇列，在資源允許時才進行，網頁可能在佇列裡停留數秒，也可能更久。而且 Google 提醒，不是所有爬蟲都能執行 JavaScript，因此仍建議採用伺服器端轉譯或預先轉譯，讓使用者和檢索器都能更快瀏覽。簡單來說，重要的內容盡量直接寫在 HTML 裡，不要完全靠前端腳本產生，因為沒經過轉譯，Google 可能看不到那些內容。
爬過的頁面不一定進索引，重複頁面只留代表版本
爬到頁面之後，Google 會解讀內容，這個動作稱為建立索引，包括處理與分析文字內容，以及 title 元素、alt 屬性、圖片、影片等關鍵的內容標記。處理的過程中，系統也會判斷這個頁面是不是別頁的重複版本，把內容相似的頁面分成一群，再選出最具代表性的「標準網頁」，其他版本則是在不同情境下才會出場的替代版本。
同一階段，Google 還會收集標準網頁的信號，像是網頁語言、內容所在的國家或地區、網頁可用性，留給下一階段使用，資訊則存進由數千台電腦代管的大型資料庫。要留意的是，Google 不保證一定建立索引，並非處理過的每個網頁都會被收進去。所以「被爬過」與「進索引」是兩件事。
排名在使用者查詢當下才發生
真正決定誰排前面的，是第三階段，而且發生在使用者按下搜尋的當下，不是爬蟲讀頁面的時候。使用者輸入查詢後，系統會搜尋索引資料庫，找出符合的網頁，傳回它認為與查詢最相關、品質也最好的結果。Google 說明相關性取決於數百種因素，包括使用者所在的位置、語言和裝置。舉例來說，位在巴黎和香港的人搜尋「單車維修店」，看到的結果並不相同；搜尋結果頁顯示的功能也會隨查詢改變，搜尋「單車維修店」可能出現本地搜尋結果，搜尋「現代單車」則較可能出現圖片搜尋結果。
所以爬蟲只負責把頁面帶進來，排名是另一套系統依當下的查詢計算出來的。檢索與排名兩端都用得上的是連結，爬蟲靠連結找新頁面，Google 的連結分析系統也把連結當作理解頁面的信號，PageRank 至今仍是其核心排名系統之一。
搜尋引擎爬蟲不只 Googlebot 一支
爬蟲常被想成單一一支程式，實際上同一家公司就有好幾種爬蟲，不同的搜尋引擎又各有自己的。翻網站日誌或設定檔時看到的那一長串名字，其實各自代表不同的角色，而且這些名字本身並不可靠，誰都可以自稱是某家的爬蟲。
Google 的三類爬蟲對 robots.txt 的遵守程度不同
Googlebot 是 Google 搜尋用的爬蟲通稱，其中包含兩種，Googlebot Smartphone 模擬行動裝置的使用者，Googlebot Desktop 則模擬電腦使用者。兩者可以從 HTTP 要求標頭裡的 user-agent 辨別，但遵循 robots.txt 中同一個產品權杖，所以無法在 robots.txt 單獨指定其中一種。Google 搜尋主要將大多數網站的行動版內容編入索引，因此大部分的檢索要求來自行動版，只有一小部分來自電腦版。
範圍更廣的 Google 檢索器與擷取程式，則分成三類，對 robots.txt 的態度各不相同。
- 常見檢索器：例如 Googlebot，一律遵循自動檢索的 robots.txt 規則。
- 特殊情況檢索器：例如 AdsBot，只有特定產品使用，因為接受檢索的網站與 Google 產品之間有協議，所以不一定遵循 robots.txt。
- 使用者觸發的擷取程式：例如 Google 網站驗證工具，是依使用者的要求才行動，會忽略 robots.txt。
這代表日誌裡看到名字以 Google 開頭的訪客，不一定是 Googlebot，也不一定會遵守 robots.txt。
Bingbot 與 DuckDuckBot 等其他搜尋引擎爬蟲
其他搜尋引擎也有各自的爬蟲，例如 Bing 的爬蟲叫 Bingbot，DuckDuckGo 的爬蟲叫 DuckDuckBot。這些名稱會出現在 HTTP 要求的 user-agent 裡，所以對照網站日誌時，看到這些名字，就能知道是哪一家的爬蟲來過。
不過名稱和遵守規則的方式，都以各家搜尋引擎公開的說明文件為準，不能憑印象推測。更重要的是，名字只是爬蟲自己申報的，申報的內容是真是假，得靠另一套方法確認。
User-Agent 能偽造，真假 Googlebot 要靠 DNS 反查加正查確認
爬蟲在每次請求時都會報上名字，也就是 user-agent，但這個名字誰都能填。Google 的說明就提醒，其他檢索器經常假冒 Googlebot 採用的 user-agent，所以決定封鎖之前務必先驗證，免得誤擋真的 Googlebot，或被冒名的流量誤導。
Google 的檢索器會透過三種方式識別自己，分別是 HTTP user-agent 標頭、要求的來源 IP，以及來源 IP 的反向 DNS 主機名稱。手動驗證的邏輯是兩步：
- 對日誌中的 IP 做反向 DNS 查詢，確認網域是 googlebot.com、google.com 或 googleusercontent.com。
- 再對該網域名稱做正向 DNS 查詢，確認結果回到原本的那個 IP。
只做第一步並不夠。反向 DNS 的紀錄由掌管該 IP 位址的一方自行設定，冒名者可以把自己 IP 的反查結果設成看似 googlebot.com 的名稱；正向查詢查的則是 googlebot.com 這類網域本身的紀錄，只有網域的擁有者能設定，所以要靠第二步，才能確認這個名稱真的指回該 IP。Google 的說明文件以 66.249.66.1 為例，反查會得到 crawl-66-249-66-1.googlebot.com，再正查回 66.249.66.1，驗證才算通過。
需要大量驗證時，Google 另外公布了檢索器與擷取程式的 IP 範圍清單，可以直接用來比對來源 IP。
爬蟲讀到的網頁，不一定等於瀏覽器裡的畫面
爬蟲讀頁面的方式跟人不同，有幾項固定的限制，會讓人看得到的內容，爬蟲卻讀不到。除了前面提過的 JavaScript 轉譯，連結的寫法、登入與封鎖、單一檔案的讀取上限，也都會造成這種落差。
這些限制大多不是網站出了什麼大問題，而是爬蟲運作原理本來就有的邊界，知道之後，建站時就能提早避開。
爬蟲只認帶 href 的標準連結，每個重要頁面都要被連到
爬蟲沿著連結走訪，但只認寫法標準的連結。Google 的說明指出，Google 一般只能檢索含 href 屬性的 a 元素；如果 a 元素沒有 href，或是改用其他標記搭配腳本事件來產生連結效果，例如只靠 onclick 跳轉，Google 就無法準確擷取其中的網址。把 href 寫成以 javascript: 開頭的指令，也被 Google 列為不建議的寫法，Google 或許仍會嘗試解析，但不保證解析得出實際網址。對人來說，這些按鈕點下去都會跳頁，但對爬蟲而言，這條路未必走得通。
另一個前提是站內的連結結構。Google 的建議是，網站上每個重要的網頁，至少要有一個其他網頁連結過去，爬蟲才有路可走。單頁應用程式也一樣，切換檢視時要用 History API，而不是用 # 片段載入不同內容，這樣 Googlebot 才能剖析並擷取網址。
爬蟲無法讀取需要登入或被 robots.txt 封鎖的頁面與資源
爬蟲不會輸入帳號密碼，需要登入才能看的頁面，它進不去。被 robots.txt 禁止檢索的網址也是同樣的結果，Googlebot 在發出 HTTP 要求前會先讀 robots.txt，網址若被標為不允許檢索，就不會發出要求，連頁面載入時用到的 JavaScript，也不會在被封鎖的檔案或頁面上轉譯。
有一個常見的失誤，是把頁面依賴的 CSS 或 JavaScript 資源檔也一起封鎖。Google 的說明建議，不重要的圖片、指令碼或樣式檔可以封鎖，但如果缺少這些資源，會讓 Google 的檢索器難以理解頁面內容，就不要封鎖。
Googlebot 讀取單一檔案有大小上限
爬蟲也不是無上限地下載。Google 的說明提到，Googlebot 為 Google 搜尋檢索時，對每個檔案只會讀取前面的一段，到了大小上限就停止擷取，只把已經下載的部分送去建立索引。這個限制套用在未壓縮的資料上，HTML 參照的 CSS、JavaScript 也是各自擷取，各有自己的上限；PDF 的上限則比其他檔案類型大。
在不同的 Google 文件裡看到的上限數字可能不一樣，是因為 Google 檢索器的基礎架構有一個預設上限，個別產品的爬蟲可以設定不同的值，Googlebot 就有自己的數字，影片、圖片等其他 Google 檢索器的上限也可能不同。一般篇幅的頁面不太需要擔心，但極端冗長的頁面，後半段的內容可能不會進入索引，所以重要的內容別放在最後面。
網站能用的控制工具，各自管不同的事
提到控制爬蟲，多數人第一個想到 robots.txt，但它只是其中一種，而且常被拿去做它做不到的事。工具要依想達成的目的來選，想管走訪的流量用 robots.txt，想讓頁面不出現在搜尋結果用 noindex，想完全不讓任何人看就用密碼保護。
在這之前，還有三項最基本的技術規定。Google 說明，網頁要在 Google 搜尋顯示，需要符合三項條件，分別是 Googlebot 沒有被封鎖、網頁正常運作並回應 HTTP 200，以及有可以編入索引的內容。其他工具處理的，都是這三項之上的事。
robots.txt 管走訪流量，不管收錄
robots.txt 告訴搜尋引擎爬蟲可以存取網站上的哪些網址，主要目的是避免網站因要求過多而超載，並不是用來讓頁面從搜尋結果消失。Google 的說明提到，被 robots.txt 禁止的網頁，如果有別的網站連結過來，Google 仍可能為這些網址建立索引，網址或連結的錨定文字等公開資訊，仍可能顯示在搜尋結果裡，只是沒有網頁說明。
它也不是強制規範。Google 說明，檢索器能自行決定是否遵循，Googlebot 與一些值得信任的檢索器會遵循，但並非每個都會。IETF 制定的 Robots Exclusion Protocol（RFC 9309）也寫明，這些規則不是一種存取授權，而且 robots.txt 裡列出的路徑會公開可見，所以不能取代有效的內容安全措施。要保護私人內容，不能只靠它。
檔案本身的位置也有規定。robots.txt 必須放在網站主機的根目錄，不能放在子目錄，一個網站只能有一個，內容必須是 UTF-8 編碼的純文字檔。
noindex 要讓爬蟲讀得到才生效，完全擋人則用密碼保護
三種「不想被看到」的需求，對應三種不同的工具。不想讓爬蟲檢索，用 robots.txt；不想讓頁面出現在搜尋結果，用 noindex，可以是 meta robots 標記，PDF、影片、圖片這類非 HTML 的檔案，則改用 X-Robots-Tag 回應標頭；想讓任何爬蟲或使用者都進不來，就用密碼保護等存取控制。Google 的說明也是這樣區分的。
noindex 有一個前提，爬蟲得讀得到頁面，才看得到這個指令。robots.txt 和 noindex 同時使用是常見的陷阱，頁面被 robots.txt 擋住時，爬蟲根本讀不到頁面上的 noindex，這條規則就會被忽略，頁面反而可能因為別處的連結而留在搜尋結果裡。所以要讓頁面從搜尋結果消失，就不能同時用 robots.txt 把它擋在門外。
HTTP 狀態碼 301、404 與 5xx 對爬蟲的不同意義
爬蟲和網站之間靠 HTTP 狀態碼溝通，每一種狀態碼都在告訴爬蟲這個網址目前是什麼情況。回應 200 表示頁面正常運作，Google 會查看內容、判斷是否處理，內容也才有機會傳進索引管道；不過進了管道，索引系統也不保證一定會建立索引。如果內容看起來像錯誤頁（例如空白頁或錯誤訊息），卻回應 200，Search Console 會把它顯示為 soft 404。
重新導向方面，301 是強烈的「請改處理新網址」信號，302 則是微弱的信號，Google 的檢索器預設最多跟隨 10 次重新導向。4xx（429 除外）等於告訴爬蟲這個頁面不存在，已經索引的網址會被移出索引，對這些網址的檢索頻率也會逐漸降低，但不會影響整個網站的檢索頻率。
429 與 5xx 則屬於伺服器出狀況的信號，會讓 Google 的檢索器暫時降低檢索頻率；已索引的網址暫時保留，但如果持續出錯，最終會被移出索引。伺服器恢復回應 2xx 之後，檢索頻率才會逐步回升。這意味著網站一旦不穩定，爬蟲也會跟著少來。
Sitemap 與內部連結幫爬蟲找到頁面
Sitemap 是站方主動幫爬蟲指路的清單，提供網站頁面、影片與檔案的資訊，包括彼此的關係、最後更新日期與語言版本。Google 的說明指出，Sitemap 對大型網站、新網站，或是含有大量影音內容的網站特別有幫助。
反過來，規模小、連結完善、沒有影音或新聞內容的網站，可能不需要 Sitemap。Sitemap 也不保證頁面一定被收錄，它和內部連結是互補的，前面提過每個重要頁面至少要被另一頁連到，Sitemap 無法取代良好的連結結構。
Search Console 的檢索統計與網址檢查
最後一類工具是用來看結果的。Google Search Console 提供「檢索統計資料」報表，可以看 Google 爬取網站的情形；「網頁索引」報表，看頁面的收錄狀態；還有「網址檢查」工具，可以單獨檢查某一個頁面。Google 說明這幾項都可用來檢查網頁的狀態。
實務上，覺得爬蟲的來訪有異常，例如突然變少、伺服器回應出錯變多，先看檢索統計；懷疑特定頁面沒進索引，用網址檢查看那一頁；想掌握全站的收錄狀況，則看網頁索引報表。
資料爬蟲的基本流程與使用分寸
資料爬蟲做的事，像是人用瀏覽器看網頁，只是改由程式執行，並把需要的資料存下來。搜尋引擎爬蟲背後有「站方希望被收錄」的默契，資料爬蟲沒有這層默契，所以更需要自己劃出界線。
資料爬蟲的流程是請求、解析與儲存
流程的輪廓只有三步。先向網站送出請求，拿回網頁內容；再從內容裡找出需要的欄位，例如標題、價格、表格；最後存成表格或資料庫能使用的格式。以價格監測為例，程式每天固定去讀幾個商品頁，取出價格，存成一份可以前後比較的紀錄。
人一次只能看一頁，程式卻可以在很短的時間內重複請求成百上千次，這也是它會對站方造成負擔的原因。Cloudflare 的說明提到，爬蟲存取需要消耗伺服器資源，網站可能因為過量索引而增加頻寬成本或超載，所以網站管理者可能會限制爬蟲存取。
用爬蟲抓資料前，先確認站方規則、請求頻率與內容授權
動手抓資料之前，有幾件事要先確認。
- 站方的 robots.txt 與使用條款：先看站方對自動存取的態度，知道哪些路徑被要求不要走。
- 有沒有站方提供的資料介面（API）：有的話優先用，因為那是站方願意提供的正式管道，資料格式也更穩定。
- 請求頻率：自己節制速度，不要拖垮對方的伺服器，否則先吃虧的往往是自己，會被限制或封鎖。
- 登入後的內容與個人資料：這類內容不是公開提供的，不碰最保險。
- 內容的授權範圍：抓回來的內容怎麼使用，要看原內容的授權範圍，能抓到不等於能自由轉載或再利用。
最常被誤解的一點，是 robots.txt 沒有禁止，不等於什麼都能拿去用。前面提過 RFC 9309 寫明 robots.txt 的規則不是一種存取授權，它只是請爬蟲遵守的約定。
搜尋引擎爬蟲會依伺服器的回應放慢速度，避免讓網站超載，資料爬蟲也該有同樣的自覺。如果遇到站方設了防爬機制，那是對方在表達限制，不是等著被破解的技術挑戰。
爬蟲本身只是一個自動走訪網頁的工具，用在搜尋引擎上，是網站被搜尋到的第一關；用在資料蒐集上，則要自己守住分寸。對經營網站的人來說，與其擔心爬蟲來不來，不如先確認它走得到、讀得懂、沒有被誤擋，重要頁面有標準的連結可走，伺服器回應穩定，robots.txt 與 noindex 沒有互相打架。這幾件事沒出問題，後面的收錄與排名才有討論的基礎。