SEO للقائمة الضخمة

الخلاصة — القائمة الضخمة هي قائمة تنقّل منسدلة تعرض روابط كثيرة دفعة واحدة ضمن أعمدة. ومن منظور SEO ليست سوى روابط داخلية، لذلك يجب أن يكون كل رابط عنصرًا حقيقيًا من نوع <a href> كي تتمكن Google من تتبعه بثبات. الخطأ الأكثر شيوعًا هو إنشاء اللوحة المنبثقة بمعالجات نقر JavaScript بدل الروابط الفعلية؛ فتبدو سليمة للمستخدم بينما تعجز محركات البحث عن زحفها. وعلى الجوال، تأكد من أن قائمة الهامبرغر تحتفظ بالروابط نفسها.

ما القائمة الضخمة؟

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

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

القاعدة الأهم

لكي يتتبع محرك البحث رابطًا، يجب أن يكون رابط HTML حقيقيًا: عنصر <a> يحمل السمة href:

<a href="/shoes/mens/">Men's shoes</a>

هذا هو الجوهر. إذا كانت روابط القائمة عناصر <a href> حقيقية فقد أنجزت معظم العمل. تبدأ المشكلة عندما يبني المطور الانتقال بسلوك «انقر للذهاب» في JavaScript بدل رابط فعلي. يبدو الأمر مطابقًا للمستخدم، لكنه لا يترك لـ Google رابطًا تتبعه، وقد تظل الصفحات المقصودة غير مكتشفة من دون إنذار.

كيف تفحص قائمتك؟

انقر بزر الفأرة الأيمن واختر عرض مصدر الصفحة (لا «فحص العنصر»)، ثم ابحث عن أحد روابط القائمة. ظهوره بصيغة <a href="..."> في المصدر الخام علامة جيدة. أما ظهوره فقط في DOM الحي الذي بناه JavaScript داخل أداة الفحص، لا في المصدر، فهو تحذير ينبغي إرساله إلى المطور.

لا تنسَ الجوال

تتحول القائمة الضخمة على الهاتف إلى قائمة هامبرغر أو أكورديون. كثيرًا ما تختصر الفرق هذه القائمة لتبسيط الواجهة فتحذف بالخطأ روابط كانت موجودة على سطح المكتب. تريد Google تكافؤ محتوى الجوال وسطح المكتب؛ لذلك افحص قائمة الجوال بالطريقة نفسها: هل تضم الوجهات ذاتها، وهل كل منها رابط <a href> حقيقي؟

للتفاصيل الأعمق عن فشل JavaScript، والمحتوى المخفي حتى التمرير، وعدد الروابط، وأمثلة الترميز الجيد والسيئ، انتقل إلى تبويب متقدم.

الخلاصة — القائمة الضخمة روابط داخلية ضمن واجهة أكبر، ولذلك تبدأ سلامتها بشرط <a href>. أكثر أعطال الواقع شيوعًا لوحة JavaScript لا تحتوي على مراسي حقيقية؛ فتبدو مرتبطة للمستخدم ولا تستطيع Google زحفها، وقد تعزل الصفحات إذا كانت القائمة مسارها الداخلي الوحيد. افحص «عرض المصدر» لا أداة الفحص. لا يُستبعد المحتوى المخفي حتى التمرير لمجرد إخفائه ما دام موجودًا في HTML الأولي ولم يُجلب بعد التفاعل فقط؛ الإخفاء عبر CSS مقبول، أما AJAX عند التمرير فهو الخطر. تقول Google إنها تأخذ هذا المحتوى في الحسبان، لكنها لم توثق مساواة وزنه دائمًا بالمحتوى الظاهر. لا يوجد سقف صارم لعدد الروابط؛ التنظيم هو العامل الأهم: اجمعها حسب الفئات في أعمدة قابلة للمسح وبنصوص ربط وصفية. ويجب أن تتضمن قائمة الجوال الروابط القابلة للزحف نفسها. البيانات المنظمة لا تعوّض الروابط الحقيقية.

ابدأ من هنا: القائمة الضخمة ليست سوى روابط داخلية

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

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

العطل الأكثر شيوعًا: معالجات JavaScript بدل الروابط الحقيقية

