Shopify स्टोर्स के साथ Cloudflare Crawl Endpoint के फायदे और नुकसान

Cloudflare /crawl Endpoint क्या है?

Cloudflare का /crawl endpoint उनके Browser Rendering API का हिस्सा है, जो वर्तमान में ओपन बीटा में है। यह एक शुरुआती URL से कंटेंट स्क्रैप करता है, कॉन्फिगर करने योग्य डेप्थ या पेज सीमा तक साइट भर के लिंक फॉलो करता है, और परिणामों को HTML, Markdown, या Workers AI द्वारा संचालित स्ट्रक्चर्ड JSON के रूप में लौटाता है। Cloudflare इसे मॉडल ट्रेनिंग, RAG पाइपलाइन बनाने, और किसी साइट के कंटेंट पर शोध या निगरानी के लिए एक टूल के रूप में प्रस्तुत करता है।

Endpoint एक साइन्ड-एजेंट के रूप में काम करता है जो डिफ़ॉल्ट रूप से robots.txt और Cloudflare के AI Crawl Control का सम्मान करता है, जो एक उल्लेखनीय डिज़ाइन निर्णय है। इसका उद्देश्य डेवलपर्स के लिए वेबसाइट नियमों का अनुपालन आसान बनाना और क्रॉलर्स के लिए साइट मालिक के मार्गदर्शन को अनदेखा करना कठिन बनाना है।

Endpoint यहां स्थित है:

https://api.cloudflare.com/client/v4/accounts/<account_id>/browser-rendering/crawl

इसे उपयोग करने के लिए आपको Browser Rendering Edit अनुमति वाले Cloudflare API टोकन की आवश्यकता है।

यह कैसे काम करता है

क्रॉल दो चरणों में एक एसिंक्रोनस जॉब के रूप में चलता है:

1. क्रॉल शुरू करें एक शुरुआती URL वाले POST अनुरोध के साथ। API तुरंत एक जॉब ID लौटाता है।
2. परिणामों के लिए पोल करें उस जॉब ID का उपयोग करके GET अनुरोधों के साथ। जब जॉब का स्टेटस running से completed में बदलता है, तो आपका क्रॉल किया गया डेटा तैयार है।

जॉब सात दिनों तक चल सकते हैं। पूरा होने के बाद परिणाम 14 दिनों तक संग्रहीत रहते हैं।

आप क्या भेजते हैं

न्यूनतम रूप से, आप एक URL भेजते हैं:

curl -X POST 'https://api.cloudflare.com/client/v4/accounts/{account_id}/browser-rendering/crawl' \
  -H 'Authorization: Bearer <apiToken>' \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "https://example.com"
  }'

मुख्य पैरामीटर

आपको क्या वापस मिलता है

प्रत्येक क्रॉल किया गया पेज एक रिकॉर्ड के रूप में लौटाया जाता है जिसमें URL, स्टेटस, आपके चुने गए फॉर्मेट में कंटेंट, और बेसिक मेटाडेटा (HTTP स्टेटस कोड, पेज टाइटल, रीडायरेक्ट के बाद अंतिम URL) शामिल होता है। render: true के साथ, आपको Open Graph टैग भी मिलते हैं। रिस्पॉन्स में बिलिंग दृश्यता के लिए browserSecondsUsed और 10 MB से अधिक परिणामों को पेजिनेट करने के लिए cursor भी शामिल है।

यहां एक लाइव Shopify स्टोर के 24-पेज रेंडर्ड क्रॉल से वास्तविक जॉब-स्तरीय रिस्पॉन्स दिया गया है:

{
  "job_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "status": "completed",
  "total": 24,
  "finished": 24,
  "browserSecondsUsed": 58.38,
  "record_count": 24,
  "records": [
    {
      "url": "https://www.example-store.com/products/premium-widget-bundle",
      "status": "completed",
      "metadata": {
        "status": 200,
        "title": "Premium Widget Bundle | Example Store",
        "url": "https://www.example-store.com/products/premium-widget-bundle",
        "lastModified": "",
        "og:type": "product",
        "og:site_name": "Example Store",
        "og:title": "Premium Widget Bundle | Example Store",
        "og:image": "https://www.example-store.com/cdn/shop/files/product-image.jpg",
        "og:description": "Our best-selling bundle with everything you need..."
      },
      "markdown": "Store\n\nexample-store\n\nURL\n\nhttps://www.example-store.com\n\nCurrency\n\nUSD\n\n# Premium Widget Bundle\n\nOur best-selling bundle with everything you need..."
    }
  ]
}

render: true के साथ, मेटाडेटा ऑब्जेक्ट में Open Graph फील्ड्स का पूरा सेट शामिल होता है: type, site name, title, image URL, और description। ये ब्राउज़र रेंडर के दौरान पेज के OG मेटा टैग से प्राप्त किए जाते हैं। render: false के साथ, मेटाडेटा में केवल HTTP स्टेटस कोड, पेज टाइटल, और अंतिम URL होता है। कोई Open Graph फील्ड एक्सट्रैक्ट नहीं होती।

मार्कडाउन फील्ड में केवल मुख्य कंटेंट नहीं, बल्कि पूरे पेज का आउटपुट होता है। नेविगेशन मेनू, मेगा मेनू, फुटर, और दोहराए जाने वाले टेम्पलेट ब्लॉक सभी हर रिकॉर्ड में शामिल होते हैं। हमारे परीक्षणों में, औसत पेज ने लगभग 158 KB मार्कडाउन लौटाया, जिसमें से लगभग 90% दोहराया गया बॉयलरप्लेट था। यदि आप इसे LLM या RAG पाइपलाइन में फीड कर रहे हैं, तो आपको टेम्पलेट हटाने और वास्तविक पेज कंटेंट को अलग करने के लिए अपने स्वयं के कंटेंट एक्सट्रैक्शन लॉजिक की आवश्यकता होगी।

जब हमने उसी स्टोर पर render: false चलाया तो यह रिस्पॉन्स आया:

