Manage websites
Note
This topic is for CMS administrators and developers with administrative access rights.
Add and remove websites from an Optimizely Content Management System (CMS) installation to create short-lived campaign websites.
Go to Settings > 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 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 hostname. You can have several single sites with separate databases and code bases 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 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 need a manual hostname configuration. 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 (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.
Requirements
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 the 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 –
- The IIS must be configured for multi-site setup to respond to any hostname.
- For a single-site setup, each separate CMS site must have an IIS site configured.
Create and update a website from the Settings view
On the Manage 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 Create Website.
Add the following information when creating and updating site settings for your installation:
Site setting | Description |
|---|---|
Name | Type a name that identifies the website, such as Example Site. |
URL | Enter the URL for the site, such as https://examplesite.com. If your CMS or Optimizely Commerce Connect site uses Unicode characters in the URL segments, internationalized domain names should be registered in Punycode format. See also: Internationalized Resource Identifiers (IRIs) on Optimizely World. |
Start page | Select the page to which the visitor is sent if only a hostname is specified. |
Use site-specific assets | Select this check box to ensure that this site's assets, such as blocks and media, are not available for use on other sites in the installation. This option affects the folder structure editors see in the assets panel. |
Host name | 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 * hostname. That site is used as a fallback when an exact match for the hostname 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 ensure that host bindings active in IIS are mirrored in the corresponding site configuration. For example, you want to add examplesite.se. Usage: The hostname list is evaluated by the application in two different scenarios:- Request routing – When serving a request, the application evaluates the host list to see which site and language (culture) should be served. |
- Cross-site linking – When generating links to another site or culture, the host list is evaluated to find the hostname for constructing the link URL.:::hint{style="info"} Note
An explicit hostname must accompany a wildcard * mapping to support cross-site link generation. ::: | | Culture | Select the default language for a visitor accessing the website using the hostname. | | Type | * Primary host – A primary host is the preferred hostname when generating links between sites or languages (cultures). If no host is defined as primary, the first non-redirected host and non-edit host are used. You can define only one primary host per language plus one unbound primary to any language.
- Edit host – An editing host is the preferred hostname for editing a site. This hostname is used for links between sites when the users are in the editing view. The primary or first-found host is used if no editing host is defined. You can define only one editing host per site and not bind it to any language. Users are not forced to go to the editing host for editing and remain on their current host if the editing view is requested from another host on the site.
- Redirection host – A redirection host defines that requests using this hostname are redirected to a different hostname. Such requests are redirected to the primary host or, if none is defined, the first non-redirected host found. You can set redirection to permanent or temporary, which determines the type of HTTP redirect status that should be used. Redirected host names are never used when generating links. Any number of redirection hosts can be defined as long as there is at least one primary or standard host name bound to the same language. | | 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 hostname regardless of scheme. |
Example: Default website with different host names, languages, and redirection types
The following example shows a default website with several hostnames, 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 not redirected.
- A request to https://redirected.com is redirected to https://examplesite.com using an HTTP 302 response per the wildcard specification.
Example: Campaign website
The following example shows a campaign website:
