Chapter 4: Salesforce Commerce Cloud Redirects

Redirecting SFCC URLs

< Prev.

Next >

---

Redirects are crucial in SEO as they tell both users and search engines a great deal of information. They’re able to keep the user experience flowing without interruption and able to pass on search authority to another location once a page has moved or expired; impacting how your webpages perform.

During a website migration project, redirects are a massive consideration. You may not just be looking to update technologies on a website but you may be looking to move, en masse, the established authority that Google and other search engines have attributed to your pages. 

With that, in Salesforce Commerce Cloud, you have 3 areas to build redirects,

• URL Redirects
• Static Mapping
• Dynamic Mapping

There are subtle nuances between each of the 3 and depending on your redirect strategy and what you hope to accomplish in your 301 redirect map, one may be better suited than another. If you’re wondering “how long does seo for a site migration take“, these 3 website migration tools have my time navigating SFCC more effecifient and effective in getting a website ready for launch.

With that, let’s get into it.

1. URL Redirects

URL Redirects, from what I’ve been told, were designed to manage the redirects for pages generated by Commerce Cloud. As such, URL redirects are great for retiring Category, Product, and Content pages, where you’ll be able to select which assets you’d like to remove. However, as you’ll find through the URL Redirect creation process, you can also redirect various URLs not generated by SFCC. More on that later.

The below is the entry page for URL Redirects. 

You can view a list of already built redirects or toggle an advanced search if you’ve already pulled various redirects together.

You can filter redirects by Category, Product, Content, Folder, Status Code, as well as other criteria. This comes in handy when you’re combing across multiple lines of redirects.

If we go back to the Simple view, we can build a new URL Redirect. 

Once you’ve started, you can select from a series of configurations.

Source Type: Because this portal was designed to redirect SFCC generated pages, you are allowed to search by the various page types. You’ll be able to pinpoint the location of the redirect source and select a Category, Product, Content, Folder, or URI (or the URL path of a location).

After you select the source, you can then provide values for a URI / Category ID / Product ID / Folder ID / Content ID, i.e. Category ID would only let you select from a list of categories.

Destination Type: Similar to the Source Type, you can define the Destination Type as well by URL, Category, Product, Folder, and Content.

Similar to Source Type, you’ll be able to provide a value for the URL you’re targeting or the ID of the Category, Product, Folder, or Content asset you want to redirect to.

Destination URL Parameters: If you so choose, you can try to carry over specific URL parameters. This is helpful if you have a specific campaign that you want to continue tracking onto a new location.

Copy Source URL Parameters: Similar to the Destination URL Parameters, you’re able to dictate whether you want to carry URL Parameters en masse.

Note: I really never understood why there were 2 configurations for parameters, if you can toggle on Copy Source URL Parameters.

Redirect Type: This configuration allows you to tell SFCC which status codes you want attributed to the Redirect. You can select from Permanent (301), Found / Temporary (302), or Temporary (307). This configuration is great because you can tailor your redirects based on current strategies / needs. If you need to take down a page temporarily, you can use a 302 and still retain the search authority to the original source.

Enabled: Last but not least, you can tick a box called “Enabled” – this will trigger the redirect and allow it to work. Left unchecked, the redirects won’t toggle on. This area is the only section, from what I’ve gathered, to allow one to toggle a different HTTP status code, separate from 301 Permanent. It gives you an opportunity to select a 302 or 307 Temporary redirect. It’s a great feature if you want to pause certain redirects – e.g. you want to toggle off holiday categories during the summer.

1.1 A Note on URL Redirects

As you can imagine, building redirects in this manner would seem ideal but, with this approach, you’re building redirects one by one. And for a migration project or robust SEO project plan, where you’re dealing with possibly tens, if not hundreds of thousands of pages, you don’t want to implement redirects one by one. 

There are methods of uploading an XML to populate the redirects in masse. But unless I’m working with pre-existing built redirects in URL Redirects, I wouldn’t go the XML route either.

I’ve grown to appreciate the next 2 redirect portals, Static Mapping and Dynamic Mapping.

---

---

Let’s talk through Static Mappings first.

