SEO في Salesforce Commerce Cloud

دليل يشرح كيفية عمل SEO في Salesforce Commerce Cloud ‏(B2C Commerce أو SFCC، المعروفة سابقًا باسم Demandware): الركائز الأصلية القوية التي يمكن ضبطها في Business Manager، والأجزاء التي يجب بناؤها يدويًا مثل hreflang وعناوين التنقل متعدد الأوجه وschema وقابلية زحف PWA Kit وStorefront Next.

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

توفر Salesforce Commerce Cloud ركائز SEO أصلية قوية، منها ملف robots.txt قابل للتعديل لكل موقع، وخرائط XML تلقائية، وقواعد لوسوم meta، ونموذج رئيسي وتنويعات يتوافق مع ProductGroup. لكن نجاحها يتطلب ضبط hreflang وعناوين المرشحات والبيانات المنظمة وقابلية زحف الواجهات المنفصلة عمدًا؛ فالمنصة ليست القيد، بل عدم الإلمام بها.

الخلاصة — توفر SFCC، أي B2C Commerce المعروفة سابقًا باسم Demandware، ركائز SEO أصلية قوية: ملف robots.txt لكل موقع يُعدّل في Business Manager، وخرائط XML تُنشأ تلقائيًا كمهمة مجدولة، وMeta Tag Rules قائمة على القواعد لعناوين الكتالوج وأوصافه، ونموذج منتج رئيسي وتنويعات مصمم لاستخدام canonical ويتطابق تقريبًا مع مخطط Google ‏ProductGroup/hasVariant/isVariantOf. أما العمل المتبقي فهو ما يتوسع مع المتجر: hreflang، إذ لا توجد ميزة مخصصة في B2C بل خيار “Include Alternate URLs” في خريطة الموقع أو وسوم <link> مخصصة؛ وعناوين المرشحات، التي تحتاج إلى تطوير مخصص؛ والبيانات المنظمة، وهي مهمة قوالب لا مفتاح إعداد؛ وقابلية زحف PWA Kit أو إطار Storefront Next الأحدث، حيث يلزم SSR لكنه لا يكفي، ويجب الاختبار باستخدام ?__server_only في PWA Kit والتحقق من الآلية المكافئة في Storefront Next. وأكبر قرار معماري هو ما إذا كانت العلامة متعددة المناطق ستستخدم موقعًا واحدًا بعدة إعدادات محلية أم مواقع متعددة؛ فهذا يحدد عدد مجموعات إعدادات SEO الكاملة التي يجب إبقاؤها متزامنة.

Evidence for this claim Salesforce B2C Commerce provides sitemap generation that merchants configure and run for storefront URLs. Scope: Salesforce B2C Commerce; scheduling and content selection require configuration. Confidence: high · Verified: Salesforce Developers: Create a sitemap Evidence for this claim Salesforce documents server-side rendering and crawler considerations for PWA Kit storefronts. Scope: Salesforce PWA Kit; SSR alone does not guarantee indexing or ranking. Confidence: high · Verified: Salesforce Developers: PWA best practices

الإطار العام: أدوات أصلية قوية تتطلب معرفة عميقة بالمنصة

معظم المحتوى عن SEO في SFCC إما تسويق سطحي لوكالات أو وثائق مطورين بلا سياق لتحسين محركات البحث. والحقيقة بينهما: تتيح SFCC أدوات SEO أصلية قابلة للضبط من لوحة الإدارة أكثر من معظم المنصات المنافسة، لكن لا يعمل شيء جيدًا من دون إعداد مقصود، وقد تضر بك عدة إعدادات افتراضية إن تركتها كما هي. صنّف كل مهمة إلى «ركيزة أصلية» أو «شيء عليك بناؤه»، وستصبح المنصة أوضح.

هناك أمران يجب فهمهما قبل أي شيء آخر:

  1. يعيش SEO في Business Manager. مركزه هو Merchant Tools ← الموقع ← SEO، ويتوزع على شاشات Canonical URL tags وURL Redirects وSitemaps وRobots وMeta Tag Rules وURL Rules/Aliases، ولكل شاشة قواعدها.
  2. يشكّل نموذج المنتج الرئيسي والتنويعات كل شيء. يضم المنتج الرئيسي عدة منتجات تنويع حسب اللون والمقاس. وهذا هو محور القرار المركزي في SEO، ويتطابق مع الطريقة التي تريد Google بها ترميز التنويعات.
  3. حدد بنية واجهة المتجر قبل تحديد الإصلاح. يشمل Salesforce Commerce Cloud أربعة أجيال على الأقل تختلف في سلوكها مع SEO: بنية SiteGenesis القديمة، وSFRA الحالية، وPWA Kit المنفصلة الراسخة، وإطار React الأحدث Storefront Next ضمن دورة إصدار B2C Commerce لعام 2026. تختلف مسارات الإدارة وسلوك cartridges وآليات التصيير بينها، فلا ينتقل إصلاح تحقق في واحدة تلقائيًا إلى الأخرى. تنطبق شاشات Business Manager في هذه المقالة عمومًا على SFRA وSiteGenesis، أما آليات PWA Kit اللاحقة فمقيدة بالسياقات التي تنطبق عليها.

