هندسة الموقع

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

ما هندسة الموقع؟

هندسة الموقع هي شبكة الروابط القابلة للزحف التي تصل صفحاتك — أي المسارات التي تستخدمها محركات البحث (والقراء) لاكتشاف الصفحات والتنقل بينها — إلى جانب نقاط دخول مساندة مثل خريطة موقع XML. وهي ليست الشيء نفسه الذي تمثله مجلدات عناوين URL: فمسار الصفحة (/blog/category/post/) لا يحدد وحده موضعها في الهندسة. والفرق يشبه الفرق بين مكتبة مرتبة لكل كتاب فيها رف ولافتة تدل عليه، وكومة كتب على الأرض.

لهندسة الموقع أهمية في البحث لسببين:

1. الاكتشاف. تعثر محركات البحث على الصفحات أساساً باتباع روابط <a href> القياسية من صفحات تعرفها بالفعل. إذا لم يرتبط شيء بصفحة، يصعب على Google العثور عليها أصلاً.
2. السياق. عندما ترتبط صفحة بأخرى وتحيط بالرابط كلمات ذات صلة، يساعد ذلك Google على فهم موضوع الصفحة المرتبط بها.

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

النماذج الثلاثة التي ستسمع عنها

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

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

ما يهم فعلاً

لا تحتاج إلى اختيار اسم تجاري. تحتاج إلى:

• تسلسل هرمي واضح: الصفحة الرئيسية ← صفحات الفئات/المحاور ← الصفحات المحددة.
• ربط كل صفحة مهمة من صفحة أخرى واحدة على الأقل (من دون «صفحات يتيمة») — وتقول وثائق Google بوضوح إن كل صفحة تهمك يجب أن يكون لها رابط من صفحة أخرى واحدة على الأقل في موقعك.
• روابط <a href> حقيقية، لا تنقلاً يعتمد على النقر فقط ولا تستطيع Google اتباعه على نحو موثوق.
• ربط الصفحات ذات الصلة بعضها ببعض بنص رابط وصفي.
• عدم دفن أي شيء مهم على عمق يجعل وصول برامج الزحف إليه صعباً.

لا يضمن أي من ذلك الزحف أو الفهرسة أو الترتيب؛ بل يجعل الصفحة قابلة للوصول والفهم من الأساس.

ما يخطئ فيه معظم الناس

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

هل تريد النسخة الأعمق — كيف تتدفق قيمة الروابط، والتسلسلات الهرمية المسطحة مقابل العميقة، ومتى يناسب كل نموذج؟ انتقل إلى تبويب Advanced.

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

لماذا يتجادل مختصو SEO في هذا أصلاً؟

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

هناك ثلاثة نماذج ذات أسماء شائعة:

• بنية الصوامع — محتوى مجمّع في أقسام موضوعية معزولة. يحظر التفسير الصارم (الذي روّج له Bruce Clay) الروابط الداخلية بين الصوامع لإبقاء «قيمة الروابط» في كل صومعة مركزة.
• المحور والأذرع — ترتبط صفحة محور عامة واسعة بصفحات أذرع تفصيلية، وترتبط الأذرع بها. ويُسمى المحور أحياناً صفحة ركيزة.
• مجموعات الموضوعات — صياغة HubSpot لعام 2017: تستهدف صفحة ركيزة كلمة مفتاحية واسعة، وتستهدف صفحات المجموعة موضوعات فرعية طويلة الذيل، ويرتبط كل شيء ببعضه.

التوضيح الذي أتمسك به

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

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

ما الذي توصي به Google فعلاً؟

توصي Google بتسلسل هرمي/من أعلى إلى أسفل: تغطي الصفحة الرئيسية الموضوع الأوسع، وتقع صفحات الفئات/المحاور في الوسط، وتوجد صفحات المحتوى المحددة في القاع. شرح John Mueller السبب بوضوح: إن النهج من أعلى إلى أسفل أو البنية الهرمية “helps us a lot more to understand the context of individual pages within the site.” (ترجمة) «يساعدنا كثيراً على فهم سياق الصفحات الفردية داخل الموقع». هذه هي الفائدة — فالبنية ليست حيلة للترتيب، بل الطريقة التي تفهم بها Google موضوع كل صفحة وعلاقة الصفحات بعضها ببعض.

