میں نے 25 سال پرانا ڈومین خریدا: مردہ URLs پر روزانہ 1,000+ requests آنے لگیں

میں نے ایک ایسا ڈومین خریدا جو پہلی بار 2000 میں رجسٹر ہوا تھا۔ کاغذ پر اس کی لمبی history ایک فائدہ لگ رہی تھی۔ لیکن نئی سائٹ لانچ ہوتے ہی server logs ان صفحات کے requests سے بھرنے لگے جو میں نے کبھی بنائے ہی نہیں تھے۔

نئے project میں موجود نہ ہونے والے URLs پر روزانہ 1,000 سے زیادہ requests آ رہی تھیں۔ Analytics میں یہ تقریباً صفر engagement کے ساتھ direct traffic کے بڑے spike کی صورت میں نظر آ رہا تھا۔ اسی دوران Yandex crawler پرانے paths پر واپس جا رہا تھا، 404 Not Found حاصل کر رہا تھا، اور Yandex Webmaster میں ایک ہی رات میں 900 سے زیادہ errors جمع ہو گئے۔

میری پہلی explanation سادہ تھی: پرانے bots مردہ URLs کو hit کر رہے ہیں، Yandex اس activity کو دیکھتا ہے اور اس لیے crawl جاری رکھتا ہے۔ میری طرف سے sequence واقعی ایسا ہی نظر آتا تھا۔ لیکن میرا data اس causal relationship کو ثابت کرنے کے لیے کافی نہیں تھا۔

میں حقیقتاً کیا confirm کر سکتا تھا

تین الگ observations تھیں۔ پہلی، server کو ڈومین کی پچھلی زندگی سے متعلق URLs پر بڑی تعداد میں requests مل رہی تھیں۔ دوسری، یہ traffic تقریباً کوئی meaningful user engagement پیدا نہیں کر رہا تھا۔ تیسری، Yandex crawler بھی پرانے paths request کر رہا تھا اور Webmaster dashboard نے ایک ہی رات میں 900 سے زیادہ errors دکھائے۔

Operationally یہ واقعی مسئلہ تھا: noisy logs، غیر ضروری requests اور صاف کرنے کے لیے webmaster report۔ لیکن یہ facts یہ ثابت نہیں کرتے کہ third-party bots نے Yandex crawl کو trigger کیا یا errors نے ranking یا organic traffic کو براہ راست نقصان پہنچایا۔ Crawling indexing نہیں، indexing ranking نہیں، اور error report penalty کا ثبوت نہیں۔

404 اور 410 کے بارے میں میں نے کیا زیادہ simplify کیا تھا

پہلے میں فرق یوں سمجھتا تھا: 404 یعنی “شاید ابھی نہیں ہے”، جبکہ 410 یعنی “ہمیشہ کے لیے ختم ہو گیا”۔ Intuition کے طور پر یہ مفید ہے، مگر technically مکمل درست نہیں۔

404 Not Found کا مطلب ہے کہ server requested resource کا current representation فراہم نہیں کر سکتا؛ status خود یہ نہیں بتاتا کہ حالت temporary ہے یا permanent۔ 410 Gone زیادہ specific ہے: جب server جانتا ہو کہ resource اب دستیاب نہیں اور یہ حالت مستقل متوقع ہے، تب یہ مناسب ہے۔

SEO claims میں بھی یہ precision ضروری ہے۔ Search engines 404 یا 410 return کرنے والے URLs کو search سے ہٹا سکتے ہیں۔ اسی لیے اب میں 410 کو کوئی جادوئی “stronger SEO status” نہیں کہتا اور deleted page کے لیے 404 کو ہمیشہ غلط بھی نہیں سمجھتا۔

پھر بھی میرے case میں targeted 410 کیوں مناسب تھا

پرانے paths temporary failure نہیں تھے۔ وہ ڈومین کے سابق content سے تعلق رکھتے تھے اور نئے project میں ان کی کوئی جگہ نہیں تھی۔ مجھے معلوم تھا کہ یہ مخصوص URLs permanently gone تھے۔ اس لیے 410 Gone ان کی اصل حالت کو صحیح بیان کرتا تھا۔