الركائز الأصلية: ملف robots.txt قابل للتعديل لكل موقع، وخرائط XML مجدولة تُنشأ تلقائيًا مع hreflang وتواريخ آخر تعديل اختياريًا، وURL Rules مع Hostname Aliases لعناوين نظيفة تراعي الإعدادات المحلية، ومنتجات تنويع مصممة لاستخدام canonical، وMeta Tag Rules قائمة على القواعد، وعمليات إعادة توجيه دائمة تلقائية لتغييرات العناوين داخل Business Manager، وSSR للتحميل الأول في PWA Kit.

ما عليك بناؤه: hreflang، وعناوين التنقل متعدد الأوجه أو المرشحات، والبيانات المنظمة، ومعالجة robots.txt لعدة إعدادات محلية، وقوالب H1، وإدارة جميع وسوم الصفحة في البنية المنفصلة.

القرار المعماري الذي يشكل كل شيء: المواقع أم الإعدادات المحلية؟

قبل لمس أي شاشة SEO، احسم هذا: هل تُمثّل العلامة متعددة المناطق بموقع واحد وعدة إعدادات محلية أم بعدة مواقع، لكل إعداد محلي أو منطقة موقع؟ تُبنى واجهات المتاجر متعددة المناطق في SFCC عادةً كمواقع مستقلة في Business Manager. وهذا مهم لأن لكل موقع مجموعة كاملة مستقلة من إعدادات SEO: مهمة خريطة موقع وملف robots.txt وMeta Tag Rules وURL Rules خاصة به. عشرة مواقع تعني عشر نسخ من كل شيء يجب إبقاؤها متزامنة يدويًا. سمّ هذا القرار صراحةً مبكرًا، لأنه يضاعف نطاق كل قسم لاحق بصمت.

بنية عناوين URL: ‏URL Rules مقابل Hostname Aliases

توفر SFCC مسارين للإعداد، ويعتمد المسار المناسب على مدى تعقيد إعداداتك المحلية:

  • URL Rules ‏(Merchant Tools ← الموقع ← SEO ← URL Rules) تربط الإعداد المحلي ومقاطع مسار الفئة والمنتج بنمط. وهي أبسط وأقل مرونة؛ إذ تختار أسماء مضيف بديلة أو معاملات URL أو مسارات لتوجيه الإعدادات المحلية.
  • Hostname Aliases ‏(Merchant Tools ← الموقع ← SEO ← Aliases) ملف أسماء مستعارة بصيغة JSON يوفر إمكانات أوسع، منها نهج مختلط يجمع مثلًا أسماء مضيف على نمط ccTLD لبعض الإعدادات المحلية ومسارات مجلدات فرعية لإعدادات أخرى داخل الموقع نفسه. ويتطلب التوجيه المختلط استخدام ملف الأسماء المستعارة.

الآليات الجديرة بالمعرفة:

  • افرض الأحرف الصغيرة. توصي إرشادات إعداد عناوين URL في SFCC باختيار Lower Case حتى لا تُنشئ عناوين متعددة تختلف فقط في حالة الأحرف.
  • استخدم الشرطات بدل المسافات. يمكن ترميز المسافة إلى (%20) أو استبدالها بعلامة جمع أو شرطة سفلية أو شرطة أو نقطة. وتوضح إرشادات Salesforce أن محركات البحث تعامل الشرطات فواصل، والشرطات السفلية أدوات وصل؛ لذا فالشرطة هي الخيار الأنظف. وتوصي NOVOS بالشيء نفسه بدل %20 الافتراضي.
  • category مقابل category-path. استخدم category للمواقع التي يزيد عمقها على فئتين أو ثلاث، لكن استخدم category-path عند تكرار أسماء الفئات تحت آباء مختلفين لإزالة الالتباس.
  • تُضاف معرّفات المنتجات تلقائيًا. لا تضف معرّف المنتج إلى القاعدة؛ إذ تلحقه B2C Commerce تلقائيًا دائمًا مع الامتداد .html. ولا يمكن إزالة .html من دون تطوير مخصص.
  • اربط المنتجات بالنطاق لا بمسار فئة. توصي NOVOS بذلك لتقليل التكرار والتعقيد، لأن إسناد المنتج إلى عدة فئات يجعل مقطع URL القائم على الفئة غير مستقر.
  • قواعد عامة لنظافة URL من إرشادات Salesforce: اجعل العناوين مقروءة وقصيرة، وقلل المجلدات، وتجنب المعاملات، وأدخل الكلمات المفتاحية، ولا تضع مؤشرًا لنوع الصفحة أو الامتداد الخاص sc.html أو كلمة demandware في URL.

