SEO للتمرير اللانهائي

الخلاصة — يحمّل التمرير اللانهائي مزيدًا من المحتوى كلما مررت إلى أسفل بدل النقر للانتقال إلى الصفحة 2 ثم 3. لكن Googlebot لا يمرر ولا ينقر. فإذا لم تظهر منتجاتك أو مقالاتك إلا بعد تمرير الزائر، فقد لا تراها Google أبدًا. والحل أن تمنح كل «صفحة» من المحتوى رابطًا حقيقيًا مستقلًا، كي تجد محركات البحث ما تزحفه حتى من دون التفاعل مع التمرير.

ما التمرير اللانهائي؟

استخدمته مئات المرات من دون تسميته. في موجز اجتماعي أو تصنيف متجر أو مقال طويل، تواصل التمرير فيظهر مزيد من العناصر بلا زر «الصفحة التالية» ولا أرقام صفحات. هذا هو التمرير اللانهائي: تراقب JavaScript مقدار تمريرك، وعندما تقترب من النهاية تجلب الدفعة التالية وتضيفها بهدوء.

تبدو التجربة سلسة للبشر، لكن محركات البحث ليست بشرًا.

لماذا ينطوي على مخاطرة في SEO؟

تعثر Google على صفحاتك وتقرأها ببرنامج آلي يسمى Googlebot. يحمّل Googlebot الصفحة لكنه لا يتصرف كزائر بشري:

• لا يمرر إلى أسفل الصفحة.
• لا ينقر الأزرار.

لذلك لا يوجد، من منظور Googlebot، أي محتوى لا يُحمّل إلا بعد تمرير شخص أو نقره زر “Load more” (ترجمة) «تحميل المزيد». فإذا عرضت صفحة التصنيف 24 منتجًا أولًا وحمّلت البقية عند التمرير، فقد لا ترى Google سوى أول 24.

القاعدة الوحيدة التي تجعله آمنًا

تتلخص الحيلة في جملة واحدة: تحتاج كل دفعة محتوى إلى عنوان ويب حقيقي مستقل.

بدل الاعتماد على التمرير وحده، يوفر الإعداد الملائم للبحث صفحات عادية قابلة للزحف خلف الكواليس، مثل example.com/shoes?page=2 و?page=3، تربطها روابط عادية تستطيع Google اتباعها. يمثل التمرير اللانهائي التجربة المريحة للبشر، وتمثل الروابط المرقمة شبكة الأمان لمحركات البحث. وتبدل التطبيقات الحديثة العنوان في شريط المتصفح أثناء التمرير، بحيث يعيدك نسخ الرابط إلى الموضع نفسه.

أكثر الأخطاء شيوعًا

• «تستطيع Google عرض JavaScript الآن، لذا ستفهمه». تستطيع Google تشغيل JavaScript، لكنها مع ذلك لن تمرر أو تنقر لتشغيل أداة التحميل. القدرة على العرض لا تساوي تنفيذ إجراء.
• «زر تحميل المزيد أكثر أمانًا من التمرير التلقائي». فقط إذا كان رابطًا حقيقيًا إلى صفحة حقيقية؛ أما الزر الذي يشغل معالج نقر وحده فلا تراه Google أيضًا.
• «إذا لم تُفهرس الصفحة فإن Google تتجاهلها». في التمرير اللانهائي قد تعني «غير مفهرسة» أن المحتوى دُمج في صفحة أخرى عرضًا، وهذه مشكلة مختلفة بعلاج مختلف.

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

الخلاصة — لا يمرر Googlebot ولا ينقر، لذلك يكون المحتوى المحجوب خلف التمرير غير مرئي افتراضيًا. تتمثل حيلة Google في العرض ضمن منفذ رؤية طويل جدًا، نحو 411×12 140px للجوال و1024×9 307px لسطح المكتب. لكن الارتفاع نفسه قد يشغل أداة التحميل أثناء العرض، فيدمج الصفحة المنطقية التالية في الحالية وتُفهرس صفحتان تحت رابط واحد. الحل الدائم معماري: روابط دائمة ومطلقة لكل دفعة، مثل ?page=12، تربطها عناصر anchor قابلة للزحف، مع تحديث History API لشريط العنوان عندما تصبح الدفعة هي العنصر الرئيسي. أصبح rel=next وrel=prev قديمين لدى Google منذ 2019، لكن Bing ما زالت تحترمهما. وفي صفحات تصنيفات التجارة الإلكترونية تمثل خرائط الموقع أو خلاصة Merchant Center شبكة اكتشاف احتياطية. تحقق من كل شيء في HTML المعروض بأداة URL Inspection.

توضيح أولي

إذا بحثت عن “Google infinite scroll” فسترى نتائج عن التمرير المستمر في صفحات نتائج Google نفسها، وهي ميزة تجربة استخدام فعّلتها Google ثم أوقفتها في منتصف 2024. لا علاقة لهذا القرار بكيفية زحف Googlebot إلى موقعك. يتناول هذا المقال التمرير اللانهائي كنمط تحميل في صفحاتك وإمكان فهرسة Google لما يحمّله.

القيد الأساسي: لا تتفاعل Google مع صفحتك

ينطلق كل شيء من حقيقة واحدة. تقول وثائق Google للتحميل الكسول إن الأنماط الموصى بها “don’t rely on user actions, such as scrolling or clicking, to load content, which is important as Google Search does not interact with your page.” (ترجمة) «لا تعتمد على إجراءات المستخدم، مثل التمرير أو النقر، لتحميل المحتوى؛ فهذا مهم لأن بحث Google لا يتفاعل مع صفحتك». وتقول وثيقة التقسيم بوضوح أكبر: “Google’s crawlers don’t ‘click’ buttons and generally don’t trigger JavaScript functions that require user actions to update the current page contents.” (ترجمة) «لا تنقر برامج زحف Google الأزرار، ولا تشغل عمومًا وظائف JavaScript التي تتطلب إجراء من المستخدم لتحديث محتوى الصفحة الحالية».

