دليل اللغة واستهداف البلد
نشرت: 2018-11-19ما هي أفضل طريقة لإعداد موقع ويب يتطلب استهداف البلد واللغة؟ حسنًا ، هذه مشكلة نوقشت كثيرًا بين خبراء تحسين محركات البحث ولسوء الحظ ، لا توجد إجابة واضحة. بغض النظر عن الطريقة التي تختارها لإعداد موقع الويب الخاص بك ، ستكون هناك أوجه قصور لأن كل موقف يختلف ويعتمد على الطبيعة الفريدة لعملك.
ومع ذلك ، كمقدمة للموضوع ، سأقوم باستكشاف كيفية التعامل مع مسألة استهداف اللغة والبلد في بيئة التجارة الإلكترونية.
عند التفكير في نهجنا في البداية ، كان هناك العديد من القضايا المختلفة التي يجب أخذها في الاعتبار ، ولكن بشكل أساسي ، كان هناك عاملين مهمين يجب أخذهما في الاعتبار:
- تحسين محركات البحث (SEO)
- تحسين معدل التحويل (CRO)
كان هناك جانبان منفصلان يجب مراعاتهما لكل من هذين العاملين عندما كنا نختار إعداد المجال الخاص بنا: الطريقة التي نستهدف بها اللغات والطريقة التي نستهدف بها البلدان. الموقع متعدد اللغات هو موقع ويب يقدم محتواه بأكثر من لغة ، على سبيل المثال ، شركة كندية تقدم محتواها باللغتين الإنجليزية والفرنسية.
من ناحية أخرى ، فإن موقع الويب متعدد الأقاليم هو موقع ويب يستهدف على وجه التحديد مستخدمين في بلدان مختلفة. يتم القيام بذلك بشكل متكرر لتحسين CRO من خلال تخصيص المحتوى مثل عملية الطلب وتفاصيل الشحن والبحث عن العنوان وأي محتوى آخر لتحسين التحويلات بناءً على الموقع الجغرافي. بالإضافة إلى هذين الضبطين الفرديين ، من المهم أن تضع في اعتبارك أن الموقع يمكن أن يكون متعدد المناطق ومتعدد اللغات.
تحظى العلامات التجارية التي نعمل معها بشعبية في العديد من البلدان المختلفة ، يخدم بعضها (مثل كندا) المستخدمين في بلدان متعددة ، وقد أضاف هذا مستوى آخر من التعقيد إلى إعدادنا. كيف كنا نخدم المستخدمين اللغة الصحيحة مع تزويدهم أيضًا بتجربة مستخدم مصممة خصيصًا لموقعهم الجغرافي لمنحهم توقعات واقعية للشحن والسعر والضمانات؟
كيف كان شكل إعدادنا السابق؟
في السابق كنا نستخدم إعداد دليل فرعي لجميع المواقع على شبكة MoreNiche ، مع إصدار الولايات المتحدة على https://brandwebsites.com/us/ ، والنسخة الفرنسية على https://brandwebsites.com/fr/ والنسخة الكندية للموقع https://brandwebsites.com/can/.
وبالتالي ، يمكن أن ينتهي الأمر بالمستخدمين الكنديين إما / can / أو / fr / اعتمادًا على اللغة التي بحثوا بها ، حتى أن بعض المستخدمين الكنديين وصلوا إلى / us / site على الرغم من تعيين اللغة على en-US. في الواقع ، كان ما يقرب من نصف المستخدمين الكنديين قد وصلوا إلى موقع الولايات المتحدة وفقدوا العديد من تحسينات الاستخدام المهمة التي أثبتت أنها تفيد بشكل كبير CRO.
بشكل عام ، عندما يتعلق الأمر باستهداف اللغة والبلد بشكل صحيح ، كانت دقتنا في المنطقة 70٪ ، مما يعني أن نسبة معقولة من مستخدمي الموقع لم تكن لديهم تجربة مثالية. كان هذا أداء أضعف بشكل كبير من موقع CrazyBulk الذي كان يستخدم بالفعل إعدادًا متعدد المجالات وسجل دقة بنسبة 90 ٪.
وقد انعكس هذا في كل من معدلات التحويل وتصنيفات العلامات التجارية لكل بلد على حدة. بشكل عام ، يبدو أن Google تفضل إعداد موقع اللغة ، واستفاد المستخدمون من تجربة الخروج المخصصة المحسّنة وجهود CRO الأخرى.
كيف يبدو الحل المثالي؟
إذن ما هو الحل المثالي للإعداد الذي يتطلب استهدافًا يعتمد على الجغرافيا واللغة؟ هذا سؤال صعب ، بدون إجابة كاملة. في الواقع ، فإن مُحسّنات محرّكات البحث تناقش إلى الأبد هذه القضية الخلافية.
تتمثل رؤيتنا طويلة المدى في أن جميع المواقع يجب أن تكون على نطاقات لغة (ccTLDs) أو نطاقات فرعية (على gTLD) حيث لا يتوفر ccTLD لضمان أن التجربة مخصصة للبلد المحدد. يجب أن يكون لدى البلدان التي تتطلب أكثر من لغة إعداد متعدد اللغات ، على سبيل المثال ، https://brandwebsites.ca سيخدم موقع اللغة الإنجليزية الكندية الأساسي بينما https://brandwebsites.ca/fr/ سيخدم أقل قليلاً موقع هام للغة الفرنسية الكندية.
نظرًا لأن الغالبية الواضحة من الزيارات تأتي من الشركات التابعة ، فقد شعرنا أنه من الأهمية بمكان مراعاة CRO أولاً لضمان حصول معظم المستخدمين على تجربة مصممة خصيصًا لموقعهم الجغرافي.
من أجل دعم هذا الإعداد والتأكد من أننا لم نواجه مشكلات مع المحتوى المكرر ، كنا بحاجة إلى التأكد من أننا نستخدم hreflang بشكل صحيح لشرح لمحركات البحث ما كنا نستهدفه بالضبط. بالإضافة إلى ذلك ، احتجنا إلى أن نكون على دراية بالمحتوى المكرر عبر نطاقات متعددة وأن نفكر مليًا في ما إذا كان ينبغي لنا استخدام تحديد العنوان المتعارف عليه أو ما إذا كان من الجيد ، في الواقع ، وجود محتوى مكرر نظرًا لأننا كنا نستهدف مستخدمين مختلفين في بلدان مختلفة. يوجد أدناه مقتطف من نصيحة Google بشأن المحتوى المكرر في حالة مواقع الويب الخاصة باللغة والبلد.
في كثير من الأحيان ، خاصةً عند ارتداء قبعة تحسين محركات البحث (SEO) الخاصة بك ، من السهل جدًا أن تصبح خائفًا بشكل مفرط من وجود محتوى مكرر على موقع الويب الخاص بك. نتج الكثير من هذا الخوف عن الطبيعة الحماسية لتحديث Google Panda الأولي في فبراير 2011. على الرغم من أن المحتوى المكرر كان دائمًا شيئًا يجب وضعه في الاعتبار ، إلا أن أهميته تضاعفت عشرة أضعاف مع تقديم Panda.
بين عشية وضحاها اختفت العديد من المواقع التي احتلت مرتبة جيدة في السابق بسبب مشاكل جودة المحتوى والنسخ التي رفعت علامة ضد الموقع وتميز بشكل فعال النطاق بأكمله على أنه منخفض الجودة. في الواقع ، ما زلت أنصحك بقراءة هذا المنشور القديم على Moz الذي يقدم بعض النصائح التفصيلية حول المحتوى المكرر في عالم ما بعد Panda.
شيء واحد جدير بالملاحظة الآن هو أنه منذ يناير 2016 ، أصبحت Panda فعليًا مجرد جزء آخر من خوارزمية Google الأساسية وهي أكثر دقة في طبيعتها. هذا يعني أنه حتى في أسوأ السيناريوهات ، يجب ألا تجد نطاقك بالكامل معاقباً. ولكن في حالة حدوث ذلك ، يجب أن تكون قادرًا على التعافي بشكل أسرع حيث لن تضطر إلى الانتظار عدة أشهر للتحديث التالي للخوارزمية.
بالإضافة إلى ذلك ، تعلمت Google بسرعة كبيرة أن بعض المحتوى المكرر لا بأس به ، خاصةً عندما يستهدف مستخدمين مختلفين في بلدان مختلفة. مع وضع ذلك في الاعتبار ، قدمت في كانون الأول (ديسمبر) 2011 سمة hreflang حتى تتمكن من الإشارة إلى Google الذي يجب أن يرى أي إصدار من المحتوى الخاص بك عندما يأتي من بحث Google.
لقد اكتملت خطوتنا الأولى الآن
لذلك لم نتمكن من الانتقال مباشرة من الإعداد السابق إلى إعداد أحلامنا لمجموعة متنوعة من الأسباب التقنية والمتعلقة بالموارد. بدلاً من ذلك ، اتخذنا بضع خطوات صغيرة على طول الطريق. في الوقت الحالي بالنسبة لغالبية العلامات التجارية التي نعمل معها ، لدينا المجالات التالية:
https://brandwebsites.com
https://uk.brandwebsites.com
https://au.brandwebsites.com
https://ca.brandwebsites.com
https://fr.brandwebsites.com
https://de.brandwebsites.com
https://brandwebsites.es
https://brandwebsites.gr
كما ترى ، هناك مزيج من النطاقات الفرعية على نطاق .com gTLD و ccTLDs. عندما نحصل على ccTLDs ، سننتقل من النطاق الفرعي إلى ccTLD لتوحيد إعدادنا على ccTLDs ، مع وضع بعض الفوائد المحتملة الأخرى في الاعتبار والتي سنناقشها لاحقًا.
منذ الانتهاء من هذا الترحيل في أوائل عام 2017 ، قمنا بتحديث خرائط المواقع الخاصة بنا وتأكدنا من إعداد المجالات الجديدة بشكل صحيح في أدوات مشرفي المواقع في Google و Bing. لقد أنشأنا أيضًا عمليات إعادة توجيه دائمة (301) حتى لا تضيع حركة المرور في المواقع القديمة ببساطة ، وبالتالي نحتفظ ببعض قيمة مواقع الويب الأخرى التي ترتبط بصفحات في الإعداد القديم.
اعتبارًا من 6 فبراير 2017 ، أصدرنا أيضًا تغييرات على الخادم للطريقة التي نتعامل بها مع إعادة التوجيه من "www." إلى "non-www." ، بالإضافة إلى التغييرات التي طرأت على الطريقة التي نضمن بها تأمين كل حركة المرور وإعادة التوجيه إلى https: //.
إلى جانب هذه التغييرات ، سنقوم أيضًا بتحديث ملف robots.txt لكل موقع للإشارة بوضوح إلى موقع خريطة الموقع الجديد ولمنع المشكلات الشائعة مثل فهرسة صفحات نتائج البحث على بعض مواقع الويب الخاصة بالعلامات التجارية.
ما هي الخيارات الأخرى التي أخذناها في الاعتبار؟
أثناء عملية اتخاذ القرار بشأن الإعداد الجديد ، كان لدينا العديد من الخيارات التي يجب مراعاتها:
المجالات الخاصة بالبلد ، مثل https://brandwebsites.es
النطاقات الفرعية في gTLD ، مثل https://fr.brandwebsites.com
أدلة فرعية على gTLD ، على سبيل المثال https://brandwebsites.com/el/
إعدادنا الحالي ، على سبيل المثال المثال 3 ولكن بدون موقع على مستوى الجذر ، على سبيل المثال https://brandwebsites.com/us/
معلمات URL ، مثل https://brandwebsites.com؟lang=de
لماذا لم نلتزم بالإعداد الحالي؟
على الفور رفضنا الإعداد الحالي ، لأن عدم وجود موقع على مستوى الجذر تسبب في مجموعة متنوعة من المشكلات:
- تمت إعادة توجيه المستخدمين بشكل متكرر من مجال مستوى الجذر إلى دليل فرعي للغة ، مما أدى إلى إبطاء وقت التحميل. نتج هذا عن مزيج من الروابط الداخلية القديمة ، والروابط الخارجية بدون مجلدات اللغة أو قيام المستخدمين بزيارة المجال مباشرة عبر المتصفح.
- تتوقع Google وجود موقع على مستوى الجذر. في الواقع ، كانت التصنيفات ذات العلامات التجارية للموقع تظهر في Google على أنها https://brandwebsites.com على الرغم من عدم وجود صفحة هنا. لم نكن نجعل مهمتها سهلة وقد انعكس ذلك في تصنيفات العلامات التجارية لموقع الولايات المتحدة للعديد من علاماتنا التجارية.
- غالبًا ما يتطلب التحقق من النطاق ظهور علامة على الصفحة الرئيسية ؛ يمكن أن يكون هذا باستخدام إعداد الأدوات الاجتماعية أو أدوات مشرفي المواقع. بينما يمكننا التغلب على البعض من خلال التحقق من صحة استخدام طريقة أخرى مثل إدخالات DNS ، إلا أننا لم نتمكن من التعامل مع البعض الآخر وقد تسبب هذا في بعض المشكلات في التكامل الاجتماعي.
- كنا نخلط بين استهداف اللغة والبلد ونجعل الأمور أكثر صعوبة مما يجب أن تكون عليه للمستخدمين. على سبيل المثال ، تم تعيين الدليل الأسباني الخاص بنا على الإعدادات المحلية es_ES بينما كان الكثير من حركة المرور قادمًا بالفعل من المستخدمين الأسبان في المكسيك (es_MX). كان هذا هو إعداد hreflang = "es_ES" ، بينما قد تكون hreflang = "es" لتغطية جميع البلدان الناطقة باللغة الإسبانية أكثر فاعلية بالنسبة لتحسين محركات البحث. ولكن هذا من شأنه أن يخلق مشاكله الخاصة مع تخصيص عربة التسوق من حيث الأعلام المحلية ومقدمي الشحن.
ببساطة ، كنا بحاجة إلى أن نكون قادرين على تخصيص الموقع حسب موقع المستخدم ، لذلك احتجنا إلى فصل استهداف اللغة والبلد.
مع وضع هذه النقاط الأربع في الاعتبار ، تمكنا على الفور من رفض الإعداد الحالي وإلقاء نظرة على البدائل التي من شأنها أن توفر لنا مستوى المرونة الذي طلبناه.
معلمات URL - لماذا هي فكرة سيئة؟
كان الخيار الواضح التالي الذي لم نرغب حتى في التفكير فيه هو اللغات التي يتم إعدادها كمعلمات لعناوين URL. السبب الواضح لذلك هو أنه لا يمكنك ببساطة الاستهداف الجغرافي للغات المنفصلة في أدوات مشرفي المواقع.
بالإضافة إلى ذلك ، من الصعب للغاية على المستخدمين التعرف على موقع الويب والوصول يدويًا إلى المجال الصحيح ، ولدينا أيضًا مخاوف بشأن الحفاظ على موقع اللغة الذي كان المستخدم موجودًا عليه وإدارة الارتباط الداخلي بشكل عام بشكل فعال.
هناك بعض المواقف التي يمكن أن تعمل فيها معلمات URL ، ولكن هذا يحدث عندما تكون أقل قلقًا بشأن مُحسّنات محرّكات البحث وتقوم بتصفية حركة مرور الصفحة المقصودة يدويًا. على سبيل المثال ، يمكن أن تزدهر مواقع الويب التي يتم تشغيلها بالكامل بواسطة حركة مرور الشركات التابعة التي لا تتوقع الكثير في طريق دعم حركة مرور محركات البحث (SEO) من خلال إعداد لغة معلمة URL.
موازنة الخيارات المتبقية - ما هي الإيجابيات والسلبيات؟
لذلك تُرك لنا ثلاثة خيارات متاحة للنظر فيها:
- المجالات الخاصة بكل بلد
- المجالات الفرعية في gTLD
- أدلة فرعية على gTLD
لكل خيار من هذه الخيارات إيجابياته وسلبياته ، وأود أن أوضح أنه لا يوجد حل مثالي. في حين أن مُحسّنات محرّكات البحث في كل مكان من المرجح أن يكونوا مؤيدين لأحد هذه الخيارات على حساب الخيارات الأخرى ، إلا أنه اختيار ظرفية تمامًا يتطلب مراعاة عوامل متعددة:
- التأثير على موارد فريق التسويق الرقمي الخاص بك
- تكلفة إنشاء الحل وصيانته
- كيف تتأثر تجربة المستخدم
- التأثير المحتمل على محركات البحث
يمكن تقسيم هذه العوامل بشكل أكبر إلى عناصر متعددة يجب أخذها في الاعتبار لكل خيار والجدول أدناه يلخصها. ومع ذلك ، ضع في اعتبارك أن قيمة هذه العناصر لموقعك على الويب أو مؤسستك هي شيء شخصي تمامًا لموقفك.
موارد | كلفة | CRO | SEO |
حان وقت الإعداد | تكلفة الاستضافة | مستوى التخصيص UX | قيود الاستهداف |
حان وقت الصيانة | تكلفة المجال | البساطة للمستخدم | البساطة لمحركات البحث |
سرعة الموقع | سرعة الموقع | ||
دقة الاستهداف | دقة الاستهداف |
تختلف أهمية هذه العناصر الاثني عشر اختلافًا كبيرًا اعتمادًا على موقفك. هذا هو السبب في عدم وجود حل واحد يناسب جميع الحلول لاستهداف اللغة والبلد. بدلاً من ذلك ، إنها دعوة للحكم تتطلب دراسة متأنية لأن قرارك سيؤثر على موقع الويب الخاص بك والقدرة على تغييره لسنوات قادمة.
جانب قيد النظر | المجالات الخاصة بكل بلد | المجالات الفرعية في gTLD | أدلة فرعية على gTLD |
حان وقت الإعداد | عالٍ | متوسط | قليل |
حان وقت الصيانة | زيادة | اساسي | اساسي |
تكلفة الاستضافة | اساسي/ يزداد إذا تمت استضافة كل مجال على حدة. | اساسي/ يزداد إذا تمت استضافة كل مجال فرعي بشكل منفصل. | اساسي |
تكلفة المجال | زيادة ولكن الحد الأدنى | اساسي | اساسي |
مستوى التخصيص UX | تم تحسينه بسبب القدرة على إضفاء الطابع الإقليمي على عملية النظام. | تم تحسينه بسبب القدرة على إضفاء الطابع الإقليمي على عملية النظام. | قليل |
البساطة للمستخدم | من السهل فهم موقع البلد الذي يتواجدون فيه. | لا يتم التعرف على النطاقات الفرعية دائمًا بسهولة ولكنها لا تزال على ما يرام. | ليس مثاليًا ، قد لا يكون المستخدم واضحًا إذا كان المجلد هو البلد أو اللغة. |
سرعة الموقع | تم تحسينه حيث يمكن استضافة نطاقات ccTLD أكبر بشكل منفصل وأكثر محلية للمستخدمين. | تم تحسينه حيث يمكن استضافة نطاقات فرعية أكبر بشكل منفصل وأكثر محلية للمستخدمين. | اساسي |
دقة الاستهداف | في منطقة 90٪ ، بناءً على بياناتنا. | غير معروف ، توقع في مكان ما بين خيارين آخرين. | في منطقة 70٪ ، بناءً على بياناتنا. |
قيود الاستهداف | يمكن للمجال أن يستهدف البلد الذي صمم من أجله فقط. يمكن إنشاء لغات متعددة في نفس البلد باستخدام المجلدات الفرعية. | يمكن استهداف نطاق فرعي لأي بلد تم اختياره. ليس واضحًا مثل ccTLD. يمكن استهداف لغات متعددة بالمجلدات الفرعية. | يعمل بشكل أفضل عندما يكون هناك لغة واحدة فقط من كل لغة في نفس المجال. يبدو وكأنه محتوى مكرر أكثر من ccTLDs والمجالات الفرعية. |
البساطة لمحركات البحث | تنص ccTLD على وجه التحديد على المكان الذي تحاول فيه الترتيب. مما يجعلها سهلة التفسير. مخاوف من أن نشر الروابط بين مجالات متعددة يقلل من السلطة. | يمكنك تعيين المكان الذي تريد أن تحتل مرتبة فيه في Google Search Console. بعض المخاوف بشأن نشر الروابط بين النطاقات الفرعية وما إذا تم التعامل معها بشكل مستقل. | حتى مع ترميز hreflang الصحيح ، فقد رأيت ترتيبًا خاطئًا للصفحة المقصودة للبلد. قوي من موقف الروابط SEO. بعض الجدل حول ما إذا كان الترتيب في البلد يعتمد على الارتباط المحلي. |
استنتاجاتنا
من منظور تحسين محركات البحث (SEO) البحت ، هناك مخاطر مرتبطة بفصل موقع واحد إلى مجالات متعددة ، وأكبر هذه المخاطر هو التأثير غير المعروف للنطاقات المتعددة على الروابط الخلفية. ومع ذلك ، أصبحت Google أكثر دقة في الطريقة التي تتعامل بها مع الروابط ، لذا سيكون من الحكمة استنتاج أنها تولي اهتمامًا أكبر للروابط المحلية المتخصصة عند تحديد التصنيفات في بلد معين.
لكن فوائد CRO للتغيير تفوق المخاطر التي ينطوي عليها أي عمل إضافي لتحسين محركات البحث مطلوب لضمان التصنيف. يتيح استخدام النطاقات لاستهداف بلد ما ، وفصل اللغة واستهداف الموقع الجغرافي ، اتباع نهج أكثر دقة لاستهداف مستخدمي الموقع.
بالإضافة إلى ذلك ، هناك بعض فوائد تحسين محركات البحث في الفصل لأنها تساعد في منع بعض المشكلات التي رأيناها مع ترتيب موقع البلد الخطأ في موقع معين. على سبيل المثال ، لقد رأينا كثيرًا ترتيب الموقع الرئيسي باللغة الإنجليزية الأمريكية بدلاً من الإصدار المترجم ، على سبيل المثال ، المجلد / can / في كندا. سيساعدنا ذلك أيضًا في المستقبل على تسريع الموقع في بلدان معينة ، حيث يُعتبر الطلب كبيرًا بما يكفي ، من خلال استضافة المجالات على خوادم منفصلة خاصة بالموقع.
نفذت العديد من المؤسسات نطاقات منفصلة خاصة بكل بلد بنفس الطريقة التي نطبقها ، بما في ذلك Google و Amazon و Wikipedia (المجالات الفرعية). نظرًا لأن مواقعنا الإلكترونية هي مواقع للتجارة الإلكترونية ، فإنها تجعلها مرشحين مثاليين لهذا المستوى من الفصل الذي يتطلب تنوع اللغة والبلد المصمم خصيصًا للمستخدم. بالإضافة إلى ذلك ، يمكن منع القلق بشأن المحتوى المكرر من خلال ترميز hreflang المناسب والاستجابة لنصائح Google بشأن المحتوى المكرر على المواقع الدولية.
ماذا بعد ذلك؟
لقد أكملنا المرحلة الأولى من التغييرات التي أجريناها على مواقع الويب ونتطلع الآن إلى التحسين:
- ترميز Hreflang: في بعض الأماكن ، يبدو أن المكون الإضافي الذي نستخدمه يتسبب في حدوث مشكلات مع عدم وجود علامات رجوع. ويعني هذا بشكل فعال أنه ليست كل المواقع المتباينة في اللغة والبلد تشير إلى بعضها البعض. يجب أن يتضمن هذا مرجعًا ذاتيًا للصفحة التي ترتبط بها بترميز hreflang.
- قم بتوسيع الاختلافات اللغوية بمجرد أن يكون لدينا تحكم أكبر في hreflang. أحد الأمثلة المثالية على ذلك هو إنشاء نسخة فرنسية-كندية من الموقع ، والتي ستكون دليلًا فرعيًا على المجال الكندي. يمكننا أيضًا أن نتطلع إلى نقل اختلافات لغة غير محددة للموقع الافتراضي إلى brandwebsites.com ولدينا لغات متعددة في المجال ، على سبيل المثال:
- <link rel = ”alternate” href = ”https: // uk.brandwebsites.com/” hreflang = ”en-GB” />
<link rel = ”alternate” href = ”https: // ca.brandwebsites.com/” hreflang = ”en-ca” />
<link rel = ”alternate” href = ”https: // au.brandwebsites.com/” hreflang = ”en-au” />
<link rel = ”alternate” href = ”https: // brandwebsites.com/” hreflang = ”en-US” />
<link rel = ”alternate” href = ”https: // brandwebsites.com/” hreflang = ”en” />
<link rel = ”alternate” href = ”https://brandwebsites.es/” hreflang = ”es-ES” />
<link rel = ”alternate” href = ”https://brandwebsites.com/es/” hreflang = ”es” />
- المزيد من المواقع اللغوية ذات عمليات الدفع المصممة خصيصًا للبلد ، بما في ذلك عوامل الثقة مثل مزودي التوصيل المحليين والأعلام. ابدأ أيضًا في النظر في اختبارات التقسيم الخاصة بكل بلد عند الاقتضاء ، نظرًا لاختلاف سلوك المشتري وتوقعات تجربة المستخدم على مستوى العالم.
في حين أن هذه المعلومات قد لا تساعد الشركات التابعة لنا مباشرة مع مُحسنات محركات البحث الدولية ، يجب أن تمنحك الكثير من الأفكار عندما يتعلق الأمر بإنشاء موقع الويب الخاص بك متعدد اللغات.