بنية الموقع المسطحة مقابل العميقة: إطار عملي لاتخاذ القرار

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

ما المقصود فعليًا بالبنية «المسطحة» و«العميقة»؟

لكل موقع تسلسل هرمي: الصفحة الرئيسية في القمة، ثم الأقسام، ثم الصفحات الفردية. لكن التعريف المفيد ليس عددًا ثابتًا من الطبقات، بل توزيع عمق النقر في موقعك (نسبة الصفحات عند العمق 1 و2 و3 و4+) وبالأخص عدد النقرات اللازمة للوصول إلى صفحاتك ذات الأولوية. تصف البنية المسطحة توزيعًا تقع فيه معظم الصفحات، ولا سيما ذات الأولوية، على بُعد نقرة أو نقرتين من الصفحة الرئيسية. وتصف البنية العميقة توزيعًا يتطلب فيه بلوغ الصفحات المعتادة المرور بطبقات عدة: الصفحة الرئيسية ← الفئة ← الفئة الفرعية ← الفئة الفرعية الأدنى ← الصفحة. أما نطاقات عدد الصفحات والمستويات الواردة لاحقًا فهي قواعد إرشادية لمعايرة هذا التوزيع وليست تعريفه.

تشرح المقالات المجاورة في هذه المجموعة، عن بنية الموقع وهيكل الموقع، لماذا يتفوق الهرم المتزن على موقع مسطح كالفطيرة أو موقع عميق بلا داعٍ. وهذه المقالة هي المتابعة العملية: كيف تقرر مقدار التسطيح أو العمق المناسب لموقعك تحديدًا، وكيف تفحصه وتصلحه؟

الإجابة المختصرة

لا يوجد عدد «صحيح» عالمي للمستويات. ويتوقف القرار على سؤالين:

1. كم صفحة لديك يجب أن يكون العثور على كل منها ممكنًا بذاتها؟ يستطيع موقع شركة صغير من 40 صفحة إبقاء كل شيء على بُعد نقرة أو نقرتين من الصفحة الرئيسية. ولا يستطيع متجر يضم ٢٠٬٠٠٠ منتج ذلك؛ إذ يحتاج إلى فئات وفئات فرعية، وإلا صار التنقل جدارًا غير صالح للاستخدام من الروابط.
2. ما مدى وضوح الفصل بين فئاتك؟ إذا كانت أقسامك واضحة وغير متداخلة (الأحذية مقابل القمصان)، يمكنك الحفاظ على بنية أكثر تسطحًا. وإذا تداخلت، فستحتاج عادةً إلى شيء من البنية الإضافية لتنظيمها.

القاعدة الوحيدة الجديرة بالتذكر

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

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

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

الخلاصة — هذه المقالة هي دليل «كيف أقرر وأنفّذ» المرافق للتغطية المفاهيمية للهرم مقابل التسطيح، وليست إعادةً للنقاش حول تفوق الهرم على الطرفين. ينبغي أن يتناسب العمق أساسًا مع (أ) مدى تمايز الفئات الطبيعية والقوالب وأنماط التحديث، ثم مع (ب) عدد الصفحات التي تحتاج إلى URL مستقل يمكن العثور عليه. وبوصفها قواعد إرشادية للمعايرة لا حدودًا ثابتة: موقع تعريفي من نحو 50 صفحة ← مسطح؛ بضعة آلاف من الصفحات ← هرم ضحل من مستويين إلى ثلاثة؛ أكثر من ١٠٬٠٠٠ وحدة SKU ← تسلسل هرمي متعدد المستويات مع صفحات مركزية، وإلا ظهر نمط فشل القائمة الضخمة المكدسة بالروابط. لا تحدد Google حدًا أقصى للنقرات. قِس توزيع عمق النقر المقسّم بالزحف، حسب القالب والأولوية لا بمتوسط الموقع كله، ثم قارنه بحذر مع إحصاءات الزحف في GSC؛ فهي بيانات إجمالية من الطرف الأول وليست إثباتًا لكل URL، وذلك للعثور على هاوية العمق التي يتراجع عندها الزحف. أصلح بصفحات مركزية، وهي الأعلى عائدًا، ووحدات المحتوى ذي الصلة ومسارات التنقل، مع اختبار كل تغيير في مقابل شريحة مقارنة ونافذة مراقبة ومحفّز للتراجع. عمق مجلدات URL لا يساوي عمق النقر؛ اربط الصفحة المدفونة من موضع أقرب بدل إعادة كتابة URL. ولا يضمن شيء من ذلك مكاسب في الزحف أو الفهرسة أو الترتيب أو الزيارات أو الاستشهادات بالذكاء الاصطناعي.

