ccTLD مقابل النطاق الفرعي مقابل الدليل الفرعي لـSEO الدولي

الخلاصة — إذا أردت تقديم نسخ مختلفة من موقعك لبلدان مختلفة، فلديك ثلاثة أشكال لعناوين URL تختار منها: نطاق دولة مثل example.de، أو نطاق فرعي مثل de.example.com، أو مجلد مثل example.com/de/. توثق Google الأشكال الثلاثة باعتبارها هياكل قابلة للاستخدام. وهناك فرق مهم: فنطاق الدولة (.de أو .fr أو .co.uk) يرسل إشارة قوية تلقائيًا إلى محركات البحث و المستخدمين عن البلد المقصود. أما إصدار المجلد فهو الأسهل تشغيلًا، ولذلك هو الخيار الافتراضي المنطقي لمعظم المواقع.

الخيارات الثلاثة

لنفترض أنك شركة أمريكية تتوسع في ألمانيا. أين توجد النسخة الألمانية من موقعك؟ لديك ثلاثة خيارات:

• ccTLD — نطاق المستوى الأعلى لرمز الدولة: example.de. و.de هو امتداد نطاق ألمانيا، كما أن .fr لفرنسا و.co.uk للمملكة المتحدة. أنت تشتري نطاقًا منفصلًا لكل بلد.
• النطاق الفرعي — بادئة في نطاقك الرئيسي: de.example.com. النطاق الرئيسي نفسه، مع إضافة «de.» إلى بدايته.
• الدليل الفرعي (أو المجلد الفرعي) — مسار في نطاقك الرئيسي: example.com/de/. النطاق نفسه، وكل شيء في مكان واحد، لكنه منظم داخل مجلدات.

هل يتفوق أحدها في الترتيب؟

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

لكن هذا لا يعني أنها قابلة للتبادل. إليك الفرق الوحيد الذي يهم المبتدئ فهمه فعلًا:

يعلن ccTLD بلده تلقائيًا. عندما ترى Google example.de، تعرف مسبقًا أن الموقع يستهدف ألمانيا — ولا يلزم إعداد إضافي. ويحصل المستخدمون على الإشارة نفسها: فالمتسوق الألماني يثق بعنوان .de أكثر من نطاق .com عام.

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

فأيها تختار؟

قاعدة بسيطة تقريبية:

• استخدم دليلًا فرعيًا (example.com/de/) إذا لم تكن متأكدًا. فهو الأرخص والأسهل تشغيلًا — نطاق واحد، وإعداد استضافة واحد، ومكان واحد لإدارة كل شيء — وتظل «قوة» موقعك كلها في نطاق واحد.
• استخدم ccTLD (example.de) إذا كنت تملك نطاقات البلدان أصلًا، أو كانت الثقة في العنوان المحلي مهمة فعلًا (وهو شائع لدى البنوك والحكومات وتجار التجزئة الكبار)، أو كانت لدى بلد ما أسباب قانونية تلزمك باستخدام نطاقه.
• استخدم نطاقًا فرعيًا (de.example.com) أساسًا عندما يكون لديك سبب تقني لإبقاء كل بلد على مضيف منفصل، لكنك لا تريد شراء نطاقات منفصلة.

أكثر ما يخطئ فيه الناس

لا تشترِ ccTLD لكل بلد معتقدًا أنه سيرفع ترتيبك. لن يحدث ذلك — وستقسم سلطة موقعك بين عشرات النطاقات المنفصلة، على كل واحد منها أن يكسب روابطه وسمعته من الصفر. هذه تكلفة حقيقية وليست مكسبًا مجانيًا. أتريد المقايضة الكاملة، وما تقوله Google فعلًا، وكيف غيّر إيقاف أداة الاستهداف الجغرافي في Search Console الأمور؟ فانتقل إلى علامة التبويب Advanced.

