In a multisite solution, you need to decide whether the sites can share the same code base, and if there is content that the sites cannot share.
## What is multisite?
Optimizely Content Management System (CMS) can host multiple websites using a shared database, and the same content assets. You can add new sites from the CMS admin view, and the start pages will share the same root page in the content structure. See [Setting up multiple sites](🔗).
In DXP, sites use the same Web App, and share the same code base and Optimizely Search & Navigation index. You can have an unlimited number of sites in the Web App. Common scenarios include solutions for the fashion industry, where sites may share the same content types and controllers, but each brand use different views and styles, resulting in different outbound presentations.
## Development strategies
### Code base
Consider how to organize your code using standard conventions and site-specific structures. Can the sites share the same code base, or do you need to separate them? Can you work with shared models and controllers, but use different views?
### Content types
Restrict blocks to a single site or share blocks across all sites. If possible, limit the number of site-specific content types (pages, blocks, media).
Limit access to specific content types by using roles/permissions and the [AvailableContentTypes](🔗) attribute.
Limit ability to add content by using the [AllowedTypes](🔗) attribute on content areas.
Editors with access to multiple sites will have access to all.
### Display channels/options
Defined [display channels](🔗) and [display options](🔗) are available across all sites. Consider how to manage these if different websites have different requirements. For example, you can use [TemplateResolver](🔗) to detect which template should be active for a specific site.
Forms in a multisite solution are available for selection across sites. To restrict access to forms, you can [apply access rights on form folders](🔗), just as you do for other types of content items. You can also create a specific [virtual role for managing forms](🔗).
Optimizely offers built-in categorization functionality to tag content, and build features based on this. Categories are shared between sites in a multisite solution. You can organize categories by site in a hierarchical structure, or you can build your own category system.
### Personalized recommendations
Added visitor groups are available for all sites in edit view. You can create a specific [role for managing visitor group criteria](🔗) (optional), and ensure that editors working with content personalization are included in the group, and well-aware of which visitor groups to use in what context.
### User access
If sites in a multisite solution are administered by different editors, you can set up site-specific groups to provide editing access in selected parts of the shared content structure. See [access rights in the Optimizely user guide](🔗).
While available for on-premises versions of Optimizely,_Lucene.NET is not supported_ with DXP. Instead, [Optimizely Search & Navigation](🔗) is included providing advanced search features, and should be leveraged in your search implementation.
Sites with Optimizely Search & Navigation share the same index, and optimizations apply to all sites. Each site has its own partition of the index, and a shared partition for shared content. You can view search results and statistics per site or across all sites; you can limit search results per site.
When translating user interface texts using the built-in localization service, you can create one or more XML files with any name, in the _~/Resources/LanguageFiles_ folder.
Content types may have the same class name in code, using a different namespace and class name. To ensure that users can differentiate these, use unique _DisplayNames_. See [Localize the user interface](🔗).
### Custom cultures
Custom cultures such as ”sv-gb” and ”en-fr”, are currently _not_ supported for solutions running in Optimizely DXP. Cultures are part of the standard operating system, and require changes to the registry to modify or add them. This modification is not allowed by the Azure App Service.
See the blog post [Implement custom cultures, CultureInfo, localize Azure App Service](🔗) for more information.
### Apps (add-ons)
Installed add-ons are available across all sites. However, you can restrict access through configuration by setting access rights for the location paths.
You can debug on your local machine and in the _Integration_ environment. Debug in other environments only when absolutely needed. See [Troubleshoot](🔗).