بنية الموقع

TL;DR — بنية الموقع هي التسلسل الهرمي والتنقل ومسارات التنقل وتنظيم عناوين URL — أي كيفية تجميع صفحاتك وكيف ينتقل الأشخاص ومحركات البحث بينها. تعثر محركات البحث على صفحاتك أساساً باتباع الروابط، لذا فإن الرافعة الكبرى ليست مجلدات عناوين URL — بل روابطك الداخلية. اجمع المحتوى المرتبط، واربط بصفحاتك المهمة، وأبقها على بعد نقرات قليلة من الصفحة الرئيسية.

ما هي بنية الموقع

بنية الموقع (يسميها كثيرون هندسة الموقع) هي الشكل المرئي الكامل لموقعك: التسلسل الهرمي، والتنقل والقوائم، ومسارات التنقل، وطريقة تنظيم عناوين URL. فكر فيها بطريقتين في الوقت نفسه:

• للأشخاص — هل يستطيع الزائر الوصول إلى موقعك والعثور سريعاً على ما جاء من أجله باستخدام القوائم والفئات ومسارات التنقل؟
• لمحركات البحث — هل يستطيع روبوت مثل Googlebot اتباع الروابط من صفحة إلى أخرى واكتشاف كل ما تريد العثور عليه؟

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

الفكرة الواحدة التي يغفل عنها معظم الناس

إليك ما يفاجئ الناس: مجلدات عناوين URL لا تحدد بنية موقعك وحدها — فالروابط الداخلية هي التي تؤدي العمل الأكبر. من المغري التفكير في أن صفحة على example.com/shoes/running/model-x/ «أعمق» من example.com/model-x/، لكن Google لا يعد الشرطات المائلة ليقرر ما هو مهم. فالربط الداخلي هو الإشارة الرئيسية التي يقرأها لفهم كيفية ارتباط صفحاتك بعضها ببعض.

السؤال المهم فعلاً هو: كم نقرة تحتاج للوصول من صفحتك الرئيسية إلى صفحة ما؟ هذه هي عمق النقر، وهي ما ينبغي تحسينه — لا عدد الشرطات المائلة في عنوان URL.

كيف تضبطها (النسخة البسيطة)

• اربط بصفحاتك المهمة من الصفحة الرئيسية والتنقل الرئيسي.
• اجمع المحتوى المرتبط في فئات واضحة.
• لا تدفن الصفحات — يجب الوصول إلى الصفحات المهمة خلال بضع نقرات.
• استخدم روابط حقيقية (<a href="…">)، لا أزراراً أو قوائم لا تعمل إلا بنقرات JavaScript — فقد لا تتبعها الروبوتات.
• لا تترك صفحات يتيمة — قد لا يُعثر أبداً على صفحة لا يربط بها شيء.
• أضف خريطة موقع كنسخة احتياطية حتى تمتلك محركات البحث قائمة بعناوين URL لديك.

الخطأ الذي يرتكبه معظم الناس

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

تنبيه صادق: إن ترتيب بنيتك لا يضمن وحده زحفاً أسرع أو ترتيباً أفضل أو مزيداً من الزيارات. إنه يزيل الاحتكاك ويجعل العثور على صفحاتك المهمة أسهل — أما الباقي فيعتمد على المحتوى الموجود في تلك الصفحات.

هل تريد النسخة الأعمق — اقتباسات Mueller الفعلية، وعمق النقر مقابل عمق عنوان URL، وفخ القائمة العملاقة، ومكان كل موضوع فرعي؟ انتقل إلى تبويب Advanced.

