اللفة الثانية: ماذا يحدث عندما تقوم بتحسين المحتوى نفسه مرتين
أقوم بتشغيل عملية أتمتة تعمل على تحسين صفحات الحاسبات كل مساء. تقوم هذه العملية بإضافة معايير مرجعية موثقة، وأمثلة محلولة، وروابط داخلية. وقد أجرت 43 عملية إرسال (commits) حتى الآن.
هذا الأسبوع، دخلت الأتمتة في "لفة ثانية". حيث أعادت زيارة ثلاث صفحات كانت قد حسنتها بالفعل:
• حاسبة نسبة السعر إلى الربحية (P/E Ratio) (تم تحسينها مرتين، بفاصل 34 يومًا) • حاسبة تقييم الشركات البرمجية (SaaS Valuation) (تم تحسينها مرتين، بفاصل 35 يومًا) • حاسبة القيمة الدفترية (Book Value) (تم تحسينها مرتين، بفاصل 37 يومًا)
أردت أن أرى ما إذا كانت جولة ثانية من التحسينات ستحدث فرقًا ملموسًا. كانت النتائج بمثابة مواجهة مع الواقع.
تُظهر البيانات من Google Search Console الحقيقة:
• نسبة السعر إلى الربحية (P/E Ratio): 711 ظهورًا، نقرتان • تقييم الشركات البرمجية (SaaS Valuation): 17 ظهورًا، 0 نقرات • القيمة الدفترية (Book Value): 0 ظهور، 0 نقرات
المحتوى الآن أفضل؛ فهو يحتوي على أوصاف ميتا (meta descriptions) محددة ومعايير مرجعية دقيقة. لكن المحتوى الأفضل لم يغير تقييم Google لسلطة الصفحة (page authority).
تقوم الأتمتة بتحسين المحتوى، لكنها لا تستطيع تغيير نظرة Google لمستوى موثوقية النطاق (domain) بشكل فوري. لا تزال الصفحات المحسنة تقبع بالقرب من أسفل نتائج البحث.
وفي الوقت نفسه، الصفحات التي لم تلمسها الأتمتة أبدًا هي التي تحقق الفوز.
ارتفع مولد أوامر الشراء 8 مراكز في أسبوع واحد، وحصل على 20 نقرة. كما حصلت حاسبة الانطباعات على 1,041 ظهورًا و10 نقرات. لم تكن أي من هاتين الصفحتين ضمن قائمة انتظار الأتمتة قط.
هذا يخلق فجوة هائلة. الصفحات التي تحقق أفضل أداء هي تلك التي لم ألمسها. أما الصفحات التي أعمل عليها بكثافة، فهي بالكاد تحصل على أي زيارات.
لماذا يحدث هذا؟
- السلطة (Authority): قد تهيمن عمالقة الإعلام المالي على مجالات P/E وSaaS. لا يمكن لأي كمية من المحتوى أن تهزم موثوقية النطاق الراسخة لديهم.
- القصد (Intent): قد تقوم الأتمتة بتحسين محتوى لا يتوافق مع الطريقة التي يبحث بها الناس فعليًا.
- المنافسة (Competition): قد تستهدف الصفحات التي لم تُلمس مساحات استعلام أقل ازدحامًا.
لن أوقف الأتمتة. سأضع نقطة تفتيش في 21 يوليو. سأتحقق من البيانات مرة أخرى خلال أربعة أسابيع. إذا أدت الجولة الثانية إلى تحريك التصنيفات، فسأقوم بالإبلاغ عن ذلك. وإذا لم يحدث ذلك، فسأدرك أن تكرار الشيء مرتين ليس حلاً لضعف السلطة (authority).
هل تقوم ببناء SEO برمجِي (programmatic SEO)؟ هل واجهت طريقًا مسدودًا حيث يؤدي المحتوى الجيد إلى تصنيفات سيئة؟ دعونا نتبادل الآراء في التعليقات.
الجولة الثانية: تحسين ثلاث آلات حاسبة مرتين — إليكم ما تركه المسار الأول
عندما تبدأ في بناء شيء ما، يكون الدافع الأول هو جعله يعمل. في البرمجة، هذا هو "المسار الأول": اجعل الوظائف تعمل، بغض النظر عن مدى فوضوية الكود. ولكن بمجرد أن يعمل، تدرك أن الكود الذي كتبته ليس بالضرورة الكود الذي تود الاستمرار في التعامل معه.
في هذه الرحلة، قمت ببناء ثلاث آلات حاسبة مختلفة. مررت بكل واحدة منها بمرحلتين من التحسين، واليوم، أود أن أشارككم ما تركه المسار الأول خلفه.
المسار الأول: جعله يعمل
خلال المسار الأول، كان تركيزي منصباً بالكامل على الوظائف (Functionality). هل يمكن للآلة الحاسبة أن تجمع؟ نعم. هل يمكنها الطرح؟ نعم. هل يمكنها التعامل مع الجذور التربيعية؟ نعم.
كان الكود في هذه المرحلة:
- مزدحماً: الكثير من المنطق محشور داخل دوال ضخمة واحدة.
- غير مرن: إضافة ميزة جديدة كانت تتطلب تعديل أجزاء متعددة من قاعدة الكود.
- هشاً: كان يفتقر إلى المعالجة الصحيحة للحالات الحدية (edge cases) مثل القسمة على صفر أو المدخلات غير الصالحة.
كان الهدف هو إثبات المفهوم (Proof of Concept)، ولكن النتيجة كانت ديناً تقنياً (technical debt) كبيراً.
المسار الثاني: جعله أفضل
بمجرد حصولي على نسخة تعمل، بدأت "المسار الثاني". هذه المرة، لم يكن السؤال "هل يعمل؟" بل "كيف تم بناؤه؟".
في هذه المرحلة، ركزت على:
- إعادة هيكلة الكود (Refactoring): تقسيم الدوال الكبيرة إلى وحدات أصغر ذات مسؤولية واحدة.
- فصل الاهتمامات (Separation of Concerns): فك الارتباط بين منطق الحساب وواجهة المستخدم.
- المتانة (Robustness): تنفيذ عمليات تحقق صارمة ومعالجة للأخطاء في الحالات الحدية.
ما الذي تركه المسار الأول خلفه؟
بعد الانتهاء من المسار الثاني، أدركت أن المسار الأول لم يكن "خاطئاً" — بل كان ضرورياً. ومع ذلك، فقد ترك خلفه عدة تحديات:
- تعقيد غير ضروري: الكود الذي يعمل بسرعة في البداية قد يصبح عبئاً مع توسع المشروع.
- صعوبات في الاختبار: عندما يكون المنطق مترابطاً بشكل وثيق، تصبح كتابة اختبارات الوحدة (unit tests) كابوساً.
- نقص الوضوح: الكود الذي يركز فقط على المخرجات غالباً ما يفتقر إلى التوثيق الذاتي وسهولة القراءة.
الخلاصة
البرمجة هي عملية تكرارية. يمنحك المسار الأول الثقة بأن فكرتك قابلة للتنفيذ، بينما يمنحك المسار الثاني الأساس الذي يمكنك البناء عليه. لا تخشَ كتابة كود "فوضوي" في البداية، طالما أنك تملك الانضباط للعودة وتحسينه في الجولة التالية.