السجلات تخفّض موقعًا من 16M إلى 730K صفحة

تسجّل سجلات الخادم ما طلبه Googlebot فعلًا، لا ما تخمّنه محاكاة زاحف. ونشرت JetOctopus، مزوّد تحليل السجلات والزحف، ثلاث دراسات حالة قصيرة من هذه البيانات في مقالة واحدة كتبها Serge Bezborodov بتاريخ 27 مايو 2020.

تتناول هذه المادة الحالة الأكبر تغيّرًا مقيسًا، وتبيّن ما لا تقوله المقالة.

ماذا أظهرت السجلات؟#

كان للموقع أكثر من 16 مليون صفحة و342,000 زيارة شهريًا. جزء منه يظهر في أعلى النتائج، وجزء آخر لم يُفهرس أشهرًا، وهي صفحات ذات صلة ومربحة لا قديمة.

زحفت JetOctopus 2 مليون صفحة ووجدت في كل منها نحو 900 رابط داخلي، وقدّرت العدد الكلي بنحو 16 مليون صفحة، ثم أوقفت الزحف لتفهم سبب ضخامة الموقع.

وحلّلت السجلات فوجدت Googlebot ينفق موارده على صفحات تحمل وسوم rel=canonical، لأن الموقع وضع canonical أو canonical ذاتيًا على كل عنصر في كل فئة وصفحة تصفية وتقسيم.

والدرس الذي تستخلصه المقالة أن وسم canonical لا يوقف الزحف. فعلى Googlebot أن يجلب عنوان URL ليقرأ الوسم، فتظل ملايين نسخ التصفية والفرز الموسومة بـ canonical تكلّف طلبات زحف.

ماذا تغيّر وبأي نتيجة؟#

كانت التوصية إغلاق تركيبات الفئة والتصفية وتقسيم الصفحات والفرز التي ولّدت معًا معظم تلك الصفحات. ونتيجة المصدر المعلنة أن حجم الموقع تقلّص إلى 730,000 صفحة ليزحف البرنامج إلى الصفحات الأكثر ربحًا.

وهذا خفض في عدد الصفحات بنحو 95%. ولا تذكر المقالة أعداد طلبات الزحف ولا الصفحات المفهرسة ولا الزيارات بعد التغيير، ولا مدة زمنية، فنذكر تغيّر عدد الصفحات فقط.

هل كان robots.txt الحل؟#

ليس لهذا الموقع. فالتوصية تقول “أغلق” التركيبات دون تسمية الآلية.

لكن خلاصة المقالة تناقش المقايضات: توصي Google بـ noindex بدل الحظر، لكن في متاجر التجارة الإلكترونية الضخمة يبقى الزاحف منفقًا ميزانية الزحف على جلب الصفحة ليقرأ التوجيه، بينما قد يوقف robots.txt زحف أقسام كاملة.

ماذا تقول وثائق Google؟#

دليل ميزانية الزحف الحالي لدى Google موجّه للمواقع الكبيرة التي فيها مليون صفحة فريدة أو أكثر وتتغير أسبوعيًا تقريبًا، وللمواقع المتوسطة التي فيها 10,000 صفحة أو أكثر وتتغير يوميًا، وللمواقع التي تعلق فيها عناوين URL كثيرة بحالة “Discovered - currently not indexed”.

وكتالوج من 16 مليون صفحة داخل هذا النطاق تمامًا.

وفي مسألة noindex صار الدليل صريحًا. فهو يقول ألا تستخدمه لهذا الغرض، لأن Google ستطلب الصفحة ثم تسقطها، فيضيع وقت الزحف.

ويوصي بدمج المحتوى المكرر وحظر زحف عناوين URL غير المرغوب في زحفها بـ robots.txt، ويضيف ألا يُستخدم robots.txt لإعادة توزيع ميزانية الزحف مؤقتًا. وتغطي ملاحظتنا البحثية عن noindex وميزانية الزحف هذا التوجيه بالتفصيل.

ماذا في الحالتين الأخريين؟#

في سوق فيه 226,000 صفحة و4 ملايين زيارة شهريًا، مُنعت عناوين التصفية بقاعدة Disallow: /*? ومع ذلك بقيت نسخ مكررة في فهرس Google. والسبب قاعدة Allow: /product متعارضة تطابق عناوين URL نفسها.

وتشرح وثائق robots.txt لدى Google المنطق: تستخدم برامج الزحف القاعدة الأكثر تحديدًا بطول المسار، وحين تتعارض القواعد تأخذ Google بالأقل تقييدًا. ونصحت JetOctopus باختبار التوجيهات بأداة تحقق قبل نشرها، لأن قواعد كل محرك بحث قد تختلف.

وفي موقع عقاري فيه أكثر من مليون صفحة و4.5 مليون زيارة شهريًا، أظهرت السجلات 38 مليون طلب من Googlebot في شهر، ذهب منها 23.5 مليونًا إلى محتوى AJAX، أي نحو 62% من الإجمالي.

وتلاحظ المقالة أن Google حين تعرض محتوى يُحمَّل بطلبات XHR POST يُحسب كل طلب فرعي من ميزانية الزحف. وكان الإصلاح الموصى به حظر AJAX عديم القيمة في robots.txt، مع تحذير من أن الحظر المتسرّع قد يحجب محتوى تحتاجه الصفحة. ولا تذكر أي من الحالتين رقمًا بعد التغيير.

ماذا تفحص في سجلاتك؟#

• حصة طلبات Googlebot الذاهبة إلى عناوين المعاملات والتصفية والفرز والتقسيم مقابل الصفحات القابلة للفهرسة.
• هل ما زالت النسخ الموسومة بـ canonical تُجلب بكثافة، أي أن الوسم لا يوفر زحفًا.
• أي قاعدة Allow في robots.txt تتداخل مع نمط Disallow، واختبر عناوين نموذجية بـ أداة اختبار robots.txt.
• الطلبات إلى نقاط AJAX وAPI التي تعيد أجزاء لا صفحات.

تبيع JetOctopus أداة تحليل السجلات المستخدمة هنا ولا تسمّي عميلًا، فتعامل مع الحالات الثلاث كلها عرضًا من JetOctopus نفسها.