هذه ليست مقالة «لماذا»

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

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

العمق دالة في تمايز الفئات والحجم

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

1. مدى تمايز الفئات الطبيعية أو تداخلها، والمهمة التي يؤديها المستخدم. تلخص أبحاث Nielsen Norman Group عن التسلسلات الهرمية المسطحة والعميقة للمواقع الأمر: «Flat hierarchies tend to work well if you have distinct, recognizable categories, because people don’t have to click through as many levels,» (الترجمة العربية) «تعمل التسلسلات المسطحة جيدًا عادةً عندما تكون لديك فئات مميزة يسهل تمييزها، لأن الناس لا يضطرون إلى النقر عبر مستويات كثيرة»، وكذلك «Categories that are specific and do not overlap are the easiest to understand.» (الترجمة العربية) «الفئات المحددة وغير المتداخلة هي الأسهل فهمًا». وخلاصتهم توافق روح هذا الإطار: «Like most design questions, there’s no single right answer, and going too far to either extreme will backfire.» (الترجمة العربية) «كما في معظم أسئلة التصميم، لا توجد إجابة صحيحة واحدة، والمبالغة في أي من الطرفين ستأتي بنتائج عكسية». ووازن أيضًا قالب الصفحة وأهميتها للأعمال وتكرار تحديث القسم، مثل مثال Illyes عن /news/ و/archives/ أدناه؛ فهذه العوامل لا تقل أهمية عن عدد الصفحات المجرد.
2. عدد العناصر المميزة التي تحتاج إلى صفحة مستقلة يمكن العثور عليها. تمثل 40 صفحة و٢٠٬٠٠٠ منتج مشكلتين مختلفتين، لكن عدد الصفحات وحده إشارة تقريبية لا العامل الحاسم؛ فقد يحتاج موقع صغير ذو فئات شديدة التداخل إلى بنية أكثر من موقع أكبر ذي أقسام واضحة ومتمايزة.

تشير إرشادات Google في الاتجاه نفسه من ناحية الحجم. قال Gary Illyes إن التسلسل الهرمي ينبغي أن يتناسب مع الموقع، وإنه في الموقع الكبير «likely better to have a hierarchical structure» (الترجمة العربية) «من الأفضل على الأرجح اعتماد بنية هرمية»، لأنها تتيح لمحركات البحث «treat different sections differently, especially when it comes to crawling,» (الترجمة العربية) «معاملة الأقسام المختلفة بصورة مختلفة، ولا سيما عند الزحف»، وإنك إذا «put everything in one directory, that’s hardly possible.» (الترجمة العربية) «وضعت كل شيء في دليل واحد، فلن يكاد ذلك يكون ممكنًا». (نقلته Search Engine Journal؛ وأتعامل مع الصياغة الدقيقة بوصفها تفريغًا صحفيًا متخصصًا لا وثيقةً معيارية). وهذه هي النقطة الجوهرية للطرف ذي الكتالوج الكبير: الحجم يفرض التسلسل الهرمي.

قواعد إرشادية لعدد الصفحات

لا ينشر أي من Google أو Bing جدولًا يربط عدد الصفحات بالمستويات، ولا تربط دراسة مؤرخة النطاقين التاليين، نحو 50 صفحة أو أكثر من ١٠٬٠٠٠ صفحة، بعينة محددة من المواقع. تعامل معها كقواعد إرشادية للممارسين تعايرها على موقعك، لا كحدود عالمية مثبتة؛ فقد تدفعك عنها في أي اتجاه درجة تمايز الفئات والقوالب وأنماط التحديث:

