نشرت تحديثًا لملف sitemap يضم نحو 3000 صفحة جديدة تحت المسار /en/blog/.... وبعد ذلك بفترة قصيرة ظهر نمط غير متوقع في Yandex Webmaster: كان Yandex يحاول الزحف إلى المسارات المقابلة تحت /blog/...، أي من دون البادئة /en.
لو كانت هذه الروابط تعيد 404 مباشرة، لكان من الممكن أن تتحول آلاف محاولات الزحف إلى طلبات عديمة الفائدة نحو مسارات غير موجودة. لحسن الحظ، كنت قد أعددت مسبقًا تحويلات 308 دائمة من المسارات التي لا تحتوي على بادئة اللغة إلى روابط النسخة الإنجليزية الصحيحة.
هذه الطبقة الصغيرة من التوجيه الدفاعي كانت أكثر فائدة مما توقعت.
ما الذي رأيته فعليًا؟
- نشرت sitemap يحتوي على نحو 3000 صفحة جديدة ببنية
/en/blog/.... - بعد ذلك أظهر Yandex Webmaster أن Yandex يحاول الزحف إلى روابط مقابلة من نوع
/blog/.... - كانت هذه المسارات البديلة مشمولة أصلًا بتحويلات 308.
- وبدل أن تنتهي الطلبات عند 404، تم توجيهها إلى روابط
/en/blog/...المقصودة.
هناك تصحيح مهم لطريقة وصفي للحادثة في النسخة الأصلية: لا أستطيع إثبات أن Yandex «فسّر ملف sitemap بشكل خاطئ». لقد رأيت المسارات غير المتوقعة بعد تحديث sitemap، لكن الترتيب الزمني وحده لا يثبت السبب الداخلي. يمكن لمحركات البحث اكتشاف الروابط من إشارات ومصادر تاريخية متعددة. لذلك، من دون دليل أقوى، الصياغة الدقيقة هي ببساطة أن Yandex زحف إلى مسارات لم أكن أتوقعها.
هذا الفرق مهم. طلب crawler لرابط غريب هو ملاحظة مباشرة. أما تفسير سبب اختياره لهذا الرابط تحديدًا فهو ادعاء منفصل.
لماذا كانت تحويلات 308 مفيدة؟
منطق التحويل لدي كان يتعامل مع المسار الأقصر كاسم بديل دائم للرابط المترجم:
/blog/example-post -> 308 -> /en/blog/example-postوبذلك، حتى عندما يصل crawler من رابط غير متوقع، فإنه يصل في النهاية إلى الصفحة التي أردت تقديمها فعليًا.
308 Permanent Redirect هو تحويل HTTP دائم يحافظ على طريقة الطلب ومحتواه. في طلبات GET العادية التي تستخدمها برامج الزحف، الحفاظ على الطريقة ليس عادة الجزء الأهم؛ ما كان يهمني هنا هو أن التحويل دائم بشكل صريح. وتُصنّف وثائق Yandex Webmaster الحالية كلًا من 301 و308 كتحويلات دائمة.
وثائق Yandex Webmaster الرسمية حول عمليات إعادة التوجيه.
هذا لا يعني أن 308 أفضل تلقائيًا من 301 من ناحية SEO. في حالتي كانت تحويلات 308 موجودة أصلًا، وقد أدت المهمة المطلوبة: الرابط غير المتوقع لم يتحول إلى طريق مسدود.
التحويل شبكة أمان، وليس إصلاحًا لملف sitemap
قللت التحويلات من أثر المشكلة، لكنها لم تجعل الزحف غير الضروري شيئًا مرغوبًا. كل تحويل زائد يعني طلبًا إضافيًا وقفزة إضافية. كما أن قاعدة تحويل واسعة أكثر من اللازم قد تخفي أخطاء توليد الروابط إذا توقفت عن البحث عن مصدر العناوين غير الصحيحة.
إذا كان ملف sitemap نفسه يحتوي على روابط قديمة أو روابط تقوم بالتحويل، فالحل الصحيح هو إصلاح sitemap ووضع الروابط النهائية فيه. وظيفة التحويلات هي حماية المسارات القديمة أو البديلة أو التي اكتُشفت بالصدفة، لا تبرير بيانات روابط غير دقيقة.
في حالتي كان sitemap يحتوي بالفعل على /en/blog/.... التحويلات جعلت الموقع فقط أكثر تحمّلًا عندما يصل crawler عبر /blog/....
ما الذي أتحقق منه الآن بعد حادثة كهذه؟
- فتح ملف sitemap المنشور فعليًا. لا أعتمد على كود التوليد فقط، بل أفحص الملف النهائي وعينة من الروابط.
- فحص الاستجابة النهائية. الروابط المراد فهرستها يُفضّل أن تصل مباشرة إلى الصفحة المقصودة من دون سلاسل تحويل غير ضرورية.
- اختبار المسارات البديلة المتوقعة. إذا كان لرابط قديم أو من دون بادئة وجهة دائمة، فيجب أن يكون الربط مباشرًا وواضحًا واحدًا لواحد.
- تجنب سلاسل التحويل.
A -> B -> Cأصعب في التحقق منA -> C. - مقارنة تقارير crawler ببيانات الخادم عندما يكون ذلك ممكنًا. أدوات Webmaster مفيدة، لكنها لا تشرح دائمًا من أين اكتُشف الرابط أول مرة.
- عدم استنتاج الترتيب من الزحف وحده. الزحف والفهرسة والترتيب والزيارات مراحل مختلفة.
curl -I https://example.com/blog/example-post
HTTP/2 308
location: https://example.com/en/blog/example-postهذا مثال توضيحي فقط. الفكرة هي التحقق من status والوجهة الفعلية بدل افتراض أن قاعدة التوجيه تعمل.
ما الذي أستطيع تأكيده وما الذي لا أستطيع؟
أستطيع تأكيد أن تحويلات 308 الموجودة مسبقًا منعت طلبات /blog/... غير المتوقعة من الانتهاء بـ404 وأرسلتها إلى الروابط المقصودة.
لا أستطيع تأكيد أن parser الخاص بـ sitemap لدى Yandex كان السبب. كما أنني لم أقس تحسنًا في الترتيب أو الفهرسة، ولم أحدد مقدارًا معينًا من الزيارات «التي تم إنقاذها». القول بذلك سيكون أقوى من الأدلة التي أملكها.
الدرس الذي بقي معي أضيق لكنه أكثر فائدة: يجب أن تتحمل بنية الروابط الأخطاء المتوقعة عند حدود النظام. sitemap نظيف هو خط الدفاع الأول، وطبقة دقيقة من التحويلات الدائمة هي الخط الثاني.
عندما يتوفر الاثنان، تقل كثيرًا فرصة تحول مسار crawler غير متوقع إلى آلاف الروابط الميتة.