राजस्व वाली वेबसाइट
स्टोर, बुकिंग वेबसाइट, सदस्यता प्रोडक्ट या संभावित ग्राहक लाने वाली वेबसाइट की नियमित बाहरी उपलब्धता जाँच रखें।
चेतावनियों के साथ वेबसाइट अपटाइम मॉनिटरिंग
प्रोजेक्ट का सार्वजनिक URL देखें, 30-दिन की उपलब्धता और प्रतिक्रिया पढ़ें और विफल HTTP जाँच की पड़ताल करें। SEO काम के साथ घटना इतिहास और योग्य ईमेल सूचनाएँ रखें।
वेबसाइट अपटाइम जाँच सेट करें
Screpy प्रोजेक्ट के सहेजे सार्वजनिक URL की नियमित जाँच चालू करें। अंतराल चुनने से पहले आगंतुकों के लिए उपयोगी लक्ष्य तय करें।
- हर प्रोजेक्ट एक HTTP या HTTPS URL देखता है, अलग-अलग एंडपॉइंट की सूची नहीं।
- प्रोजेक्ट सेटिंग में जाँच चालू करना, 1–60 मिनट का अंतराल और वैकल्पिक सूचना ईमेल तय करना संभव है।
- निर्धारित जाँच के लिए योग्य सक्रिय सशुल्क प्लान चाहिए; डिफ़ॉल्ट अंतराल अलग होते हैं।
- प्रोजेक्ट टीम की निष्क्रियता से अंतराल बढ़ते हैं; 30 निष्क्रिय दिनों के बाद जाँच रुकती है।
- अंतिम जाँच का समय ताज़गी बताता है; तय अंतराल सटीक निष्पादन समय की गारंटी नहीं है।
example.com60 s
अपटाइम प्रतिशत समझें
देखें कि पिछले 30 दिनों में कितनी जाँच सफल रही। प्रतिशत के साथ जाँच की संख्या और अंतिम समय पढ़ें।
- अपटाइम सफल जाँच को सभी दर्ज जाँच से भाग देकर 100 से गुणा करता है।
- वर्तमान स्थिति उस अवधि की अंतिम पूरी जाँच से आती है।
- जाँच दर्ज न हो तो डेटा अनुपलब्ध है, 100% अपटाइम नहीं।
- प्रतिशत नमूनों पर आधारित है; सीधे बंद रहने के मिनट या समय-भारित SLA में नहीं बदला जा सकता।
अपटाइम
93.8%503200
वेबसाइट प्रतिक्रिया समय देखें
ग्राफ़ में धीमी प्रतिक्रियाएँ और बार-बार विफलता पहचानें। पहुँच योग्य URL भी धीमा जवाब दे सकता है।
- ग्राफ़ 30 दिनों की अधिकतम 160 हाल की जाँच उपयोग करता है; दिखने वाला हिस्सा स्क्रीन की चौड़ाई पर निर्भर है।
- रुझान रेखा पाँच जाँच का औसत है; औसत प्रतिक्रिया पूरे 30 दिनों की सफल जाँच उपयोग करती है।
- समय HTTP विलंब मापता है, पूरा पेज लोड, Core Web Vitals या आगंतुक प्रक्रिया नहीं।
प्रतिक्रिया समय
240 msHTTP स्थिति जाँच देखें
आखिरी आठ जाँच की स्थिति, समय, HTTP कोड और प्रतिक्रिया देखें। सार्वजनिक URL के अपेक्षित व्यवहार से तुलना करें।
- HTTP 200–399 उपलब्ध माना जाता है; अन्य HTTP जवाब अनुपलब्ध। समय समाप्ति और त्रुटि अलग दर्ज होती हैं।
- रीडायरेक्ट का अनुसरण नहीं होता; 3xx परिणाम गंतव्य चलने की पुष्टि नहीं करता।
- जाँच HEAD उपयोग करती है, 405 या 501 पर GET से दोबारा कोशिश करती है; कनेक्शन विफलता में HTTP कोड नहीं भी हो सकता।
- उपलब्ध परिणाम सामग्री, फ़ॉर्म या खरीद सत्यापित नहीं करता; HTTP 200 त्रुटि पेज भी उपलब्ध गिना जा सकता है।
HTTP स्थिति
200GET /HTTP/2 200वेबसाइट बंद होने की घटनाएँ देखें
पहली विफल जाँच से बाद की सफल जाँच तक घटना देखें। बंद होने के कारण की जाँच अलग करें।
- पहली विफलता घटना खोलती है, अगली उसे अपडेट करती हैं और पहली सफल जाँच हल करती है।
- डैशबोर्ड सभी समय की खुली और हल घटनाओं की संख्या तथा अंतिम पाँच का स्थिति, शुरुआत और विवरण दिखाता है।
- समय जाँच दर्शाता है, दो नमूनों के बीच की सटीक शुरुआत नहीं; छोटे व्यवधान छूट सकते हैं।
अवधि
12 min503200
बंद होने के ईमेल पाएँ
योग्य सूचनाएँ प्रोजेक्ट सदस्यों और वैकल्पिक अतिरिक्त पते पर भेजें। ईमेल के योग्य होने से पहले घटना दर्ज होती है।
- उसी घटना की बाद की विफलता 404, 500 या 503 जैसे समर्थित HTTP कोड पर ईमेल भेज सकती है।
- समय समाप्ति, कनेक्शन त्रुटि और असमर्थित कोड दर्ज होते हैं, लेकिन ये ईमेल नहीं भेजते।
- हर प्रोजेक्ट के लिए 24 घंटे में एक बंद होने का और अलग एक बहाली का ईमेल सीमा है।
- बहाली ईमेल के लिए पहले सूचित, दबाई न गई घटना चाहिए; दर्ज अवधि आगंतुकों की सटीक बंद अवधि का प्रमाण नहीं।
!
प्रोजेक्टexample.com
समीक्षाSEO MCP से अपटाइम पढ़ें
जुड़े AI सहायक से पहुँच वाले प्रोजेक्ट के सहेजे परिणाम समझाने को कहें। दर्ज डेटा और नई जाँच अलग करने के लिए समय देखें।
- SEO MCP 30-दिन की स्थिति, प्रतिशत, सफल जाँच का औसत और अंतिम जाँच लौटाता है।
- अधिकतम 160 हाल के रिकॉर्ड में स्थिति, प्रतिक्रिया समय और तारीख हैं; HTTP कोड और घटनाएँ नहीं।
- केवल पढ़ने वाला अनुरोध नई जाँच नहीं चलाता, कारण नहीं पहचानता या समस्या ठीक नहीं करता; गायब परिणाम अनुपलब्ध रहते हैं।
GET
/projectsJSON{
"data": [
{ "domain": "example.com" }
]
}SEO रिपोर्ट में अपटाइम जोड़ें
ग्राहक या टीम की सहेजी रिपोर्ट में उपलब्धता के प्रमाण दें। रिपोर्ट की झलक लाइव निगरानी से अलग प्रश्न का उत्तर देती है।
- विजेट में 30-दिन के आँकड़े, हाल की जाँच और रिपोर्ट अवधि से मेल खाने वाली घटनाएँ हैं।
- घटना संख्या डैशबोर्ड के सभी समय के कुल से अलग हो सकती है; हल घटनाओं में दर्ज अवधि हो सकती है।
- रिपोर्ट बनाते समय सहेजा डेटा लेती है और लाइव चेतावनी नहीं भेजती।
अनुभाग
aACMEरिपोर्टPDF
साइट की स्थिति का स्कोर87/100
स्थान+24
अपटाइम मॉनिटरिंग पर बात करें। SEO MCP के साथ।
SEO MCP से सहेजा 30-दिन अपटाइम और हाल के स्थिति/प्रतिक्रिया रिकॉर्ड पढ़ें। अंतिम स्थिति को वर्तमान मानने से पहले समय देखें; घटनाएँ और HTTP कोड नहीं मिलते।
- Screpy: नमस्ते! example.com के लिए अपटाइम मॉनिटरिंग देखें। आप क्या जानना चाहते हैं?
- आप: example.com का सहेजा अपटाइम और अंतिम जाँच समय समझाओ।
- Screpy: उदाहरण सहेजा परिणाम: 10:18 UTC की जाँच उपलब्ध थी और 30 दिनों में 99.95% जाँच सफल। प्रतिशत नमूनों पर आधारित है, अभी पहुँच का प्रमाण नहीं। पड़ताल में डैशबोर्ड घटनाएँ और होस्टिंग लॉग देखें। सहेजा अपटाइम: अंतिम जाँच: 10:18 UTC. 30-दिन अपटाइम: 99.95%.
- आप: इसे एक छोटी कार्ययोजना में बदलो।
- Screpy: मैं निष्कर्ष और सुझाव अलग रखूँगा। प्रमाण देखें, एक बदलाव चुनें और बाद में नतीजे जाँचें। आपके अगले कदम: समीक्षा: हर निष्कर्ष का स्रोत और तारीख जाँचें।. निर्णय: पहला बदलाव चुनें।. सत्यापन: बदलाव के बाद नतीजों की तुलना करें।.
- आप: क्या प्रमाण को सरल भाषा में समझा सकते हो?
- Screpy: हाँ। किसी समर्थित परिणाम के बारे में पूछें। मैं बताऊँगा कि वह क्या दिखाता है, कहाँ से आया है और क्या अनिश्चित है। अनुपलब्ध डेटा अनुपलब्ध ही रहता है; सुझाव अपने-आप किए गए सुधार नहीं हैं।
उपयोगी अपटाइम मॉनिटरिंग प्रक्रिया बनाएँ।
सार्वजनिक लक्ष्य चुनें, निगरानी चालू करें और जिम्मेदार ईमेल तय करें। विफलता पर वर्तमान रिकॉर्ड जाँचें और बाद की सफल जाँच सुनिश्चित करें।
-
सार्वजनिक प्रोजेक्ट वेबसाइट URL उपयोग करें
प्रोजेक्ट का सही सार्वजनिक URL उपयोग करें, लॉगिन आवश्यक रास्ता नहीं। रीडायरेक्ट का अनुसरण नहीं होता, इसलिए गंतव्य अलग जाँचें।
-
जाँच चालू करें और अंतराल कॉन्फ़िगर करें
सेटिंग में निगरानी चालू करें, अंतराल और वैकल्पिक ईमेल सहेजें; योग्य सशुल्क पहुँच और हाल की जाँच पुष्टि करें।
-
आखिरी विफल जाँच की पड़ताल करें
स्थिति, अंतिम जाँच, HTTP परिणाम और घटना विवरण पढ़ें। गंभीर विफलता अभी जाँचें; 30-दिन प्रतिशत संदर्भ देता है, इंतज़ार का कारण नहीं।
-
जाँच करें और बहाली की पुष्टि करें
विफलता को तैनाती, DNS, TLS, होस्टिंग और ऐप लॉग से मिलाएँ। बाद की सफल जाँच पुष्टि करें; घटना हल होना हर आगंतुक रास्ता सत्यापित नहीं करता।
वास्तविक नुकसान वाले डाउनटाइम की वेबसाइट को प्राथमिकता दें।
उन प्रोजेक्ट की नियमित जाँच करें जहाँ उपलब्धता बिक्री, संभावित ग्राहकों, कैंपेन, ग्राहक पहुँच या सर्च क्रॉलर की सार्वजनिक कंटेंट प्राप्ति प्रभावित करती है।
ऑर्गेनिक सर्च वेबसाइट
कंटेंट गुणवत्ता या रैंकिंग काम के उपयोगी होने से पहले उस सार्वजनिक वेबसाइट पर नज़र रखें जहाँ सर्च क्रॉलर व ऑर्गेनिक विज़िटर को पहुँचना है।
लॉन्च और कैंपेन वेबसाइट
लॉन्च, माइग्रेशन, रीडिज़ाइन और सक्रिय कैंपेन के दौरान प्रोजेक्ट वेबसाइट ट्रैक करें, जब उपलब्धता समस्या से अधिक तत्काल नुकसान होता है।
कई प्रोजेक्ट का पोर्टफ़ोलियो
हर उपलब्ध Screpy प्रोजेक्ट का अपटाइम अलग देखें, ताकि एजेंसियाँ और इन-हाउस टीमें क्लाइंट या ब्रांड वेबसाइट एक कार्यप्रवाह में रख सकें।
अपटाइम नतीजे का दायरा समझें।
Screpy कॉन्फ़िगर प्रोजेक्ट वेबसाइट के बाहरी HTTP प्रमाण और घटना इतिहास देता है। सवाल इससे बाहर हो तो इन्फ़्रास्ट्रक्चर, लॉग, लेन-देन परीक्षण और सर्च डेटा उपयोग करें।
एक प्रोजेक्ट वेबसाइट लक्ष्य
Uptime Monitoring Screpy प्रोजेक्ट का कॉन्फ़िगर सार्वजनिक वेबसाइट URL जाँचता है। यह स्वतंत्र एंडपॉइंट मॉनिटर की सामान्य सूची नहीं है।
बाहरी जाँच, इन्फ़्रास्ट्रक्चर मापन नहीं
नतीजा बताता है कि सार्वजनिक लक्ष्य ने जवाब दिया या नहीं। यह CPU, मेमोरी, कंटेनर, डेटाबेस, निजी नेटवर्क या सर्वर लॉग नहीं जाँचता।
घटना के प्रमाण, मूल कारण का सबूत नहीं
HTTP स्थिति, समय और घटना के टाइमस्टैम्प जाँच सीमित करने में मदद करते हैं, लेकिन DNS, TLS, होस्टिंग, डिप्लॉयमेंट, फ़ायरवॉल या ऐप कोड में से कारण साबित नहीं कर सकते।
उपलब्धता SEO की गारंटी नहीं है
विज़िटर और क्रॉलिंग के लिए सार्वजनिक पेज का काम करना ज़रूरी है, लेकिन अकेला ऊँचा अपटाइम प्रतिशत इंडेक्सिंग, रैंकिंग, ट्रैफ़िक, राजस्व या कन्वर्ज़न की गारंटी नहीं देता।
विफलता के अनुरूप वेबसाइट स्थिति का कार्यप्रवाह चुनें।
समय के साथ पहुँच मॉनिटर करें, विफल URL या क्रॉल पैटर्न दोहराएँ तो व्यापक वेबसाइट ऑडिट करें या उपलब्धता स्थिर होने पर पेज परफ़ॉर्मेंस जाँचें।
सार्वजनिक प्रोजेक्ट URL का जाँच-आधारित 30-दिन अपटाइम, प्रतिक्रिया, HTTP परिणाम और घटनाएँ देखें।
उपलब्धता समस्या के आसपास बार-बार विफल पेज, रीडायरेक्ट समस्याएँ, टूटे लक्ष्य और तकनीकी पैटर्न खोजने के लिए व्यापक वेबसाइट क्रॉल करें।
वेबसाइट पहुँच योग्य हो लेकिन लोडिंग या प्रतिक्रिया की जाँच चाहिए तो नियमित लैब परफ़ॉर्मेंस जाँच चलाएँ।
Screpy दस्तावेज़
वेबसाइट अपटाइम मॉनिटर करना सीखें
सार्वजनिक लक्ष्य चुनना, निगरानी और सूचनाएँ सेट करना, प्रतिक्रिया समझना और घटनाएँ जाँचना सीखें।
वेबसाइट अपटाइम मॉनिटरिंग के आम सवाल
नमूनों, निष्क्रिय प्रोजेक्ट, रीडायरेक्ट, गायब जाँच, ईमेल की शर्तों और पेज प्रदर्शन के उत्तर।
Screpy किसे चालू या बंद मानता है?
HTTP 200–399 उपलब्ध, अन्य HTTP जवाब अनुपलब्ध; समय समाप्ति और त्रुटि अलग स्थिति हैं। रीडायरेक्ट नहीं चलते और सामग्री सत्यापित नहीं होती। रीडायरेक्ट या HTTP 200 त्रुटि पेज सही पेज चलने के बिना उपलब्ध हो सकता है।
डाउनटाइम घटना और बहाली कैसे काम करते हैं?
पहली विफलता घटना खोलती है, अगली खुला रखती हैं और सफल जाँच हल करती है। डैशबोर्ड स्थिति, शुरुआत और विवरण दिखाता है; योग्य बहाली ईमेल में दर्ज अवधि है। नमूने सटीक शुरुआत या हर छोटा व्यवधान नहीं पकड़ते।
Screpy वेबसाइट अपटाइम कितनी बार जाँचता है?
सेटिंग 1–60 मिनट स्वीकार करती है; सशुल्क पहुँच चाहिए। टीम गतिविधि के एक दिन तक वही अंतराल, उसके बाद कम से कम 10 मिनट और सात दिन बाद कम से कम 60 मिनट है। 30 निष्क्रिय दिन बाद निर्धारित जाँच रुकती है। वास्तविक अंतिम समय देखें।
क्या अपटाइम मॉनिटरिंग सर्वर या लेन-देन मॉनिटरिंग की जगह लेती है?
नहीं। Screpy एक सार्वजनिक HTTP(S) लक्ष्य जाँचता है। निजी ढाँचा, लॉगिन या खरीद, सामग्री, भौगोलिक उपलब्धता या कारण नहीं जाँचता। इनके लिए लॉग और विशेष जाँच उपयोग करें।
Screpy Uptime Monitoring क्या मापता है?
Screpy एक सार्वजनिक URL की स्थिति, उपलब्ध HTTP कोड, प्रतिक्रिया और समय दर्ज करता है। डैशबोर्ड प्रतिशत और औसत में 30-दिन जाँच उपयोग करता है, आठ हाल की जाँच दिखाता है और अलग सभी समय की संख्या व अंतिम पाँच घटनाएँ देता है।
क्या Screpy डाउनटाइम चेतावनियाँ भेजता है?
खुली घटना में बाद की विफलता 404, 410, 500, 501, 502, 503, 504, 505, 507, 508, 525 या 526 पर ईमेल भेज सकती है। सदस्य और वैकल्पिक अलग पता योग्य सूचना पाते हैं। बंद होने और बहाली की अलग सीमा प्रति प्रोजेक्ट प्रति 24 घंटे एक ईमेल है। दबाई घटना बाद में फिर नहीं भेजी जाती; बहाली के लिए पहले न दबाई गई बंद होने की सूचना चाहिए। समय समाप्ति, बिना कोड की त्रुटि और अन्य कोड योग्य नहीं।
क्या Uptime Monitoring रिस्पॉन्स समय का इतिहास दिखाता है?
हाँ। ग्राफ़ 30 दिनों की अधिकतम 160 हाल की प्रतिक्रियाएँ लोड करता है; छोटे स्क्रीन पर कम दिखती हैं। पाँच-जाँच रुझान 30-दिन की सफल जाँच के औसत से अलग है। HTTP प्रतिक्रिया पेज रेंडरिंग या सहभागिता नहीं मापती।
क्या वेबसाइट डाउनटाइम क्रॉलिंग या इंडेक्सिंग प्रभावित कर सकता है?
लगातार सर्वर त्रुटि क्रॉल धीमा कर सकती है और सामग्री लेना रोक सकती है। उपलब्ध परिणाम Googlebot पहुँच, रीडायरेक्ट गंतव्य, इंडेक्सिंग या रैंकिंग का प्रमाण नहीं। क्रॉल और खोज डेटा से भी URL जाँचें।
SEO में दमदार। जेब पर हल्का।
वाकई किफ़ायती कीमत पर SEO टूल्स का व्यापक सेट।
- तकनीकी ऑडिट, रैंक ट्रैकिंग और AI में विज़िबिलिटी
- कीवर्ड रिसर्च, बैकलिंक विश्लेषण और अपटाइम मॉनिटरिंग
- एक वर्कस्पेस। लचीले प्लान। कम खर्च।
आपकी जेब में बचे ज़्यादा पैसे