When moving Sitecore project from traditional Server Side Rendering with CD servers or JSS to Static Site Generation you change publishing and delivering approach from this:
into something like this:
This change has some implications, which can easily be overlooked at the start of the project. Here are some of them:
Custom Redirects
Typically in Sitecore solutions redirects are either implemented with custom module/pipeline processor or using IIS URL Rewrite module. With SSG none of them will work, remember we no longer have CD server which can execute the logic, we don’t even have IIS! To handle redirects we have to use CDN. For example with Akamai we can use either Redirect Behaviour for simple use cases, like adding www. or redirecting http to https:
or Akamai Edge Redirector for more complex scenarios:
Resolving Languages
Most common approach to handle languages in Sitecore based website is to use language prefix in the url for example: “/news” or “/en/news” for English version “/es/news” for Spanish or “/fr/news” for French.
With SSG you have to generate separate html files for pages in each language. You can either generate each language to different storage account and then configure CDN to use different origin, depending on path or cookie, or to store them all in a single Storage Account inside sub-folders matching language prefixes:
Keep in mind that out-of-the-box Sitecore language resolving based on a cookie won’t work with SSG. If you want to keep this behaviour or resolve languages by GeoIP, you have to implement this logic at the Edge inside CDN configuration.
404 Page
Usually “Page Not Found” in traditional Sitecore is implemented using custom pipeline, which shows custom 404 content if context item is not resolved for given path. With SSG this won’t work, but if you host your static website on Azure Storage Account you can configure relative URL to a custom page which will be shown when HTTP 404 status occurs:
To generate content driven 404 page with Next.js check guide prepared by Uniform team.
Forms Submit
Custom Forms
When you have custom form which posts data back to Sitecore to execute some logic, you need use “action” attribute, to explicitly indicate your controller’s action URL where this POST request should go:
Additionally, you can pass current context item ID in sc_itemid parameter, so Sitecore will automatically resolve context item inside the controller.
Remember that your local storage most likely is not able to handle HTTP POST requests, so you need to configure your CDN to use different origin based on the type of the traffic, for example all paths starting with /api/* shall use Sitecore origin and the rest will go to static storage account.
Sitecore Forms
Sitecore Forms don’t work on static generated pages due to AntiForgeryToken used inside Forms for both React and MVC implementations (when you generate static page with a form, token value will be the same for all users and won’t match the value from cookie in post request and the entire functionality won’t work). To overcome this issue you can either remove token validation (but it will be less secure), or migrate to non-Sitecore forms. You can find a guide for both approaches in here.
Build Time
Finally, pay attention to your front-end application compile & bundle time. It should be as fast as possible, so static site generation will not affect your Content Authors work. It may become an issue if you have multiple languages and larger authoring team.
For example if time of single generation is 1 minute and you have 5 languages, published changes will be live in all languages after 5 minutes. This may be even more if other Authors published their changes and your generation works on a single queue.