هذا أكثر ما أراه يتعطل عمليًا. قد يستخدم الفريق إضافة jQuery قديمة أو مكوّن React/Vue مخصصًا، فتكون «روابط» اللوحة معالجات نقر أو سمات موجّه بلا href، أو محتوى لا يُحقن في DOM إلا بعد التمرير أو النقر. وهذه الأنماط تطابق مباشرة صيغ الروابط التي تقول Google إنها لا تستطيع زحفها بثبات:

<a routerLink="products/category">Shoes</a>          <!-- no href -->
<span href="https://example.com">Shoes</span>        <!-- not an anchor -->
<a onclick="goto('https://example.com')">Shoes</a>   <!-- onclick, no href -->

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

كيف تتحقق من قابلية زحف القائمة فعلًا؟

لا تثق بالصفحة المعروضة وحدها؛ افحص المصدر.

• استخدم عرض مصدر الصفحة، لا فحص العنصر. يعرض المصدر HTML الخام الذي أرسله الخادم، بينما تعرض أداة الفحص DOM بعد تشغيل JavaScript، وهو ما قد يخفي العطل المقصود. إذا ظهرت روابط اللوحة كعناصر <a href="..."> في المصدر فهي مرسومة من الخادم؛ وإن ظهرت في أداة الفحص فقط فهذه إشارة حمراء.
• أداة فحص عنوان URL في GSC. افحص الصفحة في Search Console وراجع HTML المعروض أو الصفحة التي زحفها Googlebot لمعرفة ما انتهى إليه فعليًا.

الدقة المهمة هي أن Google يعرض JavaScript حاليًا، ولذلك قد يزحف قائمة مبنية به، لكن «قد» ليست ضمانًا. النمط الآمن القابل للتحقق هو روابط <a href> مرسومة من الخادم، ثم تحسينها تدريجيًا بـ JavaScript للحركة والتفاعل. استخدم JavaScript ليضبط سلوك القائمة، لا ليخلق وجود الروابط.

هل يُخفَّض المحتوى المخفي حتى التمرير؟

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

ليس تلقائيًا، لكن يلزم التعبير بدقة. تقول إرشادات Google الحالية وتصريح John Mueller إن المحتوى الموجود في HTML والمخفي بصريًا داخل لوحة أو أكورديون أو تبويب مغلق يؤخذ في الحسبان ولا يُستبعد مباشرة. وعندما سُئل Mueller عن تخفيض قيمة محتوى التبويبات والأكورديون في الفهرسة المعتمدة على الجوال قال: “No. Specifically when it comes to content on mobile pages we do take into account anything that’s in the HTML. So if there’s something there that might be visible to users at some point we will include that… so that’s completely normal”. (ترجمة) «لا. فيما يخص محتوى صفحات الجوال تحديدًا، نأخذ في الحسبان كل ما يوجد في HTML. فإذا كان هناك شيء قد يصبح مرئيًا للمستخدمين في وقت ما فسندخله… وهذا طبيعي تمامًا». نقل Roger Montti التصريح في Search Engine Journal. وتؤكد وثائق الفهرسة المعتمدة على الجوال عمليًا أن وضع المحتوى في أكورديون أو تبويبات مقبول ما دام مكافئًا لسطح المكتب.

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

يحل ذلك محل الادعاء الشائع تقريبًا في 2015–2016 بأن ما وراء التبويبات ومربعات التوسيع يحصل بالضرورة على وزن أقل. ما يدعمه السجل أضيق: لا يُهمَل المحتوى الموجود في HTML لمجرد إخفائه، لكن مساواة وزنه بالمحتوى المرئي لم تُوثق. لا تستبدل خرافة «مخفَّض دائمًا» بادعاء غير مدعوم بأنه «متساوٍ بالتأكيد».

وهنا الفارق الحاسم: «مخفي عبر CSS» و«مجلوب بعد التفاعل فقط» حالتان مختلفتان تمامًا.

• اللوحة التي تستخدم display:none حتى التمرير، مع وجود الروابط مسبقًا في DOM، قابلة للفهرسة بصورة طبيعية.
• اللوحة التي تجلب HTML عبر استدعاء API يبدأ عند التمرير قد لا تُزحف إطلاقًا.

