تحسين محركات البحث لـJavaScript

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

ما تحسين محركات البحث لـJavaScript؟

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

هذا هو ترتيب ما يحدث لدى Google:

1. الزحف — تنزّل Google ملف HTML الأولي لعنوان URL.
2. العرض — تشغّل Google JavaScript الخاص بالصفحة في متصفح لبناء الصفحة المكتملة (خطوة العرض).
3. الفهرسة — تقرأ Google الصفحة المكتملة وتحفظها.

توثق Google هذه بوصفها المراحل الرئيسية الثلاث لمعالجة تطبيقات الويب المبنية على JavaScript.

إذا لم يظهر محتواك إلا بعد تشغيل JavaScript، فعلى Google أن تعرض الصفحة بنجاح قبل أن تتمكن من رؤيته. وهي تفعل ذلك في معظم الأحيان. وعندما لا تفعل، قد يختفي محتواك من نتائج البحث بهدوء.

الخبر الجيد أولاً

JavaScript ليس سيئاً لتحسين محركات البحث. تشغّل Google إصداراً حديثاً من Chrome ويمكنها تنفيذ JavaScript نفسه الذي ينفذه زوارك. أما الخوف القديم — “Google can’t read JavaScript” — الترجمة: «لا تستطيع Google قراءة JavaScript» فلم يعد صحيحاً.

أما ما قد يحدث خطأً فهو أكثر تحديداً:

• يحتاج محتواك إلى نقرة أو تمرير ليُحمّل، وGoogle لا تنقر ولا تمرر. Evidence for this claim Google Search does not interact with a page, so lazy-loaded content should load when it becomes visible in the viewport rather than requiring user interaction. Scope: Google Search's documented rendering behavior for lazy-loaded content; other crawlers can behave differently. Confidence: high · Verified: 2026-07-14 Google Search Central: Fix lazy-loaded content
• روابطك ليست روابط حقيقية (بل أزرار أو معالجات نقر)، لذلك لا تستطيع Google اتباعها. Evidence for this claim Google can reliably discover links only when they are HTML anchor elements with an href attribute. Scope: Link discovery by Google Search; this does not claim that every discovered URL will be crawled or indexed. Confidence: high · Verified: 2026-07-14 Google Search Central: Make your links crawlable
• ربما حظرت ملفات JavaScript أو CSS عن طريق الخطأ في robots.txt، ولذلك لا تستطيع Google عرض الصفحة على نحو صحيح.
• تبدو الصفحة سليمة في متصفحك، لكن المحتوى لا يظهر مطلقاً في طريقة العرض المعروضة لدى Google.

قائمة التحقق البسيطة

• قارن HTML الأولي (النقر بزر الفأرة الأيمن ← عرض المصدر) بـHTML المعروض (أداة فحص عنوان URL في Google Search Console). إذا غاب محتوى مهم عن طريقة العرض المعروضة، فهذه هي المشكلة.
• تأكد من أن الروابط عناصر <a href> حقيقية، لا معالجات نقر على <div>.
• لا تحظر ملفات JavaScript أو CSS في robots.txt.
• إذا كانت ميزة ما تحتاج إلى نقرة أو تمرير لتحميل المحتوى، فتأكد من إمكانية الوصول إلى ذلك المحتوى أيضاً بطريقة أخرى.
• للمحتوى الذي يجب حتماً أن يحقق ترتيباً، فضّل العرض من جهة الخادم أو بنية ثابتة/معروضة مسبقاً يكون فيها المحتوى موجوداً بالفعل في HTML الأولي. Evidence for this claim Google describes server-side rendering or pre-rendering as a good idea because it makes a website faster for users and crawlers. Scope: Google Search guidance for JavaScript sites; the source does not prescribe one framework or guarantee indexing. Confidence: high · Verified: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics

هل تريد النسخة الأعمق — أنماط الفشل الحقيقية، وفخ التمرير اللانهائي الذي يؤدي إلى فهرسة صفحتين كصفحة واحدة، وكيفية اختبار HTML المعروض؟ انتقل إلى علامة التبويب متقدم. ولمعرفة كيفية عمل عارض Google نفسه وأي إعداد عرض تختار، راجع صفحة العرض.

الخلاصة — تستطيع Google تشغيل JavaScript، لذا فإن “can Google read JS?” الترجمة: «هل تستطيع Google قراءة JS؟» هو السؤال الخطأ. أنماط الفشل هي التكافؤ (DOM الأولي مقابل المعروض)، والتفاعل (لا تمرر Google الصفحة ولا تنقر عليها)، والحالة (العارض بلا حالة)، و التوقيت. أبقِ الروابط عناصر ارتساء <a href> حقيقية، ولا تحظر JS/CSS، ونفّذ التحميل الكسول عند دخول نافذة العرض لا عند التفاعل، وأعد حالات حقيقية لأخطاء 404 من جهة العميل، وتذكر أن noindex أولياً قد يمنع العرض قبل أن يتمكن JavaScript من إزالته. ادمج التوجيهات التي عولجت فعلاً، لكن لا تفترض وجود فائز عام بين الأولي والمعروض. انتبه خصوصاً إلى التمرير اللانهائي: فقد تشغّل نافذة عرض طويلة أداة التحميل وتدمج عنواني URL في صفحة مفهرسة واحدة. لتفاصيل العارض الداخلية واختيار وضع العرض، راجع العرض.

هل تستطيع Google قراءة JavaScript؟ نعم — لكن هذا ليس السؤال

تعالج Google تطبيقات JavaScript في ثلاث مراحل: “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (الترجمة العربية) «تعالج Google تطبيقات الويب المبنية على JavaScript في ثلاث مراحل رئيسية: 1. الزحف 2. العرض 3. الفهرسة». تشغّل المرحلة الوسطى JS الخاص بك في Chrome دائم التحديث ومن دون واجهة رسومية لبناء DOM الذي تتم فهرسته. “Rendering is important because websites often rely on JavaScript to bring content to the page, and without rendering Google might not see that content.” (الترجمة العربية) «العرض مهم لأن مواقع الويب تعتمد غالباً على JavaScript لجلب المحتوى إلى الصفحة، ومن دون العرض قد لا ترى Google ذلك المحتوى».

