صيانة موقع WordPress‏: قائمة المراجعة الشهرية (وما يفعله وكيل الذكاء الاصطناعي نيابةً عنك)

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

ما هي صيانة موقع WordPress‏؟ جولة حارس، لا إطفاء حرائق

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

الصيانة تعمل بالطريقة نفسها. الفرق بين موقع يتعطل مرة في السنة وموقع لا يتعطل ليس الحظ. إنه جولة منتظمة، بوتيرة مختلفة لكل نقطة.

صيانة موقع WordPress‏ الأسبوعية: خمسة فحوص تستغرق دقائق

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

يحتاج فحصان في الجدول إلى شرح، لأن معظم المفاجآت تولد هنا.

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

المتجر: البريد جزء من عملية البيع. في WooCommerce‏، تأكيد الطلب الذي لا يصل إلى العميل يعني عميلًا يتصل بك قلقًا. بحسب التوثيق الرسمي، معظم مشكلات البريد هي مشكلات تسليم: الخادم يرسل، لكن الرسالة لا تصل. يُنصح بالإرسال عبر مزوّد SMTP‏ مخصص، والتأكد من أن عنوان المرسِل ينتمي إلى نطاقك لا إلى Gmail‏. ويمكن أيضًا الاطلاع على سجلات WooCommerce‏ (ضمن "الحالة") لمعرفة هل نجح النظام في تسليم الرسالة.

تحديثات النواة والإضافات والقالب: مهمة شهرية، بعد الاختبار

ترتيب التحديث الآمن (نسخة احتياطية، ثم اختبار، ثم موافقة، وعندها فقط الموقع الحي) فصّلناه في دليل الإدارة ولن نكرره. ما ينقص هناك هو منطق الوتيرة.

يشدد التوثيق الرسمي لـWordPress على أخذ نسخة احتياطية قبل كل ترقية، تشمل قاعدة البيانات وكل الملفات، وعلى الفحص بعدها لمعرفة هل تعثّر النشر أو ظهرت أخطاء. ويذكر أيضًا أن التحديثات الفرعية التلقائية للنواة مفعّلة افتراضيًا منذ الإصدار 3.7. أي أن WordPress‏ ينفّذ الإصلاحات الصغيرة بنفسه. وكل ما عدا ذلك مكانه الشهر.

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

ما الذي يفحصه الوكيل في بيئة الاختبار (نسخة من الموقع يمكن الخطأ فيها دون أن يراه أي عميل):

1. تحميل الصفحة الرئيسية وصفحة خدمة رئيسية وصفحة منتج دون أخطاء.
2. كل نموذج يرسل، ورسالة حقيقية تصل.
3. في المتجر: منتج يدخل السلة ويصل إلى صفحة الدفع حتى مرحلة السداد.
4. لا أخبار سيئة جديدة في "صحة الموقع" لم تكن موجودة من قبل.
5. الموقع يبدو سليمًا على الجوال، لأن معظم الزوار هناك.

إن مرّ كل شيء، تصلك رسالة في تيليجرام تتضمن ما جرى تحديثه وما جرى فحصه وما هي المخاطرة. توافق أنت، فيصعد التحديث إلى الموقع الحي. وإن فشل شيء، فالموقع الحي لم يُمَسّ أصلًا.

الأمان: المستخدمون والمصادقة الثنائية والإضافات المنسية

معظم الاختراقات لا تشبه ما نراه في الأفلام. تشبه إضافة قديمة لم يعد أحد يستخدمها، أو حساب مصمم عمل معك قبل ثلاث سنوات وكلمة مرور لم تتغير منذ ذلك الحين.

يقترح الدليل الرسمي لتأمين WordPress‏ بعض الخطوات البسيطة: إبقاء الإصدارات محدّثة، واستخدام كلمات مرور قوية ومصادقة ثنائية، وحذف الإضافات غير المستخدمة، ونقل الملفات عبر SFTP‏ لا عبر FTP‏ العادي. وهذه بالضبط بنود الصيانة الشهرية.

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

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

سرعة الموقع: ثلاثة أرقام يكفي أن تعرفها

"الموقع بطيء" ليس تشخيصًا. حددت Google‏ ثلاثة مقاييس، هي Core Web Vitals‏، ووفق web.dev‏ يُعدّ الموقع سليمًا حين يستوفي المقاييس الثلاثة في 75% من الزيارات، على الجوال وعلى الحاسوب.

المصدر: web.dev‏، Core Web Vitals‏. تُقاس العتبات عند النسبة المئوية الخامسة والسبعين من تحميلات الصفحة.

يقيس الوكيل مرة في الشهر الصفحة الرئيسية وأهم ثلاث صفحات، ويقارن بالشهر السابق ويبلّغ عن التغيير. أدوات القياس هي PageSpeed Insights‏ وتقرير Core Web Vitals‏ في Search Console‏، وكلاهما يعتمد على بيانات ميدانية من زوار حقيقيين.

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

الروابط المكسورة وصفحات 404: ليس كل 404 عطلًا

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

بحسب صفحة المساعدة لدى Google‏، لا تضر أخطاء 404 بأداء الموقع في البحث، ويمكن تجاهلها حين لا يُفترض أن يكون العنوان موجودًا. أما ما يستحق الإصلاح فهو:

• عنوان أرسلتَه في ملف الخريطة (sitemap‏) وهو غير موجود. تُصلح الملف.
• محتوى انتقل إلى عنوان جديد. تضيف إعادة توجيه إلى العنوان الجديد.
• أخطاء إملائية شائعة في العنوان. يمكن توجيهها إلى الصفحة الصحيحة.
• محتوى حُذف نهائيًا. تُبقي 404 أو 410. لا توجّه إلى الصفحة الرئيسية، لأن Google‏ تُصنّف ذلك "soft 404‏" وقد يعيق معالجة الموقع.

تقسيم العمل هنا بسيط. يفحص الوكيل الروابط الداخلية المكسورة، ويقرأ تقارير Search Console‏، ويعدّ قائمة مرتبة: "يلزم إصلاح" مقابل "يمكن تجاهله". أما عمليات إعادة التوجيه نفسها، التي تغيّر سلوك الموقع، فتنتقل إليك للموافقة.

ما له تاريخ انتهاء: الشهادة والدومين وإصدار PHP‏

هذه الأشياء لا تنكسر. إنها تنتهي، ولذلك تُفحص في التقويم.

شهادة SSL‏. منذ 15 مارس 2026، لا تزيد مدة صلاحية الشهادات العامة على 200 يوم (كانت 398 قبل ذلك)، ووفق جدول CA/Browser Forum‏ ستستمر المدة في الانخفاض حتى 47 يومًا في 2029. والمعنى لنشاط صغير: التجديد اليدوي مرة في السنة لم يعد نموذجًا يصلح. من يدير الموقع يحتاج إلى تجديد تلقائي وإلى فحص أنه يحدث فعلًا. عند Let‏'s Encrypt‏ مثلًا، الشهادة صالحة 90 يومًا والتوصية أن تُجدَّد كل 60 يومًا. يفحص الوكيل كل أسبوع كم يومًا بقي، وينبّه قبل النهاية بوقت طويل.

الدومين. تجديد سنوي يصل إلى بريد قديم. نوصي بالتجديد التلقائي وبعنوان بريد يقرؤه أحد فعلًا. يبلّغ الوكيل عن تاريخ الانتهاء، أما الدفع نفسه فعليك أنت.

إصدار PHP‏. وفق صفحة متطلبات WordPress‏، يُوصى بـPHP بالإصدار 8.3 فما فوق. ووفق php.net‏، هذه حالة الدعم حتى اليوم:

إن كان موقعك لا يزال على 8.2، فأمامك حتى نهاية العام. تُنفَّذ ترقية PHP‏ من لوحة تحكم الاستضافة، وقد تكسر إضافة قديمة لم تُحدَّث. لذلك تُفحص أولًا في بيئة الاختبار، وتمر عبر موافقتك. يتعرّف الوكيل على الإصدار في "صحة الموقع"، وينبّه ويجهّز الفحص.

الفحوص الربع سنوية: أربعة فحوص لا يكاد أحد يجريها

أهم الفحوص هي تلك التي تُؤجَّل إلى الأبد، لأن شيئًا لا ينكسر أثناء عدم إجرائها. إلى أن يحدث ذلك.

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

قائمة المراجعة: الجولة الشهرية والربع سنوية

علّم ما أُنجز، وانظر كم من الجولة صار مغطى. العلامات لا تُحفظ في أي مكان، ولذلك يمكنك العودة إلى هنا كل شهر. كل سطر مكتوب مع وتيرته.

أين لا يحلّ وكيل الذكاء الاصطناعي محل المختص

من المهم قول ذلك بوضوح، لأن هذا هو المكان الذي يغري فيه المبالغة. وكيل الذكاء الاصطناعي ممتاز في الفحوص المتكررة والتقارير وتجهيز الملف. وهو أقل ملاءمة لما يلي:

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

كيف تبدأ هذا الشهر

1. افحص ثلاثة تواريخ: متى كانت آخر نسخة احتياطية، ومتى تنتهي الشهادة، وأي إصدار PHP‏ يعمل عندك.
2. أرسل رسالة اختبار من كل نموذج وتأكد من وصولها.
3. حدد من يفعل ماذا: أي الفحوص تنتقل إلى الوكيل، وأي الإجراءات تنتظر موافقتك. اكتب ذلك، ولا تتفقوا شفهيًا.
4. ابدأ بشهر من التقارير فقط. دون تغييرات. وانظر ماذا يخبرك الموقع.

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

الأسئلة الشائعة

المصادر

• https‏://developer.wordpress.org/advanced-administration/security/backup‏/
• https‏://developer.wordpress.org/advanced-administration/upgrade/upgrading‏/
• https‏://developer.wordpress.org/advanced-administration/security/hardening‏/
• https‏://wordpress.org/about/requirements‏/
• https‏://www.php.net/supported-versions.php‏
• https‏://web.dev/articles/vitals‏
• https‏://support.google.com/webmasters/answer/2445990‏
• https‏://developers.google.com/search/docs/crawling-indexing/http-network-errors‏
• https‏://woocommerce.com/document/email-faq‏/
• https‏://letsencrypt.org/docs/faq‏/
• https‏://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods‏/
• https‏://www.digicert.com/campaigns/tls-ssl-certificate-validity‏