ليست الحالة الثانية مشكلة «تخفيض محتوى مخفي»، بل مشكلة قابلية زحف: لا توجد الروابط قبل أن يفعل المستخدم شيئًا، فلا يراها الزاحف. الخلط بين العطلين يبقي الخرافة حية. افصل بينهما: إخفاء CSS سليم؛ وروابط AJAX التي لا تظهر إلا بعد التفاعل معطلة.

ميزانية الروابط: جمّعها ولا تكدّسها

لا يوجد حد صارم موثق لعدد روابط القائمة الضخمة. قاعدة «100 رابط في الصفحة» خرافة، كما يشرح مقال الروابط الداخلية؛ وموقف Google أنه لا يوجد عدد مثالي سحري.

لكن غياب الحد لا يعني إدراج كل شيء. العامل الحقيقي هو التنظيم لا العدد الخام. في جلسة Search Central عام 2021 نُقلت حالة قائمة تضم أكثر من 1 000 رابط وانخفضت الزيارات بعد تحويلها من تحميل عند التمرير إلى HTML ثابت. لم يكن قلق Mueller العدد بذاته، بل أن مجموعة هائلة غير مميزة من الروابط على المستوى نفسه تسطّح التجميع الموضوعي. قال: “we think, oh, all of these are equally important, and we don’t really know which of these are connected to each other” (ترجمة) «نعتقد أن هذه كلها متساوية الأهمية، ولا نعرف حقًا أيها مرتبط ببعضه»، وقال: “a pyramid structure helps us a lot more to understand the context of individual pages.” (ترجمة) «تساعدنا البنية الهرمية كثيرًا على فهم سياق الصفحات الفردية». كما رأى أن إعادة بعض تلك الروابط إلى التحميل عند التمرير يمكن أن تكون إصلاحًا بنيويًا مشروعًا إذا بقيت لها مسارات زحف من صفحات أخرى أكثر صلة.

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

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

يجب أن تحمل نسخة الجوال الروابط نفسها، لا واجهة أصغر فحسب

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

نفّذ على الجوال التدقيق نفسه: راجع HTML المعروض للتنقل، وتأكد من وجود الوجهات نفسها ومن أن كل واحدة عنصر <a href> حقيقي. الاختبار هو ذاته للقابلية والتكافؤ، لكنه يجري على الواجهة الأصغر.

يغطي ذلك الوجهات لا التفاعل، وهما اختباران منفصلان. لا تشترط الفهرسة المعتمدة على الجوال تخطيط تفاعل مطابقًا، لذلك يصلح الهامبرغر أو الأكورديون. لكن نمط الكشف يحتاج اختبار لوحة المفاتيح والتركيز: هل يستطيع مستخدم لوحة المفاتيح بلوغ الزر وفتحه والتنقل بين الوجهات مع حالة aria-expanded دقيقة؟ يقدم نمط تنقل الكشف في WAI-ARIA مثالًا مطابقًا، لا الحل الوحيد. اختبر تكافؤ الوجهات وسلوك الكشف/لوحة المفاتيح كشرطين مستقلين، إذ قد تنجح القائمة في أحدهما وتفشل في الآخر.

خرافة أخرى: البيانات المنظمة لا تصلح قابلية الزحف

تعرض بعض الأدلة ترميز SiteNavigationElement كأنه يجعل القائمة قابلة للزحف، لكنه لا يفعل. تستطيع البيانات المنظمة وصف التنقل دلاليًا، ولا تعوّض الروابط الفعلية. وقد أوضح Mueller: “we don’t use those URLs in the same way as we would use normal internal links on a page.” (ترجمة) «لا نستخدم عناوين URL تلك بالطريقة نفسها التي نستخدم بها الروابط الداخلية العادية في الصفحة». المخطط طبقة فوق روابط <a href> القابلة للزحف، لا بديلًا منها.

ما الذي تضمنه هذه الاختبارات، وما الذي لا تضمنه؟

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

هل يحتاج موقعك أصلًا إلى قائمة ضخمة؟

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

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

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

