Salesforce commerce cloud (SFCC) is a commonly used, cloud-based platform for eCommerce sites, be it large, small, B2C or even B2B. As an all-in-one tool for website hosting and catalogue management, SFCC features an array of valuable settings to enable you to serve products and categories to users across multiple countries and domains. 

When used to its full capacity, SFCC can help you to implement SEO functionality expertly and with ease, however, the platform can be difficult to navigate without proper guidance and consideration.

We’ve identified some key areas within SFCC Business Manager (the command centre for your eCommerce platform) which can be harnessed to ensure best practice for SEO, which we’ll be looking at throughout this three-part series:

Part 1: Hostname configuration, location mapping & URL structure
Part 2: Website crawling & redirect tools
Part 3: On page SEO (focusing on dynamic rules and manual overrides for metadata and H1s) 

In this masterclass series we will deep dive into how to implement these best practices, to ensure that your SFCC site will not only meet the needs of your customers, but will also align with the ever-evolving demands of search engines. In this blog post we will be kicking things off, by taking a detailed look at hostname configuration, location mapping & URL structure.

Hostname Configuration, Location Mapping & URL Structure

SFCC Business Manager features a number of tools to allow you to properly configure your URL structure, international setup and hostname, all of which are key to ensuring your site is mapped correctly to your registered domain name, is structured for geo-targeting and your URLs are SEO-friendly, user-friendly and readable.

Alias File

Alias configuration is typically one of the first steps when setting up a new website, and is crucial to ensure correct setup and enable sitemap creation and redirects. Many features within SFCC will not work correctly without proper configuration of an alias file.

Uses of the alias file:

• Defining alternative names for your website
• Mapping site paths for geolocations that exist on the same ccTLD but a separate subfolder, via the same catalogue
• Mapping site paths for geolocations that exist on separate ccTLDs, via the same catalogue
• Automatically mapping misspellings of domains to the correct one (the domain name and DNS must be registered for this to work)
• Defining website entry points to prevent duplicate homepages from occurring on your site (this is a common problem with SFCC SEO but luckily one that is easily rectified)
• Mapping pipelines and controllers generated via the SFCC platform to SEO friendly URLs

Important to note: SFCC operates on multiple environments to allow for development, testing and live versions of a website to exist. Alias configuration is specific to each instance and therefore must be set per environment to ensure each version is mapped correctly.

Also important to note: While the basics of an alias file can be set up by an SEO, we would always recommend involving a developer or a solution architect for anything more complex, as this is crucial to get right for your website to function as intended. However, an understanding of how the alias file works is beneficial for SEOs to understand and mitigate issues that may occur as a result of the alias setup, either for new domains, new locales or migrated websites.

The alias file can be found within Merchant Tools > SEO > Aliases

Standard alias file configuration for a production environment:

SFCC provides the following example of an alias file setup:

{"__version": "1", 
"settings": { 
     "http-host": "httphostname", 
     "https-host": "httpshostname",
     "job-hostnames":
      {
        "default":"www.my-default-host.com",
        "de":"www.my-de-host.com",
        "en":"www.my-en-host.com"
      }, 
     "site-path": "sitepath", 
     "default" : "defaultValue",
     "site-path-trailing-slash" : "yes" } 
"hostName1": [
   { mappingRule1 },
   { mappingRuleN }
 ],
"hostNameN": [
   { mappingRule1 },
   { mappingRuleN }
]
}

Things to note:

• The version listed for your site must always be 1; other version numbers are currently unsupported and if used, your alias file will be ignored
• The http / https hostnames should start from the domain OR the ‘www’ depending on which URL structure you use. 
• Common SEO issues include having duplicate sites generated by hosts with and without the ‘www’. To prevent this, ensure both are mapped in the alias file to the primary version. 
• Websites with https encryption (necessary for Ecommerce sites where you can buy online) do not usually need accessible and crawlable http versions, and having both hostnames can cause duplication. You can therefore omit this from the alias file and instead enable automatic redirection of http to https URLs:
  • To do this, navigate to Merchant Tools > Site Preferences > Storefront URLs and tick the option for ‘Require URL generation to use HTTPS protocol. Incoming page requests using HTTP are redirected to HTTPS.’
• The job hostname default should always be the primary version of the host irrespective of locales.
  • For example, if your catalogue hosts separate ccTLDs for different locales, the primary version should be default. This will usually be the most valuable locale for your business.
• Duplicate homepages can be an issue generated via SFCC due to having different pipelines for the site default and the homepage. These pipelines are typically depicted as Default-Start and Home-Show and need to be mapped to the same entry point to prevent duplication. This is done by specifying the destination  in the alias file, i.e:

{
			"entry-point-pipelines": [
				"Default-Start",
				"Home-Show"
			],
			"entry-point-destination": [
				"site-path"
			]
		}

• If you’re using the alias file to setup locale / language mappings, you’ll need to use the ‘if-site-path’ commands to set this correctly
• For example, for a site targeting the Belgian market, using subfolders for Dutch and French languages, your configuration may need to include something like:

{
			"if-site-path": "nl-be",
			"locale": "nl_BE",
			"site-path-trailing-slash": "yes"
		},
		{
			"if-site-path": "fr-be",
			"locale": "fr_BE",
			"site-path-trailing-slash": "yes"
}

• You may need to map any production environment URLs generated by your setup (i.e. production-examplecode.demandware.net [the production URL generated by your site may be different to this and should be checked by the development team]) to the live version of the site as part of the alias configuration, to prevent this creating a separate hostname which may be indexable. 
• Here is an example set up for a domain with the following attributes: This domain is targeting the Belgian market, via a hostname of www.exampledomain.be.
• The domain is localised into both Dutch and French, with the Dutch version as primary. 
• The languages are hosted via subfolders of ‘/nl’ and ‘/fr’ within the ccTLD. 
• The ‘enforce https’ rule has been enabled, meaning we do not need to configure http and https hostnames.

Taking into account all of the above, the alias file could look something like this:

{
	"__version": "1",
	"settings": {
		"job-hostnames": {
			"default": "www.exampledomain.be"
		}
	},
"exampledomain.be": [
		{
			"locale": "nl_BE"
		},
		{
			"host": "www.exampledomain.be",
			"path": "nl"
		},
		{
			"if-site-path": "nl",
			"locale": "nl_BE"
		}
	],
	"www.exampledomain.be": [
		{
			"if-site-path": "nl",
			"locale": "nl_BE",
			"site-path-trailing-slash": "yes"
		},
		{
			"locale": "nl_BE"
		},
		{
			"entry-point-pipelines": [
				"Default-Start",
				"Home-Show"
			],
			"entry-point-destination": [
				"site-path"
			]
		}
	],
	"production-examplecode.demandware.net": [
		{
			      "host": "www.exampledomain.be",
		              "path": "/"
		
		}
	]
}

Staging and development environment alias configurations

These should be alternative versions of your specified domain. These need to be set with their own aliases; alias files are not and should never be replicated between environments due to the differences in uses between these. 

Important to note: Your site may also feature a sandbox environment for testing purposes. If so, this setup will also need to be considered by your development team or solution architect.

Example alias configuration for a staging site with the same above specifications:

{
   "__version":"1",
	"settings": {
		"job-hostnames": {
			"default": "www.staging-exampledomain.be"
		}
	},
      {
         "if-site-path":"nl",
         "locale":"nl_BE",
         "site-path-trailing-slash":"yes"
      },
      {
         "if-site-path":"fr",
         "locale":"fr_BE",
         "site-path-trailing-slash":"yes"
      },


      {
         "locale":"nl_BE"
      },
      {
         "entry-point-pipelines":[
            "Default-Start",
            "Home-Show"
         ],
         "entry-point-destination":[
            "site-path"
         ]
      }
   }

The development environment can follow the same setup, but with the domain of www.development-exampledomain.be

Locale Mapping

In this example, we have mapped the locales to their URLs using the alias file. However, we still need to enable the locales on the platform. You can check which locales are enabled on your site by navigating to Merchant Tools > Site Preferences > Locales. These also need to be enabled within Administration > Global Preferences > Locales. 

From here, you can select which locales should be available on your site. These locales must be mapped either via URL Rules or the Alias file (as shown above) to ensure an SEO friendly set up.

When should you use URL rules over the Alias File to map locales?

In short, URL rules are simpler, but offer less capability. You can select to map your locales via alternative hostnames, URL parameters or paths. However, for a mixed approach, i.e. catalogues that need to utilise multiple hostnames (such as ccTLDs) as well as separate language subfolders, this will need to be done via the alias.

If you map all of your URLs via the alias, the locale mapping setting can be left as ‘none’.

URL Structure

SFCC features URL rule settings which can be utilised in order to automatically create SEO friendly URLs across your website. This is split into rules for character replacements and search refinements, as well as the following page types:

• Catalogue URLs – with separate rules for Categories (PLPs) and Products (PDPs)
• Content URLs – with separate rules for Content pages (i.e. assets) and Folders
• Pipeline URLs – this allows you to remap pipelines (controllers that execute commands used in the storefront)

(For URL rules for search refinements, please see the Search Refinements for Facets section.)