TL;DR — بنية الموقع هي التسلسل الهرمي والتنقل ومسارات التنقل وتنظيم عناوين URL. والربط الداخلي هو الإشارة الرئيسية التي يقرأها Google لفهمها — وليس مجلدات عناوين URL. يوضح Mueller الأمر: “we don’t care so much about the folder structure.” (ترجمة) «لا نهتم كثيرًا ببنية المجلدات». يهم عمق النقر (الروابط من الصفحة الرئيسية)؛ أما عمق عنوان URL (عدد الشرطات المائلة) فلا يهم، ولا تمنحك بنية URL المسطحة اصطناعياً أي فائدة. يتفوق الهرم المعقول على الطرفين — فالمبالغة في التسطيح (مثل القوائم العملاقة) تزيل إشارات التجميع التي يستخدمها Google للسياق. يستنتج Google الأهمية النسبية للصفحة من أنماط الربط الداخلي. لا تملك الصفحات اليتيمة مسار اكتشاف داخلياً وقد لا تُزحف أبداً. ينبغي أن تعكس مسارات التنقل مساراً نموذجياً للمستخدم، لا أن تنسخ عنوان URL آلياً. اختر النطاقات الفرعية أو الأدلة الفرعية بناءً على الاحتياجات التنظيمية، لا على افتراض أن صيغة عنوان URL وحدها تنشئ عقوبة. تساعد خرائط المواقع في الاكتشاف لكنها لا تحل محل الروابط، ولا يضمن أي من ذلك وتيرة زحف أو ترتيباً أو نتيجة زيارات محددة.

الربط الداخلي هو الطريقة التي يقرأ بها Google بنيتك

بنية الموقع أوسع من أي إشارة واحدة: فهي التسلسل الهرمي والتنقل والقوائم ومسارات التنقل وطريقة تنظيم عناوين URL — الشكل المرئي الكامل الذي يواجهه الشخص أو الزاحف. لكن الأمر الذي تقلل معظم الأدلة من شأنه هو كيفية قراءة Google لهذا الشكل فعلياً: فهو يحلله أساساً عبر رسم الروابط الداخلية، لا عبر تحليل مسارات عناوين URL. وقد قال John Mueller ذلك بوضوح شديد: “For us, we don’t care so much about the folder structure, we really essentially focus on the internal linking.” (ترجمة) «لا نهتم كثيرًا ببنية المجلدات؛ بل نركز أساسًا على الربط الداخلي». وبشأن الشرطات المائلة تحديداً: “Just looking at the number of slashes, for example, in a URL doesn’t tell us that this is lower level or higher level.” (ترجمة) «مجرد النظر إلى عدد الشرطات المائلة في عنوان URL لا يخبرنا إن كانت الصفحة في مستوى أدنى أو أعلى».

غالباً ما تعكس عناوين URL البنية — فمسار مرتب مثل /category/subcategory/page/ يعكس عادةً بنية الروابط — لكن هذا ارتباط لا سببية. وكما قال Mueller: “a lot of times the architecture of the website is visible in the URL structure, but it doesn’t have to be the case.” (ترجمة) «تظهر هندسة الموقع كثيرًا في بنية عنوان URL، لكن ذلك ليس شرطًا». وتقول وثائق Google للتجارة الإلكترونية الشيء نفسه من جانب المحرك: “Google tries to find the best content on your site by analyzing the relationship between pages based on their linkages.” (ترجمة) «تحاول Google العثور على أفضل محتوى في موقعك بتحليل العلاقة بين الصفحات استنادًا إلى الروابط التي تصل بينها».

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

عمق النقر، لا عمق عنوان URL

بما أن Google يقرأ الروابط، فالمقياس المهم هو عمق النقر — عدد الروابط التي يتبعها الزاحف للوصول إلى صفحة من الصفحة الرئيسية — وليس عدد المقاطع في عنوان URL. ويقول Mueller مرة أخرى: “It’s really like from the homepage or from the primary page, how quickly can we reach that specific page?” (ترجمة) «السؤال الفعلي هو مدى سرعة وصولنا إلى تلك الصفحة المحددة من الصفحة الرئيسية أو الصفحة الأساسية».

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

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

الهرم يتفوق على الطرفين