وكما قلت في دليل JavaScript SEO: “Googlebot doesn’t take action on webpages. It’s not going to click things or scroll, but that doesn’t mean it doesn’t have workarounds. As long as content is loaded in the DOM without a needed action, Google will see it. If it’s not loaded into the DOM until after a click, then the content won’t be found.” (ترجمة) «لا ينفذ Googlebot إجراءات في صفحات الويب؛ فلن ينقر أو يمرر، لكن لديه حلولًا بديلة. ما دام المحتوى يُحمّل في DOM من دون إجراء مطلوب فستراه Google، أما إذا لم يدخل DOM إلا بعد نقرة فلن يُعثر عليه».

لذلك يمثل التمرير اللانهائي الذي لا يعمل إلا عند حدث تمرير حقيقي مشكلة اكتشاف محتوى قبل أي شيء آخر.

حيلة Google: منفذ رؤية طويل جدًا

لا تحاكي Google التمرير، بل تعرض الصفحة في منفذ رؤية طويل بصورة غير معتادة، فيقع المحتوى البعيد عدة شاشات داخل منطقة العرض من دون تمرير. كانت أول إشارة مسجلة لذلك ملاحظة جون مولر عام 2017: “Googlebot renders with a very tall viewport, which skews some CSS (often images). Try in Chrome dev-tools, eg 9000px high viewport.” (ترجمة) «يعرض Googlebot الصفحة بمنفذ رؤية طويل جدًا، ما يشوه بعض CSS، وغالبًا الصور. جرّب في أدوات Chrome منفذًا بارتفاع 9000px مثلًا».

الأرقام التي وثقتها هي: يحمّل Google الجوال بحجم شاشة 411×731 بكسل ثم يمد الطول إلى 12 140 بكسل؛ “essentially, it becomes a really long phone with a screen size of 411×12140 pixels. For desktop, it does the same and goes from 1024×768 pixels to 1024×9307 pixels.” (ترجمة) «يصبح عمليًا هاتفًا طويلًا جدًا بحجم 411×12140 بكسل، ويفعل الأمر نفسه لسطح المكتب فينتقل من 1024×768 إلى 1024×9307». لم أر اختبارات حديثة تعيد فحص هذه القيم الدقيقة، وقد تختلف باختلاف طول الصفحة، وترجع الأبعاد الأصلية إلى اختبار مستقل أجراه الباحث JR Oakes. ليست النقطة عدد البكسلات نفسه، بل أن Google تحاكي رؤية موضع بعيد بالارتفاع لا بالحركة.

تعامل مع أبعاد البكسل الدقيقة وسلوك دمج صفحتين أدناه بوصفهما ملاحظات مؤرخة خاصة بالتنفيذ، لا عقدًا ثابتًا للمنصة. لا تنشر Google مواصفة رسمية لأي منهما وقد يتغير سلوك العرض. لا تفترض أن موقعك يتصرف بالطريقة نفسها؛ أكد السلوك الحالي لروابطك باختبار HTML المعروض في القسم التالي.

نمط الإخفاق الذي لا يشرحه أحد: فهرسة صفحتين كواحدة

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

شخّصت هذه الحالة عدة مرات. ومن دليل JavaScript SEO:

“Another issue I’ve seen with this setup is, occasionally, two pages get indexed as one. I’ve seen this a few times when people said they couldn’t get their page indexed. But I’ve found their content indexed as part of another page that’s usually the previous post from them.” (ترجمة) «رأيت في هذا الإعداد فهرسة صفحتين أحيانًا كصفحة واحدة؛ وعندما ظن أصحاب الموقع أن الصفحة لم تُفهرس، وجدت محتواها ضمن صفحة أخرى تكون عادة المنشور السابق».

“My theory is that when Google resized the viewport to be longer, it triggered the infinite scroll and loaded another article in when it was rendering. In this case, what I recommend is to block the JavaScript file that handles the infinite scrolling so the functionality can’t trigger.” (ترجمة) «نظريتي أن إطالة Google لمنفذ الرؤية شغلت التمرير اللانهائي وحمّلت مقالًا آخر أثناء العرض؛ لذلك أوصي بحجب ملف JavaScript المسؤول مؤقتًا حتى لا تعمل الوظيفة».

وصف جون مولر الآلية نفسها عام 2022: تعرض Google الصفحة بمنفذ مرتفع، وهذا “would trigger some amount of infinite scrolling” (ترجمة) «سيشغّل قدرًا من التمرير اللانهائي»، وأضاف: “we might have two or three of these pages loaded on one page with infinite scroll, but not everything.” (ترجمة) «قد نحمّل صفحتين أو ثلاثًا من هذه الصفحات في صفحة واحدة ذات تمرير لانهائي، لكن ليس كل شيء». نُقلت الأقوال عبر Search Engine Journal ولم تؤكد من التسجيل الأولي.

تنتج عن ذلك نتيجتان:

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

كيفية التشخيص

