Note: This topic is intended for administrators and developers with administration access rights in Episerver.
You can easily add and remove websites from an Episerver installation, perhaps to create short-lived campaign websites.
On the Config tab > Manage Websites, you can see an overview of existing websites in your installation. These websites share the same database, content types and templates, making it easy to set up new websites. You can also define whether content, such as blocks, folders, and media , should be shared or site-specific.
You can add new websites in the following ways:
- Single-site setup lets your installation have one CMS site mapped to one IIS instance. The IIS mapping is with a wildcard or a specific host name. You can have several single sites with separate databases and code base on the same server. In that case, you have a separate admin interface for each site.
- Multi-site setup lets you have a single CMS site as a base (default site), and can create new sites in admin view that share the same root page, database and code base. The additional sites are automatically mapped and require no additional configuration (if the base site is mapped to wildcard), or they need manual configuration of host name.
When you work in a multi-site setup, you see all sites in the same interface, which makes it easy to work with them. One reason to run a multi-site setup with specific host name mapping (that is, a different IIS instance per CMS site) is that you can use different application pools, which means that if one site fails, the other sites continue to run.
The following requirements must be met to manage websites in admin view:
- Available licenses. A notification message informs you of the number of sites allowed by the license available for the installation. See License Information on the Admin tab for information.
- Unique URL. In admin view, each website must have a unique URL and start page in the content tree. Start pages cannot be nested.
- Domain mapping must be configured in IIS.
- For multi-site setup, the IIS must be configured to respond to any host name.
- For single-site setup, each separate CMS site must have an IIS site configured.
On the Websites tab, you can click a site to see detailed information about its settings. You can also update the site information.
To add more sites to your installation, click Add Site. Add the following information when creating and updating site settings for your installation:
|Name||Type a name that identifies the website, such as Example Site.|
Enter the URL for the site, such as https://examplesite.com.
If your CMS or Commerce site is using Unicode characters in the URL segments, internationalized domain names should be registered in PunycodePunycode is a way to transform Unicode to ASCII used for Internet host names. format. See also: Internationalized Resource Identifiers (IRIs) on Episerver World.
|Start page||Select the page to which the visitor is sent if only a host name is specified.|
|Use site-specific assets||Select this check box to ensure that assets, such as blocks and media, for this site are not available for use on other sites in the installation. This option affects the folder structure editors see in the assets pane.|
Optional. Enter a specific URL, such as examplesite.com. If you do not name the website, it is automatically named with the URL you have entered.
One of the sites in the installation must be bound to the * host name. That site is used as a fallback when an exact match for the host name used by the visitor cannot be found. This setting is less important in a single-site scenario, because you can have only one site configuration. However, in a multi-site scenario, you must make sure that host bindings active in IIS are mirrored in the corresponding site configuration. For example, you want to add examplesite.se.
Usage: The host name list is evaluated by the application in two different scenarios:
Note: A wildcard * mapping must be accompanied by an explicit host name to support cross-site link generation.
|Culture||Select the default language for when a visitor accesses the website using the host name.|
|Scheme||Select the preferred scheme to be used for this host. This affects only the generation of links to the site as incoming requests are matched to the host name regardless of scheme.|
The following example shows a default website with several host names, languages and redirection types configured:
This example would lead to the following behavior:
- A request to https://redirected.se is redirected to https://examplesite.se using an HTTP 301 response.
- A request to https://www.examplesite.se is served the Swedish content.
Note: Canonical links added in the templates should point to https://examplesite.se
- A request to https://redirected.no/page/ is redirected to https://examplesite.no/page/ using an HTTP 301 response as this is the only Norwegian host that is not redirected.
- A request to https://redirected.com is redirected to https://examplesite.com using an HTTP 302 response as per the wildcard specification.
The following example shows a campaign website:
Sorry about that
Why wasn't this helpful? (check all that apply)
Thanks for your feedback.
Want to tell us more?
Send an email to our authors to leave your feedback.
Thanks for taking the time to give us some feedback.