फ्री इमेज होस्टिंग लिंक क्या Google पर दिख जाती है? 7 सर्विसेज़ की noindex जांच

WhatsApp या Telegram के किसी फैमिली ग्रुप में आपने कभी न कभी कोई फोटो-होस्टिंग लिंक ज़रूर भेजा होगा — शादी की फोटो, बिल की स्क्रीनशॉट, या किसी फॉर्म का स्कैन। सवाल यह है: क्या वह लिंक सिर्फ उन्हीं लोगों तक पहुंचा जिन्हें आपने भेजा, या वह कहीं Google के इंडेक्स में भी बैठ गया, जहां से कोई भी उसे एक साधारण site: सर्च से खोद सकता है?

जुलाई 2026 के आखिर में यही बात एक बड़े स्तर पर सामने आई: सिर्फ Google पर site:claude.ai/share टाइप करने से लोगों की AI चैट हिस्ट्री की भरमार निकल आई — जिनमें API keys, क्रिप्टो प्राइवेट keys, कानूनी सलाह, और रिज़्यूमे तक शामिल थे। वजह कोई हैकिंग नहीं थी, बल्कि सेटिंग्स का आपस में टकराव था — वे शेयर पेज robots.txt में "क्रॉल मत करो" के तौर पर मार्क थे, और साथ ही उन पर X-Robots-Tag: none भी लगा था। दिक्कत यह है कि जब Googlebot को robots.txt से ही गेट पर रोक दिया जाए, तो वह अंदर घुस ही नहीं पाता, और जब अंदर घुस ही नहीं पाया तो पेज के भीतर असल में काम करने वाला noindex टैग पढ़ेगा कैसे? नतीजा यह हुआ कि पेज किसी बाहरी लिंक के ज़रिए खोजा गया, इंडेक्स हो गया, और उसे रोकने वाला कोई मैकेनिज़्म काम नहीं कर पाया। एक साल के भीतर यह चौथी ऐसी घटना है — इससे पहले ChatGPT (अनुमानित 70,000–100,000 बातचीत) और Grok (लाखों में) भी इसी तरह उजागर हो चुके हैं।

इसका फोटो-होस्टिंग सर्विसेज़ से सीधा कोई लेना-देना नहीं — वह AI चैट शेयरिंग थी, फोटो नहीं। लेकिन मैकेनिज़्म बिल्कुल वही है: जो भी फीचर "सिर्फ लिंक जानने वाला ही देख सकता है, पर क्रॉलर को सही तरीके से रोका नहीं गया" के आधार पर बना है, वह इसी लॉजिक का शिकार बन सकता है। फोटो-होस्टिंग की व्यू पेज भी बिल्कुल यही मॉडल है — URL पता है तो देख सकते हो — और इसे भी उतने ही तीन लेयर, robots.txt, meta robots, X-Robots-Tag से रोकना पड़ता है। एक भी लेयर गलत सेट हो, तो फोटो भी सर्च रिज़ल्ट में लीक हो सकती है।

तो मैंने असल में टेस्ट कर के देखा।

जांच का तरीका — क्या किया, क्या नहीं किया

सच कहूं तो इस तरह के टेस्ट में सबसे बड़ा खतरा "अंदाज़े से लिख देना" होता है, इसलिए तरीका पहले साफ कर देता हूं। सितंबर 2026 में, मैंने हर सर्विस के व्यू पेज पर ब्राउज़र जैसा User-Agent लगाकर curl -I चलाया (HTTP हेडर में X-Robots-Tag देखने के लिए), पूरा HTML खींचकर <meta name="robots"> देखा, और हर सर्विस का robots.txt सीधे पढ़ा। जो सर्विसेज़ JavaScript से कंटेंट रेंडर करती हैं और curl से असली लिंक नहीं मिलता (जैसे Imgur के होमपेज का सजेस्टेड सेक्शन), वहां ब्राउज़र ऑटोमेशन टूल से पेज असल में लोड करके लिंक निकाला।

क्या फोटो असल में सर्च में मिलती है, यह चेक करने के लिए मैंने Google सर्च भी चलाई — लेकिन एक सीमा बताना ज़रूरी है: जो सर्च टूल मैंने इस्तेमाल किया, उसे imgur.com डोमेन ने ही ब्लॉक कर रखा था (Google ने नहीं, बल्कि Imgur की सुरक्षा ने ही उस सर्च टूल के क्रॉलर को रोका), इसलिए Imgur वाले सेल में "क्या इंडेक्स हुआ" कॉलम मैं उसी तरीके से वेरिफाई नहीं कर पाया — सिर्फ टेक्निकल सेटिंग के आधार पर यह कह सकता हूं कि वह "थ्योरेटिकली इंडेक्स होने लायक है"। यह मैं छुपाना नहीं चाहता, टूल की सीमा है, और झूठ बोलने से बेहतर है साफ बता देना।

