SEO الدولي التقني

كيفية تنفيذ SEO لموقع متعدد اللغات أو المناطق: hreflang، وبنية عناوين URL الإقليمية، والنطاقات المحلية، والمجلدات الفرعية، والنطاقات الفرعية، ومشكلات canonical والروابط العائدة.

نُشر أول مرة: 27 يونيو 2026 · آخر تحديث: 9 أغسطس 2026 · Advanced
اللغات

SEO الدولي التقني هو النصف التنفيذي من SEO متعدد المناطق واللغات. يربط hreflang عناوين URL البديلة، بينما تجمع canonical العناوين المكررة بصورة منفصلة. ويمثل x-default تعيينًا للغة غير المدرجة، وليس إعادة توجيه. تقبل Google hreflang في HTML أو رؤوس HTTP أو خرائط XML للموقع. وتظل بنية عناوين URL الإقليمية مفاضلة بين ccTLD والمجلدات الفرعية والنطاقات الفرعية؛ ولا يضمن أي من ذلك الفهرسة أو الترتيب أو الزيارات أو اللغة المعروضة، بل يدعم الاكتشاف ومطابقة المنطقة.

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

Evidence for this claim Google recommends separate locale-specific URLs, crawlable navigation, and explicit locale signals for multi-regional or multilingual sites rather than automatic IP-based adaptation alone. Scope: Current Google international site guidance. Confidence: high · Verified: Google Search Central: Managing multi-regional sites Evidence for this claim hreflang annotations identify localized alternates and require reciprocal, valid URL relationships; they are not a ranking guarantee. Scope: Current Google hreflang implementation. Confidence: high · Verified: Google Search Central: Localized versions

كيف يعمل hreflang ولماذا يفشل بصمت؟

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

تحكمه قاعدتان. تستخدم اللغة رموز ISO 639-1 وتستخدم المنطقة رموز ISO 3166-1 alpha-2 — ولذلك تكون المملكة المتحدة gb لا uk (وهو خطأ شائع وصامت). ويجب أن تشير كل صفحة في المجموعة إلى كل صفحة أخرى في المجموعة، بما فيها نفسها.

مجموعة hreflang عملية (مع x-default)

بالنسبة إلى صفحة منشورة بالإنجليزية الأمريكية والإنجليزية البريطانية والإسبانية الإسبانية، يحمل كل عنوان من عناوين URL الثلاثة هذه الكتلة نفسها في <head>:

<link rel="alternate" hreflang="en-us" href="https://example.com/us/page/" />
<link rel="alternate" hreflang="en-gb" href="https://example.com/uk/page/" />
<link rel="alternate" hreflang="es-es" href="https://example.com/es/page/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page/" />

تحدد قيمة x-default عنوان URL احتياطيًا للغات أو المناطق التي لم تدرجها صراحة. وهي وسم بحث، وليست إعادة توجيه أو وعدًا بأن يصل كل باحث غير مطابق إلى ذلك العنوان. حذفها ليس قاتلًا. ولطرق التسليم الثلاث — عناصر HTML <link>، ورؤوس HTTP Link، ووسوم خريطة XML للموقع — ولكل حالة طرفية مثل المجموعات أحادية الاتجاه والمجموعات الجزئية وإعادة التوجيه داخل مجموعة، راجع كيفية تنفيذ hreflang وx-default hreflang، بينما يحافظ هذا المحور على اللب المستقر فقط.

تبادل وسم العودة: عدم التطابق الذي يبطل زوجًا

أكثر طرق فشل مجموعة hreflang شيوعًا هي غياب وسم العودة. إذا أدرج /uk/page/ عنوان /us/page/ بوصفه بديلًا، لكن /us/page/ لم يدرج /uk/page/ عائدًا، تتعامل Google مع الوسم بوصفه غير مؤكد وتتجاهل ذلك الزوج. يجب أن يكون التأكيد متبادلًا:

<!-- WRONG: /us/page/ lists UK below but never gets pointed back to from /uk/page/ -->
<link rel="alternate" hreflang="en-us" href="https://example.com/us/page/" />
<link rel="alternate" hreflang="en-gb" href="https://example.com/uk/page/" />

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

يهم تعارض canonical وhreflang أكثر في حالة أضيق: صفحات شبه متطابقة باللغة نفسها عبر الدول (مثل صفحات منتجات بالإنجليزية الأمريكية والبريطانية تختلف فقط في العملة وبعض التهجئات). تتعامل إرشادات Google مع ذلك بوصفه مشكلة محتوى مكرر، لا مشكلة ترجمة — اختر نسخة مفضلة واجمع rel="canonical" مع hreflang بدل محاولة إبقاء كل نسخة إقليمية مستقلة تمامًا. أما الصفحات المترجمة بالكامل والمختلفة جوهريًا في اللغة فهي حالة منفصلة ولا تحتاج إلى هذه المعالجة. راجع المحتوى المكرر عبر اللغات وcanonicalization للتفاصيل.

ccTLD مقابل المجلد الفرعي مقابل النطاق الفرعي: أين تتراكم الإشارات؟

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

أيًا كانت البنية التي تختارها، أبقِ النسخ المحلية على عناوين URL مستقرة ومنفصلة وقابلة للزحف بدل تبديل المحتوى اعتمادًا على عنوان IP أو رأس Accept-Language وحده. يزحف Googlebot عادة من بنية تحتية مقرها الولايات المتحدة ولا يرسل رأس Accept-Language، لذلك قد يؤدي عنوان URL الذي يكيّف محتواه مع منطقة مكتشفة — من دون عنوان URL منفصل قابل للربط لكل نسخة — إلى بقاء بعض النسخ خارج الزحف أو الفهرسة أو الترتيب.

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

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.