2. Static Mappings

2.1 Syntax

Static Mappings is designed to take in multiple lines of redirects at once. Where URL Redirects you would enable redirects one by one, you can copy and paste in bulk from a text editor or spreadsheet en masse. This bulk capability is the biggest benefit to Static Mappings over URL Redirects, I feel.

You can liken the syntax used in Static Mapping similar, but definitely not identical to, an htaccess file or the Nginx language. However, what works in htaccess or Nginx won’t exactly work within this portal.

To better understand the syntax that drives Static Mapping, reference their documentation here.

Because Dynamic Mapping syntax takes similar syntax from Static, let’s walk through a few examples to better understand how to build redirects using these portals.

Let’s work with a common rule I use; see below,

/w/old-womens-shoes/ i p,,,Search-Show,,cgid,womens-dress-shoes

• /w/old-womens-shoes/: The legacy URL path we’re telling SFCC is retiring.
•  i : this allows the rule to be case insensitive
• Search-Show: The pipeline request being made. In our case, we’re making a request that is calling upon category pages but you can also make requests for product, content, or other pipelines.
• cgid: The parameter of a pipeline that is being referenced to help identify a target. In our case, with “cgid” we’re telling Commerce Cloud to use the Category ID to build the redirect. Remember, this would switch if we decided to target another Pipeline, such as products. More on that in a sec.
• womens-dress-shoes: This portion is the category ID that is being targeted. This will then finalize the redirect.

With all the above values combined, you’re able to tell SFCC to retire the URL path beginning with /w/old-womens-shoes/ and point it to the Commerce Cloud category location whose ID is “womens-dress-shoes”.

I’ve seen brands use rules source similar to,

https://www.example.com/w/old-womens-shoes/ i p,,,Search-Show,,cgid,womens-dress-shoes
https://blog.example.com/w/old-womens-shoes/ i p,,,Search-Show,,cgid,womens-dress-shoes

There’s no need; SFCC only requires the URL path within Static and Dynamic Mappings. You’re redirect won’t work with a URL (possibly with Alias configuration but I’ve never tested it).

Let’s say you want to redirect a legacy product detail page (PDP) to its new location.

That’s totally doable. You have to start referring to your source and target using the correct product syntax with the necessary associated details. Let’s look at the example below, 

/p/white-leather-heels/123ABC/ i p,,,Product-Show,,pid,WDS001

• /p/white-leather-heels/123ABC/: The legacy URL path we’re telling SFCC is retiring.
•  i : this allows the rule to be case insensitive
• Product-Show: The pipeline request being made. It’s switched from Search-Show to Product-Show, as we’re now requesting a different page type.
• pid: The parameter of a pipeline that is being referenced to help identify a target. It’s again switched to pid, or the Product ID. Remember, we said this would switch depending on the Pipeline or page type we decided to target.
• WDS001: this is the product ID of your target.

With the updated syntax, you’re saying that your legacy URL path /w/old-womens-shoes/ should redirect to the product whose ID is WDS001.

2.2 File Size

Folks have asked how many lines they can add to the Static Mapping file and honestly, that’s going to depend.

If you read the Static Mapping doc, Salesforce states that it’s file size limit is 2MB. Once you hit that limit, you won’t be able to save this section. Don’t think it’s something incorrectly you’ve done; it may be that you hit a limit.

You can add onto the file using an XML import but it can become even more tedious having to upload an XML file every time you have to add in a couple of lines of new redirects. 

In any case, I’ve seen files that have fewer lines of rules that error out. I believe this is because, in this file, characters you use also drive up space. I’ve seen files max out at 20K lines of rules and 15K of rules, so you can’t place a limit on the file based on total rules.

Let’s say you have a massive product catalog, and you’re easily going to blow past the 2MB limit, what can you do?

Well, you might have to lean on Generic Mapping. This is a file, or series of files, that is able to manage the large load of various redirects. We won’t go in depth on this end but please keep in mind that to use a Generic Mapping file, you will have to create an SEO dev ticket to upload the URLs and build the logic.

---

---

2.3 QA’ing Redirects