{
  "job_id": "f9e8d7c6-b5a4-3210-fedc-ba9876543210",
  "status": "completed",
  "total": 266,
  "finished": 266,
  "browserSecondsUsed": 0,
  "record_count": 256,
  "records": [
    {
      "url": "https://www.example-store.com/products/classic-knit-sweater",
      "status": "completed",
      "metadata": {
        "status": 200,
        "title": "Classic Knit Sweater | Example Store",
        "url": "https://www.example-store.com/products/classic-knit-sweater",
        "lastModified": ""
      },
      "markdown": "Skip to content\n\nFree Shipping $150+\n\n# Classic Knit Sweater\n\nOur best-selling sweater made from premium natural fibers..."
    }
  ]
}

शून्य ब्राउज़र सेकंड, 266 पेजों में से 256 रिकॉर्ड। रेंडर्ड संस्करण की तुलना में मेटाडेटा न्यूनतम है: कोई Open Graph फील्ड नहीं, केवल HTTP स्टेटस, पेज टाइटल, और URL। लेकिन मार्कडाउन में अभी भी नेविगेशन, प्रोडक्ट विवरण, और फुटर सहित पूरा पेज कंटेंट है। सर्वर-रेंडर्ड Shopify स्टोर्स के लिए, स्टैटिक HTML में पहले से वह सब कुछ है जो आपको चाहिए।

URL खोज

क्रॉलर तीन स्रोतों के माध्यम से URLs खोजता है (जब source all पर सेट हो):

1. आपके द्वारा प्रदान किया गया शुरुआती URL
2. डोमेन पर मिले साइटमैप लिंक
3. क्रॉल किए गए पेजों पर मिले इंटरनल लिंक

आप source पैरामीटर का उपयोग करके इसे केवल साइटमैप या केवल पेज लिंक तक सीमित कर सकते हैं। excludePatterns हमेशा includePatterns पर प्राथमिकता लेता है, इसलिए आप एक विस्तृत जाल बिछा सकते हैं और फिर उन अनुभागों को हटा सकते हैं जिनकी आपको आवश्यकता नहीं है।

रेंडरिंग बनाम फास्ट फेच

render: true (डिफ़ॉल्ट) एक हेडलेस ब्राउज़र चालू करता है, JavaScript निष्पादित करता है, और पेज के पूरी तरह लोड होने की प्रतीक्षा करता है। यह सिंगल-पेज एप्लिकेशन और JavaScript-रेंडर्ड कंटेंट के लिए आवश्यक है, लेकिन यह ब्राउज़र सेकंड का उपयोग करता है जो बिल किए जाते हैं।

render: false JavaScript निष्पादित किए बिना एक तेज HTML फेच करता है। बीटा के दौरान, ये फेच बिल नहीं किए जाते। यह स्टैटिक साइटों या सर्वर-रेंडर्ड पेजों के लिए सही विकल्प है जहां कंटेंट पहले से प्रारंभिक HTML में है।

बिलिंग और उपलब्धता

Endpoint Workers Free और Paid दोनों प्लान पर उपलब्ध है। रेंडर्ड क्रॉल Cloudflare की Browser Rendering प्राइसिंग के तहत आपके शामिल आवंटन से परे $0.09 प्रति ब्राउज़र घंटा बिल किए जाते हैं।

Workers Free: प्रति दिन 10 मिनट का ब्राउज़र समय। /crawl endpoint प्रति दिन 5 जॉब, प्रति क्रॉल 100 पेज, और प्रति मिनट 6 API अनुरोधों तक सीमित है।

Workers Paid ($5/माह): प्रति माह 10 घंटे का ब्राउज़र समय शामिल। कोई प्रति-क्रॉल पेज सीमा नहीं। प्रति मिनट 600 API अनुरोध। अतिरिक्त ब्राउज़र घंटे $0.09 प्रत्येक हैं।

render: false क्रॉल शून्य ब्राउज़र समय उपयोग करते हैं। ये बीटा के दौरान मुफ्त हैं लेकिन अंततः मानक Workers प्राइसिंग के अंतर्गत आएंगे।

वॉल क्लॉक टाइम क्या है?

वॉल क्लॉक टाइम क्रॉल शुरू होने से लेकर पूरा होने तक का कुल बीता हुआ समय है, ठीक वैसे ही मापा जाता है जैसे आप इसे स्टॉपवॉच से मापते। इसमें सब कुछ शामिल है: नेटवर्क लेटेंसी, Cloudflare का आंतरिक क्यू समय, DNS लुकअप, सर्वर रिस्पॉन्स टाइम, और (यदि रेंडरिंग सक्षम है) ब्राउज़र निष्पादन समय।

वॉल क्लॉक टाइम ब्राउज़र टाइम से अलग है। ब्राउज़र टाइम केवल उन सेकंड की गणना करता है जो Cloudflare का हेडलेस ब्राउज़र सक्रिय रूप से पेज रेंडर करने में खर्च करता है। एक क्रॉल 22 मिनट का ब्राउज़र टाइम उपयोग कर सकता है लेकिन क्यू और नेटवर्क ओवरहेड के कारण 25 मिनट वॉल क्लॉक ले सकता है। बिना रेंडरिंग वाले क्रॉल शून्य ब्राउज़र टाइम उपयोग करते हैं लेकिन फेच और क्यू प्रक्रिया से वॉल क्लॉक टाइम अभी भी होता है।

हमारे बेंचमार्क में, हम दोनों नंबर रिपोर्ट करते हैं ताकि आप देख सकें कि आप किसके लिए भुगतान कर रहे हैं (ब्राउज़र टाइम) बनाम आप वास्तव में कितनी देर प्रतीक्षा कर रहे हैं (वॉल क्लॉक टाइम)।

बारीक शर्तें

Endpoint crawl-delay सहित robots.txt निर्देशों का सम्मान करता है। यह स्वयं को CloudflareBrowserRenderingCrawler/1.0 के रूप में पहचानता है। यह CAPTCHAs, Turnstile चुनौतियों, या अन्य बॉट सुरक्षा को बाइपास नहीं करता। यदि आप अपनी खुद की साइट क्रॉल कर रहे हैं और ब्लॉक हो रहे हैं, तो आपको क्रॉलर को अनुमति देने के लिए एक WAF स्किप नियम बनाना होगा।

Cloudflare /crawl पांच Shopify स्टोर्स पर कैसे व्यवहार करता है