المأزق التقليدي: صفحات رئيسية مكررة تنتج من مساري Default-Start وHome-Show غير المعيّنين، فتحل إلى نسخ www ومن دون www. عيّنهما صراحةً وإلا أنشأت أسماء المضيف مواقع مكررة. وثمة تفصيل آخر في ملف الأسماء المستعارة: يجب أن يعلن الملف الإصدار 1 وإلا تجاهله النظام بالكامل.

مقارنةً بمنصة مثل BigCommerce، التي توفر بُنى URL جاهزة وتزيل البادئات من قائمة، أو Shopify، التي تفرض /products/ و/collections/، تمنح SFCC طبقة URL أكثر قابلية للضبط بكثير، لكنها تتطلب جهدًا أكبر لضبطها.

خرائط مواقع XML

إنشاء خريطة الموقع مهمة مجدولة في Business Manager، لا ملفًا ثابتًا تصونه. تصل إليها عبر App Launcher ← Merchant Tools ← الموقع ← SEO ← Sitemaps، وتضبط جدول المهمة من تبويب Job. توصي Salesforce بتشغيلها في أوقات انخفاض الزيارات، مثل الصباح الباكر، لتجنب ارتفاع استهلاك CPU والذاكرة، وبعد نسخ البيانات اليومي من بيئة staging.

ثلاثة أمور توقع الناس في الخطأ:

  • اضبط كل نوع من البيئات على حدة. لا يمكن نسخ إعدادات خريطة الموقع بين Staging وProduction أو Development؛ بل تضبط منفردة في كل بيئة، خلافًا لمعظم تفضيلات الموقع.
  • changefreq وpriority بلا قيمة. أكدت Google أنها تتجاهلهما في خرائط المواقع، فلا تهدر جهد التطوير في ضبطهما. حافظ بدلًا من ذلك على دقة lastmod؛ فهو يضاف تلقائيًا إلى الخريطة المولدة ويقدم إشارة حقيقية لما تجب إعادة زحفه.
  • يُضاف hreflang بخيار واحد. يمكنك تضمينه بتحديد “Include Alternate URLs”، فيضيف شروح hreflang داخل خرائط الموقع القياسية. لكن كثرة الإعدادات المحلية قد تتجاوز حد الروابط في الملف، وعندها تحتاج إلى خرائط مخصصة يبنيها مهندس حلول.

للواجهات المنفصلة آلية أخرى. يوضح دليل Salesforce ‏“Improve SEO with a Sitemap” لمتاجر PWA Kit أن خرائط المواقع “provide search crawlers with instructions on the pages to index and the site hierarchy, which can improve your SEO rankings.” (ترجمة) «تزوّد زواحف البحث بتعليمات عن الصفحات المطلوب فهرستها وبنية الموقع، ما قد يحسن ترتيبك في البحث». إذا ضُبطت المسارات في Business Manager فأنشئ الخريطة هناك؛ وإلا فارفع واحدة عبر نقطة SCAPI ‏uploadCustomSitemapAndTriggerSitemapGeneration. يتطلب الربط نطاقًا مخصصًا، سواء CDN مدمجًا أو نطاقًا فرعيًا مثل seo.example.com، واسم مضيف مستعارًا مطابقًا، وإتاحة الخريطة عند example.com/sitemap_index.xml. وفي PWA Kit أضف app.get('/sitemap_index.xml', runtime.serveStaticFile('static/sitemap_index.xml')) إلى ssr.js وأتح الملف عبر ssrShared في إعداد التطبيق.

ملف Robots.txt

توجد آليتان مختلفتان، والخلط بينهما يسبب أخطاء نشر فعلية:

  1. تفضيل الموقع في Business Manager، وهو المسار الافتراضي الموصى به. يتيح App Launcher ← Merchant Tools ← الموقع ← SEO ← Robots كتابة robots.txt لكل موقع حتى 50 000 حرف. يُخزن كتفضيل للموقع ويمكن نسخه بين البيئات.
  2. ملف ثابت على مستوى cartridge، لواجهات المتاجر المخصصة أو SFRA. يوضع robots.txt في cartridge/static/default داخل cartridge مخصص ويُدار عبر UX Studio. ولا ينتقل بين البيئات إلا عبر نسخ الشيفرة، لأن المجلد الثابت خاص بـcartridge لا بالموقع.

