دليل عملي للمواقع العربية
السيو التقني للمواقع العربية: Core Web Vitals وسرعة الموقع وملف robots.txt
ما هو السيو التقني؟ هو مجموعة التحسينات التي تساعد محركات البحث على اكتشاف صفحات الموقع وفهمها وفهرستها بكفاءة، وتمنح الزائر تجربة سريعة ومستقرة وقابلة للاستخدام. يشمل ذلك بنية الموقع، وإشارات الفهرسة، وCore Web Vitals، وملف robots.txt، وخريطة الموقع XML، والأمان، والتوافق مع الجوال.
ما هو السيو التقني؟
SEO التقني هو الأساس الذي يحمل المحتوى الجيد والروابط والسمعة الرقمية. قد تكتب صفحة عربية دقيقة تلبي نية الباحث، لكن قيمتها تبقى محدودة إذا تعذر على عناكب البحث الوصول إليها، أو كان عنوانها الأساسي غير واضح، أو تأخر عرض محتواها، أو تحركت عناصرها أثناء القراءة. لذلك لا يقتصر العمل التقني على إرضاء أداة قياس؛ بل يهدف إلى إزالة العوائق بين الصفحة وبين المستخدم ومحرك البحث.
يبدأ التدقيق بفهم مسار الصفحة: هل يمكن الوصول إليها عبر رابط HTML عادي؟ هل تعيد استجابة ناجحة؟ هل تسمح تعليمات الفهرسة بإدراجها؟ هل تشير الصفحة إلى عنوان canonical صحيح؟ وهل تقدم النسخة المحمولة المحتوى نفسه؟ بعد ذلك تُفحص السرعة، واستقرار التخطيط، وسلامة البيانات المنظمة، والروابط الداخلية. ويمكن ربط هذا العمل بخطة أوسع ضمن خدمات تحسين محركات البحث بدل معالجة كل خطأ بمعزل عن هدف الصفحة.
لماذا يحتاج الموقع العربي إلى عناية تقنية خاصة؟
اتجاه الكتابة من اليمين إلى اليسار لا يغير قواعد الزحف، لكنه يضيف نقاط فحص مهمة: تحميل الخط العربي، وطريقة التفاف العناوين الطويلة، وثبات القوائم والأيقونات، وسلامة المزج بين النص العربي والأرقام أو الأكواد اللاتينية. كما ينبغي تعريف اللغة والاتجاه في HTML، واستخدام ترميز UTF-8، وكتابة عناوين URL ثابتة ومفهومة. إذا كان الموقع متعدد اللغات، فيلزم تطبيق hreflang بصورة متبادلة، مع عدم تحويل المستخدم أو العنكبوت تلقائيًا إلى لغة أخرى بطريقة تمنع الوصول إلى النسخ البديلة.
ما الفرق بين السيو التقني وسيو المحتوى؟
سيو المحتوى يجيب عن أسئلة مثل: ماذا يبحث الجمهور؟ وهل الصفحة شاملة وواضحة؟ أما السيو التقني فيسأل: هل تستطيع الأنظمة الوصول إلى تلك الإجابة وعرضها بسرعة وفهم علاقتها ببقية الصفحات؟ المجالان متكاملان. عنوان جيد لا يعوض صفحة محجوبة، وسرعة ممتازة لا تجعل محتوى ضعيفًا مفيدًا. لهذا تُرتب الأولويات بحسب أثر المشكلة وعدد الصفحات المتأثرة، ثم تُراجع ضمن استراتيجية المحتوى وتجربة المستخدم.
تشمل نقطة البداية كذلك مراجعة التكرار الناتج عن المعلمات والفلاتر والنسخ القابلة للطباعة. عندما تعرض عناوين متعددة المحتوى نفسه، ينبغي اختيار النسخة الأساسية بوضوح، وتوحيد الروابط الداخلية عليها، وضبط التحويلات عند الاستغناء عن نسخة قديمة. لا تستخدم canonical لتغطية أخطاء بنيوية متكررة من دون فهم مصدرها؛ فهو إشارة تساعد محرك البحث، بينما يظل إصلاح التوجيه والربط الداخلي أكثر وضوحًا للمستخدم والعنكبوت.
Core Web Vitals الثلاثة
تقيس Core Web Vitals جوانب محسوسة من تجربة الصفحة: سرعة ظهور المحتوى الرئيسي، واستجابة الواجهة لتفاعل المستخدم، وثبات العناصر بصريًا. المقاييس الحالية هي LCP وINP وCLS. من الأفضل قراءة بيانات المستخدمين الفعلية أولًا، لأنها تعكس الأجهزة والشبكات الحقيقية، ثم استخدام الاختبارات المخبرية لتشخيص السبب وتجربة الحل. يشرح دليل Core Web Vitals الرسمي من Google Search Central تعريف المقاييس ومنهج قياسها.
| المقياس | ماذا يقيس؟ | أسباب شائعة | بداية المعالجة |
|---|---|---|---|
| LCP | زمن ظهور أكبر عنصر محتوى مرئي في نافذة العرض. | صورة رئيسية ثقيلة، خادم بطيء، CSS يحجب العرض، أو خط متأخر. | تحسين الخادم والصورة، وإعطاء المورد الرئيسي أولوية تحميل مناسبة. |
| INP | مدى سرعة استجابة الصفحة للنقر واللمس والكتابة طوال الزيارة. | مهام JavaScript طويلة، مستمعات أحداث ثقيلة، أو تحديث عرض مكلف. | تقسيم المهام، تقليل الشيفرة غير الضرورية، وتخفيف العمل بعد التفاعل. |
| CLS | مقدار التحرك غير المتوقع للعناصر أثناء عمر الصفحة. | صور بلا أبعاد، إعلانات تحجز مكانها متأخرًا، أو تبديل خط يغير القياسات. | حجز المساحات مسبقًا وتثبيت أبعاد الوسائط والعناصر الديناميكية. |
كيف نحسن LCP دون الإضرار بجودة الصورة؟
حدد أولًا عنصر LCP الفعلي؛ فقد يكون صورة الغلاف أو عنوانًا نصيًا أو كتلة كبيرة. إذا كان صورة، استخدم أبعادًا تناسب مساحة العرض، وصيغة حديثة مدعومة، وضغطًا بصريًا متوازنًا، مع srcset للأحجام المختلفة. لا تطبق التحميل الكسول على صورة تظهر فورًا أعلى الصفحة. حسّن زمن استجابة الخادم، وقلل CSS الحرج، ولا تحمل خطوطًا وأوزانًا لا تستخدمها الصفحة. الهدف ليس حذف الهوية البصرية، بل إيصال المورد الأهم مبكرًا وبحجم منطقي.
كيف نعالج CLS وINP في واجهة عربية؟
للحد من CLS، عرّف عرض الوسائط وارتفاعها أو نسبة أبعادها، واحجز مساحة للشريط والتنبيه والنموذج قبل وصول محتواها. راقب تبديل الخط العربي لأنه قد يغير طول السطر وارتفاعه. ولتحسين INP، سجل التفاعلات البطيئة، وافحص القوائم والفلاتر والبحث والسلة، ثم قسّم المهام الطويلة وأجّل الوظائف الثانوية. في المتاجر خصوصًا، يجب ألا تحول الإضافات الكثيرة كل نقرة إلى سلسلة طلبات وحسابات؛ ويقدم دليل تحسين معدل التحويل سياقًا مفيدًا لربط الأداء بسهولة إتمام المهمة.
ملف robots.txt
ملف robots.txt نص عام يوجد عادة في جذر النطاق، ويعطي برامج الزحف تعليمات حول المسارات المسموح أو غير المسموح بزحفها. وظيفته إدارة الزحف، وليس حماية البيانات أو إزالة صفحة من نتائج البحث. يمكن لمحرك البحث معرفة عنوان صفحة محظورة عبر روابط خارجية، كما يستطيع أي شخص فتح الملف؛ لذلك لا تضع فيه أسرارًا ولا تعتمد عليه كآلية وصول.
هل يمنع robots.txt فهرسة الصفحة؟
ليس بالضرورة. إذا أردت منع الفهرسة، يجب أن يتمكن محرك البحث من جلب الصفحة ورؤية توجيه noindex في وسم robots أو في ترويسة HTTP. الجمع بين الحظر في robots.txt وnoindex داخل الصفحة قد يمنع العنكبوت من قراءة التوجيه أصلًا. أما المحتوى الخاص فينبغي حمايته بالمصادقة أو الصلاحيات. راجع الصياغة والسلوك في توثيق Google لملف robots.txt.
مثال بسيط يحتاج إلى تكييف مع بنية الموقع، لا نسخه بلا مراجعة:
User-agent: * Disallow: /internal-search/ Allow: / Sitemap: https://example.com/sitemap.xml
افحص الملف بعد أي نقل نطاق أو تغيير بيئة. من الأخطاء الخطرة بقاء قاعدة حظر شاملة من بيئة الاختبار، أو حجب ملفات CSS وJavaScript اللازمة لفهم الصفحة، أو كتابة مسار واسع يحجب أقسامًا مطلوبة. وثّق سبب كل قاعدة، واحتفظ بالملف قصيرًا، واختبر عناوين ممثلة بدل الاكتفاء بالنظر إلى النص.
Sitemap XML
خريطة الموقع XML قائمة منظمة بعناوين URL التي تريد مساعدة محركات البحث على اكتشافها. هي إشارة اكتشاف وليست ضمانًا للفهرسة، ولا تصلح لإخفاء ضعف الربط الداخلي. يجب أن تحتوي العناوين الأساسية القابلة للفهرسة فقط: استجابات ناجحة، غير محظورة، وغير موجهة إلى canonical مختلف. استبعد صفحات البحث الداخلي والمعلمات المكررة وصفحات الأخطاء والتحويلات.
ماذا يجب أن تحتوي خريطة الموقع XML؟
ضع الصفحات المهمة والنهائية، وقسم الخرائط إذا كان ذلك يجعل إدارتها أو تشخيصها أسهل، ثم اجمعها في فهرس Sitemap عند الحاجة. حدّث قيمة آخر تعديل فقط عندما يتغير المحتوى فعلًا؛ فتغييرها آليًا كل يوم يضعف فائدتها. استخدم عناوين مطلقة ومتسقة في البروتوكول والنطاق والشرطة النهائية. ويمكن الإشارة إلى موقع الخريطة داخل robots.txt، مع إرسالها إلى أدوات مشرفي محركات البحث ومراقبة الفروق بين العناوين المقدمة والمفهرسة.
لا تعتبر الخريطة بديلًا للتنقل. يجب أن تصل العناكب والمستخدمون إلى الصفحات المهمة عبر روابط سياقية وتصنيفات واضحة. لذلك يفيد بناء مركز مقالات مثل مكتبة مقالات متاجر، وربط الأدلة ذات الصلة ببعضها، بدل ترك صفحات يتيمة لا يشير إليها إلا ملف XML.
سرعة الموقع وCDN
سرعة الموقع نتيجة سلسلة كاملة تبدأ من الخادم وقاعدة البيانات، وتمر بتوليد HTML والاتصال وتحميل الموارد وتنفيذ JavaScript، وتنتهي بالرسم على شاشة المستخدم. لهذا لا يكفي تثبيت إضافة تخزين مؤقت أو ضغط الصور وحده. قسّم المشكلة إلى زمن الخادم، وحجم الموارد، وترتيب تحميلها، وكلفة التنفيذ في المتصفح، ثم عالج أكبر عنق زجاجة.
تساعد شبكة توصيل المحتوى CDN على تقديم الملفات من مواقع أقرب للزائر، وتقليل الحمل على الخادم الأصلي، وتوفير تخزين مؤقت عند الحافة. لكنها لا تصلح استعلام قاعدة بيانات بطيئًا أو قالبًا يرسل JavaScript ضخمًا. اضبط سياسات التخزين بعناية، ولا تخزن صفحات شخصية أو سلة مستخدم كنسخة عامة. بعد التفعيل، تحقق من رؤوس الاستجابة، وتحديث الملفات عند النشر، واتساق HTTPS، وعدم إنشاء تحويلات زائدة.
ما الأولوية: الخادم أم الصور أم JavaScript؟
الإجابة تأتي من القياس. إذا كان وصول HTML بطيئًا فابدأ بالخادم والتخزين المؤقت وقاعدة البيانات. إذا ظهر HTML بسرعة وتأخر العنصر الرئيسي، افحص الصورة أو الخط أو CSS. إذا بدت الصفحة جاهزة لكنها تتجمد عند النقر، ركز على JavaScript والعمل في المسار الرئيسي. رتب الإصلاحات بحسب أثرها على القوالب واسعة الاستخدام؛ فتحسين رأس مشترك أو مكون منتج قد يفيد آلاف الزيارات أكثر من تنميق صفحة منخفضة الأهمية.
في الصفحات العربية، اختبر الخطوط على اتصال متوسط وجهاز متواضع. حمّل الملفات المستخدمة فقط، واختر استراتيجية عرض تقلل زمن الانتظار والتحول البصري، وراجع إن كان الخط البديل قريب القياسات من الخط النهائي.
اختبار الأداء
الاختبار الجيد يجمع بين بيانات ميدانية ومخبرية. البيانات الميدانية تخبرك بما يواجهه الزوار عبر فترة زمنية وأجهزة متعددة، بينما يعيد الاختبار المخبري تشغيل ظروف محددة تساعد على التشخيص. لا تقارن نتيجتين من إعدادات مختلفة، ولا تحكم من تشغيل واحد؛ ثبّت الصفحة والجهاز والشبكة قدر الإمكان، وكرر القياس، وسجل النسخة والتاريخ والتغيير المنفذ.
كيف تنفذ تدقيقًا تقنيًا قابلًا للتكرار؟
- اختر عينات من الصفحة الرئيسية، والتصنيفات، والمقالات، وصفحات الخدمة أو المنتج، لا صفحة واحدة فقط.
- تحقق من حالة HTTP، وcanonical، ووسم robots، واللغة، والروابط، وإمكانية الوصول إلى الموارد.
- راجع LCP وINP وCLS ميدانيًا إن توفرت البيانات، ثم شخّص كل قالب بأداة مخبرية.
- افحص ملف robots.txt وخريطة الموقع XML، وقارن محتواهما بالصفحات التي تريد فهرستها فعلًا.
- طبّق تغييرًا محددًا، ثم اختبر الانحدارات على الهاتف وسطح المكتب قبل النشر وبعده.
متى نعيد القياس بعد الإصلاح؟
أعد الاختبار المخبري فورًا للتأكد من أن السبب المباشر تحسن ولم يظهر خلل وظيفي. أما البيانات الميدانية فتحتاج وقتًا لتجميع زيارات جديدة، لذلك راقب اتجاهها بدل انتظار قفزة لحظية. اربط كل تعديل بتاريخ ونطاق واضحين، وراقب أيضًا التحويلات والأخطاء وقابلية الاستخدام؛ فقد تخفض حجم ملف ثم تفسد مكونًا مهمًا، وهذا ليس نجاحًا.
أنشئ سجلًا مختصرًا للتدقيق يضم عنوان الصفحة، ونوع القالب، والمشكلة، ودليل اكتشافها، وأولوية الإصلاح، والمسؤول، ونتيجة إعادة الاختبار. صنف المشكلات إلى حرجة تمنع الوصول أو الفهرسة، ومؤثرة تطال الأداء أو التجربة، وتحسينات محدودة. بهذه الطريقة لا تتحول قائمة الأدوات إلى عشرات التنبيهات غير المرتبة، ويمكن للفريق معالجة السبب المشترك قبل الأعراض المنفردة. راجع السجل بعد إطلاق قالب جديد، أو تغيير الاستضافة، أو إضافة نظام تحليلات، أو تعديل بنية الروابط، لأن هذه الأحداث قد تغير سلوك صفحات كثيرة دفعة واحدة.
الخلاصة العملية: اجعل الصفحات المهمة قابلة للزحف والفهرسة، اضبط robots.txt وSitemap XML وفق وظيفة كل منهما، حسّن المورد الأكبر والتفاعل والثبات، ثم قس من واقع المستخدم. السيو التقني عملية صيانة مستمرة تتبع تغييرات المحتوى والقالب والاستضافة، وليس فحصًا ينتهي مرة واحدة.
