نرى كثيرًا عبارة «أنظمة SEO بنحو عشرة وكلاء». وإذا نظرنا إلى ما تفعله فعلًا، وجدنا أن معظمها يقرأ البيانات وينتج قائمة توصيات ثم يتوقف عند هذا الحد. لا يكتب شيئًا على الموقع. والأهم أنه لا يقيس ما حدث بعد ذلك.
بنيت لنفسي نظام autopilot خاصًا بـ SEO، وأسميته Cortex. يعمل كل يوم على خادم، حتى عندما يكون حاسوبي مطفأً. أكثر ما استغرق مني وقتًا ليس جزء «الوكلاء». إنه الحلقة: الرصد، ثم التنفيذ، ثم التحقق، ثم القياس، ثم القدرة على القول هل أفاد الإجراء بشيء.
إليك الخطوات لبناء نظام من هذا النوع، وما انكسر عندي وكيف أصلحته. لا أذكر أي رقم مأخوذ من سجلي الداخلي: ما أرويه تجربة معاشة وليس قياسًا. والوقائع الرقمية الوحيدة مصدرها وثائق Google.
أهم النقاط
الـ autopilot المفيد في SEO يغلق الحلقة: يرصد، وينفذ على الموقع، ويعيد التحقق مباشرة على الإنترنت، ثم يقيس قبل التنفيذ وبعده. وبدون كتابة وقياس يصبح مجرد لوحة متابعة فيها اقتراحات.
مراجع مستقل عن الكاتب، يرفض كثيرًا، أفضل من رقابة متساهلة. عندي منع سعرًا مضللًا قبل النشر.
بحسب وثائق Google، قد يستغرق احتساب تغيير الـ title «من بضعة أيام إلى بضعة أسابيع»، ويجب أن تراعي نافذة القياس ذلك.
الصفحة المعدَّلة أثناء القياس يجب أن «ترتاح»، وإلا اختلط الأثر. وسجل التعديلات اليدوية يمنع النظام من محو عمل الإنسان.
تتضخم التكاليف بسرعة إذا كان كل استدعاء يعيد تحميل سياق الأداة كاملًا: حدّد ميزانية لكل تشغيل، واحسبها وسجّلها.
ما الذي يفصل autopilot عن التقرير الآلي
التقرير الآلي يجيب عن سؤال «ما الذي لا يسير كما ينبغي؟». أما الـ autopilot فيجيب عن ثلاثة أسئلة إضافية: ماذا نغيّر، وهل التغيير آمن، وهل نجح.
الأخير هو السؤال الذي يُتجاوز أكثر من غيره. ومع ذلك، بدونه لا نعرف هل يحسّن النظام شيئًا أم أنه يتحرك فقط. انطلقت من هذه الفكرة: إجراء بلا قياس قبله وبعده ليس إجراء SEO، بل مراهنة.
تتلخص بنيتي في سلسلة واحدة. مهمة يومية على خادم تقوم بالرصد (Search Console وPageSpeed والفهرسة). ثم مرحلة تحقيق تتعمق فيما برز. بعدها يمر وكيل تنفيذ لكل موقع بالمراحل التالية: الخطة، الكاتب، الفحوص الآلية، المراجع المستقل، النسخة الاحتياطية، الكتابة، إعادة التحقق مباشرة، والتراجع الآلي إذا فشل الفحص. يُسجَّل كل إجراء في سجل. ويقارن القياس الأيام الـ 28 السابقة بالأيام الـ 28 اللاحقة. وفي الصباح أتلقى موجزًا فيه قرار واحد فقط عليّ اتخاذه.
الخطوة 1: بيانات موثوقة، وحدودها
كل شيء ينطلق من Search Console. وبعض نقاط الوثائق تغيّر طريقة بناء الرصد.
أولًا الموضع. بحسب مساعدة Search Console حول تقرير الأداء، الموضع المعروض هو الأعلى الذي يشغله رابط من موقعك، ويُحسب متوسطه على الاستعلامات المعنية، أما CTR فهو نسبة النقرات إلى مرات الظهور. لذلك فالموضع المتوسط ليس ترتيبًا ثابتًا، ويجب قراءته بحذر.
ثم الحداثة والحجم. تشير وثائق Search Analytics API إلى أن البيانات تتوفر عادة بعد يومين أو ثلاثة، وأن الـ API يعرض 50 000 سطر كحد أقصى في اليوم لكل نوع بحث، وأن النتائج تُستعرض بالتصفح على دفعات من 25 000 سطر. وتوضح أيضًا أن النظام قد يتخلى عن بعض البيانات عند التجميع حسب الصفحة والاستعلام، وأن الحصول على إجماليات دقيقة يتطلب إزالة هذين البعدين. والنتيجة العملية: لا تقارن أبدًا إجماليًا دقيقًا بمجموع أسطر، ولا تقس على الأيام الثلاثة الأخيرة.
وبالنسبة للفهرسة، يعطي URL Inspection API حالة النسخة الموجودة في فهرس Google. ولا يختبر الصفحة مباشرة. لذلك لا ينبغي لوكيلي أن يستنتج من ذلك أن «الصفحة قابلة للفهرسة»: هو يرصد ما احتفظت به Google، لا ما يقدمه الموقع اليوم.
الخطوة 2: تحديد ما يجب معالجته
رصدي للمكاسب السريعة بسيط عن قصد. أبحث عن الصفحات القريبة من الصفحة الأولى التي يقل CTR فيها بوضوح عن الصفحات الأخرى في الموقع نفسه عند الموضع نفسه، مع استبعاد العلامة التجارية. الفكرة: مقارنة الموقع بنفسه عند موضع متساوٍ، بدل مقارنته بمنحنى CTR متوسط وجدته على الإنترنت.
استبعاد العلامة التجارية نقطة منهجية. فاستعلامات العلامة التجارية لها CTR مختلف جدًا، وكانت ستحجب الإشارة. والصفحة التي تؤدي أضعف عند موضع متساوٍ يكون غالبًا عنوانها (title) أو وصفها غير جاذب، أو لا يجيب عن نية الاستعلام.
هذا الرصد ينتج مرشحين لا قرارات. وتتحقق مرحلة التحقيق من أن الصفحة مفهرسة فعلًا، وأنها تجيب عن الاستعلام، وأنه لا توجد صفحة أخرى في الموقع تستهدف الشيء نفسه.
الخطوة 3: وكلاء يكتبون، ومراجع يرفض
عند هذه النقطة تتوقف معظم العروض. جعل وكيل يكتب أمر سهل. أما جعله يكتب دون أن يكسر الموقع فهو العمل الحقيقي.
يفصل نظامي بين الأدوار. وكيل يخطط. وكاتب يقترح. وفحوص آلية تتحقق مما يمكن التحقق منه برمجيًا (الطول والصيغة ووجود العناصر الإلزامية). ثم مراجع مستقل لم يكتب النص يحكم هل هو صالح للنشر.
هذا المراجع يرفض كثيرًا، وهذا مقصود. فقد التقط سعرًا مضللًا قبل النشر. ورفض أيضًا نصوصًا كانت تعيد صياغة الصفحة بدل أن تضيف إليها شيئًا. أما الكاتب الذي يراجع نفسه فيوافق تقريبًا على كل شيء.
عندما يرفض المراجع، لا أخفف من صرامته. بل يتلقى الكاتب آخر أسباب الرفض ليتعلم منها. تخفيف الرقابة يرفع معدل النشر، وهذا بالضبط ما لا ينبغي تحسينه.
بعد الموافقة تأتي النسخة الاحتياطية للحالة السابقة، ثم الكتابة، ثم إعادة التحقق مباشرة: يعيد النظام تحميل الصفحة المنشورة ويتأكد أن التغيير موجود وأن لا شيء آخر قد تحرك. وإذا فشل الفحص يكون التراجع آليًا. وبدون هذه اللبنة الأخيرة لن أترك وكيلًا يكتب أبدًا.
الخطوة 4: القياس، وحماية القياس
يقارن القياس نافذة قبل الإجراء بنافذة بعده، على الصفحة المعنية. وهناك احتياطان كلّفني اكتشافهما غاليًا.
ترك الصفحة ترتاح
إذا عُدّلت الصفحة أثناء نافذة القياس، لم نعد نعرف أي تعديل أنتج أي أثر. لذلك يفرض النظام فترة راحة: الصفحة المعدَّلة لا تُمس ما دام قياسها لم ينتهِ.
ولتحديد المدة، لا بد أيضًا من معرفة التأخر من جهة Google. بحسب وثائق title links، على Google أن تعيد زحف الصفحة ومعالجتها، وقد يستغرق ذلك «من بضعة أيام إلى بضعة أسابيع». وتذكّر الصفحة نفسها بأن Google قد تولّد عنوانًا مختلفًا عمّا كتبته إن رأت أن الـ title لا يعكس الصفحة. فالـ title المعدَّل ليس بالضرورة هو الـ title المعروض: ويجب أن يكون النظام قادرًا على رصد ذلك.
اليوم الذي كاد فيه النظام يمحو عملي
الثغرة الأولى التي عشتها: كان النظام لا يرى إلا إجراءاته هو. وكاد يعيد كتابة صفحة عدّلتها يدويًا قبل أيام قليلة. لم يكن يعرف أنها «في فترة راحة»، لأن من لمسها كنت أنا لا هو.
الحل هو سجل للتعديلات اليدوية يقرؤه النظام قبل كل قرار. وبمجرد أن أغيّر صفحة يدويًا أسجلها فيه. ليس حلًا أنيقًا، لكنه يعالج المشكلة.
الإجراءات بلا URL
الفخ الثاني: بعض الإجراءات تخص ملفات، مثل llms.txt أو sitemap أو robots.txt. ليس لها URL صفحة، فلا قياس صفحة بصفحة. لا يمكن تتبعها إلا على مستوى الموقع، ويصعب نسب الأثر إليها. أدوّنها في السجل، لكنني لا أدّعي قياس نتيجتها.
الخطوة 5: التكلفة، قبل أن تفاجئك
أحرقت اختباراتي الأولى كثيرًا من الـ tokens. والسبب أن كل استدعاء كان يعيد تحميل سياق الأداة كاملًا، بتعليماتها وملفات إعدادها وسجلها، بينما كانت المهمة تحتاج إلى ثلاثة أسطر من السياق.
انتقلت إلى سياق أدنى: كل وكيل يتلقى ما يحتاجه لمهمته ولا شيء غيره. والدرس الأعم: ميزانية لكل تشغيل، تُحدَّد مسبقًا، وتُحسب وتُسجَّل. وإذا تجاوزها التشغيل توقف ونبّهني. لا تعويض صامتًا.
الخطوة 6: إبقاء الإنسان حيث يهم
لا يحتوي موجز الصباح إلا على قرار واحد لي. وكل ما عداه إما أُنجز وجرى التحقق منه، وإما استُبعد مع ذكر السبب.
على موقع عميل حساس، أحتفظ بحق الموافقة. بعض المواقع تبقى في وضع الاقتراحات فقط: يرصد النظام ويحقق ويكتب، لكنه لا ينشر. الاستقلالية تُكتسب موقعًا بعد موقع، لا دفعة واحدة.
مثال قيد التنفيذ: mesfrais.pro
على موقعي mesfrais.pro، جعلت النظام يعيد كتابة عناوين (titles) قالب صفحات. رفض المراجع المستقل النسخة الأولى: كان النص يَعِد خطأً بميزة ضريبية في بعض الصفحات. وربما كان إنسان مستعجل سيتركه يمر.
بعد ذلك حصرت النطاق في الـ title وحده، لعزل الأثر. دون تعديل المحتوى في الوقت نفسه. والتراجع جاهز.
ليست عندي نتيجة بعد. نافذة القياس لم تنتهِ، وعندما تنتهي لن تقول إلا ما جرى على هذه الصفحات، لا ما قد يجري في مكان آخر. أفضّل أن أكتب ذلك كما هو على أن أعلن مكسبًا قبل أوانه.
ما الذي سأفعله صباح الاثنين
البدء بنوع واحد من الإجراءات، مثل عناوين قالب واحد. النطاق الضيق يجعل القياس مقروءًا.
كتابة السجل قبل الوكيل: إجراءات النظام، والتعديلات اليدوية، والتواريخ، والحالة السابقة. يقرؤه النظام قبل كل قرار.
الفصل بين الكاتب والمراجع، مع تأطير للمراجع ينطلق من أن النص مرفوض حتى يثبت العكس. وعدم تخفيف صرامته حين يرفض كثيرًا.
التخطيط للتراجع قبل أول كتابة، ولإعادة التحقق المباشر بعدها مباشرة.
تحديد فترة راحة الصفحات وطول نافذة القياس، مع مراعاة المهل التي تصفها Google.
تحديد ميزانية لكل تشغيل وتقليص سياق كل استدعاء إلى الحد الضروري.
إبقاء وضع الاقتراحات فقط على المواقع التي يكلّف فيها الخطأ غاليًا.
الحدود
يروي هذا المقال نظامًا بنيته لاحتياجاتي. لا أقدم أرقامًا داخلية، لذلك لا يمكنك الحكم على فعاليته بناءً على كلامي، ولا أدّعي أنه يحسّن الزيارات. والحالة الوحيدة التي وصفتها بالتفصيل ليست لها نتيجة بعد.
مقارنة 28 يومًا قبل الإجراء وبعده تبقى مقارنة بسيطة. فهي لا تُلغي أثر الموسمية، ولا تحديثات Google، ولا احتمال أن تعيد Google كتابة الـ title. وارتفاع الأرقام بعد الإجراء ليس دليلًا على أن الإجراء هو السبب.
وأخيرًا، نقاط الوثائق المذكورة تعكس قراءتها في تاريخ هذا المقال وقد تتغير. كما أن هذه الوثائق لا تعطي، في الصفحات التي فتحتها، حصة دقيقة لـ URL Inspection API: تحقق منها قبل تحديد حجم مهمتك.