AI से बनी वेबसाइट को प्रकाशित करने से पहले कैसे जाँचें

AI कुछ ही मिनटों में ऐसा लैंडिंग पेज या फ़ॉर्म बना सकता है जो पूरा दिखता है। यही रफ़्तार वाइब कोडिंग का फ़ायदा है, पर इससे एक अच्छे प्रीव्यू को तैयार उत्पाद समझ लेना भी आसान हो जाता है। वेबसाइट बेदाग़ दिख सकती है और उसमें ग़लत लिंक, ग़ायब होता डेटा, बिना व्याख्या की त्रुटियाँ या ऐसा सर्वर-कोड हो सकता है जो बदले जा सकने वाले मानों पर भरोसा करता है।

यह प्रकाशन-जाँच उदाहरण के लिए वर्कशॉप पंजीकरण लेती है। व्यक्ति एक सत्र चुनता है, नाम और ईमेल लिखता है और पुष्टि पाता है। सात जाँचें बने हुए ड्राफ़्ट को उस संस्करण से अलग करती हैं जिसे आप ज़िम्मेदारी से प्रकाशित कर सकते हैं। हर जाँच एक दिखने वाला प्रमाण माँगती है, «काम करना चाहिए» वाक्य नहीं।

1. जाँच से पहले नतीजा और दायरा तय करें

एक वाक्य लिखें जिसमें अनिवार्य नतीजा हो: «मोबाइल और डेस्कटॉप, दोनों पर इच्छुक व्यक्ति उपलब्ध वर्कशॉप चुन सके, सही संपर्क विवरण भेज सके और एक साफ़ पुष्टि पाए»। यह भी लिखें कि इस संस्करण में क्या नहीं है, जैसे भुगतान, उपयोगकर्ता खाता या कैलेंडर सिंक।

यह सीमा AI को समीक्षा के दौरान सुविधाएँ जोड़कर पहले से चलती चीज़ें बिगाड़ने से रोकती है। एक साफ़ दायरे वाला प्रॉम्प्ट प्रभावित हिस्सा, अपरिवर्तित रहने वाली चीज़ें और स्वीकृति मानक भी बताता है। शुरुआती स्थिति को वर्ज़न कंट्रोल में या नाम वाले प्रीव्यू के रूप में सहेजें, ताकि आप ठीक-ठीक बता सकें कि क्या जाँचा गया।

2. असली ब्राउज़र में मुख्य रास्ता चलाएँ

साइट को एक आगंतुक की तरह खोलें, केवल कोड पढ़ने वाले की तरह नहीं। सार्वजनिक प्रवेश से शुरू करें, पंजीकरण तक जाएँ, सत्र चुनें, फ़ॉर्म भरें और नतीजा देखें। पेज दोबारा लोड करके और सँकरी स्क्रीन पर यही दोहराएँ। लिंक, फ़ोकस, प्रतीक्षा और पुष्टि—सब प्रवाह का हिस्सा हैं।

Playwright सुझाता है कि वही व्यवहार जाँचा जाए जो उपयोगकर्ता को दिखता है। बटन को उसकी भूमिका और सुगम नाम से ढूँढ़ें और दिखने वाला सफलता-संदेश जाँचें। भीतर का कोई CSS वर्ग यह सिद्ध नहीं करता कि कोई व्यक्ति उस क्रिया को ढूँढ़ या समझ सकेगा।

सही रास्ता काफ़ी नहीं। कम से कम एक ख़ाली स्थिति, एक अमान्य इनपुट और एक तकनीकी विफलता जाँचें:

• कोई सत्र नहीं: पेज स्थिति समझाता है और एक उपयोगी अगला क़दम देता है।
• ईमेल ग़लत: फ़ील्ड के पास समझ आने वाली व्याख्या मिलती है और फ़ोकस बना रहता है।
• दो बार क्लिक या धीमा नेटवर्क: पंजीकरण दो बार सहेजा नहीं जाता।
• सर्वर जवाब नहीं देता: डेटा चुपचाप ग़ायब नहीं होता और सफलता का नाटक नहीं होता।

3. फ़ॉर्म के दोनों सिरे सुरक्षित करें

HTML के फ़ील्ड प्रकार, required, उचित सीमाएँ और तुरंत मिलने वाली प्रतिक्रिया ग़लतियाँ सुधारने में मदद करती हैं। MDN याद दिलाता है कि क्लाइंट-साइड जाँच पूरी सुरक्षा नहीं है, क्योंकि अनुरोध इंटरफ़ेस को टाल सकता है। सर्वर को वही व्यावसायिक सीमाएँ अलग से लागू करनी होंगी।

पंजीकरण में सर्वर केवल असली सत्रों की पहचान स्वीकार करता है, फ़ील्ड की लंबाई सीमित करता है, ईमेल को सोच-समझकर सामान्य रूप देता है और अप्रत्याशित डेटा अस्वीकार करता है। वह यह भी जाँचता है कि सीट बची है। फ़ॉर्म में छिपा कोई मान अनुमति नहीं होता।

डेटा का रास्ता बनाएँ: ब्राउज़र से क्या निकलता है, कहाँ सहेजा जाता है, कौन पढ़ सकता है और कब मिटता है। अगर AI कोड और कॉन्फ़िगरेशन से साफ़ जवाब न निकाल सके, तो जोखिम खुला है।

