كيف تستلمون الموقع
من المطوّر

كيفية استخدام هذا الدليل

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

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

الأدوات المطلوبة

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

تأكدوا من أن الموقع سُلّم إليكم فعلًا

افحصوا النطاق عبر ⁦WHOIS⁩ وحساب المسجّل

1. افتحوا ⁦WHOIS⁩، وأدخلوا النطاق دون مسار صفحة، مثل example.ru، ثم ابدؤوا البحث.
2. حدّدوا المسجّل وتاريخ انتهاء النطاق. في نطاقات ⁦.ru⁩ قد يظهر التاريخ في الحقل paid-till؛ وقد يختلف اسم الحقل في الامتدادات الأخرى.
3. ادخلوا إلى حساب المسجّل المذكور باستخدام حساب العميل. تأكدوا من وجود النطاق وإمكانية تجديده وإدارة ⁦DNS⁩، وأن جهة اتصال استعادة الحساب تخص الموظف المسؤول.
4. طابقوا بيانات صاحب النطاق مع ترتيب الملكية المتفق عليه. إخفاء البيانات في ⁦WHOIS⁩ أمر طبيعي؛ فالأداة العامة لا تغني عن فحص الحساب والمستندات.

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

أنشئوا سجلًا لبقية صلاحيات الوصول

لا تضعوا كلمات المرور في جدول ملاحظات متاح للجميع. تكفي إحالة إلى مكان حفظ آمن واسم المسؤول. إذا قيّدت شروط المنصة الوصول، فوثّقوا العمليات التي ينفّذها العميل بنفسه وتلك التي تتطلب دعمًا.

افحصوا التحويلات واستجابات الخادم والشهادة

أربع صيغ للنطاق في ⁦httpstatus.io⁩

غالبًا ما يُفتح الموقع عبر ⁦HTTP⁩ أو ⁦HTTPS⁩، مع ⁦www⁩ أو بدونها. اختاروا العنوان الرئيسي، مثل https://example.ru/. ثم افتحوا ⁦httpstatus.io⁩ والصقوا الأسطر الأربعة في الحقل، مع استبدال المثال بنطاقكم:

http://example.ru/
http://www.example.ru/
https://example.ru/
https://www.example.ru/

اضغطوا على ⁦Check status⁩. وسّعوا النتائج وافحصوا تسلسل الرموز والعنوان النهائي. يُتوقّع أن يعيد العنوان الرئيسي 200. عند توحيد العناوين بشكل دائم، تقود الصيغ البديلة عادةً عبر 301 أو 308 إلى عنوان ⁦HTTPS⁩ الرئيسي الذي يعيد 200. كرروا الفحص لصفحة داخلية؛ يجب ألا يضيع مسارها.

احفظوا التقرير وأرسلوا للمطوّر العنوان الأصلي والسلسلة كاملة والعنوان النهائي المتوقع. التحويل المؤقت 302 ليس خطأً دائمًا؛ استوضحوا غرضه. المشكلة هي مخالفة المطلوب أو وجود حلقة أو فقدان الصفحة.

هل صفحة ⁦404⁩ تعيد الرمز ⁦404⁩ فعلًا؟

أضيفوا إلى نطاقكم مسارًا تعرفون أنه غير موجود، مثل /proverka-priemki-ne-sushchestvuet-8472/. افتحوه في المتصفح وافحصوه بالأداة نفسها. يجب أن تظهر صفحة واضحة مع تنقّل ورمز الحالة 404. إذا ظهرت عبارة «الصفحة غير موجودة» بينما يعيد الخادم 200، فهذا نجاح زائف. ويمكن أيضًا استخدام الرمز التالي عمدًا لمورد حُذف بالفعل: 410.

فحص ⁦HTTPS⁩ باستخدام ⁦SSL⁩ ⁦Labs⁩

1. افتحوا ⁦SSL Server Test⁩. في الحقل ⁦Hostname⁩ أدخلوا النطاق دون https:// أو مسار.
2. عند الحاجة، حدّدوا ⁦Do not show the results on the boards⁩، وابدؤوا الاختبار وانتظروا اكتماله.
3. افحصوا تاريخ انتهاء الشهادة ومطابقتها للنطاق ورسائل الثقة في سلسلة الشهادات. أرسلوا ملاحظات البروتوكولات إلى مسؤول الخادم مع رابط التقرير.