• القائمة الضخمة روابط داخلية في واجهة أكبر. يجب أن يكون كل رابط <a href> حقيقيًا.
• العطل الأول عمليًا لوحة JavaScript بروابط ليست مراسي حقيقية، مثل onclick أو routerLink بلا href أو DOM لا يُحقن إلا بعد التفاعل؛ فتعجز Google عن زحفها وقد تصبح الصفحة يتيمة. العطل صامت ولذلك يفوت الاختبار البشري.
• تحقق بعرض المصدر لا أداة الفحص، واستعمل كذلك فحص عنوان URL في GSC.
• النمط الآمن روابط مرسومة من الخادم ومحسنة تدريجيًا بـ JavaScript للحركة، لا روابط يعتمد وجودها عليه.
• المخفي حتى التمرير لا يُستبعد تلقائيًا. يأخذ Google المحتوى الموجود في HTML في الحسبان، لكنه لم يوثق مساواة وزنه بالمحتوى الظاهر. إخفاء CSS سليم؛ والجلب بعد التفاعل قد لا يُزحف.
• لا يضمن أي تعديل نتيجة بحث. الاختبارات تزيل أعطالًا محددة ولا تضمن الزحف أو الفهرسة أو الترتيب أو الزيارات أو استشهاد الذكاء الاصطناعي.
• لا سقف صارمًا للروابط؛ وقاعدة 100 رابط خرافة. التنظيم حسب الفئات، والأعمدة القابلة للمسح، ونصوص الربط الوصفية أهم من العدد.
• يحتاج الجوال الروابط القابلة للزحف نفسها، لا قائمة مختصرة.
• SiteNavigationElement لا يعوّض الروابط الحقيقية.

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

لا توجد وثيقة من Google أو Bing مخصصة تحديدًا «للقوائم الضخمة». الإرشادات الرسمية هنا هي قواعد قابلية زحف الروابط ونص الربط والفهرسة المعتمدة على الجوال مطبقة على هذا النمط. وفيما يلي المصادر الأولية ذات الصلة.

Google

• أفضل ممارسات روابط SEO — شرط <a href> وصيغ الروابط غير الموصى بها، مثل غياب href أو استخدام onclick أو عنصر غير مرساة.
• أفضل ممارسات الفهرسة المعتمدة على الجوال — تكافؤ محتوى الجوال وسطح المكتب، وجواز وضع المحتوى في أكورديون أو تبويبات ما دام مكافئًا.
• الدليل المتعمق لعمل بحث Google — السياق العام لاكتشاف عناوين URL عبر الروابط.

Bing / Microsoft

• إرشادات مشرفي مواقع Bing — لا تتناول القوائم الضخمة تحديدًا، لكنها توصي بإبقاء الصفحات المهمة ضمن نحو ثلاث نقرات من الصفحة الرئيسية وتعتمد أكثر على خرائط XML للاكتشاف. لذلك قد يكون عزل الصفحات عرضًا أخطر حين تقل مسارات الاكتشاف البديلة.

Schema.org

• SiteNavigationElement — نوع مخطط للتنقل، يفيد كتحسين دلالي فوق روابط حقيقية ولا يصلح مشكلة الزحف.

إتاحة الوصول (WAI-ARIA / WCAG)

• مثال قائمة تنقل الكشف في WAI-ARIA — تنفيذ عملي لسلوك قابل للتشغيل بلوحة المفاتيح، وهو مثال لا الشكل المطابق الوحيد.
• WCAG 2.2 — فهم معيار النجاح 2.1.1: لوحة المفاتيح — الشرط الأساسي لإمكان تشغيل الزر واللوحة من دون فأرة.

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

تصريحات مسجلة ذات صلة ببناء قائمة ضخمة قابلة للزحف ومنظمة جيدًا.

Google — شرط الرابط القابل للزحف (أفضل ممارسات روابط SEO)

• “Google can only crawl your link if it’s an <a> HTML element (also known as anchor element) with an href attribute.” (ترجمة) «لا تستطيع Google زحف رابطك إلا إذا كان عنصر HTML من نوع <a>، المعروف أيضًا بعنصر المرساة، ويحمل السمة href». الانتقال إلى الاقتباس

John Mueller، Google — المحتوى المخفي أو المبوب يؤخذ في الحسبان مثل المحتوى المرئي