استخدم URL Inspection Tool في Search Console واقرأ HTML المعروض لا المصدر الخام. تقول وثائق Google: “You can use the URL Inspection Tool in Search Console to see if all content was loaded. Check the rendered HTML to make sure your content is in the rendered HTML by looking for it in URL Inspection Tool.” (ترجمة) «يمكنك استخدام URL Inspection Tool لمعرفة هل حُمّل كل المحتوى. افحص HTML المعروض وتأكد من وجود المحتوى فيه». ابحث عن محتوى تتوقع وجوده في الصفحة 1 وحدها. فإذا وجدت محتوى الصفحة 2 أو المقال التالي داخل عرض الصفحة 1 فقد أعدت إنتاج خلل الدمج.

يمكنك أيضًا محاكاة منفذ الرؤية الطويل محليًا: افتح Chrome DevTools واضبط منفذًا مخصصًا طويلًا جدًا، نحو 9000px وفق اقتراح مولر، وحمّل الصفحة لترى هل تعمل الأداة بلا تمرير.

الحل: روابط مقسمة إلى صفحات وHistory API

الحل الدائم معماري ومأخوذ من وثيقة Google الحالية للتحميل الكسول. لجعل التمرير قابلًا للفهرسة، “make sure your website supports paginated loading of these chunks” (ترجمة) «تأكد من أن موقعك يدعم تحميل هذه الدفعات في صفحات»:

• “Give each chunk its own persistent, unique URL.” (ترجمة) «امنح كل دفعة رابطًا دائمًا وفريدًا».
• “Ensure that the content shown on each URL remains the same every time it’s loaded in a browser” (ترجمة) «تأكد من بقاء المحتوى المعروض في كل رابط نفسه عند كل تحميل»؛ وتقترح Google أرقامًا مطلقة مثل ?page=12.
• “Avoid using relative elements like ?date=yesterday in these URLs” (ترجمة) «تجنب عناصر نسبية مثل ?date=yesterday في هذه الروابط»؛ فالعنوان الذي يعيد محتوى مختلفًا كل مرة لا يصلح canonical.
• “Link sequentially to the individual URLs so that search engines can discover the URLs in a paginated set” (ترجمة) «اربط الروابط الفردية بالتسلسل كي تكتشف محركات البحث مجموعة الصفحات»؛ استخدم روابط <a href> حقيقية لا معالجات نقر.
• “When a new page chunk is loaded in response to the user scrolling, and it becomes the primary visible element for the user, update the displayed URL using the History API.” (ترجمة) «عند تحميل دفعة جديدة استجابة لتمرير المستخدم وصيرورتها العنصر المرئي الأساسي، حدّث الرابط المعروض باستخدام History API».

تكمن أناقة النقطة الأخيرة في أن history.pushState() وreplaceState() يبدلان الرابط في شريط العنوان عند عبور المستخدم حدود كل دفعة، فيطابق الرابط المرئي المحتوى الرئيسي ويمكن تحديث الصفحة ومشاركتها وربط الموضع نفسه. وفي الوقت ذاته توجد روابط ?page=N القابلة للزحف مستقلة، فتصل Google إلى كل دفعة سواء شغّل العارض التمرير أم لا.

ملاحظتان مهمتان للتنفيذ:

• استخدم IntersectionObserver أو التحميل الكسول الأصلي للمتصفح، لا مستمع scroll خامًا. أداؤه أفضل كثيرًا، وهو آلية «التحميل عند الظهور» التي تعتمدها Google للمحتوى المؤجل.
• أبقِ مجموعة الصفحات قابلة للاكتشاف بعيدًا عن JavaScript. ضع عناصر anchor حقيقية في DOM، و/أو أدرج روابط ?page=N في خريطة XML. ومهما التقط العارض، تمثل الخريطة والروابط شبكة الأمان.

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

حالة التنقل: يجب أن يعيد الرجوع والتقدم والتحديث والمشاركة بناء العرض نفسه

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

• استخدم pushState() عندما تصبح دفعة المحتوى الرئيسي المرئي لأول مرة؛ فهذه خطوة تنقل حقيقية تجعل زر الرجوع ذا معنى.
• استخدم replaceState() للتصحيحات التي لا ينبغي أن تنشئ محطة رجوع مستقلة، مثل مزامنة الرابط بعد تمرير سريع عبر عدة دفعات.
• استمع إلى popstate وأعد عرض أو جلب الدفعة المطابقة للرابط. يعيد سلوك المتصفح الافتراضي موضع التمرير، لا حالة القائمة الديناميكية. فإذا أضاف المحمّل 40 عنصرًا ثم رجع المستخدم، فعليك إعادة بناء العناصر التابعة للصفحة لا مجرد التمرير إليها.
• لا تعتمد على استعادة التمرير التلقائية وحدها؛ فهي تتحكم في موضع منفذ العرض لا المحتوى الموجود. وإذا تغيرت القائمة بين الزيارات فقد تضع المستخدم في سياق خاطئ.

هذا هو الانضباط نفسه الذي يعتمد عليه حل الروابط المقسمة: يجب أن يعيد رابط الدفعة المحتوى الموعود عند تحميل جديد أو تحديث أو اختبار مباشر في Search Console، لا عند جلبه أول مرة أثناء التمرير فقط.

حالات التحميل والخطأ ونهاية النتائج

يحتاج التطبيق الإنتاجي إلى حالات أكثر من «جار التحميل» و«تم التحميل»:

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

لا يخص هذا Google وحدها، لكنه مستوى الموثوقية نفسه الذي يعتمد عليه حل الروابط المقسمة؛ فإذا أمكن للمحمّل أن يفشل بصمت فلا يمكنك الوثوق بأن الزحف أو جلسة المستخدم التقطت الدفعة المطلوبة.

إتاحة الوصول والأداء: أمران لا يمنحهما التمرير اللانهائي مجانًا