يجب أن يفتح الموقع في متصفح عادي دون تحذير من شهادة غير صالحة. افحصوا أيضًا الصور والخطوط والبرامج النصية؛ فاستخدام ⁦HTTPS⁩ للصفحة لا يصلح روابط الموارد التي ما زالت عبر ⁦HTTP⁩. تقييم ⁦SSL⁩ ⁦Labs⁩ يخص إعدادات ⁦TLS⁩، لا أمان الموقع كله.

تأكدوا من عدم حجب الموقع عن روبوتات البحث

الخطوة ⁦1⁩. افتحوا ⁦robots.txt⁩

أدخلوا في المتصفح https://example.com/robots.txt. ابحثوا عن مجموعة User-agent: * وأي قواعد منفصلة لـ⁦Googlebot⁩ و⁦Yandex⁩. هذان السطران يمنعان الروبوت المعني من الزحف بالكامل:

User-agent: *
Disallow: /

في موقع عام بعد الإطلاق، يستدعي ذلك مراجعة الإعدادات. لكن لا تحذفوا القيود عشوائيًا؛ فقد تكون الحسابات والسلة والعناوين التقنية محجوبة عمدًا. تتحدد النتيجة بتفاعل المجموعات والقواعد والعنوان المحدد.

افتحوا ⁦Yandex Webmaster⁩ → ⁦Tools → Robots.txt analysis⁩ (تحليل ⁦robots.txt⁩) وأدخلوا عنوان الموقع. بعد تحميل الملف، افحصوا السماح للرئيسية وصفحة خدمة ومقال والعناوين المهمة الأخرى. إذا حُجبت صفحة مطلوبة، احفظوا عنوانها والقاعدة المسببة. تشرح الخطواتَ صفحة مساعدة الأداة.

الخطوة ⁦2⁩. ابحثوا عن ⁦noindex⁩ في الصفحة والترويسات

افتحوا المصدر عبر خيار «عرض مصدر الصفحة» في المتصفح، ثم ابحثوا عن name="robots"، name="googlebot" و noindex. المهم هو وجود وسم ميتا فعلي داخل <head>، مثل:

<meta name="robots" content="noindex, nofollow">

في مقال مثل هذا، قد تكون كلمة noindex واردة في مثال تعليمي لا في حظر فعّال. افحصوا أيضًا ترويسات الاستجابة في ⁦httpstatus.io⁩؛ فقد تصل التعليمة بصيغة X-Robots-Tag: noindex. وفي ⁦WordPress⁩، راجعوا «الإعدادات ← القراءة» والخيار الذي يطلب من محركات البحث عدم فهرسة الموقع؛ وقد تضيف إضافات ⁦SEO⁩ قيودًا أيضًا.

النتيجة المتوقعة: الصفحات المقصودة للبحث لا تحتوي على منع فهرسة غير مقصود. يجب أن يتمكن ⁦Google⁩ من الوصول إلى الصفحة لقراءة noindex؛ وحظر الزحف في ⁦robots.txt⁩ لا يحل محل هذه التعليمة. توضح الفرقَ وثائق ⁦Google⁩.

الخطوة ⁦3⁩. افحصوا خريطة الموقع ⁦XML⁩

خذوا عنوان الخريطة من السطر Sitemap: في ⁦robots.txt⁩ أو اطلبوه من المطوّر. قد يكون اسمها sitemap.xml، sitemap_index.xml أو غير ذلك. افتحوها؛ وإذا كانت قائمة بخرائط أخرى، فافتحوا خرائط الصفحات والمنتجات والمقالات. تأكدوا من استخدام النطاق الفعلي وصيغة ⁦HTTPS⁩ الرئيسية، لا موقع الاختبار.

افتحوا عناوين من كل قسم. يجب ألا تتضمن الخريطة بالخطأ تحويلات أو صفحات محذوفة أو صفحات ⁦noindex⁩. طابقوا القائمة كاملة مع سجل الموقع المتفق عليه؛ ففتح خريطة واحدة لا يثبت اكتمالها. في ⁦Yandex Webmaster⁩ استخدموا ⁦Tools → Sitemap validator⁩ (مدقق خريطة الموقع)، والصقوا الرابط وراجعوا الأخطاء؛ ويتوفر دليل رسمي.

الخطوة ⁦4⁩. افحصوا الصفحة في ⁦Google Search Console⁩