السطحية ليست الهدف، والعمق ليس الهدف أيضاً. أوضح Mueller أن البنية الهرمية هي ما يساعد: “a pyramid structure helps us a lot more to understand the context of individual pages,” (ترجمة) «تساعدنا البنية الهرمية أكثر بكثير على فهم سياق الصفحات الفردية»، و*“it’s not the case that a super flat structure is going to be better than a reasonable pyramid.”* (ترجمة) «ليست البنية شديدة التسطيح أفضل من هرم معقول». كما أشار إلى فشل العمق الزائد: “you don’t want it to be such that it’s like you have to click through a million times.” (ترجمة) «لا تريد أن يتطلب الوصول النقر مرات لا تُحصى».

فخ التسطيح الزائد حقيقي ولا يناقش بما يكفي. قد تعمل القوائم العملاقة التي تعرض مئات الروابط على بعد نقرة واحدة من الصفحة الرئيسية على تسطيح بنيتك إلى حد يجعل Google، بحسب كلمات Mueller، “Google can’t recognize which parts of the site belong together” (ترجمة) «لا تستطيع Google تمييز أجزاء الموقع التي تنتمي بعضها إلى بعض» — لذلك توجد قيمة في تقليل ارتفاع الزحف من دون تحويل الموقع إلى سطح واحد. ويحافظ الهرم المعقول (الرئيسية → الفئة → الفئة الفرعية → الصفحة) على إشارات التجميع.

تتدفق الأهمية عبر الروابط

يستنتج Google الأهمية النسبية للصفحة من روابطك الداخلية. وتقول إرشادات التجارة الإلكترونية لديه مباشرة: “the more links a page has to it within a site, the higher the relative importance of the page,” (ترجمة) «كلما زاد عدد الروابط الداخلية المؤدية إلى صفحة، ارتفعت أهميتها النسبية»، ويستخدم Google “the number of links it needs to follow to reach a page and the number of links to a page to infer the relative importance of a page.” (ترجمة) «عدد الروابط التي يلزم اتباعها للوصول إلى الصفحة وعدد الروابط المؤدية إليها لاستنتاج أهميتها النسبية». وينتج عن ذلك عاملان عمليان: اربط بصفحات الأولوية بكثرة، واربط بها من مكان أقرب إلى الصفحة الرئيسية.

هناك تفصيلان في التنفيذ يذكرهما Google: استخدم روابط حقيقية من نوع <a href> — “don’t use JavaScript events on other HTML DOM elements for navigation” (ترجمة) «لا تستخدم أحداث JavaScript على عناصر HTML DOM أخرى للتنقل» — ولا تعتمد على بحث الموقع الداخلي للاكتشاف، لأن “Googlebot generally doesn’t try to submit searches into a search box as part of crawling a site.” (ترجمة) «لا يحاول Googlebot عادةً إرسال عمليات بحث عبر مربع البحث أثناء زحف الموقع».

أين تظل الأدلة مفيدة

مجلدات عناوين URL ليست زينة خالصة. ففي المواقع الكبيرة، يتعلم Google سلوك الزحف على مستوى الدليل — فقد يزحف إلى /news/ أكثر من /archive/ لأنه يتعلم معدل تغير عناوين URL في كل دليل. وقد ذكر Gary Illyes أن Google “prefers a hierarchical structure for large sites,” (ترجمة) «يفضل بنية هرمية للمواقع الكبيرة»، وأن أهمية البنية النظيفة تكمن في أن Google يزحف إلى صفحات أقل، ولذلك تحتاج إلى إظهار الأولويات. لذا نظّم حسب الموضوع وكذلك حسب وتيرة التحديث حيثما أمكن — لكن تذكر أن إشارة أهمية الزحف ما زالت تأتي من رسم الروابط، لا من المسار.

تساعد خرائط المواقع — لكنها لا تحل محل الروابط

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

مسارات التنقل: مسار المستخدم لا نسخة من عنوان URL

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

ما الذي لا تضمنه البنية

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

يوصي Bing بإمكانية وصول قريبة

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

