अपने निजी side project को SEO test bed की तरह इस्तेमाल करते हुए एक महीना पूरा हुआ तो मेरे पास 632 ऑर्गेनिक विज़िटर थे। यह उत्साहजनक था, लेकिन सबसे उपयोगी सीख दूसरे नंबर से मिली: 15 अक्टूबर को साइट ने उस समय तक का daily peak 83 विज़िटर देखा, और उस spike का कुछ हिस्सा इंसानी traffic जैसा नहीं लग रहा था.
उस समय मैं काम पर एक बड़े SEO initiative की तैयारी कर रहा था। मुझे केवल और theory पढ़ने के बजाय वास्तविक अभ्यास चाहिए था। Side project ने मुझे बदलाव करने, data देखने और गलत होने की जगह दी—बिना हर observation को तुरंत production decision बनाए.
यह फर्क जल्दी महत्वपूर्ण हो गया। किसी बदलाव के साथ metric का बदलना यह साबित नहीं करता कि वही बदलाव उसका कारण था। Traffic spike sources देखने से पहले growth जैसा लग सकता है। और session replay कुछ अजीब दिखा सकता है, लेकिन केवल उसी से यह पता नहीं चलता कि ऐसा क्यों हुआ.
632 ऑर्गेनिक विज़िटर वास्तव में क्या बताते हैं
पहले महीने का पुष्टि किया जा सकने वाला परिणाम 632 ऑर्गेनिक विज़िटर है। लेकिन यह अकेला नंबर यह साबित नहीं करता कि मैंने कोई repeatable SEO formula खोज लिया था, मेरे हर बदलाव ने ranking सुधारी, या यही trajectory आगे भी चलेगी.
Learning project के लिए असली मूल्य यह था कि अब observe करने लायक वास्तविक search traffic था। मैं बदलाव कर सकता था, देख सकता था कि कौन-सी metric हिली, और फिर अगला सवाल ज्यादा सटीक बना सकता था। यह SEO को ऐसी checklist मानने से ज्यादा उपयोगी था जिसमें हर “best practice” से automatically ranking gain की उम्मीद की जाए.
Font size ने correlation और causation का फर्क याद दिलाया
मुझे एक चीज़ ने खास तौर पर चौंकाया: font-size adjustments और performance metrics के बीच correlation. इसे “छोटी UX details rankings को प्रभावित कर सकती हैं” कह देना आसान था। मेरे data से इतना मजबूत दावा साबित नहीं होता.
मैंने वास्तव में इतना देखा: मैंने font size बदला और बाद में कुछ related metrics हिलीं। मैंने ऐसा controlled experiment नहीं किया जिसमें font size को बाकी सभी changes से अलग किया गया हो, और मेरे पास यह सबूत भी नहीं है कि search engine ने उसी CSS change के कारण ranking बदली। Font size line wrapping, layout और element positions बदल सकता है और इसलिए rendering या UX measurements पर असर डाल सकता है। मेरे case में exact mechanism फिर भी unproven है.
ऐसे experiment के लिए एक ज्यादा सुरक्षित rule है: पहले observation लिखो, explanation बाद में। “Change Y के बाद metric X हिली” data है। “Y ने X को cause किया” तब तक hypothesis है जब तक पर्याप्त evidence न हो.
83-विज़िटर वाला दिन Webvisor खोलने से पहले बेहतर लग रहा था
15 अक्टूबर को साइट ने उस समय तक का सबसे बड़ा daily total देखा: 83 विज़िटर। यह जरूरी नहीं कि 83 organic visitors थे; यह उस दिन का total traffic peak था जिसे मैं analyze कर रहा था। Source breakdown में एक महत्वपूर्ण हिस्सा China से आया और direct traffic के रूप में classify हुआ.
“Direct” को “किसी ने मेरा URL खुद टाइप किया” समझना आसान है। लेकिन Yandex Metrica में referrer pass न होने वाली sessions भी, कुछ अन्य स्थितियों के साथ, इस category में आ सकती हैं। Yandex इसे अपनी traffic-source documentation में बताता है। इसलिए source label अकेले यह नहीं बताता कि visitor कौन था या उसने page वास्तव में कैसे खोजा.
फिर मैंने Yandex Webvisor में suspicious sessions देखीं। Page ऐसा दिख रहा था जैसे उसे CSS disabled करके खोला गया हो। जो pattern मैंने देखा, उसके आधार पर मेरा अनुमान था कि लगभग 20 “users” शायद bots थे.
CSS का गायब होना clue था, proof नहीं
यह संख्या अभी भी estimate है। जो मैंने देखा उसके कम-से-कम दो broad explanations हो सकते हैं.
- Requests सच में automated हो सकती थीं. Scraper केवल HTML fetch कर सकता है और stylesheets, images या दूसरे अनावश्यक assets छोड़ सकता है। Bandwidth बचाना plausible कारण है, लेकिन मैंने यह confirm नहीं किया कि motive यही था.
- Replay original session को पूरी तरह reproduce न कर पाया हो. Session-replay systems recorded data से page reconstruct करते हैं। Yandex खुद ऐसे cases document करता है जहाँ recording visitor को दिखे page से अलग हो सकती है, जिसमें stylesheet changes के बाद CSS-related replay problems भी शामिल हैं.
इसलिए “Webvisor में page CSS के बिना दिखा” observation है। “Visitor ने जानबूझकर CSS बंद किया” interpretation है। “इसलिए वह bot था” एक और inference है। Pattern ने bot hypothesis को मेरे लिए plausible बनाया, लेकिन replay की एक property confident classification के लिए काफी नहीं है.
Logs में मैं क्या verify करूंगा
ऐसी anomaly के लिए मैं visual replay से ज्यादा server logs पर भरोसा करूंगा। मैं User-Agent, IP या network ranges, request timing और repetition, requested assets, paths, HTTP status codes और referrers compare करूंगा। यह भी देखूंगा कि client ने केवल HTML मांगा या CSS, JavaScript और images भी, और क्या वही pattern analytics dimensions—browser, JavaScript support, region, session duration और landing page—में भी दिखता है.
इनमें से कोई signal अकेले perfect नहीं है। साथ में वे bot hypothesis को “replay अजीब लग रहा था” से कहीं बेहतर support या weaken कर सकते हैं.
बड़ी सीख ranking से ज्यादा measurement की थी
मैंने side project इसलिए शुरू किया था कि काम पर बड़े SEO initiative से पहले practical experience मिल सके। एक महीने बाद उपयोगी नतीजा केवल 632 ऑर्गेनिक विज़िटर नहीं था। उससे भी महत्वपूर्ण यह देखना था कि incomplete data के आसपास आकर्षक कहानी कितनी जल्दी बन सकती है.
मैं 83-विज़िटर peak को growth कह सकता था। Font change के बाद metrics के movement को “ranking factor” कह सकता था। हर CSS-less session को bot कह सकता था। तीनों कहानियां आसान होतीं। कोई भी पर्याप्त रूप से proven नहीं होती.
आगे के experiments के लिए ज्यादा defensible workflow होगा: traffic sources अलग करना, changelog रखना, before/after compare करना लेकिन causation assume न करना, anomalies को HTTP request level पर देखना, और analytics tools को भी limitations वाले measurement systems समझना.
मेरे लिए अभी तक experiment का सबसे मूल्यवान हिस्सा यही है। SEO ने study करने के लिए traffic दिया; कठिन skill यह तय करना है कि data वास्तव में क्या साबित करता है.
मैं logs में अभी भी खासकर China से आए direct traffic को देख रहा हूँ। अगर repeatable request pattern मिलता है, तो मूल सवाल का ज्यादा मजबूत जवाब होगा: क्या वे लगभग 20 visits वास्तव में bots थीं, और क्या CSS skip करना उनके behavior का हिस्सा था?