الخلاصة — عند استهداف بلد أو لغة، تختار بين ccTLD (example.de)، ونطاق فرعي على gTLD (de.example.com)، ودليل فرعي على gTLD (example.com/de/). توثق Google الأشكال الثلاثة باعتبارها هياكل قابلة للاستخدام، مع مقايضات مختلفة. الفرق الحقيقي هو الإشارة الجغرافية: يحمل ccTLD إشارة بلد تلقائية لا لبس فيها، ولا يحصل الخياران الآخران عليها مجانًا. وتكلفة هذه الإشارة هي التجزئة — فالنطاقات المنفصلة تقسم قيمة الروابط، وتضاعف البنية التحتية، وتجعل إدارة hreflang عبر الخصائص أصعب. تجمع الأدلة الفرعية السلطة في نطاق واحد وهي الأرخص تشغيلًا، لكن بعد إزالة Google تقرير الاستهداف الدولي من Search Console (سبتمبر 2022)، لم تعد هناك طريقة صريحة لإعلان البلد المستهدف لمجلد فرعي — استخدم hreflang إلى جانب المحتوى المحلي الظاهر والإشارات المحلية الأخرى. وتأتي النطاقات الفرعية في الوسط: اسم مضيف منفصل يمكن استضافته داخل البلد، لكنه يحتاج بخلاف ذلك إلى الإشارات اليدوية نفسها التي يحتاج إليها الدليل الفرعي. وتهم الملكية وأهلية التسجيل والحوكمة والتكلفة بقدر أهمية الإشارة — كما أن تغيير الهيكل لاحقًا هو ترحيل كامل لعناوين URL (إعادة توجيه، وcanonical، وhreflang، وخرائط مواقع، ومراقبة)، وليس إصلاحًا سريعًا. خياري الافتراضي هو الأدلة الفرعية، إلا إذا دفعك ccTLD قائم، أو متطلب ثقة/قانون، أو فصل حقيقي للبنية التحتية إلى خيار آخر. هذا قرار دولي — أما سؤال بنية النقطة مقابل الشرطة المائلة العام فهو موضوع منفصل (انظر أدناه).

الهياكل الثلاثة بدقة

ccTLD هو نطاق المستوى الأعلى لرمز الدولة — .de و.fr و.co.uk و.jp. وتتعامل Google معه باعتباره إشارة قوية للاستهداف الجغرافي افتراضيًا: فهي تربط النطاق ببلد تلقائيًا، ولا يمكنك (ولا تحتاج إلى) تجاوز ذلك بإعداد يدوي. أما gTLD (نطاق المستوى الأعلى العام مثل .com و.org و.net) فلا يحمل معنى بلديًا بمفرده، ولذلك يجب على النطاق الفرعي أو الدليل الفرعي الواقع على gTLD أن يكسب استهدافه الجغرافي بطريقة أخرى.

ما الذي تقوله Google فعلًا

تسرد وثائق Google حول إدارة المواقع متعددة المناطق واللغات هذه الهياكل باعتبارها هياكل عناوين URL لاستهداف البلدان، مع مقايضاتها:

• النطاق الخاص ببلد (ccTLD) — الميزة: استهداف جغرافي واضح، وموقع خادم واضح بحكم العرف، وفصل سهل للمواقع. العيب: مكلف، وقد تكون إتاحته محدودة، ويحتاج إلى بنية تحتية أكبر.
• النطاق الفرعي مع gTLD — الميزة: سهل الإعداد ويسمح بمواقع خوادم مختلفة. العيب: قد لا يتعرف المستخدمون على الاستهداف الجغرافي من عنوان URL وحده.
• الدليل الفرعي مع gTLD — الميزة: سهل الإعداد وقليل الصيانة (المضيف نفسه). العيب: قد لا يتعرف المستخدمون على الاستهداف الجغرافي من عنوان URL، مع موقع خادم واحد.
• معلمات URL (example.com?country=de) — غير موصى بها لاستهداف البلدان؛ فمن الصعب تقسيمها، ولا يستطيع المستخدمون التعرف على الموقع الجغرافي من عنوان URL.

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

الفرق الأساسي: إشارة جغرافية تلقائية مقابل يدوية

هذه هي النقطة كلها في القرار، وهي ما يفصله عن نقاش النطاق الفرعي مقابل الدليل الفرعي العام.

يمنحك ccTLD إشارة البلد مجانًا. يُفهم example.de على أنه يستهدف ألمانيا لحظة أن تراه Google. لا تفعل شيئًا. ويراه المستخدمون أيضًا — فـ.de في شريط العنوان إشارة ثقة وملاءمة لا يستطيع مسار .com/de/ منافستها.

لا يحصل النطاق الفرعي أو الدليل الفرعي على gTLD على ذلك تلقائيًا. لا يقول .com شيئًا عن البلد. فكيف تخبر Google بأن example.com/de/ مخصص للمستخدمين الناطقين بالألمانية في ألمانيا؟

لسنوات، كانت الإجابة تتكون من جزأين: hreflang و تقرير الاستهداف الدولي في Search Console، الذي كان يتيح لك ضبط البلد المستهدف يدويًا لخاصية gTLD كاملة — بما في ذلك، عند استخدام خاصية بادئة URL، دليل فرعي محدد مثل example.com/de/. وكان إعداد البلد اليدوي ذلك هو الطريقة الوحيدة للاستهداف الجغرافي الصريح لمجلد فرعي.

التغيير الذي تفوته معظم المقالات: اختفاء الاستهداف الدولي

أزالت Google تقرير الاستهداف الدولي من Search Console في سبتمبر 2022 (إشعار الإيقاف الخاص بـGoogle، كما غطته Search Engine Land). كان التقرير يضم علامتي تبويب — مدقق أخطاء hreflang وإعداد استهداف البلد. وذكرت Google أن قيمة إعداد البلد اليدوي انخفضت بمرور الوقت وأن hreflang نضج.

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