• المواقع الصغيرة أو التعريفية (أقل من نحو 50–100 صفحة وفئات طبيعية قليلة): ابقها مسطحة. الصفحة الرئيسية ← مستوى واحد من القسم أو الفئة ← الصفحات، مع وجود معظم المحتوى على عمق نقرة أو نقرتين. رقم Bing البالغ ثلاث نقرات هو الحد الخارجي، ونادرًا ما ستبلغه.
• مواقع المحتوى المتوسطة (بضع مئات إلى بضعة آلاف من الصفحات ومجالات موضوعية متعددة متمايزة فعلًا): هرم ضحل؛ الصفحة الرئيسية ← الفئة ← فئة فرعية اختيارية ← الصفحة، ومعظم المحتوى ضمن ثلاث نقرات.
• كتالوجات التجارة الإلكترونية الكبيرة ومواقع المؤسسات وأرشيفات الناشرين (أكثر من ١٠٬٠٠٠ صفحة أو وحدة SKU): يصبح التسلسل الهرمي ضرورة لا خيارًا جماليًا. تحتاج إلى مستويات كافية: فئة عليا ← فئة فرعية ← طبقة تصفية اختيارية أحيانًا ← المنتج، كي لا تحاول عرض الكتالوج كله في سطح تنقل واحد. الفشل التقليدي هو الإفراط في تسطيح الكتالوج داخل قائمة ضخمة تلقي مئات الروابط على بُعد نقرة واحدة من الصفحة الرئيسية، فتبدد إشارات التجميع. وليس التصحيح «إضافة عمق بلا نهاية»، بل إضافة ما يكفي من التسلسل لتنظيم الكتالوج ثم استخدام الصفحات المركزية لإبقاء العناصر ذات الأولوية في نطاق ثلاث إلى أربع نقرات.

ستجد أدلة منافسة تجزم بأرقام دقيقة، مثل «المسطح = ثلاث نقرات أو أقل» و«اجعل الفئات الفرعية مستويين أو ثلاثة» و«8 فئات عليا × 4–8 فئات فرعية». تفيد هذه الأرقام بوصفها إجماعًا مهنيًا وافتراضات شائعة بحكم الواقع، لكنها غير منسوبة إلى محرك بحث، فتعامل معها بهذه الصفة. أما الشكل البسيط المدعوم جيدًا فهو: كتالوج صغير ← مسطح، وكتالوج كبير ← تسلسل هرمي أكبر.

عمق URL ليس عمق النقر: تذكير لا إعادة شرح

تثبت مقالتا بنية URL وهيكل الموقع في هذه المجموعة أن Google يقرأ رسم الروابط البياني لا الشرطات المائلة في عناوين URL. لا أعيد الحجة هنا؛ وإنما تهم عمليًا لأنها تغير طريقة إصلاح مشكلة العمق.

قد يبدو URL مثل /category/subcategory/product/ عميقًا بثلاثة مستويات، لكنه يصبح على بُعد نقرة واحدة من الصفحة الرئيسية إذا ربطت به صفحة مركزية مباشرةً. وبالعكس قد تُدفن صفحة ذات URL قصير ومرتب على عمق ست نقرات بلا مركز يربط بها. ومن ذلك قاعدتان للإصلاح:

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

هذا التمييز هو ما يتيح المثال التطبيقي اللاحق، من ست نقرات إلى ثلاث، من دون إعادة تسمية شيء.

تدقيق عمقك الحالي بالترتيب

لا يمكنك تحديد الوجهة من دون معرفة موضعك. اتبع ثلاث خطوات:

1. استخرج توزيع عمق النقر من عملية زحف، مقسّمًا لا متوسطًا. شغّل Ahrefs Site Audit، مستخدمًا Structure Explorer أو عرض العمق، أو Screaming Frog، مستخدمًا تبويب Site Structure وعمود Crawl Depth، وانظر إلى نسب الصفحات عند الأعماق 1 و2 و3 و4+. لا تتوقف عند الرقم العام للموقع، بل قسّمه حسب القالب وغرض الصفحة وأولوية الأعمال ومصدر الاكتشاف، أي رابط داخلي مقابل sitemap فقط. راجع مقالة عمق الزحف لآليات القياس على مستوى URL. هذه خريطة الحقيقة للعمق داخل رسم الروابط لا داخل عناوين URL. في الموقع السليم تتركز الصفحات ذات الأولوية تحديدًا في الفئات الضحلة، فقد يخفي متوسط عام جيد قالب إيرادات مدفونًا.