لا يحمل التمرير اللانهائي نتيجة متأصلة جيدة أو سيئة لمؤشرات Core Web Vitals؛ فالنتيجة تتوقف على التنفيذ. توسع كل دفعة DOM، وقد يرفع DOM الكبير تكلفة التخطيط وإعادة حساب الأنماط. راقب تكلفة الإضافة وتحميل الصور وانزياح التخطيط للمحتوى بلا مساحة محجوزة والمهام الطويلة. وفي الصفحات شديدة الطول فكر في جعل الدفعات البعيدة افتراضية بإزالة عقدها من DOM بدل نموه بلا حد.

تحتاج إتاحة الوصول إلى تصميم مقصود، لا افتراض أن «ظهوره يعني سلامته»:

• يحتاج مستخدمو لوحة المفاتيح إلى الوصول إلى المحتوى الجديد والتذييل أو تنقل نهاية الصفحة من دون أن تستمر الصفحة في النمو تحت ترتيب Tab.
• يحتاج مستخدمو قارئ الشاشة إلى إعلان المحتوى الجديد من دون مقاطعة؛ ومن المعتاد استخدام منطقة حالة مهذبة لا تنبيه مزعج.
• صُمم نمط موجز WAI-ARIA لهذه الحالة: مناطق على مستوى المقال داخل حاوية موجز مع سلوك لوحة مفاتيح محدد للتنقل والوصول إلى ما قبل الموجز وبعده.
• ينبغي ألا ينتقل التركيز أو يضيع بصمت عند تحميل دفعة جديدة.

ليس هذا تنظيفًا اختياريًا؛ بل الفرق بين تمرير يعمل للجميع وآخر لا يعمل إلا لمستخدم فأرة لديه JavaScript ولا يغادر المسار المثالي.

السياق التاريخي: rel=next/prev أصبح قديمًا

إذا تعلمت التقسيم قبل سنوات، فربما استخدمت rel="next" وrel="prev". قدمتهما Google عام 2011 وربطتهما بتوصياتها الأصلية للتمرير الملائم للبحث في 2014. ثم أعلنت عام 2019 أنها لم تكن تستخدمهما منذ سنوات وأوقفتهما رسميًا. وتوضح الوثيقة الحالية أن Google كانت تستخدم <link rel="next" href="..."> و<link rel="prev" href="..."> لبيان علاقة الصفحة التالية والسابقة، لكنها لم تعد تعتمد عليهما، مع احتمال استمرار محركات بحث أخرى في استخدامهما.

لذلك وصفة Google الحالية هي روابط فريدة وروابط قابلة للزحف وHistory API، من دون حاجة إلى rel=next أو rel=prev. لكن «محركات أخرى» تشمل Bing التي ما زالت تحترمهما، فلا ضرر من إبقائهما لفائدة عابرة للمحركات وإتاحة الوصول. لا تنشر Bing إرشادًا خاصًا بالتمرير؛ بل تحذر عمومًا أن bingbot يستطيع عرض JavaScript لكن “it is difficult for bingbot to process JavaScript at scale” (ترجمة) «يصعب على bingbot معالجة JavaScript على نطاق واسع»، لذلك يفيده بديل التقسيم القابل للزحف للسبب نفسه.

صفحات تصنيفات التجارة الإلكترونية: الحالة الأعلى مخاطرة

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

هناك شبكتا أمان مهمتان:

• خرائط XML تضم كل منتج canonical وكل رابط تصنيف مقسم، كي لا يعتمد الاكتشاف على العارض.
• خلاصة منتجات Merchant Center تزود Google ببيانات المنتجات بعيدًا عما يلتقطه عارض صفحة التصنيف.

وجد تحليل Lumar لأبرز متاجر الأزياء البريطانية أن التمرير اللانهائي هو، بعبارتهم، “the biggest loser when it comes to indexability and SEO friendliness” (ترجمة) «الخاسر الأكبر في قابلية الفهرسة والملاءمة لـSEO» بين أنماط التقسيم. وهذا يذكّر بأن الأمر ليس حالة نظرية نادرة بل الإخفاق الافتراضي لتجربة شائعة. ينبغي قراءة النسب المحددة من تقرير Lumar المباشر قبل الاستشهاد برقم دقيق.

التمرير اللانهائي مقابل التقسيم مقابل تحميل المزيد

تعرض وثيقة Google ثلاثة أنماط بوضوح بشأن المفاضلات. يستخدم التمرير اللانهائي “a single page for all content” (ترجمة) «صفحة واحدة لكل المحتوى»، وهو “intuitive — the user just keeps scrolling” (ترجمة) «بديهي؛ يواصل المستخدم التمرير»، لكنه قد يسبب “scrolling fatigue” (ترجمة) «إرهاق التمرير» بسبب غموض حجم النتائج، ولا يستطيع معالجة أعداد كبيرة جدًا. التقسيم المرقم هو الأكثر متانة لـSEO لأن كل صفحة رابط حقيقي أصلًا. ويقع «تحميل المزيد» بينهما: سليم إذا كان الزر رابطًا حقيقيًا لصفحة مقسمة، وعديم الفائدة إذا كان معالج نقر فقط.

ليس السؤال «أيها مسموح؟»؛ فكلها مسموحة. السؤال هو «أي تجربة تريد، وهل بنيت تحتها طبقة روابط قابلة للزحف؟». ويلخص مولر ذلك عام 2023: “if each piece or virtual page is also accessible and findable through a unique URL, generally it should be fine to have infinite scroll.” (ترجمة) «إذا كان الوصول إلى كل جزء أو صفحة افتراضية والعثور عليها ممكنًا عبر رابط فريد، فينبغي أن يكون التمرير اللانهائي سليمًا عمومًا».

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