1. في ⁦Search Console⁩ اختاروا الموقع الإلكتروني الذي تم إثبات ملكيته.
2. الصقوا العنوان الكامل لصفحة مهمة في حقل فحص ⁦URL⁩ العلوي.
3. ميّزوا بين المعلومات المحفوظة في الفهرس وفحص النسخة الحالية. اضغطوا على اختبار عنوان ⁦URL⁩ المنشور / ⁦Test Live URL⁩ لفحص الاستجابة الحالية.
4. وسّعوا تفاصيل الزحف والفهرسة. عند وجود منع أو فشل في الجلب، أرسلوا السبب المحدد إلى المطوّر. كرروا الاختبار المباشر بعد الإصلاح.

نجاح الاختبار المباشر يعني إمكانية الظهور تقنيًا في البحث، ولا يَعِد بفهرسة فورية أو ترتيب مرتفع. يوضح اختلاف هذين الوضعين دليل مساعدة ⁦Google⁩. وبالنسبة إلى ⁦Yandex⁩، استخدموا أيضًا فحص استجابة الخادم في ⁦Webmaster⁩ وتقارير الفهرسة.

اعثروا على الروابط المعطلة والتكرار وأخطاء الترميز

كيفية بدء الزحف في ⁦Screaming Frog⁩

1. ثبّتوا ⁦SEO Spider⁩ من الموقع الرسمي. الصقوا عنوان الصفحة الرئيسية في الحقل ⁦Enter URL to spider⁩ واضغطوا على ⁦Start⁩.
2. انتظروا انتهاء الزحف. إذا بلغ حد النسخة المجانية البالغ ⁦500⁩ عنوان، فلا تعتبروا التقرير كاملًا؛ فالمشروع الأكبر يحتاج إلى أداة دون هذا القيد.
3. افتحوا علامة التبويب ⁦Response Codes⁩ وابحثوا عن استجابات ⁦4xx⁩ و⁦5xx⁩. اختاروا العنوان المتأثر وافحصوا ⁦Inlinks⁩ لمعرفة الصفحات التي تشير إليه.
4. صدّروا النتائج وأرسلوا للمقاول أزواجًا من «الصفحة المصدر ← الرابط المعطل».

الزحف عبر الروابط لا يضمن العثور على كل الصفحات؛ فقد تُغفل صفحة يتيمة لا يشير إليها أي رابط. قارنوا التصدير بخريطة الموقع وقائمة ⁦CMS⁩ والبنية المتفق عليها. إذا كانت البرامج النصية تبني المحتوى، فتحققوا من وضع العرض. تشرح الإعدادات والقيودَ إرشادات الزحف الأول.

ما الذي تراجعونه في النتائج

ترد أسماء علامات التبويب ووظائفها في دليل ⁦SEO Spider⁩. التنبيه الآلي سبب لفحص الصفحة. فتطابق ⁦title⁩ في نسخة مكررة عمدًا يختلف عن تطابقه في عشر صفحات لخدمات مختلفة، ولكل حالة قرار مناسب.

كيفية فحص البيانات المنظّمة

افتحوا ⁦Rich Results Test⁩، واختاروا فحص ⁦URL⁩ والصقوا العنوان وابدؤوا الاختبار. وسّعوا النوع المكتشف والأخطاء. تفحص الأداة النتائج المنسّقة التي يدعمها ⁦Google⁩؛ وعدم العثور على نتيجة مؤهلة لا يعني أن كل ترميز ⁦Schema.org⁩ غير صحيح.

افتحوا أيضًا ⁦Schema Markup Validator⁩ وافحصوا العنوان نفسه. طابقوا القيم مع المحتوى: العنوان والمؤلف والمؤسسة والصورة و⁦URL⁩ والتواريخ. يحتاج المقال إلى صورة مرتبطة به، والخدمة إلى معلومات حديثة. لن يكشف المدقق ذو النتيجة الخضراء مؤلفًا مختلقًا أو صورة لموضوع آخر إذا كان الكود صحيحًا شكليًا.

افحصوا بشكل منفصل معاينة الرابط في تطبيق المراسلة والبيانات الوصفية og:title، og:description، og:image. ظهور الشعار القديم نفسه في جميع المواد يستدعي ضبط صور مخصّصة للصفحات. انتبهوا إلى التخزين المؤقت في تطبيق المراسلة؛ فقد يعرض البطاقة القديمة بعد الإصلاح.

ما الذي تفحصونه يدويًا في النصوص والصور

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