• hreflang — التعليقات المتبادلة من نوع language-region التي تخبر Google بأي نسخة تعرض لكل مستخدم (انظر hreflang وx-default).
• الإشارات التي تستنتجها Google بنفسها — موقع الخادم/CDN، واللغة والعملة المحليتان، والعنوان ورقم الهاتف المحليان، والروابط من مواقع داخل البلد.

لا يمثل أي من ذلك إعلانًا صريحًا من نوع «هذا المجلد يستهدف ألمانيا» كما كان الإعداد القديم. فـhreflang تلميح عن النسخة التي ينبغي عرضها، وليس تعيينًا لبلد. ولذلك يعتمد مسار الدليل الفرعي الآن بالكامل على تنفيذ hreflang بصورة صحيحة — وفي دراستي لـ374 756 نطاقًا يستخدم hreflang، أخطأ أكثر من 67% منها جزئيًا على الأقل. هذه هي التكلفة الحقيقية لخيار «الأسهل تشغيلًا»: الإشارة الجغرافية تقع عليك كلها، مع هامش خطأ أقل.

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

تكلفة ccTLD: التجزئة

إذا كانت ccTLD تمنح أوضح إشارة، فلماذا لا تستخدمها في كل مكان؟ لأن الإشارة تأتي مع تكاليف حقيقية:

• تقسيم السلطة. كل ccTLD هو نطاق منفصل. فالنقود الواردة إلى example.de تبني سلطة example.de، لا example.com. أنت تبدأ سمعة كل بلد من قرب الصفر بدل تجميعها في نطاق قوي واحد. وبالنسبة إلى موقع تتركز قوته في gTLD واحد، قد تضر هذه التجزئة أكثر مما تنفع الإشارة الجغرافية الواضحة.
• تضاعف البنية التحتية. مزيد من النطاقات للتسجيل والتجديد، ومزيد من إعدادات الاستضافة أو CDN، ومزيد من الشهادات، ومزيد من كل شيء. وبعض ccTLDs تتطلب حضورًا أو عنوانًا محليًا للتسجيل أصلًا (مثل .com.au، وتاريخيًا بعض ccTLDs الأوروبية)، وهو عائق قانوني/إداري لا تقني فحسب.
• hreflang أصعب. hreflang عبر نطاق واحد دقيق ومزعج؛ أما hreflang عبر عشرات الخصائص المنفصلة — وكل واحدة تحتاج إلى الإشارة إلى الأخرى تبادليًا — فهو الموضع الذي تتعطل فيه المواقع الدولية الكبيرة غالبًا. وكل ccTLD تضيفه هو عقدة أخرى ينبغي لكل عقدة سواه الإشارة إليها بصورة صحيحة.

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

النطاقات الفرعية: الحل الأوسط

النطاق الفرعي على gTLD (de.example.com) خيار أوسط حقيقي، لكن افهم لماذا هو في الوسط:

• مثل الدليل الفرعي، يقع على gTLD، ولذلك لا يحصل على إشارة بلد تلقائية — بل يحتاج إلى hreflang والإشارات المستنتجة نفسها التي يحتاج إليها المجلد الفرعي.
• بخلاف الدليل الفرعي، هو اسم مضيف منفصل، ولذلك يمكن استضافته بسهولة على خادم مختلف أو في بلد مختلف، كما يمكن فصله إلى فريق أو حزمة تقنية مختلفة. وتشير وثائق Google تحديدًا إلى أن النطاقات الفرعية “allow different server locations.” (ترجمة) «تسمح بمواقع خوادم مختلفة».
• أما تعامل Google مع النطاق الفرعي بوصفه جزءًا من موقعك الرئيسي (فتنتقل السلطة) أو بوصفه موقعًا منفصلًا، فيُحسم لكل موقع بناءً على التكامل — وهو التقييم لكل موقع نفسه الذي يحكم سؤال النطاق الفرعي مقابل الدليل الفرعي العام.

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

ماذا عن دراسات الارتباط؟

سترى دراسات تظهر هيمنة ccTLD في نتائج البحث الدولية — فمثلًا وجدت تحليلات SE Ranking لـ20 000 كلمة مفتاحية عبر 15 سوقًا أن ccTLD تحتل الحصة الأكبر من المراكز الثلاثة الأولى، تليها الأدلة الفرعية بفارق كبير، ثم النطاقات الفرعية بحصة صغيرة. وإذا أخذت ذلك على ظاهره، فستستنتج أن ccTLD «تفوز».

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

أين توجد المقايضات العامة (غير الدولية)؟

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

الملكية والحوكمة والتكلفة جزء من القرار أيضًا

