Configure custom error pages in multisite or multilingual environment

Use this article to configure handling custom errors using Sitefinity CMS pages, where each site or each language has its own version of the custom error page.

Multisite mode 

When managing more than one website in your Sitefinity CMS project (Multisite), you can have a different custom error page for each site. This enables you to modify the custom error page according to the specific website needs, for example apply different design.

As long as each of your websites has a custom error page with a URL matching the one you have specified when configuring your custom errors in the web.config, Sitefinity CMS will serve the proper page for the corresponding site. For more information see: Custom error pages.

For example, if you have 2 sites - https://myfirstsite.com, and https://mysecondsite.com, and each of them contains a custom errors page with a URL https://myfirstsite.com/404 and respectively https://mysecondsite.com/404, and your custom errors have been configured to handle the 404 status code by serving a page with URL /404, then as long as users browsing https://myfirstsite.com encounter a resource not found (404) error, https://myfirstsite.com/404 error page will be served, and the ones, who encounter a 404 error on https://mysecondsite.com will get the https://mysecondsite.com/404 page served. 

Multilingual mode 

If your site has more than one languages defined, you might want to offer users a friendly custom errors page for the current language version of the site. To achieve this you must introduce different custom errors configurations in your we.config using the <location> tag. The <location> tag enables you to specify different configuration behavior for different sections of your website. By default, Sitefinity CMS uses a prefix (directory) to resolve each language for the site. For example, the Bulgarian language version of the content will be served on https://mysite.com/bg/. You can use the language prefix to specify the path for the <location> tag, and thus have the configuration inside apply only for the /bg/ path. The following sample demonstrates the above described configuration:

 <location path="bg">
 <system.webServer>
 <httpErrors errorMode="Custom">
 <clear />
 <remove statusCode="403" subStatusCode="-1" />
 <remove statusCode="404" subStatusCode="-1" />
 <remove statusCode="500" subStatusCode="-1" />
 
 <error statusCode="403" path="/bg/error-pages/403" responseMode="ExecuteURL" />
 <error statusCode="404" path="/bg/error-pages/404" responseMode="ExecuteURL" />
 <error statusCode="500" path="/bg/error-pages/500" responseMode="ExecuteURL" />
 </httpErrors>
 </system.webServer>
 
 <system.web>
 <customErrors mode="RemoteOnly">
 <error statusCode="403" redirect="~/bg/error-pages/403" />
 <error statusCode="404" redirect="~/bg/error-pages/404" />
 <error statusCode="500" redirect="~/bg/error-pages/500" />
 </customErrors>
 </system.web>
 </location>

For more information on configuring <location> tags in your web.config, see: MSDN: How to: Configure Specific Directories Using Location Settings.

NOTE: If your website is using different domains (for example, https://bg.mysite.com and https://us.mysite.com) to serve multilingual content, you do not need to follow the approach for configuring a <location> tag, described above. You can have one configuration for custom errors in your web.config, and different translations of your custom error pages for each language. As long as the URLs of your custom error pages match in each language,  the proper page will be served for the current language domain users are browsing. This is because the specified paths are relative and are always resolved for the current domain. For more information about configuring how the multilingual URLs behave, see: Language settings.

Was this article helpful?