اشتريت دومينًا سُجِّل لأول مرة عام 2000. على الورق، بدا هذا التاريخ الطويل ميزة أكثر منه مشكلة. لكن بعد إطلاق الموقع الجديد بدأت سجلات الخادم تمتلئ بطلبات لصفحات لم أنشئها أصلًا.
كانت روابط لا وجود لها في المشروع الجديد تتلقى أكثر من 1,000 طلب يوميًا. وفي analytics ظهر ذلك كقفزة كبيرة في direct traffic مع engagement يكاد يكون معدومًا. وفي الوقت نفسه كان crawler الخاص بـ Yandex يعيد زيارة مسارات قديمة ويحصل على 404 Not Found، بينما تراكم في Yandex Webmaster أكثر من 900 خطأ خلال ليلة واحدة.
كان تفسيري الأول بسيطًا: البوتات القديمة تضرب الروابط الميتة، وYandex يرى هذا النشاط، ولذلك يواصل crawl لهذه الروابط. هكذا بدا تسلسل الأحداث من جهتي. لكن بياناتي لم تكن كافية لإثبات هذه العلاقة السببية.
ما استطعت تأكيده فعلًا
كانت لدي ثلاث ملاحظات منفصلة. أولًا، الخادم كان يستقبل عددًا كبيرًا من الطلبات لروابط تعود إلى الحياة السابقة للدومين. ثانيًا، هذا الترافيك لم يتحول تقريبًا إلى تفاعل حقيقي من المستخدمين. ثالثًا، crawler الخاص بـ Yandex كان يطلب بدوره مسارات قديمة، وسجّل Webmaster أكثر من 900 خطأ في ليلة واحدة.
من ناحية التشغيل، كانت هذه مشكلة حقيقية: سجلات مليئة بالضجيج، وطلبات غير ضرورية، وتقارير أخطاء تحتاج إلى تنظيف. لكن هذه الحقائق لا تثبت أن بوتات الطرف الثالث هي التي دفعت Yandex إلى crawl تلك الروابط، ولا أن الأخطاء أضرّت مباشرة بالـ ranking أو organic traffic. Crawling ليس indexing، وindexing ليس ranking، وتقرير الأخطاء ليس دليلًا على penalty.
ما كنت أبسّطه أكثر من اللازم في 404 و410
كنت أفكر سابقًا بهذه الطريقة: 404 يعني «ربما الصفحة غير موجودة مؤقتًا»، بينما 410 يعني «اختفت نهائيًا». هذا مفيد كفكرة مبسطة، لكنه ليس دقيقًا تقنيًا.
404 Not Found يعني أن الخادم لا يستطيع توفير representation حالي للـ resource المطلوب؛ والكود وحده لا يحدد إن كان الوضع مؤقتًا أم دائمًا. أما 410 Gone فهو أكثر تحديدًا: يناسب الحالة التي يعرف فيها الخادم أن الـ resource لم يعد متاحًا وأن هذا الوضع متوقع أن يكون دائمًا.
وهذه الدقة مهمة أيضًا عند الحديث عن SEO. يمكن لمحركات البحث إزالة روابط تعيد 404 أو 410. لذلك لم أعد أصف 410 بأنه status «أقوى للـ SEO» بطريقة سحرية، ولا أعتبر 404 خطأ لكل صفحة محذوفة.
لماذا ظل 410 الموجّه منطقيًا في حالتي
المسارات القديمة لم تكن عطلًا مؤقتًا. كانت تعود إلى محتوى سابق على الدومين ولم يكن لها مكان في المشروع الجديد. كنت أعرف أن هذه الروابط المحددة اختفت بشكل دائم. لذلك كان 410 Gone وصفًا دقيقًا لحالتها.
لهذا ضبطت 410 فقط للمسارات القديمة المعروفة، بدل تحويل كل URL غير معروف إلى 410. بعد هذا التغيير انخفض ضجيج الـ crawl والتقارير حول تلك المسارات، وأصبحت حالة أدوات مشرفي المواقع أنظف بكثير.
ومع ذلك أبقى حذرًا في الحديث عن السببية. أستطيع القول إن التحسن جاء بعد هذا التغيير، وإن 410 كان يعبر بدقة عن حالة الروابط. لكنني لا أستطيع إثبات أن 410 وحده أوقف كل البوتات. أي بوت خارجي يمكنه تجاهل معنى HTTP status والاستمرار في طلب المسار نفسه بلا نهاية.
قاعدة القرار التي أستخدمها الآن
السؤال المفيد ليس «هل 410 أفضل من 404؟»، بل «ماذا حدث فعلًا لهذا URL؟»
- هناك بديل واضح: استخدم permanent redirect مثل
301إلى الرابط الجديد المكافئ فعلًا. - الـ resource القديم حُذف نهائيًا ولا يوجد بديل:
410 Goneاختيار دقيق. - الرابط غير معروف أو مكتوب خطأ أو لم يوجد أصلًا:
404 Not Foundعادي هو الأنسب.
ما أتجنبه هو إعادة توجيه كل رابط ميت إلى الصفحة الرئيسية فقط لإخفاء الأخطاء. هذا يخفي الحالة الحقيقية للـ resource وقد يجعل التجربة أسوأ للمستخدم ولـ crawler معًا.
كيف سأراجع دومينًا قديمًا قبل الإطلاق اليوم
إذا استخدمت دومينًا ذا تاريخ مرة أخرى، فسأتعامل مع تاريخ روابطه كجزء من migration حتى لو لم أكن أنقل الموقع القديم نفسه.
- افحص البصمة القديمة. ابحث قبل الإطلاق عن historical URL وعن أقسام legacy الواضحة.
- راقب access logs من اليوم الأول. الطلبات المتكررة لمسارات لم تنشئها دليل على أن الدومين ما زال محفوظًا في ذاكرة أنظمة خارجية.
- افصل بين البشر وsearch crawlers والبوتات العشوائية. قفزة direct traffic وخطأ crawler إشارتان مختلفتان، ولا ينبغي دمجهما تلقائيًا في قصة سببية واحدة.
- صنّف الروابط الميتة المتكررة. لكل pattern مهم، قرر بوضوح إن كان الصحيح 301 أو 404 أو 410.
- راقب النتائج كلٌ على حدة. تكرار الطلبات وتقارير crawler وindexing أبعاد مختلفة؛ لا أحولها إلى مؤشر مبهم واحد اسمه «SEO health».
هذا جهد صغير مقارنة باكتشاف المشكلة بعد أن تكون السجلات وأدوات مشرفي المواقع قد امتلأت بالضجيج.
ما الذي لا يحله 410
410 هو تصريح HTTP عن حالة resource. ليس firewall ولا rate limiter ولا آلية لحظر البوتات. إذا واصل scraper إرسال الطلبات بعد تلقي 410، فما زال على الخادم استقبالها والرد عليها. وإذا كانت المشكلة الحقيقية هي حجم طلبات مسيء، فهذه مشكلة بنية تحتية منفصلة.
وهو أيضًا ليس SEO boost. إعادة status الصحيح تساعد crawler على فهم ما حدث للـ URL، لكنها لا تجعل الموقع الجديد يرتفع في الترتيب من تلقاء نفسها.
الدرس الذي بقي معي
المفاجأة لم تكن أن للدومين القديم روابط قديمة. المفاجأة كانت سرعة عودة هذا التاريخ غير المرئي بعد الإطلاق: أكثر من 1,000 طلب يوميًا لصفحات لا أملكها، engagement شبه معدوم، وأكثر من 900 خطأ في Yandex Webmaster خلال ليلة واحدة.
الدومين القديم ليس namespace فارغًا. الروابط القديمة وcrawlers والـ scripts والبوتات قد تتذكر مسارات بعد سنوات من اختفاء المحتوى الأصلي. قاعدتي الآن بسيطة: راجع التاريخ، أعد HTTP status الذي يطابق الواقع، وافصل bot traffic التشغيلي عن الاستنتاجات المتعلقة بمحركات البحث.
التاريخ قد يكون أصلًا ذا قيمة. لكنه أيضًا state ترثه.