تصوغ Google هذا على أنه مقايضة لا مسابقة ترتيب، وتتجاوز المقايضات الإشارة الجغرافية:

• الملكية والإتاحة. يجب أن تكون قادرًا فعلًا على شراء ccTLD الذي تريده والاحتفاظ به. تقيد بعض سجلات البلدان من يستطيع التسجيل — بحضور تجاري محلي، أو جهة اتصال محلية، أو عنوان محلي (وكان ذلك صحيحًا تاريخيًا لبعض ccTLDs الأوروبية ونظيرات .com.au). ويُسوَّق عدد قليل من ccTLDs ويُعامل كنطاقات عامة للزينة أكثر من كونها إشارات بلدان (.io و.co)، فلا تفترض أن كل نهاية cc تتصرف بالطريقة نفسها في نظر Google.
• الحوكمة وعزل النشر. يمكن لفريق مختلف تشغيل ccTLD أو نطاق فرعي منفصل، على حزمة تقنية مختلفة، مع عمليات نشر مستقلة — وهذا مفيد حقًا إذا احتاج سوق محلي إلى دورة إصدار خاصة به. لكن هذا العزل تكلفة أيضًا: خصائص أكثر للتأمين والمراقبة والحفاظ على اتساقها، ومساحة أكبر لخطأ سوق واحد (وسم hreflang معطوب أو شهادة منتهية) كي يفوت الفريق الذي يدير الأسواق الأخرى.
• التكلفة. يتوسع التسجيل والتجديد والاستضافة والشهادات مع عدد الخصائص. وتضاعف استراتيجية ccTLD لكل سوق كل ذلك، بينما تبقي استراتيجية الدليل الفرعي الأمر عند نطاق واحد.

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

مخاطر الترحيل

تغيير الهياكل لاحقًا — من ccTLD إلى دليل فرعي، أو من نطاق فرعي إلى ccTLD، أو في أي اتجاه آخر — ليس نسخًا ولصقًا. إنه ترحيل لعناوين URL، بالآليات نفسها والمخاطر نفسها التي ينطوي عليها أي ترحيل آخر:

• إعادة التوجيه. يحتاج كل عنوان URL قديم إلى إعادة توجيه 1:1 إلى نظيره الجديد، لا إلى إعادة توجيه شاملة إلى الصفحة الرئيسية.
• وسوم canonical. حدّث canonical لتشير إلى عناوين URL الجديدة؛ وعندما تظل لديك نسخ إقليمية باللغة نفسها، توصي Google بـcanonical مفضل مع hreflang بدل تركها تتنافس.
• hreflang. يجب أن تشير مجموعة hreflang التبادلية لكل لغة إلى عناوين URL الجديدة — عبر كل خاصية، لا الخاصية التي نقلتها فقط.
• الروابط الداخلية وخرائط المواقع. حدّث الروابط الداخلية إلى عناوين URL الجديدة وجدّد خرائط XML كي تعثر برامج الزحف على الهيكل الجديد سريعًا.
• التحقق من المضيف. يمثل ccTLD أو النطاق الفرعي خاصية جديدة في Search Console وBing Webmaster Tools؛ فتحقق منها قبل أن تحتاج إلى البيانات، لا بعد تعطل شيء.
• المراقبة. راقب الفهرسة وحركة المرور والترتيب طوال الانتقال. وإذا قارنت أرقام ما قبل الترحيل وما بعده، فتذكر أن الترحيل نفسه متغير مربك — لا يمكنك إسناد التغيير إلى شكل URL الجديد من دون ضبط كل ما تغير في الوقت نفسه (إعادة التوجيه والمحتوى والروابط).

لا ترحّل الهياكل لمجرد مطاردة زيادة في الترتيب — فلا تذكر Google تفضيلًا بينها، ويحمل الترحيل نفسه مخاطر أكبر مما يُرجح أن يصلحه تغيير الهيكل.

توصيتي

