اختبار صفحات السلاسل المجدولة: تجربة عملية لمنع الروابط المعطلة

الفجوة بين المحتوى المجدول والصفحات التجميعية

الصفحة التجميعية — سلسلة كانت أو أرشيفًا أو صفحة وسم — تُبنى عادةً من حالة النشر، لا من نية النشر. هذا التمييز يبدو بسيطًا حتى نصل إلى اللحظة التي نسبق فيها المحتوى: لدينا مقالات مكتوبة ومُراجعة ولها عنوان وموعد، لكنها لم تصبح متاحة بعد. السؤال الهندسي هنا ليس «كيف نعرض ما لم يُنشر؟» بل «كيف نبني صفحةً يمكن اختبارها اليوم، بينما محتواها لم يوجد بعد على الواجهة العامة؟».

الفجوة تظهر في ثلاثة مواضع مترابطة. في الواجهة، قد يُعرض عنوان بلا هدف قابل للنقر، فيبدو للقارئ كأنه رابط معطّل. في الزحف، قد يجد محرك البحث مسارًا داخليًا إلى صفحة ستعيد 404، فيسجّل رابطًا ميتًا مبكرًا. في البيانات المنظمة، قد نُعلن عن مقال عبر خريطة الموقع أو عبر ترميز Schema بينما صفحته غير موجودة. كل واحدة من هذه المشكلات قابلة للوقاية قبل النشر، بشرط أن نفصل بوضوح بين «الإعلان عن عنوان وتاريخ» و«إتاحة محتوى».

في هذه الدراسة نستعرض ما قيس فعليًا صباح 13 نوفمبر 2026 بتوقيت القاهرة على صفحة سلسلة داخل موقع https://egytag.com/، وتحديدًا المسار https://egytag.com/ar/topics/العلم-والثقة-من-الغموض-إلى-الفهم. السلسلة نموذج اختبار داخل نظام إيجي تاج، والمقال يحاول تحويل ما جرى إلى بروتوكول قابل للتكرار، لا إلى تقرير إنجاز.

الفرضية ومعيار النجاح: ماذا يمكن التحقق منه قبل النشر؟

الفرضية التي بُني عليها الاختبار كانت محددة: صفحة السلسلة يجب أن تكون صالحة للعرض ومقروءة آليًا قبل أن يصبح أي مقال من مقالاتها متاحًا، وأن تعرض عناوين المقالات المجدولة ومواعيدها دون أن تُنشئ أي مسار قابل للنقر يؤدي إلى صفحة غير موجودة. أي أن النجاح ليس «الصفحة تبدو جميلة»، بل «الصفحة تُصدر HTML سليمًا، وتُحمّل أنماطها، وتُصنّف حلقاتها تصنيفًا صحيحًا، ولا تُسرّب روابط».

يمكن صياغة معيار النجاح في نقاط قابلة للقياس:

أما ما لا يمكن التحقق منه قبل النشر فيجب قوله صراحةً: لا يمكن إثبات أن الرابط سيظهر تلقائيًا بعد النشر بمجرد نجاح الاختبار الحالي، ولا يمكن الحكم على التخطيط البصري أو تجربة الموبايل، ولا على أداء التحميل أو ترتيب البحث. هذه كلها تحتاج قياسًا منفصلًا بعد توفر الحالة المنشورة.

تصميم صفحة السلسلة والانتقال من scheduled إلى published

التصميم الذي يجعل الاختبار ممكنًا هو تصميم يمنع الخطأ بنيويًا بدلًا من التحقق منه لاحقًا. الفكرة المركزية: كل حلقة في الصفحة عنصر واحد يحمل حالة صريحة، ويُبنى شكلها من تلك الحالة. الحلقة المنشورة تُرسم كرابط إلى /ar/articles/<slug>، والحلقة المجدولة تُرسم كعنصر غير تفاعلي يعرض العنوان ووقت النشر القادم فقط، بلا href وبلا href="#" بديل.