ومن الجدير بالذكر أن Google تستخدم مصطلح “hub page” في وثائقها — إذ تصف كيف “a hub page, such as a category page, links to a new blog post” (ترجمة) «ترتبط صفحة محور، مثل صفحة فئة، بتدوينة جديدة» لأغراض الاكتشاف. لذلك فصياغة المحور والأذرع ليست اختراعاً في SEO؛ بل هي لغة Google نفسها.

الروابط الداخلية تتفوق على بنية عناوين URL

هذا أكثر أجزاء الهندسة تعرضاً لسوء الفهم. تتعلق كثير من نصائح الصوامع في الحقيقة بمجلدات عناوين URL — وضع صفحات /category-a/ تحت مسار واحد ومنع الروابط إلى /category-b/. لكن Google تركز على إشارات الربط الداخلي، لا مقاطع مسار عنوان URL. أشار Mueller مراراً إلى أن بعض مختصي SEO يبالغون في التركيز على بنية عناوين URL؛ وتستنتج Google التسلسل الهرمي من طريقة ترابط الصفحات، لا من أسماء المجلدات.

والنتيجة كبيرة: لا يشير وجود صفحة في /blog/technical-seo/site-architecture/ إلى شيء لدى Google يتجاوز ما يقوله محتواها وروابطها الواردة. عناوين URL المنطقية مفيدة للبشر ولإدارة الموقع — لكنها ليست الهندسة. رسم الروابط هو الهندسة. ولهذا تعمل «الصوامع الافتراضية» (تركيز الروابط بحسب الموضوع بغض النظر عن المجلدات) جيداً، بينما تجلب «الصوامع المادية» الصارمة (العزل القائم على المجلدات من دون روابط متقاطعة) مشكلات في الزحف وتجربة المستخدم بلا فائدة تعوضها.

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

أين تخطئ الصوامع الصارمة؟

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

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

ظلت Shari Thurow تقول ذلك لسنوات («أوقفوا جنون الصوامع»)، وتصل وجهة نظر Ahrefs المخالفة (مقال Joshua Hardwick «لماذا لا معنى له») إلى النتيجة نفسها. احتفظ بالتركيز وأسقط الجدار — واتخذ القرار وفق ما إذا كان الرابط يخدم القارئ والصفحة المقصودة فعلاً، لا وفق مزاعم غير موثقة عن الوزن الذي تمنحه Google للعزل الصارم.

التسلسلات الهرمية المسطحة مقابل العميقة

هناك نمطان للفشل عند الطرفين:

• مسطح أكثر من اللازم — كل شيء على بعد نقرة واحدة من الصفحة الرئيسية. تتبدد قيمة الروابط والإشارة الموضوعية؛ فلا تستطيع الصفحة الرئيسية أن تزكي مئات الأبناء المتساوين على نحو ذي معنى، وتفقد التجميع الموضوعي الذي يساعد على بناء السياق.
• عميق أكثر من اللازم — صفحات مهمة تفصلها نقرات كثيرة عن الصفحة الرئيسية. وبصياغة Mueller: إذا جعلتها عميقة جداً، فهذا “makes it harder for us to crawl and harder for us to pass the signals around.” (ترجمة) «يجعل الزحف أصعب علينا ويصعّب تمرير الإشارات». تميل الصفحات العميقة إلى أن يزحف إليها المحرك بوتيرة أقل وأن ترث قدراً أقل من السلطة الداخلية. لم تنشر Google رقماً محدداً لعمق النقر؛ فلا تعامل أي عدد ثابت بوصفه متطلباً — فالعمق الصحيح يعتمد على حجم موقعك ومدى تمايز فئاته، وهو موضوع مستقل (راجع التعمق في البنية المسطحة مقابل العميقة وعمق الزحف ضمن هذه المجموعة للحصول على إطار القرار الكامل).

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

ما الذي يفعله الربط الداخلي فعلاً؟

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

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

هذا الموقع مثال حي. يستخدم patrickstox.com تسلسلاً هرمياً من ركيزة ← مجموعة ← مقال ← مقال فرعي عبر بضع مئات من الصفحات، مستعملاً تصنيف pillar وcluster وclusterSelf وsubcluster وsubsubcluster — كما يدرج المقالات عمداً في أكثر من مجموعة (نمط alsoIn) بدلاً من عزلها بالجدران. هذا محور وأذرع مع ربط متقاطع مقصود: النموذج الذي أصفه تماماً، لا صومعة صارمة.