हमने गति, सफलता दर, लागत, और क्रॉलर प्रत्येक साइट के साथ कैसे इंटरैक्ट करता है, यह मापने के लिए पांच लाइव Shopify स्टोर्स पर /crawl endpoint चलाया। हर स्टोर का नाम गुमनाम रखा गया है। ये वास्तविक क्रॉल से वास्तविक नंबर हैं। वॉल क्लॉक टाइम अनुमानित आंकड़े हैं। कुछ शुरुआती परीक्षणों में सीमित एरर हैंडलिंग वाली स्क्रिप्ट का उपयोग किया गया, जिसने कुछ स्टोर्स पर रिपोर्ट की गई सफलता दरों को प्रभावित किया हो सकता है। जहां यह लागू होता है, हमने नीचे नोट किया है।

यह एक सेट-इट-एंड-फॉरगेट-इट endpoint नहीं है। प्रत्येक स्टोर ने endpoint अनुरोधों पर अलग-अलग प्रतिक्रिया दी। कुछ को रेंडर्ड क्रॉल पूरा करने के लिए रिसोर्स ब्लॉकिंग की आवश्यकता थी। अन्य ने एक मोड पर 429 एरर लौटाए लेकिन दूसरे पर ठीक काम किया। Crawl-delay निर्देश, पेज काउंट, और स्टोर आर्किटेक्चर सभी ने परिणाम बदल दिए। प्रत्येक साइट के लिए सेटिंग्स का परीक्षण और ट्यूनिंग करने की योजना बनाएं। हमारी अनुशंसित कॉन्फिगरेशन साइट टाइप के अनुसार देखने के लिए, किसी भी वेबसाइट के लिए सबसे अच्छी Cloudflare /crawl सेटिंग्स देखें।

टेस्ट 1: बड़ा ई-कॉमर्स कैटलॉग (स्टोर A)

हमने /crawl endpoint को लगभग 3,000 पेजों वाले एक बड़े Shopify स्टोर पर चलाया। कंटेंट तेजी से वापस आया, मार्कडाउन उपयोग योग्य था, और endpoint को प्रोडक्ट पेज, कलेक्शन पेज, और ब्लॉग कंटेंट फेच करने में कोई समस्या नहीं हुई। कोई प्रॉक्सी समस्या नहीं, कोई ब्लॉक नहीं, कोई रेट लिमिटिंग नहीं।

हमने अलग-अलग स्केल पर कई क्रॉल चलाए:

JavaScript रेंडरिंग के बिना क्रॉलिंग ने दोनों स्केल पर 100% सफलता प्राप्त की। पूर्ण ब्राउज़र रेंडरिंग ने एक छोटे सैंपल टेस्ट में 5 में से 4 पेज लौटाए। इतने छोटे सैंपल पर, एक गायब पेज ब्राउज़र टाइमआउट, क्षणिक एरर, या स्क्रिप्ट-साइड समस्या हो सकती है।

टेस्ट 2: छोटा Shopify स्टोर (स्टोर D, 24 पेज)

एक छोटा स्टोर जहां हमने पूरा वर्कफ्लो टेस्ट किया:

रेंडरिंग के बिना क्रॉलिंग ने एरर लौटाए। हमारे शुरुआती टेस्ट ने प्लेन HTML फेच पर 429 रिस्पॉन्स लौटाए। हमने इस स्टोर को बेहतर एरर हैंडलिंग के साथ दोबारा टेस्ट नहीं किया है, इसलिए हम पुष्टि नहीं कर सकते कि 429s स्टोर की रेट लिमिटिंग से आए या टेस्ट के दौरान क्षणिक समस्याओं से।

साइटमैप-आधारित डिस्कवरी के साथ पूर्ण रेंडरिंग पूरी तरह सफल रही। 24 में से 24 पेज क्रॉल हुए, 100% पूर्णता।

एक महत्वपूर्ण खोज: डिफ़ॉल्ट URL डिस्कवरी मोड ने केवल 1 पेज खोजा क्योंकि होमपेज में लगभग कोई इंटरनल लिंक नहीं थे। साइटमैप-आधारित डिस्कवरी पर स्विच करने से सभी 24 पेज मिले। यदि आपका होमपेज न्यूनतम या JavaScript-भारी है, तो क्रॉलर केवल लिंक के माध्यम से पेज नहीं खोज सकता।

टेस्ट 3: मध्यम आकार का अपैरल स्टोर (स्टोर B, 256 पेज), रेंडरिंग के साथ और बिना

हमारा सबसे विस्तृत टेस्ट। 256 इंडेक्सेबल पेजों वाला एक मध्यम आकार का अपैरल स्टोर: प्रोडक्ट, कलेक्शन, ब्लॉग पोस्ट, और सूचनात्मक पेज। हमने वास्तविक अंतर मापने के लिए पूरी साइट पर दोनों मोड चलाए।

टेस्ट 4: हेल्थ और सप्लीमेंट्स रिटेलर (स्टोर C), बड़े स्केल पर आंशिक सफलता

एक विशाल कैटलॉग वाला बड़ा हेल्थ प्रोडक्ट रिटेलर। हमने अलग-अलग स्केल पर रेंडरिंग के बिना दो क्रॉल चलाए:

आंशिक सफलता दर यह संकेत कर सकती है कि इस स्टोर का इन्फ्रास्ट्रक्चर कुछ नॉन-ब्राउज़र अनुरोधों को ड्रॉप करता है, लेकिन हमारे शुरुआती टेस्ट में मजबूत एरर रिकवरी नहीं थी, इसलिए इनमें से कुछ विफलताएं हमारी तरफ बेहतर रिट्राई हैंडलिंग से ठीक हो सकती थीं। सफलता दर बड़े स्केल पर 40% से 89% तक सुधरी। हमने कारण अलग करने के लिए इस स्टोर को बेहतर एरर हैंडलिंग के साथ दोबारा टेस्ट नहीं किया है।

टेस्ट 5: बड़ा मल्टी-कैटेगरी स्टोर (स्टोर E, ~1,200 पेज)

हमारा सबसे बड़ा और सबसे खुलासा करने वाला टेस्ट। चार साइटमैप में वितरित लगभग 1,200 URLs वाला एक Shopify स्टोर: 521 प्रोडक्ट, 626 कलेक्शन, 22 पेज, और 31 ब्लॉग पोस्ट।

नो-रेंडर क्रॉल ने शून्य ब्राउज़र लागत के साथ सभी 1,200 पेजों पर 100% सफलता प्राप्त की। रेंडर्ड क्रॉल रिसोर्स ब्लॉकिंग ऑप्टिमाइज़ेशन सक्षम करके 100-पेज सैंपल पर चलाया गया।