میں نے ہر unknown URL کو 410 بنانے کے بجائے صرف known legacy paths پر targeted 410 configure کیا۔ اس تبدیلی کے بعد پرانے paths کے گرد crawl اور reporting noise کم ہوا اور webmaster tools کی صورتحال خاصی صاف ہو گئی۔

پھر بھی causality پر میں محتاط ہوں۔ میں کہہ سکتا ہوں کہ improvement targeted 410 کے بعد آئی اور 410 ان URLs کی حالت کے لیے semantically درست تھا۔ میں یہ ثابت نہیں کر سکتا کہ صرف 410 نے ہر bot کو روک دیا۔ کوئی third-party bot HTTP status کا مطلب ignore کر کے ایک ہی path کو مسلسل request کر سکتا ہے۔

اب میری decision rule

صحیح سوال “کیا 410، 404 سے بہتر ہے؟” نہیں، بلکہ “اس URL کے ساتھ حقیقتاً کیا ہوا؟” ہے۔

• واضح replacement موجود ہے: واقعی equivalent نئے URL پر 301 جیسا permanent redirect استعمال کریں۔
• پرانا resource مستقل طور پر ہٹ چکا ہے اور replacement نہیں: 410 Gone precise choice ہے۔
• URL صرف unknown ہے، typo ہے یا کبھی موجود ہی نہیں تھا: عام 404 Not Found مناسب ہے۔

میں صرف errors غائب کرنے کے لیے ہر dead URL کو homepage پر redirect نہیں کروں گا۔ اس سے resource کی حقیقی state چھپ جاتی ہے اور user اور crawler دونوں کے لیے experience خراب ہو سکتا ہے۔

آج میں aged domain کو launch سے پہلے کیسے audit کروں گا

اگر میں دوبارہ history والا domain استعمال کروں تو پرانی website migrate نہ کرنے کے باوجود URL history کو migration کا حصہ سمجھوں گا۔

1. پرانا footprint دیکھیں۔ Launch سے پہلے historical URLs اور واضح legacy sections تلاش کریں۔
2. پہلے دن سے access logs دیکھیں۔ ایسے paths پر repeated requests جنہیں آپ نے کبھی بنایا نہیں، دکھاتے ہیں کہ domain کی external memory ابھی باقی ہے۔
3. Humans، search crawlers اور random bots الگ رکھیں۔ Direct traffic spike اور crawler error الگ signals ہیں؛ انہیں خودکار طور پر ایک 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 میں نہ سمیٹیں۔

یہ اس حالت کے مقابلے میں بہت کم کام ہے جب مسئلہ تب معلوم ہو کہ 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 بھی نہیں۔ درست status crawler کو سمجھنے میں مدد دیتا ہے کہ URL کے ساتھ کیا ہوا، مگر وہ خود نئے site کو بہتر rank نہیں کراتا۔

میرے لیے بچ جانے والا lesson

حیرت اس بات پر نہیں تھی کہ پرانے domain کے پرانے URLs تھے۔ حیرت اس بات پر تھی کہ invisible history launch کے فوراً بعد کتنی تیزی سے واپس نظر آئی: ان صفحات پر روزانہ 1,000 سے زیادہ requests جو میرے پاس تھے ہی نہیں، تقریباً zero engagement، اور Yandex Webmaster میں ایک ہی رات میں 900 سے زیادہ errors۔

Aged domain خالی namespace نہیں۔ Original content ختم ہونے کے سالوں بعد بھی پرانے links، crawlers، scripts اور bots paths یاد رکھ سکتے ہیں۔ میری موجودہ rule سادہ ہے: history audit کریں، reality کے مطابق HTTP status دیں، اور operational bot traffic کو search-engine conclusions سے الگ رکھیں۔

History asset ہو سکتی ہے۔ لیکن وہ state بھی ہے جو آپ inherit کرتے ہیں۔