2. قارن بإحصاءات الزحف في GSC، بحذر. يخبرك الزحف بمدى عمق الصفحات، بينما يخبرك تقرير إحصاءات الزحف بما تختار Google زحفه فعليًا ووتيرته. يقسم الطلبات إلى Discovery، أي عناوين URL لم تزحف إليها Google من قبل، وRefresh، أي إعادة زحف صفحات معروفة. تعامل مع الإحصاءات بوصفها بيانات إجمالية على مستوى الموقع ومن الطرف الأول؛ فهي ليست سجلًا لكل URL ولا تثبت وحدها أن صفحة أو شريحة بعينها تعاني بسبب العمق. والقراءة العملية التالية تفسير للممارسين لا تصريح من Google: إذا ظل Discovery قريبًا من الصفر مع استمرار النشر، فربما لا تكشف الروابط الداخلية الصفحات الجديدة أو العميقة للزاحف؛ وإذا هبط Refresh بشدة من دون إزالة صفحات، فقد يكون عامل بنيوي يكبح إعادة الزحف. تكمن الفائدة في وصل بيانات عمق الزاحف ببيانات GSC، لكن تعامل مع الناتج كفرضية تُختبر بمقارنة شريحة غيّرتها بأخرى مشابهة لم تغيّرها، لا كإثبات مستقل.

3. اعثر على هاوية العمق. ضع المصدرين فوق بعضهما: مستوى العمق الذي تهوي بعده وتيرة الزحف والتغطية هو التعريف العملي المقاس لما هو «عميق أكثر من اللازم» في موقعك، وهو أنفع من أي رقم عام. لا تفترض أن العمق 5 سيئ، بل تلاحظ مثلًا أن الزحف في شريحة محددة ينهار بعد العمق 4. وقد تزعم مصادر ثانوية أن الصفحات عند العمق 5 تُزحف أقل 5–10 مرات؛ لم أجد لذلك مصدرًا أوليًا من Google، لذا لن أعرضه كإحصائية. قِس هاويتك أنت واختبرها في مقابل مجموعة مقارنة قبل التصرف.

إصلاح مشكلات العمق

بالترتيب التقريبي للأولوية:

• صفحات المركز أو الفئات، وهي الإصلاح الوحيد الأعلى عائدًا. أضف صفحة في مستوى متوسط أو قوّها كي يستخدمها البشر والزواحف للوصول إلى المحتوى المدفون بنقرات أقل، من دون لمس عناوين URL. وهذه هي الخطوة الأولى غالبًا.
• وحدات المحتوى ذي الصلة. تنشئ روابط نهاية المقال والشريط الجانبي مسارات إضافية إلى الصفحات العميقة. وهي إشارة أضعف من روابط متن المحتوى؛ إذ تحاول Google تحديد المنطقة الأساسية للصفحة وتزن الروابط السياقية أكثر من روابط وحدات التنقل، وهذه قراءة موثقة جيدًا لموقف Mueller لا اقتباس حرفي. لكن كثرة المسارات الحقيقية تساعد عند التوسع.
• مسارات التنقل. تعزز التسلسل الهرمي للمستخدمين ومحركات البحث، ونسختها المقروءة آليًا هي بيانات BreadcrumbList المنظمة. تقول Google: «A breadcrumb trail on a page indicates the page’s position in the site hierarchy, and it may help users understand and explore a site effectively.» (الترجمة العربية) «يشير مسار التنقل في الصفحة إلى موضعها في التسلسل الهرمي للموقع، وقد يساعد المستخدمين على فهم الموقع واستكشافه بفاعلية».
• ترقيم الصفحات وعلاقته بالعمق. القائمة المرقمة مسار زحف بذاتها، الصفحة 1 ← 2 ← 3…، ولذلك يرث المنتج أو المقال الذي لا يظهر إلا في الصفحة 4+ عمق نقر إضافيًا حقيقيًا. لا تعتمد على ترقيم عميق لنقل العناصر ذات الأولوية؛ أبرزها عبر مركز أو وحدة ذات صلة، وأبق صفحات الترقيم ذات canonical ذاتي كي يظل المسار مفتوحًا.

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

لا يَعِد أي من هذه الإصلاحات بالزحف أو الفهرسة أو الترتيب أو الزيارات أو الاستشهادات بالذكاء الاصطناعي؛ فالعمق عامل من عوامل كثيرة. اجعل كل تغيير قابلًا للعكس والاختبار: اختر شريحة مقارنة لا تغيّرها، وحدد نافذة مراقبة، فتكفي عادةً عدة دورات زحف أو إعادة زحف لرؤية تغير اتجاهي في Discovery أو Refresh أو توزيع العمق، وحدد محفّز التراجع مسبقًا. إذا زادت صفحة مركزية نقرات بعض المستخدمين من دون تقصير مسار الزحف المقصود، فتراجع عنها بدل تكديس تغييرات أخرى فوقها. راجع تبويب Validation Tests لجدول الاختبار والمراقبة والتراجع الكامل.