• “No. Specifically when it comes to content on mobile pages we do take into account anything that’s in the HTML. So if there’s something there that might be visible to users at some point we will include that… so that’s completely normal.” (ترجمة) «لا. بالنسبة إلى صفحات الهاتف تحديدًا، ننظر في كل ما يتضمنه HTML؛ فإذا وُجد عنصر قد يراه المستخدم لاحقًا فسندخله، وهذا سلوك معتاد»؛ جاء الرد على سؤال مباشر عن تخفيض محتوى التبويبات والأكورديون في الفهرسة المعتمدة على الجوال. قراءة التغطية

John Mueller، Google — البنية المسطحة مقابل الهرمية في قائمة من 1 000 رابط

• “If it’s very flat, then we think, oh, all of these are equally important, and we don’t really know which of these are connected to each other.” (ترجمة) «إذا كانت البنية مسطحة جدًا، فنعتقد أن هذه كلها متساوية الأهمية، ولا نعرف حقًا أيها مرتبط ببعضه». قراءة التغطية
• “A pyramid structure helps us a lot more to understand the context of individual pages within the site.” (ترجمة) «تساعدنا البنية الهرمية كثيرًا على فهم سياق كل صفحة في الموقع». / “I don’t think it would always have a negative effect.” (ترجمة) «لا أعتقد أن لها دائمًا أثرًا سلبيًا»، بشأن الانتقال من نحو 1 000 رابط مسطح إلى بنية أعمق. قراءة التغطية

John Mueller، Google — البيانات المنظمة ليست بديلًا للروابط الداخلية الحقيقية

• “Even if in the structured data you also provide URLs, we don’t use those URLs in the same way as we would use normal internal links on a page.” (ترجمة) «حتى إذا قدمت عناوين URL في البيانات المنظمة، فإننا لا نستخدمها بالطريقة نفسها التي نستخدم بها الروابط الداخلية العادية في الصفحة».

هل ينبغي أن تستخدم قائمة ضخمة، وهل قائمتك آمنة؟

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

قائمة فحص SEO للقائمة الضخمة

نفّذها من الأعلى إلى الأسفل: قابلية الزحف أولًا، ثم البنية، ثم الجوال:

• كل رابط في اللوحة عنصر <a href> حقيقي، لا onclick ولا routerLink ولا سمة routerLink بلا href ولا عنصرًا غير مرساة منسقًا كرابط.
• تظهر الروابط في عرض مصدر الصفحة لا في أداة الفحص وDOM الحي فقط.
• يوجد HTML الخاص باللوحة في الصفحة الأولية ويُخفى بـ CSS، ولا يُجلب عبر API عند التمرير أو النقر.
• يؤكد فحص عنوان URL في GSC وجود الروابط في HTML المزحوف أو المعروض.
• يحسّن JavaScript ولا ينشئ: يدير الحركة والتفاعل بينما تبقى الروابط موجودة بدونه.
• لا وجهات يتيمة: لا تعتمد صفحة مهمة على القائمة كرابطها الداخلي الوحيد.
• تُجمع الروابط حسب الفئة بعناوين أعمدة تعكس تسلسل الموقع، لا في جدار غير منظم.
• الأعمدة قابلة للمسح وفي كل مجموعة عدد محدود من العناصر.
• نص الربط وصفي ومحدد لكل وجهة، لا عبارة عامة مكررة.
• القائمة انتقائية لا شاملة، وتحصل الصفحات المهمة أيضًا على روابط سياقية.
• قائمة الجوال تضم الروابط نفسها الموجودة في نسخة سطح المكتب.
• روابط الجوال أيضًا عناصر <a href> حقيقية وافحصها بالمصدر وGSC.
• البيانات المنظمة SiteNavigationElement، إن استُخدمت، فوق روابط فعلية لا بدلًا منها.
• أعد الفحص بعد ترقيات الواجهة لأن تغييرات الأطر قد تحول الروابط بصمت إلى معالجات نقر.

ورقة غش SEO للقائمة الضخمة

قابل للزحف أم لا؟

نمطا الفشل اللذان يخلط الناس بينهما