रिसोर्स ब्लॉकिंग ने अटके हुए क्रॉल और साफ क्रॉल के बीच का फर्क बनाया। रिसोर्स ब्लॉक किए बिना, रेंडर्ड क्रॉल 100 में से 99 पेजों पर अनिश्चित काल तक अटक गया और उन 99 पेजों के लिए 649 सेकंड ब्राउज़र टाइम खर्च किया। रिसोर्स ब्लॉकिंग (इमेज, मीडिया, फॉन्ट, स्टाइलशीट) को domcontentloaded वेट कंडीशन के साथ सक्षम करने से सभी 100 पेज 475 सेकंड में पूरे हुए, बिना किसी हैंगिंग के ब्राउज़र टाइम में 27% की कमी।

robots.txt में Crawl-delay ने दिखाई देने वाले ठहराव पैदा किए। स्टोर E की robots.txt कुछ बॉट्स के लिए 10-सेकंड crawl-delay निर्दिष्ट करती है। हमारे नो-रेंडर पोलिंग डेटा में, यह कई मिनट के पठार के रूप में दिखाई दिया जहां पेज काउंट फिर से शुरू होने से पहले रुक गया। Cloudflare क्रॉलर crawl-delay निर्देशों का सम्मान करता है, जो उन साइटों पर वॉल क्लॉक टाइम को सीधे बढ़ाता है जो इन्हें सेट करती हैं।

/crawl Endpoint वास्तव में क्या स्वीकार करता है

Endpoint एक शुरुआती URL लेता है, सूची नहीं। यह उस URL से साइटमैप, पेज लिंक, या दोनों के माध्यम से बाहर की ओर स्पाइडरिंग करके पेज खोजता है। यदि आपके पास पहले से Scrapy क्रॉल से URL सूची है और मार्कडाउन कन्वर्शन के लिए Cloudflare का उपयोग करना चाहते हैं, तो आपको प्रत्येक URL के लिए अलग /markdown या /scrape endpoints को व्यक्तिगत रूप से कॉल करना होगा।

Cloudflare /crawl सर्वर साइड पर वास्तव में क्या करता है?

हमने स्टोर D (25 पेज) के पूर्ण रेंडर्ड क्रॉल के दौरान पूरे सर्वर लॉग निकाले ताकि वास्तविक ट्रैफिक फुटप्रिंट का विश्लेषण किया जा सके। परिणाम ब्राउज़र-रेंडर्ड क्रॉलिंग और पारंपरिक बॉट क्रॉलिंग के बीच मौलिक अंतर दर्शाते हैं, जिसमें एनालिटिक्स, सर्वर लोड, और बॉट ट्रैफिक मॉनिटरिंग पर अनपेक्षित दुष्प्रभाव शामिल हैं।

पूर्ण रेंडर्ड Cloudflare /crawl वास्तव में कितना ट्रैफिक उत्पन्न करता है?

सबसे बड़ी खोज: 2,234 अनुरोधों में से केवल 1.1% वास्तविक पेज कंटेंट थे। शेष 98.9% JavaScript, CSS, एनालिटिक्स बीकन, ट्रैकिंग पिक्सल, और चेकआउट प्रीलोड थे जो ब्राउज़र द्वारा हर पेज को वास्तविक विज़िटर की तरह लोड करने से ट्रिगर हुए।

Amazonbot या ChatGPT-User जैसा नॉन-रेंडर्ड बॉट प्रति पेज 1 अनुरोध उत्पन्न करता है। Cloudflare ब्राउज़र रेंडरर 89 उत्पन्न करता है।

क्या Cloudflare /crawl Shopify एनालिटिक्स को बढ़ाता है?

हमारे लॉग में 163 POST अनुरोध पूरी तरह से Shopify एनालिटिक्स और ट्रैकिंग endpoints थे जो क्रॉल के दौरान फायर हुए। ये वही इवेंट हैं जो वास्तविक ग्राहक द्वारा आपके स्टोर पर आने पर फायर होते हैं। Shopify Analytics के दृष्टिकोण से, Cloudflare क्रॉलर 2 मिनट में आपकी साइट के हर पेज को ब्राउज़ करने वाले विज़िटर जैसा दिखता है।

Cloudflare /crawl आपके सर्वर को कितनी तेजी से हिट करता है?

सभी 2,234 अनुरोध 134 सेकंड की विंडो में आए। पीक थ्रूपुट 82 अनुरोध प्रति सेकंड तक पहुंचा। क्रॉलर ने पूरी 25-पेज साइट को 2 मिनट से थोड़ा अधिक समय में रेंडर किया, लेकिन सर्वर ने ट्रैफिक का एक निरंतर बर्स्ट देखा जो ऑर्गेनिक ब्राउज़िंग पैटर्न से बिल्कुल अलग दिखता है।

छोटे स्टोर्स के लिए, यह प्रबंधनीय है। हजारों पेजों वाले बड़े स्टोर्स के लिए, अनुरोध एम्प्लीफिकेशन (प्रति पेज 89x) निरंतर थ्रूपुट के साथ मिलकर ओरिजिन सर्वर पर महत्वपूर्ण लोड बना सकता है, विशेषकर यदि आप शेयर्ड होस्टिंग प्लान पर हैं या आक्रामक रेट लिमिटिंग लागू है।

Cloudflare /crawl कहां से आता है?

क्रॉल US में 5 Cloudflare डेटा सेंटर्स में वितरित किया गया:

यह एक सिंगल सर्वर नहीं है जो अनुरोध कर रहा है। Cloudflare रेंडरिंग वर्कलोड को अपने एज नेटवर्क में वितरित करता है। सभी 23 IPs 104.28.x.x रेंज में थे, और user-agent हर एक अनुरोध पर CloudflareBrowserRenderingCrawler/1.0 था।

Cloudflare /crawl कौन-सा ब्राउज़र फिंगरप्रिंट छोड़ता है?

रेंडरर उचित Sec-Fetch हेडर भेजता है जो वास्तविक Chrome ब्राउज़र की नकल करते हैं:

दो फिंगरप्रिंट अंतर स्पष्ट हैं: रेंडरर sec-ch-ua Client Hints हेडर पूरी तरह छोड़ देता है (वास्तविक Chrome ब्राउज़र हमेशा इन्हें भेजता है), और सभी अनुरोध HTTP/2 या HTTP/3 के बजाय HTTP/1.1 का उपयोग करते हैं। यदि आप बॉट डिटेक्शन नियम बना रहे हैं, तो ये Cloudflare के ब्राउज़र रेंडरर को वास्तविक विज़िटर ट्रैफिक से अलग करने के विश्वसनीय संकेत हैं।

सर्वर लॉग में Cloudflare /crawl अन्य AI बॉट्स की तुलना में कैसा है?

हमने Cloudflare क्रॉल की तुलना उन अन्य बॉट्स से की जो उसी 12-घंटे की विंडो में उसी स्टोर पर आए:

Amazonbot और ChatGPT-User रॉ HTML फेच करते हैं: एक अनुरोध, एक पेज, कोई JavaScript निष्पादन नहीं। AhrefsBot डिस्कवरी के लिए साइटमैप क्रॉल करता है। Cloudflare ब्राउज़र रेंडरर हर पेज पर पूरा Shopify स्टोरफ्रंट निष्पादित करता है, हर स्क्रिप्ट, पिक्सल, और प्रीलोड को ऐसे ट्रिगर करता है जैसे कोई वास्तविक ग्राहक ब्राउज़ कर रहा हो।

Cloudflare /crawl गति और लागत: पूर्ण बेंचमार्क

हमारे द्वारा चलाया गया हर क्रॉल, एक तालिका में। सभी स्टोर गुमनाम, सभी नंबर वास्तविक परीक्षणों से। वॉल क्लॉक टाइम अनुमानित हैं। स्टोर C और D की सफलता दरें हमारी शुरुआती टेस्ट स्क्रिप्ट में सीमित एरर हैंडलिंग से प्रभावित हो सकती हैं।

रेंडरिंग के साथ बनाम बिना Cloudflare /crawl कितना तेज है?

सबसे स्पष्ट तुलना स्टोर B से आती है, जहां हमने ठीक उन्हीं 256 पेजों पर दोनों मोड चलाए:

सभी ग्यारह क्रॉल का पैटर्न सुसंगत है: रेंडरिंग के बिना क्रॉलिंग नाटकीय रूप से तेज है। रेंडरिंग के बिना वॉल क्लॉक टाइम अधिकतर Cloudflare का आंतरिक क्यू और फेच ओवरहेड है। पूर्ण रेंडरिंग उस बेसलाइन के ऊपर प्रति पेज लगभग 5 सेकंड का ब्राउज़र टाइम जोड़ती है।

पूर्ण रेंडर्ड Cloudflare क्रॉल की प्रति पेज लागत कितनी है?

Cloudflare की Browser Rendering प्राइसिंग ब्राउज़र घंटों पर आधारित है, वह समय जो उनका हेडलेस ब्राउज़र सक्रिय रूप से आपके पेज रेंडर करने में खर्च करता है। रेंडरिंग के बिना क्रॉलिंग शून्य ब्राउज़र घंटे उपयोग करती है और बीटा के दौरान मुफ्त है।

Workers Free प्लान: प्रति दिन 10 मिनट का ब्राउज़र टाइम। /crawl endpoint आगे प्रति दिन 5 क्रॉल जॉब तक सीमित है, प्रति क्रॉल अधिकतम 100 पेज के साथ।

Workers Paid प्लान ($5/माह): प्रति माह 10 घंटे का ब्राउज़र टाइम शामिल। इसके बाद, आप प्रति अतिरिक्त ब्राउज़र घंटा $0.09 भुगतान करते हैं। /crawl endpoint पर कोई प्रति-क्रॉल सीमा नहीं। प्रति मिनट 600 API अनुरोध तक।

$0.09/घंटा पर हमारे टेस्ट क्रॉल की वास्तविक लागत यह रही:

प्रति पेज लगभग 5 सेकंड ब्राउज़र टाइम पर, ये सभी लागतें पेड प्लान में शामिल 10 घंटों के अंदर आराम से आती हैं। 3,000-पेज रेंडर्ड क्रॉल आपके 10 शामिल घंटों में से लगभग 4 उपयोग करेगा, यानी आप $5 बेस के अलावा कुछ भी भुगतान करने से पहले प्रति माह दो पूर्ण क्रॉल चला सकते हैं। रेंडरिंग के बिना क्रॉलिंग मुफ्त है और किसी भी प्लान पर इसकी कोई ब्राउज़र टाइम लागत नहीं है।

कब रेंडरिंग छोड़ें बनाम कब Cloudflare /crawl पर पूर्ण रेंडरिंग का उपयोग करें?

निष्कर्ष

अधिकतर सर्वर-रेंडर्ड कंटेंट वाले Shopify स्टोर्स के लिए, रेंडरिंग के बिना क्रॉलिंग आपको शून्य लागत पर कम समय में 90% से अधिक उपयोगी कंटेंट प्रदान करती है।

Shopify स्टोर्स पर Cloudflare /crawl का परीक्षण करके हमने क्या सीखा

5 लाइव Shopify स्टोर्स पर 11 क्रॉल चलाने और पूर्ण सर्वर लॉग का विश्लेषण करने के बाद, ये वे निष्कर्ष हैं जो सबसे अधिक मायने रखते हैं।

90% कंटेंट बिना रेंडरिंग के आ जाता है

मानक सर्वर-रेंडर्ड पेजों वाले Shopify स्टोर्स के लिए, JavaScript रेंडरिंग के बिना क्रॉल करने से 90% से अधिक उपयोगी कंटेंट कैप्चर हो गया। पूर्ण रेंडरिंग से 14% कंटेंट वृद्धि लगभग पूरी तरह से होमपेज और इंडेक्स पेजों पर JavaScript-लोडेड एलिमेंट्स से आई। व्यक्तिगत प्रोडक्ट पेज और ब्लॉग लेख दोनों तरीकों से लगभग समान थे। जब तक आपका स्टोर एक सिंगल-पेज ऐप के रूप में नहीं बना है, आपको शायद पूर्ण रेंडरिंग की आवश्यकता नहीं है।

पूर्ण रेंडरिंग 89 गुना ट्रैफिक मल्टीप्लायर बनाती है