خلاصة مكثفة للنسخة المتقدمة:

• القيد الأساسي: لا يمرر Googlebot ولا ينقر؛ فالمحتوى المحجوب خلف إجراء غير مرئي افتراضيًا.
• حيلة Google: تعرض في منفذ طويل جدًا، نحو 411×12 140px للجوال و1024×9 307px لسطح المكتب.
• الإخفاق: قد يشغل المنفذ الطويل المحمّل أثناء العرض ويدمج الصفحة التالية في الحالية، فتُفهرس صفحتان تحت رابط واحد.
• لا ضمان: قد تحمّل Google صفحتين أو ثلاثًا لا كل شيء؛ فالتمرير وحده غير موثوق للفهرسة العميقة.
• الحل المعماري: روابط دائمة وفريدة ومطلقة لكل دفعة، مثل ?page=12، وعناصر <a href> قابلة للزحف، وتحديث شريط العنوان عبر pushState وreplaceState.
• آلية التشغيل: IntersectionObserver أو التحميل الأصلي، لا مستمع scroll خامًا.
• ملاحظة تاريخية: أوقفت Google ‏rel=next وrel=prev في 2019، وما زالت Bing تدعمهما.
• التجارة الإلكترونية: تمثل PLPs الحالة الأعلى مخاطرة؛ ادعمها بخرائط الموقع وخلاصة Merchant Center، واختبر HTML المعروض في URL Inspection.
• إسعاف خلل مباشر: احجب ملف JavaScript للمحمّل أثناء إعادة البناء.
• حالة التنقل: استخدم pushState لخطوة حقيقية وreplaceState للتصحيحات، ومعالج popstate يعيد بناء المحتوى لا موضع التمرير وحده.
• حالات موثوقة: ميّز التحميل الأولي والتالي والفراغ والخطأ وإعادة المحاولة ونهاية النتائج.
• الإتاحة والأداء: لا نتيجة متأصلة لمؤشرات Core Web Vitals؛ صمم وصول لوحة المفاتيح والإعلانات المهذبة ونمط WAI-ARIA منفصلة عن إصلاح الفهرسة.
• ملاحظات مؤرخة: تعامل مع أبعاد المنفذ وآلية الدمج كخاصتين بالتنفيذ وتحقق من كل رابط.

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

وثائق مصادر أولية عن التمرير والتقسيم وعرض JavaScript.

Google

• إصلاح المحتوى المحمّل كسولًا — يتضمن دعم التحميل المقسم للتمرير، والروابط الفريدة وأرقام الصفحات وHistory API واختبار URL Inspection. آخر تحديث 2025-12-10.
• التقسيم والتحميل التدريجي وتأثيرهما في بحث Google — الأنماط الثلاثة ومفاضلاتها وملاحظة التفاعل وإيقاف rel=next وrel=prev.
• توصيات التمرير اللانهائي الملائم للبحث — تدوينة 2014 التاريخية، وقد تجاوز الإرشاد الحالي اقترانها بالوسمين.
• نص ساعات مكتب SEO في سبتمبر 2023 — إعادة مولر المسجلة لقاعدة الرابط الفريد.
• أساسيات JavaScript SEO — سياق العرض الأوسع.

Bing / Microsoft

• سلسلة bingbot: ‏JavaScript والعرض الديناميكي والحجب — إرشاد Bing العام للعرض؛ لا توجد صفحة خاصة بالتمرير، وما زالت تحترم الوسمين.

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

تصريحات مسجلة من Google وBing، ويقود كل رابط إلى المقطع المقتبس.

Google: التمرير وقاعدة التحميل المقسم

• “To implement infinite scroll in an indexable way, make sure your website supports paginated loading of these chunks.” (ترجمة) «لتنفيذ التمرير بطريقة قابلة للفهرسة، تأكد من دعم موقعك تحميل هذه الدفعات في صفحات». … “Give each chunk its own persistent, unique URL.” (ترجمة) «خصص لكل دفعة عنوان URL ثابتًا لا يشاركها فيه غيرها». — Google Search Central. الانتقال إلى الاقتباس
• “When a new page chunk is loaded in response to the user scrolling, and it becomes the primary visible element for the user, update the displayed URL using the History API.” (ترجمة) «عند تحميل دفعة جديدة بالتمرير وصيرورتها العنصر المرئي الأساسي، حدّث الرابط المعروض باستخدام History API». الانتقال إلى الاقتباس
• “The methods mentioned don’t rely on user actions, such as scrolling or clicking, to load content, which is important as Google Search does not interact with your page.” (ترجمة) «لا تعتمد الطرق المذكورة على إجراء المستخدم لتحميل المحتوى، لأن بحث Google لا يتفاعل مع صفحتك». الانتقال إلى الاقتباس
• “You can use the URL Inspection Tool in Search Console to see if all content was loaded. Check the rendered HTML to make sure your content is in the rendered HTML by looking for it in URL Inspection Tool.” (ترجمة) «استخدم URL Inspection لمعرفة هل حُمّل كل المحتوى وتأكد من وجوده في HTML المعروض». الانتقال إلى الاقتباس

Google: سلوك الزاحف وrel=next/prev

