JavaScript SEO بالتجربة: ماذا يفهرس Google وBing وYandex فعلاً من صفحات JS

المشكلة في JavaScript ليست انه "سيئ" لمحركات البحث. المشكلة ان كثيراً من الفرق تفترض ان الصفحة اذا بدت كاملة في المتصفح، فالمحرك سيراها بالطريقة نفسها. هذا افتراض مريح، لكنه ليس دقيقاً دائماً.

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

اذا كنت تعمل على React او Vue او Next.js او Nuxt، فهذا الموضوع قريب جداً من واقعك. واذا اردت التحقق مما يصل فعلاً الى crawler قبل النشر، فـ SEO Analyzer نقطة بداية جيدة لمراجعة الـ HTML الابتدائي وما ينقصه.

اولاً: الفهرسة على مرحلتين

غالباً لا يعالج Google صفحات JavaScript الثقيلة في خطوة واحدة. بل يعمل على مرحلتين:

1. يزحف اولاً الى HTML الابتدائي ويفهرسه.
2. لاحقاً، عندما تتوفر موارد الرندر، ينفذ JavaScript ويعيد تقييم الـ DOM النهائي.

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

ولهذا نرى احياناً snippets غريبة او عناوين غير مكتملة في البداية، ثم تتغير بعد ايام. واحياناً لا تتغير اصلاً.

كيف بُنيت صفحة الاختبار

تم تصميم الصفحة بشكل متطرف عمداً:

• HTML ابتدائي شبه فارغ
• title و H1 و meta description والنص الرئيسي تُضاف عبر JavaScript
• المحتوى يُجلب عبر AJAX
• schema Article تُحقن عبر JS كذلك

بمعنى آخر: اذا لم ينفذ المحرك JavaScript، فلن يرى الا القليل.

1$(document).ready(function () {
2  $.ajax({
3    url: '/api/get-article-data',
4    success: function(data) {
5      $('title').text(data.title);
6      $('h1#main-title').text(data.h1);
7      $('meta[name="description"]').attr('content', data.description);
8      $('#article-content').html(data.body);
9
10      var script = document.createElement('script');
11      script.type = 'application/ld+json';
12      script.text = JSON.stringify(data.schemaData);
13      document.head.appendChild(script);
14    }
15  });
16});

وكانت الفكرة ان نجعل الفرق بين HTML الابتدائي والنسخة النهائية واضحاً جداً، حتى نعرف بسرعة هل تم التعامل مع JavaScript فعلاً ام لا.

ماذا استطاعت ادوات Google ان ترى

قبل النظر الى نتائج البحث، كان هناك اختبار مهم: Rich Results Test من Google استطاع بناء الـ DOM النهائي وقراءة العناصر التي اضافها JavaScript.

هذا يخبرنا ان Google "يستطيع" تقنياً قراءة الصفحة. لكنه لا يقول لنا متى سيستخدم هذه القراءة داخل الفهرس الحي.

الموجة الاولى: ما الذي ظهر في البداية

بعد ساعات من ارسال الصفحة، ظهرت النتيجة بالفعل في Google وBing وYandex. لكن العنوان والوصف كانا مستمدين من HTML الابتدائي، لا من المحتوى الذي ولده JavaScript لاحقاً.

هذا هو الدليل الاوضح على الموجة الاولى. الصفحة "مفهرسة"، نعم، لكن ليس بالصيغة الكاملة التي يراها المستخدم في المتصفح.

هذه المشكلة تصبح حساسة عندما يكون الوقت عاملاً حاسماً، مثل:

• صفحات الهبوط الجديدة
• المقالات الخبرية
• الحملات الزمنية
• اي صفحة تحتاج انعكاساً سريعاً في النتائج

الموجة الثانية: Google يلحق، لكن بعد انتظار

بعد عدة ايام، اظهر بحث site: نصاً كان موجوداً اصلاً فقط بعد تنفيذ JavaScript. هذا يعني ان Google وصل في النهاية الى النسخة المرندرة.