With the various rules you’ve created in static mapping (or in any other redirect location), you’ll want to make sure that the redirects are working correctly.

You can QA by appending the URL path at the end of your SFCC host location. Depending on the location, the environment of your SFCC instance, and alias configuration, the URL can look something similar to, 

https://staging-na01-example.demandware.net/on/demandware.store/

Or something completely different. Again, it’s dependent on its location, environment, and alias. Some folks like to QA in Development before taking it to Staging. Other times, brands host it elsewhere.

When it comes to testing the redirect, we can take a fake staging URL, such as the below,

https://stg.example.com/w/old-womens-shoes/

You can either take the URL and place it within a browser URL bar or use a crawler. I prefer to use a crawler like Screaming Frog especially if I’m QAing a handful of redirects.

The status codes of redirects generated in Static and Dynamic Mapping should always be 301 Permanent, unless there’s an issue. Even then, QAing a redirect can be a large endeavor, so, again, I highly recommend Screaming Frog.

2.4 A Note on Static Mapping

Static Mapping is a great start to managing your redirect strategy en masse. Its copy and paste capabilities make it much easier updating on the fly without sacrificing workflow.

3. Dynamic Mappings

3.1 Syntax

Dynamic Mappings syntax has a large overlap with Static Mappings so we won’t break down each piece of a rule. Rather, we’ll focus on the syntax unique to Dynamic Mappings, covered below.

3.2 Wildcards

The biggest benefit to Dynamic Mappings over Static Mapping is wildcard (**) capabilities. If you’re not too familiar with wildcards, they target a wider range of source URL values.

Let’s pull in the first Static Mapping example we provided up top, 

/w/old-womens-shoes/ i p,,,Search-Show,,cgid,womens-dress-shoes

However, we want to redirect more than just w/old-womens-shoes/; we want to redirect everything after the first subfolder, /w/. And we want to point it to the “women” category page. The rule would update to read, 

/w/** i p,,,Search-Show,,cgid,women

The above rule “catches all” legacy URLs after /w/, as such we can say this rule is a “catch-all”, that points the URLs to the Women category page.

Let’s take it a step further, let’s say you are redirecting multiple products whose legacy URLs are using product IDs that are not changing in SFCC from a legacy platform. Let’s use the below examples.

• https://www.example.com/p/white-leather-heels/123ABC/
• https://www.example.com/p/beach-sandals/456LMNO/
• https://www.example.com/p/black-leather-loafers/789XYZ/

You can single out the product ID as the intended target within a Commerce Cloud rule with a combination of wildcards. The rule would look similar to,

/p/*/*/ i p,,,Product-Show,,pid,{1}

Let’s break this down really quick.

You’ll notice that in the first category Dynamic Mapping rule, we used a double wildcard “**” but in the product ID folder we used a single wildcard “*”. What’s the difference?

A * wildcard accounts for any value up to a forward slash “/” but not account for any slashes

A ** wildcard accounts for any value up to and including a forward slash “/”

Additionally, you’ll notice in the product redirect rule we wrote accounted had 2 single wild cards /p/*/*/. This is because we’re trying to bypass the product URL, no matter its product name (in a name subfolder) so we can get to the product ID, which is going to be used in the redirect target syntax.

Because we’re using 2 wildcards, we’ll have to tell the redirect target to focus on the 2nd, which accounts for the ID. With that, you can reference wildcards as sequences that you want to loop back into the target syntax, see below.

1st “*” or “**” = {0}

2nd “*” or “**” = {1}

3rd “*” or “**” = {2} 

So looping back the 1st “*” wildcard, you’d have to use a {0} but because we want to loop back in the 2nd “*” wildcard, we define it as {1}.

Using a rule such as, 

/p/*/*/ i p,,,Product-Show,,pid,{1}

…We can redirect URLs such as, 

• https://www.example.com/p/white-leather-heels/123ABC/
• https://www.example.com/p/beach-sandals/456LMNO/
• https://www.example.com/p/black-leather-loafers/789XYZ/

…And point to the new URLs for those products on Commerce Cloud. Because we created our Product URLs to be straightforward, we can say that the resolving URLs are,