إذن تستطيع Google تشغيل JavaScript. أما الأسئلة المفيدة فهي أكثر تحديداً:

• التكافؤ — هل يحتوي DOM المعروض فعلاً على ما تعتقد أنه يحتويه؟
• التفاعل — هل يتطلب أي شيء تمريراً أو نقراً لن تنفذه Google؟
• الحالة — هل تعتمد على ملفات تعريف الارتباط أو localStorage التي يمحوها العارض عديم الحالة؟
• التوقيت — هل يؤجَّل المحتوى الأساسي خلف JavaScript بطيء أو متأخر؟

فيما يخص التوقيت تحديداً: تضع Google الصفحة التي زُحف إليها (والتي أعادت 200) في قائمة انتظار العرض، و*“the page may stay on this queue for a few seconds, but it can take longer than that.”* (الترجمة العربية) «قد تبقى الصفحة في قائمة الانتظار هذه لبضع ثوانٍ، لكن الأمر قد يستغرق وقتاً أطول». لا يوجد تأخير ثابت أو مهلة منشورة — والصفحة التي تعيد حالة غير 200، أو تبدأ بتوجيه noindex، قد تتجاوز قائمة انتظار العرض بدلاً من انتظار JavaScript ليغيرها.

توجد آليات كيفية العرض لدى Google — خدمة عرض الويب، وانعدام الحالة، والتخزين المؤقت، وخرافة «الموجتين» — في صفحة العرض. سأركز هنا على المشكلات والإصلاحات العملية.

يجب أن تكون الروابط عناصر ارتساء <a href> حقيقية

هذا هو أكثر أخطاء تحسين محركات البحث لـJS شيوعاً. “Google can only discover your links if they are <a> HTML elements with an href attribute.” (الترجمة العربية) «لا تستطيع Google اكتشاف روابطك إلا إذا كانت عناصر HTML من نوع <a> ولها سمة href». عنصر <div> قابل للنقر وله معالج onclick غير مرئي لـGoogle بوصفه رابطاً — فلن تتبعه، وقد لا تزحف إلى الصفحات التي تعتمد عليه للاكتشاف. لا بأس مطلقاً في حقن الروابط باستخدام JavaScript، ما دامت تنتهي كعناصر ارتساء <a href> حقيقية في DOM المعروض. لكن عناصر الارتساء المعروضة هذه تُحلل بعد تشغيل JavaScript — فوجود الرابط في DOM المعروض يجعله قابلاً للاكتشاف، ولا يَعِد بأن عنوان URL سيُزحف إليه أو يُفهرس أو يُعامل مثل رابط موجود في HTML الأولي.

المحتوى المحمّل كسولاً والمقيّد بالتفاعل

لا يتصرف العارض كمستخدم فضولي: “Google Search does not interact with your page.” (الترجمة العربية) «لا يتفاعل بحث Google مع صفحتك». فلا تمرير ولا نقر ولا تحويم. لذلك لن يظهر أي محتوى لا يُحمّل إلا عند أحد هذه الأحداث.

إرشادات Google: حمّل المحتوى عندما يدخل نافذة العرض، لا عندما يتصرف المستخدم — “make sure that your lazy-loading implementation loads all relevant content whenever it is visible in the viewport,” (الترجمة العربية) «تأكد من أن تنفيذ التحميل الكسول يحمّل كل المحتوى ذي الصلة متى كان مرئياً في نافذة العرض» و*“don’t add lazy-loading to content that is likely to be immediately visible when a user opens a page.”* (الترجمة العربية) «لا تضف التحميل الكسول إلى محتوى يُرجح أن يكون مرئياً فور فتح المستخدم للصفحة». استخدم IntersectionObserver أو loading="lazy" الأصلي للصور — لا تستخدم مطلقاً معالج تمرير أو نقر — حتى يُحمّل المحتوى أثناء عرض عادي.

التمرير اللانهائي: عندما تُفهرس صفحتان كصفحة واحدة

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

يمكن أن يعرض Googlebot الصفحة في نافذة عرض أطول بكثير من نافذة متصفح نموذجية. لا تنشر Google حجماً دقيقاً لنافذة العرض — ويمكن أن يتغير — لذلك لا تصمم بناءً على رقم محدد؛ بل اختبر تنفيذك. المهم هو الآلية: إذا كانت أداة تحميل التمرير اللانهائي تعمل بناءً على موضع التمرير أو ارتفاع نافذة العرض، فقد تؤدي نافذة عرض أطول من المتوقع إلى تشغيل أداة التحميل أثناء العرض نفسه — فيُلحق محتوى المقالة أو صفحة المنتج التالية بالـDOM نفسه. عندها يكون محتوى عنواني URL مختلفين قد عُرض معاً، وقد تفهرسهما Google كصفحة واحدة. من واقع تجربتي، “occasionally, two pages get indexed as one” (الترجمة العربية) «تُفهرس صفحتان أحياناً كصفحة واحدة» — فقد ظهرت لدي صفحات على أنها «غير مفهرسة» بينما كانت مفهرسة فعلياً كجزء من صفحة أخرى (عادةً المنشور السابق في الخلاصة)، لأن “when Google resized the viewport to be longer … it triggered the infinite scroll and loaded another article in when it was rendering.” (الترجمة العربية) «عندما أعادت Google تغيير حجم نافذة العرض لتصبح أطول… شغّل ذلك التمرير اللانهائي وحمّل مقالة أخرى أثناء العرض». تحقق مما إذا كان إعدادك يفعل ذلك بفحص HTML المعروض في فحص عنوان URL لصفحة تتوقع أن تتوقف قبل ذلك — لا تفترض حجماً ولا تفترض أنك في مأمن.

هناك مستويان لتنفيذ ذلك على النحو الصحيح.