These rules utilise attributes within the catalogue and can be customised to your requirements based on how you want your URL structure to appear. This ensures that you do not need to set URLs manually for every given page on your site. 

In order to enable rule-based URLs,  you need to first enable this option in the storefront. Not doing so will default URLs to using parameters as standard, so its really worth ensuring this is enabled. You can do this by navigating to Merchant Tools > Site Preferences > Storefront URLs.

From here, select the checkbox for: Enable New Rule-Based Storefront URLs to Replace Legacy SEO URLs

Once done, you can go to the URL Rules tab to configure your URLs. This is located within Merchant Tools > SEO > URL Rules > Settings.

Character Replacement Settings

These settings ensure your URLs are properly encoded and formatted correctly:

• Lower Case: we recommend checking this setting to ensure all URLs resolve automatically to lower case. This will prevent duplicate URLs and subsequent redirects that may be generated from URLs with mixed cases. Lower case URLs are also generally accepted as preferred by bots and crawlers.
• White Space: this allows you to override spaces within URLs with predefined characters. Typically, these resolve to ‘%20’ but this can become messy for both users and crawlers. The options to select from include plus symbols (+), underscores (_), minus symbols (-) and full stops (.). We recommend minus symbols as the cleanest form, but you can theoretically use any of these.
• Custom Replacements: enabling this allows you to set replacements for special characters i.e. replacing ‘ä’ with ‘ae’ for German URLs. These can be set by locale/language to make these specific per market. The system will look at the language (country) settings first, followed by the language setting, and then the default, in order to apply the replacements.
• Character Replacement for ‘pageURL’: we recommend ticking this to ensure that if URLs are manually overwritten, the character rules will still apply. This is a failsafe to protect against human error from manually typed characters.

Catalogue URLs

Click into the ‘Catalog URLs’ tab to configure catalogue URLs, split into rule types for Categories and Products.

These rules are built up from attributes which you can specify based on your requirements for URL structure. These attributes can be standard or custom, depending on your configuration.

Things to note:

• Ensure the attributes used can successfully generate unique URLs
  • For example, if you use the category name attribute as the only identifier within PLP URLs, any categories that feature the same name will try to resolve to the same URL. 
  • The system will automatically check for conflicts and flag these within the main URL Rules page, and may automatically append URLs with a number when this happens to prevent exact duplicates, however this can make things confusing for users, internal teams and search engines.
  • It therefore may be better to include at least two elements within a given rule.
• Use a constant as part of the URL to allow for better reporting/crawling
  • It’s good SEO practice to use an identifier to bucket category and product URLs into separate folders. This will allow easier tracking and reporting for internal teams, will allow search engines to better understand site structure, and may make it easier to spot patterns within page types during technical and website audits.
  • For example, we often see Ecommerce sites opting to use the letter ‘c’ for category pages, and ‘p’ for product pages. Alternatively you could use ‘cat’ and ‘prod’, ‘plp’ and ‘pdp’ or any other identifier that is appropriate for your business.
• Product URLs will always include the Product ID, so you do not need to specify this in the rule
  • SFCC automatically appends the ID to the product page to ensure this is unique. This can also be done for variations of products if each version requires a self-referencing canonical.
  • The product ID will always include ‘.html’ at the end of the URL. There is no way to prevent this without custom development.
• Avoid including elements that are not always static, which will therefore cause URLS to change periodically
  • For example, including a category name in the product URL may seem like good practice for SEO in terms of breadcrumbing. However, products may be assigned to multiple categories within a catalogue i.e. a toaster being assigned to both ‘Home and Dining’ and ‘Kitchenware’ categories. This means that the system will automatically assign the primary category as the one to include in the URL, but if this changes, the URL will also change.
  • Depending on the codebase, the system may automatically redirect old URLs to the new one, but this can cause crawling errors, site speed issues, poor UX and index bloat. It’s therefore best to avoid including elements that do not result in one single output as part of the URL structure.
• Ticking ‘enable Overrides’ ensures that you can use custom URLs for given pages
  • This is good for creating specific SEO friendly URLs that include keywords for example that may be better optimised than the standard rule. However, manual input can result in duplication, so ensuring the rule is best created to produce optimised URLs is preferrable.

Content URLs

These follow the same rule setup and tickbox options as catalogue URLs, and apply to content assets and folder level pages within the SFCC setup (i.e. pages outside of the standard Ecommerce catalogue such as About Us, Blogs, Size Charts etc.).

You can find these by clicking into the ‘Content URLs’ tab within URL Rules.

Pipeline URLs

Click into ‘Pipeline URLs’ to map standard SFCC pipelines to appropriate aliases.