متى تستخدم أي نموذج؟

بصراحة؟ ابنِ بنية المحور والأذرع/مجموعة الموضوعات وتوقف عن القلق بشأن التسميات:

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

لا يوجد عدد سحري لصفحات المجموعة في كل محور. العدد الصحيح هو عدد الموضوعات الفرعية المميزة ذات الطلب الحقيقي — لا هدف اعتباطي مثل 5 أو 10 أو 30. ويكيبيديا المثال الكلاسيكي: صفحات نظرة عامة واسعة ترتبط بعمق بصفحات موضوعات فرعية مفصلة، وكلها مترابطة بكثافة، ولا توجد جدران صوامع في أي مكان.

هندسة الموقع وبحث الذكاء الاصطناعي

تستخدم AI Overviews ومساعدات الذكاء الاصطناعي توسيع الاستعلام — أي تفكيك السؤال إلى عدة استعلامات فرعية مترابطة. والفرضية المعقولة، لا الضمان الموثق، هي أن الموقع ذا التغطية المنظمة والمترابطة عبر موضوعاته الفرعية تكون لديه فرصة أفضل للظهور عبر عدد أكبر من هذه الاستعلامات، لأن مزيداً من الموضوعات الفرعية تغطيها صفحة قابلة للاكتشاف والزحف. لم أر دليلاً مضبوطاً يعزل الهندسة بوصفها السبب هنا، لذا عاملها كشيء تختبره على محتواك لا كآلية راسخة. والموقف العلني لـGary Illyes هو أن تحسين بحث الذكاء الاصطناعي يحتاج إلى SEO العادي — محتوى عالي الجودة ومنظم وقابل للزحف — لا إلى هندسة خاصة. البنية التي تخدم البحث التقليدي هي نفسها التي ستبنيها لبحث الذكاء الاصطناعي؛ ولا يوجد دليل تشغيل منفصل.

تدقيق هندسة موقعك

جولة عملية تعتمد في معظمها على بيانات الزحف:

• اعثر على الصفحات اليتيمة — الصفحات التي لا تملك روابط داخلية واردة. ازحف إلى الموقع (باستخدام Ahrefs Site Audit أو Screaming Frog) وابحث عن الصفحات التي لا تتلقى أي روابط واردة.
• اعثر على الصفحات شديدة العمق — عناوين URL المهمة المدفونة على بعد نقرات كثيرة من الصفحة الرئيسية؛ لا توجد قاعدة برقم ثابت، لكن إذا أظهرت بيانات الزحف أن الزحف إليها يقل كلما تعمقت، فتحقق.
• ارسم الموضوعات واعثر على محاور محتملة — مجموعات صفحات مترابطة تفتقد صفحة نظرة عامة مركزية.
• نفّذ تحليل فجوات الروابط الداخلية — صفحات مترابطة ينبغي أن ترتبط بعضها ببعض لكنها لا تفعل.

التحفظ الصريح

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

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

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

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

• هندسة الموقع = رسم الروابط القابل للزحف، لا مجلدات عناوين URL. فهي تشكل الاكتشاف ومدى وضوح فهم Google لسياق كل صفحة — ولا تضمن وحدها الزحف أو الفهرسة أو الترتيب أو اقتباسات الذكاء الاصطناعي.
• ثلاث تسميات للممارسين وبنية متداخلة واحدة. ليست الصوامع والمحور والأذرع ومجموعات الموضوعات فئات موثقة لدى Google؛ بل تلتقي في تسلسل هرمي/من أعلى إلى أسفل وصفه Mueller بإيجابية: البنية الهرمية “helps us a lot more to understand the context of individual pages.” (ترجمة) «تساعدنا كثيراً على فهم سياق الصفحات الفردية».
• يتداخل المحور والأذرع ومجموعات الموضوعات في الغالب. النمط الأساسي نفسه من مجتمعين مختلفين — مصطلح هندسة المعلومات مقابل إعادة تقديم HubSpot في 2017 لتسويق المحتوى. و«صفحة الركيزة» مجرد الاسم التسويقي للمحور.
• أسقط الصوامع الصارمة. الجزء القيّم هو التركيز الموضوعي للروابط؛ ولا يطلب أي مصدر من Google قاعدة «لا تربط أبداً بين الصوامع»، وهي تضر تجربة المستخدم.
• الروابط الداخلية أهم من بنية عناوين URL. تستنتج Google التسلسل الهرمي من الروابط، لا من مقاطع المسار؛ وقال Mueller إن مختصي SEO يبالغون في التركيز على بنية عناوين URL.
• أبقِ البنية ضحلة، لكن لا تطارد رقماً ثابتاً. لم تنشر Google حداً لعمق النقر؛ فالعمق الزائد يضر الزحف وتدفق الإشارات، والتسطيح الزائد يبدد الإشارة الموضوعية.
• لا يوجد عدد سحري للمجموعات. غطّ الموضوعات الفرعية ذات الطلب الحقيقي؛ ويكيبيديا هي النموذج.
• يحتاج بحث الذكاء الاصطناعي إلى SEO عادي (Illyes) — والتغطية المنظمة المترابطة فرضية معقولة للمساعدة في توسيع الاستعلام، لا ضماناً موثقاً.
• الهندسة بنية تحتية وليست اختصاراً للترتيب — ولا تستطيع إنقاذ المحتوى السطحي.

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

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

