الدليل النهائي لتطوير الويب للشركات البريطانية

لمن هذا الدليل

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

اختيار المنصة

غالباً ما يكون الجدل حول المنصات نزعةً عرقيةً. القرار في الواقع ميكانيكي إلى حدٍّ بعيد، ويتوقف على سؤالٍ واحد: كم مرة يحتاج الأشخاص غير التقنيين إلى تغيير الأمور؟

ووردبريس

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

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

بناء مخصص (Next.js أو ما شابه)

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

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

الاختبار الصادق

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

ما يؤثر حقاً في التصنيفات

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

• عنوان فريد ووصف ميتا لكل صفحة، ضمن حدود 60 و160 حرفاً تقريباً، مكتوب للاستعلام وليس لبدء اسم الشركة
• عنوان رئيسي واحد (H1) لكل صفحة يصف محتوى الصفحة — عددٌ مدهش من المواقع لا يحتوي حتى على واحد
• روابط كانونيكية حتى لا تتنافس نفس المحتويات في عناوين متعددة مع نفسها
• بيانات منظمة كشبكة مترابطة: المنظمة، الموقع الإلكتروني، الخدمة، الأسئلة الشائعة، المقالة، المسار
• علامات Open Graph وTwitter Card، وإلا ستظهر كل مشاركة على واتساب ولينكدإن فارغة
• خريطة الموقع النظيفة التي تستبعد أرشيفات المؤلفين وغيرها من الصفحات عديمة القيمة البحثية
• روابط داخلية، متبعة، منظمة في مجموعات مواضيعية

النقطة الأخيرة deserve التركيز لأنها غالباً ما تُنصح بها بشكل خاطئ. لا تجعل روابطك الداخلية nofollow. يتم تقسيم PageRank عبر الروابط على الصفحة، ويتم تجاهل الحصة المخصصة للروابط التي تحمل علامة nofollow بدلاً من إعادة توزيعها. لا تخزن السلطة بعلامات nofollow الداخلية؛ بل تدمرها. يمكنك وضع nofollow للروابط الخارجية إذا أردت — يجب أن تكون الروابط الداخلية دائماً متبعة.

الأداء، بمصطلحات ذات معنى

Core Web Vitals هي مقياس جوجل للتجربة، لكن السبب التجاري أبسط: المواقع البطيئة تفقد الاستفسارات.

ثلاثة أرقام يجب أن تلزم بها مطورك:

• أكبر رسم محتوى (LCP) أقل من 2.5 ثانية على هاتف متوسط المدى عبر 4G — وليس على سطح مكتبك
• التفاعل إلى الطلاء التالي (INP) أقل من 200 ميلي ثانية
• التحول التراكمي للهيكل (CLS) أقل من 0.1 — لا شيء يقفز أثناء تحميل الصفحة

تنبع معظم المشاكل من أربعة أسباب: صور غير مُحسَّنة، خطوط تحظر العرض، نصوص خارجية (أدوات الدردشة، مديري العلامات، المتتبعات)، وشحن جافاسكريبت لميزات لا تستخدمها الصفحة.

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

التغيير الذي يستحق الفهم في عصر الذكاء الاصطناعي

حدث شيء حقيقي، ويغير قراراً معمارياً.

إن زاحفات الذكاء الاصطناعي — GPTBot، ClaudeBot، PerplexityBot، CCBot — غالباً ما تطلب HTML خاماً ولا تنفذ جافاسكريبت. تستطيع جوجل تقديم جافاسكريبت، لكنها تفعل ذلك ببطء وأقل موثوقية من تقديم HTML plain.

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

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

إعادة البناء أم الإصلاح؟

إعادة البناء غالباً ما تكون الإجابة الخاطئة، ولدى الوكالات حافز واضح لعدم قول ذلك.

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

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

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

الهجرة دون فقدان التصنيفات

إذا قررت إعادة البناء، فإن الهجرة هي المكان الذي تتضرر فيه المواقع. الأساسيات:

1. قم بجرد جميع عناوين URL المفهرسة من Search Console وخريطة الموقع الخاصة بك، قبل أي شيء آخر.
2. احتفظ بها بدلاً من التحويل wherever ممكن. الإبقاء على عنوان URL كما هو — بما في ذلك شرطة المقطع النهائية — لا ينطوي على أي مخاطرة. تمرير 301 يحتفظ بمعظم الإشارات، لكن معظم ليس كل شيء.
3. عندما يكون التحويل ضرورياً، اجعله أحادي الخطوة. السلاسل تضعف وتضيع من ميزانية الزحف.
4. احتفظ بالعناوين والوصف والبيانات المنظمة. تحسينها أمر جيد؛ فقدانها ليس كذلك.
5. لا تطلق الموقع الجديد أبطأ من القديم. قارن الأداء قبل وبعد.
6. راقب Search Console يومياً خلال الشهر الأول، حتى تُلتقط أخطاء التغطية في أيام وليس في شهور.

توقع تقلبات طفيفة لمدة أسبوع أو أسبوعين. الهجرة المنفذة جيداً لا تنتج هبوطاً مفاجئاً.

ما يجب الإصرار عليه

• سعر ثابت مقابل نطاق مكتوب
• ملكية كاملة للكود، بما في ذلك المستودع
• ميزانية أداء متفق عليها قبل التصميم
• كل عنوان URL مفهرس موثق كتابياً
• بيانات منظمة في كل قالب صفحة
• تدريب حتى يتمكن فريقك من النشر بدونك

الخطوات التالية

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