للبحث عن أخطاء ⁦HTML⁩ يمكنكم استخدام ⁦Nu Html Checker⁩؛ أرسلوا العنوان وراجعوا رسائل أخطاء البنية. على المطوّر تقييم أثرها؛ فعدد التحذيرات لا يغني عن فحص الموقع. وتدخل المراجعة الشاملة لإعدادات البحث ضمن تدقيق ⁦SEO⁩ التقني.

افحصوا الواجهة على شاشات مختلفة

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

فحص سريع للعرض في ⁦Chrome⁩

1. افتحوا الصفحة، ثم أدوات المطوّر من قائمة المتصفح أو باستخدام ⁦F12⁩.
2. فعّلوا شريط الأجهزة بزر الهاتف والجهاز اللوحي. في وضع ⁦Responsive⁩ اضبطوا العرض يدويًا.
3. في الفحص الأولي جرّبوا ⁦320⁩ و⁦390⁩ و⁦768⁩ و⁦1440⁩ بكسل. هذه مجموعة عملية لاكتشاف العيوب، وليست قائمة شاملة بكل الأجهزة.
4. عند كل عرض، مرّروا الصفحة كاملة وافتحوا القوائم والجداول والتبويبات والنماذج. سجّلوا العنوان والعرض ولقطة للمشكلة.

⁦Device Mode⁩ يساعد على فحص التجاوب لكنه لا يحاكي الهاتف الفعلي بالكامل. كرروا المسار الرئيسي على هاتف ⁦Android⁩ و⁦iPhone⁩ حقيقيين إذا كانا ضمن أجهزة جمهور المشروع.

ما الذي يُعدّ عيبًا

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

تنقّلوا أيضًا بين العناصر باستخدام مفتاح ⁦Tab⁩. يجب أن يكون التركيز مرئيًا والأزرار والحقول قابلة للوصول، والأخطاء مشروحة نصيًا. كبّروا المتصفح إلى ⁦200⁩% وتأكدوا من إمكانية القراءة وتنفيذ الإجراء الرئيسي. افحصوا متطلبات الإتاحة المتفق عليها بقائمة منفصلة.

تأكدوا من وصول الطلب إلى المستلم

رسالة «شكرًا» تثبت فقط ظهور الرسالة. ينتهي استلام النموذج عند النقطة التي يبدأ فيها الموظف معالجة الطلب: البريد أو ⁦CRM⁩ أو نظام الطلبات. أخبروا المسؤول قبل الاختبار حتى لا يظنه عميلًا حقيقيًا.

اختبروا كل نموذج خطوة بخطوة

1. احصروا النماذج المختلفة: طلب أسفل الصفحة، ومعاودة اتصال، ونافذة منبثقة، وموجز مشروع، ورفع ملف. قد تستخدم النماذج المتشابهة ظاهريًا معالجات مختلفة.
2. افتحوا الصفحة المطلوبة. لاختبار المصدر، يمكن إضافة معلمات اختبار متفق عليها: ?utm_source=acceptance&utm_medium=test&utm_campaign=site_handover.
3. استخدموا علامة واضحة مثل «اختبار الاستلام — نموذج الخدمة — ⁦14⁩:⁦35⁩» مع بيانات اتصالكم المعتمدة. املؤوا كل حقل بقيمة مختلفة لتسهيل اكتشاف فقدان البيانات.
4. أرسلوا النموذج مرة واحدة، وسجّلوا الوقت والنتيجة الظاهرة.
5. ابحثوا عن الرسالة في الوارد والبريد المزعج. إذا كان الحفظ في ⁦CMS⁩ مطلوبًا، فابحثوا عن السجل هناك. وفي ⁦CRM⁩ راجعوا البطاقة والمسار والمسؤول والهاتف والتعليق والمصدر.
6. طابقوا البيانات المستلمة مع المرسلة. يجب أن تفتح المرفقات، وأن تقود الروابط إلى المواد الصحيحة، وأن تصل معلمات الحملات إلى الحقول المخصصة.

النتيجة المتوقعة: يُحفظ الطلب ويصل عبر المسار المتفق عليه دون فقد الحقول، ويستطيع الموظف معرفة مصدره. وجود السجل في ⁦CMS⁩ مع غياب الرسالة نتيجتان مختلفتان: الحفظ نجح، أما وصول الإشعار فلم يُؤكّد.

اختبروا الأخطاء وإعادة الإرسال

المتجر والدفع والحساب الشخصي

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