25 पेजों को रेंडर करने से 2,234 सर्वर अनुरोध उत्पन्न हुए। उनमें से केवल 25 वास्तविक पेज कंटेंट थे। शेष 98.9% JavaScript फाइलें (75%), एनालिटिक्स बीकन (6.3%), CSS (4.3%), ट्रैकिंग पिक्सल (3.4%), और चेकआउट प्रीलोड (3.3%) थे। हर रेंडर किए गए पेज ने पूरे Shopify क्लाइंट-साइड स्टैक को ट्रिगर किया, जैसे कि एक वास्तविक ग्राहक ब्राउज़ कर रहा हो।

आपके Shopify एनालिटिक्स संभवतः बढ़ा-चढ़ा कर दिखाए जा रहे हैं

रेंडर किए गए क्रॉल Shopify की पूरी एनालिटिक्स स्टैक फायर करते हैं: monorail बीकन, ट्रैकिंग इवेंट, Shop Pay प्रीलोड, और web-pixel स्क्रिप्ट। हम मानते हैं कि इसका मतलब है कि Shopify Analytics इन्हें वास्तविक विज़िटर सेशन के रूप में गिन रहा है। यदि ऐसा है, तो एक ही रेंडर किया गया क्रॉल आपके सेशन काउंट, पेजव्यू, और कन्वर्शन फनल डेटा को बढ़ा सकता है। हमने Shopify की रिपोर्टिंग में इसकी सीधे पुष्टि नहीं की है, लेकिन सर्वर लॉग वही सभी एनालिटिक्स इवेंट फायर होते दिखाते हैं जो एक वास्तविक ग्राहक के लिए होते।

पूर्ण रेंडरिंग स्टोर रेट लिमिट को बाईपास कर सकती है

स्टोर D ने बिना रेंडरिंग के हर पेज पर 429 एरर लौटाए। उसी स्टोर पर पूर्ण रेंडरिंग पर स्विच करने से 100% सफलता मिली। यदि आपको बिना रेंडरिंग के रेट लिमिट मिलती हैं, तो पूर्ण रेंडरिंग आपका समाधान है।

साइटमैप डिस्कवरी, लिंक डिस्कवरी से अधिक विश्वसनीय है

डिफ़ॉल्ट लिंक-आधारित डिस्कवरी ने स्टोर D पर लगभग कुछ नहीं पाया क्योंकि होमपेज में बहुत कम इंटरनल लिंक थे। साइटमैप-आधारित डिस्कवरी पर स्विच करने से सभी 24 पेज मिल गए। हमेशा साइटमैप डिस्कवरी का उपयोग करें।

क्रॉलर 5 US डेटा सेंटरों से आता है

Cloudflare अपने एज नेटवर्क में रेंडरिंग वर्कलोड वितरित करता है। हमारा क्रॉल Atlanta (38%), Chicago (25%), Miami (23%), Newark (9%), और Washington DC (5%) में 23 अद्वितीय IPs से आया। सभी IPs 104.28.x.x रेंज में आते हैं।

दो फिंगरप्रिंट अंतर इसे बॉट के रूप में पहचानते हैं

रेंडरर sec-ch-ua Client Hints हेडर्स छोड़ देता है (वास्तविक Chrome हमेशा इन्हें भेजता है) और HTTP/2 या HTTP/3 के बजाय HTTP/1.1 का उपयोग करता है। यदि आप बॉट डिटेक्शन नियम बना रहे हैं, तो ये विश्वसनीय संकेत हैं।

रेंडरिंग वास्तव में कम कंटेंट लौटा सकती है

स्टोर E पर, बिना-रेंडर क्रॉल ने रेंडर किए गए क्रॉल की तुलना में प्रति पेज 6.8% अधिक कंटेंट लौटाया। ब्राउज़र समय को ऑप्टिमाइज़ करने के लिए इमेज, फॉन्ट, और स्टाइलशीट को ब्लॉक करने से कुछ JavaScript को डायनामिक एलिमेंट्स भरने से भी रोका गया। स्टैटिक HTML में पहले से सब कुछ था। सर्वर-रेंडर्ड Shopify स्टोर्स के लिए, रेंडरिंग से अधिक कंटेंट कैप्चर होने की गारंटी नहीं है।

रिसोर्स ब्लॉकिंग अटके हुए क्रॉल को रोकती है

रिसोर्स ब्लॉकिंग के बिना, स्टोर E पर रेंडर किया गया क्रॉल 100 में से 99 पेजों पर अटक गया और कभी पूरा नहीं हुआ। इमेज, मीडिया, फॉन्ट, और स्टाइलशीट के लिए domcontentloaded वेट कंडीशन के साथ ब्लॉकिंग सक्षम करने से सभी 100 पेज पूरे हुए और ब्राउज़र समय 27% कम हो गया। यदि आपके रेंडर किए गए क्रॉल पूरा होने से पहले रुक जाते हैं, तो रिसोर्स ब्लॉकिंग समाधान है।

robots.txt Crawl-Delay वॉल क्लॉक टाइम बढ़ाता है

स्टोर E का robots.txt 10-सेकंड crawl-delay निर्दिष्ट करता है। हमारे बिना-रेंडर पोलिंग डेटा में, यह कई-मिनट के ठहराव के रूप में दिखा जहां पेज काउंट रुक गया और फिर से शुरू हुआ। Cloudflare क्रॉलर crawl-delay निर्देशों का सम्मान करता है, इसलिए आक्रामक विलंब वाली साइटों का वॉल क्लॉक टाइम पेज काउंट से अपेक्षित समय से काफी अधिक होगा।

लागत कम है लेकिन Free प्लान की सीमाएं हैं

256 पेज रेंडर करने की लागत $0.09 प्रति ब्राउज़र घंटे पर लगभग $0.03 थी। 24 पेज रेंडर करने की लागत लगभग $0.002 थी। Workers Free प्लान ब्राउज़र समय को प्रति दिन 10 मिनट तक सीमित करता है, अधिकतम 5 क्रॉल जॉब और प्रति क्रॉल 100 पेज। Workers Paid प्लान ($5/माह) में प्रति माह 10 घंटे ब्राउज़र समय शामिल है, बिना किसी प्रति-क्रॉल सीमा के। 3,000-पेज रेंडर क्रॉल उन 10 शामिल घंटों में से लगभग 4 का उपयोग करेगा, इसलिए अधिकांश स्टोर बिना अतिरिक्त शुल्क के पेड प्लान पर आराम से फिट हो जाते हैं। बिना रेंडरिंग के क्रॉल करने में शून्य ब्राउज़र समय लगता है और बीटा के दौरान किसी भी प्लान पर मुफ्त है।