• مخفي بـ CSS: الروابط في DOM واللوحة مخفية حتى التمرير ← تُفهرس طبيعيًا.
• مجلوب بعد التفاعل: لا توجد الروابط حتى يقع حدث ← قد لا تُزحف أبدًا. هذا عطل قابلية زحف لا مسألة تخفيض محتوى مخفي.

الخرافة مقابل الواقع

تحقق سريع

• عرض مصدر الصفحة لا أداة الفحص: ابحث عن رابط قائمة وتأكد أنه <a href>.
• فحص عنوان URL في GSC: هل تظهر الروابط في HTML المزحوف أو المعروض؟
• الجوال: كرر الاختبارين على قائمة الهامبرغر أو الأكورديون.

ترميز جيد وسيئ للقائمة الضخمة

سيئ: لوحة تعتمد على JavaScript فقط

الروابط التي لا توجد قبل تشغيل JavaScript لا تستطيع Google تتبعها بثبات، كما في الأمثلة الآتية:

<nav class="mega">
  <button class="trigger" onclick="openFlyout('shoes')">Shoes</button>
  <div class="flyout" id="shoes-flyout" hidden>
    <!-- injected by JS after the click; empty in the server HTML -->
    <span class="menu-link" data-url="/shoes/mens/">Men's shoes</span>
    <span class="menu-link" data-url="/shoes/womens/">Women's shoes</span>
    <a routerLink="/shoes/kids/">Kids' shoes</a>          <!-- no href -->
    <a onclick="go('/shoes/sale/')">Sale</a>              <!-- onclick, no href -->
  </div>
</nav>

كل وجهة هنا غير مرئية للزاحف: «روابط» <span> ليست مراسي، وrouterLink بلا href، ومرساة onclick لا تحمل مسارًا يمكن تتبعه. وإذا لم تكن لهذه الصفحات روابط داخلية أخرى تصبح يتيمة.

جيد: روابط مرسومة من الخادم ومحسنة تدريجيًا

الروابط عناصر <a href> حقيقية موجودة في HTML الذي أرسله الخادم، ولا يضيف JavaScript إلا سلوك التمرير:

<nav class="mega" aria-label="Primary">
  <ul>
    <li>
      <a href="/shoes/">Shoes</a>
      <div class="flyout">          <!-- CSS: display:none until hover/focus -->
        <div class="col">
          <h3>Men's</h3>
          <ul>
            <li><a href="/shoes/mens/running/">Men's running shoes</a></li>
            <li><a href="/shoes/mens/boots/">Men's boots</a></li>
          </ul>
        </div>
        <div class="col">
          <h3>Women's</h3>
          <ul>
            <li><a href="/shoes/womens/running/">Women's running shoes</a></li>
            <li><a href="/shoes/womens/boots/">Women's boots</a></li>
          </ul>
        </div>
      </div>
    </li>
  </ul>
</nav>

/* Hidden until hover — links are still in the DOM, so they're crawled normally */
.flyout { display: none; }
.mega li:hover > .flyout,
.mega li:focus-within > .flyout { display: block; }

كل شيء هنا قابل للزحف في HTML الخام، ولا يغيّر إخفاء اللوحة بـ CSS ذلك؛ فالمحتوى الموجود في DOM لا يُستبعد لمجرد الإخفاء البصري.

أفضل: التجميع بدل الجدار

يتضمن المثالان أدناه عدد الروابط نفسه لكنهما يقدمان لـ Google إشارتين مختلفتين: إلى اليسار قائمة غير مجمعة، وإلى اليمين الروابط ذاتها تحت عناوين تعكس التسلسل الهرمي.

<!-- Structurally flat: an ungrouped wall -->
<div class="flyout">
  <a href="/shoes/mens/running/">Men's running</a>
  <a href="/shoes/womens/running/">Women's running</a>
  <a href="/shoes/kids/">Kids'</a>
  <a href="/shoes/mens/boots/">Men's boots</a>
  <a href="/shoes/sale/">Sale</a>
  <a href="/shoes/womens/boots/">Women's boots</a>
  <!-- ...140 more, no structure... -->
</div>

