This blog post provides information about managed web sites in the Sitecore ASP.NET CMS, including explanations of the default managed sites and tips for configuring multiple managed web sites. For more information about configuring multiple sites with Sitecore, see Configuring Multiple Sites on the Sitecore Developer Network (SDN).
Managed web sites represent published sites, such as an organizations marketing web site, but also represent the CMS itself and specific functions within the CMS, such as authentication. A single Sitecore instance uses multiple web sites to provide content management, content delivery and additional features. Each Sitecore instance can manage any number of logical web sites using a single instance of IIS.
You can bind any number of host headers to a single IIS web site. Each web site managed by a Sitecore instance can have a unique host name (for example, www.domain.tld and partner.domain.tld), or any number of managed web sites can share a host name (such as localhost).
The SiteResolver processor in the httpRequestBegin pipeline defined in the web.config file sets the context site to the first /configuration/sitecore/sites/site element in the web.config file with attributes that match the HTTP request. Actually, Sitecore appears to first look for a site.config file in the subdirectory corresponding to the path part of the requested URL, but I assume most solutions don't include such files. You could of course write your own site resolver processor. For more information about pipelines, see my blog post All About Pipelines in the Sitecore ASP.NET CMS. For more information about the Sitecore context, see my blog post The Sitecore Context.
The most important site attributes for determining the context site seem to include:
An HTTP request can only activate a site if the hostName, virtualFolder and port match. The first match sets the context site and the SiteResolver does not evaluate the request against additional sites.
In cases where you have access rights, you can use the sc_site query string parameter to specify a managed site for the request.
The default Sitecore configuration includes ten default managed web sites:
Of these, shell and website are typically the most important to Sitecore developers. Because of their impact on the context site (including the context database and the default content database), always consider which managed web site a request activates, and how this affects other properties such as the context database. For example, put Sitecore user interface components under /sitecore/shell or /sitecore modules/shell so that they share context with the Sitecore user interface, and don't use these subdirectories for other purposes. If you don't follow this practice, the Sitecore context might not contain what you expect.
Sitecore implementations most frequently add additional managed web sites before the default published site named website, typically specifying a hostName attribute but no virtualFolder or port. The rootPath and startItem attributes of the site determine the home item for the managed web site.
When you add a managed web site, remember to update the publish:end and publish:end:remote events defined in the web.config file to clear output caches for the web site after publishing.
That's all I could think of for now to write about managed web sites in Sitecore. If you have additional information or links about this topic, please comment on this blog post.
Updates 27.June.2011: For information about extending the SiteInfo class with properties to represent custom attributes of the /configuration/sitecore/sites/site elements in the web.config file, see Benjamin Vangansewinkel's blog post Add a custom property to the site node. You can use the Sitecore.Sites.SiteContextSwitcher class with the C# using statement to set the context site for a block of code.