Salesforce is fast positioning itself within the marketplace as one of the go-to platforms for high-traffic, enterprise-level e-commerce businesses, and according to the latest W3Tech data the platform has been adopted in 2020 by companies such as the WWE, Halfords, and Dolce & Gabbana.
As you may know, Salesforce Commerce Cloud has several frameworks and integrations to allow webmasters and administrators to create custom storefronts and community pages; each can add its own set of challenges and nuances to the SFCC platform as a whole.
In previous articles, I’ve talked about add-ons such as SFRA (Storefront Reference Architecture) and its potential impact on speed. In this article, I’m going to focus on another SFCC framework, Lightning.
If you’re interested in Salesforce Commerce Cloud, you might also like this SEO focused research, in which we analyzed1,926 live Salesforce Commerce Cloud websites for SEO issues and trends.
What is Salesforce Lightning?
Lightning is a custom Salesforce Commerce Cloud framework that enables an easier route to develop responsive applications and storefronts. Lightning includes:
- The Lightning Component Framework – a UI development framework that removes some technical debt/barriers to development
- The Lightning App Builder – a visual page builder that utilizes out-of-the-box, and customized, Lightning components.
- The Lightning Experience Builder – similar to the App Builder but designed to create and build community pages visually and quickly, without code.
Some Salesforce components utilize Lightning components also, such as Aloha and Partner Central.
It’s also worth noting that Lightning Communities differs and is not compatible with Salesforce Tabs + Visualforce Communities.
SEO considerations for Lightning Community pages
Salesforce’s documentation identifies SEO for the Commerce Cloud storefront and for Communities as being two separate “beasts”, so this is why in this article I’m looking at solely the recommendations for Communities.
So what are the basics that Salesforce tell you to do to make sure that:
your community is optimized to deliver the most SEO ‘juice’ to deliver value to your customers and your business.
Dissecting Salesforce’s Advice
Setting Your Preferred Domain
Within the Experience Builder, there is a setting to set the preferred domain (e.g. HTTP/HTTPS and non-www./www.).
This is separate to setting the preferred domain within Google Search Console, and also won’t ensure that your non-www. and non-HTTPS versions redirect to the desired, secure, URI path.
Cached Content Snapshots
By default, Communities caches a “snapshot” of your content every 15 days and using request chain filters; it appears to serve this content to Google.
If your content is likely to refresh more often than this, such as price changes or stock and availability changes, or even fresh reviews surfacing sooner, you will need to manually refresh the page’s snapshot from the SEO settings tab within Experience Builder.
Robots.txt File Configuration
The advice within the Salesforce Trailblazer Community articles is to disallow all pathways within robots.txt, and then declare the specific crawl paths you want to be indexed. For example, the below configuration is for a Visualforce page:
User-agent: * Disallow: / # hides everything from ALL bots Allow: /<path-prefix-1>/s # add path you want to open to bots Allow: /<path-prefix-2>/s # add path you want to open to bots Sitemap: http://<community_URL>/s/sitemap.xml Sitemap: http://<community_URL>/<sub_path>/s/sitemap.xml
My advice here would be to do the opposite, and allow total access – only disallowing URI paths and subfolders you don’t want being indexed.
Setting up Google Search Console & Bing Webmaster Tools
Still referred to as Google Webmaster Tools within Salesforce’s documentation; apparently, the most reliable way to verify your WMT accounts is to use the <head> tag.
Google Webmaster Tools and Bing Webmaster Tools require some form of verification for your site. One of the most reliable choices is by adding a meta tag to your community <head> markup that the tools sites provide for you.
The most reliable way, however, is with either an HTML file upload or through the DNS. That way with a code push that alters the
<head> you won’t accidentally remove verification, access, and data.
The HTML tag method, however, is the most accessible through the Experience Builder and can be done through a copy and paste, meaning the admin/storefront manager doesn’t need developer support or access to the server or infrastructure beyond the storefront backend.
Multilingual Knowledge Articles
International SEO can be tricky, especially when so many large websites have it wrong – but don’t seem to be affected by it. However, in my opinion, the below advice from Salesforce is not one to be followed:
If your org supports multilingual Knowledge articles, we recommend not replacing the URLs of translated articles with language-specific URLs. Instead, keep the same URL as the base language article.
With the XHTML example provided being:
<xhtml:link rel="alternate" hreflang="language_code" href="page_URL?language=language_code" />
If you’re creating multilingual versions of a page, you should use separate URLs and reference them using Hreflang in either:
- The <head>
- The XML sitemap
- The HTTP Header
For more on international SEO, click here.
Other Trailblazer Notes
Other advice from the Trailblazer support articles can be summarised as:
- Make sure your title tag and meta description are good
- Check your XML sitemap only contains URLs you want it to
- HTTPS is better than HTTP
- 301 redirects are good and should be handled by your DNS provider