महत्वपूर्ण यात्राओं से शुरू करें, न कि एक विशाल स्कैन से
प्रत्येक के लिए पाँच से दस URL चुनें और अपेक्षित परिणाम परिभाषित करें: एक पुष्टि पृष्ठ, रसीद, CRM रिकॉर्ड, या प्रदाता हैंडऑफ। सार्वजनिक पृष्ठ और वे क्रियाएँ शामिल करें जो राजस्व, विश्वास, सहायता मांग, या कानूनी दायित्व उत्पन्न करती हैं। एक साइन-आउट विंडो और फोन में विज़िटर के रूप में परीक्षण करें।
यदि किसी तृतीय पक्ष के पास कोई महत्वपूर्ण चरण है, तो हैंडऑफ और समर्थन संपर्क को मैप करें। आप अपने संक्रमण का परीक्षण कर सकते हैं, पर उस प्रदाता को प्रमाणित नहीं कर सकते। निष्कर्षों को ब्लॉकर, महत्वपूर्ण गिरावट, या सुधार के रूप में वर्गीकृत करें ताकि सजावटी कार्य किसी टूटे हुए जर्नी को छिपा न दें।
वे रूट कवर करें जो राजस्व, विश्वास, सहायता मांग, या कानूनी दायित्व उत्पन्न करते हैं।
हर महत्वपूर्ण निष्कर्ष के लिए नामांकित मालिक और लक्ष्य तिथि आवश्यक है।
दिखावट के साथ-साथ पहुँचयोग्य उपयोग की जाँच करें
पहुँचयोग्यता का मतलब है कि लोग विभिन्न इनपुट विधियों और सहायक तकनीक के साथ साइट को समझ और संचालित कर सकें। चुने हुए पृष्ठों पर नेविगेशन, मेनू, कंट्रोल और फॉर्म के लिए Tab से गुजरें। दृश्य कीबोर्ड फोकस, महत्वपूर्ण कंट्रोल का माउस-फ्री संचालन, और मुख्य सामग्री तक पहुँच का रास्ता जांचें। W3C के Easy Checks कीबोर्ड फोकस और skip link जैसी चीज़ों को प्रथम समीक्षा के उपयोगी आइटम के रूप में पहचानता है।
प्रासंगिक इमेज टेक्स्ट, पेज शीर्षक, हेडिंग, कंट्रास्ट, ज़ूम व्यवहार, जहाँ आवश्यक हो मीडिया विकल्प, फॉर्म लेबल, आवश्यक फ़ील्ड और समझने योग्य त्रुटियाँ निरीक्षण करें। एक गैर-संवेदनशील परीक्षण सबमिशन भेजें। यह अनुपालन ऑडिट नहीं है: W3C चेतावनी देता है कि पृष्ठ त्वरित जाँच पास कर सकते हैं जबकि अभी भी महत्वपूर्ण अवरोध मौजूद हो सकते हैं। उच्च जोखिम वाले काम, री-डिज़ाइन, या ज्ञात समस्याओं के लिए योग्य मूल्यांकन का उपयोग करें।
लेबल, निर्देश, त्रुटियाँ, और पुष्टि तक वास्तविक पथ का परीक्षण करें।
वैकल्पिक टेक्स्ट को छवि के उद्देश्य को संप्रेषित करना चाहिए; हेडिंग पृष्ठ का आयोजन करें।
रैंक वादा किए बिना खोजनेयोग्यता की समीक्षा करें
SEO खोज इंजनों को सामग्री समझने में मदद करता है और लोगों को यह निर्णय लेने में मदद करता है कि खोज से साइट पर जाना है या नहीं। प्रत्येक प्राथमिक पृष्ठ के लिए, एक नवागन्तुक के रूप में शीर्षक, मुख्य हेडिंग, खुलने वाली प्रति, URL, और आंतरिक लिंक पढ़ें। वे उद्देश्य स्पष्ट करना चाहिए और उपयोगी अगले कदम की ओर ले जाना चाहिए। Google वर्णनात्मक URL, उपयोगी सामग्री, और वर्णनात्मक लिंक टेक्स्ट की सलाह देता है।
यदि आप Google Search Console का उपयोग करते हैं, तो सामग्री बदलाव के बाद प्रमुख URL का निरीक्षण करें। Google कहता है कि URL Inspection यह जांचने में मदद कर सकता है कि उसका क्रॉलर पृष्ठ को कैसे देखता है और क्या वह महत्वपूर्ण संसाधनों तक पहुँच सकता है। आकस्मिक ब्लॉकिंग, टूटी आंतरिक लिंक्स, या अस्पष्ट पथ ठीक करें, फिर रिक्रॉलिंग के लिए समय दें। Google अनुक्रमण या रैंकिंग की गारंटी नहीं देता।
साइन-आउट होकर आंतरिक लिंक्स खोलें और 404 पृष्ठ, लूप्स और अप्रासंगिक गंतव्यों को लॉग करें।
वितरण वह जगह देखें जहाँ विज़िटर अनुभव करते हैं
डिलीवरी में सर्वर रिस्पॉन्स, इमेज, फ़ॉन्ट, स्क्रिप्ट, कैशिंग और तृतीय पक्ष शामिल हैं। प्राथमिक पृष्ठों पर ब्राउज़र प्रदर्शन जाँच चलाएँ, फिर एक वास्तविक फोन पर मूल कार्य दोहराएँ। मुख्य सामग्री देर से दिखाई दे रही है, धीमे कंट्रोल, लेआउट जंप, विफल संसाधन, या ऐसे बैनर नोट करें जो कार्य अवरुद्ध करते हैं। Core Web Vitals एक web.dev उपयोगकर्ता-अनुभव फ्रेमवर्क है; मापन का उपयोग जर्नी परीक्षण की जगह नहीं बल्कि जांच केंद्रित करने के लिए करें।
नई टैग्स, विजेट्स, एम्बेड्स, फ़ॉन्ट और छवि परिवर्तनों की कार्यान्वयनकर्ता के साथ समीक्षा करें। HTTP कैश पहले के रिस्पॉन्स को पुन: उपयोग करते हैं। MDN बताता है कि Cache-Control कैशिंग निर्देशों को संप्रेषित करता है और कैश्ड रिस्पॉन्स ताज़ा या स्टेल हो सकते हैं। रिलीज के बाद सामान्य और ताज़ा ब्राउज़र सत्र की तुलना करें, फिर तकनीकी मालिक को हेडर और CDN नियम जांचने के लिए कहें। गोपनीयता और रिलीज प्रभाव को समझे बिना समग्र कैश परिवर्तन से बचें।
रिकॉर्ड करें कि क्या प्राथमिक सामग्री दिखाई देती है, पृष्ठ स्थिर रहता है, और आवश्यक कंट्रोल प्रतिक्रिया देते हैं।
MDN बताता है कि केवल कुकी किसी रिस्पॉन्स को निजी नहीं बनाती; वैयक्तिकृत कैशिंग की समीक्षा के लिए तकनीकी मालिक से पूछें।
सुरक्षा बुनियादी स्तर की पुष्टि करें और भुगतान परिवर्तनों को सुरक्षित रखें
एक मालिक जांच दृश्यमान अंतराल खोज सकती है; यह penetration test नहीं है। सार्वजनिक साइट को HTTPS पर खोलें और HTTP आज़माएँ। OWASP सभी पृष्ठों के लिए TLS की सलाह देता है और सार्वजनिक HTTP ट्रैफ़िक को HTTPS पर रीडायरेक्ट करने को सामान्य दृष्टिकोण बताता है। सर्टिफिकेट या मिक्स्ड-कन्टेंट चेतावनियों, अप्रत्याशित डोमेंस, और HTTP पृष्ठों को सुरक्षित रूप से रीडायरेक्ट के बजाय कंटेंट सर्व करने जैसी चीज़ों को एस्केलेट करें।
प्रकाशन, डोमेन, DNS, भुगतान, प्लगइन और बैकअप एक्सेस के वर्तमान स्वामित्व की पुष्टि करें। एक योग्य सुरक्षा पेशेवर या प्रदाता को TLS कॉन्फ़िगरेशन, पैचिंग, प्रमाणीकरण, सर्वर कॉन्फ़िगरेशन और लॉग्स की समीक्षा करनी चाहिए। भुगतान के लिए केवल एक प्रदाता-स्वीकृत परीक्षण विधि या सुरक्षित नॉन-प्रोडक्शन वातावरण का उपयोग करें। किसी अनौपचारिक परीक्षण में वास्तविक कार्ड डेटा या क्रेडेंशियल कभी न डालें और केवल दृश्य समीक्षा को PCI अनुपालन का प्रमाण न मानें।
सर्टिफिकेट चेतावनी, असुरक्षित-कंटेंट चेतावनी, या अप्रत्याशित रीडायरेक्ट को जाँच होने तक रिलीज़ रोकने वाला मुद्दा मानें।
संदिग्ध समझौता, सुरक्षा आवश्यकताओं, और भुगतान अनुपालन प्रश्नों को योग्य समीक्षक के पास भेजें।
पुनर्प्राप्ति को सिद्ध करें और लूप बंद करें
प्राथमिक यात्रा को पुनर्निर्मित करने के लिए क्या चाहिए इसकी सूची बनाएं: एप्लिकेशन वर्शन, डेटाबेस, अपलोड की गई मीडिया, कॉन्फ़िगरेशन स्थान, DNS और डोमेन एक्सेस, इंटीग्रेशन सेटिंग्स, और विक्रेता संपर्क। CISA सलाह देता है कि महत्वपूर्ण डेटा की पहचान करें, वेबसाइट और संचालन डेटाबेस की रक्षा करें, बैकअप सुरक्षित रखें, और पुनर्प्राप्ति का परीक्षण करें। पूछें कि कब एक रिस्टोर का परीक्षण हुआ, उसने क्या बहाल किया, कितना समय लगा, और कौन उसे अधिकृत कर सकता है। जहाँ व्यावहारिक हो सुरक्षित रूप से अभ्यास करें।
रिलीज से पहले पूर्व संस्करण, रिवर्सल ट्रिगर, अनुमोदक, और DNS, कैश, डेटाबेस स्कीमा, और तृतीय-पक्ष परिवर्तनों के हैंडलिंग की पहचान करें। एक बैकअप तत्काल समाधान नहीं है, और रोलबैक बाहरी डेटा या भुगतान घटनाओं को उलट नहीं कर सकता। निष्कर्ष, साक्ष्य, मालिक, तिथि और पुन:परीक्षण परिणाम का रजिस्टर रखें।
स्कोप, तिथि, परिणाम और अंतर की रिकॉर्डिंग “बैकअप चलते हैं” से अधिक विश्वसनीय है।
सही वातावरण में फ़िक्स के बाद मूल विफल पथ का सत्यापन करें।