إلى أين تذهب بعد ذلك

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

• بنية عناوين URL — عناوين URL مقروءة ووصفية، وواصلات لا شرطات سفلية، وحساسية حالة الأحرف، ولماذا تصف عناوين URL التسلسل الهرمي بدلاً من إنشائه.
• الروابط الداخلية — الإشارة البنيوية الرئيسية التي يقرأها Google، وكيف ينقل نص الرابط موضوع الصفحة، وكيف توجه الأهمية إلى صفحات الأولوية. (مدرج أيضاً ضمن SEO على الصفحة.)
• الصفحات اليتيمة — صفحات لا يشير إليها أي رابط داخلي: لماذا لا تُكتشف، ولا تكسب قيمة الروابط، وتهدر ميزانية الزحف بهدوء — وكيف تجدها وتصلحها. (متفرعة ضمن الروابط الداخلية.)
• مسارات التنقل — تعزيز التسلسل الهرمي للمستخدمين ومحركات البحث، وترميز البيانات المنظمة، وسبب توصية Google بمسار نموذجي للمستخدم بدلاً من نسخ عنوان URL آلياً.
• التقسيم إلى صفحات — كيف تندرج مجموعات الصفحات المقسمة (قوائم الفئات والأرشيفات) في البنية وكيف يتعامل Google معها اليوم.
• هندسة الموقع (النماذج) — أساس الهرم، إلى جانب نماذج العزل والمركز والأذرع ومجموعات الموضوعات، ومتى يكون كل منها مناسباً.
• النطاق الفرعي مقابل الدليل الفرعي — يتعامل Google معهما بالطريقة الخوارزمية نفسها؛ ونصيحة Mueller العملية هي إبقاء المحتوى المرتبط معاً ما لم يكن “really kind of slightly different.” (ترجمة) «مختلفًا إلى حد ما فعلًا».
• عمق الزحف — عمق النقر مقابل عمق اجتياز الزحف، ولماذا ينبغي أن تكون الصفحات المهمة قريبة من الصفحة الرئيسية. (مدرج أيضاً ضمن How Search Works.)

للسياق الأوسع، راجع SEO التقني وHow Search Works.

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

خلاصة مكثفة لنسخة Advanced:

• بنية الموقع = هندسة المعلومات المرئية. التسلسل الهرمي والتنقل ومسارات التنقل وتنظيم عناوين URL. والربط الداخلي هو الإشارة الرئيسية التي يقرأها Google لفهمها، لا مجلدات عناوين URL. يقول Mueller: “we don’t care so much about the folder structure… we really essentially focus on the internal linking.” (ترجمة) «لا نهتم كثيرًا ببنية المجلدات؛ بل نركز أساسًا على الربط الداخلي».
• عمق النقر، لا عمق عنوان URL. المهم هو عدد الروابط من الصفحة الرئيسية للوصول إلى صفحة. لا تمنح بنية عناوين URL المسطحة اصطناعياً أي فائدة SEO — اربط من مكان أقرب إلى الصفحة الرئيسية بدلاً من إعادة كتابة عناوين URL. وما زالت لعناوين URL وظيفة حقيقية موثقة: أن تكون مقروءة ووصفية للناس، وأن تظهر كمسارات تنقل في نتائج البحث — لكنها مقياس مختلف عن عمق النقر.
• الهرم المعقول يتفوق على الطرفين. السطحية ليست أفضل تلقائياً؛ يقرأ Google التسطيح المفرط على أنه «كل شيء متساوي الأهمية»، فيزيل السياق. والعمق الزائد سيئ أيضاً. وقد تبالغ القوائم العملاقة في التسطيح وتخفي الصفحات التي تنتمي معاً.
• تتدفق الأهمية عبر الروابط. كلما زادت الروابط الداخلية إلى صفحة (وكلما اقتربت من الصفحة الرئيسية)، زادت أهميتها المستنتجة. استخدم روابط <a href> حقيقية؛ ولا تعتمد على بحث الموقع أو التنقل عبر أحداث JavaScript لاكتشاف الصفحات.
• ما زالت الأدلة مهمة على نطاق واسع من حيث وتيرة الزحف على مستوى الدليل، لكن إشارة الأهمية هي رسم الروابط، لا المسار.
• تمثل مسارات التنقل مساراً نموذجياً للمستخدم، لا نسخة آلية من عنوان URL — وهذه صياغة Google نفسها، وهي مفيدة عندما يكون للصفحة أكثر من مسار مشروع للوصول إليها.
• تساعد خرائط المواقع لكنها لا تحل محل الروابط — يضعها Illyes في المرتبة الثانية بعد الروابط الداخلية. خريطة الموقع نسخة احتياطية للاكتشاف، وليست بديلاً عن التنقل أو الروابط الداخلية.
• لا توجد ضمانات. لا يضمن تنظيم البنية من جديد وحده وتيرة الزحف أو سرعة الفهرسة أو الترتيب أو الزيارات أو اقتباسات الذكاء الاصطناعي — وحتى sitelinks تلقائية وليست مضمونة.
• النطاق الفرعي مقابل الدليل الفرعي: يُعاملان بالطريقة الخوارزمية نفسها؛ اتخذ القرار تنظيمياً. يوصي Bing بإمكانية وصول قريبة عموماً؛ ولم أتمكن من استعادة مصدر أولي حالي برقم محدد لعدد النقرات.
• الموضوعات الفرعية: بنية عناوين URL، والروابط الداخلية، والصفحات اليتيمة، ومسارات التنقل، والتقسيم إلى صفحات، ونماذج هندسة الموقع، والنطاق الفرعي مقابل الدليل الفرعي، وعمق الزحف.

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

إرشادات من المصادر الأساسية لمحركات البحث.

Google

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

Bing / Microsoft

• إرشادات Bing لمشرفي المواقع — تسلسل هرمي منظم جيداً، وصفحات مهمة سهلة الوصول، وعناوين URL نظيفة، واكتشاف يبدأ من خريطة الموقع. (هذه الصفحة غلاف تطبيق JavaScript؛ ولم أتمكن من استعادة نص مصدر أولي قابل للجلب عن رقم محدد لعدد النقرات حتى هذا التحديث.)

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

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

John Mueller — الربط الداخلي مقابل بنية عناوين URL

• “For us, we don’t care so much about the folder structure, we really essentially focus on the internal linking.” (ترجمة) «لا نهتم كثيرًا ببنية المجلدات؛ بل نركز أساسًا على الربط الداخلي». قراءة التغطية
• “Just looking at the number of slashes, for example, in a URL doesn’t tell us that this is lower level or higher level.” (ترجمة) «مجرد النظر إلى عدد الشرطات المائلة في عنوان URL لا يخبرنا إن كانت الصفحة في مستوى أدنى أو أعلى». قراءة التغطية
• “It’s really like from the homepage or from the primary page how quickly can we reach that specific page?” (ترجمة) «السؤال الفعلي هو مدى سرعة وصولنا إلى تلك الصفحة المحددة من الصفحة الرئيسية أو الصفحة الأساسية». قراءة التغطية

John Mueller — الهرم مقابل التسطيح

• “A pyramid structure helps us a lot more to understand the context of individual pages.” (ترجمة) «تساعدنا البنية الهرمية أكثر بكثير على فهم سياق الصفحات الفردية». قراءة التغطية
• “It’s not the case that a super flat structure is going to be better than a kind of reasonable pyramid.” (ترجمة) «ليست البنية شديدة التسطيح أفضل من هرم معقول». قراءة التغطية

John Mueller — عناوين URL المسطحة اصطناعياً

• يقول Google إن “no SEO benefit for having an artificially flat URL structure” (ترجمة) «لا فائدة في SEO من بنية عناوين URL مسطحة اصطناعيًا» مقارنة بموقع لديه عمق أدلة. قراءة التغطية