النتيجة العملية هنا واضحة: Google قادر على معالجة محتوى CSR حتى عندما يأتي عبر AJAX. لكنه لا يفعل ذلك فوراً.

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

Bing وYandex: هنا يظهر الفرق بوضوح

في نفس التجربة، ظل Bing وYandex معتمدين بدرجة اكبر على HTML الابتدائي. لم يظهرا مرونة Google نفسها في التقاط المحتوى المولد على العميل.

وهذا مهم جداً اذا كان مشروعك لا يعتمد على Google فقط، او اذا كنت تعمل في سوق توجد فيه محركات اخرى ذات وزن فعلي.

الحل الوسيط: Dynamic Rendering

كمرحلة اضافية، تم تفعيل dynamic rendering:

• المستخدم العادي يحصل على صفحة JavaScript المعتادة
• الـ crawler يحصل على نسخة HTML مرندرة مسبقاً

بعد ذلك، قام Yandex بتحديث الـ snippet وبدأ يعتمد على المحتوى الجاهز.

هذا لا يعني ان dynamic rendering هو الاختيار المثالي لكل مشروع. لكنه يثبت شيئاً عملياً: عندما تعطي محرك البحث HTML جاهزاً مبكراً، تقل مشاكل الفهم والفهرسة.

ماذا تعلمنا من التجربة

1. نعم، Google يعالج JavaScript. لكن هذا لا يلغي المخاطر

من اكثر الاستنتاجات الخاطئة شيوعاً: "طالما Google يرندر JS، اذاً لا يهم اين نضع المحتوى". هذا غير صحيح.

Google قد يرندر، لكن:

• توجد طوابير
• توجد فترات تأخير
• لا تُعالج كل الصفحات بالسرعة نفسها
• المحتوى الحساس SEO يفقد سرعته اذا خرج من HTML الابتدائي

2. الـ HTML الابتدائي يظل طبقة الحماية الاقوى

اذا كانت الصفحة مهمة للـ SEO، فمن الافضل ان تظهر هذه العناصر منذ الاستجابة الاولى:

• <title>
• meta description
• H1
• النص الاساسي
• الروابط المهمة
• الـ schema ذات القيمة

هذا هو الخيار الاكثر استقراراً عبر المحركات المختلفة.

3. SSR وSSG ما زالا الخيار الاكثر هدوءاً

اذا كانت البنية التقنية تسمح، فـ SSR او SSG يظلان افضل للمحتوى الحساس. ليس لأن CSR "ممنوع"، بل لأنه من غير المنطقي وضع title والنص الرئيسي والوصف في طابور رندر مؤجل اذا كان يمكن تقديمها جاهزة منذ البداية.

4. Dynamic rendering اقرب الى حل انتقالي

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

توصيات عملية للفرق

اذا اردنا اختصار الدرس في نقاط تنفيذية:

1. لا تجعل المحتوى الحرج SEO معتمداً كلياً على CSR.
2. اختبر ما يراه الـ crawler فعلاً.
3. اذا كانت سرعة الفهرسة مهمة، فكر اولاً في SSR او SSG.
4. استخدم CSR للتفاعل، لا للجوهر الدلالي للصفحة.
5. استخدم dynamic rendering فقط عندما يفرضه عليك الواقع التقني.

وللمراجعة السريعة بعد الاطلاق، يفيدك SEO Analyzer في التأكد من ان HTML الابتدائي يحمل ما يكفي، كما يساعد Meta-Tag Generator في تثبيت اشارات snippet الاساسية.

الخلاصة

هذه التجربة لا تقول ان JavaScript "يدمر SEO". ما تقوله بشكل ادق هو ان تأخير ظهور المحتوى المهم الى ما بعد الرندر العميلي ما زال يعني تأخيراً، وتفاوتاً بين المحركات، وفهرسة اقل قابلية للتوقع.

اذا اردت قاعدة بسيطة، فهي هذه: اترك التجربة التفاعلية الغنية لـ JavaScript، لكن ضع المعنى SEO للصفحة في HTML منذ البداية. هذه غالباً اقل مخاطرة بكثير.