पूरी तुलना तालिका

सर्विस	व्यू पेज का उदाहरण	robots.txt में रोक	meta robots / X-Robots-Tag	इंडेक्स स्टेटस (सितंबर 2026)
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 शेयर लिंक	photos.app.goo.gl/xxx	/share/ पाथ robots.txt में साफ तौर पर एक्सक्लूड नहीं	पेज JS से रेंडर होता है, curl से कंटेंट का अंदाज़ा नहीं लग पाया	इंडेक्स हो चुका — सर्च में दूसरों के शेयर लिंक मिले, कुछ अब भी खुल जाते हैं
lpic.cc	lpic.cc/शॉर्ट-कोड	Allow: / (होमपेज लेवल पर खुला)	व्यू पेज के सोर्स कोड में साफ index: false, follow: true सेट है	साफ तौर पर noindex — डिज़ाइन से ही व्यू पेज इंडेक्स नहीं होता

Google Photos वाली लाइन देखकर, ईमानदारी से कहूं तो मैं एक पल के लिए चौंक गया।

हर सर्विस की बारीकी — दिक्कत किस लेयर में है

ImgBB और Postimages इस टेस्ट में सबसे साफ मामले हैं: robots.txt सीधे खाली कंटेंट लौटाता है, यानी कोई पाथ रोक नहीं है; पेज में meta robots टैग भी कहीं नहीं। कोई रोक नहीं और कोई टैग नहीं — मतलब "पूरी तरह खुला" डिफ़ॉल्ट है, कोई ऑप्शन नहीं जिसे अपलोड के वक्त बंद किया जा सके। सर्च करते ही लगभग तुरंत रिज़ल्ट मिल गए, और कई पेजों का टाइटल फोन कैमरे का ओरिजिनल फ़ाइलनेम था (IMG_ के बाद तारीख-समय वाला पैटर्न) — साफ पता चलता है कि सीधे फोन से अपलोड हुई फोटो है।

Flickr का मामला ज़्यादा बारीक है और गलत समझा जाना आसान है। इसके robots.txt में करीब चालीस नामी क्रॉलर (Googlebot समेत) लिस्टेड हैं, जिन्हें सिर्फ कुछ खास अकाउंट या फीचर पेज से रोका गया है — आम यूज़र का /photos/username/photo-id पाथ इस रोक-सूची में नहीं है; पेज पर सिर्फ noarchive (वेब स्नैपशॉट नहीं) है, noindex बिल्कुल नहीं। यह असली उदाहरण है: जो फोटो पेज मुझे सर्च में मिला, वह Flickr के आधिकारिक अकाउंट की एक ट्यूटोरियल पोस्ट थी, जिसमें बताया गया था "Flickr फोटो कैसे शेयर करें" — यानी शेयर करना सिखाने वाला पेज खुद ही सर्च में मिल गया, यह थोड़ा आयरनिक है।

Google Photos शेयर लिंक इस टेस्ट का सबसे चिंताजनक हिस्सा है। ध्यान दें: शेयर लिंक ऊपर से लगता है कि "जिसे दिया, सिर्फ वही देख सकता है" वाला प्राइवेट मैकेनिज़्म है, लेकिन मैंने बिना किसी खास कमांड के, सिर्फ आम कीवर्ड से सर्च करके दूसरों के photos.app.goo.gl शेयर लिंक ढूंढ निकाले (प्राइवेसी की वजह से यहां असली लिंक नहीं दिए जा रहे)। इनमें से कुछ खोलने पर लॉगिन मांगता है — मतलब शेयर परमिशन बाद में बदल दी गई या एक्सपायर हो गई; कुछ अब भी सीधे खुल जाते हैं — यानी "सिर्फ किसी खास व्यक्ति के साथ प्राइवेट शेयर किया गया" लिंक, कभी था या अब भी है, पब्लिक सर्च से खोजा जा सकता है। यह बिल्कुल Claude वाली घटना जैसा ही रिस्क शेप है: लिंक बनाने का इरादा पब्लिक करने का नहीं था, पर क्रॉलर रूल्स की बारीकियां तय करती हैं कि सर्च इंजन उसे उठाएगा या नहीं।

Catbox एक अलग ही मामला है। इसकी बाकी सर्विसेज़ जैसी अलग "व्यू पेज" है ही नहीं — अपलोड करते ही सीधे फ़ाइल का डायरेक्ट लिंक मिलता है, खोलते ही फोटो खुद दिखती है, कोई HTML खोल नहीं जिसमें meta robots टैग लगाया जा सके। इसका मतलब पारंपरिक "meta robots चेक" यहां हो ही नहीं सकता। लेकिन इसका मतलब यह नहीं कि यह ज़्यादा सुरक्षित है — बस रिस्क कहीं और शिफ्ट हो जाता है: Google इमेज सर्च फिर भी डायरेक्ट फोटो URL इंडेक्स कर सकता है, बस उसका पैमाना HTML पेज वाले पैमाने से अलग है, और इस हिस्से के लिए मुझे कोई भरोसेमंद वेरिफिकेशन तरीका नहीं मिला — सच कहूं तो यह वेरिफाई ही नहीं हो पाया, और मैं कोई मनगढ़ंत आंकड़ा नहीं देना चाहता।