تفصيلان مهمان:

  • إبطال ذاكرة التخزين المؤقت. عند تفعيل التخزين المؤقت، يجب إبطال ذاكرة المحتوى الثابت حتى يُقدّم ملف robots.txt الجديد على مستوى cartridge.
  • نطاق robots هو النطاق لا المجلد الفرعي. إذا شغلت عدة إعدادات محلية في مجلدات فرعية، فيجب أن يلبي ملف robots.txt واحد عند جذر النطاق احتياجاتها كلها؛ فخطط للقواعد وفق ذلك.

فلسفة الممارسين التي أوافقها: اجعل robots.txt في الحد الأدنى. استخدم canonical وnoindex للتحكم في ما يُعرض في النتائج؛ أما robots.txt فيتحكم في الزحف لا الفهرسة، والإفراط في الاعتماد عليه هو النمط المضاد الحقيقي. أبق بيئات التطوير وstaging غير قابلة للزحف عبر إعداد cartridge المنشور، واضبط production عمدًا. (ترد الآليات العامة في الزحف وتحديد canonical.)

عناوين canonical ونموذج المنتج الرئيسي والتنويعات — القسم الفارق

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

In the SFCC pattern described here, child variation URLs point `rel=canonical` to the master PDP, while ProductGroup connects the structured-data family.

The SFCC master product is the canonical product detail page. Each color, size, or other child variation URL points rel canonical to the master URL. In structured data, the master maps to ProductGroup and child Product entities connect through hasVariant and isVariantOf. Verify the public storefront output.

تمثل SFCC تنويعات اللون والمقاس لمنتج ما في منتج رئيسي (أساسي) واحد يضم منتجات تنويع فرعية. وتوصي Salesforce بأن تشير عناوين منتجات التنويع عبر canonical إلى المنتج الرئيسي للحفاظ على الترتيب أو تحسينه؛ أي توجيه rel="canonical" في كل صفحة منتج خاصة بلون أو مقاس إلى المنتج الأساسي، فتتجمع إشارات الترتيب في URL واحد.

انظر الآن إلى توصية Google للحالة نفسها، “one product, many variations” (الترجمة العربية): «منتج واحد وتنويعات متعددة». توصي إرشاداتها بشأن تنويعات المنتجات بأن “use the ProductGroup class with associated properties variesBy, hasVariant, and productGroupID to group such variants together.” (ترجمة) «تستخدم فئة ProductGroup مع الخصائص المرتبطة variesBy وhasVariant وproductGroupID لجمع هذه التنويعات». وهذا يطابق مفهوميًا نموذج المنتج الرئيسي والتنويعات في SFCC:

  • المنتج الرئيسي هو ProductGroup لدى Google.
  • منتجات التنويع هي عناصر hasVariant، أو يستخدم كل Product في النمط «المنفصل» isVariantOf للإشارة إلى @id الخاص بالمجموعة.
  • توثق Google نمطًا متداخلًا (ProductGroup.hasVariant) تصفه بأنه “the most compact and natural representation of a product group” (ترجمة) «أكثر تمثيل موجز وطبيعي لمجموعة منتجات»، ونمطًا منفصلًا (Product.isVariantOf) قد “might be easier for some content management systems (CMSes) to generate” (ترجمة) «يكون أسهل في التوليد لبعض أنظمة إدارة المحتوى». ويلائم النمط المنفصل طريقة تصيير SFCC لمنتجات التنويع عبر صفحات منتجات مستقلة.

بالنسبة إلى محدد تنويعات في صفحة واحدة، تقول Google بالإبقاء على “only one distinct canonical URL for the overall ProductGroup (ترجمة) «عنوان canonical مميز واحد فقط لـProductGroup كله»، وهي بالضبط قاعدة «التنويع ← المنتج الرئيسي» التي توصي بها SFCC.

اجعل الإشارات متفقة، لأن Google تؤكد وجوب اتساق إشارات تحديد canonical. تصف rel="canonical" بأنه “a strong signal that the specified URL should become canonical,” (الترجمة العربية): «إشارة قوية إلى أن يصبح URL المحدد هو canonical»، وإدراج الخريطة بأنه “a weak signal,” (الترجمة العربية): «إشارة ضعيفة»، وتقول إن “these methods can stack and thus become more effective when combined.” (الترجمة العربية): «هذه الأساليب يمكن أن تتراكم فتزداد فاعلية عند جمعها». لكن لا تناقض نفسك؛ إذ تحذر Google: “Don’t specify different URLs as canonical for the same page using different canonicalization techniques (for example, don’t specify one URL in a sitemap, but a different URL for that same page using rel="canonical").” (الترجمة العربية): «لا تحدد عناوين URL مختلفة بوصفها canonical للصفحة نفسها باستخدام أساليب مختلفة». وفي SFCC يجب أن تسمي إشارات rel="canonical" لمنتج التنويع وخريطة الموقع وhreflang والروابط الداخلية URL الرئيسي نفسه. وتقول أيضًا “when linking within your site, link to the canonical URL rather than a duplicate URL” (الترجمة العربية): «عند الربط داخل موقعك، اربط بـURL المعتمد بدل URL مكرر»؛ لذا اربط التنقل الداخلي بالمنتج الرئيسي، لا بعناوين تنويعات محددة.