مثال تطبيقي: من ست نقرات إلى ثلاث

خذ منتجًا مدفونًا هكذا: الصفحة الرئيسية ← الفئة العليا ← الفئة الفرعية ← الفئة الفرعية الأدنى ← صفحة القوائم 3 ← المنتج. هذا عمق ست نقرات. المنتج مهم فعلًا، لكن على الزاحف اجتياز قائمة عميقة للوصول إليه، ولذلك يُعاد زحفه نادرًا.

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

متى لا يكون «زحف كل شيء» هو الهدف؟

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

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

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

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

• هذه رفيقة «كيف أقرر» لا مقالة «لماذا يفوز الهرم».
• يتناسب العمق أساسًا مع تمايز الفئات والقوالب والأولوية وأنماط التحديث، ثم مع عدد الصفحات.
• نطاقات عدد الصفحات قواعد للممارسين لا حدود مثبتة: نحو 50 صفحة تعريفية ← مسطح؛ بضعة آلاف ← هرم ضحل من مستويين إلى ثلاثة؛ ١٠٬٠٠٠+ وحدة SKU ← تسلسل متعدد المستويات يمنع فشل القائمة الضخمة. ويرى Illyes أن البنية الهرمية أنسب على الأرجح للمواقع الكبيرة.
• Bing وحده يذكر رقمًا: نحو ثلاث نقرات للصفحات المهمة، هدفًا عمليًا لا ضمانًا؛ ولا تذكر Google رقمًا.
• عمق مجلد URL لا يساوي عمق النقر. أصلح العمق بربط الصفحة من موضع أقرب لا بإعادة كتابة URL.
• دقّق بالترتيب وبالتقسيم لا المتوسط: ازحف لتوزيع العمق حسب القالب والأولوية ومصدر الاكتشاف؛ قارنه بحذر مع Discovery وRefresh في إحصاءات GSC الإجمالية؛ ثم اعثر على هاوية العمق واختبر الفرضية في مقابل شريحة مقارنة.
• أصلح بالترتيب: صفحات المركز أو الفئات، ثم وحدات المحتوى ذي الصلة، ثم مسارات التنقل وBreadcrumbList، مع الانتباه إلى العمق الذي يضيفه ترقيم الصفحات. اجعل التغييرات قابلة للعكس والمراقبة ولا تعد بمكاسب.
• المثال التطبيقي: خُفض عمق منتج من 6 نقرات إلى 3 عبر مركز تشكيلة جديد بلا تغيير URL.
• العمق عامل خطر لا عقوبة تلقائية: قِس الهاوية ولا تفترضها من الرقم.

كم مستوى من التسلسل الهرمي ينبغي أن يضم موقعك؟

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

أيًا كانت النتيجة التي تصل إليها، يبقى التدقيق والإصلاح واحدين: ازحف لاستخراج توزيع عمق النقر، وقارنه بإحصاءات الزحف في GSC للعثور على هاوية العمق، ثم قصّر المسار إلى الصفحات المدفونة ذات الأولوية بصفحة مركزية أولًا.

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

إرشادات المصادر الأولية ذات الصلة بتحديد عمق الموقع وقياسه وإصلاحه.

Google

• أفضل ممارسات روابط SEO: اجعل روابطك قابلة للزحف — يجب أن تكون الروابط <a href>، وينبغي أن يصل رابط واحد على الأقل من صفحة أخرى إلى كل صفحة تهمك، وهو الحد الذي تفشل فيه الصفحات العميقة أو اليتيمة.
• تحسين ميزانية الزحف — كيف يحرم الزحف المهدَر على أنماط URL منخفضة القيمة بقية موقع كبير وعميق.
• تقرير إحصاءات الزحف — تقسيم Discovery مقابل Refresh الذي يستند إليه تشخيص هاوية العمق.
• بيانات BreadcrumbList المنظمة — ترميز الإصلاح الذي يشير إلى موضع الصفحة في التسلسل الهرمي.
• مساعدة Google على فهم بنية موقع التجارة الإلكترونية — الربط الهرمي للكتالوجات الكبيرة وكيف تستدل Google على الأهمية من الروابط.

Bing / Microsoft

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

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

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

Gary Illyes من Google — يتناسب التسلسل الهرمي مع حجم الموقع