النمط المضاد الشائع هو وضع رابط شكلي ثم تعطيله بجافاسكربت أو توجيهه إلى صفحة خطأ. هذا ينقل المشكلة إلى طبقة أخرى: محرك البحث قد يرى الرابط في HTML المصدر، والقارئ الذي يستخدم لوحة المفاتيح قد يصل إلى هدف فارغ، ومن يعطّل جافاسكربت يرى رابطًا حيًا إلى 404. الحل الأنظف هو ألا يوجد href أصلًا، وأن يكون العنصر div أو span مع نص بديل يوضح أن المقال مجدول.

الانتقال من مجدول إلى منشور لا يُبنى كحدث لصق يدوي، بل كإعادة اشتقاق من حالة CMS الفعلية عند كل عرض أو عند كل تحديث للكاش. عمليًا هذا يعني أن القالب لا يعرف مواعيد ثابتة، بل يسأل: ما حالة هذه الحلقة الآن؟ ويبني على الجواب. هذا يجعل تأجيل النشر أو تغيير موعده عملية بيانات لا عملية نشر. في حالة السلسلة هنا، المقالات مرتبطة بوتيرة نشر كل ثماني ساعات، لكن ظهور الروابط تلقائيًا بعد النشر لم يكن قد تحقق منه وقت القياس، وهو مصمم ليعمل من الحالة الفعلية لا من افتراض.

بروتوكول الاختبار عبر fetch ومحلل DOM محدود

السكربت المستخدم داخلي في أداة اختبار داخلية غير منشورة ويعمل في بيئة Node.js، ولم يُنشر علنًا. المفيد للقارئ ليس نسخه، بل خطوات بناء ما يشبهه. البروتوكول الذي اتبعناه قابل لإعادة التركيب على أي نظام:

1. اجلب صفحة السلسلة باستخدام fetch مع ترويسة وكيل واضحة، وسجّل رمز الحالة والزمن المستغرق للاستجابة. 2. اجلب ملف الأنماط المشار إليه فعلًا في الصفحة، لا مسارًا مفترضًا. 3. حلّل HTML بمحلل DOM حقيقي (jsdom أو cheerio)، ثم اختر حاويات الحلقات بسمة بيانات ثابتة. 4. صنّف الحلقات حسب حالة كل واحدة، واطلب من السكربت أن يفشل إذا اختلف التصنيف عن مصدر البيانات. 5. افتح كل حلقة مجدولة وابحث داخلها عن أي رابط، لا عن روابط النطاق فقط. 6. اطلب معاينة عامة لمقال مجدول وتوقّع 404، مع التأكد أن جسم الاستجابة لا يحتوي نص المقال. 7. سجّل النتائج كبيانات، لا كرسائل نجاح، حتى يمكن مقارنتها بين تشغيلين.

التحذير المهم: التعبيرات النمطية ليست محلل HTML عامًا. قد تنجح في عدّ سمة بسيطة، لكنها تنهار أمام التداخل والتعليقات والترميز والسمات متعددة الأسطر. استخدام regex المشروط يكون في فحص ضيق جدًا، مثل التأكد من غياب نمط href="/ar/articles/ من جزء محدد بعد استخراجه بالمحلل.

// Requires Node.js 20+ and: npm install jsdom
const { JSDOM } = require('jsdom');
const seriesUrl = 'https://egytag.com/ar/topics/العلم-والثقة-من-الغموض-إلى-الفهم';
const res = await fetch(seriesUrl);
const doc = new JSDOM(await res.text()).window.document;
const cards = [...doc.querySelectorAll('.topic-series__item')];
const scheduled = cards.filter(card => card.classList.contains('is-scheduled'));
const leaked = scheduled.filter(card => card.querySelector('a[href]'));
console.log({status:res.status, total:cards.length, scheduled:scheduled.length,
  leakedLinks:leaked.length});
if (res.status !== 200 || cards.length !== 9 || leaked.length) process.exitCode = 1;

المثال توضيحي للبنية وليس نقلًا حرفيًا للسكربت الداخلي؛ أسماء السمات فيه افتراضية ويجب مطابقتها لما يصدره قالبك فعلًا.