<!-- Grouped: the hierarchy is legible -->
<div class="flyout">
  <div class="col"><h3>Men's</h3>
    <ul><li><a href="/shoes/mens/running/">Running</a></li>
        <li><a href="/shoes/mens/boots/">Boots</a></li></ul></div>
  <div class="col"><h3>Women's</h3>
    <ul><li><a href="/shoes/womens/running/">Running</a></li>
        <li><a href="/shoes/womens/boots/">Boots</a></li></ul></div>
  <div class="col"><h3>Kids &amp; Sale</h3>
    <ul><li><a href="/shoes/kids/">Kids' shoes</a></li>
        <li><a href="/shoes/sale/">Sale</a></li></ul></div>
</div>

كلا المثالين قابل للزحف، لكن النسخة المجمعة وحدها تحفظ علاقات الفئات التي تساعد Google على فهم الصفحات المنتمية إلى بعضها.

الأنماط المضادة في القوائم الضخمة

هذه أكثر طرق تعطل القوائم الضخمة تكرارًا، وما ينبغي فعله بدلًا منها.

1. معالجات نقر بدل المراسي. استخدام onclick أو routerLink بلا href أو <span> منسق كرابط يبدو سليمًا للإنسان ولا يستطيع الزاحف تتبعه. ← استخدم روابط <a href> فعلية وحسّن سلوكها بـ JavaScript.

2. جلب HTML للوحة عند التمرير. يُسحب المحتوى من API بعد الحدث، فلا توجد الروابط حتى يتفاعل المستخدم. ← ضع الروابط في HTML الأولي وأخف اللوحة بـ CSS.

3. الثقة بالصفحة المعروضة بدل المصدر. يفوّت فحص DOM الحي عطل JavaScript الذي تبحث عنه. ← استخدم عرض مصدر الصفحة وفحص عنوان URL في GSC.

4. جدار روابط غير مميز. تسطح مئات الروابط على المستوى نفسه إشارة التجميع رغم عدم خرق حد عددي. ← اجمعها حسب الفئات بعناوين تعكس التسلسل الهرمي واجعل القائمة انتقائية.

5. نص ربط عام ومتكرر. لا تخبر عبارات مثل «تسوّق الآن» و«عرض الكل» و«انقر هنا» محرك البحث بوجهة الرابط. ← اكتب نصًا وصفيًا خاصًا بكل وجهة.

6. قائمة جوال مختصرة. حذف الروابط من الهامبرغر أو الأكورديون يكسر تكافؤ المحتوى وقد يعزل صفحات مسارها الوحيد قائمة سطح المكتب. ← احتفظ بالروابط نفسها وتأكد من أنها مراسٍ حقيقية.

7. معاملة المخطط كإصلاح للزحف. إضافة SiteNavigationElement فوق روابط JavaScript لا تجعلها قابلة للزحف. ← المخطط طبقة دلالية فوق روابط موجودة، لا بديلًا منها.

8. الاعتقاد بأن المخفي حتى التمرير مخفَّض. تؤدي الخرافة القديمة إلى حلول معقدة بلا داعٍ. الروابط الموجودة في DOM والمخفية بـ CSS تُؤخذ في الحسبان. ← تأكد ببساطة من وجودها فعلًا في HTML.

مشكلات القائمة الضخمة التي ينبغي تشخيصها

تبدو الروابط عاملة لكن الزاحف لا يكتشفها

العَرَض: يفتح النقر الوجهة في المتصفح، لكن عنوان URL يغيب عن زحف بدأ من الصفحة الرئيسية. السبب المرجح: العنصر div أو button أو معالج JavaScript بدل مرساة تحمل href. الإصلاح: اعرض <a href="/destination/"> حقيقيًا في HTML، ثم أعد الزحف من الصفحة الرئيسية وتأكد من ظهور الوجهة كرابط داخلي صادر.

روابط سطح المكتب قابلة للزحف لكن روابط الجوال تختفي

العَرَض: تظهر الفئات المهمة في قائمة سطح المكتب ولا تظهر في DOM على الجوال. السبب المرجح: تستخدم قائمة الجوال مصدر بيانات منفصلًا ومختصرًا. الإصلاح: أعطِ أكورديون الجوال الوجهات المهمة نفسها وتأكد من وجود المراسي قبل أي نقرة.