John Mueller — النطاقات الفرعية مقابل الأدلة الفرعية

• “In general, we see these the same… I would personally try to keep things together as much as possible… Use subdomains where things are really kind of slightly different.” (ترجمة) «نراهما عمومًا بالطريقة نفسها؛ وأحاول شخصيًا إبقاء الأشياء معًا قدر الإمكان، وأستخدم النطاقات الفرعية عندما يكون المحتوى مختلفًا إلى حد ما فعلًا». قراءة التغطية

Gary Illyes — التسلسل الهرمي والاكتشاف

• يذكر Google أنه “prefers a hierarchical structure for large sites,” (ترجمة) «يفضل بنية هرمية للمواقع الكبيرة»، وأن البنية النظيفة مهمة لأن Google يزحف إلى صفحات أقل — مع كون خرائط XML للمواقع ثاني أهم طريقة للاكتشاف بعد الروابط الداخلية. قراءة التغطية

قائمة فحص بنية الموقع

مرور للتأكد من أن بنيتك تعمل للزوار والزواحف معاً:

• ترتبط الصفحات المهمة من الصفحة الرئيسية و/أو التنقل الرئيسي.
• جُمع المحتوى في فئات واضحة (هرم معقول، لا سطح مستوٍ ولا متاهة).
• تقع صفحات الأولوية على عدد صغير ومدروس من النقرات من الصفحة الرئيسية — عمق النقر منخفض (لا يوجد رقم ثابت على مستوى الموقع؛ راجع صفحة عمق الزحف لقياس توزيعك الخاص).
• لا توجد صفحات يتيمة — لكل صفحة تريد العثور عليها رابط داخلي واحد على الأقل يشير إليها.
• يستخدم التنقل روابط حقيقية من نوع <a href>، لا نقرات أحداث JS أو أزراراً.
• لا تعتمد على بحث الموقع الداخلي لاكتشاف الصفحات المهمة.
• يصف نص رابط الربط الداخلي موضوع الوجهة.
• لا تبالغ القوائم العملاقة في تسطيح البنية (تبقى إشارات التجميع سليمة).
• توجد مسارات تنقل، وموسومة ببيانات منظمة، وتمثل مساراً نموذجياً للمستخدم بدلاً من نسخ عنوان URL آلياً.
• اختير النطاق الفرعي مقابل الدليل الفرعي على أساس تنظيم المحتوى، لا عقوبة ترتيب متخيلة (أبقِ المحتوى المرتبط معاً افتراضياً).
• أُرسلت خريطة XML للموقع في Google Search Console وBing Webmaster Tools — كنسخة احتياطية للروابط، لا بديلاً عنها.

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

1. البنية مرئية؛ والروابط الداخلية هي طريقة قراءة Google لها. بنيتك هي التسلسل الهرمي والتنقل ومسارات التنقل وعناوين URL التي يراها الناس فعلياً. قبل أن تلمس المجلدات، انظر إلى ما يربط بماذا — يقرأ Google العلاقات بين الصفحات “based on their linkages” (ترجمة) «استنادًا إلى الروابط التي تصل بينها». يمكن لمسار عنوان URL أن يصف التسلسل الهرمي، لكنه لا ينشئه.

2. حسّن عمق النقر لا عمق عنوان URL. السؤال هو: كم رابطًا نحتاج إلى اتباعه من الصفحة الرئيسية للوصول إلى هذه الصفحة؟ وليس: كم شرطة مائلة في العنوان؟ هل تريد أن تُحتسب صفحة أكثر؟ اربط بها من مكان أقرب. لا يفعل جعل عنوان URL أكثر تسطحاً شيئاً.

3. الهرم بين نمطي الفشل. استهدف المسار الرئيسية → الفئة → الفئة الفرعية → الصفحة. فالتسطيح الزائد (القوائم العملاقة، وكل شيء على بعد نقرة واحدة) يزيل إشارات التجميع والسياق؛ والعمق الزائد (النقر مليون مرة) يدفن الصفحات. الهرم هو المسار الأوسط الذي يكافئه Google فعلياً.

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

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