• اجعل الأدلة الفرعية الخيار الافتراضي (example.com/de/). فهي الأرخص تشغيلًا، وتبقى السلطة مجمعة، وبالنسبة لمعظم المواقع تعد الإشارة الجغرافية الأضعف مقايضة مقبولة مقابل البساطة. التزم فقط بإتقان hreflang، لأنه منذ 2022 رافعتك الصريحة الوحيدة.
• اختر ccTLD عندما تكون الإشارة الجغرافية مهمة فعلًا ويمكنك تحمل التجزئة: تملك نطاقات البلدان أصلًا، أو تعمل في قطاع تزيد فيه قيمة العنوان المحلي الثقة (التمويل أو الصحة أو التجزئة الكبيرة أو الجهات القريبة من الحكومة)، أو لدى سوق ما متطلبات قانونية/تسجيلية تدفعك إلى استخدام نطاقه. تأكد من قدرتك فعلًا على تسجيل النطاقات التي تريدها وإدارتها قبل الالتزام. واعرف مسبقًا أن كل نطاق يبني سلطته الخاصة.
• اختر النطاقات الفرعية أساسًا لأسباب تتعلق بالبنية التحتية — تحتاج إلى مضيف أو حزمة تقنية منفصلة لكل بلد، لكنك لا تريد (أو لا تحتاج) نطاقات منفصلة. وستظل مدينًا بالإشارة الجغرافية اليدوية نفسها التي يحتاج إليها الدليل الفرعي.
• لا تخلط عشوائيًا. إن اختيار هيكل وتطبيقه باتساق عبر كل الأسواق أهم من الهيكل الذي تختاره. فالاتساق هو ما يبقي hreflang والزحف قابلين للإدارة على نطاق واسع.
• لا ترحّل الهياكل بلا خطة. إذا انتقلت، فعامل الأمر كترحيل كامل لعناوين URL — إعادة توجيه وcanonical وhreflang وروابط داخلية وخرائط مواقع والتحقق من المضيف والمراقبة — لا إصلاحًا سريعًا لمشكلة ترتيب.

أين يندرج هذا

يغطي الأشقاء في هذه المجموعة أساسيات دولية أوسع — تدقيق SEO دولي، وقائمة تنفيذ، وبحث كلمات مفتاحية عبر الأسواق، وقرار الترجمة مقابل التوطين. أما آليات الوسوم فتوجد في hreflang وx-default. والعامل الحاسم بعد اختيار هيكل هو في الغالب صحة hreflang، لا الهيكل نفسه.

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

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

• ثلاثة هياكل لاستهداف البلدان: ccTLD (example.de)، ونطاق فرعي على gTLD (de.example.com)، ودليل فرعي على gTLD (example.com/de/).
• لا تفضل Google أحدها في الترتيب (وهو ما تذكره في وثائق المواقع متعددة المناطق ووثائق بنية عناوين URL). فالاختيار يتعلق بالإشارات والتشغيل، لا بالترتيب.
• الفرق الأساسي — الإشارة الجغرافية. يحمل ccTLD إشارة بلد تلقائية لا لبس فيها إلى Google والمستخدمين معًا، من دون إعداد يدوي. أما النطاق الفرعي أو الدليل الفرعي على gTLD فلا يحصل على إشارة بلد تلقائية، بل يعتمد على hreflang والإشارات المستنتجة (موقع الخادم واللغة والعملة والروابط المحلية).
• إزالة الاستهداف الدولي (سبتمبر 2022). أزالت Google تقرير Search Console الذي كان يتيح ضبط البلد المستهدف لخاصية gTLD (بما فيها الدليل الفرعي) يدويًا. لم تعد هناك طريقة صريحة لإعلان بلد مجلد فرعي — وhreflang هي الرافعة المتبقية الوحيدة.
• تكلفة ccTLD = التجزئة. تقسم النطاقات المنفصلة قيمة الروابط (فكل واحد يبني سلطته الخاصة)، وتضاعف البنية التحتية، وتجعل hreflang عبر الخصائص أصعب.
• الدليل الفرعي = الأرخص، مع سلطة مجمعة في نطاق واحد، لكنه يعتمد بالكامل على hreflang في الإشارة الجغرافية.
• النطاق الفرعي = حل وسط: اسم مضيف منفصل (استضافة/موقع خادم مرن)، لكنه يحتاج إلى الإشارات الجغرافية اليدوية نفسها التي يحتاج إليها الدليل الفرعي؛ وتتعامل معه Google كجزء من الموقع أو كموقع منفصل بحسب كل موقع.
• تحفظ الارتباط: الدراسات التي تظهر هيمنة ccTLD في نتائج البحث الدولية (مثل دراسة SE Ranking لعشرين ألف كلمة مفتاحية) ارتباطية — فالعلامات المحلية الراسخة تستخدم ccTLD بحكم العرف، ولا يتسبب النطاق نفسه في الترتيب.
• الملكية والحوكمة والتكلفة. تقيد بعض ccTLD من يستطيع تسجيلها (بمتطلبات حضور أو عنوان محلي)، ويُعامل عدد قليل منها كنطاقات عامة للزينة لا كإشارات بلدان. وكلما زادت الخصائص زاد عبء الحوكمة والتكلفة (التسجيل والاستضافة والشهادات) بصرف النظر عن الإشارة الجغرافية.
• مخاطر الترحيل. تغيير الهياكل لاحقًا هو ترحيل كامل لعناوين URL — إعادة توجيه وcanonical وhreflang وروابط داخلية وخرائط مواقع والتحقق من المضيف والمراقبة — وأي مقارنة ترتيب قبل/بعد تربكها كل التغييرات الأخرى. لا ترحّل لمجرد مطاردة زيادة في الترتيب.
• خيار Patrick الافتراضي: الأدلة الفرعية، إلا إذا دفع ccTLD قائم، أو متطلب ثقة/قانون، أو فصل حقيقي للبنية التحتية إلى غير ذلك. والاتساق عبر الأسواق أهم من الاختيار نفسه.