تفتح اللوحة بالتمرير ولا تفتح بلوحة المفاتيح

العَرَض: يستطيع مستخدم الفأرة الوصول إلى اللوحة، ولا يكشفها Tab وEnter. السبب المرجح: يعتمد التفاعل على التمرير وحده. الإصلاح: اجعل المشغّل زرًا يدعم لوحة المفاتيح وحالة aria-expanded دقيقة، وأبقِ روابط الوجهات مراسٍ عادية.

إطار الوصول والعرض والتقييد

استخدم ثلاثة اختبارات عند مراجعة أي قائمة ضخمة:

1. الوصول: هل يستطيع المستخدم والزاحف بلوغ كل وجهة مهمة عبر مرساة حقيقية على سطح المكتب والجوال؟
2. العرض: هل توجد المراسي في HTML المستلَم أو المعروض من دون اشتراط تمرير أو نقرة أو استجابة API؟
3. التقييد: هل تقتصر القائمة على الوجهات التي تستحق روابط على مستوى الموقع وتُجمع تحت عناوين مفيدة بدل أن تصبح خريطة موقع منسدلة؟

تفشل القائمة إذا انكسر أي اختبار. يحمي الوصول الاكتشاف، ويحمي العرض التنفيذ، ويحمي التقييد التسلسل الهرمي وسهولة الاستخدام.

فحص روابط القائمة الضخمة في المتصفح

شغّل الشيفرة الآتية في وحدة تحكم Chrome DevTools بينما القائمة مغلقة. تسرد المراسي داخل حاويات التنقل الشائعة وتحدد العناصر التي لا تحمل href:

const links = [...document.querySelectorAll('header nav a, [role="navigation"] a')];
console.table(links.map(a => ({ text: a.textContent.trim(), href: a.getAttribute('href'), crawlable: a.hasAttribute('href') })));

شغّل المقتطف نفسه بعرضي سطح المكتب والجوال. أي وجهة تظهر في مجموعة نتائج واحدة فقط تحتاج إلى مراجعة.

استخراج وجهات التنقل أثناء الزحف

استخدم XPath الآتي في خاصية الاستخراج المخصص لدى الزاحف لجمع عناوين URL في القائمة:

//header//nav//a[@href]/@href | //*[@role='navigation']//a[@href]/@href

يغطي الاتحاد عناصر nav الدلالية ومناطق التنقل المحددة بدور ARIA. قارن المجموعة المستخرجة بمخزون التنقل المعتمد بدل افتراض أن كل هدف قابل للنقر هو رابط.

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

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

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

رسمي

• أفضل ممارسات روابط SEO من Google — المرجع الأساسي لما يجعل الرابط قابلًا للزحف.
• أفضل ممارسات الفهرسة المعتمدة على الجوال من Google — شرط تكافؤ المحتوى الذي يجب أن تحققه قائمة الجوال.

من أنحاء الصناعة

• Mueller من Google وخرافة محتوى التبويبات المخفي — التصريح المباشر بشأن أخذ المحتوى المخفي حتى التفاعل في الحسبان.
• Google توصي ببنية تنقل هرمية للمواقع الكبيرة — إجابة Mueller الكاملة عن قائمة 1 000 رابط ومصدر إرشاد ميزانية الروابط هنا.
• هل محتوى التبويبات عامل ترتيب في Google؟ — تاريخ النقاش وسبب تقادم ادعاء «التخفيض».
• Google: محتوى التبويبات أو مربعات التوسيع مخفَّض — الإرشاد الأقدم الذي استُبدل لاحقًا، ويفيد في فهم أصل الخرافة.
• القوائم الضخمة وSEO — معالجة نظرية لقيمة الروابط مع مثال عن توزيع PageRank؛ خلفية مفيدة وليست مصدرًا من Google.
• r/TechSEO — مجتمع لتشخيص الصفحات اليتيمة ومشكلات قابلية الزحف.

اختبر نفسك: SEO للقائمة الضخمة

خمسة أسئلة سريعة عن بناء قائمة ضخمة قابلة للزحف ومنظمة جيدًا. اختر إجابة لكل سؤال ثم تحقق.

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