मैंने 25 साल पुराना डोमेन खरीदा: dead URLs पर रोज़ 1,000+ requests आने लगीं

मैंने एक ऐसा डोमेन खरीदा जो पहली बार 2000 में रजिस्टर हुआ था। कागज़ पर उसकी पुरानी history एक फायदा जैसी लग रही थी। लेकिन नया साइट लॉन्च करते ही server logs उन pages के requests से भरने लगे जिन्हें मैंने कभी बनाया ही नहीं था।

नए project में मौजूद न होने वाले URLs पर रोज़ 1,000 से ज़्यादा requests आ रही थीं। Analytics में यह लगभग zero engagement के साथ direct traffic का बड़ा spike दिख रहा था। उसी समय Yandex crawler पुराने paths पर वापस आ रहा था, 404 Not Found पा रहा था, और Yandex Webmaster में एक ही रात में 900 से ज़्यादा errors जमा हो गए।

मेरी पहली explanation सीधी थी: पुराने bots dead URLs को hit कर रहे हैं, Yandex उस activity को देख रहा है और इसलिए उन्हें crawl करता जा रहा है। मेरी तरफ से sequence ऐसा ही दिखता था। लेकिन मेरा data उस causal relationship को साबित करने के लिए पर्याप्त नहीं था।

मैं वास्तव में क्या confirm कर सकता था

तीन अलग observations थे। पहला, server डोमेन की पुरानी life से जुड़े URLs पर बहुत सारे requests ले रहा था। दूसरा, वह traffic meaningful user engagement में लगभग convert नहीं हो रहा था। तीसरा, Yandex crawler भी पुराने paths मांग रहा था और Webmaster dashboard में एक रात में 900 से ज़्यादा errors दिखे।

Operationally यह असली समस्या थी: noisy logs, unnecessary requests और साफ करने लायक webmaster report। लेकिन ये facts यह साबित नहीं करते कि third-party bots ने Yandex crawl को trigger किया, या errors ने ranking अथवा organic traffic को सीधे नुकसान पहुँचाया। Crawling indexing नहीं है, indexing ranking नहीं है, और error report penalty का proof नहीं है।

404 और 410 को लेकर मैंने क्या ज़्यादा simplify किया था

पहले मैं फर्क ऐसे समझता था: 404 का मतलब “शायद अभी नहीं है”, 410 का मतलब “हमेशा के लिए गया”। Intuition के लिए ठीक है, लेकिन technically पूरी तरह accurate नहीं है।

404 Not Found का मतलब है कि server requested resource का current representation नहीं दे सकता; status अपने आप यह नहीं बताता कि condition temporary है या permanent। 410 Gone ज़्यादा specific है: जब server जानता है कि resource अब available नहीं है और यह condition permanent मानी जा रही है, तब यह उचित है।

SEO claims में भी यह precision ज़रूरी है। Search engines 404 और 410 दोनों लौटाने वाले URLs को search से हटा सकते हैं। इसलिए अब मैं 410 को कोई magic “stronger SEO status” नहीं कहता और deleted pages पर 404 को हमेशा गलत भी नहीं मानता।

फिर भी मेरे case में targeted 410 सही क्यों था

पुराने paths temporary failure नहीं थे। वे डोमेन के पुराने content से जुड़े थे और नए project में उनकी कोई जगह नहीं थी। मुझे पता था कि ये specific URLs permanently gone थे। इसलिए 410 Gone उनकी वास्तविक स्थिति को सही तरीके से बताता था।

मैंने हर unknown URL को 410 करने के बजाय केवल known legacy paths पर targeted 410 configure किया। उसके बाद पुराने paths से जुड़ा crawl और reporting noise कम हुआ और webmaster tools की स्थिति काफी साफ हो गई।

फिर भी causal claim में मैं सावधान रहता हूँ। मैं कह सकता हूँ कि improvement targeted 410 के बाद आया और 410 उन URLs की स्थिति के लिए semantically सही था। मैं यह साबित नहीं कर सकता कि सिर्फ 410 ने हर bot को रोक दिया। कोई third-party bot HTTP status का meaning ignore करके उसी path को लगातार request कर सकता है।

अब मेरी decision rule क्या है

सही सवाल “410 क्या 404 से बेहतर है?” नहीं, बल्कि “इस URL के साथ वास्तव में क्या हुआ?” है।

• Clear replacement मौजूद है: वास्तव में equivalent नए URL पर 301 जैसे permanent redirect का उपयोग करें।
• पुराना resource permanently हट चुका है और replacement नहीं है: 410 Gone precise choice है।
• URL बस unknown है, typo है या कभी exist ही नहीं किया: सामान्य 404 Not Found उचित है।

मैं सिर्फ errors हटाने के लिए हर dead URL को homepage पर redirect नहीं करूँगा। इससे resource की real state छिप जाती है और user तथा crawler दोनों के लिए experience खराब हो सकता है।

आज मैं aged domain को launch से पहले कैसे audit करूँगा

अगर मैं फिर किसी पुराने history वाले domain का उपयोग करूँ, तो उसके URL history को migration का हिस्सा मानूँगा, भले ही पुरानी website खुद migrate न कर रहा हूँ।

1. पुराना footprint देखें। Launch से पहले historical URLs और obvious legacy sections खोजें।
2. पहले दिन से access logs देखें। ऐसे paths पर repeated requests जिन्हें आपने कभी बनाया नहीं, यह दिखाते हैं कि domain की external memory अभी भी मौजूद है।
3. Humans, search crawlers और random bots को अलग रखें। Direct traffic spike और crawler error अलग signals हैं; उन्हें automatically एक causal story में न मिलाएँ।
4. Recurring dead URLs को classify करें। हर important pattern के लिए तय करें कि 301, 404 या 410 में से क्या सही है।
5. Results को अलग-अलग monitor करें। Request frequency, crawler reports और indexing अलग dimensions हैं; इन्हें एक vague “SEO health” metric में न समेटें।

यह उस situation से बहुत कम काम है जिसमें समस्या तब दिखती है जब logs और webmaster tools पहले ही noise से भर चुके हों।

410 क्या solve नहीं करता

410 resource की state के बारे में HTTP statement है। यह firewall, rate limiter या bot-blocking mechanism नहीं है। अगर scraper 410 मिलने के बाद भी requests भेजता रहता है, server को वे requests अभी भी receive और answer करनी पड़ेंगी। अगर असली समस्या abusive request volume है, तो वह अलग infrastructure problem है।

410 SEO boost भी नहीं है। Correct status crawler को समझने में मदद करता है कि URL के साथ क्या हुआ; उससे नया site अपने आप बेहतर rank नहीं करता।

मेरे लिए बचा हुआ lesson

Surprise यह नहीं था कि पुराने domain के पुराने URLs थे। Surprise यह था कि invisible history launch के तुरंत बाद कितनी जल्दी वापस दिखने लगी: उन pages पर रोज़ 1,000 से ज़्यादा requests जो मेरे पास थे ही नहीं, लगभग zero engagement, और Yandex Webmaster में एक रात में 900 से ज़्यादा errors।

Aged domain खाली namespace नहीं है। Original content हटने के सालों बाद भी पुराने links, crawlers, scripts और bots paths याद रख सकते हैं। मेरी current rule सरल है: history audit करो, reality के मुताबिक HTTP status दो, और operational bot traffic को search-engine conclusions से अलग रखो।

History asset हो सकती है। लेकिन वह state भी है जिसे आप inherit करते हैं।