खोज क्वेरी को पेज ब्रीफ में बदलें
एक सटीक इरादे क्लस्टर के साथ शुरू करें। क्वेरी थीम, विज्ञापन वादा, संभावित प्रश्न, डेस्टिनेशन URL, और एक प्राथमिक क्रिया रिकॉर्ड करें। एक आपात-नल-सॉल्वर (emergency-plumber) खोज में सेवा क्षेत्र, उपलब्धता, संपर्क विधि, और योग्यताएँ चाहिए; एक प्रोडक्ट-श्रेणी खोज में मूल्य, फिट, और तुलना विवरण की आवश्यकता हो सकती है।
मेसेज मैच अर्थ को संरक्षित करता है; यह कीवर्ड बार-बार करने का अर्थ नहीं है। हीरो सेक्शन को यह जवाब देना चाहिए कि यह क्या है और विज़िटर ने क्लिक क्यों किया—वही ऑफ़र या परिणाम जो विज्ञापन में था। जब कोई अपवाद, मूल्य-आधार, पात्रता, या भौगोलिक सीमाएँ निर्णय को प्रभावित करती हैं तो दावे के बगल में उन्हें रखें।
डिज़ाइन से पहले क्वेरी थीम, ऑफ़र, दर्शक, क्रिया, और आवश्यक प्रमाण लिखें।
सटीक शब्दावली किसी ऐसे ऑफ़र को ठीक नहीं कर सकती जो व्यवसाय प्रदान नहीं कर सकता।
पहली स्क्रीन को अगली क्रिया के योग्य बनाएं
एक स्पष्ट हेडिंग, संक्षिप्त स्पष्टीकरण, दिखाई देने योग्य क्रिया, और उस क्रिया को विश्वसनीय बनाने के लिए आवश्यक प्रमाण का उपयोग करें: सटीक मूल्य, विनिर्देश, डिलीवरी विवरण, पात्रता नियम, रिटर्न पॉलिसी, या संदर्भ-सूचक प्रतिक्रिया। सामग्री शर्तों को छिपाने के बजाय विस्तृत जानकारी के लिंक दें।
एक प्रमुख क्रिया इरादे से मेल खानी चाहिए: “Get a quote,” “Check availability,” और “Buy now” अलग-अलग प्रतिबद्धताएँ हैं। यदि पहले जानकारी की आवश्यकता है, तो उसे पहुँचने में आसान बनाएं। पॉप-अप, ऑटो-डाउनलोड, और असंबंधित नेविगेशन से बचें जो कार्य में बाधा डालते हैं; Google उन डेस्टिनेशन को मनाही करता है जो अनावश्यक रूप से कठिन या निराशाजनक नेविगेशन प्रस्तुत करते हैं।
मूल्य, क्रिया, और महत्वपूर्ण शर्त को शीर्ष के पास रखें; उन्हें नीचे समर्थन दें।
अप्रमाणित दावों के बजाय विशिष्ट, सत्यापनीय व्यवसाय जानकारी का उपयोग करें।
मोबाइल फॉर्म को पूरा करने के लिए डिज़ाइन करें
फोन पर पाथ की जांच करें: लैंडिंग व्यू, सहमति, फ़ॉर्म, वैलिडेशन, पुष्टि, फोन लिंक, और हैंडऑफ़। संकीर्ण व्यूपोर्ट पर टेक्स्ट और कंट्रोल्स क्लिप या ओवरलैप नहीं होने चाहिए। WCAG 2.2 कहता है कि सामान्य वर्टिकल सामग्री को 320 CSS पिक्सल पर बिना जानकारी या कार्यक्षमता खोए रिफ्लो होना चाहिए, सिवाय उन मामलों के जहाँ दो-आयामी लेआउट अनिवार्य हो।
हर इनपुट को एक दिखाई देने वाला, संबद्ध लेबल दें और अस्पष्ट फ़ॉर्मैट्स को बताएं। W3C समझाता है कि लेबल और निर्देश लोगों को बताते हैं कि किस डेटा की अपेक्षा है और त्रुटियों को रोक सकते हैं। अस्थायी फ़ील्ड संकेत, रंग, या केवल आइकन पर निर्भर न रहें। कीबोर्ड ऑर्डर, फ़ोकस, त्रुटियाँ, ज़ूम, और साइट के अनुसार सहायक-प्रौद्योगिकी समीक्षा का परीक्षण करें।
जहाँ संभव हो आरामदायक आकार के कंट्रोल प्रयोग करें। WCAG का 44 × 44 CSS-पिक्सल टार्गेट Level AAA के लिए संवर्धित मानक है, न कि सार्वभौमिक कानूनी नियम।
केवल उस डेटा के लिए पूछें जो कथित अगले कदम के लिए आवश्यक है।
गति के लिए बजट रखें और पाथ की रक्षा करें
रिलीज़ से पहले लैब डायग्नोस्टिक्स और रिलीज़ के बाद फील्ड डेटा का उपयोग करें। Web Vitals LCP को परसेइव्ड लोडिंग के रूप में, INP को प्रत्युत्तरशीलता के रूप में, और CLS को दृश्य स्थिरता के रूप में परिभाषित करता है। सिफारिश किए गए अच्छे थ्रेशहोल्ड्स 75वें पर्सेंटाइल पर मोबाइल और डेस्कटॉप को अलग करते हुए हैं: LCP 2.5 सेकंड के भीतर, INP 200 मिलीसेकंड या उससे कम, और CLS 0.1 या कम। ये बेंचमार्क हैं, रूपांतरण के गारंटी नहीं।
पहली स्क्रीन को प्राथमिकता दें: इमेज आयाम सेट करें, साइज्ड इमेज्स डिलीवर करें, गैर-आवश्यक कोड को डेफर करें, और धीमी प्रतिक्रिया, रेंडर-ब्लॉकिंग संसाधन, लंबे टास्क, और शिफ्ट्स की जांच करें। फ़ाइनल URL, रीडायरेक्ट्स, कैंपेन पैरामीटर्स, सहमति, सबमिट, पुष्टि, और महत्वपूर्ण निर्भरताओं का अभ्यास करें। कम ट्रैफ़िक वाले पेजों में फील्ड डेटा कम हो सकता है; लैब चेक्स का उपयोग करें और ट्रैफ़िक बढ़ने पर वास्तविक-उपयोगकर्ता डेटा एकत्र करें।
प्रकाशन से पहले प्रतिनिधि मोबाइल और डेस्कटॉप परिस्थितियों पर पेज, क्रिया, और पुष्टि का परीक्षण करें।
SIU प्रीफ़्लाइट और रेमेडिएशन प्रथाओं का उपयोग करके कैंपेन विस्तारण से पहले रोकी जा सकने वाली लैंडिंग-पाथ रिग्रेशन को कम करें।
विश्वसनीयता, डेटा संग्रह, और भुगतान को दायरे में रखें
विज़नेस पहचान, ऑफ़र की शर्तें, प्राइवेसी विकल्प, और संपर्क मार्ग को विज्ञापन के साथ सुसंगत रखें और संवेदनशील क्रियाओं से पहले दृश्य बनाएं। केवल वही डेटा इकट्ठा करें जो उद्धृत उद्देश्य के लिए आवश्यक हो। वैलिडेशन, सहमति, और रिटेंशन उत्पाद और कानूनी निर्णय हैं; यह लेख शैक्षिक है, कानूनी सलाह नहीं।
यदि पाथ कार्ड लेती है या एक पेमेंट फ्रेम एम्बेड करती है, तब स्क्रिप्ट और HTTP-हेडर परिवर्तन भुगतान-पेज सुरक्षा को प्रभावित कर सकते हैं। PCI SSC कहता है कि PCI DSS v4.x आवश्यकताएँ 6.4.3 और 11.6.1 स्क्रिप्ट अधिकृतकरण और अखंडता के साथ-साथ टेमपर मॉनिटरिंग को संबोधित करती हैं, जिसमें सुरक्षा-प्रभावित हेडर्स शामिल हैं। एक स्वीकृत भुगतान आर्किटेक्चर का उपयोग करें और क्रियान्वयन और एक्वायरर दायित्वों का मूल्यांकन करने के लिए योग्य सुरक्षा, अनुपालन, और कानूनी समीक्षकों से आकलन कराएँ।
पेमेंट-प्रभावित पेजों पर स्क्रिप्ट, मालिक, उद्देश्य, और पृष्ठों की सूची बनाएं पहले कि पेमेंट-पाथ परिवर्तित करें।
इस चेकलिस्ट से PCI DSS अनुपालन निष्कर्ष न निकालें; PCI SSC किसी इकाई के अनुपालन का निर्धारण नहीं करता।
परीक्षण करें बिना परिणामों को भ्रमित किए
एक परिकल्पना, एक प्राथमिक परिणाम, और पृष्ठ त्रुटियों, अमान्य लीड्स, स्पीड, और रद्दीकरण जैसे गार्डरेल घोषित करें। क्वेरी थीम, ऑफ़र की शर्तें, ट्रैफ़िक स्रोत, मापन परिभाषाएँ, और पेज परिवर्तन इतनी स्थिर रखें कि तुलना का अर्थ निकले।
Google Ads एक कैंपेन प्रयोग को एक ड्राफ्ट के रूप में परिभाषित करता है जिसे मूल से परीक्षण के लिए उसके कुछ ट्रैफ़िक और बजट का उपयोग करके एक निर्दिष्ट अवधि के लिए चलाया जाता है। यह स्वचालित रूप से हर लैंडिंग-पेज URL परीक्षण को मान्य नहीं करता। वैरिएंट्स की निष्पक्ष तुलना करने की विधि का उपयोग करें, एक्सपोज़र और तारीखों का दस्तावेज़ रखें, और जो गार्डरेल नुकसान पहुँचाते हैं उस वैरिएंट को रोलबैक करें।
जब आपको यह जानना हो कि किस चीज़ ने परिणाम उत्पन्न किया, तो एक साथ हेडलाइन, ऑफ़र, फ़ॉर्म लंबाई, और दर्शक न बदलें।
परिकल्पना, वैरिएंट्स, नियम, मीट्रिक्स, सीमाएँ, परिणाम, मालिक, और रोलबैक निर्णय सहेजें।