أي هيكل ينبغي أن تستخدم؟

اعمل من الأعلى إلى الأسفل — فأول إجابة «نعم» تنطبق عليك تحسم الأمر عادةً.

1. هل تملك بالفعل نطاقات بلدان، أو هل تأسس نشاطك عليها بالفعل (example.de وexample.fr مثلًا)؟ → استخدم ccTLD. لقد دفعت تكلفة التجزئة وبنيت سلطة محلية بالفعل؛ فلا تهدر ذلك لتجميع كل شيء. احتفظ بها ووصل hreflang عبر الخصائص.

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

3. هل تحتاج إلى وضع كل بلد على خادم أو حزمة تقنية أو فريق منفصل فعلًا، لكنك لا تريد شراء نطاقات منفصلة؟ → استخدم نطاقًا فرعيًا (de.example.com). تحصل على مرونة الاستضافة/الموقع من دون نطاق منفصل — تذكر فقط أنك ما زلت مدينًا بـhreflang؛ فالنطاق الفرعي لا يستهدف نفسه جغرافيًا.

4. لا ينطبق ما سبق — هل أنت موقع أغلبه .com يتوسع إلى لغات/بلدان جديدة وتريد أبسط ما يعمل؟ → استخدم أدلة فرعية (example.com/de/). تبقى السلطة مجمعة في نطاق واحد، وإعداد استضافة واحد، وملكية Search Console واحدة. والتزم بصحة hreflang، لأنه منذ سبتمبر 2022 لم يعد هناك إعداد يدوي لاستهداف البلد يمكنك الرجوع إليه.

قاعدتان تتجاوزان شجرة القرار:

• الاتساق يتفوق على الاختيار «المثالي». هيكل واحد مطبق بعناية عبر كل الأسواق أفضل من مزيج يُختار لكل سوق بناءً على حدس.
• لا ترحّل الهياكل لمجرد زيادة في الترتيب. لا تفضل Google أحدها؛ ومخاطر الترحيل (انظر المقال العام عن النطاق الفرعي مقابل الدليل الفرعي) تتغلب عادةً على إشارة يمكنك الحصول عليها عبر hreflang.

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

وثائق المصدر الأول من محركات البحث.

Google

• إدارة المواقع متعددة المناطق واللغات — هياكل عناوين URL الثلاثة لاستهداف البلدان (ccTLD والنطاق الفرعي والدليل الفرعي)، ومزاياها وعيوبها، والتوصية باستخدام عناوين URL مختلفة لكل نسخة بدل العرض عبر ملفات الارتباط أو المتصفح.
• أفضل ممارسات بنية عناوين URL — توصي بـccTLD أو الأدلة الفرعية للاستهداف الجغرافي، من دون تفضيل معلن في الترتيب.
• أخبر Google بالنسخ المحلية من صفحتك (hreflang) — قواعد hreflang التبادلية التي تمثل الإشارة الجغرافية الصريحة الوحيدة المتبقية للنطاقات الفرعية والأدلة الفرعية على gTLD، إلى جانب الإشارات المستنتجة (موقع الخادم والمحتوى المحلي والروابط المحلية) التي تقرؤها Google بنفسها.
• زحف المواقع متعددة اللغات وفهرستها — كيف تكتشف Google نسخة اللغة الصحيحة وتعرضها.

Bing / Microsoft

• كيفية إخبار Bing ببلد موقعك ولغته (مدونة Bing Webmaster) — إرشادات Bing للمواقع متعددة البلدان/اللغات؛ لاحظ أن Bing يعتمد بدرجة أكبر على إشارة meta/header من نوع content-language لا على hreflang.
• إرشادات Bing لمشرفي المواقع — إرشادات عامة، ولا تفرض تفضيلًا بين ccTLD أو النطاق الفرعي أو الدليل الفرعي للمواقع المشروعة.

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

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

Google — لا تفضيل في الترتيب بين الهياكل

• أُعيدت صياغة موقف Google: تنص وثائقها على اختيار ما يسهل تنظيمه وإدارته، وأنها لا تفضل هيكلًا على آخر من منظور الفهرسة والترتيب. وثائق بنية عناوين URL

Google — الهياكل الدولية الثلاثة ومقايضاتها

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

Google — إزالة تقرير الاستهداف الدولي (سبتمبر 2022)

