डीवीसी प्रोजेक्ट

इस पेज पर Google Docs के सीज़न के लिए स्वीकार किए गए एक तकनीकी लेखन प्रोजेक्ट की जानकारी है.

प्रोजेक्ट की खास जानकारी

ओपन सोर्स संगठन:
डीवीसी
तकनीकी लेखक:
रीमास्टर किया गया
प्रोजेक्ट का नाम:
एसईओ / साइट के आंकड़े और Docs के साइट अपडेट
प्रोजेक्ट की अवधि:
मानक अवधि (तीन महीने)

प्रोजेक्ट का विवरण

सर्च इंजन को ज़्यादा से ज़्यादा लोगों तक पहुंचाने, उपयोगकर्ता के व्यवहार को समझने, और आने वाले समय में कॉन्टेंट को बेहतर बनाने के लिए, मैं DVC के लिए बॉटम-अप ऑप्टिमाइज़ेशन रणनीति का सुझाव देता/देती हूं.

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

इस प्रोसेस का मकसद फ़ीडबैक लूप को इस तरह से तैयार करना है:

  1. खोज के नतीजों में किन पेजों और शब्दों को शामिल किया जाता है?
  2. इन शब्दों से क्या संबंधित है? क्या हम खोज करने वालों के सवालों के जवाब दे रहे हैं? दस्तावेज़ में क्या नहीं है?
  3. मौजूदा दस्तावेज़ को अपडेट करें या बनाए जाने वाले नए दस्तावेज़ों की पहचान करें (अगर यह बेहतर लगे).
  4. जिन क्षेत्रों में संगठन अपने नतीजे पाना चाहता है, लेकिन उनके पास कोई नतीजा नहीं है, तो सामग्री बनाने से पहले प्रतिस्पर्धी की खोजों या उपयोगकर्ता से जुड़े आंकड़ों का सबूत देख लें.
  5. 1 बजे फिर से शुरू करें.

मैं इस हाई-लेवल प्रोजेक्ट प्लान का सुझाव देता/देती हूं (सवाल-जवाब के सेशन में लागू करने के बारे में ज़्यादा जानकारी के साथ):

पहला हफ़्ता — Analytics टूल और ट्रैकिंग के लिए शुरुआती सेट अप. एसईओ ऑडिट चलाएं और मेटाडेटा या तकनीकी समस्याओं को ठीक करने के लिए समस्याएं जनरेट करें. (यह वॉर्म-अप पीरियड में भी शुरू हो सकता है). दूसरा हफ़्ता — उन दस्तावेज़ों की पहचान करें जो पहले से ही मुख्य शब्दों के हिसाब से रैंक किए जा रहे हैं. कॉन्टेंट को बड़ा करने के लिए, मिलते-जुलते शब्दों की पहचान करें और अन्य सुधारों के लिए दस्तावेज़ों का ऑडिट करें. अपडेट प्लान करने के लिए, हर दस्तावेज़ के स्केल पर समस्याएं बनाएं. दस्तावेज़ों को अपडेट/पब्लिश करना शुरू करें. तीसरा हफ़्ता — नए अवसरों की पहचान करने के लिए खोज के नतीजों पर नज़र रखना जारी रखें और प्लान किए गए अपडेट के बैकलॉग के हिसाब से काम करना जारी रखें. 4 से 10 हफ़्ता — हाल ही में अपडेट किए गए दस्तावेज़ों के खोज नतीजों में हुए बदलावों पर नज़र रखें. साथ ही, बैकलॉग पर नज़र रखें और उसे अपडेट करें. 10+ हफ़्ता — हालांकि, यह प्रोजेक्ट के लिए तय नहीं है, लेकिन बदलाव और तरीकों की दर को आसानी से तय करने के बाद, इन्हीं सिद्धांतों और फ़ीडबैक लूप का इस्तेमाल करके DVC के इस्तेमाल के उदाहरणों और दस्तावेज़ के होम पेज में बदलाव किए जा सकते हैं. मेरी राय में, ऐसे प्रोजेक्ट के लिए बॉटम-अप का तरीका भी ज़्यादा असरदार होता है.

यहां प्रोजेक्ट के आइडिया में दिए गए हर सवाल के सीधे तौर पर जवाब दिए गए हैं:

सवाल. हमें कौनसे टूल का इस्तेमाल करना चाहिए? (जैसे, Google Analytics वगैरह)

जवाब. रिपोर्ट के टूल के बीच डेटा इकट्ठा करने के लिए, Google Analytics, Google Search Console, और Google Data Studio ज़रूरी टूल हैं. Google Tag Manager की मदद से, कुछ खास क्लिक या पेज इवेंट को ट्रैक किया जा सकता है. उदाहरण के लिए, YouTube पर एम्बेड किए गए वीडियो ट्यूटोरियल. समस्याओं को फ़्लैग करने और Docs साइट पर प्रतिस्पर्धी और मिलते-जुलते खोज शब्दों को ट्रैक करने के लिए, मैं एसईओ ऑडिट टूल (मैं Ubersuggest का इस्तेमाल करता हूं) का भी इस्तेमाल करता हूं. हालांकि, DVC साइट बहुत तेज़ी से लोड होती है, लेकिन हमें यह पक्का करना होगा कि PageSpeed Insights की सुविधा का इस्तेमाल किया जाए. ऐसा इसलिए, क्योंकि यह एसईओ के लिए भी बहुत ज़रूरी है.

