SharePoint 2010 & 2013 URL Cheat Sheet

05/11/2012 update: since writing this, the  has been updated to include a supported limit of up to 20 Web Applications per SharePoint 2013 farm. This is in line with what I have heard from various SharePoint MCMs.

Designing a URL structure for a SharePoint farm sounds like a straightforward task. Surely it’s just a case of creating a few Web apps and corresponding DNS entries, right?

The challenge is balancing simplicity with scalability. Most people who have managed IIS know what a host header is so the traditional approach of creating a Web application for each host-named URL often seems like a good idea when first starting out.

Sooner or later, however, you will probably run into one of the following limitations:

  • ​A limit of around 20 Web apps ​per farm (a SP2010 recommendation)
  • A limit of  per Web server
  • A  per IIS Web site
Although I’d like to explore the reasons for the above limitations (as I ), I thought I’d start with a high-level set of recommendations in the form of a cheat sheet. As you will see, each option will involve some form of compromise but I am slightly biased toward the host-named site collection approach (especially as we now have the Set-SPSite cmdlet). In fact, even  – given that they use them for Office 365 that isn’t very surprising.
Note that the options below are not mutually exclusive – it’s entirely possible that your farm will include a mixture of Web applications containing both host-named and path based site collections.
I would really like to hear about your experiences with building scalable SharePoint URL namespaces as it’s something I often get asked. I’m sure you will think of something that I haven’t considered.
One important caveat I would like to add is that I have not yet had a chance to really test the new cmdlet other than briefly on a SP2013 VM I built a couple of weeks ago. Hence, I would strongly recommend that you test your scenario extensively before spending time – and taking the risk – of implementing in a production environment. Heck, the beta has only just been released :-). ​​
Requirement Capability Benefits Drawbacks Example
Only a few unique host named URLs (less than 20/farm) – e.g. a corporate intranet. Host-named Web applications Easy to manage; familiar to IIS admins Doesn’t scale beyond ~ 20 Web apps. Web app 1 (host-named): 

Site collections (path based):





Web app 2 (host-named): 

Site collections (path based):




Web app 3 (host-named): 

Site collections (path based):

/ (root)


IIS App Pool isolation between host-named URLs Host-named Web applications See above. Doesn’t scale beyond 10 Web apps (due to a supported  See above; each Web app resides in its own application pool.
Out of the box self-service site creation Host-named Web applications See above. See above. See above. More info available on Microsoft’s 
More than 20 unique URLs per farm – e.g. a hosting scenario or large corporate farm. Host-named site collections (HNSC) Hugely scalable (supported limit of !) More complex to manage- need an additional IP per Web application containing HNSCs (or) Web app 1:No host header, unique IP address 

Site collections (host-named):


Web app 2:No host header, unique IP address 

Site collections (host-named):


Web app 3:No host header, unique IP address 

Site collections (host-named):

To make site collections available via multiple URLs – e.g. if hosting content to internal users and customers. Option 1: Alternate Access Mappings (AAM) 


Access one site collection with multiple URLs for different use cases Web app 1 (host-named): 

Default zone (Fully qualified domain name):


Intranet zone (host name only):


Option 2: HNSC with Cmdlet – new in SP2013 Supports multiple URLs in a scalable manner. Managed via PowerShell only. Web app 1:No host header, unique IP address 

Site collections (host-named):


Additional Site collections URLs:


To use standard HTTP ports (80/443) – why wouldn’t you do this? J All approaches support this. Sites are easily accessible and managed
SSL All approaches support this. Transport security Requires a certificate

One thought on “SharePoint 2010 & 2013 URL Cheat Sheet

  1. Pingback:

Comments are closed.