النتائج المرصودة صباح 13 نوفمبر 2026

ما رُصد في ذلك التشغيل محدد ولا يتجاوزه:

التفسير الحذر لهذه النتائج: نجاح 15/15 يخص وحدات متنوعة، وليس برهانًا على صحة الموقع كله؛ إنه دليل على أن قواعد تلك الوحدات تعمل في بيئة الاختبار. والعدد 9/9 مجدولة و 0 منشورة يعني أن الصفحة كانت في أكثر حالاتها حساسية: تعرض معلومات كاملة عن محتوى غير متاح، وهذا بالضبط الوضع الذي تُختبر فيه سلامة الروابط.

سيناريوهات تغيير الوقت والتسلسل وإلغاء النشر

الحالة الساكنة لا تكفي. القيمة الحقيقية للاختبار تظهر عند تغيّر البيانات، وهذه سيناريوهات يجب تغطيتها بضوابط محددة:

الضوابط المصاحبة مهمة بقدر السيناريوهات: ثبّت الساعة في بيئة الاختبار بدل الانتظار، واستخدم بيانات تجريبية معزولة، واجعل التشغيل قابلًا للتكرار دون آثار جانبية، وسجّل الحالة الفعلية من CMS قبل الحكم، ولا تعدّل قاعدة البيانات يدويًا لتجاوز آلة الحالة، لأن ذلك يلغي ما تحاول اختباره.

سلامة الروابط والبيانات المنظمة وال ـSEO

القاعدة التي ثبتت هنا هي الفصل بين إعلان التوفر وإتاحة المحتوى. عنوان المقال وموعده يمكن أن يظهرا في صفحة السلسلة، بينما يبقى مسار /ar/articles/<slug> مغلقًا حتى النشر. هذا الفصل يجب أن يمتد إلى ما هو أبعد من الواجهة:

ما لا يكشفه الاختبار الآلي

الاختبار الذي أُجري يثبت بنية HTML وحالة الروابط، ولا يثبت التجربة. هناك فجوات يجب الاعتراف بها صراحةً: التخطيط عند عرض 360 بكسل، وانكسار العناوين العربية الطويلة داخل بطاقة الحلقة، وترتيب التركيز بلوحة المفاتيح، وإعلان حالة «مجدول» لقارئ الشاشة، وتنسيق التاريخ حسب إعدادات القارئ، وسلوك الصفحة عند تعطيل جافاسكربت، والفرق بين ما يصدره الخادم وما يعرضه المتصفح بعد الترطيب.

هذه لا تُغطى إلا باختبار عرض بصري بمصفوفة أجهزة، ومقارنة لقطات، ومراجعة وصولية يدوية، ثم قياس أداء لاحق بأدوات الميدان والمختبر. غياب هذه الخطوات في تجربتنا يعني أن النتيجة الحالية جزئية بطبعها، وأن وصفها بأنها «نجاح كامل» سيكون تضليلًا.

خاتمة: مبدأ قابل للنقل

الدليل المتاح اليوم يقول إن صفحة سلسلة يمكن أن تعرض تسع حلقات مجدولة، بعناوينها ومواعيدها، وتظل خالية من أي رابط معطّل، وأن معاينة المقال قبل موعده تعيد 404 كما صُممت. ويقول أيضًا إن الانتقال التلقائي بعد النشر لم يُثبت بعد، وإن الجانب البصري والأداء خارج نطاق ما قيس. هذا توازن ضروري: نعرف ما تحقق، ونعرف ما بقي.

المبدأ نفسه لا يرتبط بنظام بعينه، بل ينطبق على أي نظام إدارة محتوى: اشتق الإتاحة من الحالة، لا تُصدر رابطًا لا هدف له، اختبر الحالات السلبية قبل الإيجابية، واعتبر 404 قبل النشر عقدًا مكتوبًا لا خطأً. من يبني اختبارًا صغيرًا حول هذه الأفكار يحصل على أمان أكبر من أي قائمة تحقق تُملأ يدويًا.