أنشئوا حسابَي اختبار بدورين مختلفين. افحصوا الدخول والخروج واستعادة الوصول والإجراءات المسموحة. يجب ألا يرى المستخدم طلبًا أو مستندًا يخص غيره بمجرد فتح عنوانه. استخدموا بيانات اختبار متفقًا عليها فقط. ناقشوا أخطاء نقل الحقول وتوجيه الطلبات مع مختص في تكامل ⁦CRM⁩.

افحصوا أهداف ⁦Metrica⁩ بعد إجراء فعلي

ابدؤوا بالدخول إلى ⁦Yandex Metrica⁩ بحساب العميل. طابقوا النطاق ورقم العداد، وتأكدوا من رؤية الإعدادات والتقارير المطلوبة. اطلبوا قائمة الأهداف: ما الذي يُعدّ طلبًا أو نقرة هاتف أو تنزيلًا أو شراءً.

كيفية تفعيل المصحح

1. افتحوا الصفحة مع المعلمة ?_ym_debug=2. إذا كان العنوان يحتوي أصلًا على علامة استفهام، فأضيفوا &_ym_debug=2.
2. نفّذوا الإجراء المستهدف وافتحوا لوحة التصحيح أسفل الصفحة.
3. في علامتَي التبويب ⁦Events⁩ و ⁦Console⁩ تحققوا من رقم العداد والحدث، وقارنوهما بالهدف المتفق عليه.
4. ثم ابحثوا عن التحويل في التقرير، مع مراعاة تأخر تحديث البيانات وفلاتر زياراتكم الشخصية.

وضع _ym_debug=2 مخصّص لشيفرة العداد الجديدة. إذا لم تظهر اللوحة، فاستخدموا البديل الموثّق من ⁦Yandex⁩ مع _ym_debug=1 ووحدة تحكم المتصفح. ترد الخطوات الدقيقة وأسباب غياب الحدث في التعليمات الرسمية لفحص الأهداف.

كيفية اكتشاف هدف مضبوط بشكل خاطئ

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

احفظوا وقت الاختبار واسم الهدف ولقطة الحدث والطلب المستلم. حدّثوا الصفحة بعد الإرسال الناجح؛ يجب ألا يتكرر الحدث دون طلب جديد إلا إذا كان ذلك مقصودًا. ومع ⁦Google Analytics 4⁩ طابقوا الحدث في التصحيح أو التقرير الفوري مع الإجراء الفعلي، وسلّموا الحساب والصلاحيات للعميل أيضًا.

كيفية فحص ⁦PageSpeed⁩ وفهم ما يحتاج إلى إصلاح

افحصوا كل عنوان على حدة

1. افتحوا ⁦PageSpeed Insights⁩، والصقوا العنوان الكامل وابدؤوا التحليل.
2. انتظروا التقرير وافحصوا تبويبَي الهاتف والحاسوب؛ فالدرجات وظروف القياس تختلف.
3. احفظوا رابط التقرير والتاريخ والعنوان والجهاز، وسجّلوا التغييرات بين الجولات عند إعادة القياس.
4. ابدؤوا ببيانات المستخدمين الفعلية إن توفرت، ثم تشخيص المختبر. تحققوا هل تخص البيانات العنوان الحالي أم أصل الموقع كله.
5. وسّعوا التوصيات وحددوا الموارد المعنية: صورة أو برنامج نصي أو خط أو طلب. أرسلوا عناوينها ووصف المشكلة للمطوّر مع التقرير.

إذا شملت الاستلامات جميع الصفحات، فسجّلوا كل العناوين مع تقريرين لكل عنوان. فحص الرئيسية وخدمة ومقال يكشف مشكلات القوالب العامة، لكنه لا يثبت نتيجة باقي الصفحات.

تنطبق حدود ⁦Core Web Vitals⁩ على المئين ⁦75⁩ للزيارات الفعلية، مع الفصل حسب الجهاز. قد لا تتوفر بيانات لموقع جديد أو قليل الزيارات؛ وهذا لا يعني سرعة صفرية ولا فشلًا تلقائيًا. ترد التعريفات والشروط في وثائق ⁦Web Vitals⁩.

مثال لتحليل التقرير

مثال آخر: ⁦CLS⁩ مرتفع لأن الصورة تدفع النص عند تحميلها. اطلبوا حجز مساحتها بالأبعاد أو النسبة ثم أعيدوا الفحص. وإذا كانت الاستجابة بطيئة، فعلى المطوّر دراسة الخادم والتخزين المؤقت والتطبيق. لا يكفي زمن واحد لاتهام قاعدة البيانات أو الاستضافة تلقائيًا.