• «For a large site it’s likely better to have a hierarchical structure… that will allow you to do funky stuff on just one section, and will also allow search engines to potentially treat different sections differently, especially when it comes to crawling.» (الترجمة العربية) «من الأفضل على الأرجح أن يعتمد الموقع الكبير بنية هرمية، إذ تتيح إجراء أمور خاصة في قسم واحد، وقد تتيح لمحركات البحث معاملة الأقسام بصورة مختلفة، ولا سيما عند الزحف».
• «Having a /news/ section for newsy content and /archives/ for old content would allow search engines to crawl /news/ faster than the other directory.» (الترجمة العربية) «وجود قسم /news/ للمحتوى الإخباري و/archives/ للمحتوى القديم يتيح لمحركات البحث زحف /news/ أسرع من الدليل الآخر».
• «If you put everything in one directory, that’s hardly possible.» (الترجمة العربية) «إذا وضعت كل شيء في دليل واحد، فلن يكاد ذلك يكون ممكنًا». — Gary Illyes، من Google، في SEO Office Hours، كما نقلته Search Engine Journal. نُقلت عبر تفريغ صحفي متخصص لفيديو جلسة مكتبية، لا من صفحة وثائق معيارية؛ تحقق من الصياغة الدقيقة في الأصل قبل اعتمادها نهائيًا.

مساعدة Google Search Console — آلية إحصاءات الزحف وراء «هاوية العمق»

• Discovery: «The URL requested was never crawled by Google before.» (الترجمة العربية) «لم تزحف Google من قبل إلى عنوان URL المطلوب». / Refresh: «A recrawl of a known page.» (الترجمة العربية) «إعادة زحف إلى صفحة معروفة». — تقرير إحصاءات الزحف. من صفحة مركز مساعدة تُعرض بجافاسكربت؛ تحقق من الصياغة في الصفحة الحية قبل اعتمادها نهائيًا.

وثائق Google Search Central — مسارات التنقل والتسلسل الهرمي

• «A breadcrumb trail on a page indicates the page’s position in the site hierarchy, and it may help users understand and explore a site effectively.» (الترجمة العربية) «يشير مسار التنقل في الصفحة إلى موضعها في التسلسل الهرمي للموقع، وقد يساعد المستخدمين على فهم الموقع واستكشافه بفاعلية». — بيانات BreadcrumbList المنظمة. تستخدم الصفحة تبويبات تُعرض بجافاسكربت؛ تحقق من أن الرابط العميق يصل إلى المقطع في الصفحة الحية.

Nielsen Norman Group — ثقل أبحاث تجربة المستخدم المقابل: تمايز الفئات

• «Flat hierarchies tend to work well if you have distinct, recognizable categories, because people don’t have to click through as many levels.» (الترجمة العربية) «تعمل التسلسلات المسطحة جيدًا عادةً عندما تكون الفئات مميزة يسهل تمييزها، لأن الناس لا يضطرون إلى النقر عبر مستويات كثيرة».
• «Categories that are specific and do not overlap are the easiest to understand.» (الترجمة العربية) «الفئات المحددة وغير المتداخلة هي الأسهل فهمًا».
• «Like most design questions, there’s no single right answer, and going too far to either extreme will backfire.» (الترجمة العربية) «كما في معظم أسئلة التصميم، لا توجد إجابة صحيحة واحدة، والمبالغة في أي من الطرفين ستأتي بنتائج عكسية». — Kathryn Whitenton، التسلسلات الهرمية المسطحة والعميقة للمواقع، Nielsen Norman Group. ليس مصدرًا لمحرك بحث؛ يُستشهد به بوصفه أقوى بحث متاح في تجربة المستخدم يربط العمق بتمايز الفئات وقابلية العثور، وهي زاوية تميل إرشادات SEO المحضة إلى إغفالها.

قائمة التحقق لقرار العمق وتدقيقه

نفّذها من أعلى إلى أسفل: حدد الهدف أولًا، ثم قِس، ثم أصلح:

• حددت حجم الموقع. تعرف تقريبًا عدد الصفحات التي تحتاج إلى URL مستقل يمكن العثور عليه.
• قيّمت تمايز الفئات. تعرف هل فئاتك الطبيعية متمايزة فتستطيع البقاء أكثر تسطحًا، أم متداخلة فتحتاج إلى مراكز وروابط متقاطعة.
• حددت هدفًا. للصفحات ذات الأولوية هدف صريح لعمق النقر، نحو 3 نقرات لمعظم المواقع و3–4 للكتالوجات الكبيرة.
• زحفت لاستخراج توزيع عمق النقر. تعرف نسبة الصفحات عند الأعماق 1 و2 و3 و4+.
• قارنت بإحصاءات الزحف في GSC. فحصت Discovery مقابل Refresh وأنماط الاستجابة لما تزحفه Google فعليًا.
• حددت هاوية العمق. عرفت المستوى الذي تهبط عنده وتيرة الزحف أو التغطية؛ وهو «العميق أكثر من اللازم» المقاس لا رقم عام.
• الصفحات ذات الأولوية ضحلة. لا توجد صفحة إيرادات مدفونة على عمق 5–6 نقرات بلا رابط مركزي.
• لا يوجد تسطيح مفرط بقائمة ضخمة. لا يُلقى كتالوج كبير كله في سطح تنقل واحد.
• الصفحات المركزية موجودة. للشرائح المدفونة ذات الأولوية صفحة مركزية أو تشكيلة ضحلة تربط بها مباشرةً.
• مسارات التنقل موجودة مع بيانات BreadcrumbList المنظمة.
• ترقيم الصفحات ليس المسار الوحيد إلى العناصر ذات الأولوية الواقعة في الصفحة 4+ من قائمة.
• لم «تصلح» العمق بإعادة كتابة عناوين URL. اختُصر عمق النقر بربط أقرب لا بتسطيح مسار URL.

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

1. العمق قرص تضبطه مدخلات اثنان. اضبطه وفق (أ) عدد الصفحات القابلة للعثور و(ب) مدى تمايز فئاتك. صغير + متمايز ← مسطح. ضخم + متداخل ← تسلسل هرمي مع مراكز. وما عداه بينهما.

2. Bing وحده يعطيك رقمًا. هدف Bing البالغ نحو 3 نقرات هو الرقم الصريح الوحيد الذي يذكره أي من المحركين؛ أما Google فتتحدث عمدًا عن القرب في رسم الروابط لا عدد المستويات. تعامل مع أرقام المنافسين، مثل “2–3 levels / 3 clicks” (الترجمة العربية) «مستويين أو ثلاثة / ثلاث نقرات»، كإجماع مهني لا قانون.

3. قِس الهاوية ولا تفترض الرقم. «العميق أكثر من اللازم» ليس ثابتًا عالميًا. ازحف لاستخراج توزيع العمق، وضع فوقه إحصاءات الزحف في GSC، واعثر على العمق الذي يتراجع عنده الزحف فعلًا. ذلك هو العمق الزائد في موقعك.

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

5. الصفحة المركزية أولًا. إضافة صفحة مركزية في مستوى متوسط أو تقويتها هي الإصلاح الأعلى عائدًا؛ فقد تخفض مجموعة من العناصر المدفونة من ست نقرات إلى ثلاث دفعةً واحدة، بلا تغيير URL.

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

مثال تطبيقي: تقريب منتج من 6 نقرات إلى 3

قبل — عمق 6 نقرات

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

بعد — عمق 3 نقرات

ما الذي تغير؟ صفحة مركزية جديدة واحدة، مرتبطة من الصفحة الرئيسية أو التنقل الأساسي، تربط مباشرةً بالمنتج وبالعناصر النظيرة ذات الأولوية. لم يتغير URL المنتج قط؛ فما زال يمكن أن يكون /footwear/running/trail/model-x/. وهذه هي خلاصة الفرق بين عمق URL وعمق النقر: الإصلاح مسار رابط ضحل لا إعادة كتابة URL. ويمكن لمركز واحد معالجة مجموعة كاملة من العناصر المدفونة في آن واحد.

قراءة توزيع العمق

قد تعيد عملية زحف لموقع متوسط الحجم توزيعًا كهذا:

المهم ليس «15% عند العمق 5+» مجردًا، بل أي الصفحات في ذلك النطاق. قارن بإحصاءات الزحف في GSC: إذا كان Refresh قليلًا لهذه الصفحات العميقة وكانت تهمك، فهي قائمة عملك للصفحات المركزية. وإن كانت محتوى طرفيًا منخفض القيمة ويُزحف جيدًا، فاتركها؛ فالعمق عامل خطر لا مشكلة تلقائية.

إجبار كل صفحة على العمق واحد

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

إضافة فئات لا تساعد أحدًا على الاختيار

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