फायदे

गति

पेज लगभग तुरंत फेच होते हैं, बजाय autothrottle के साथ कई घंटों की Scrapy क्रॉल के। कोई क्यूइंग नहीं, कोई पॉलिटनेस डिले नहीं, हज़ारों अनुरोधों के माध्यम से सम्मानजनक गति से काम करने के लिए अपने स्पाइडर की प्रतीक्षा नहीं।

Markdown आउटपुट

Endpoint हर पेज के लिए पूर्व-परिवर्तित HTML-to-Markdown लौटाता है। यह LLM इंजेशन, RAG पाइपलाइन, और कंटेंट विश्लेषण के लिए बिना किसी पोस्ट-प्रोसेसिंग के सीधे उपयोगी है। आप पूरी एक्सट्रैक्शन लेयर छोड़ देते हैं और सीधे क्लीन टेक्स्ट पर पहुंच जाते हैं। वेबसाइट कंटेंट के ऊपर AI एप्लिकेशन बनाने वाली टीमों के लिए, यह पाइपलाइन से एक कदम हटा देता है।

Render मोड विकल्प

render: true सेट करने से JavaScript निष्पादित होता है और स्वचालित रूप से Open Graph मेटाडेटा (og:title, og:description, og:image, og:site_name) एक्सट्रैक्ट होता है। JavaScript-भारी साइटों के लिए जहां कंटेंट क्लाइंट-साइड रेंडर होता है, यह वास्तविक पेज देखने और एक खाली शेल देखने के बीच का अंतर है।

कोई प्रॉक्सी या रेट-लिमिट सिरदर्द नहीं

Cloudflare अपने इन्फ्रास्ट्रक्चर पर एंटी-बॉट उपायों और रेट लिमिटिंग को संभालता है। आपको प्रॉक्सी पूल प्रबंधित करने, user agent रोटेट करने, या CAPTCHAs से निपटने की आवश्यकता नहीं है। एक API कॉल।

इंक्रीमेंटल क्रॉलिंग

modifiedSince और maxAge पैरामीटर आपको उन पेजों को छोड़ने देते हैं जो बदले नहीं हैं या हाल ही में फेच किए गए थे। आवर्ती क्रॉल के लिए जहां आप कंटेंट परिवर्तनों की निगरानी कर रहे हैं, यह केवल वास्तव में नए या अपडेट किए गए पेजों को प्रोसेस करके समय और लागत दोनों बचाता है।

सरलता

एक API कॉल। JSON रिस्पॉन्स। कोई स्पाइडर कोड नहीं, कोई मिडलवेयर नहीं, कोई आइटम पाइपलाइन नहीं, कोई सेटिंग्स फाइल नहीं।

डिफ़ॉल्ट रूप से अच्छा व्यवहार करने वाला बॉट

क्रॉलर एक साइन्ड-एजेंट है जो robots.txt, crawl-delay, और Cloudflare के AI Crawl Control का सम्मान करता है। यह स्वयं को CloudflareBrowserRenderingCrawler/1.0 के रूप में पहचानता है और बॉट प्रोटेक्शन या CAPTCHAs को बाईपास नहीं कर सकता। आपको स्वयं लॉजिक बनाए बिना नैतिक क्रॉलिंग अनुपालन मिलता है।

Cloudflare Crawl Endpoint क्या समर्थित नहीं करता

Cloudflare /crawl पूर्ण क्रॉल पाइपलाइन से कैसे अलग है?

नीचे दी गई तालिका स्पष्ट रूप से दिखाती है कि Cloudflare के /crawl endpoint में कौन-सी क्षमताएं मौजूद हैं बनाम एक प्रोडक्शन Scrapy पाइपलाइन में। यह Shopify स्टोर्स के विरुद्ध हमारे वास्तविक परीक्षणों पर आधारित है।

Cloudflare /crawl कौन-सा स्ट्रक्चर्ड डेटा एक्सट्रैक्ट करता है?

render: false के साथ, कुछ नहीं। कोई JSON-LD नहीं, कोई Microdata नहीं, कोई OpenGraph पार्सिंग नहीं।

render: true के साथ, केवल बेसिक OG टैग (og:title, og:description, og:image, og:site_name)। JSON-LD और schema.org मार्कअप पार्स, एक्सट्रैक्ट, या वैलिडेट नहीं किए जाते।

तुलना के लिए, हमारी Scrapy पाइपलाइन हर URL के लिए schemas_found, issues (गायब contactPoint, address, आदि), top_level_schemas, और nested_schemas उत्पन्न करती है। आप देख सकते हैं कि किन पेजों में Product स्कीमा है, किनमें Organization मार्कअप गायब है, और किनमें वैलिडेशन एरर हैं जो AI सिस्टम को कंटेंट गलत तरीके से पढ़ने का कारण बनेंगे।

Cloudflare /crawl कौन-से HTTP स्टेटस कोड लौटाता है?

केवल 200 रिस्पॉन्स। उसी साइट के हमारे Scrapy क्रॉल ने 2,547 404 एरर, साथ ही 403 रिस्पॉन्स और कनेक्शन एरर कैप्चर किए। 404 डिटेक्शन घोस्ट पेज विश्लेषण, टूटी लिंक सुधार, और रीडायरेक्ट मैपिंग के लिए महत्वपूर्ण है। इसके बिना, आप उन पेजों को मिस कर रहे हैं जो सक्रिय रूप से लिंक इक्विटी लीक कर रहे हैं और AI क्रॉलर्स को भ्रमित कर रहे हैं।

Cloudflare /crawl कितने URLs प्रोसेस कर सकता है?

प्रति जॉब 100,000 तक। यह अधिकांश साइटों को कवर करता है, लेकिन लाखों प्रोडक्ट पेज, वैरिएंट URLs, और फिल्टर्ड कलेक्शन पेजों वाले बड़े ई-कॉमर्स कैटलॉग इस सीमा को पार कर जाएंगे। Scrapy में कोई अंतर्निहित URL सीमा नहीं है।