• لا تنقر برامج زحف Google الأزرار ولا تشغل عمومًا وظائف JavaScript التي تتطلب إجراء لتحديث المحتوى. الانتقال إلى الاقتباس
• “In the past, Google used <link rel="next" href="...">” (ترجمة) «استخدمت Google سابقًا وسم الصفحة التالية»، واستخدمت كذلك <link rel="prev" href="..."> للصفحة السابقة؛ ولم تعد تعتمد الوسمين، وقد تستخدمهما محركات أخرى. الانتقال إلى الاقتباس

جون مولر، Google: ساعات مكتب سبتمبر 2023

• “It depends how you implement infinite scrolling. if each piece or virtual page is also accessible and findable through a unique URL, generally it should be fine to have infinite scroll.” (ترجمة) «يتوقف الأمر على التنفيذ؛ فإذا أمكن الوصول إلى كل جزء أو صفحة افتراضية والعثور عليها عبر رابط فريد، فينبغي أن يكون التمرير سليمًا عمومًا». الانتقال إلى الاقتباس

جون مولر، Google: تغريدة «منفذ 9000px» في نوفمبر 2017

• “Googlebot renders with a very tall viewport, which skews some CSS (often images). Try in Chrome dev-tools, eg 9000px high viewport.” (ترجمة) «يعرض Googlebot بمنفذ طويل جدًا يشوه بعض CSS؛ جرّب في أدوات Chrome ارتفاع 9000px». — نقلًا عن Search Engine Roundtable. قراءة التغطية

Bing: عرض JavaScript عمومًا

• “As we shared last week at SMX East, bingbot is generally able to render JavaScript. However, bingbot does not necessarily support all the same JavaScript frameworks that are supported in the latest version of your favorite modern browser.” (ترجمة) «يستطيع bingbot عمومًا عرض JavaScript، لكنه لا يدعم بالضرورة كل الأطر التي يدعمها أحدث متصفح». — Fabrice Canel وFrédéric Dubut، Microsoft Bing. الانتقال إلى الاقتباس

أي نمط تقسيم ينبغي استخدامه؟

اتبع الخطوات من أعلى إلى أسفل.

1. هل يحتاج المحتوى بعد الشاشة الأولى إلى الترتيب؟

• لا، مثل موجز داخلي أو لوحة مسجلة الدخول ← أي نمط مناسب؛ حسّن تجربة الاستخدام فقط.
• نعم ← واصل.

2. هل لديك رابط حقيقي لكل دفعة أو تستطيع بناءه؟

• لا ولا تستطيع ← استخدم التقسيم المرقم التقليدي؛ فكل صفحة رابط حقيقي افتراضيًا، وهو الأقل مخاطرة.
• نعم ← التمرير أو «تحميل المزيد» كلاهما صالح؛ واصل.

3. ما حجم المجموعة؟

• كبيرة جدًا، آلاف العناصر أو كتالوج عميق ← فضّل التقسيم المرقم أو التمرير فوق روابط حقيقية؛ فلا يتحمل التمرير الخالص أعدادًا ضخمة. أضف خرائط موقع شبكة اكتشاف.
• متوسطة ← التمرير أو تحميل المزيد المدعومان بروابط مقسمة صالحان.

4. هل التمرير موصول بروابط حقيقية وHistory API؟

• لا، حدث تمرير فقط بلا روابط ← لا تطلقه؛ فهذا الإعداد يدمج المحتوى العميق أو يمنع فهرسته.
• نعم، روابط ?page=N وعناصر anchor وpushState ← أطلقه ثم تحقق في HTML المعروض بأداة URL Inspection.

5. هل هو مباشر وصفحة عميقة «غير مفهرسة»؟

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

قائمة تحقق للتمرير الملائم للبحث

• لكل دفعة رابط دائم وفريد ومطلق، مثل ?page=2 لا ?date=yesterday.
• يعيد كل رابط المحتوى نفسه في كل تحميل، بلا اعتماد على الجلسة.
• ترتبط الدفعات بعناصر <a href> حقيقية يمكن اكتشافها دون JavaScript.
• يتحدث الرابط المرئي عبر History API باستخدام pushState وreplaceState باستخدام pushState وreplaceState باستخدام pushState وreplaceState باستخدام pushState وreplaceState عند صيرورة الدفعة المحتوى الرئيسي.
• يستخدم المحمّل IntersectionObserver أو التحميل الأصلي لا مستمع scroll خامًا.
• تُدرج الروابط المقسمة في خريطة XML، وتدعم التجارة الإلكترونية بخلاصة Merchant Center.
• يمكن إبقاء rel=next وrel=prev لـBing؛ تتجاهلهما Google.
• يؤكد URL Inspection ← HTML المعروض وجود المحتوى العميق وعدم دمجه من صفحة مجاورة.
• يُعاد الاختبار محليًا بمنفذ DevTools طويل، نحو 9000px، للتأكد من عدم التشغيل الزائد.
• يعيد معالج popstate بناء محتوى الدفعة عند الرجوع والتقدم، لا موضع التمرير فقط.
• توجد حالات مستقلة للتحميل والخطأ وإعادة المحاولة والفراغ ونهاية النتائج.
• يصل مستخدم لوحة المفاتيح إلى المحتوى والتذييل، ويُعلن الجديد بمنطقة حالة مهذبة.

ما الذي يعطل SEO للتمرير؟

التحميل بحدث التمرير وحده بلا روابط حقيقية. يبقى المحتوى في DOM بعد تشغيل التمرير فقط؛ وGooglebot لا يمرر، لذلك لا يراه ولا يجد بديلًا يزحفه.

زر «تحميل المزيد» كمعالج نقر خالص. لا تنقر Google الأزرار أيضًا. لا يفيد إلا إذا كان رابط <a href> حقيقيًا إلى صفحة مقسمة أو احتواه.