اجعل التمرير اللانهائي ملائماً للبحث من الأساس. ادعم التحميل المقسّم إلى صفحات تحت التمرير اللانهائي. يجب أن يكون لكل جزء “its own persistent, unique URL,” (الترجمة العربية) «عنوان URL دائم وفريد خاص به» وأن يظل المحتوى على كل عنوان URL كما هو في كل مرة يُحمّل فيها، وأن تتجنب المعلمات النسبية مثل ?date=yesterday، وأن “link sequentially to the individual URLs so that search engines can discover the URLs in a paginated set,” (الترجمة العربية) «تربط بعناوين URL الفردية بالتتابع حتى تتمكن محركات البحث من اكتشاف عناوين URL في مجموعة مقسّمة إلى صفحات»، وعندما يُحمّل جزء جديد عند التمرير يجب أن “update the displayed URL using the History API.” (الترجمة العربية) «تحدّث عنوان URL المعروض باستخدام History API». استخدم روابط ترقيم صفحات <a href> حقيقية وعناوين URL فريدة — “don’t use URL fragment identifiers” (الترجمة العربية) «لا تستخدم معرّفات أجزاء URL» (الجزء الذي يلي #) لأرقام الصفحات، لأن Google تتجاهلها. وكما أقول في دليلي لتحسين محركات البحث لـJavaScript، “if you have an infinite scroll setup, I still recommend a paginated page version so that Google can still crawl properly.” (الترجمة العربية) «إذا كان لديك إعداد تمرير لانهائي، فما زلت أوصي بنسخة مقسّمة إلى صفحات حتى تظل Google قادرة على الزحف على النحو الصحيح».

إذا كانت أداة تحميل معيبة تدمج الصفحات فعلياً، فأسرع إصلاح مباشر هو: “block the JavaScript file that handles the infinite scrolling so the functionality can’t trigger.” (الترجمة العربية) «احظر ملف JavaScript الذي يتولى التمرير اللانهائي حتى لا تتمكن الوظيفة من العمل». إذا لم تستطع أداة التحميل العمل أثناء العرض، فلن تستطيع إلحاق محتوى الصفحة التالية، وسيعود كل عنوان URL إلى العرض بوصفه نفسه.

أخطاء 404 الوهمية بعد التوجيه من جهة العميل

يمكن لتطبيقات الصفحة الواحدة تبديل المحتوى من دون تغيير رمز حالة HTTP، ولذلك قد تظل طريقة عرض «غير موجود» تعيد 200. قد تصنف Google تلك الاستجابة على أنها خطأ 404 وهمياً بعد تقييم المحتوى المعاد، لكن الجلب الثابت وحده لا يستطيع إثبات أن Google أجرت ذلك التصنيف. هناك إصلاحان: التنقل باستخدام History API، وفي حالة عدم العثور الحقيقية إما التوجيه إلى عنوان URL يعيد حالة 404 حقيقية أو إضافة وسم noindex. ولا تعتمد على أجزاء URL في التوجيه — “the AJAX-crawling scheme has been deprecated since 2015, so you can’t rely on URL fragments to work with Googlebot.” (الترجمة العربية) «أُلغي نظام الزحف إلى AJAX منذ 2015، لذلك لا يمكنك الاعتماد على أجزاء URL للعمل مع Googlebot».

تواجه إعادة التوجيه من جهة العميل مشكلة الأدلة نفسها: فقد تظل الاستجابة الأولية 200 حتى يعمل JavaScript. لا تدعم Google عمليات إعادة التوجيه باستخدام JavaScript إلا كحل احتياطي عندما يتعذر استخدام عمليات إعادة التوجيه من جهة الخادم أو عبر meta-refresh. أبلغ عن الحالة الثابتة والتنقل المعروض المرصود كلّاً على حدة؛ ولا تعِد كتابة حالة HTTP في التدقيق ولا تسمِّ كل تغيير معروض في عنوان URL إعادة توجيه.

لا تحظر JavaScript أو CSS في robots.txt

لن تعرض Google ملفات JavaScript المحظورة أو الصفحات المحظورة. قد تؤدي قاعدة في robots.txt تمنع حزمتك (أو دليل /_next/ أو /static/ أو /assets/ الذي توجد فيه) إلى تعطيل العرض بالكامل — تجلب Google الغلاف، ولا تستطيع تشغيل البرامج النصية، وتفهرس صفحة فارغة. تحقق من موارد الصفحة في فحص عنوان URL بحثاً عن أي شيء محظور.

تكافؤ DOM وتوجيهات robots المدركة لمراحل المعالجة

قارن HTML الأولي (عرض المصدر) بـHTML المعروض (فحص عنوان URL). المحتوى الموجود في HTML المعروض وحده يظل قابلاً للفهرسة — إذا تم عرضه. أما المحتوى غير الموجود في أي منهما فلا وجود له لدى Google.

هناك خطر واحد في ترتيب المراحل توثقه Google مباشرةً: “When Google encounters the noindex tag, it may skip rendering and JavaScript execution, which means using JavaScript to change or remove the robots meta tag from noindex may not work as expected.” (الترجمة العربية) «عندما تصادف Google وسم noindex، قد تتجاوز العرض وتنفيذ JavaScript، ما يعني أن استخدام JavaScript لتغيير وسم robots الوصفي من noindex أو إزالته قد لا يعمل كما هو متوقع». إذا كان HTML الأولي يرسل noindex أولياً أردت استبداله باستخدام JavaScript، فقد تتصرف Google وفق ذلك noindex الأولي ولا تشغّل أبداً البرنامج النصي الذي كان سيزيله.

لا تحوّل هذا إلى قاعدة عامة تقول إن «المعروض يفوز». فالتوفيق خاص بكل حقل:

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

اختر وضع عرض يضع المحتوى في DOM

تعود معظم مخاطر تحسين محركات البحث لـJS إلى كيفية إنتاج HTML. النسخة المختصرة: يضع SSR والعرض الثابت/المسبق والإماهة المحتوى في DOM (أو يدخله إليه سريعاً)، مما يقلل مقدار اعتماد ظهورك على نجاح العارض؛ أما العرض الكامل من جهة العميل فيجعل مزيداً من الأمور رهناً باكتمال العرض على النحو الصحيح وفي الوقت المناسب كل مرة. العرض الديناميكي حل التفافي لا خياراً مكافئاً — وفق إرشادات Google التي كان آخر تحديث لها في ديسمبر 2025، تصف Google العرض الديناميكي بأنه حل التفافي لا حلاً طويل الأجل، وتوصي بدلاً منه بالعرض من جهة الخادم أو العرض الثابت أو الإماهة. وكما صغتها في دليلي لتحسين محركات البحث لـJavaScript، “any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines.” (الترجمة العربية) «سيكون أي إعداد من نوع SSR أو العرض الثابت أو العرض المسبق ملائماً لمحركات البحث». توجد القائمة الكاملة — CSR وSSR و SSG والإماهة وISR والحافة والبث والعرض الديناميكي — مع جدول للمفاضلات في صفحة العرض. وتصف Google بشكل منفصل العرض من جهة الخادم أو العرض المسبق بأنه فكرة جيدة للمستخدمين وبرامج الزحف. Evidence for this claim Google describes server-side rendering or pre-rendering as a good idea because it makes a website faster for users and crawlers. Scope: Google Search guidance for JavaScript sites; the source does not prescribe one framework or guarantee indexing. Confidence: high · Verified: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics

كيفية الاختبار

فحص عنوان URL في Search Console هو المرجع الحاسم: شغّل اختباراً مباشراً، ثم انظر إلى HTML المعروض ولقطة الشاشة وموارد الصفحة/رسائل وحدة التحكم لمعرفة ما حُمّل وما أخفق. يتيح اختبار النتائج المنسّقة فحصاً سريعاً لـHTML المعروض. وعلى نطاق واسع، استخدم برنامج زحف ينفذ JavaScript (Ahrefs Site Audit أو Screaming Frog في وضع عرض JS) لمقارنة الأولي بالمعروض عبر الموقع.

JavaScript ليس سيئاً لتحسين محركات البحث ولا شريراً. إنه فقط مختلف عما اعتاده كثير من مختصي تحسين محركات البحث. تعاون مع مطوريك، وضع محتواك المهم في DOM، ودع أدوات Google نفسها — لا افتراضاتك — تحكم في ما تم عرضه.

إلى أين تذهب تالياً: مجموعة تحسين محركات البحث لـJavaScript

هذا المحور هو الخريطة. كل موضوع أدناه شرح متعمق مستقل:

العرض والبنية

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

أدلة خاصة بأطر العمل

• تحسين محركات البحث لـReact — لماذا ينشئ React المعتمد أولاً على CSR مخاطر فهرسة، وكيف تعرض Google تطبيقات React، وReact Router وHistory API، وreact-helmet-async للوسوم الوصفية، ومتى تستخدم Next.js.
• تحسين محركات البحث لـAngular — إعدادات SPA الافتراضية في Angular، و@angular/ssr (خليفة Angular Universal)، وخدمتا Title وMeta المدمجتان، والعرض المسبق، والإماهة التزايدية في Angular الحديث.
• تحسين محركات البحث لـNext.js — Pages Router مقابل App Router، وMetadata API، وnext/image وCWV، وتوقيت ISR وGooglebot، وخرائط الموقع، وأكثر أخطاء تحسين محركات البحث لـNext.js شيوعاً.
• تحسين محركات البحث لـNuxt — SSR افتراضياً، وuseSeoMeta()، وأوضاع العرض في Nuxt، ومنظومة وحدة @nuxtjs/seo، وكيف يُقارن Nuxt بـVue المجرد من حيث قابلية الفهرسة.
• تحسين محركات البحث لـVue — إعداد CSR الافتراضي في Vue 3 وما يعنيه لبرامج الزحف، وcreateWebHistory()، و@unhead/vue، وخيارات العرض المسبق من دون إطار فوقي، ومتى يكون Nuxt الاختيار الصحيح.
• تحسين محركات البحث لـSvelte — Svelte مقابل SvelteKit، وSSR افتراضياً في SvelteKit، و<svelte:head>، وفخ adapter-static مع ssr: false، وخيارات المحولات، والآثار على برامج زحف الذكاء الاصطناعي.
• تحسين محركات البحث لـAstro — انعدام JS افتراضياً، وبنية الجزر، و@astrojs/sitemap، وastro:assets، وView Transitions وHistory API، وسلوك احتياطي Server Islands، ومزايا Core Web Vitals لدى Astro.

ملخص الذكاء الاصطناعي

خلاصة مركزة للنسخة المتقدمة:

• السؤال «Can Google read JS?» سؤال خاطئ — فهي تستطيع ذلك. وتتمثل أنماط الفشل في التكافؤ (الأولي مقابل المعروض)، والتفاعل (لا تمرر Google الصفحة ولا تنقر عليها)، والحالة (العارض بلا حالة)، والتوقيت.
• لا يوجد تأخير ثابت للتوقيت — تضع Google صفحة بحالة 200 في قائمة انتظار العرض، وقد تنتظر «بضع ثوانٍ» أو أكثر، من دون مهلة منشورة؛ وقد تتجاوز الصفحة ذات الحالة غير 200 أو التي تبدأ بتوجيه noindex قائمة انتظار العرض بالكامل.
• يجب أن تكون الروابط ارتساءات <a href> حقيقية — فـonclick على <div> غير مرئي كرابط. لا مشكلة في حقن الروابط باستخدام JS إذا انتهت إلى ارتساءات، لكن الارتساءات المعروضة تُحلل بعد تشغيل JS — أي إنها قابلة للاكتشاف، لا ضماناً للزحف أو الفهرسة.
• نفّذ التحميل الكسول عند نافذة العرض، لا عند التفاعل — فـ Google «لا تتفاعل مع صفحتك». استخدم IntersectionObserver أو التحميل الكسول الأصلي، ولا تجعل المحتوى رهين التمرير أو النقر.
• قد يدمج التمرير اللانهائي صفحتين في صفحة واحدة — يستطيع Googlebot العرض عند نافذة أطول من المتصفح المعتاد (لا يوجد حجم دقيق منشور — اختبر إعدادك)، وقد يؤدي ذلك إلى تشغيل أداة التحميل وإضافة محتوى الصفحة التالية. الإصلاح: عناوين URL مرقمة + روابط <a href> حقيقية + History API؛ وإذا كانت أداة التحميل تدمج الصفحات، فاحظر ملف JS الخاص بها.
• أخطاء 404 الوهمية بعد التوجيه من جهة العميل — أعد 404 حقيقية أو noindex؛ ولا تفهرس قوالب فارغة، ولا تعتمد على أجزاء عناوين URL (فقد أُلغي زحف AJAX في 2015).
• لا تحظر JS/CSS في robots.txt — فلن تعرض Google الصفحة من ملفات محظورة.
• قد تمنع noindex إزالة نفسها — قد تتجاوز Google العرض عندما ترى noindex أولياً، ولذلك قد لا يعمل JS المقصود به إزالته.
• تكافؤ DOM وترتيب المراحل (وسوم robots الوصفية) — قارن الأولي بالمعروض، وتذكر أن noindex الأولي قد يوقف العرض. طبّق قواعد الدمج فقط على التوجيهات التي عولجت فعلاً، واختبر تكافؤ العنوان الأساسي بقواعده الخاصة.
• يغير وضع العرض التبعية لا النتيجة — يضع SSR أو الموقع الثابت أو العرض المسبق أو hydration المحتوى في DOM مبكراً، فيقل الاعتماد على العرض؛ أما CSR الكامل فيعتمد عليه أكثر، والعرض الديناميكي حل مؤرخ من Google وليس خياراً مساوياً. راجع صفحة العرض للتفاصيل.
• اختبر باستخدام URL Inspection (HTML المعروض ولقطة الشاشة ووحدة التحكم)، واختبار النتائج المنسقة، وزاحف يعرض JavaScript.

الوثائق الرسمية

وثائق المصادر الأولية من محركات البحث.

Google

• فهم أساسيات JavaScript SEO — المراحل الثلاث، والروابط القابلة للزحف، واختبار HTML المعروض.
• إصلاح مشكلات JavaScript المتعلقة بالبحث — معالجة أخطاء 404 الوهمية، وHistory API، وقيود العارض.
• إصلاح المحتوى المحمّل كسولاً — التحميل عند نافذة العرض (لا عند التفاعل)، والتمرير اللانهائي الملائم للبحث.
• ترقيم صفحات التجارة الإلكترونية وتحميل الصفحات تدريجياً — عناوين URL فريدة، وروابط <a href>، وسبب تجاهل Google لمعرفات الأجزاء.
• دليل متعمق لكيفية عمل بحث Google — موضع العرض في مسار الزحف ← الفهرسة ← العرض.

Bing / Microsoft

• سلسلة bingbot: JavaScript والعرض الديناميكي والإخفاء — نظرة Bing إلى عرض JS والعرض الديناميكي.

اقتباسات من المصدر

تصريحات مسجلة من Google (مع بعض ما كتبته بنفسي). كل رابط لمحرك بحث هو رابط عميق يقفز إلى المقطع المقتبس في صفحة المصدر.

Google — العرض والروابط

• “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (الترجمة العربية) «تعالج Google تطبيقات الويب المبنية على JavaScript في ثلاث مراحل رئيسية: 1. الزحف 2. العرض 3. الفهرسة». انتقل إلى الاقتباس
• “Google can only discover your links if they are <a> HTML elements with an href attribute.” (الترجمة العربية) «لا تستطيع Google اكتشاف روابطك إلا إذا كانت عناصر HTML من نوع <a> ذات سمة href». انتقل إلى الاقتباس
• “Rendering is important because websites often rely on JavaScript to bring content to the page, and without rendering Google might not see that content.” (الترجمة العربية) «العرض مهم لأن مواقع الويب تعتمد غالباً على JavaScript لجلب المحتوى إلى الصفحة، ومن دون العرض قد لا ترى Google ذلك المحتوى». انتقل إلى الاقتباس
• “The page may stay on this queue for a few seconds, but it can take longer than that.” (الترجمة العربية) «قد تبقى الصفحة في قائمة الانتظار هذه لبضع ثوانٍ، لكن الأمر قد يستغرق وقتاً أطول» — بخصوص توقيت قائمة انتظار العرض، فلا يوجد تأخير ثابت منشور. انتقل إلى الاقتباس
• “When Google encounters the noindex tag, it may skip rendering and JavaScript execution, which means using JavaScript to change or remove the robots meta tag from noindex may not work as expected.” (الترجمة العربية) «عندما تصادف Google وسم noindex فقد تتجاوز العرض وتنفيذ JavaScript، ولذلك قد لا يعمل استخدام JavaScript لتغيير وسم robots الوصفي أو إزالة noindex كما هو متوقع». انتقل إلى الاقتباس

Google — التفاعل والتحميل الكسول والتمرير اللانهائي

• “Google Search does not interact with your page.” (الترجمة العربية) «لا يتفاعل بحث Google مع صفحتك». انتقل إلى الاقتباس
• “…loads all relevant content whenever it is visible in the viewport.” (الترجمة العربية) «يحمّل كل المحتوى ذي الصلة متى كان مرئيًا في نافذة العرض». انتقل إلى الاقتباس
• “Give each chunk its own persistent, unique URL.” (الترجمة العربية) «امنح كل جزء عنوان URL دائمًا وفريدًا خاصًا به» — للتمرير اللانهائي الملائم للبحث. انتقل إلى الاقتباس
• “Don’t use URL fragment identifiers (the text after a # in a URL) for page numbers in a collection. Google ignores fragment identifiers.” (الترجمة العربية) «لا تستخدم معرّفات أجزاء URL، أي النص بعد #، لأرقام الصفحات في مجموعة؛ إذ تتجاهل Google معرّفات الأجزاء». انتقل إلى الاقتباس

Google — أخطاء 404 الوهمية والتوجيه

• “We recommend using the History API to load different views.” (الترجمة العربية) «نوصي باستخدام History API لتحميل طرق عرض مختلفة». انتقل إلى الاقتباس

Patrick Stox (من عملي — JavaScript SEO: A Definitive Guide)

• فيما يخص وسوم robots الوصفية تحديداً: “With meta robots tags, Google is always going to take the most restrictive option it sees — no matter the location… Google will choose the most restrictive statements between HTML and the rendered version of a page.” (الترجمة العربية) «مع وسوم robots الوصفية، ستختار Google دائماً الخيار الأكثر تقييداً الذي تراه، بغض النظر عن الموضع… وستختار البيانات الأكثر تقييداً بين HTML ونسخة الصفحة المعروضة».
• “If you have an infinite scroll setup, I still recommend a paginated page version so that Google can still crawl properly.” (الترجمة العربية) «إذا كان لديك إعداد للتمرير اللانهائي، فما زلت أوصي بنسخة مرقمة من الصفحة حتى تتمكن Google من الزحف إليها بصورة صحيحة».
• بخصوص الدمج: “occasionally, two pages get indexed as one” (الترجمة العربية) «تُفهرس صفحتان أحياناً كصفحة واحدة» — ويحدث ذلك عندما “Google resized the viewport to be longer … it triggered the infinite scroll and loaded another article in when it was rendering.” (الترجمة العربية) «عندما وسّعت Google نافذة العرض شغّل ذلك التمرير اللانهائي وحمّل مقالة أخرى أثناء العرض». والإصلاح هو: “block the JavaScript file that handles the infinite scrolling so the functionality can’t trigger.” (الترجمة العربية) «احظر ملف JavaScript الذي يتولى التمرير اللانهائي حتى لا تتمكن الوظيفة من العمل».

قائمة فحص JavaScript SEO

مرور سريع للتأكد من أن Google تستطيع عرض المحتوى المعتمد على JS وفهرسته:

• يظهر المحتوى المهم في HTML المعروض (تحقق من URL Inspection لا من View Source فقط).
• الروابط ارتساءات <a href> حقيقية — وليست معالجات onclick على <div> أو <span>.
• ملفات JavaScript وCSS غير محظورة في robots.txt.
• لا يوجد محتوى رهين بنقرة أو تمرير أو تحويم (فـ Google لا تتفاعل)؛ حمّل كسولاً عند نافذة العرض باستخدام IntersectionObserver أو loading="lazy".
• لا يُحمّل المحتوى الظاهر فوراً أعلى الجزء المرئي تحميلاً كسولاً.
• تتطابق توجيهات robots بين HTML الأولي والمعروض (ولا يحقن JS noindex) — وتأخذ Google الأكثر تقييداً.
• تعيد تغييرات المسارات من جهة العميل التي تصل إلى مورد مفقود 404 حقيقية أو noindex (لا قوالب 404 وهمية).
• للتمرير اللانهائي نسخة مرقمة ذات عناوين URL فريدة وروابط <a href> حقيقية وتحديثات History API — ولا تدمج الصفحات عند نافذة عرض طويلة.
• يستخدم المحتوى الذي يجب أن يحقق ترتيباً SSR أو بنية ثابتة أو عرضاً مسبقاً، لا CSR كاملاً (راجع صفحة العرض).
• تحققت سريعاً من لقطة الشاشة المعروضة وأخطاء وحدة التحكم في الاختبار المباشر لـ URL Inspection.

النماذج الذهنية

1. السؤال «Can Google run my JS?» سؤال خاطئ. تستطيع ذلك. والأسئلة الحقيقية تتعلق بالتكافؤ والتفاعل والحالة والتوقيت:

• التكافؤ — هل يحتوي DOM المعروض على ما تعتقد أنه يحتويه؟
• التفاعل — هل يتطلب أي شيء تمريراً أو نقراً لن تنفذه Google؟
• الحالة — هل تعتمد على cookies أو localStorage يمسحها العارض بلا حالة؟
• التوقيت — هل يتأخر المحتوى المهم خلف JavaScript بطيء أو متأخر؟

2. إذا لم يكن المحتوى في DOM المعروض فهو غير موجود. يعرض View Source HTML الأولي؛ ويعرض URL Inspection DOM المعروض. وتتخذ قرارات الفهرسة استناداً إلى DOM المعروض — لذلك فهذا هو الأثر الذي ينبغي فحصه كل مرة.

3. روابط حقيقية أو لا روابط. يعتمد الاكتشاف على ارتساءات <a href>. أما معالجات النقر والأزرار والتنقل عبر JS الذي لا ينتج ارتساءً فهي طرق مسدودة للزحف.

4. صمّم لروبوت لا يلمس الصفحة أبداً. لا تمرير ولا نقر ولا تحويم. وإذا احتاج المحتوى إلى إجراء كي يظهر، فافترض أن Google لن تراه — وحمّله عند نافذة العرض بدلاً من ذلك.

5. اختبر فخ نافذة العرض الطويلة في التمرير اللانهائي. قد يعرض Googlebot عند نافذة أطول من المتصفح المعتاد (لا يوجد حجم ثابت منشور، لذلك لا تصمم على رقم محدد)، وقد تُشغّل أداة تعتمد على التمرير أو الارتفاع أثناء العرض وتدمج الصفحة التالية. صمّم للتعامل مع ذلك: عناوين URL مرقمة + روابط حقيقية + History API؛ وإذا كانت الأداة تدمج الصفحات فعلاً، فاحظر ملف JS الخاص بها.

6. دع الأدوات تحسم الأمر. متصفحك ليس Googlebot. فـ HTML المعروض ولقطة الشاشة ووحدة التحكم في URL Inspection هي مصدر الحقيقة — لا عبارة «يبدو سليماً على جهازي».

مطبات JavaScript SEO — ورقة غش

أي وضع عرض؟ (التبعية على نجاح العرض)

هذا ليس ضماناً للنتيجة — فما زال على SSR/SSG/hydration أن يُعرض بصورة صحيحة وأن يجتاز كل فحص آخر في هذه المقالة. للاطلاع على التفصيل الكامل (ISR وedge وstreaming والعرض الديناميكي ومقايضاته)، راجع صفحة العرض.

شاهد ما يراه Googlebot

تختبئ أخطاء العرض في الفجوة بين HTML الأولي (ما يرسله الخادم) وHTML المعروض (ما يوجد بعد تشغيل JS). إليك بعض الفحوص السريعة عبر سطر الأوامر قبل اللجوء إلى زاحف كامل.

اجلب HTML الأولي (ما يعود قبل تشغيل أي JS)

macOS / Linux:

# Raw HTML as the server sends it — this is the "first fetch"
curl -sL -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/page/ -o raw.html

# Is your important text actually in the raw HTML? (empty result = JS-dependent)
grep -o "Your headline text" raw.html

Windows (PowerShell):

$ua = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://example.com/page/" -UserAgent $ua -OutFile raw.html
Select-String -Path raw.html -Pattern "Your headline text"

إذا كان النص مفقوداً من raw.html لكنه ظاهر في متصفحك، فهذا يعني أن JavaScript أضافه — ولذلك يعتمد على العرض. أما HTML المعروض فاستخدم له «View Crawled Page → rendered HTML» في URL Inspection، أو زاحفاً يعمل بChrome بلا واجهة رسومية؛ فـcurl العادي لا يشغّل JS.

أكد أنك لا تحظر JS/CSS في robots.txt

macOS / Linux:

curl -sL https://example.com/robots.txt | grep -iE "disallow.*\.(js|css)|Disallow:\s*/(_next|static|assets|dist)"

Windows (PowerShell):

(Invoke-WebRequest "https://example.com/robots.txt").Content |
  Select-String -Pattern "Disallow.*\.(js|css)","Disallow:\s*/(_next|static|assets|dist)"

يعني توجيه Disallow المطابق لـ JavaScript أو CSS أن Google لا تستطيع عرض الصفحة بصورة صحيحة — وهذا خطأ في الغالب. كما تسرد URL Inspection موارد الصفحة المحظورة؛ أما grep فلا يلتقط إلا الحالات الواضحة بسرعة.

أدوات تصحيح JavaScript SEO

شاهد الفرق بين HTML الأولي وما تعرضه Google باستخدام Render Gap:

1. ألصق عنوان URL الكامل للصفحة التي تريد اختبارها — وتظهر أفضل النتائج مع صفحة قالب تعتمد كثيراً على JavaScript.
2. امسح فحص مكافحة إساءة الاستخدام واضغط Test page؛ فهو يجلب HTML الأولي أولاً، ولا يعرض الصفحة في Chrome بلا واجهة رسومية إلا عندما يبدو ذلك HTML قالباً فارغاً.
3. اقرأ الحكم المرمز بالألوان، ثم افحص جدول Initial HTML vs Rendered DOM بحثاً عن الصفوف الموسومة changed.
4. انتقل إلى علامة تبويب Raw vs rendered diff لرؤية ما أضافه JavaScript أو أزاله سطراً بسطر.

• URL Inspection (Google Search Console) — مصدر الحقيقة. نفّذ اختباراً مباشراً، ثم اعرض HTML المعروض ولقطة الشاشة وموارد الصفحة (ما حُمّل وما حُظر) ورسائل وحدة تحكم JavaScript.
• اختبار النتائج المنسقة — طريقة سريعة لفحص HTML المعروض والبيانات المنظَّمة لعنوان URL من دون التحقق من الموقع.
• Chrome DevTools — قارن View Source (HTML الأولي) بلوحة Elements (DOM المعروض)؛ وتكشف وحدة التحكم أخطاء JS التي قد تفرغ المحتوى.
• زواحف عرض JavaScript — ينفذ Ahrefs Site Audit وScreaming Frog SEO Spider (بوضع عرض JS) JavaScript كي يقارنا الأولي بالمعروض على نطاق واسع.
• أدوات عرض المصدر المعروض — إضافات متصفح تعرض DOM المعروض إلى جانب الأولي للمراجعة السريعة.
• تحليل سجلات الخادم — أكد أن Googlebot يجلب موارد JS/CSS فعلاً (راجع تحليل ملف السجل).

مطالبات لتشخيص JavaScript SEO

قارن HTML الأولي بالمعروض

ألصق الاستجابة الأولية وDOM المعروض لعنوان URL نفسه. أزل بيانات العملاء والرموز أولاً.

Act as a technical SEO reviewer. Compare RAW_HTML and RENDERED_HTML below. Report only
meaningful differences in title, meta robots, canonical, headings, body copy,
structured data, and crawlable <a href> links. For each difference, label its likely
indexing impact, show the exact conflicting snippets, and give a verification step.
Do not infer content that is not present.

RAW_HTML:
[paste]

RENDERED_HTML:
[paste]

فرز عينة من المسارات

Review this CSV of JavaScript routes with columns URL, HTTP_STATUS, RAW_TITLE,
RENDERED_TITLE, RAW_CANONICAL, RENDERED_CANONICAL, RAW_WORDS, RENDERED_WORDS. Group
failures into shared-shell duplicates, restrictive-directive conflicts, soft 404s,
and likely render timeouts. Rank groups by affected URL count. Return the exact rows
that support each conclusion and a test to confirm it; do not invent thresholds.

[paste CSV]

تحقق من تغيير في JavaScript SEO

أثبت وجود محتوى المسار قبل JavaScript

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

أثبت اتفاق التوجيهات عبر مراحل المعالجة

الاختبار الذي ينبغي تشغيله: قارن HTML الأولي بـHTML المعروض في URL Inspection بحثاً عن وسوم robots والعناوين الأساسية. النتيجة المتوقعة: تظهر مجموعة توجيهات واحدة مقصودة في المرحلتين، من دون قيمة أكثر تقييداً في الغلاف الأولي. تفسير الفشل: يحاول JavaScript تجاوز إشارة فهرسة بعد فوات الأوان. نافذة المراقبة: فورية في العرض المحلي؛ وبعد إعادة الزحف في Search Console. مؤشر التراجع: يظهر noindex أو عنوان أساسي غير صحيح في أي مرحلة.

أثبت بقاء الروابط قابلة للزحف

الاختبار الذي ينبغي تشغيله: عطّل JavaScript وافحص التنقل إلى مسارات نموذجية. النتيجة المتوقعة: تبقى الوجهات في سمات ارتساء href حقيقية. تفسير الفشل: تملك معالجات العميل الاكتشاف بدلاً من الروابط. نافذة المراقبة: فورية. مؤشر التراجع: تختفي المسارات المهمة من رسم الروابط عند فشل البرامج النصية.

موارد تستحق وقتك

كتاباتي ذات الصلة

• JavaScript SEO: دليل نهائي — دليلي الكامل إلى العرض وتكافؤ DOM وقاعدة التوجيه الأكثر تقييداً والتمرير اللانهائي ومشكلة الصفحتين كصفحة واحدة. وهذه المقالة نسخة مختصرة مرتبطة بالمصادر.
• دليل المبتدئين إلى SEO التقني — موضع JavaScript SEO ضمن الصورة الأكبر.

محاضراتي

• كيف يعمل البحث (SlideShare) — شرحي للزحف والعرض والفهرسة والترتيب. (ينطبق إخلاء المسؤولية المعتاد لدي: «This is my understanding of systems… not going to be 100% complete or accurate.»)

من الآخرين

• r/TechSEO — مجتمع تصحيح مشكلات العرض والفهرسة.
• web.dev — العرض على الويب — الشرح المرجعي لمقايضات العرض من فريق Chrome.
• Google Search Central — JavaScript SEO — الوثائق الرسمية الأولية عن المراحل الثلاث والروابط القابلة للزحف واختبار HTML المعروض.
• Onely — محور JavaScript SEO — مقالات تقنية متعمقة عن العرض وفهرسة الموجتين وتدقيق JS SEO من وكالة متخصصة.
• قائمة تشغيل JavaScript SEO لدى Martin Splitt — سلسلة فيديو Google الرسمية التي تشرح كل مفهوم من مفاهيم JS SEO، من إنتاج فريق منظومة الويب لدى Google.
• تغطية JavaScript SEO في Search Engine Journal — أخبار المجال وأدلة الممارسين عن مشكلات عرض JS عند ظهورها.

ملفات صوتية

• Search Off the Record (علاقات البحث في Google) — يتناول Martin Splitt وJohn Mueller وGary Illyes بانتظام JavaScript SEO والعرض من الداخل. استمع

فيديوهات

• Google Search Central (YouTube) — سلسلة JavaScript SEO لدى Martin Splitt هي أفضل شرح رسمي بالفيديو لكيفية تعامل Google مع JS. القناة

إحصاءات تستحق الاستشهاد

• الصياغة الرسمية الحالية: لا يوجد تأخير ثابت. تقول وثائق Google نفسها (المحدّثة في 2026-03-04) إن الصفحة ذات الحالة 200 التي زُحف إليها “The page may stay on this queue for a few seconds, but it can take longer than that” (الترجمة العربية) «قد تبقى الصفحة في قائمة الانتظار هذه لبضع ثوانٍ، لكن الأمر قد يستغرق وقتاً أطول» — ولا يوجد تأخير ثابت أو مهلة منشورة، وقد تتجاوز الصفحات ذات الحالة غير 200 أو التي تبدأ بـnoindex العرض بالكامل. انتقل إلى الاقتباس
• نقطة بيانات تاريخية (مؤرخة) — وسيط تأخر العرض نحو 5 ثوانٍ. في تصريحات أقدم خلال مؤتمر، وصف موظفو Google (Martin Splitt وTom Greenaway) وصول الصفحات إلى العارض بوسيط يقارب 5 ثوانٍ، وبالمئين التسعين خلال دقائق — لا «أسابيع» كما أوحت الخرافة القديمة. أستشهد بهذا في دليل JavaScript SEO. اعتبره نقطة بيانات تاريخية من ذلك الحديث، لا مقياساً منشوراً حالياً — فلم تعِد Google نشره بوصفه رقماً مستمراً، والاقتباس الخاص بتوقيت قائمة الانتظار أعلاه هو الصياغة الرسمية الحالية.
• «موجتا الفهرسة» تتراجعان، بحسب Martin Splitt (تصريحات 2019). في محادثة مع John Mueller في أغسطس 2019، قال Splitt إن فهرسة الموجتين «تلعب دوراً أقل فأقل» مع انخفاض تكلفة العرض وتقارب الزحف والعرض والفهرسة — من دون تحديد موعد توقفها تماماً. التغطية هذا توصيف Splitt من تلك المحادثة تحديداً، لا مواصفة Google مؤرخة قابلة للاستشهاد — استخدمه سياقاً اتجاهياً، لا ضماناً حالياً في أي من الاتجاهين.

تعالج Google تطبيقات JavaScript عبر الزحف والعرض والفهرسة. Evidence for this claim Google processes JavaScript web apps in three main phases: crawling, rendering, and indexing; without rendering, Google might not see JavaScript-provided content. Scope: Google Search's processing of JavaScript pages; successful rendering does not guarantee indexing or ranking. Confidence: high · Verified: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics وهي تزحف عموماً إلى الروابط عندما تكون ارتساءات ذات سمات href. Evidence for this claim Google can reliably discover links only when they are HTML anchor elements with an href attribute. Scope: Link discovery by Google Search; this does not claim that every discovered URL will be crawled or indexed. Confidence: high · Verified: 2026-07-14 Google Search Central: Make your links crawlable وتصف Google العرض من جهة الخادم أو العرض المسبق بأنه فكرة جيدة للمستخدمين والزاحفين. Evidence for this claim Google describes server-side rendering or pre-rendering as a good idea because it makes a website faster for users and crawlers. Scope: Google Search guidance for JavaScript sites; the source does not prescribe one framework or guarantee indexing. Confidence: high · Verified: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics كما أن بحث Google لا يتفاعل مع الصفحة لتشغيل المحتوى. Evidence for this claim Google Search does not interact with a page, so lazy-loaded content should load when it becomes visible in the viewport rather than requiring user interaction. Scope: Google Search's documented rendering behavior for lazy-loaded content; other crawlers can behave differently. Confidence: high · Verified: 2026-07-14 Google Search Central: Fix lazy-loaded content

سجل التغييرات