(ترد التفاصيل العامة لمخطط التنويعات في SEO لتنويعات المنتجات، وآليات canonical في تحديد canonical.)

Meta Tag Rules

لعناوين الصفحات وأوصافها مساران للتنفيذ: إدخال يدوي لكل عنصر (Category/Product ← حقلا Page Title وPage Description)، أو توليد ديناميكي قائم على القواعد عبر Meta Tag Rules ‏(Merchant Tools ← الموقع ← SEO ← Meta Tags)، التي تطبق صيغًا على أنواع الصفحات.

  • قاعدة ديناميكية أساسية: عنوان فئة مثل ${Category.Name} | Example Brand.
  • تجاوز هجين مع قيمة احتياطية: تتيح ${IF Category.pageTitle THEN Category.pageTitle ELSE Category.Name} للتجار تجاوز القاعدة في صفحات محددة مع بقائها الإعداد الافتراضي للكتالوج. هذا هو النمط المناسب للتوحيد؛ فالقواعد قابلة للتوسع، وأي استثناء يستخدم هذه الصيغة الهجينة أو يرث القاعدة العامة.
  • ترجم كلمات الربط. في القواعد المحلية، ترجم كلمات الربط المحيطة بالفاصل | واضبطها على مستوى اللغة أو اللغة والبلد.
  • H1 قيد قائم. لا توجد صيغة قياسية في Meta Tag Rules لإنشاء H1 ديناميكيًا كما في العناوين والأوصاف؛ ويتطلب ذلك تطويرًا مخصصًا.

عمليات إعادة التوجيه

تجمع SFCC بين سلوك إعادة توجيه أصلي وتلقائي وأدوات يدوية:

  • تُفعّل عمليات 301 تلقائية عند تجاوز URL فئة أو منتج داخل Business Manager، كما تصحح SFCC عناوين PDP المكتوبة خطأ ما دام معرّف المنتج الأساسي سليمًا.
  • ثلاث أدوات يدوية: URL Redirects للربط واحدًا بواحد، وStatic Mappings لأنماط العناوين القديمة التي تعيد التوجيه إلى موارد ثابتة، وDynamic Mappings للأنماط المعقدة القائمة على أحرف البدل.
  • رموز الحالة: استخدم 301 للدائم، أو 308 عند تنفيذه بتطوير مخصص، و307 للمؤقت. (ترد الخلفية في دليلي Ahrefs عن 11 نوعًا من إعادة التوجيه و301 مقابل 302.)
  • وجّه إلى معرّفات العناصر لا إلى مسارات ثابتة. توصي NOVOS بالتوجيه إلى أنواع العناصر ومعرّفاتها بدل سلاسل URL حرفية لتجنب الأخطاء وحلقات إعادة التوجيه عند تغير عنوان الوجهة لاحقًا.

قاعدة الأولوية مهمة، وهي اقتباس مباشر من وثائق المطورين: “If there’s a conflict between your URL redirects and your URL rules for SEO, the URL redirects take precedence.” (ترجمة) «إذا تعارضت عمليات إعادة توجيه URL مع قواعد URL الخاصة بـSEO، فلعمليات إعادة التوجيه الأولوية».

في سياق الترحيل: عند إعادة إطلاق SFRA، تكون استراتيجية إعادة التوجيه أهم مكوّن منفرد في SEO للحفاظ على الترتيب؛ وتقدر ممارسة Salesforce لدى Acxiom أنها تستحوذ على 60–70% من جهد SEO عند الإطلاق. وهذا يتسق مع الدرس الأعم بأن نجاح ترحيل الموقع يتطلب أكثر من قائمة تحقق.

البيانات المنظمة وschema — سمّ الفجوة بصدق