6. قرار متشابه أم مختلف (النطاق الفرعي مقابل الدليل الفرعي). يتعامل Google معهما بالطريقة نفسها، لذا اتخذ القرار تنظيمياً: أبقِ المحتوى المرتبط معاً في دليل فرعي افتراضياً؛ ولا تلجأ إلى نطاق فرعي إلا عندما يكون المحتوى مختلفًا إلى حد ما فعلًا.

7. تجيب مسارات التنقل عن “كيف وصل زائر معتاد إلى هنا؟” لا عن “ماذا يقول عنوان URL؟”. عندما يكون للصفحة أكثر من مسار مشروع، اختر المسار الذي يمثل الزيارة العادية بأفضل شكل ووسمه باستمرار — لا تجبر المسار على مطابقة مجلدات عناوين URL التي لا تعكس التنقل الحقيقي.

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

أدوات لرؤية البنية التي تتلقاها محركات البحث

• Google Index Checker — راجع الحالة القابلة للملاحظة وحواجز robots وcanonical على الصفحات المهمة، ثم أحل الأمر إلى فحص عناوين URL في Search Console لرؤية الحالة التي سجلها Google.
• XML Sitemap Validator — اكتشف ملفات خريطة الموقع المشوهة وعناوين URL التي تتعارض مع البنية القابلة للزحف التي قصدت نشرها.
• Ahrefs Site Audit أو زاحف روابط آخر — افحص عمق الزحف والروابط الواردة والصادرة والمرشحين للصفحات اليتيمة وإعادات التوجيه والرسم الفعلي الذي تنتجه القوالب.
• تصور للزحف — استخدم شجرة أدلة لتنظيم عناوين URL تشغيلياً، ورسم روابط موجه بالقوة للهندسة؛ لا تخلط بين الصورتين.
• Analytics وSearch Console — صِل الطلب والأداء بالزحف حتى تحظى الصفحات عالية القيمة المدفونة في الرسم بالأولوية.

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

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

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

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

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

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

كلماتي

• Patrick Stox على SlideShare — محاضرات تشمل دورة مكثفة في SEO التقني وترحيل المواقع (SMX Munich) وSEO الدولي: الجوانب التقنية غير المألوفة (Pubcon)، وكلها تتناول تدقيقات هندسة الموقع وإعادة التصميم. (ينطبق إخلاء المسؤولية الدائم: هذا فهمي لهذه الأنظمة، وليس مواصفة رسمية.)

من مختلف أرجاء المجال

• كيفية بناء هندسة موقعك لـ SEO (Ahrefs، Chris Haines) — الأنواع والأدوات والعناصر التقنية للبنية.
• بنية الموقع: الدليل الشامل (Yoast) — شرح شامل يركز على WordPress.
• هندسة الموقع (Backlinko) — مرجع على نمط المركز لمفاهيم الهندسة.
• كيفية بناء هندسة موقع أفضل وأذكى وأسهل اكتشافاً (Search Engine Land، Anna Crowe) — شرح تفصيلي مع دراسة حالة وسياق Illyes عن التسلسل الهرمي والزحف.
• هندسة الموقع: إنشاء بنية موقع تحسن الترتيب (Search Engine Land) — دليل مرجعي في المجال.
• بنية الموقع الهرمية (Search Engine Journal) — إرشادات Mueller عن الهرم مقابل التسطيح والقوائم العملاقة.
• Google يعامل النطاقات الفرعية والأدلة الفرعية بالطريقة نفسها، يقول John Mueller (Search Engine Journal) — سؤال النطاق الفرعي مقابل الدليل الفرعي.
• هندسة الموقع لـ SEO: الدليل الحاسم (Impression Digital) — دليل تنفيذ شامل.

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