4. कीबोर्ड, अर्थ और संदेश जाँचें

WCAG वेब सामग्री को अधिक सुगम बनाने का साझा मानक देता है। छोटे प्रकाशन के लिए पूरा मानक याद करने की ज़रूरत नहीं, पर मुख्य प्रवाह बिना माउस के भी समझ में आना और चलना चाहिए। Tab, Shift+Tab, Enter और Space से चलें। फ़ोकस न ग़ायब हो, न किसी डायलॉग के पीछे रहे।

दिखने वाले लेबल, शीर्षकों का क्रम, कंट्रास्ट, छवियों के विकल्प-पाठ और स्थिति-संदेश जाँचें। 200 प्रतिशत ज़ूम करें और सँकरी स्क्रीन इस्तेमाल करें। स्वचालित ऑडिट कई बुनियादी समस्याएँ पकड़ता है, पर वह न कीबोर्ड जाँच की जगह लेता है, न स्क्रीन रीडर या लोगों के साथ की गई छोटी समीक्षा की।

5. सुरक्षा की सीमाएँ परखें

OWASP बार-बार दिखने वाले वेब जोखिम गिनाता है, जैसे टूटा हुआ पहुँच-नियंत्रण, ग़लत कॉन्फ़िगरेशन, आपूर्ति-शृंखला की ख़ामियाँ और इंजेक्शन। इन श्रेणियों को ठोस सवालों में बदलें। क्या कोई व्यक्ति दूसरों के पंजीकरण पढ़ सकता है? क्या ब्राउज़र बंडल में कोई गुप्त कुंजी है? क्या सर्वर फ़ॉर्म से आई भूमिका पर भरोसा करता है? क्या बाहरी पैकेज और एनवायरनमेंट वेरिएबल नियंत्रित हैं?

कुछ भी बदलने से पहले AI से प्रमाण और जगहें बताने को कहें। लॉगिन, भुगतान, स्वास्थ्य जानकारी या अन्य संवेदनशील डेटा अनुभवी समीक्षा के हक़दार हैं। बना हुआ कोड परिभाषा से असुरक्षित नहीं होता, पर उसकी भरोसेमंद दिखावट बिना जाँची धारणाएँ छिपा सकती है।

6. ज़रूरी डिवाइस पर प्रदर्शन मापें

web.dev, LCP, INP और CLS को लोडिंग, प्रतिक्रिया और दृश्य स्थिरता के स्थिर Core Web Vitals के रूप में रखता है। ये उपयोगी संकेत हैं, कोई सार्वभौमिक पास-बटन नहीं। असली पेज को उत्पादन की छवियों, फ़ॉन्ट, स्क्रिप्ट और बाहरी सेवाओं के साथ मापें।

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

7. मंज़ूरी, निगरानी और वापसी तैयार रखें

प्रकाशन से पहले तीन सवालों के जवाब दें: कौन मंज़ूरी देता है? कौन-से संकेत विफलता दिखाएँगे? पिछला संस्करण कैसे वापस आएगा? एक नियंत्रित प्रीव्यू—जैसा ChatGPT Sites वाले लेख में है—आख़िरी समीक्षा के काम आता है, बशर्ते उसके पाठक और फ़ॉर्म डेटा सोच-समझकर चुने गए हों।

एक ठोस, परखा हुआ संस्करण प्रकाशित करें, कोई धुँधली «मौजूदा स्थिति» नहीं। उसके बाद सार्वजनिक URL, मुख्य प्रवाह, सर्वर त्रुटियाँ और असली सबमिशन जाँचें। वापसी तभी भरोसेमंद है जब लक्ष्य संस्करण, ज़िम्मेदार व्यक्ति और प्रक्रिया ज्ञात हों।

प्रकाशन के लिए संक्षिप्त सूची

• लक्ष्य, बाहर रखी चीज़ें और परखा गया संस्करण दर्ज हैं।
• सही रास्ता, ख़ाली स्थिति, अमान्य इनपुट और सर्वर विफलता ब्राउज़र में जाँचे गए।
• क्लाइंट और सर्वर, दोनों जाँचते हैं; अधिकार और डेटा का रास्ता समझ में आता है।
• प्रवाह कीबोर्ड, ज़ूम और एक ज़रूरी फ़ोन पर चलता है।
• गुप्त कुंजियाँ, एनवायरनमेंट वेरिएबल, निर्भरताएँ और सार्वजनिक बिंदु देखे गए।
• असली संसाधनों के साथ प्रदर्शन मापा गया और गंभीर गिरावट ठीक की गई।
• मंज़ूरी, निगरानी और वापसी के लिए एक ज़िम्मेदार व्यक्ति है।

ये जाँचें AI-सहायता की रफ़्तार मिटाने के लिए नहीं हैं। ये उसका असली फ़ायदा बचाती हैं: एक विचार से जल्दी ऐसे उपयोगी उत्पाद तक पहुँचना जिसका व्यवहार आप समझा सकें और जिसकी ज़िम्मेदारी ले सकें। जब कोई प्रमाण छूटे, तो उस कमी को अगला सीमित काम बना दें। दोहराव तेज़ बना रहेगा, और प्रकाशन जुआ नहीं बनेगा।