روابط fragment/hash للتقسيم مثل #page=2. لا تنشئ fragments روابط مستقلة قابلة للزحف. استخدم معلمات استعلام أو مسارات حقيقية.

روابط نسبية أو غير مستقرة مثل ?date=yesterday ومحتوى الجلسة. لا يصلح الرابط الذي يعيد محتوى مختلفًا كصفحة مستقرة قابلة للفهرسة؛ استخدم أرقام صفحات مطلقة.

تجاهل خلل الدمج بمنفذ طويل. قد تعني «غير مفهرسة» أن العارض دمج المحتوى في رابط مجاور، لا أن Google تجاهلته؛ وهذا يحتاج إلى علاج مختلف.

حجب كل JavaScript وCSS بوصفه «حلًا». حجب ملف تشغيل التمرير المحدد إجراء إسعافي مقصود؛ أما حجب كل الموارد فيفسد عرض الصفحة كلها.

ورقة مرجعية لـSEO التمرير اللانهائي

أنماط تجربة الاستخدام الثلاثة

ضرورات التمرير

• رابط دائم وفريد ومطلق لكل دفعة، مثل ?page=12.
• المحتوى نفسه في كل تحميل، بلا ?date=yesterday.
• روابط <a href> قابلة للزحف بين الدفعات.
• History API، وتحديدًا pushState وreplaceState، لمزامنة شريط العنوان.
• IntersectionObserver لا مستمع scroll خامًا.

حقائق سريعة

• Googlebot لا يمرر ولا ينقر.
• منفذ العرض المبلغ عنه نحو 411×12 140px للجوال و1024×9 307px لسطح المكتب.
• قد يشغل المنفذ الطويل المحمّل فتُفهرس صفحتان كواحدة.
• أوقفت Google ‏rel=next وrel=prev عام 2019، وما زالت Bing تستخدمهما.
• تحقق عبر URL Inspection وHTML المعروض.
• في خلل مباشر احجب ملف تشغيل التمرير مؤقتًا.

أمثلة للتنفيذ الجيد والسيئ

سيئ: تمرير فقط وغير مرئي لـGoogle

ترسل صفحة التصنيف 24 منتجًا في HTML. يجلب مستمع scroll الدفعة التالية ويضيف 24 أخرى. لا توجد روابط ?page=N ولا anchors ولا History API. يحمّل Googlebot الصفحة ولا يمرر ويفهرس 24 منتجًا، وتبقى المنتجات الـ300 الأخرى غير قابلة للاكتشاف عبر الصفحة.

سيئ: خلل الدمج في موقع مباشر

تضيف مدونة الناشر المنشور التالي تحت الحالي. يشتكي الكاتب من عدم فهرسة مقاله الجديد، لكنه مفهرس ضمن رابط المنشور السابق لأن منفذ Google الطويل شغّل المحمّل. العلاج التقسيم الصحيح، ومؤقتًا حجب ملف التشغيل.

جيد: تمرير فوق روابط حقيقية

يوجد التصنيف نفسه في /shoes?page=1 و/shoes?page=2، وكل رابط يعيد محتوى ثابتًا ومدرجًا في الخريطة ومرتبطًا بعنصر <a href>. للبشر يحمّل IntersectionObserver الدفعة التالية، ويحدث history.pushState() العنوان إلى ?page=2. تصل Google إلى كل صفحة مباشرة، ويكون التمرير تحسينًا فوق البنية.

مقتطفات للتنفيذ والتشخيص

نمط History API في العميل

حمّل كل دفعة عند اقترابها من الظهور باستخدام IntersectionObserver، ثم بدّل الرابط المرئي عندما تصبح رئيسية. الأساس أن روابط ?page=N صفحات حقيقية على الخادم بعيدًا عن النص البرمجي.

// A sentinel element sits at the bottom of the current chunk.
const sentinel = document.querySelector('#load-more-sentinel');
let nextPage = 2;

const io = new IntersectionObserver(async (entries) => {
  if (!entries[0].isIntersecting) return;
  const res = await fetch(`/shoes?page=${nextPage}&partial=1`);
  const html = await res.text();
  document.querySelector('#product-grid').insertAdjacentHTML('beforeend', html);

  // Update the address bar so refresh/share/link land on this chunk.
  // pushState adds a history entry; replaceState if you don't want back-button steps.
  history.pushState({ page: nextPage }, '', `/shoes?page=${nextPage}`);
  nextPage++;
}, { rootMargin: '600px' }); // start loading before the user hits the very bottom

io.observe(sentinel);

والأهم أن البديل القابل للزحف يبقى في DOM؛ فهذا ما تتبعه Google:

<nav aria-label="Pagination">
  <a href="/shoes?page=2" rel="next">Next</a>
  <!-- rel="next"/"prev" is ignored by Google since 2019 but still used by Bing -->
</nav>

Console في DevTools: هل يعمل المحمّل بلا تمرير حقيقي؟

حاكِ منفذ Google الطويل، ثم تحقق هل حُمّلت دفعات إضافية تلقائيًا. اضبط في Chrome DevTools منفذًا بطول نحو 1024×9000، وأعد التحميل، وشغّل المقتطف في Console لعد الدفعات قبل أي تمرير يدوي:

// Count rendered product cards (adjust the selector to your markup)
console.log('cards rendered without scrolling:', document.querySelectorAll('#product-grid .product-card').length);
// If this is much higher than your per-page count, the loader is over-firing on height alone.

Console في DevTools: أكد وجود الروابط المقسمة