• https://www.example.com/white-leather-heels/123ABC.html
• https://www.example.com/beach-sandals/456LMNO.html
• https://www.example.com/black-leather-loafers/789XYZ.html

…We redirected URLs using a common path between a legacy URL and its new location.

3.3 Query String and Parameters

You may have noticed that we haven’t touched URL Parameters such as those you can find in paid search, social, or email campaigns. 

Reason being, in Static Mappings you’re not able to bring in query strings or parameters. However, in Dynamic Mappings, you can loop in parameters, using an additional piece of “query string” syntax. 

If we decided to bring over UTM parameters for our earlier category redirect rule in Static Mapping, we’d have to build something similar to,

/w/old-womens-shoes/** i p,,,Search-Show,,cgid,womens-dress-shoes,{_querystring}

We loop in a double “**” wildcard because we’re saying that anything following the stated URL path should be included in this redirect. We want this approach to capture any parameters that follow the URL path. Please note: I’ve tested with single “*” wildcard usage but that doesn’t generate a redirect.

Additionally, we’ve added in a {_querystring} portion to the rule. This syntax states that you should bring over any parameters that exist.

So if we had a legacy URL parameters such as,

https://www.example.com/w/old-womens-shoes/?utm=123

The parameter would follow the redirect through to its new destination,

https://www.example.com/women/shoes/?utm=123

Please Note: It’s extraordinarily important to account for parameters in either Dynamic or Static Mappings. I’ve seen sites that hadn’t accounted for parameters and suddenly saw a drop in traffic from their other channels – paid, search, email, etc.

Reason being, there might be legacy URLs used in these other channels, let’s say an old email, where someone bookmarked a page and wanted to revisit the URL. If parameters from old URLs aren’t accounted for, via a {_querystring} protocol, or other means, there is nothing that dictates how to manage the additional URL path. As such, parameter URLs will break.

3.4 Redirect Order / Sequence

As you can tell, Dynamic Mapping could be very efficient when redirecting URLs through its wildcard and querystring approach.

When you have 3 portals that can trigger redirects, it’s important to note that there is a sequence when it comes to redirecting in SFCC. 

When requesting a legacy URL in SFCC and the sequence Commerce Cloud retrieves the redirect goes,

1. Salesforce checks in URL Redirects first,
2. And if not found, it checks in Static Mapping,
3. And it finally checks in Dynamic Mapping.

Why is it set up this way? My guess is, it’s meant to improve efficiency and load time.

When talking about redirect order specifically in Dynamic Mappings, you want to be especially careful.

Because a wildcard “*” can capture anything if the criteria is met, you can capture entire site sections and redirect them accidentally.

I’ve had to clean up redirect maps in the past because of misuse of wildcards.

Let’s walk through an example using “legacy” URLs. Let’s say our redirect map is the below and we’ve placed it in Dynamic Mapping.

/w/** i p,,,Search-Show,,cgid,women,{_querystring}
/w/old-womens-shoes/** i p,,,Search-Show,,cgid,womens-dress-shoes,{_querystring}

I’ve seen brands place a broad rule that captures a more specific one.

/w/** will capture any legacy URL that begins with /w/, including /w/old-womens-shoes/. Commerce Clouds says, the rule with /w/** takes priority because it was the first to meet the criteria.

3.5 A Note on Dynamic Mappings

Dynamic Mappings has been a life saver for me on several occasions. It’s nimble but rigid as you’d like it to be. It can also help you save a ton of time and still be accurate.

However, as you can tell with a few examples, it can also be intense to manage. I’ve also encouraged brands and team members to become friends with Microsoft Excel and Screaming Frog, as they’ve both been incredible tools when redirect mapping and QAing.

Summary

Well, I’m sure if you’re reading this post, you have your redirect work cut out for you. It can be daunting but my piece of advice is start early and understand your URL structures. Keeping this in mind, you’ll be able to discern what redirect logic would be ideal for your site.

Now, let’s move onto Robots.txt.

Get in Touch

Name *

Email Address *

Company *

Website *

Can you elaborate further on where you need my help? *

Send Message