Google

• دليل متعمق لكيفية عمل بحث Google — اكتشاف عناوين URL عبر الروابط، واستخدام Google نفسه لعبارة «صفحة محور»/صفحة فئة.
• الروابط القابلة للزحف — اجعل روابطك قابلة للزحف — يجب ربط كل صفحة مهمة من صفحة أخرى واحدة على الأقل؛ ويجب أن تكون الروابط <a href>؛ ويساعد نص الرابط والسياق المحيط في فهم الصفحات المرتبط بها.
• أهمية هندسة الروابط (2008) — إرشادات Google طويلة الأمد التي تفيد بأن بنية الروابط الداخلية تشكل تدفق PageRank والأهمية المتصورة للصفحة.

Bing / Microsoft

• إرشادات Bing لمشرفي المواقع — بنية واضحة ومسطحة وقابلة للزحف؛ وروابط داخلية معقولة؛ وتسلسل للعناوين (H1/H2/H3)؛ وإرسال خرائط الموقع.

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

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

John Mueller من Google — عن التسلسل الهرمي/البنية الهرمية

• “The top-down approach or pyramid structure helps us a lot more to understand the context of individual pages within the site.” (ترجمة) «يساعدنا النهج من أعلى إلى أسفل أو البنية الهرمية كثيراً على فهم سياق الصفحات الفردية داخل الموقع». — John Mueller، عن بنية الموقع. تغطية Search Engine Journal · تغطية Search Engine Roundtable

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

• حذّر Mueller من أن بعض مختصي SEO يبالغون في التركيز على بنية عناوين URL/المجلدات؛ وتعتمد Google على الربط الداخلي لفهم التسلسل الهرمي، لا مقاطع مسار عنوان URL. تغطية Search Engine Roundtable

John Mueller من Google — عن عمق الزحف

• “I don’t think it would always have a negative effect. I do think if you make it too deep, then that makes it harder for us to crawl and harder for us to pass the signals around.” (ترجمة) «لا أعتقد أن له دائماً أثراً سلبياً. لكنني أعتقد أنك إذا جعلته عميقاً جداً، فسيصعب علينا الزحف ويصعب علينا تمرير الإشارات». — John Mueller، عن التسلسلات الهرمية العميقة للصفحات.

وثائق Google Search Central — عن الاكتشاف عبر صفحات المحاور

• “Other pages are discovered when Google extracts a link from a known page to a new page: for example, a hub page, such as a category page, links to a new blog post.” (ترجمة) «تُكتشف صفحات أخرى عندما تستخرج Google رابطاً من صفحة معروفة إلى صفحة جديدة: مثلاً، ترتبط صفحة محور، مثل صفحة فئة، بتدوينة جديدة». الانتقال إلى الاقتباس

وثائق Google Search Central — عن قابلية الربط

• “Every page you care about should have a link from at least one other page on your site.” (ترجمة) «يجب أن يكون لكل صفحة تهمك رابط من صفحة أخرى واحدة على الأقل في موقعك». الانتقال إلى الاقتباس

Gary Illyes من Google — عن قابلية الزحف وبحث الذكاء الاصطناعي