قبل الوثوق بالبديل، تحقق من أن كل ?page=N يعيد محتوى حقيقيًا ومختلفًا من الخادم، لا مسارًا يعتمد على JavaScript وحدها:

// Run in the console; a real paginated URL should return HTML containing products.
for (const n of [2, 3, 4]) {
  const html = await (await fetch(`/shoes?page=${n}`)).text();
  console.log(`page ${n}: ${html.includes('product-card') ? 'has products ✅' : 'EMPTY — JS-only? ❌'}`);
}

Bookmarklet: افتح فحص HTML المعروض للصفحة

اسحب الأداة إلى شريط الإشارات لفتح الرابط الحالي في URL Inspection داخل Search Console، ثم اقرأ HTML المعروض لا المصدر لمعرفة عمق ما التقطته Google:

javascript:(()=>{const u=encodeURIComponent(location.href);open('https://search.google.com/search-console/inspect?resource_id=&id='+u,'_blank');})();

أثبت قابلية التمرير للفهرسة بعد الإطلاق

اختبر شبكة منتجات محمّلة كسولًا دون خلط حالات المتصفح

لا تكفي لقطة واحدة من نافذة طويلة. اختبر رابط التصنيف نفسه بالمصفوفة التالية، وابدأ كل تنقل جديد بذاكرة مؤقتة فارغة أو حالة موثقة ومتسقة:

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

سجل لكل تشغيل:

• الرابط المطلوب والرابط النهائي في الشريط؛
• أبعاد المنفذ وهل حُمّلت الصفحة أو تغير حجمها عندها؛
• بطاقات المنتجات بعد كل تحميل؛
• روابط المنتجات الفريدة في <a href> حقيقية؛
• الروابط المكررة أو المفقودة أو العابرة للصفحات؛
• طلبات الشبكة والمحفز لكل دفعة؛
• هل تحدث حدود الصفحة الرابط وتنجو من التحديث؛
• عقد شجرة إتاحة الوصول وأسماؤها وأدوارها ووجهاتها.

طابق الأعداد مع مخزون الكتالوج أو الدفعات المتوقع. عدد البطاقات المرئية وعدد الروابط الفريدة ادعاءان منفصلان؛ فقد ترسم الشبكة 48 بطاقة مع روابط أقل أو مكررة أو عناصر غائبة من شجرة الإتاحة. احتفظ بمنتج أول وآخر مميز لكل دفعة لكشف دمج الصفحة 2 في 1 بصمت.

اختبر كل دفعة كرابط مستقل

الاختبار: اطلب أول رابط مقسم وأوسطه وآخره مباشرة مع تعطيل JavaScript. المتوقع: محتوى ثابت وفريد واستجابة ناجحة دون تمرير. تفسير الإخفاق: طبقة الروابط شكلية أو تعتمد على تفاعل العميل. النافذة: فور الإطلاق. سبب التراجع: تحويل أي دفعة إلى الأولى أو إعادة shell مشترك أو تغير المحتوى بين الطلبات.

اختبر اكتشاف الزاحف بلا تفاعل

الاختبار: افحص DOM المعروض قبل التمرير واستخرج روابط التقسيم. المتوقع: دفعات متسلسلة عبر href مطلق أو نسبي للجذر. الإخفاق: لا مسار للزاحف بعد المجموعة الأولى. النافذة: فورية. سبب التراجع: وجود الدفعة التالية خلف معالج زر أو حدث تمرير فقط.

اختبر خلل الدمج بمنفذ طويل

الاختبار: اعرض الدفعة الأولى في منفذ Chrome طويل جدًا وابحث في DOM عن عنصر مميز من التالية. المتوقع: لا يمتص الرابط الأول محتوى التالي الرئيسي. الإخفاق: يعمل المحمّل أثناء العرض بلا تفاعل. النافذة: فورية محليًا ثم بعد إعادة زحف Google. سبب التراجع: ظهور دفعتين منطقيتين كمستند واحد أو عدم تتبع شريط العنوان للدفعة الرئيسية.

اختبر معلوماتك: SEO التمرير اللانهائي

خمسة أسئلة سريعة عن جعل التمرير قابلًا للفهرسة. اختر إجابة ثم تحقق.

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

كتاباتي

• مشكلات JavaScript SEO وأفضل الممارسات — الشرح الكامل، ومنها فهرسة صفحتين كواحدة وأبعاد منفذ العرض.
• دليل المبتدئين إلى SEO التقني — موضع العرض وقابلية الزحف.

محاضراتي

• كيف يعمل البحث — شرح الزحف والعرض والفهرسة والترتيب. وينطبق تنبيهي: “This is my understanding of systems… not going to be 100% complete or accurate.” (ترجمة) «هذا فهمي للأنظمة ولن يكون كاملًا أو دقيقًا بنسبة 100%».

من القطاع

• Google Search Central: إصلاح المحتوى المحمّل كسولًا — الإرشاد الحالي للتحميل المقسم.
• Google Search Central: التقسيم والتحميل التدريجي — الأنماط الثلاثة وإيقاف rel=next وrel=prev.
• كيف تزحف Google صفحات التمرير — شرح دمج صفحتين أو ثلاث.
• لماذا يسبب التمرير مشكلات SEO — عدم تمرير Googlebot واستخدام IntersectionObserver.
• منفذ Googlebot بطول 9000px — أصل شرح المنفذ الطويل.
• تمرير ملائم لـSEO — إطار الصفحات المكونة.
• تنفيذ التمرير لـSEO — شرح تنفيذي.
• حالة التقسيم في التجارة الإلكترونية — تحليل متاجر الأزياء الذي قيّم التمرير أسوأ نمط.

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