• أُعيدت الصياغة من إعلان Google في Search Console كما نُقل: أُحيل تقرير الاستهداف الدولي إلى التقاعد لأن قيمة إعداد استهداف البلد اليدوي انخفضت بمرور الوقت مع نضج hreflang — فبقي hreflang آلية الإشارة إلى النسخ المحلية. إشعار الإيقاف الخاص بـGoogle

الأخطاء الشائعة (وما ينبغي فعله بدلًا منها)

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

الخرافة 2: «الأدلة الفرعية جيدة بالقدر نفسه، لذلك لا أحتاج إلى hreflang». لماذا هي خاطئة: لا يحصل الدليل الفرعي على gTLD على إشارة بلد تلقائية، ومنذ أن أزالت Google تقرير الاستهداف الدولي (سبتمبر 2022) لم يعد هناك إعداد يدوي لاستهداف البلد. ومن دون hreflang، لم تخبر Google بشيء عن الجمهور المقصود لكل نسخة. افعل بدلًا من ذلك: نفّذ hreflang متبادلًا ومرجعًا إلى نفسه عبر كل مجلدات اللغات المحلية — فهذا هو الرافعة الصريحة الوحيدة المتبقية.

الخرافة 3: «اضبط البلد المستهدف في Search Console لمجلدي /de/». لماذا هي خاطئة: لم يعد هذا الإعداد (الاستهداف الدولي) موجودًا — فقد أُزيل في سبتمبر 2022. ولا يمكنك إعلان بلد المجلد الفرعي صراحةً بعد الآن. افعل بدلًا من ذلك: اعتمد على hreflang والإشارات المستنتجة (موقع الخادم/CDN، واللغة والعملة المحليتان، والعنوان المحلي، والروابط داخل البلد).

الخرافة 4: «تستهدف النطاقات الفرعية نفسها جغرافيًا لأنها أسماء مضيفين منفصلة». لماذا هي خاطئة: لا يحمل النطاق الفرعي على gTLD (de.example.com) معنى بلديًا من .com؛ ويحتاج إلى hreflang والإشارات المستنتجة نفسها التي يحتاج إليها الدليل الفرعي. فالاسم المضيف المنفصل يمنح مرونة الاستضافة، لا إشارة جغرافية تلقائية. افعل بدلًا من ذلك: عامل الاستهداف الجغرافي للنطاق الفرعي كما تعامل استهداف الدليل الفرعي — ابدأ بـhreflang — واستخدم النطاق الفرعي فقط لمزايا بنيته التحتية.

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

الخرافة 6: «اخلط الهياكل لكل سوق — اختر ما هو مريح في كل مرة». لماذا هي خاطئة: يجعل المزيج غير المتسق مجموعات hreflang والزحف والسلطة أصعب فهمًا وأسهل كسرًا على نطاق واسع. افعل بدلًا من ذلك: اختر هيكلًا أساسيًا وطبقه باتساق؛ ولا تحِد عنه إلا لسبب محدد ومبرر (مثل ccTLD قائم أو متطلب قانوني).

قائمة فحص اختيار هيكل URL دولي

قبل الاختيار

• تأكد من أنك تحتاج فعلًا إلى استهداف البلد/اللغة (محتوى مختلف لكل سوق)، لا مجرد ترجمة موقع عالمي واحد.
• أحصِ أسواقك المستهدفة وسجل أي سوق لديه متطلبات قانونية/تسجيلية لنطاق محلي.
• تحقق مما إذا كنت تملك ccTLD ذات صلة بالفعل أو تحصل على ترتيب في أي منها.
• قرر مقدار أهمية الثقة المحلية في قطاعك (يميل التمويل/الصحة/التجزئة إلى ccTLD؛ وغالبًا ما يناسب SaaS/المحتوى الأدلة الفرعية).

اتخاذ القرار

• هل أنت مؤسس على ccTLD بالفعل، أو هل الثقة/القانون حاسمان؟ → ccTLD.
• هل تحتاج إلى استضافة/موقع خادم منفصل لكل بلد، لكن ليس إلى نطاقات منفصلة؟ → نطاق فرعي.
• وإلا، هل تريد أبسط تشغيل مع سلطة مجمعة؟ → دليل فرعي (الخيار الافتراضي).
• أيًا كان اختيارك، خطط لتطبيقه باتساق عبر كل الأسواق.

بعد الاختيار (أي هيكل gTLD — نطاق فرعي أو دليل فرعي)

• تذكر أنه لم يعد هناك إعداد يدوي لاستهداف البلد في Search Console (أُزيل في سبتمبر 2022).
• نفّذ hreflang متبادلًا ومرجعًا إلى نفسه عبر كل النسخ.
• أضف x-default لصفحة الاختيار/البديل.
• عزز ذلك بالإشارات المستنتجة: موقع الخادم/CDN، واللغة والعملة المحليتان، والعنوان/الهاتف المحليان، والروابط من مواقع داخل البلد.
• لا ترحّل هيكلًا قائمًا يعمل لمجرد الحصول على زيادة في الترتيب.

