يستطيع جوجل عرض JavaScript. ذلك الخبر السار. والسيئ أن عرض JS أغلى على جوجل بنحو مئة مرة من تحليل HTML الصرف، وأظهرت الأبحاث أن جوجل يحتاج نحو تسعة أضعاف الوقت لزحف المواقع المدعومة بـ JavaScript مقارنة بمكافئاتها HTML الساكنة. إن اتكأ موقعك على العرض من جهة العميل لمحتوى حاسم، فلديك مشكلة ظهور أدركتها أم لا.
في Gorilla Marketing، ندقق بانتظام مواقع ثقيلة بـ JS تجلس أقسام محتوى كاملة فيها غير مرئية لمحركات البحث. يفكك هذا الدليل بدقة كيف يتعامل جوجل مع JavaScript وأين تسوء الأمور وما تستطيع فعله حياله، إطار عمل بإطار عمل.
ما سيو JavaScript؟
سيو JavaScript ممارسة ضمان إتاحة المحتوى المولد أو المعدَّل بـ JavaScript كاملاً لزواحف محركات البحث. يجلس ضمن السيو التقني لكنه يعبر إلى استراتيجية المحتوى ومعمارية الموقع وتطوير الواجهات.
صفحات HTML القياسية مباشرة لـ Googlebot. يجلب HTML ويقرأ المحتوى ويتبع الروابط ويفهرس الصفحة. يعقّد JavaScript هذا لأن المحتوى لا يوجد في استجابة HTML الأولية. بل على المتصفح (أو الزاحف) تنفيذ JavaScript لبناء محتوى الصفحة في الـ DOM.
لمحترفي السيو، ذلك التمييز مهم للغاية. إن عجز Googlebot عن رؤية محتواك أثناء مرور زحفه الأولي، فعليه وضع الصفحة في طابور العرض، وهناك تتسلل التأخيرات والإخفاقات وفجوات الفهرسة. هدف سيو JavaScript إغلاق الفجوة بين ما يراه المستخدم في متصفحه وما يراه محرك البحث حين يجلب صفحتك.
كيف يزحف جوجل JavaScript ويعرضه؟
يعالج جوجل صفحات JavaScript عبر خط أنابيب من ثلاث مراحل، وفهمه مفتاح تشخيص مشاكل سيو JS.
المرحلة 1: الزحف
يرسل Googlebot طلب HTTP لرابطك كأي صفحة أخرى. يتلقى استجابة HTML الأولية. لتطبيق معروض من جهة العميل، تلك الـ HTML الأولية غالباً هيكل شبه فارغ ببضعة وسوم <script> وعنصر نائب <div id="root"></div>.
عند هذه النقطة، يستخرج Googlebot ما يستطيع من HTML الخام: أي روابط في وسوم <a> والوسوم التعريفية الحاضرة في المصدر وأي محتوى مضمّن مباشرة لا محقون بـ JavaScript.
المرحلة 2: العرض
الصفحات المحتاجة تنفيذ JavaScript توضع في طابور عرض. ثم تعالج خدمة عرض الويب لدى جوجل (WRS) هذه الصفحات بنسخة Chromium بلا واجهة، مشغّلة إصداراً دائم التحديث يبقى متزامناً مع أحدث إصدار Chrome مستقر. ومنذ تحديث 2019 الدائم، لم تعد مزايا JavaScript الحديثة المشكلة التي كانتها.
إليك المصيدة: العرض كثيف الموارد. على جوجل تخصيص موارد حوسبة لتنفيذ JavaScript وبناء الـ DOM والتقاط HTML النهائي المعروض. وطابور العرض يعني تأخيراً بين الزحف والعرض. أحياناً ثوانٍ وأحياناً أطول، حسب موارد جوجل المتاحة وترتيبه أولوية موقعك.
المرحلة 3: الفهرسة
بعد عرض الصفحة، يعالج جوجل الـ DOM المبني كاملاً. يستخرج المحتوى ويكتشف الروابط المحقونة بـ JavaScript ويفهرس الصفحة. والروابط الموجودة أثناء العرض تُضاف لطابور الزحف لمعالجة مستقبلية.
نظام المرورين (زحف ثم عرض) السبب الجذري لمعظم مشاكل سيو JavaScript. المحتوى الموجود فقط بعد تنفيذ JavaScript دائماً في وضع أدنى مقارنة بالحاضر في استجابة HTML الأولية.
لماذا يسبب العرض من جهة العميل مشاكل سيو؟
العرض من جهة العميل (CSR) يعني تنزيل المتصفح وثيقة HTML ضئيلة ثم تشغيل JavaScript لبناء محتوى الصفحة. النهج الافتراضي لتطبيقات الصفحة الواحدة (SPA) المبنية بأطر مثل React وVue وAngular.
من منظور المستخدم، ينجح CSR بعد تحميل JavaScript وتنفيذه. ومن منظور محرك البحث، يخلق عدة مشاكل.
HTML الأولية فارغة. حين يجلب Googlebot صفحة CSR أول مرة، ينال شبه لا محتوى. كل شيء يعتمد على معالجة طابور العرض الصفحة بنجاح.
العرض غير مضمون. أكد جوجل أن العرض يؤجَّل حتى توفر الموارد. للمواقع الكبيرة، يعني هذا أن بعض الصفحات قد تنتظر في طابور العرض فترات ممتدة، أو في حالات حدية قد لا تُعرض أصلاً خلال دورة زحف معينة.
اكتشاف الروابط متأخر. إن حُقنت روابطك الداخلية بـ JavaScript، فلن يجدها Googlebot أثناء مرور الزحف الأولي. يبطئ هذا اكتشاف الصفحات الجديدة وقد يشظّي عدالة روابطك الداخلية.
الوسوم التعريفية المضبوطة بـ JavaScript غير موثوقة. مع قول جوجل إنه يستطيع معالجة العناوين والأوصاف ووسوم canonical المضبوطة بـ JavaScript، هناك مشكلة معروفة: عناصر canonical من ترميز محقون ديناميكياً لا تُعالج دائماً صحيحاً، مؤديةً لتخمين من جوجل. الأسلم بكثير تضمينها في HTML الأولية.
ما استراتيجيات العرض الرئيسية للسيو؟
اختيار استراتيجية العرض الصحيحة أكبر قرار منفرد تتخذه لسيو JavaScript. إليك مقارنة كل نهج.
العرض من جهة الخادم (SSR)
مع SSR، ينفذ الخادم JavaScript ويرسل HTML معروضة كاملاً للمتصفح (ولـ Googlebot). المحتوى حاضر في الاستجابة الأولية فلا اعتماد على طابور العرض.
منفعة السيو: المحتوى والروابط والوسوم التعريفية كلها مرئية بالمرور الأول. يعامله Googlebot أشبه بصفحة HTML قياسية.
المقايضة: كل طلب يطلق عرضاً من جهة الخادم، بما يزيد زمن أول بايت (TTFB). يخفَّف هذا بالتخزين المؤقت لكنه يضيف تعقيد بنية. وهناك خطوة الإماهة (hydration) أيضاً: يرسل الخادم HTML معروضة كاملاً، لكن المتصفح لا يزال يحتاج تنزيل JavaScript وتنفيذه ليجعل الصفحة تفاعلية. حتى اكتمال الإماهة، تبدو الصفحة جاهزة لكنها لا تستجيب لمدخلات المستخدم.
الأطر الداعمة له: Next.js (لـ React) وNuxt.js (لـ Vue) وAngular Universal.
التوليد الساكن (SSG)
يعرض SSG الصفحات مسبقاً وقت البناء، منتجاً ملفات HTML ساكنة قابلة للتقديم من CDN. المعيار الذهبي لملاءمة السيو لأن كل صفحة وثيقة HTML كاملة بصفر اعتماد عرض.
منفعة السيو: أسرع TTFB ممكن وبلا اعتماد على طابور العرض والمحتوى حاضر دائماً.
المقايضة: تحتاج معرفة كل روابطك وقت البناء. لمواقع بملايين الصفحات الديناميكية (كتالوجات سيو التجارة الإلكترونية الكبيرة مثلاً)، SSG الصرف غير عملي.
الأطر الداعمة له: Next.js (التصدير الساكن) وNuxt.js (أمر generate) وGatsby وEleventy وAstro.
التجديد الساكن التزايدي (ISR)
ISR نهج هجين شهّره Next.js. تُولَّد الصفحات ساكنة وقت البناء لكنها قابلة لإعادة التوليد في الخلفية بعد فاصل زمني محدد. يمنحك منافع SSG للسيو مع مرونة التعامل مع تحديثات المحتوى.
منفعة السيو: كـ SSG لمعظم الصفحات، بسلوك التقديم القديم أثناء إعادة التحقق للطزاجة.
الأفضل لـ: المواقع المحتاجة أداءً ساكناً بمحتوى يتغير دورياً، كقوائم المنتجات أو المقالات بتسعير محدَّث.
العرض من جهة العميل (CSR)
CSR الصرف يرسل هيكل HTML فارغاً ويتكئ كلياً على JavaScript لبناء الصفحة. كما غُطي أعلاه، النهج الأشد إشكالاً للسيو.
متى يكون مقبولاً: للصفحات الموثَّقة (لوحات التحكم ومناطق الحسابات) غير المحتاجة فهرسة. ولأي صفحة تريد تصدرها، CSR وحده لا يكفي.
العرض الديناميكي
يكشف العرض الديناميكي وكلاء مستخدم الزواحف ويقدم لهم HTML معروضة مسبقاً بينما يقدم نسخة JavaScript القياسية للمستخدمين. صرّح جوجل صراحة أن العرض الديناميكي حل التفافي لا نهج طويل المدى، ويوصي بـ SSR أو SSG بدله.
متى لا يزال منطقياً: إصلاحاً مؤقتاً أثناء هجرة تطبيق CSR كبير إلى SSR أو SSG. يشتري وقتاً لكنه يضيف تعقيداً وعبء صيانة.
لا يعتبر جوجل العرض الديناميكي إخفاءً (cloaking) شرط مطابقة المحتوى المعروض ما يراه المستخدمون. لكن واضح من وثائقهم أنهم يفضلون حلك المشكلة بمستوى المعمارية.
كيف تتقارن هذه الاستراتيجيات؟
إليك مرجعاً سريعاً لاختيار النهج الصحيح:
| الاستراتيجية | المحتوى في HTML الأولية؟ | كلفة البناء | كلفة الخادم | الأفضل لـ |
|---|---|---|---|---|
| SSR | نعم | منخفضة | عالية (لكل طلب) | المحتوى الديناميكي والتخصيص |
| SSG | نعم | عالية (عند البناء) | منخفضة جداً | المدونات والتوثيق وصفحات التسويق |
| ISR | نعم | متوسطة | متوسطة | صفحات المنتجات والمحتوى المحدَّث دورياً |
| CSR | لا | منخفضة | منخفضة | التطبيقات الموثَّقة ولوحات التحكم |
| العرض الديناميكي | نعم (للروبوتات) | متوسطة | متوسطة | جسر هجرة مؤقت |
أي أطر JavaScript الأفضل (والأسوأ) للسيو؟
ليست كل الأطر متساوية الإشكال. الإطار نفسه ليس المشكلة؛ ضبطك العرض هو المهم.
React
يعود React افتراضياً للعرض من جهة العميل، بما يجعل تطبيقات React الصرفة إشكالية للسيو فور الإخراج. لكن نظام React البيئي يضم خيارات SSR وSSG قوية.
ما تفعله: لا تستخدم Create React App لأي شيء يحتاج التصدر. استخدم Next.js بدله. يمنحك SSR وSSG وISR بضبط ضئيل. وإن علقت بتطبيق React SPA قائم، ففكّر في هجرة مرحلية: انقل صفحات هبوطك الأعلى زيارات إلى Next.js أولاً وأبقِ الـ SPA لأقسام لوحة التحكم الموثَّقة وحوّل الباقي تدريجياً. يتيح لك هذا إثبات أثر السيو قبل الالتزام بإعادة بناء كاملة.
Next.js
Next.js الإطار المفضل لتطوير React الواعي بالسيو. يدعم SSR وSSG وISR واستراتيجيات عرض لكل صفحة، أي تستطيع استخدام SSG للمقالات وSSR لصفحات المنتجات الديناميكية في التطبيق نفسه.
ما تفعله: استخدم getStaticProps للصفحات بمحتوى معروف وقت البناء. واستخدم getServerSideProps للصفحات المحتاجة بيانات طازجة بكل طلب. وفعّل ISR بـ revalidate للصفحات المحدَّثة دورياً.
Vue.js
كـ React، يعود Vue افتراضياً لـ CSR. وNuxt.js إطار SSR/SSG لـ Vue، مكافئ ما يمثله Next.js لـ React.
ما تفعله: استخدم Nuxt.js بأمر generate للمواقع الساكنة أو شغّله بوضع SSR للمحتوى الديناميكي. ويدعم Nuxt 3 العرض الهجين، متيحاً مزج SSR وSSG لكل مسار.
Nuxt.js
يتعامل Nuxt.js مع قصور Vue في السيو جيداً. قدّم Nuxt 3 قواعد مسارات تتيح تعريف استراتيجيات العرض بمستوى المسار، فيستطيع /blog/ التوليد الساكن بينما يستخدم /products/ مقدار SSR.
ما تفعله: عرّف قواعد المسارات في nuxt.config.ts لتلائم حاجات كل قسم. استخدم routeRules لضبط prerender أو SSR أو ISR لكل نمط مسار.
Angular
كان Angular تاريخياً الإطار الأخدع للسيو. يوفر Angular Universal مقدار SSR، لكن الإعداد أشد تعقيداً من مكافئات Next.js أو Nuxt.js.
ما تفعله: نفّذ Angular Universal لـ SSR. يتطلب الضبط شيفرة قوالب أكثر من مكافئات Next.js أو Nuxt، وستحتاج التعامل بعناية مع الشيفرة الخاصة بالمنصة (واجهات المتصفح مثل window وdocument لا توجد على الخادم). وللمشاريع الجديدة حيث السيو أولوية، يبقى دعم نظام Angular البيئي للعرض الملائم للبحث خطوة خلف React وVue. ليس مانعاً لكنه يعني عملاً يدوياً أكثر.
Gatsby
Gatsby مولد مواقع ساكنة مبني على React. كل صفحة تُعرض مسبقاً وقت البناء، بما يجعله ملائماً للسيو جوهرياً. لكن أزمنة البناء قد تطول كثيراً للمواقع الكبيرة جداً.
ما تفعله: ينجح Gatsby للمواقع كثيفة المحتوى حتى بضعة آلاف صفحة. وللأكبر، Next.js مع ISR ملاءمة أفضل عادة.
ملخص الأطر
| الإطار | العرض الافتراضي | دعم SSR | دعم SSG | صعوبة السيو |
|---|---|---|---|---|
| React (صرف) | CSR | إعداد يدوي | إعداد يدوي | عالية |
| Next.js | SSR/SSG | مدمج | مدمج | منخفضة |
| Vue.js (صرف) | CSR | إعداد يدوي | إعداد يدوي | عالية |
| Nuxt.js | SSR/SSG | مدمج | مدمج | منخفضة |
| Angular | CSR | Angular Universal | محدود | متوسطة-عالية |
| Gatsby | SSG | ليس الاستخدام الأساسي | مدمج | منخفضة |
كيف يؤثر JavaScript على الربط الداخلي وعدالة الروابط؟
من أشد مشاكل سيو JavaScript إغفالاً. الروابط الداخلية الطريقة الأساسية لاكتشاف محركات البحث الصفحات وتوزيع إشارات الترتيب عبر موقعك. حين يتحكم JavaScript في تنقلك، قد تنكسر عدة أشياء.
روابط ليست روابط حقيقية
ليتبع Googlebot رابطاً، يحتاجه وسم <a> سليماً بسمة href. أطر JavaScript أحياناً تستخدم معالجات onClick أو عناصر <button> أو توجيهاً مخصصاً لا ينتج عناصر <a href> قابلة للزحف في الـ DOM.
<a href="https://gorillamarketing.ae/products/widget">Widget</a>
<span onclick="navigate('/products/widget')">Widget</span>
<button onclick="loadPage('widget')">Widget</button>الأول قابل للزحف والثاني والثالث لا. إن استخدم تنقلك الرئيسي أو ترقيم صفحاتك أو روابط فئاتك معالجات أحداث JavaScript بدل وسوم إرساء سليمة، فلن يكتشف Googlebot تلك الصفحات بالزحف الداخلي. شائع خصوصاً في تطبيقات React وVue أحادية الصفحة حيث يستخدم المطورون مكونات توجيه خاصة لا تُخرج دائماً وسوم <a> قياسية في HTML المعروضة. تحقق دائماً من الـ DOM المعروض لتأكيد إنتاج روابطك عناصر إرساء سليمة بسمات href كاملة.
التوجيه المبني على الهاش يكسر الزحف
تطبيقات الصفحة الواحدة المستخدمة أجزاء الهاش للتوجيه (مثل example.com/#/products) تخلق مشكلة جوهرية. صرّح جوجل أنه لا يتبع موثوقاً الروابط بأجزاء الروابط. كل صفحة متمايزة تحتاج رابطها النظيف باستخدام History API.
https://example.com/#/about
https://example.com/#/contact
https://example.com/about
https://example.com/contactالزوج الأول (بالهاش) غير قابل للزحف موثوقاً والثاني (روابط نظيفة) هو الصحيح.
اكتشاف الروابط المتأخر
حتى حين ينتج JavaScript وسوم <a> سليمة، الروابط المحقونة بعد العرض تُكتشف فقط أثناء المرور الثاني (بعد طابور العرض). في موقع كبير، يتراكم هذا التأخير. الصفحات الجديدة المربوطة فقط عبر تنقل معروض بـ JavaScript ستستغرق أطول لدخول الفهرس.
لأداء السيو في المواقع الثقيلة بـ JS، اضمن وجود أهم روابطك الداخلية في استجابة HTML الأولية. والتنقل المعروض من الخادم يحل هذا نظيفاً.
ماذا يحدث للبيانات المنظمة في مواقع JavaScript؟
يؤكد جوجل قدرته على معالجة البيانات المنظمة (JSON-LD) المحقونة بـ JavaScript. لكن هناك قلقاً عملياً: البيانات المنظمة المعتمدة على العرض خاضعة لتأخيرات طابور العرض نفسها كأي محتوى مولد بـ JavaScript.
إن وُلّد ترميز سكيماك من جهة العميل ولم تُعرض الصفحة في الوقت، فلن يراه جوجل. ولشيء بأهمية سكيما المنتجات أو المراجعات أو الأسئلة الشائعة، ذلك خطر يستحق الإزالة.
الممارسة المثلى: احقن بيانات JSON-LD المنظمة في استجابة HTML الأولية، إما مضمنة مباشرة أو عبر SSR. لا تتكئ على JavaScript جهة العميل لتوليدها. مباشر مع أطر SSR: يتيح Next.js وNuxt.js كلاهما تضمين JSON-LD في <head> أو <body> الصفحات المعروضة من الخادم بجهد ضئيل.
غطينا البيانات المنظمة بعمق أكبر في مقالنا المخصص للموضوع.
كيف تتعامل زواحف الذكاء الاصطناعي والنماذج اللغوية مع JavaScript؟
إليك ما تفوّته معظم أدلة سيو JavaScript كلياً: الأهمية النامية لمحركات بحث الذكاء الاصطناعي وزواحف النماذج اللغوية.
لم يعد جوجل الزاحف الوحيد المهم. ChatGPT (عبر OAI-SearchBot وChatGPT-User) وPerplexity وClaude وأنظمة ذكاء اصطناعي أخرى تزحف الويب بشكل متزايد لاستقاء الإجابات. وبخلاف Googlebot، لا تعرض هذه الزواحف JavaScript عموماً. تجلب HTML الخام وتعمل بما تجده في الاستجابة الأولية.
إن اتكأ موقعك على العرض من جهة العميل، فالمحتوى الذي تراه زواحف الذكاء الاصطناعي هو هيكل HTML الفارغ. ذلك <div id="root"></div> ببضعة وسوم سكربت كل ما ينالونه. محتواك المكتوب بعناية وأوصاف منتجاتك وتحليلك الخبير: لا شيء منها يوجد في الاستجابة التي تتلقاها هذه الزواحف.
يهم هذا لثلاثة أسباب:
ظهور بحث الذكاء الاصطناعي. مع تحول مستخدمين أكثر لأدوات البحث المدعومة بالذكاء الاصطناعي للإجابات، المواقع غير المرئية لزواحف النماذج تفوّت قناة زيارات نامية. حين يسأل أحد ChatGPT أو Perplexity سؤالاً يجيبه محتواك، تريد صفحتك قابلة للاستشهاد.
بيانات تدريب النماذج. إن عجزت أنظمة الذكاء الاصطناعي عن قراءة محتواك، فلن يغذي بيانات تدريبها، مقلصاً حضور علامتك في الردود المولدة عبر الزمن.
الاستشهاد والإسناد. أدوات البحث الذكية المستشهدة بمصادر لا تستطيع الإشارة إلا لصفحات تقرؤها فعلاً. صفحة CSR تعيد هيكلاً فارغاً لن يُستشهد بها حتى لو كان محتواك المعروض أفضل إجابة متاحة.
الفجوة بين قدرة عرض جوجل وما تتعامل معه الزواحف الأخرى تتسع. يستثمر جوجل بثقل في خدمة عرض الويب. ومعظم الزواحف الأخرى لا تعرض JavaScript أصلاً، ولا مؤشر على تغير ذلك قريباً. والبناء لأدنى قاسم مشترك (HTML نظيفة في الاستجابة الأولية) النهج الوحيد المغطي كل زاحف معاً.
وزواحف وسائل التواصل (فيسبوك وTwitter/X وLinkedIn وSlack) لا تستطيع عرض JavaScript أيضاً. إن حُقنت وسوم Open Graph وترميز Twitter Card من جهة العميل، فسيظهر محتواك روابط عارية بلا صور أو عناوين أو أوصاف عند المشاركة. يتقن Vue.js هذا بتضمين وسوم OG في HTML الأولية؛ وAngular.io تاريخياً يخطئه، منتجاً معاينات اجتماعية فارغة.
الإصلاح نفسه: يضمن SSR أو SSG رؤية كل زاحف، سواء Googlebot أو GPTBot أو كاشط فيسبوك، محتواك الكامل في HTML الأولية.
كيف تدقق موقع JavaScript لمشاكل السيو؟
تدقيق سيو JS منهجي يلتقط المشاكل قبل أن تكلفك ترتيباً. إليك سير عمل خطوة بخطوة.
الخطوة 1: قارن HTML الخام بالمعروضة
لأي صفحة، قارن ما يراه Googlebot بمروره الأول (HTML الخام) بالنسخة المعروضة كاملاً.
الأدوات:
أداة URL Inspection في Google Search Console – تريك HTML المعروضة ولقطة شاشة لكيفية رؤية جوجل الصفحة
View Source مقابل Inspect Element – في متصفحك، “View Source” يعرض HTML الأولية و”Inspect Element” يعرض الـ DOM المعروض
curl أو wget – جلب رابط من سطر الأوامر يمنحك بدقة ما يراه زاحف غير عارض
curl -s https://example.com/page | grep -c "<p>"إن حوت HTML الخام صفر عناصر محتوى أو شبه صفر، فلديك اعتماد CSR.
الخطوة 2: افحص العناصر الحاسمة في HTML الأولية
تحقق من وجود هذه العناصر في استجابة HTML الخام (لا الـ DOM المعروض فقط):
| العنصر | لماذا يهم | الخطر إن اعتمد على JS |
|---|---|---|
| <title> | إشارة ترتيب أساسية | قد لا يُعالج صحيحاً |
| <meta name=”description”> | معدل النقر | لن يظهر في النتائج موثوقاً |
| <link rel=”canonical”> | معالجة التكرار | قد يخمّن جوجل خطأ |
| <meta name=”robots”> | توجيهات الزحف | قد تُتجاهل التوجيهات |
| وسوم hreflang | الاستهداف الدولي | تقديم نسخة لغة خاطئة |
| بيانات JSON-LD المنظمة | أهلية النتائج الغنية | لن تظهر المقتطفات الغنية |
| روابط تنقل <a href> | اكتشاف الصفحات | لن تُوجد الصفحات |
الخطوة 3: اختبر تغطية الفهرسة
في Google Search Console، افحص تقرير Pages للصفحات بحالة “Discovered – currently not indexed” أو “Crawled – currently not indexed”. حجم عالٍ من أي منهما على الأقسام الثقيلة بـ JavaScript يشير لمشاكل عرض أو ميزانية زحف.
وتستطيع أيضاً استخدام بحث site: بجزء نصي فريد من محتواك المعروض بـ JavaScript. إن أعاد جوجل الصفحة، فالمحتوى مفهرس. وإن لم يفعل، فخط أنابيب العرض لم يعالجها.
ولفحص سريع عبر صفحات متعددة، اختر عبارة توجد فقط في محتواك المعروض بـ JavaScript (لا في مصدر HTML) وابحث site:yourdomain.com "تلك العبارة بالضبط". افعل هذا لصفحات عبر أقسام مختلفة من الموقع لا الرئيسية فقط.
الخطوة 4: دقق الروابط الداخلية
ازحف موقعك بأداة تعرض JavaScript (Screaming Frog بتفعيل عرض JS أو Sitebulb أو Lumar) وقارن رسم الروابط بزحف غير عارض. أي روابط تظهر فقط بالنسخة المعروضة معرضة لاكتشاف متأخر.
انتبه خصوصاً لـ:
روابط التنقل الرئيسي – إن ظهرت فقط بعد تنفيذ JS، فمعمارية موقعك كاملة غير مرئية بمرور الزحف الأول
روابط ترقيم الصفحات – أزرار “تحميل المزيد” المدعومة بـ JavaScript التي لا تنتج عناصر <a href> تترك الصفحات الأعمق غير قابلة للاكتشاف
روابط مسار التنقل – تعزز تسلسل الموقع للزواحف لكن فقط إن وُجدت في HTML
روابط التذييل – معروضة قالبياً وآمنة غالباً، لكنها تستحق التحقق في تطبيقات SPA حيث يحمَّل مكون التذييل ديناميكياً
الخطوة 5: افحص توقيت العرض والموارد
باستخدام Chrome DevTools، افحص كم يستغرق JavaScript لديك للتنفيذ وعرض المحتوى. انظر:
إجمالي حجم حمولة JavaScript – استهدف إبقاء إجمالي JS دون 300-400 كيلوبايت مضغوطاً لمسارات العرض الحاسمة. كل كيلوبايت JavaScript يحتاج تنزيلاً وتحليلاً وتصريفاً وتنفيذاً قبل ظهور المحتوى. وعلى أجهزة الجوال، أزمنة التحليل والتصريف وحدها قد تبلغ مئات الميلي ثوانٍ لكل مئة كيلوبايت JS غير مضغوط
زمن عرض محتوى ذي معنى – إن استغرق المحتوى ثوانٍ عدة للظهور بعد التحميل الأولي، قد تنقضي مهلة الزواحف أو تلتقط لقطة ناقصة. اختبر بظروف شبكة مخنوقة في DevTools لمحاكاة أسوأ السيناريوهات
الموارد المحجوبة – اضمن عدم حجب ملفات JavaScript لديك بـ robots.txt، وإلا عجز Googlebot عن عرض الصفحة أصلاً. من أشيع أخطاء سيو JS العرضية، خصوصاً بعد هجرات الخوادم أو تغييرات CDN
سكربتات الأطراف الثالثة – التحليلات وودجات الدردشة وأدوات اختبار A/B وسكربتات الإعلانات كلها تضيف لزمن تنفيذ JavaScript. مع أنها لا تؤثر عادة على عرض المحتوى، تستهلك موارد قد تؤخر عرض محتواك الفعلي
كتبنا منفصلاً عن أخطاء الزحف وضبط robots.txt، فراجعهما إن رأيت تحذيرات موارد محجوبة.
الخطوة 6: تحقق بأدوات متعددة
لا أداة واحدة تمنحك الصورة الكاملة. استخدم توليفة:
| الأداة | ما تخبرك به | الكلفة |
|---|---|---|
| Google Search Console (URL Inspection) | كيف يعرض جوجل صفحتك فعلاً | مجانية |
| Chrome DevTools (View Source + Inspect) | مقارنة HTML الخام بالـ DOM المعروض | مجانية |
| Screaming Frog (وضع عرض JS) | زحف موقعي بالعرض | مدفوعة |
| Sitebulb | تدقيق عرض بصري بتنبيهات | مدفوعة |
| Google Rich Results Test | HTML المعروضة والبيانات المنظمة | مجانية |
وماذا عن ميزانية الزحف وميزانية العرض؟
ميزانية الزحف كم صفحة سيزحفها جوجل في موقعك ضمن إطار زمني. تتأثر بحجم موقعك وسلطته وسرعة استجابة خادمك وتواتر تغير المحتوى.
وميزانية العرض مفهوم مرتبط لكنه متمايز. تشير للموارد التي يخصصها جوجل لعرض JavaScript في صفحاتك. لم ينشر جوجل أرقاماً دقيقة، لكن المبدأ واضح: العرض مكلف وعلى جوجل الترتيب.
لمعظم المواقع الصغيرة والمتوسطة (دون بضعة آلاف صفحة)، ميزانيتا الزحف والعرض ليستا هماً ملحاً. سيمر جوجل عبر صفحاتك بلا صعوبة. لكن للمواقع الكبيرة الثقيلة بـ JavaScript بعشرات آلاف أو ملايين الصفحات، يصبح طابور العرض عنق زجاجة حقيقياً. إن عجز جوجل عن عرض كل صفحاتك ضمن دورة زحف، فبعض المحتوى ببساطة لن يُفهرس حتى الدورة التالية، وفي موقع بملايين الروابط قد يستمر ذلك التراكم للأبد.
كيف تقلل هدر ميزانية العرض:
قدّم المحتوى الحاسم في HTML الأولية. إن استطاع جوجل فهرسة الصفحة من HTML الخام وحدها، فلا يحتاج وضعها في طابور العرض.
استخدم بصم المحتوى لملفات JS. أضف هاشاً لأسماء ملفات JavaScript (مثل main.2a846fa617c3.js) كي يعرف جوجل متى تغيرت الملفات ولا يعيد جلب الموارد غير المتغيرة.
قلل JavaScript غير الضروري. تقسيم الشيفرة يضمن تحميل كل صفحة فقط JavaScript الذي تحتاجه بدل حزمة موحدة.
أبقِ موقعك سريعاً. استجابة الخادم البطيئة تفاقم مشكلة ميزانية العرض. غطينا سرعة الموقع بتفصيل أكبر منفصلاً.
كيف يتفاعل التحميل الكسول مع سيو JavaScript؟
يؤجل التحميل الكسول تحميل الصور أو الفيديوهات أو كتل المحتوى حتى الحاجة إليها (عادة عند دخولها إطار العرض). رائع لأداء الصفحات لكنه قد يعثّر محركات البحث إن نُفذ سيئاً.
الصور: استخدم سمة HTML الأصلية loading="lazy" بدل مكتبة تحميل كسول مبنية على JavaScript. يميز Googlebot السمة الأصلية ويتعامل معها صحيحاً. أما المحمّلات الكسولة الجافاسكربتية المبدلة data-src بـ src عند التمرير فقد تمنع Googlebot من رؤية صورك، لأن الزاحف لا يمرر الصفحة.
<img src="/image.jpg" loading="lazy" alt="Description">
<img data-src="/image.jpg" class="lazyload" alt="Description">الأول آمن للزحف والثاني خطر.
المحتوى: كن حذراً مع المحتوى النصي المحمَّل كسولاً. إن حُمّل محتوى مهم (أوصاف منتجات ونص مقالات) عبر JavaScript فقط عند تمرير المستخدم، فقد لا يطلق Googlebot ذلك التحميل أبداً. المحتوى الحاسم ينبغي حضوره دائماً في العرض الأولي حتى لو تحت الطية.
المحتوى المبوب: المحتوى المخفي خلف تبويبات مدعومة بـ JavaScript متاح عموماً لـ Googlebot أثناء العرض، لكن الأسلم تضمينه في مصدر HTML. إن تحكمت التبويبات في محتوى سيو مهم، فاضمن وجود المحتوى في الـ DOM عند تحميل الصفحة، حتى لو مخفياً بصرياً بـ CSS لا غائباً من HTML.
كيف تتعامل مع JavaScript أثناء هجرة موقع؟
إن انتقلت من موقع ساكن لإطار JavaScript (أو هاجرت بين أطر)، تتضاعف مخاطر السيو. سنغطي هجرات المواقع بتفصيل كامل في مقال قادم، لكن إليك الهموم الخاصة بـ JavaScript:
أعد توجيه كل الروابط القديمة. إن تغيرت بنية روابطك (شائع عند تبني توجيه الهاش أو أنماط مسارات جديدة)، فأعدّ إعادات توجيه 301 من كل رابط قديم لمكافئه الجديد.
لا تبدّل استراتيجية العرض وبنية الروابط معاً. هاجر شيئاً واحداً كل مرة كي تعزل سبب أي تغيرات ترتيب.
اختبر العرض قبل الإطلاق. استخدم أداة URL Inspection على بيئة التجهيز (إن أمكن) أو اختبار عرض محلياً لتأكيد رؤية Googlebot كل المحتوى.
راقب تغطية الفهرسة عن قرب بعد الإطلاق. راقب قفزات صفحات “Discovered – currently not indexed” في Search Console، فهي تشير لإخفاقات عرض.
أبقِ العرض من جهة الخادم من اليوم الأول. إن بنيت موقعاً جديداً مدعوماً بـ JS، فاضبط SSR أو SSG قبل الإطلاق. ترقيع SSR في تطبيق CSR قائم أصعب بوضوح من إعداده من البداية، متطلباً غالباً تغييرات في كيفية وصول المكونات لواجهات المتصفح وجلب البيانات وإدارة الحالة.
كيف تبدو قائمة فحص سيو JavaScript؟
إليك قائمة فحص عملية تمشي عبرها لأي موقع مدعوم بـ JavaScript:
استراتيجية العرض:
المحتوى الحاسم حاضر في استجابة HTML الأولية (غير معتمد على JS جهة العميل)
SSR أو SSG أو ISR مضبوط لكل الصفحات القابلة للفهرسة
العرض الديناميكي مستخدم فقط إجراءً مؤقتاً (إن استُخدم أصلاً)
العناصر التقنية في HTML الأولية:
وسوم العناوين معروضة من الخادم
الأوصاف التعريفية معروضة من الخادم
وسوم canonical في HTML الأولية (لا محقونة بـ JS)
توجيهات robots التعريفية في HTML الأولية
وسوم hreflang في HTML الأولية
بيانات JSON-LD المنظمة في HTML الأولية
الربط الداخلي:
كل روابط التنقل تستخدم عناصر <a href> سليمة
لا توجيه مبنياً على الهاش للصفحات القابلة للفهرسة (History API بدله)
ترقيم الصفحات يستخدم روابط قابلة للزحف
روابط التذييل والشريط الجانبي في HTML الأولية
الأداء وقابلية الزحف:
ملفات JavaScript غير محجوبة بـ robots.txt
إجمالي حمولة JS مقلل بتقسيم الشيفرة
الصور تستخدم loading="lazy" الأصلية لا تحميلاً كسولاً جافاسكربتياً
أسماء ملفات JS تستخدم بصم المحتوى للتخزين المؤقت الكفء
توافق الزواحف الاجتماعية والذكاء الاصطناعي:
وسوم Open Graph في HTML الأولية
وسوم Twitter Card في HTML الأولية
المحتوى مقروء في HTML الخام (لزواحف النماذج والذكاء الاصطناعي)
المراقبة:
أداة URL Inspection تؤكد عرض المحتوى وفهرسته
تغطية الفهرسة في Search Console بلا استبعادات متعلقة بالعرض
مقارنة HTML المعروضة بالخام جزء من دورات التدقيق المنتظمة
جعل JavaScript يعمل للبحث لا ضده
JavaScript باقٍ ولا ينبغي زواله. تمكّن أطر JS الحديثة تجارب ويب سريعة تفاعلية يتوقعها المستخدمون. لم تكن المشكلة يوماً JavaScript نفسه، بل افتراض أن محركات البحث ستتعامل مع JavaScript لديك كما يفعل المتصفح.
لن تفعل. أو على الأقل، ليس بالسرعة والموثوقية والاكتمال نفسها.
الخبر السار أن الإصلاح مفهوم جيداً. العرض من جهة الخادم والتوليد الساكن والمقاربات الهجينة كـ ISR تتيح البناء بـ JavaScript مع منح كل زاحف (جوجل وBing وأدوات بحث الذكاء الاصطناعي والمنصات الاجتماعية) محتوى كاملاً في استجابة HTML الأولية. الأطر موجودة والوثائق ناضجة والأنماط مثبتة عند التوسع.
الخطر ليس التعقيد التقني بل التأخير. كل شهر يعمل فيه موقع ثقيل بـ JS على عرض جهة عميل صرف شهر من كفاءة زحف متدهورة وفهرسة متأخرة ومحتوى غير مرئي لزواحف الذكاء الاصطناعي ومشاركة اجتماعية مكسورة. وكلما انتظرت أطول، تركت ظهوراً عضوياً أكثر على الطاولة.
إن أدرت موقعاً ثقيلاً بـ JavaScript والبحث العضوي مهم لنشاطك، فمحادثة استراتيجية العرض تحتاج الحدوث الآن، لا بعد ملاحظتك مشاكل الفهرسة في Search Console. وإن بدأت مشروعاً جديداً، فاختيار إطار بدعم SSR قوي (Next.js لـ React وNuxt.js لـ Vue) أبسط طريقة لتجنب صداع سيو JavaScript كلياً.
