你的圖床分享連結會被 Google 搜到嗎？7 家免費圖床 noindex 實測
你可能不知道，你隨手貼到 LINE 群組或 Discord 的那個圖床連結，有機會正躺在 Google 的索引裡，等著被任何人用一句 site: 搜出來。
2026 年 7 月底，資安圈炸出一則新聞：只要在 Google 打上 site:claude.ai/share，就能挖出大量別人的 AI 對話紀錄，裡面有 API 金鑰、加密貨幣私鑰、法律諮詢內容、履歷表。根本原因不是駭客攻擊，是設定衝突——那些分享頁面在 robots.txt 裡被標成「禁止爬取」，同時又設了 X-Robots-Tag: none。問題是，Googlebot 一旦被 robots.txt 擋在門外，它連進都進不去，當然也讀不到頁面裡那個原本該生效的 noindex 標籤。結果就是頁面透過外部連結被發現、被收錄，卻沒有任何機制能把它擋下來。這是一年內同類事故的第四起，前面還有 ChatGPT（估計七萬到十萬筆對話）跟 Grok（數十萬筆）。
這件事跟圖床有什麼關係？沒有直接關係——那是 AI 對話分享連結，不是圖片。但機制完全可以拿來對照：任何「靠連結不公開、但沒有正確封鎖爬蟲」的分享功能，都吃這一套邏輯。圖床的觀看頁一樣是「知道網址就能看」的模式，一樣得靠 robots.txt、meta robots、X-Robots-Tag 三層機制去擋，任何一層設錯，圖片一樣會外流到搜尋結果。我處理過不少企業的資安稽核案子，圖床外洩通常比對話外洩更難察覺——沒人會想到隨手傳的截圖也會被搜到。
於是我實測了。
三層機制決定一張圖會不會被搜到
先講清楚判準，免得後面的表格看起來像玄學。一個網址能不能被 Google 收錄，看的是三層：
robots.txt 決定爬蟲進不進得去這個路徑；頁面 HTML 裡的 <meta name="robots"> 決定爬進去之後要不要收錄；HTTP 回應標頭裡的 X-Robots-Tag 則是另一個獨立的收錄指令，效果跟 meta 標籤一樣，只是不用改 HTML。三層各自獨立，卻常常被當成同一件事在管——這就是 Claude 那次事故的根本問題：robots.txt 擋住了，X-Robots-Tag 卻設對了，但沒人能讀到它。
強烈建議記住這個原則：要 noindex 生效，爬蟲必須先「進得去」。如果你在 robots.txt 裡 disallow 某個路徑，同時又指望那個路徑底下的 noindex 標籤發揮作用，那是矛盾的設計，最後大概率兩邊都不生效。
實測方法：我做了什麼、沒做什麼
老實說，這種測試最怕的就是「憑印象寫」。所以方法先攤開：2026 年 9 月，我用瀏覽器 User-Agent 對每個服務的觀看頁跑 curl -I 抓 HTTP 標頭（看 X-Robots-Tag），再抓完整 HTML 找 <meta name="robots">，另外用 curl 直接讀各服務的 robots.txt。對於用 JavaScript 渲染內容、curl 抓不到真實連結的服務（Imgur 的首頁推薦區塊就是這樣），改用瀏覽器自動化工具實際載入頁面再取連結。
能不能實際搜到，我另外跑了 Google 搜尋驗證——但這裡要老實說一個限制：我用的搜尋工具本身被 imgur.com 這個網域擋掉了存取（不是 Google 擋，是搜尋工具的爬蟲被 imgur 的防護擋下），所以 Imgur 那一格的「已被搜到」欄位我沒辦法用同樣方法驗證，只能就技術設定面判斷它「理論上可被索引」，並在表格裡誠實標注。這不是我想隱瞞的地方，是工具限制，講清楚比裝作測過更重要。
實測結果
下面這張表，每一列都是我這次真的抓過的網址跟回應，不是查文件生的。
| 服務 | 觀看頁範例 | robots.txt 限制 | meta robots / X-Robots-Tag | 索引狀態（2026-09 實測） |
|---|---|---|---|---|
| Imgur | imgur.com/gallery/xxx | 未封鎖 /gallery/ 路徑 |
都沒有設定（預設可索引） | 技術上可索引；因搜尋工具被 imgur.com 擋，未能直接驗證是否已收錄 |
| ImgBB | ibb.co/xxx | robots.txt 完全空白 | 都沒有設定 | 已被收錄——用一般關鍵字搜尋直接搜到多筆真實圖片頁 |
| Postimages | postimg.cc/xxx | robots.txt 完全空白 | 都沒有設定 | 已被收錄——同樣直接搜到多筆含檔名的圖片頁 |
| Flickr | flickr.com/photos/user/id | 具名爬蟲（含 Googlebot）被允許存取 /photos/ |
僅有 noarchive，沒有 noindex |
已被收錄——實測搜到特定使用者的特定相片頁 |
| Catbox | files.catbox.moe/xxx | 部分管理路徑禁爬，且明文擋 ClaudeBot / GPTBot | 檔案本身是純二進位直連，沒有 HTML 頁面可放 meta 標籤 | 結構上不存在「可索引的觀看頁」——沒有頁面，就沒有 meta robots 這回事 |
| Google 相簿分享連結 | photos.app.goo.gl/xxx | /share/ 路徑未被 robots.txt 明確排除 |
頁面為 JS 渲染，curl 抓不到內容判斷 |
已被收錄——搜尋可找到他人的分享連結，部分至今仍能打開 |
| lpic.cc | lpic.cc/短碼 | Allow: /（首頁層級開放） | 觀看頁原始碼明確設定 index: false, follow: true |
明確 noindex——設計上就不讓觀看頁進索引 |
看到 Google 相簿那一列，說真的我愣了一下。
逐家解讀：問題出在哪一層
ImgBB 跟 Postimages 是這次測試裡最乾脆的兩個反例：robots.txt 直接回傳空白內容，代表沒有任何路徑限制；頁面裡也沒有任何 meta robots 標籤。沒有限制加上沒有標籤，等於「完全開放」——這是預設值，不是使用者可以在上傳時關掉的選項。我搜尋時幾乎是秒搜到，不少搜尋結果的頁面標題就是手機相機產生的原始檔名（IMG_ 加一串日期時間那種），一看就知道是手機直接上傳的照片。
Flickr 的情況比較細緻，也更容易被誤判。它的 robots.txt 裡列了將近四十個具名爬蟲（含 Googlebot），這群named清單只排除少數特定帳號跟功能頁，一般使用者的 /photos/使用者/相片ID 路徑並不在排除名單裡；頁面本身只有 noarchive（不做網頁快照）,完全沒有 noindex。這是真實案例：我實測搜到的那則相片頁,標題是官方帳號在講「怎麼分享 Flickr 照片」的教學貼文——連教你怎麼分享的頁面本身都被搜到了，這聽起來有點反諷。
Google 相簿分享連結才是這次測試最讓我在意的一格。務必注意:分享連結乍看是「你給誰、誰才看得到」的私密機制，但我用一般搜尋關鍵字、不靠任何特殊指令，就能在搜尋結果裡找到別人的 photos.app.goo.gl 分享短網址（基於隱私，這裡不列出實際連結）。其中有的點進去已經要求登入，代表分享權限後來被改掉或過期；有的則仍然打得開——也就是說,一個「私下分享給特定人」的連結,曾經或現在仍然可以透過公開搜尋找到。這跟 Claude 對話外洩是同一種風險形狀:連結本身沒有公開意圖,但爬蟲規則的細節決定了它會不會被搜尋引擎撿走。
Catbox 反而是個特例。它不像前面幾家有獨立的「觀看頁」——上傳完直接給你一個檔案直連網址,打開就是圖片本身,沒有任何 HTML 外殼可以放 meta robots 標籤。這代表傳統的「meta robots 檢查」在這裡根本無從測起。但這不等於它比較安全,只是風險轉移到另一個地方:Google 圖片搜尋一樣可能收錄直連的圖檔網址,只是判準跟依據 HTML 頁面的判準不同,這部分我沒有找到穩定的驗證方法,老實講就是驗不到,不硬掰一個數字出來。
lpic.cc 我自己的產品也一起測了,不能只測別人。查看原始碼可以看到,觀看頁的 metadata 明確寫死 robots: { index: false, follow: true }——也就是說,即使你的短碼被別人分享出去、被搜尋引擎的爬蟲抓到,頁面本身也主動告訴 Google「不要收錄我」。這是設計時就定案的行為,不是這次測試才臨時補上的。不過老實說,noindex 只能防止被搜尋結果收錄,防不了「知道網址就能打開」這件事本身——這就是密碼保護功能存在的理由,兩者要一起用才算完整。
這對你代表什麼實際風險
把上面的技術細節翻譯成白話:如果你把含有個資、發票、對話截圖、身分證件的圖片傳到 ImgBB 或 Postimages 這類預設全開放索引的圖床,理論上任何人都能靠關鍵字或圖片內容的文字片段搜到它——不需要拿到你分享的連結,只要搜尋引擎已經爬過,它就在那裡等著。這跟你直接把檔案設成「公開」上傳到自己的網站,沒有本質上的差別。
很多人忽略了一個更陰險的情境:你在論壇或社群發文附上圖床連結時，通常不會刻意想「這張圖會不會被搜到」,但如果圖片裡有你的姓名、地址、部分身分證字號(常見於報稅、退貨、申請文件的截圖),搜尋引擎收錄之後,這些資訊等於永久攤在網路上,直到你自己發現並要求下架——而多數人根本不知道要去哪裡查。
怎麼保護自己的分享連結
務必注意,不是每張圖都需要防護,重點是分清楚「隨手分享的迷因」跟「含個資的截圖」該用不同等級的工具。三個具體做法:
- 先自己搜一次。上傳前後,拿檔名或圖片裡的關鍵文字去 Google 搜一次,確認有沒有被收錄的跡象。
- 敏感內容避開預設全開放索引的圖床,改用有明確標示
noindex或支援密碼保護的服務。 - 分享連結有效期限要主動設定,不要依賴「反正沒人知道網址」這種假設——Claude 事件已經證明,爬蟲不需要知道網址,只要有任何一個外部連結指向它就夠了。
如果你正在找一個把「分享連結預設不進索引」跟「密碼保護」都內建的圖床,lpic.cc 的觀看頁本來就是 noindex 設計，加上密碼保護功能，等於前面兩層防護一次到位。不過講清楚限制:免費方案的媒體預設上傳後 30 天到期（上傳表單預設開啟「查看時自動延展」），到期會被清除,而且服務靠廣告維持營運——這些取捨你要先知道,不是上傳完才發現。
常見問題 FAQ
Q1：只要設定了 noindex，圖片就絕對不會被搜到嗎？
不是絕對。noindex 是「請求」爬蟲不要收錄，多數情況下 Google 會遵守，但前提是爬蟲真的讀得到這個標籤——如果 robots.txt 同時把路徑擋住，爬蟲根本進不去，也就看不到 noindex，這正是 Claude 那次事故的成因。
Q2：Catbox 這種直連檔案的圖床，圖片會不會被搜到？ 無法用 meta robots 判斷，因為沒有 HTML 頁面。理論上 Google 圖片搜尋可能收錄直連圖檔網址本身，但驗證方式跟一般網頁不同，這次測試沒有找到可靠的驗證方法，不做未經驗證的斷言。
Q3：我已經傳到 ImgBB 的圖片，發現被搜到了，能刪掉索引嗎？ 先刪除原始圖片讓網址失效，再到 Google Search Console 的「移除網址」工具送出移除請求，會比等自然爬蟲重新爬取快很多。
Q4：這篇測的是 2026 年 9 月的結果，之後平台改設定怎麼辦？
robots.txt 跟 meta 標籤都可能隨時改動，這類設定本來就沒有永久保證。建議的做法不是死記這張表，而是自己動手用 curl -I 或瀏覽器開發者工具查一次，方法比結論更耐用。
Q5：為什麼 Flickr 允許 Googlebot 但擋掉其他大部分爬蟲？ 這是刻意的選擇——允許主流搜尋引擎索引以維持流量與能見度，同時擋掉不具名的第三方爬蟲抓取以降低內容被盜用或濫用的風險，兩者是不同的取捨考量，不是同一件事。
References
- Claude 對話分享連結被 Google 索引事件報導（2026-07-29）
- Imgur、ImgBB (ibb.co)、Postimages (postimg.cc)、Flickr、Google 相簿 (photos.google.com)、Catbox (catbox.moe) 各服務之
robots.txt，2026-09 直接存取取得 - 上述各服務觀看頁 HTTP 標頭與 HTML 原始碼，2026-09 以
curl與瀏覽器自動化工具實測取得 - lpic.cc 觀看頁 metadata 原始碼（
app/(public)/[locale]/[code]/page.tsx）