هذه حقيقة تتجاوزها معظم المقالات: لا توفر SFCC مفتاحًا أصليًا في Business Manager «لتفعيل schema للمنتجات» يماثل Meta Tag Rules أو معالجة canonical. وبخلاف BigCommerce، الذي يتضمن قالب Cornerstone فيه مخطط منتجات JSON-LD جاهزًا، تقع schema في SFCC ضمن مسؤولية القالب والمطور. تتضمن واجهة SFRA المرجعية بعض مخططات المنتجات وفتات التنقل في شيفرة القالب، لكنها منفذة برمجيًا وليست ميزة إدارية. عامل schema كمهمة بناء لا مربع اختيار، واستهدف نمط ProductGroup والتنويعات الوارد في قسم canonical، لأن JSON-LD هو التنسيق الذي توصي به Google حين يسمح الإعداد.

ثمة قيد في التصيير ينبغي مراعاته، ولا سيما في البنى المنفصلة: توصي Google بوجود البيانات المنظمة في HTML المصيّر من الخادم بدل حقنها أثناء hydration لدى العميل فقط. وفي متجر PWA Kit يعني ذلك ضرورة وجود JSON-LD في خرج SSR؛ راجع قسم الواجهات المنفصلة.

Hreflang وبنية المواقع والإعدادات المحلية المتعددة

ميّز B2B من B2C أولًا. ميزة Salesforce المخصصة والواضحة لـhreflang والمسماة “Alternate Language Links” تخص B2B Commerce، ولا توجد كشاشة مخصصة في B2C Commerce. تخلط نتائج البحث وبعض مدونات الوكالات بين المنصتين. وفي B2C Commerce يعمل hreflang عبر خيار “Include Alternate URLs” في خريطة الموقع، لا عبر شاشة إدارية مخصصة للغات البديلة.

لذلك يوجد مساران واقعيان للتنفيذ:

  1. Hreflang مضمّن في خريطة الموقع عبر “Include Alternate URLs”؛ وهو بسيط لكنه قد يتجاوز حد حجم ملف خريطة الموقع عند التوسع.
  2. وسوم <link rel="alternate" hreflang="x"> مخصصة تُخرج مباشرةً في <head>؛ وتصبح ضرورية عندما تزيد تركيبات الإعدادات المحلية وعناوين URL على ما يستوعبه نهج الخريطة.

تبقى قواعد hreflang القياسية واجبة. توضح إرشادات Google للنسخ المحلية أن كل صفحة يجب أن تتضمن مجموعة كاملة من عناصر <link> في <head>، عنصرًا لكل نسخة بما فيها الصفحة نفسها، وأن تكون المجموعة متطابقة في كل نسخة، مع x-default احتياطي للغات غير المطابقة. وتوثق Google إمكان إعلان hreflang إما بعناصر <link> في <head> أو عبر خريطة XML؛ وهما مسارا SFCC نفسيهما.

ملاحظة عن Bing: لم يدعم Bing تاريخيًا hreflang بالطريقة نفسها التي تدعمه بها Google، واعتمد بدلًا منه إشارة HTML ‏content-language. لذلك قد لا يمنحه موقع SFCC الذي ينفذ hreflang عبر خيار خريطة الموقع وحده إشارة اللغة التي يريدها. (تحقق من سلوك Bing الحالي قبل اعتماد ذلك قاعدة صارمة؛ فقد وردت تقارير متضاربة عن دعمه المعلن.)

كلما تعمقت بنية المواقع المتعددة تضاعف الأثر؛ فتذكر أن لكل موقع مهمة خريطة وملف robots.txt خاصين به، لذا فإن إضافة إعداد محلي كموقع جديد تعني إضافة مجموعة كاملة من إعدادات SEO، لا مجرد ملف لغة. (ترد الآليات الدولية في مجموعة hreflang.)

التنقل متعدد الأوجه وعناوين المرشحات

لا تنشئ SFCC تلقائيًا عناوين مرشحات نظيفة وملائمة لـSEO، ويتطلب ضبط عناوين التنقل متعدد الأوجه وفهرستها تطويرًا مخصصًا. ولا يوجد سلوك أصلي لـcanonical أو noindex لتركيبات المرشحات، لذا عليك بناء إطار القرار. وفيما يلي تصنيف عملي يمكن تكييفه مع آليات المرشحات في SFCC؛ وهو النمط نفسه المناسب لـBigCommerce وغيرها لأن المشكلة الأساسية، أي الانفجار التركيبي لعناوين المرشحات القابلة للزحف، لا تعتمد على المنصة:

نوع الصفحةCanonicalتوجيه Robots
الفئة الرئيسية (PLP)ذاتيindex
مرشح مرتفع الطلب وله قيمة بحثية حقيقيةذاتيindex
مرشح للتنقل فقطالفئة الرئيسيةnoindex,follow
ترتيب النتائج فقطالفئة الرئيسيةnoindex,follow
الصفحات المرقمة (2 فما بعدها)ذاتي، أي URL الخاص بهاindex
صفحة منتج تنويعالمنتج الرئيسيcanonical إلى الرئيسي

