SEO Page Generator Best Practices
When customizing your SuiteCommerce web store, it's important to consider how your changes might affect the SEO page generator. If the server-side rendering (SSR) malfunctions or fails entirely, partial content may be served to search engines, potentially harming your SEO. Therefore, when you test your changes, treat the SEO page generator like another browser you're testing in.
JavaScript Standards
The SEO page generator only supports JavaScript as defined in ECMAScript 5.1 (ES5.1):
-
In your extensions, don't use JavaScript from newer versions, such as the
let
andconst
keywords or template literals. -
When customizing the core code of a SuiteCommerce Advanced site built using 2019.2 or newer, you can use TypeScript and modern JavaScript if you run it through the developer tools' standard transpilation process that converts it to ES5.1.
-
If a third-party plugin or library uses JavaScript newer than ES5.1, it must be excluded from SSR using the methods detailed below.
Excluding Content from the SEO Page Generator
Remember that the SEO page generator's role is to create a version of your web page so a search engine can crawl and index it. Accordingly, there may be customizations to your web store that are designed to help human users, like a chatbot plugin, but these aren't important to web crawlers. In some cases, these customizations may negatively affect web crawlers by making it harder to parse the page, causing extra content to get indexed, or using up crawl budget.
When this happens, you should prevent this JavaScript from being included in the SSR process. To help developers exclude content, the core code and extensibility API includes utility functions for wrapping JavaScript that shouldn't be rendered by the page generator.
The best practice, which is available when writing extensions and modern versions of SuiteCommerce Advanced, is to use a method on the Environment component.
// Using the extensibility API (SuiteCommerce and SuiteCommerce Advanced Aconcagua (R2) or newer
// In an extension entry point file's mountToApp() function
var Environment = container.getComponent('Environment');
if (!Environment.isPageGenerator()) {
// Code that won't run when being rendered on the server
}
If you cannot use the extensibility API, you may use a utility function attached to the SC
global variable.
// A simple check
if (!SC.isPageGenerator()) {
// Code that won't run when being rendered on the server
}
// Alternative function
if (SC.ENVIRONMENT.jsEnvironment === 'browser') {
// Code that won't run when being rendered on the server
}
Suggestions for Content to Exclude
Here's a list of things that can cause problems for SSR, or might be unnecessary, so you may want to exclude them from the page generator.
-
JavaScript that was introduced in a version of ECMAScript newer than 5.1.
-
Plugins and libraries that don't benefit the page's content, such as chatbots, advertising, marketing, analytics, and similar tools.
-
jQuery plugins and methods that only add UI benefits, such as creating transitions or animations.
-
Calls to web APIs that add new functions for human users, such as the Geolocation API.
Limits
There are several governance limits that apply to any page sent for SSR, including memory usage, CPU usage, and execution time. If the page generator stops running because of one of these limits, it usually means that there's a problem with the JavaScript, such as recursion, forgotten timers, unresolved callbacks, or too much DOM querying.
-
A web page should load as fast as possible, but the page generator will generally time out after 20 seconds.
-
If the page generator can't finish SSR, the generated content is returned as-is with a 206 (Partial Content) status code.