هل يجب اشتراط ⁦100⁩ بالضبط؟

درجة ⁦Lighthouse⁩ نتيجة لجولة مختبرية محددة وتتأثر بظروف القياس. يشرح ⁦Google⁩ الحساب والتباين في وثائق تقييم الأداء. إذا نصّت المتطلبات على ⁦100⁩، فسجّلوا المقياس والجهاز والظروف ثم تحققوا من النتيجة الفعلية. لا تثبت لقطة واحدة عبارة «⁦100⁩ في الموقع كله».

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

تحققوا من النسخة الاحتياطية باستعادتها

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

سيناريو استعادة تجريبية

1. اختاروا نسخة محددة وسجّلوا تاريخها وما ينبغي أن تعيده بالضبط.
2. اطلبوا استعادتها في بيئة اختبار معزولة، ولا تستبدلوا الموقع العامل لإجراء تجربة.
3. قبل تشغيل النسخة، عطّلوا المدفوعات الفعلية والإرسال الجماعي والإشعارات وسائر الإجراءات الخارجية. امنعوا الغرباء وروبوتات البحث من الوصول بوسائل مناسبة.
4. افتحوا الصفحات وادخلوا إلى ⁦CMS⁩ وافحصوا الصور والبيانات والمسار الرئيسي بمستلمين تجريبيين.
5. سجّلوا مدة الاستعادة والأجزاء الناقصة والتعليمات. تأكدوا من وصول المسؤول إلى النسخة حتى عند فقد الخادم الرئيسي.

النتيجة المتوقعة: تُعرف النسخة الممكن استعادتها والوقت اللازم، وتكون الاستعادة قد نُفذت فعلًا. قول «الاستضافة تنسخ كل شيء» دون اختبار يُبقي البند غير مؤكد.

الحد الأدنى لفحص الأمان عند التسليم

طابقوا مستخدمي ⁦CMS⁩ مع المسؤولين، وراجعوا حسابات الاختبار الزائدة وصلاحيات المقاولين. حدّدوا طريقة تحديث ⁦CMS⁩ والإضافات. تأكدوا من عدم إتاحة النسخ وملفات الإعداد للعامة، وعدم تسرب بيانات الاختبار إلى الإنتاج. يوفر ⁦WordPress⁩ إرشادات رسمية لتعزيز الحماية.

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

تأكدوا من قدرتكم على تحديث الموقع بأنفسكم

اطلبوا دليلًا ونفّذوا مهمة عادية دون مساعدة المطوّر: مسودة مقال، وصورة مع ⁦alt⁩، وعنوان للبحث، ورابط داخلي، ومعاينة. ثم غيّروا سعرًا في سجل اختباري وأعيدوه. لا تستخدموا الرئيسية العامة للتدريب.

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

• استلموا الشيفرات والتصاميم والتراخيص والمواد بالنطاق المتفق عليه.
• وثّقوا النشر والتراجع وتحديث الاعتماديات.
• عيّنوا مسؤولًا عن النطاق والاستضافة والنسخ وتنبيهات الأعطال.
• سجّلوا قناة الدعم وأوقات الاستجابة وحدود الصيانة المتفق عليها.
• طابقوا التسليم مع العقد؛ فالقائمة التقنية وحدها لا تحدد الدفع أو الضمانات أو الآثار القانونية لتوقيع المستندات.

كيفية إبلاغ المطوّر بالأخطاء والتحقق من الإصلاحات

يجب أن تصف كل ملاحظة مشكلة واحدة قابلة للتكرار. بدل «الموقع بطيء»، اذكروا العنوان والجهاز والوقت والتقرير. وبدل «النموذج معطل»، حدّدوا الخطوات والوجهة التي غاب عنها الطلب. بذلك يعيد المطوّر إنتاج الخلل ويتحقق العميل من النتيجة.

أولويات الإصلاح

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

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

وثّقوا نتيجة الاستلام: ما فُحص وما أُصلح وما بقي، والمسؤول والموعد لكل بند. أنجزوا مستندات إنهاء العمل وفق العقد.

قائمة التحقق قبل إتمام الاستلام

لا تحددوا البند إلا بعد فحصه. هذه العلامات مؤقتة ولا تُحفظ بعد إعادة التحميل؛ انقلوا النتائج وروابط الأدلة إلى سجلكم.

أسئلة شائعة حول استلام الموقع