إذا اخترت ccTLD

• ضع ميزانية للتسجيل والتجديد والاستضافة والشهادات لكل نطاق على حدة.
• خطط لـhreflang عبر الخصائص المنفصلة (كل ccTLD يشير إلى كل ccTLD آخر تبادليًا).
• تقبل أن كل نطاق يبني سلطته الخاصة — ولا تتوقع تجميع قيمة الروابط.

إذا كنت تنتقل بين الهياكل

• أعد توجيه كل عنوان URL قديم 1:1 إلى نظيره الجديد — لا تعِد التوجيه الشامل إلى الصفحة الرئيسية.
• حدّث وسوم canonical إلى عناوين URL الجديدة؛ واحتفظ بـcanonical مفضل مع hreflang لأي نسخ إقليمية باللغة نفسها.
• أعد بناء hreflang التبادلي عبر كل الخصائص، مع الإشارة إلى عناوين URL الجديدة.
• حدّث الروابط الداخلية وجدّد خرائط مواقع XML.
• تحقق من المضيف/الخاصية الجديدة في Search Console وBing Webmaster Tools قبل حاجتك إلى البيانات.
• راقب الفهرسة وحركة المرور والترتيب أثناء الانتقال — وتذكر أن الترحيل نفسه متغير مربك في أي مقارنة قبل/بعد.

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

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

2. الإشارة الجغرافية التلقائية مقابل اليدوية. ccTLD وحده يمنحك إشارة البلد مجانًا. أما كل ما يقع على gTLD — نطاق فرعي أو دليل فرعي — فله إشارة يدوية أنت مسؤول عنها. ومنذ سبتمبر 2022، تعني «يدوية» hreflang لا إعداد Search Console. فإذا اخترت هيكل gTLD، فأنت تلتزم بتشغيل hreflang بصورة صحيحة.

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

4. الاتساق يتفوق على التحسين. هيكل واحد مطبق بعناية عبر كل الأسواق أهم من مزيج لكل سوق يُختار بناءً على حدس. فالخيار المتسق هو ما يبقي مجموعات hreflang والزحف قابلين للإدارة على نطاق واسع.

5. افصل السؤال الدولي عن العام. «أين ينبغي أن تعيش مدونتي؟» (النطاق الفرعي مقابل الدليل الفرعي عمومًا) و«كيف أقدم الخدمة لبلدان مختلفة؟» قراران مختلفان بعوامل حسم مختلفة. يدور الأول حول التكامل ومخاطر الترحيل؛ ويدور الثاني حول الإشارة الجغرافية. لا تنقل إجابة أحدهما إلى الآخر.

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

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

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

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

• Hreflang: الدليل السهل للمبتدئين — الآليات التي ستعتمد عليها لأي نطاق فرعي أو دليل فرعي على gTLD، إضافة إلى دراستي لـ374 756 نطاقًا يستخدم hreflang التي تظهر مدى تكرر تعطل hreflang (كان لدى أكثر من 67% منها مشكلة).
• دليل المبتدئين إلى SEO التقني — موضع قرارات بنية عناوين URL الدولية في الصورة الأكبر.
• النطاق الفرعي مقابل الدليل الفرعي: الأدلة الفرعية ليست أفضل من النطاقات الفرعية في SEO — حجتي العامة (غير الدولية) بأن الاثنين متكافئان وظيفيًا، وأن معظم «مكاسب» الترحيل مختلطة؛ اقرأه لنسخة سؤال «أين ينبغي أن تعيش مدونتي؟».

مشاركتي

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

من أرجاء المجال

• إدارة المواقع متعددة المناطق واللغات (Google Search Central) — قائمة المصدر للهياكل الثلاثة ومزاياها وعيوبها الموثقة.
• إيقاف تقرير الاستهداف الدولي (مساعدة Google Search Console) — إزالة سبتمبر 2022 وما تعنيه لإعلان بلد مجلد فرعي.
• أفضل ممارسات بنية عناوين URL (Google Search Central) — إرشادات الاستهداف الجغرافي وموقف عدم التفضيل.
• بحث النطاقات الفرعية مقابل الأدلة الفرعية: تحليل 20 ألف كلمة مفتاحية (SE Ranking) — دراسة ارتباطية شفافة عبر 15 سوقًا تظهر هيمنة ccTLD في نتائج البحث الدولية (اقرأها ارتباطًا لا سببية).
• أفضل ممارسات SEO مع Cloudflare Workers، الجزء الأول: النطاق الفرعي مقابل الدليل الفرعي (Cloudflare) — حل الوكيل العكسي إذا كنت مقيدًا بنطاق فرعي لكنك تريد عنوان URL لدليل فرعي.

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