مبدآن لا يتغيران في SFCC:

  • يحظر robots.txt الزحف لا الفهرسة. قد يُفهرس URL محظور إذا ارتبط به شيء، ولا تستطيع Google قراءة canonical أو noindex لأنها لم تجلب الصفحة. اربط قواعد المعاملات بإشارات canonical وnoindex داخل الصفحة.
  • لا تضع noindex على الصفحات المرقمة. توصي إرشادات Google للتجارة الإلكترونية بمنح كل صفحة مرقمة URL canonical خاصًا بها، لا بدمج الصفحة الثانية وما بعدها في الأولى. موضع noindex هو تنويعات المرشحات والترتيب، لا الصفحات المرقمة.

(ترد المعالجة العامة المستقلة عن المنصة في قسم التنقل متعدد الأوجه ضمن مجموعة SEO للتجارة الإلكترونية.)

تحسين محركات البحث للواجهات المنفصلة باستخدام PWA Kit (وخليفته Storefront Next)

إذا كانت واجهة متجرك منفصلة، فهي تعمل باستخدام PWA Kit، إطار Salesforce الراسخ المبني على React ‏(ويعتمد SCAPI ويُنشر على Managed Runtime)، أو باستخدام إطار Storefront Next الأحدث منذ دورة إصدار B2C Commerce لعام 2026. وتدور قصة SEO هنا بالكامل تقريبًا حول قابلية الزحف؛ فهذا هو الإطار الذي تعرض به وثائق Salesforce نفسها الموضوع.

تحقق من النطاق قبل تطبيق الآليات أدناه. هذا القسم، بما فيه اختبار ?__server_only ومسار الملف app/ssr.js وتوصيلات SSR وhydration المحددة، مكتوب لـPWA Kit التقليدي أو Composable Storefront، وقد جرى التحقق منه مباشرةً مقابل وثائق مطوري PWA Kit لدى Salesforce. أما Storefront Next فهو بنية مختلفة: يستخدم React 19 مع توجيه قائم على الملفات في React Router 7، مقابل React Router 5 في PWA Kit، ويتبع نموذج جلب البيانات ثم التصيير. وهو يعمل أيضًا على Managed Runtime، لكن بتدفق خاص به يبدأ بـSSR متدفق ثم hydration. وتعدّه Salesforce مختلفًا بما يكفي لتوفير دليل مستقل بعنوان “Migrate from PWA Kit to Storefront Next” (أي «الترحيل من PWA Kit إلى Storefront Next»). إذا كان متجرك يستخدم Storefront Next، فلا تفترض أن ?__server_only أو مسارات الملفات أدناه تنتقل إليه بلا تغيير؛ تحقق من خطوة فحص التصيير على الخادم المكافئة في وثائق Storefront Next الخاصة قبل اعتبار هذا القسم مرجعًا حرفيًا لتلك البنية. مبدأ SEO الأساسي واحد في الحالتين: يجب أن يظهر المحتوى المهم للزواحف، مثل العنوان والوصف وcanonical والنص الأساسي والسعر والتوفر وJSON-LD، في HTML المصيّر أو المتدفق من الخادم، لا أن يؤجل إلى hydration لدى العميل وحده.

كيف يعمل التصيير. يستخدم PWA Kit في التحميل الأول للصفحة التصيير من جانب الخادم: “For the critical first page load, we use server-side rendering because it offers a powerful tool for optimizing performance: caching.” (ترجمة) «في أول تحميل حاسم للصفحة، نستخدم التصيير من جانب الخادم لأنه يوفر أداة قوية لتحسين الأداء، وهي التخزين المؤقت». يعمل SSR عبر تطبيق Express في (app/ssr.js)، كما تقول الوثائق: “Managed Runtime’s CDN cache can store a previously rendered version of a page and serve it to the user in an instant.” (ترجمة) «تستطيع ذاكرة CDN المؤقتة في Managed Runtime حفظ نسخة سبق تصييرها من الصفحة وتقديمها للمستخدم فورًا». وهذا جيد للزواحف حتى الآن، لأن التحميل الأول HTML حقيقي.