lpic.cc — मेरा अपना प्रोडक्ट — भी मैंने साथ में टेस्ट किया, सिर्फ दूसरों को टेस्ट करना ठीक नहीं। सोर्स कोड देखने पर पता चलता है कि व्यू पेज की metadata में साफ robots: { index: false, follow: true } लिखा है — यानी अगर आपका शॉर्ट-कोड कहीं शेयर हो जाए और किसी क्रॉलर तक पहुंच भी जाए, पेज खुद ही Google को बताता है "मुझे इंडेक्स मत करो"। यह डिज़ाइन के वक्त ही तय किया गया व्यवहार है, इस टेस्ट के लिए अभी जोड़ा गया पैच नहीं। लेकिन सच कहूं तो noindex सिर्फ सर्च रिज़ल्ट में आने से रोकता है, "URL पता होने पर खुल जाना" इससे नहीं रुकता — इसीलिए पासवर्ड प्रोटेक्शन फीचर मौजूद है, और दोनों साथ इस्तेमाल करने पर ही सुरक्षा पूरी होती है।

आपके लिए असली रिस्क क्या है

टेक्निकल बातों को सीधी भाषा में कहें तो: अगर आपने आधार कार्ड, PAN कार्ड, बैंक स्टेटमेंट, या मेडिकल रिपोर्ट की फोटो ImgBB या Postimages जैसी डिफ़ॉल्ट-खुली इंडेक्सिंग वाली सर्विस पर डाली, तो थ्योरेटिकली कोई भी कीवर्ड या फोटो में मौजूद टेक्स्ट से उसे ढूंढ सकता है — आपका शेयर किया लिंक चाहिए ही नहीं, बस इतना काफी है कि सर्च इंजन उसे पहले ही क्रॉल कर चुका हो।

भारत में यह खतरा और ज़्यादा असल है क्योंकि Aadhaar, PAN, ड्राइविंग लाइसेंस जैसी KYC डॉक्यूमेंट की स्कैन कॉपी अक्सर व्हाट्सऐप/टेलीग्राम के ज़रिए किसी थर्ड पार्टी को भेजने के लिए किसी फ्री इमेज होस्टिंग पर पहले अपलोड कर दी जाती है, ताकि लिंक भेजना आसान हो। DPDP Act, 2023 (Digital Personal Data Protection Act) के तहत ऐसा डेटा लीक कानूनी तौर पर "डेटा फिड्यूशियरी" की ज़िम्मेदारी में आ सकता है, पर आम यूज़र के लिए असली सुरक्षा फिर भी यही है कि अपलोड से पहले ही सही सर्विस चुनी जाए — कानून लीक होने के बाद मदद करता है, होने से रोकता नहीं।

अपनी शेयर लिंक कैसे सुरक्षित रखें

हर फोटो को एक जैसी सुरक्षा की ज़रूरत नहीं, असली बात यह है कि "बस मज़ाक वाला मीम" और "पर्सनल डॉक्यूमेंट की स्कैन" को अलग लेवल का टूल मिलना चाहिए। तीन ठोस तरीके:

• अपलोड से पहले और बाद में, फ़ाइलनेम या फोटो में मौजूद कोई टेक्स्ट लेकर खुद एक बार Google पर सर्च कर लें।
• सेंसिटिव कंटेंट के लिए डिफ़ॉल्ट-खुली इंडेक्सिंग वाली सर्विस से बचें, ऐसी सर्विस चुनें जो साफ तौर पर noindex बताती हो या पासवर्ड प्रोटेक्शन देती हो।
• शेयर लिंक की एक्सपायरी खुद सेट करें, यह मत मान लें कि "किसी को URL पता ही नहीं" — Claude वाली घटना साबित कर चुकी है कि क्रॉलर को URL जानने की ज़रूरत नहीं, बस कोई एक बाहरी लिंक उस पर पॉइंट कर दे तो काफी है।

