Explore the chapters:
- Introduction
- Chapter 1: Staging vs. Production vs. Development Instances
- Chapter 2: Business Manager SEO Portal
- Chapter 3: Salesforce Commerce Cloud URL Rules
- Chapter 4: Salesforce Commerce Cloud Redirects
- Chapter 5: Salesforce Commerce Cloud Robots.txt
- Chapter 6: Salesforce Commerce Cloud Aliases
- Chapter 7: Salesforce Commerce Cloud XML Sitemaps
- Chapter 8: Salesforce Commerce Cloud URL Request Analyzer
- Chapter 9: Salesforce Commerce Cloud Page Meta Tag Rules
- Chapter 10: Salesforce Commerce Cloud SEO Settings
- Chapter 11: SFCC SEO Summary
The URL Rules portal is divided into 8 sections that either impact or provide insight into how you set up your URLs for various pages. Creating the rules that will drive the URLs are done so in this section.
Please note: I will not be delving into URL Archive, URL Refinements, and History, as I’d like to focus on the modules that drive the most actionable optimizations.
Before starting on the other sections, it’s important to note that when configuring the URL Rules you should start with a vision of how you’d like the URLs structured. That is, how should URLs be structured in your SEO project plan.
What’s more, you should discern where you are in your SEO project. If you are at the onset of a website migration, creating a URL strategy is a must to avoid any unoptimized behavior before and after launch.
With these requirements, you can try to create rules that abide by the current SFCC technology or assess if it’ll be a customization, of sorts.
1. General
This an overview of your current URL Rules. One of the biggest takeaways from this subsection is that you’ll be able to see if there are any conflicts that occur based on how you’ve configured your rules. That is if there are URLs that are identical and conflicting with one another.
See Salesforce Commerce Cloud documentation for configuring URL Rules here.
2. Settings
Within Settings, you’re able to tell SFCC how you want all URL rules to function in regard to formatting, via “Character Replacement Settings”.
Settings under this subsection include,
- Lower Case: By checking this option, you tell SFCC that you’d like all your URLs to be lower case. I prefer to check this because user behavior typically gravitates towards using lower case when inputting a URL.
- White Space: If you don’t designate what to do with white space, SFCC will input HTML encoding (%20) into the URL to account for the spacing. This isn’t ideal. You’ll want to assign how Commerce Cloud should treat white spacing. I typically use “-” Minus as it’s commonly seen on the web.
- Custom Replacements: This setting enables you to assign custom replacement rules, which are found below.
- Custom Replacement Rules: In this subsection you’re able to set up how SFCC will treat special characters such &, %, # trademark symbol, ™, copyright sign, ©, etc.
- Character Replacement for ‘pageURL‘: This setting allows you to use the special character replacement rules for values defined in pageURL. We’ll go over what pageURL is and where to find it below.
The next subsection within the “Settings” area is “Locale Mapping”.
This area is typically reserved for brands that are going to be broken out into international sites and how they’d like to denote internationalization. Brands can choose one of the below,
- URL Parameter
- Subfolder
- Hostname.
I typically recommend breaking out international sites by Subfolder to help consolidate search authority under 1 domain.
The last section on this page is dedicated to how your SFCC site will treat product listing filters and sorting options.
I typically leave this area as it comes out of the box; reason being, various other teams, particularly merchandising teams, eventually help carve out what filters will look like.
Additionally, these may change depending on what your SEO strategy will be in regard to category filters. That is, you may want SEO friendly filters – which will require a customization and an SEO dev ticket.
3. Catalog URLs
3.1 Category URL Rule
Catalog URL rules are going to be what drives your category URL structure. What feeds your category URLs is going to depend on how you’ve set up your category architecture, which extends to the taxonomy of your site, the IDs you’ve used for each category in your taxonomy, and the Names you’ve assigned to each category.
The difference between IDs and Names is that IDs are unique and should only be used once, whereas Names can be used multiple times.
Below are the configurations you can toggle
- Category URL Rule
- The rule / syntax needed to generate a URL.
- Enable Override with ‘pageURL’ Category Attribute (if set)
- This setting will give you the ability to override the rules at an individual category level. We’ll talk more about this below.
- Append Trailing Slash to Category URLs
- This setting adds a trailing “/” towards the end of category URLs. I typically like to toggle this on but there is no harm leaving it off.
- Generate URL Mappings for Offline Categories
- This setting I typically leave off but from my understanding it generates URLs for categories that are not turned on. For that reason, I don’t toggle the setting on.
- Enable Category Search Refinement URLs
- This setting turns on search refinement URLs, or URLs for filters. Depending on your site, you may want to turn this on – I typically turn this on to help drive refinement URLs.
Let’s say you’re a Shoe retailer and carry both womens and mens shoes. You can have a Taxonomy such as the below.
| Category Level | ID (Women Category) | Name (Women Category) | ID (Men Category) | Name (Men Category) |
| 1 | women | Women | men | Men |
| 2 | womens-shoes | Shoes | mens-shoes | Shoes |
| 3 | womens-dress-shoes | Dress Shoes | mens-dress-shoes | Dress Shoes |
Notice that Category IDs across both Womens and Mens are unique, that is, there is no overlap between the two. Commerce Cloud requires this uniqueness in IDs.
However, Category Names can be duplicative as indicated by the use of “Shoes” and “Dress Shoes” across both the Women and Men categories.
Why does any of this matter?
Depending on how you set up your categorical taxonomy, it may impact how your URLs are generated.
Let’s walk through an example of creating a category URL. The Out-of-the-Box setting for category URLs is
[attribute, ID]Which tells SFCC we want the URLs driven by the ID, nothing more. So for “Mens Dress Shoes” the URL would look like,
- /mens-dress-shoes
However let’s say you wanted to include a category path and lean on the name of the category (to make the taxonomy more apparent in the URL) – the above won’t suffice, you’ll have to loop in some additional SFCC syntax to help out. Below is an example of a common rule.
[ category-path, [ attribute, displayName ], / ]It tells Commerce Cloud, SFCC should use the category path and the displayName, or name of the category. Using the “Mens Dress Shoes” example above, the URL would then look like.
- /men/shoes/dress-shoes/
You can easily detect the hierarchy of the URL above all the while maintaining an easy-to-read URL. From an SEO standpoint, I feel like the above has helped tremendously in regard to letting search engines understand site taxonomy. Additionally, the above provides a great user experience in that, users are able to denote where they are within the site.
Please note: depending on the rule that you use, you may come across “URL Conflicts”. “URL Conflicts” exist when the same criteria, based on the rules, feed into multiple URLs. That is, if the rule read similar to
[attribute, displayName]URLs for both Women and Men “Dress Shoes” would be the same based on the rule and would be conflicting and generate the below format.
- /dress-shoes-1/
- /dress-shoes-2/
Business Manager will tell you when you have conflicts. If you find you have conflicts, review how the URL rules are set up and whether your rule leans on an attribute (a category trait) that may be the same across various categories.
Based on what’s creating the conflict, you can look at the report that SFCC provides and assess which pages are causing the issue. From there you can decide if it’s worth updating the attribute that’s causing the issue or updating the URL rule.
There is no right or wrong way to set up URL rules. I’ve had clients use IDs to drive URLs, others use Names, and some use complete custom approaches.
The approach to category URLs depends on your SEO Strategy and what’s either worked in the past or can be improved on in the future.
Going forward, Product and Content URLs will function in a similar manner.
3.2 Product URLs
The rules you set up for your Product URLs are going to be similar to Category URLs but on slightly different criteria. However, let’s quickly look at the Product URL Rule settings.
- Product URL Rule
- The rule / syntax needed to generate a URL.
- Enable Override with ‘pageURL’ Product Attribute (if set)
- This setting will give you the ability to override the rules at an individual product level. We’ll talk more about this below.
- Use ‘-‘ as Product ID Separator Instead of ‘/’
- This gives you the option of replacing the final subfolder that houses the product ID (e.g. /product-name/123.html) , with a simple dash “-” (e.g. /product-name-123.html). I leave this unchecked as I prefer the “/”.
How does the Product URL differ from the Category URL rule?
In a lot of ways it doesn’t, however, instead of leaning on category IDs and names, you’ll be using Product IDs and names to generate the URL for the Product Detail Page (PDP).
You’ll still need to determine if you’d like to use a category path in the product URL. Depending on the product catalog, category taxonomy, and product names, I leave the category path off as it can elongate the URL.
I also like to lean on the product name within the URL as the name is a great indicator of what the PDP is about. In regards to SEO, I’ve seen the name in the URL be a major contributor to organic performance as searchers might lean on the name within their search.
Let’s say we have 2 IDs outlined below, each in different categories.
| Product Name | Product ID | Category |
| White Leather Heels | 123ABC | Dress Shoes (Women) |
| Beach Sandals | 456LMNO | Dress Shoes (Women) |
| Black Leather Loafers | 789XYZ | Dress Shoes (Men) |
We want to generate a URL Rule that is inclusive of a category path and the product ID, no product name. The below syntax should do the trick.
[ category, [ category-path, [ attribute, ID ], / ] ]Which would result in the product URLs for the above looking like this,
- /women/shoes/dress-shoes/123ABC.html
- /women/sandals/beach-sandals/456LMNO
- /men/shoes/black-leather-loafers/789XYZ.html
This will only look like the above if you’ve assigned a product to a specific category / subcategory.
The above URLs aren’t really the approach I like to take with my URLs. Again, it depends on your strategy but if you like to keep the PDP URLs succinct, I recommend the below product name + ID syntax.
[ attribute, name ]Which would translate to,
- /dress-shoes/123ABC.html
- /beach-sandals/456LMNO
- /black-leather-loafers/789XYZ.html
It’s pretty succinct and descriptive – making it very easy to understand.
A slight segue – I’ve had clients ask that we drop “.html” from the product URLs. Reason being, it looks out of place and doesn’t fit into their URL strategy.
I’m here to tell you that I’ve dug into whether omitting the .html extension was feasible, going so far as to communicate with Salesforce reps and I’m told time and again, it’s not possible to drop the .html from both PDPs and content page.
This is what I’ve been told and I just want to save you the energy and heartache of trying to drop it as well.
That’s a lot to take in. The reason why I dug in so much for both categories and products is because as retailers, so much is dependent on these URLs. The rest of this post should be less intensive.
4. Content URLs
This module is broken out into Folder URL Rule and Content URL Rule. I won’t be going in depth with the syntax as it’s similar to Category and Product URL Rules.
The Content URLs section targets content pages and content assets (Content URL Rule), as well as their placement in the site (Folder URL). Content assets can be viewed as blocks where pages can be built upon. They not only act as blocks that can be injected into areas of an existing page, like categories or PDPs, but they can also stand as their own pages, able to rank within search.
Folders are able to take individual Content pages and house them in a directory, as such they share taxonomical similarities to Category URL Rule.
5. Pipeline URLs
Pipelines are a tad hard to explain but from what I gather, they help call a specific page type, such as when you’re referencing a category, product, login, or account page type.
They are widely used to display customer-specific information such as login details, cart information, password resets and the information is often relayed to a server location.
See Salesforce Commerce Cloud documentation for configuring Pipelines here.
In this section, you might see that it is completely empty and that’s completely fine. Every brand I’ve worked with uses a pipeline in a different way. Brands sometimes use it strictly for customers; other times, brands use it for content.
In any case, depending on the pipeline, you’ll find that the pipelines URLs out-of-the-box are long and convoluted, following a Commerce Cloud / Demandware URL, that then calls out the pipeline name. See example set of Pipeline values below,
- Account-Show
- Cart-Show
- Home-ErrorNotFound
- Order-History
- Search-Show
As you can see above, it’s not consumer friendly and is often reserved for Commerce Cloud usage. The Pipeline URLs section allows you to take the out-of-the-box values and create an alias, or a more consumer-friendly URL. So if you’d like, you can take the above pipeline and assign an alias similar to the below,
- account
- cart
- 404
- order-history
- search
It’s not a major shift but if you don’t use an alias for a Pipeline URL, you’ll get stuck with Commerce Cloud URLs that become harder for consumers to interpret.
Summary
We’re at the end of the URL configuration portion of this guide. It can be tricky to navigate through the URLs but it’s important to have an idea of how you’d like the URLs to be structured. You can save yourself a great deal of time and sanity just ideating around what the perfect structure would be and working from there.
If you find yourself needing to backtrack from a URL rule, you definitely and Salesforce Commerce Cloud is intuitive enough to build 301 HTTP Redirects to the new structure.
Lastly, as you’ll find, you don’t need the final URL structure to build a 301 redirect map in SFCC. Rather, as we’ll find out in a moment, the redirects are dependent on IDs, not names or the final structure.
Now, let’s move onto Redirects.