सवाल. हमें किन रुझानों और रिपोर्ट पर ध्यान देना चाहिए?

जवाब. एसईओ के मुख्य मेट्रिक, क्लिक, इंप्रेशन, क्लिक मिलने की दर (सीटीआर), और रैंक हैं. हालांकि, चुनौती यह है कि ये पीछे लगने वाले संकेत हैं और इन्हें बेहतर बनाने के लिए ज़्यादा जानकारी नहीं देते. इसके लिए, यह ट्रैक करना और मॉनिटर करना ज़रूरी है कि खोज करने से पहले और उसके बाद क्या होता है: लोग खोज के लिए किन शब्दों का इस्तेमाल करते हैं और साइट पर जाने के बाद क्या होता है. खोज के लिए इस्तेमाल किए जा रहे शब्द, कॉन्टेंट बनाने और अपडेट करने पर बेहतर काम करने के लिए ज़रूरी हैं (जैसा कि ऊपर बताया गया है). यह पक्का करना कि खोज के नतीजों पर आने वाले उपयोगकर्ताओं को अपनी खोज के नतीजे मिल जाएं. इससे, रैंकिंग बेहतर होगी या बिलकुल नहीं. ऐसा करने से, एक ही खोज (बाउंस) पर वापस आने से इंजन को पता चल जाता है कि वह पेज अच्छा नहीं है. साइट पर उपयोगकर्ता के जुड़ाव को मेज़र करना बहुत मुश्किल काम है. हालांकि, दस्तावेज़ के लिए हमें जिन ज़रूरी मेट्रिक की ज़रूरत होगी वे हैं बाउंस रेट, सेशन की अवधि, और पेज/सेशन. (जिन साइटों का लक्ष्य उपयोगकर्ता हासिल करना/खरीदना/संपर्क करना होता है, वहां लक्ष्य के हिसाब से कन्वर्ज़न रेट भी एक अहम मेट्रिक है.)

सवाल. हमारे पास किस तरह के उपयोगकर्ता हैं और वे किस इंटरैक्शन फ़्लो को फ़ॉलो करते हैं?

जवाब. अगर ऐसा करने के लिए सेट अप किया गया है, तो Google Analytics साइट, पेज टाइम, क्लिक यूआरएल, उपयोगकर्ता एजेंट प्रॉपर्टी के ज़रिए उपयोगकर्ता का पाथ ट्रैक करेगा. साथ ही, वेबसाइट पर वापस आने पर उनकी पहचान करने की कोशिश करेगा (और भी बहुत कुछ है, लेकिन ये बुनियादी बातें हैं). उपयोगकर्ता टाइप तय करने वाले पैटर्न की पहचान करने और उन्हें समझने में समय लगेगा, लेकिन शुरुआत के लिए लोकप्रिय इंटरैक्शन फ़्लो पर गौर करना एक अच्छी जगह है. सबसे लोकप्रिय लैंडिंग पेजों से शुरुआत करते हुए, हम दूसरे, तीसरे और उसके बाद के पेजों पर साफ़ तौर पर रुझानों की जांच करेंगे. इसके बाद, हम इनके हिसाब से उपयोगकर्ता मॉडल का सुझाव दे सकते हैं. इससे, इस्तेमाल के मुख्य उदाहरणों के बारे में जानकारी देने में भी मदद मिलेगी. इसके बाद, हम मॉडल/इस्तेमाल के उदाहरणों की पुष्टि करने के लिए, खोज के लिए इस्तेमाल हुए शब्दों, छोटी बातों, सर्वे, इंटरव्यू वगैरह का इस्तेमाल करते हैं.

सवाल. क्या हम इन उपयोगकर्ताओं की अधूरी पहचान कर सकते हैं और/या DVC के इस्तेमाल के आंकड़ों की मदद से उनके डेटा की क्रॉस-जांच कर सकते हैं?

जवाब. इस्तेमाल से जुड़े आंकड़ों के दस्तावेज़ के आधार पर, DVC असल में रैंडम आइडेंटिफ़ायर (uuid4) का इस्तेमाल करता है और प्रॉक्सी के ज़रिए डेटा भेजता है. यह मानते हुए कि इसमें कोई बदलाव नहीं किया जाएगा, क्रॉस-परीक्षा में सिर्फ़ दस्तावेज़ साइट के इस्तेमाल के पैटर्न के साथ, हर कमांड इवेंट का वॉल्यूम रुझान देखा जा सकेगा. इससे हमें दस्तावेज़ों और कमांड के इस्तेमाल में अंतर की पहचान करने में मदद मिलेगी. हालांकि, इससे उपयोगकर्ता के लेवल की अहम जानकारी नहीं मिलेगी. इसलिए, हम इस सवाल का जवाब दे सकते हैं कि “लोग किन कमांड/दस्तावेज़ों के लिए एक ही समय में दस्तावेज़ और कमांड का इस्तेमाल कर रहे हैं या नहीं?” यह बुनियादी बात है, लेकिन यह अनुमानों की बुनियादी पुष्टि करेगा (उदाहरण के लिए, अगर इस्तेमाल का कोई खास उदाहरण अच्छी तरह मेल खाता है, तो इससे मुख्य कमांड का इस्तेमाल बढ़ जाएगा) और अवसरों की पहचान होगी (जैसे, अगर किसी निर्देश का इस्तेमाल नहीं किया जा रहा है, लेकिन दस्तावेज़ गलत हैं) तो इसके उलट क्या है?