حدّ hydration هو موضع خطر SEO. بعد التحميل الأول، “rendering duties are transferred from the server side to the client side through a process called hydration,” (ترجمة) «تنتقل مهام التصيير من جانب الخادم إلى جانب العميل عبر عملية تسمى hydration»، وعندها “your React app starts running in the user’s browser.” (ترجمة) «يبدأ تطبيق React بالعمل في متصفح المستخدم». يجب أن تكون شيفرتك متماثلة التشغيل وآمنة على الجانبين؛ فـwindow.location خاص بالعميل، وreq وres خاصان بالخادم. والأهم أن Salesforce تقول إن بعض المحتوى يكون لدى العميل وحده عمدًا: “Some content, such as personalized or frequently changing content, must only be rendered on the client side to get the best possible performance.” (ترجمة) «يجب تصيير بعض المحتوى، مثل المحتوى المخصص أو سريع التغير، على جانب العميل وحده لتحقيق أفضل أداء ممكن». وهنا يقع التعارض الدقيق مع SEO: يجب ألا يوضع أي محتوى مهم للزواحف، كالعنوان والوصف وcanonical والمحتوى الأساسي والسعر والتوفر وJSON-LD، في تلك الفئة الخاصة بالعميل، وإلا فقد لا تراه الزواحف أصلًا.

كيفية التحقق، بالطريقة التي توثقها Salesforce نفسها. تطلب قائمة أفضل ممارسات PWA Kit اختبار صفحات الدخول، مثل الرئيسية وPLP وPDP، بإضافة ?__server_only، ما يتيح لك “confirm that your server-rendered pages have enough data for crawlers and that the layout shift between server and client is small (ideally non-existent). This can help to improve your SEO ranking.” (ترجمة) «التأكد من أن الصفحات المصيّرة على الخادم تتضمن بيانات كافية للزواحف، وأن انزياح التخطيط بين الخادم والعميل ضئيل، ومن الأفضل أن يكون معدومًا؛ وقد يساعد ذلك في تحسين ترتيبك في البحث». هذا أنفع اختبار منفرد لـSEO في واجهات SFCC المنفصلة، ولا يتطلب أن تكون مطورًا: افتح URL مع ?__server_only وتأكد من وجود العنوان والوصف وcanonical والنص الرئيسي ومخطط المنتج كلها.

أبق منطق URL متزامنًا عبر SCAPI. تتيح نقطة getUrlMapping للواجهة المنفصلة “support localized, user-friendly URLs based on URL rules and URL redirects set up in Business Manager” (ترجمة) «دعم عناوين URL محلية سهلة الاستخدام استنادًا إلى قواعد URL وعمليات إعادة التوجيه المضبوطة في Business Manager». فهي تحل عناوين المنتجات والفئات، بما فيها تحسينات الفئات، وأصول المحتوى، وتعود إلى الإعداد المحلي الافتراضي للموقع إن لم يُمرر إعداد. وتوصي Salesforce بمدد TTL طويلة لها، والافتراضي 12 ساعة. والنتيجة أنك لا تدير نظام URL موازيًا للواجهة المنفصلة؛ بل تقودها URL Rules وRedirects نفسها التي ضبطتها في Business Manager.

الفجوة التي يجب سدها. تتعامل وثائق PWA Kit لدى Salesforce مع «SEO» على أنه مشكلة SSR وقابلية زحف في المقام الأول، ولا تكاد تتناول وسوم meta أو canonical أو hreflang أو schema بوصفها مسؤوليات PWA Kit، بينما تخصص لخرائط المواقع وثيقة منفصلة. يقع عمل وسوم الصفحة هذا على طبقة إدارة رأس الصفحة لدى فريق التنفيذ، سواء استخدم React Helmet أو بديلًا مكافئًا. وإذا لم يتولّه أحد، فقد يخرج متجر PWA Kit قابل للزحف تقنيًا لكنه يفتقد العناوين ووسوم canonical وschema. (ترد الآليات العامة للواجهات المنفصلة في JavaScript SEO ومقال SEO لنظام إدارة محتوى منفصل.)

مقارنة SFCC بالمنصات الأخرى — النسخة الصريحة

مقارنةً بـShopify وBigCommerce وMagento وWooCommerce وPrestaShop، تقع SFCC في الطرف المؤسسي. فهي تمنح أعمق قابلية أصلية لضبط SEO بين المنصات المستضافة، ومنها robots.txt قابل للتعديل لكل موقع، وURL Rules مع Aliases، وcanonical مصمم للتنويعات، وMeta Tag Rules قائمة على القواعد، لكنها تتطلب أكبر قدر من الإلمام بالمنصة للاستفادة منها. ففي حين يفرض Shopify بادئات URL ويضع robots.txt وراء قالب، ويوفر BigCommerce بنى URL جاهزة وJSON-LD أصليًا، تمنحك SFCC أدوات التحكم الخام وتتوقع منك معرفة Business Manager. ليست منصة يصح وصفها بأن «SEO فيها جيد تلقائيًا»، بل منصة «يمكن أن يكون SEO فيها ممتازًا إذا ضُبط عمدًا». قيّمها على هذا الأساس.

Add an expert note

Pin an expert quote

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