Like with character replacement rules, these can be set at language (country), language or default level and will be applied in that order in terms of priority.

For example, you may want the Cart page on your Ecommerce site to resolve to a URL of ‘/cart/’ for EN language pages. For French language pages, you may want this to resolve to ‘/panier/’. You can set this up via pipeline URL rules for the pipeline Cart-Show.

Important to note: If you are seeing demandware.net URLs appearing in your crawl reports containing pipelines such as search-show etc., this is probably due to missing pipeline URL configurations or errors with your current setup. So, debugging this using your pipeline URL rule settings first is an ideal starting point.

Search Refinements for Facets

Search refinements in SFCC are used to create filtered pages within a top level facet, which are great for both SEO (when utilising a proper indexing and canonicalisation strategy) as well as user experience.

For example a pet supply website selling dog food products, may have a top level PLP for ‘Wet Dog Food’. This page could then be supplemented with the following types of filters:

• Packaging Type (tinned, cartons, pouches)
• Animal Lifestage (senior, adult, puppy)
• Brand (James Wellbeloved, Royal Canin, Scrumbles)
• Weight
• Packaging Material
• Flavour (chicken, lamb, beef)
• Price

To create these filter pages, each of these title attributes would need to be created as Search Refinement Types within SFCC. The filters within those types are set as Values with corresponding Display Names within this.

For best practice, Search Refinement Type should be applied at Storefront level. Products are then set with these attributes in the catalogue. When those products are assigned to categories, any relevant refinements are then automatically applied to those categories. This ensures all refinements can be managed centrally.

However, for categories that require different refinements per category type, you are able to override these at category level.

To create search refinements within the storefront, navigate to Merchant Tools > Products and Catalogs > Catalogs. Your storefront should be created within this area. From here, select ‘edit’ on your Storefront, and then click into Search Refinement Definitions.

Refinements should be created here and then edited by clicking into the newly created Refinement type. As with most settings on SFCC, these can be localised by selecting the language or language (country) from the dropdown. This will ensure that display names can be trans-localised by market.

Refinements can use bucketed values or set values. This will usually be set up by a merch team, however you should endeavour to provide SEO insights into which filters should be created that have indexing value.

One of the biggest challenges with search refinements is configuring SEO-friendly, clean URLs. As standard for SFCC sites (depending on the codebase your site is on), all refinements utilise parameters. To change this, you’ll have to implement custom development, which can only be done by a solution architect or your development team, and not directly in SFCC Business Manager. 

This is also true for setting canonical tags and no index tags on a filter by filter basis; this has to be implemented using custom development.

There are some settings we can configure in URL rules, however the standard settings can typically be left as they are:

• Refinement Position: set to after to ensure the URL order matches the expected setup, of https://domain.com/plp-url/filter/
• Refinement Segment Delimiter: leave as slash, to ensure the category portion of the URL is separated from the filter with a ‘/’.
• Refinement Delimiter: this is for when multiple selections of different refinements are applied, i.e. a colour and a size filter. This could be either a slash or a minus symbol.
• Refinement Value Delimiter: if more than one of the same filter are applied, for example two colours, this will separate them and can be left as a plus symbol.

Additionally, you can block certain refinements from appearing on categories within the Category Search Refinement Definitions settings on a PLP-by-PLP basis. You should ensure to do this to prevent filters from appearing on categories where they’re not needed and subsequently generating crawlable and/or indexable pages.

In Summary

We’ve covered a lot of ground in regards to hostname setup and URL configuration, so to summarise some of the key functionalities:

• Alias File: Essential to configure for correct setup; manages hostnames, redirects between encrypted and unencrypted versions, and defines geolocation paths, preventing common SEO issues like duplicate homepages and ensuring your site is accessible. Without this, many other features within SFCC will not work.
• Locale Mapping: Critical for geo-targeting, with setup options in both the Alias file and URL rules, depending on complexity.
• URL Structure: SFCC provides rule-based settings for SEO-friendly URLs, which can be customised for catalogue, content, and pipeline URLs.
• Search Refinements: Useful for creating SEO-friendly filtered pages; however, clean URLs and proper indexing strategies require custom development.

Thanks for reading!

I hope you’ve enjoyed part one of our masterclass series on Optimising Salesforce Commerce Cloud (SFCC) Sites for SEO. Read part 2 to discover how you can utilise SFCC tools to configure crawling and indexing strategies including sitemap creation, robots.txt files, URL redirects and more. Make sure to join our blog mailing list to get updates when this goes live in a few weeks time!

If you need help configuring your SFCC platform to meet your SEO needs, please get in touch with us today via our website.