अगर आप ऐसी सर्विस ढूंढ रहे हैं जिसमें "शेयर लिंक डिफ़ॉल्ट रूप से इंडेक्स न हो" और "पासवर्ड प्रोटेक्शन" दोनों बिल्ट-इन हों, तो lpic.cc की व्यू पेज पहले से ही noindex डिज़ाइन की है, साथ ही पासवर्ड प्रोटेक्शन फीचर भी है — दोनों लेयर एक साथ मिल जाती हैं। पर सीमाएं भी साफ बता देना ज़रूरी है: फ्री प्लान में मीडिया डिफ़ॉल्ट रूप से अपलोड के 30 दिन बाद एक्सपायर हो जाता है (अपलोड फॉर्म में "देखने पर ऑटो-एक्सटेंड" डिफ़ॉल्ट ऑन रहता है), एक्सपायर होने पर डिलीट हो जाता है, और सर्विस विज्ञापनों से चलती है — यह ट्रेड-ऑफ अपलोड करने से पहले ही पता होना चाहिए।

अक्सर पूछे जाने वाले सवाल (FAQ)

Q1: सिर्फ noindex सेट करने से फोटो कभी सर्च में नहीं आएगी? पूरी तरह गारंटी नहीं। noindex एक "रिक्वेस्ट" है, क्रॉलर से इंडेक्स न करने की — ज़्यादातर केस में Google इसे मानता है, पर शर्त यह है कि क्रॉलर उस टैग तक पहुंच ही पाए। अगर robots.txt उसी पाथ को साथ में रोक दे, तो क्रॉलर अंदर घुस ही नहीं पाता, और noindex दिख ही नहीं पाता — यही Claude वाली घटना की असली वजह थी।

Q2: Catbox जैसी डायरेक्ट-फ़ाइल-लिंक सर्विस में फोटो सर्च में आ सकती है? Meta robots से यह जज नहीं हो सकता क्योंकि कोई HTML पेज ही नहीं। थ्योरेटिकली Google इमेज सर्च डायरेक्ट फ़ाइल URL इंडेक्स कर सकता है, पर वेरिफाई करने का तरीका आम वेबपेज से अलग है — इस टेस्ट में मुझे कोई भरोसेमंद वेरिफिकेशन तरीका नहीं मिला, इसलिए मैं बिना वेरिफाई किए कोई दावा नहीं करूंगा।

Q3: मैंने ImgBB पर फोटो डाली थी और वह सर्च में मिल गई — इंडेक्स से हटा सकता हूं? पहले ओरिजिनल फोटो डिलीट करें ताकि URL काम करना बंद कर दे, फिर Google Search Console के "Remove URL" टूल से हटाने की रिक्वेस्ट भेजें — यह क्रॉलर के दोबारा क्रॉल करने का इंतज़ार करने से कहीं तेज़ होगा।

Q4: यह टेस्ट सितंबर 2026 का है, आगे सेटिंग बदल गई तो? robots.txt और meta टैग कभी भी बदल सकते हैं, यह गारंटी परमानेंट नहीं होती। इसलिए इस टेबल को रटने के बजाय, खुद curl -I या ब्राउज़र के डेवलपर टूल से एक बार चेक कर लेना ज़्यादा टिकाऊ तरीका है।

Q5: Flickr Googlebot को क्यों जाने देता है पर बाकी ज़्यादातर क्रॉलर को रोकता है? यह जानबूझकर लिया गया फैसला है — मुख्यधारा के सर्च इंजन को इंडेक्स करने देना ताकि ट्रैफिक और विज़िबिलिटी बनी रहे, वहीं अनजान थर्ड-पार्टी क्रॉलर को रोकना ताकि कंटेंट चोरी या मिसयूज़ का रिस्क कम हो — दोनों अलग-अलग ट्रेड-ऑफ हैं, एक ही बात नहीं।

Q6: भारत में इस तरह के फोटो लीक पर शिकायत कहां करें? अगर लीक हुई फोटो में पर्सनल आइडेंटिटी डॉक्यूमेंट है, तो CERT-In (Indian Computer Emergency Response Team) को रिपोर्ट किया जा सकता है, साथ ही उस सर्विस के टेकडाउन प्रोसेस से भी हटाने की रिक्वेस्ट भेजें। DPDP Act के तहत कंपनियों पर ज़िम्मेदारी है, पर प्रोसेस में समय लगता है, इसलिए रोकथाम अपलोड से पहले ही करनी बेहतर है।

संदर्भ स्रोत

• Claude चैट शेयर लिंक Google पर इंडेक्स होने की घटना की रिपोर्ट（29 जुलाई 2026）
• Imgur, ImgBB (ibb.co), Postimages (postimg.cc), Flickr, Google Photos (photos.google.com), Catbox (catbox.moe) — इन सभी सर्विसेज़ की robots.txt, सितंबर 2026 में सीधे एक्सेस करके ली गई
• ऊपर बताई सभी सर्विसेज़ के व्यू पेज के HTTP हेडर और HTML सोर्स कोड, सितंबर 2026 में curl और ब्राउज़र ऑटोमेशन टूल से टेस्ट किए गए
• lpic.cc व्यू पेज की metadata सोर्स कोड (app/(public)/[locale]/[code]/page.tsx)