معاملة عمق مجلدات URL كأنه عمق البنية

نقل /shop/shoes/trail/ إلى /trail/ لا يجعل اكتشاف الصفحة أسهل إذا ظلت الروابط نفسها تقود إليها. قِس مسارات الروابط ولا تغيّر عناوين URL إلا لسبب مستقل في هندسة المعلومات أو الترحيل.

اتخاذ القرار من متوسط الموقع كله

قد يخفي متوسط مريح قالب إيرادات مدفونًا وكومة صفحات منخفضة القيمة وضحلة. قسّم العمق حسب القالب والأهمية وقابلية الفهرسة والدور العضوي قبل تحديد ما إذا كانت البنية مسطحة أو عميقة أكثر من اللازم.

إزالة التسلسل الهرمي بدل تقوية المراكز

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

يبدو الزحف مسطحًا لكن العثور على الصفحات المهمة ما زال صعبًا

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

سببت طبقة فئات جديدة خسائر في الزحف أو الزيارات

العَرَض: انتقلت الصفحات التابعة إلى عمق أكبر وهبط الأداء بعد توسيع التصنيف. السبب المرجح: يصعب الوصول إلى الأصل الجديد نفسه، أو أزيلت روابط، أو تمر عناوين URL القديمة بقفزات إعادة توجيه إضافية. الإصلاح: قارن مسارات الروابط قبل التغيير وبعده، وأصلح التنقل وإعادة التوجيه، ولا تُبق الطبقة إلا إذا حسّنت التجميع الحقيقي.

أنشأ التسطيح جدار تنقل غير صالح للاستخدام

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

تختلف البنية بين الزواحف والمستخدمين

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

موجّه: قيّم تسلسلًا هرميًا مقترحًا

Evaluate this proposed site hierarchy without applying a universal click-depth rule.
For each template and priority group, identify the shortest expected path from the
homepage, the parent that gives the path meaning, and any layer that has too few,
too many, or overlapping children. Flag mega-menu flattening, single-child categories,
and priority pages that are less prominent than comparable pages. Recommend changes
using only the supplied inventory and business priorities; do not invent categories.

Inventory:
[PASTE URL | TEMPLATE | PROPOSED PARENT | PRIORITY | PRIMARY USER TASK]

موجّه: فسّر توزيع عمق الزحف

Analyze this crawl export by template and business priority. Compare depth distribution,
orphan status, and shortest-path source. Find cases where the sitewide average hides a
buried important group or where many low-value links make the graph artificially flat.
Return evidence rows, likely architecture cause, and the smallest link or hub change to
test. Treat URL slashes as descriptive data, not click depth.

Crawl export:
[PASTE URL | TEMPLATE | DEPTH | SHORTEST-PATH SOURCE | INDEXABILITY | PRIORITY]

التحقق من تغيير في عمق البنية

اختبر نفسك: البنية المسطحة مقابل العميقة

خمسة أسئلة سريعة عن تحديد عمق الموقع وقياسه وإصلاحه. اختر إجابة لكل سؤال ثم تحقق.

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

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

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

محاضراتي

• كيف يعمل البحث (SlideShare) — عرضي للزحف والعرض والفهرسة والترتيب، وهي المراحل التي يؤثر فيها عمق النقر. وينطبق التنبيه المعتاد: هذا فهمي لهذه الأنظمة لا مواصفة رسمية.

من أنحاء المجال

• التسلسلات الهرمية المسطحة والعميقة للمواقع (Kathryn Whitenton، Nielsen Norman Group) — بحث تجربة المستخدم الدقيق الذي يربط العمق بتمايز الفئات وقابلية العثور.
• لماذا توصي Google ببنية موقع هرمية لتحسين محركات البحث (Search Engine Journal) — Illyes عن حاجة المواقع الكبيرة إلى التسلسل الهرمي ومساعدة التجميع في الأدلة على الزحف.
• تقرير إحصاءات الزحف (مساعدة Google Search Console) — تقسيم Discovery مقابل Refresh وراء تشخيص هاوية العمق.
• كيفية تدقيق عمق الزحف وتحسين كفاءته (Sitebulb) — شرح عملي لتدقيق عمق الزحف.
• Structure Explorer (Ahrefs Academy) — استخدام Site Audit لرؤية توزيع عمق النقر.
• مرئيات بنية الموقع والزحف (Screaming Frog) — عرض عمق الزحف والبنية انطلاقًا من عملية زحف.

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