• “MAKE THAT DAMN SITE CRAWLABLE.” (ترجمة) «اجعل ذلك الموقع قابلاً للزحف». — Gary Illyes (جلسة أسئلة على Reddit)، مؤكداً أن قابلية الاكتشاف عبر الروابط هي الأولوية، لا اسم أي نموذج هندسي بعينه.
• قال Illyes إن تحسين بحث الذكاء الاصطناعي لا يتطلب سوى SEO عادي — محتوى عالي الجودة ومنظم وقابل للزحف — من دون حاجة إلى تغييرات خاصة في الهندسة.

قائمة تحقق لهندسة الموقع

جولة للتأكد من أن بنيتك تدعم الزحف وفهم السياق وتدفق قيمة الروابط:

• تسلسل هرمي واضح من أعلى إلى أسفل: الصفحة الرئيسية ← صفحات المحاور/الفئات ← الصفحات المحددة.
• لكل صفحة مهمة رابط من صفحة أخرى واحدة على الأقل (لا صفحات يتيمة).
• الصفحات المهمة غير مدفونة على عمق غير ضروري (لا توجد قاعدة ثابتة لعمق النقر — افحص بيانات الزحف بحثاً عن صفحات يقل الزحف إليها كلما تعمقت).
• لكل مجال موضوعي صفحة محور/ركيزة ترتبط بصفحات موضوعاته الفرعية.
• ترتبط صفحات الموضوعات الفرعية بمحورها وبالصفحات الشقيقة ذات الصلة.
• توجد روابط بين المجموعات عندما تكون الموضوعات مرتبطة فعلاً (لا جدران صوامع صارمة).
• تستخدم الروابط الداخلية نص رابط وصفياً وسياقاً محيطاً ذا صلة.
• لا تعتمد أي صفحة مهمة على تنقل بالنقر فقط — الروابط هي <a href> حقيقية.
• بنية عناوين URL منطقية للبشر، لكنك لا تعتمد على المجلدات للإشارة إلى الهندسة (فالروابط تفعل ذلك).
• تمت مراجعة بيانات الزحف بحثاً عن الصفحات شديدة العمق واليتيمة وفجوات الروابط الداخلية.

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

1. رسم الروابط هو الهندسة. مجلدات عناوين URL للبشر وللتنظيم. تستنتج Google التسلسل الهرمي والسياق من طريقة ترابط الصفحات. راجع رسم الروابط وصمّمه، لا شجرة المجلدات.

2. ثلاثة أسماء وبنية واحدة. الصومعة والمحور والأذرع ومجموعات الموضوعات ← تلتقي كلها في بنية هرمية مجمّعة ومترابطة داخلياً حالما تسمح بروابط متقاطعة معقولة. توقف عن البحث عن النموذج «الصحيح»؛ ابنِ المجموعة واربطها جيداً.

3. احتفظ بالنواة وأسقط الجدار. احتفظ من الصوامع بالتركيز الموضوعي (اربط بكثافة داخل الموضوع). وأسقط قاعدة العزل (لا تربط أبداً بين الصوامع) — فلا يطلبها أي مصدر من Google، وهي تضر المستخدمين.

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

5. الهندسة مضاعِف وليست مصدراً. تضاعف البنية الجيدة قيمة المحتوى الجيد بجعله قابلاً للاكتشاف وواضح السياق. وإذا ضربت صفراً (محتوى سطحي) فستظل النتيجة صفراً.

مرجع نماذج الهندسة

ما الذي ينبغي أن تفعله كل طبقة؟

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

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

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

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

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

محاضراتي

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

من أنحاء القطاع

• أوقفوا جنون الصوامع: هندسة موقع فعالة لتحسين محركات البحث وقابلية الاكتشاف (Shari Thurow، Search Engine Land) — الحجة المرجعية ضد الصوامع الصارمة.
• هندسة الموقع لتحسين محركات البحث: بنية تحقق الترتيب وتتوسع (Search Engine Land) — دليل شامل للبنية.
• الدليل الكامل إلى مجموعات الموضوعات (Search Engine Land) — نموذج المجموعة بعمق.
• مجموعات الموضوعات: التطور التالي في SEO (HubSpot) — منشأ مصطلح «مجموعة الموضوعات» عام 2017.
• استراتيجيات محتوى SEO: نموذج المحور والأذرع (Botify) — البنية نفسها تحت اسمها في هندسة المعلومات.
• John Mueller يوصي ببنية موقع هرمية (Search Engine Journal) — مصدر اقتباس الهرم/السياق.

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