2 वर्षों के हाथ से बने वेब ऑप्टिमाइज़ेशन ह्यूरिस्टिक्स को एक ऑडिट इंजन, एक उत्पाद, और एक $10M लीड में बदलने पर.
Developed by Robert E. Beckner III (Merlin) | rbeckner.com
मैंने लगभग 2 वर्ष अपने प्रोजेक्ट्स में ह्यूरिस्टिक्स को समृद्ध करने में बिताए. मैं शुरू में एक उत्पाद नहीं बना रहा था. मैं यह समझने की कोशिश कर रहा था कि कुछ साइटें क्यों दिखाई देती हैं और अन्य क्यों नहीं.
काम एक से अधिक अनुशासन को कवर करता था. संरचित डेटा. मोबाइल समानता. वास्तविक उपयोगकर्ता के लिए पृष्ठ वास्तव में कितनी तेज़ी से लोड होता है, केवल स्कोर नहीं. क्या साइट की सुरक्षा स्थिति चुपचाप उसके विश्वास संकेतों को नुकसान पहुंचा रही थी. क्या खोज इंजन वही सामग्री देखते हैं जो मनुष्य देखते हैं. प्रत्येक ह्यूरिस्टिक ने मुझे "हमने एक वेबसाइट बनाई" और "खोज इंजन समझते हैं कि हम क्या करते हैं" के बीच के अंतर के बारे में कुछ सिखाया।
उस परिष्करण के माध्यम से, मैंने 50+ ह्यूरिस्टिक्स में सूत्र बनाए. कुछ ने क्रॉल करने की क्षमता मापी. अन्य ने बॉट्स और मनुष्यों के बीच रेंडरिंग समानता मापी. कुछ ने मानकीकृत सुरक्षा कार्यान्वयन को ट्रैक किया. पैटर्न लगातार थे. समस्याएँ संरचनात्मक थीं। और वे सुधारी जा सकती थीं।.
एक लेंडिंग साइट ने 65 स्कोर किया, और हमने इसे 100 तक ले गए#
वास्तविक परीक्षण तब आया जब मैंने एक दोस्त की वेबसाइट पर पूरा सेट चलाया. वह Sphinx Capital नामक एक लेंडिंग कंपनी चलाता है। मैंने जो कुछ भी सीखा था, उसे उसके साइट के ओवरहाल में डाल दिया था.
मैंने अपनी खुद की इंफ्रास्ट्रक्चर का उपयोग करके एक निजी ऑडिट चलाया. साइट ने ह्यूरिस्टिक सेट के खिलाफ लगभग 65 में से 100 स्कोर किया. अगले 30 दिनों में, हमने नींव को फिर से बनाया — संरचित डेटा, कैनॉनिकल कॉन्फ़िगरेशन, पृष्ठ गति, मोबाइल रेंडरिंग, सुरक्षा हेडर, पूरी स्टैक. स्कोर 100 तक बढ़ गया.
ट्रैफ़िक लगभग तुरंत ही आने लगा. यह पहला संकेत था कि ह्यूरिस्टिक्स केवल सैद्धांतिक रूप से ठोस नहीं थे. वे वास्तविक बाजार में वास्तविक प्रतिस्पर्धा के साथ काम कर रहे थे.
जब ट्रैफ़िक आ रहा था, मैंने ऑडिट इंजन को एक उत्पाद में पैकेज करना शुरू किया#
इंजन ने एक वास्तविक साइट पर खुद को साबित किया, इसलिए मैंने इसे the free audit engine I run नामक उत्पाद में पैकेज किया। मुफ्त संस्करण पहले लाइव हुआ. मैंने इसे स्वतंत्र निर्माताओं — पेंटर, संगीतकार, फ़ोटोग्राफ़र जिन्हें अपनी वेबसाइटों के लिए कोई एजेंसी बजट नहीं था, के साथ साझा किया. रिपोर्टों ने उन्हें संरचनात्मक सुधारों की प्राथमिकता वाली सूची दी. कई ने उन पर कार्रवाई की और कुछ हफ्तों में ट्रैफ़िक में सुधार देखा.
वही अनुवाद प्रणाली जिसे मैंने पिछले 4 वर्षों में बनाया था, रिपोर्टों को 9 भाषाओं में प्रस्तुत करती थी. यह कोई फीचर नहीं था जिसे मैंने बाद में जोड़ा. यह शुरुआत से ही इंफ्रास्ट्रक्चर था. कोलंबिया में एक कलाकार और संयुक्त राज्य अमेरिका में एक छोटा लेंडर दोनों अपनी ऑडिट्स को अपनी भाषा में बिना किसी रुकावट के पढ़ सकते थे.
मैं अभी भी उत्पाद को कुछ पॉलिश्ड में बना रहा था जब क्षण आया.
किसी ने Google के लिए एक Fix-and-Flip Loan खोजा और एक $10M लीड उत्पन्न की#
यह ओवरहाल पूरा होने के लगभग 30 दिनों बाद हुआ. उपयोगकर्ता मोबाइल डिवाइस पर था और उसने ऋण आवेदन 5 मिनटों में भर दिया. लीड का मूल्य $10M था.
वह एकल खोज परिणाम वह क्षण था जब मैंने महसूस किया कि इंजन सिर्फ काम नहीं कर रहा था. यह वास्तविक पैसे के लिए, वास्तविक बाजारों में, वास्तविक प्रतिस्पर्धा के खिलाफ, उस डिवाइस पर काम कर रहा था जिसे अधिकांश लोग वास्तव में उपयोग करते हैं. वह तकनीकी आधार जिसे मैं 2 वर्षों से परिष्कृत कर रहा था, ने अभी एक लीड उत्पन्न की जिसका मूल्य अधिकांश वार्षिक विपणन बजट से अधिक था — और यह जैविक रूप से, खोज के माध्यम से आया, क्योंकि साइट क्रॉल करने योग्य, तेज़ और स्पष्ट थी.
ऑडिट इंजन लॉन्च करने के बाद, 1,149 रिपोर्टों ने वही पैटर्न दिखाया#
मुफ्त ऑडिट टूल लॉन्च करने के बाद, पैटर्न केवल और स्पष्ट हो गए हैं. 1,122 मुफ्त ऑडिट्स में:
Free-audit findings across 1,122 audits (% of audits with issues)Chart data
% of audits
Security gaps
88
Performance concerns
82
Crawlability issues
81
Canonical/redirect problems
67
Site architecture gaps
40
ये किनारे के मामले नहीं हैं. वे वेब की डिफ़ॉल्ट स्थिति हैं.
सबसे तेज़ी से सुधरे हुए ऑडिट्स का एक समान पहलू था: संस्थापक तकनीकी निष्कर्षों पर दिनों में कार्यवाही करते थे, महीनों में नहीं. एक रियल एस्टेट प्लेटफ़ॉर्म ने ऑडिट के बाद अपनी साइटमैप और कैनॉनिकल कॉन्फ़िगरेशन ठीक की. इंडेक्स्ड पेज काउंट 3 हफ्तों में दोगुना हो गया. एक लेंडिंग साइट ने Time to First Byte को 2.4 सेकंड से 380 मिलीसेकंड तक घटाया. ऑर्गेनिक ट्रैफ़िक 34% बढ़ा 60 दिनों में.
पैटर्न सुसंगत है. तकनीकी तैयारी सामग्री मात्रा से बेहतर है. 50 पृष्ठों वाला तेज़, क्रॉल करने योग्य साइट धीमी, टूटे हुए साइट से बेहतर है जिसमें 500.
Diagram source
graph LR
A[तकनीकी ऑडिट चलाएँ] --> B{महत्वपूर्ण समस्या पाई गई?}
B -->|हाँ| C[दिनों में ठीक करें]
B -->|नहीं| D[गति अनुकूलित करें]
C --> E[पुनः-सूचकांकित करें]
D --> E
E --> F[जैविक खोज]
style C fill:#e1f5e1
style F fill:#e1f5e1
अधिकांश साइटें खोज चरण में विफल होती हैं: सर्च इंजन उनके पेजों को क्रॉल, इंडेक्स या रैंक नहीं कर पाते. यदि उसके नीचे की इंफ्रास्ट्रक्चर टूटे हुए है तो कंटेंट कैलेंडर का कोई महत्व नहीं है.
सबसे सामान्य समस्याएँ ग्लैमर नहीं हैं. वे संरचनात्मक हैं:
गुम या खराब साइटमैप — Google आपके पेज नहीं ढूंढ सकता यदि आप उसे नहीं बताते कि वे कहाँ हैं।
कोई कैनॉनिकल टैग नहीं — वही सामग्री कई URLs पर रहती है, जिससे प्राधिकरण डुप्लिकेट्स में बंट जाता है.
टूटा हुआ hreflang — बहुभाषी साइटें गलत क्षेत्र को गलत भाषा देती हैं, जिससे क्रॉलर्स भ्रमित होते हैं.
रेंडर-ब्लॉकिंग संसाधन — पेज मनुष्यों को अच्छे लगते हैं लेकिन बॉट्स के लिए खाली होते हैं.
धीमी सर्वर प्रतिक्रिया समय — क्रॉलर्स पेज लोड होने से पहले ही छोड़ देते हैं.
ये इंजीनियरिंग समस्याएँ हैं. और ये ठीक की जा सकती हैं.
वह एकीकृत विचार जो मैं जो कुछ भी बनाता हूँ, वह खोजने योग्य होना है. चाहे आप उधारकर्ता तक पहुँचने की कोशिश कर रहे ऋणदाता हों, बाजारों की जाँच कर रहे निवेशक हों, या खोजे जाने की कोशिश कर रहे संस्थापक हों, समस्या वही है: सही लोगों को सही समय पर आपको खोजने की आवश्यकता है.
खोज इंजन अभी भी इंटरनेट के लिए प्राथमिक खोज परत हैं. अपनी तकनीकी नींव को ठीक करना वह सबसे अधिक प्रभावी कदम है जो अधिकांश व्यवसाय उठा सकते हैं. मैंने यह सीखा जब मैंने 2 वर्ष डेटा में बिताए, संरचित डेटा, मोबाइल समरूपता, प्रदर्शन और सुरक्षा में ह्यूरिस्टिक्स को परिष्कृत किया, और एक मोबाइल डिवाइस पर एकल खोज को $10M लीड में बदलते देखा, जिसने साबित किया कि काम मायने रखता है.
वही ऑडिट इंजन आज भी चल रहा है. आप अपनी साइट के स्कोर यहाँ देख सकते हैं here.