क्या Cloudflare /crawl में URL रिज़ॉल्यूशन बग है?

हमने एक ही प्रोडक्ट पेज पर 908 लिंक में से 233 में टूटे पाथ पाए। मार्कडाउन कन्वर्टर रिलेटिव URLs को पेज URL के विरुद्ध गलत तरीके से रिज़ॉल्व करता है, जिससे /products/slug//www.example.com/... जैसे डबल-पाथ URLs बनते हैं। यह Cloudflare के कन्वर्टर में एक पुष्टिकृत बग है जो किसी भी डाउनस्ट्रीम लिंक विश्लेषण को प्रभावित करता है।

Cloudflare /crawl Markdown आउटपुट में कितना बॉयलरप्लेट है?

औसत पेज ने 158 KB मार्कडाउन लौटाया। लगभग 90% दोहराया गया टेम्पलेट कंटेंट है: हर एक रिकॉर्ड पर पूर्ण नेविगेशन, मेगा मेनू, और फुटर। कंटेंट विश्लेषण के लिए इसका मतलब है भारी डीडुप्लीकेशन काम, और LLM टोकन उपयोग के लिए लागत तेज़ी से बढ़ती है। वास्तविक पेज कंटेंट को अलग करने के लिए आपको मार्कडाउन के ऊपर अपना खुद का कंटेंट एक्सट्रैक्शन लॉजिक चाहिए।

Cloudflare /crawl क्या वर्गीकृत नहीं करता?

कोई कंटेंट टाइप टैगिंग नहीं है। प्रोडक्ट पेज, कलेक्शन पेज, ब्लॉग पोस्ट, और होमपेज सभी बिना किसी भेद के रिकॉर्ड के रूप में वापस आते हैं। Scrapy हर URL को टाइप के अनुसार वर्गीकृत करता है, जो पेज श्रेणी के अनुसार क्रॉल कवरेज समझने और यह पहचानने के लिए आवश्यक है कि AI बॉट किन कंटेंट टाइप को प्राथमिकता देते हैं।

Cloudflare /crawl में कौन-सी फाइनलाइज़ेशन सुविधाएं गायब हैं?

कोई घोस्ट पेज स्क्रीनशॉट नहीं। कोई JavaScript रेंडरिंग तुलना नहीं (बॉट क्या देखता है बनाम ब्राउज़र क्या देखता है)। कोई robots.txt AI बॉट विश्लेषण नहीं। कोई क्रॉल क्वालिटी रिपोर्ट नहीं। कोई क्लाइंट मैनिफेस्ट नहीं। कोई CDN सिंक नहीं। Cloudflare डेटा केवल रॉ कंटेंट है। रिपोर्टिंग और विश्लेषण पाइपलाइन का हर हिस्सा अलग से बनाना होगा।

बड़ी साइटों के लिए Cloudflare /crawl की लागत कितनी है?

हमारे परीक्षणों में, render: true ने प्रति पेज लगभग 5 सेकंड का ब्राउज़र निष्पादन समय औसत किया। 256-पेज क्रॉल ने 1,338 ब्राउज़र सेकंड (22 मिनट) उपयोग किए और $0.09 प्रति ब्राउज़र घंटे पर लगभग $0.03 की लागत आई। 24-पेज क्रॉल ने 58 ब्राउज़र सेकंड उपयोग किए और लगभग $0.002 की लागत आई। 3,000-पेज कैटलॉग के लिए अनुमान: लगभग 4 घंटे ब्राउज़र समय। Workers Free प्लान प्रति दिन 10 मिनट ब्राउज़र समय, प्रति दिन 5 क्रॉल जॉब, और प्रति क्रॉल 100 पेज तक सीमित है। Workers Paid प्लान ($5/माह) में प्रति माह 10 घंटे ब्राउज़र समय शामिल है, बिना किसी प्रति-क्रॉल सीमा के, इसलिए 3,000-पेज क्रॉल उन 10 शामिल घंटों में से लगभग 4 का उपयोग करेगा। render: false शून्य ब्राउज़र समय उपयोग करता है और बीटा के दौरान किसी भी प्लान पर मुफ्त है।

निष्कर्ष

Cloudflare का crawl endpoint इन कामों के लिए बढ़िया है:

• त्वरित कंटेंट स्नैपशॉट जब आपको पेज टेक्स्ट तेज़ी से चाहिए
• LLM-तैयार markdown RAG पाइपलाइन और कंटेंट इंजेशन के लिए
• एड-हॉक पेज जांच जहां आपको सटीक URLs पता हैं जो आपको चाहिए
• तेज़ साइट-वाइड कंटेंट पुल जब आपको स्पाइडर बनाए बिना markdown टेक्स्ट चाहिए

यह पूर्ण क्रॉल पाइपलाइन की जगह नहीं ले सकता क्योंकि पाइपलाइन का मूल्य इनमें है:

• पूर्ण क्रॉल ग्राफ लिंक टोपोलॉजी, ऑर्फन डिटेक्शन, और 404 कवरेज के साथ
• स्ट्रक्चर्ड डेटा एक्सट्रैक्शन और वैलिडेशन (JSON-LD, Microdata, OpenGraph)
• कंटेंट वर्गीकरण पेज टाइप के अनुसार
• संपूर्ण फाइनलाइज़ेशन पाइपलाइन जिसमें घोस्ट पेज विश्लेषण, JavaScript रेंडरिंग तुलना, स्कीमा रिपोर्ट, और LLM रेडीनेस स्कोरिंग शामिल हैं

सर्वोत्तम हाइब्रिड दृष्टिकोण

Cloudflare को एक पूरक डेटा स्रोत के रूप में उपयोग करें। पूर्ण क्रॉल द्वारा आपके URLs की पहचान करने के बाद, Cloudflare के markdown आउटपुट का उपयोग LLM रेडीनेस स्कोरिंग या कंटेंट क्वालिटी विश्लेषण को फीड करने के लिए करें, जहां आपको स्ट्रक्चर्ड मेटाडेटा के बजाय वास्तविक पेज टेक्स्ट की आवश्यकता है। क्रॉल पाइपलाइन खोजती और वर्गीकृत करती है। Cloudflare endpoint महत्वपूर्ण पेजों के लिए क्लीन टेक्स्ट प्रदान करता है।

अक्सर पूछे जाने वाले प्रश्न