SharePoint URL Basics
In SharePoint, it often helps to know the basics of how things are structured, and what the standard syntax of URLs is. When explaining concepts to newcomers, I often take for granted that URLs are obvious, but they’re not if you’re not used to paying attention to them. In this post, I’ll quickly go over some basics of a SharePoint URL structure, geared toward SharePoint newcomers who want to become power users, or who want to have a bit more advanced knowledge of it. The first couple of these, like web applications and site collections are really quite technical concepts, with managed paths and such, but I’m going to attempt to water-down and simplify it.
The beginning of the URL indicates its web app. It always starts with http:// and then there’s the name of your web app. For internal sites, this name has most likely been registered in DNS by a System Administrator. I’ll use the example http://intranet.contoso.com in this blog post, with Contoso being the company’s domain name. Most likely if your company has MOSS, you’ve got at least two web apps. Once for the main intranet, and one for the My Sites, such as http://my.contoso.com.
A site collection can live at the root level of the web application OR can be at a managed path. When a site collection is at the root of the web app, it’s simply http://intranet.contoso.com. BUT, if the site collection is at a managed path, it will be two levels below, like this: http://intranet.contoso.com/sites/marketing
In this example, the “sites” is the managed path. (managed paths are set up by administrators in central administration)
Sub-sites are created under site collections. So, following the example above, a sub-site called “promos” may have the URL of:
OR, it could even be
Site Collections and Sub-sites will also have something extra, the default.aspx. This is the main landing page of the site. So, the full URL of the first example would be:
When sending people the link to the site, or for that manner, linking to it in any way, it is not necessary to include the default.aspx at the end.
When using MOSS publishing sites, there is a “Pages” library involved (see library URLs in the next section). By default, the home page of a publishing site will be something like:
Each time you click <Site Actions> and choose to create a new page on your publishing site, it automatically gets created in this Pages library, with the URL that you specify on the new page screen. A new page called News on the same site will have a URL like this:
The URL of a document library can sometimes be confused with the URL of a sub-site. A library called “Presentations”, under the site called promos (in the first example of sub-sites), will have a URL of:
But a document library does look a bit different, because of the view part of the URL, which I’ll get into in the Views section below, but here’s what the full URL of the default view of the presentations library would look like:
Within document libraries, the document URLs consist of the names of each document. For Example, if I upload an Excel file called “Project Hours.xlsx” to my “presentations” library, the URL to that file is:
Lists actually do live under a folder called “Lists” in each site, so they’re easy to identify. A list called “budgets” will have a URL of:
And yes, there will always be that default view when you create the list, so the full URL will be:
RANT: Notice that there are no strange characters anywhere in these example URLs. Those little %20 thingies are a major pet peeve of mine. Each time I create new lists, libraries, views, and even columns, I never use spaces or apostrophes or any weird characters like that. This makes the URLs ugly (in my opinion). It does take a few extra seconds of time, and a few extra clicks, but I make it a habit to first create the object with underscores between words, and save it, and then go right back in and rename it. Since the URL is tied to the original name of the list or column or whatever, it will be nice and neat.
Views in lists and libraries each have their own URL. When I showed a customer the other day how to create a filtered view in a list, grab the view’s URL, and then use it elsewhere in the site to link directly to that filtered view, this customer thought that was the coolest thing ever. Basically, each view is a .ASPX file under the URL of the list. In libraries, there is a “Forms” folder, as you may have noticed in the example above, and in lists, there is no “Forms” folder. But lists do have that “Lists” folder that exists before the name of the list, as shown above. Anyway, so for example a tasks list in SharePoint has several default views, each with their own URL, as so:
Each individual item has its own URL, based on the type of form you want to open it in. There are three default forms in SharePoint:
- NewForm.aspx – This is the very first form that is used, when creating a new item in a list.
- DispForm.aspx – This is the display form, to simply display the item after it has been created (as opposed to editing it)
- EditForm.aspx – This is the form used to edit an item and then save it again.
Another important thing to know, is that every list and library item in SharePoint has its own unique ID, which is unique within that list or library. The ID is called “ID”, and is created in numerical order as each list item is created. This ID cannot be changed. Here is the syntax of the page on which you create a new task in a task list:
Here is the syntax of the very first task created in a task list:
Here is the syntax of the very first task created in a task list, AFTER it has been created, when you’re simply viewing it:
Notice that the New Form doesn’t have an ID associated with it. There is no ID, because the item hasn’t actually been created yet. It’s not created until you click OK that first time. Then, when we click “Edit Item”, this is the URL for that same first item (ID=1) that we created in the list:
But Laura, what’s all that &Source=BlahBlahBlah stuff at the end of URLs?
The source is where you’re going to be navigated back to, after the form is filled out, and it’s usually where I came from. Like what view I was looking at when edited the form. In this example, I was looking at the “By Owner” (byowner.aspx) view of the tasks list when I clicked to edit an item, and starting with the ampersand, this is what the URL looked like after the editform.aspx?ID=1
In one scenario, I used this source stuff to my advantage. I wanted the users to be navigated to a specific URL of my choosing after they filled out a certain form, so I created manual links in this certain site, all hard-coded with the Source information.
Oh yeah, I went there. In each SharePoint site collection, each list and library has a long unique ID. This does exist in URLs in some places, like list settings. For example, on a tasks list, I click to go to the list’s settings page, and the URL (after the name of the site) looks like this. I’ve put the GUID in bold:
Therefore, when I go to the site here, and decode the URL, I get this:
Okay, okay, I’ll stop. This post isn’t geared towards developers, so I’m not going to get any more into the nitty gritty here. I guess if you want to know more about the GUID, you’ll let me know. 😉
Hopefully, this has been a helpful and explanatory crash course for SharePoint newcomers who would like to get up-to-speed.
Great post, Laura! It would be great if you devoted a developer-centric post so that you could go into the details of GUIDS and their implications to devs. ba
Great post Laura 🙂 Quick Points: Using managed paths it is entirely possible for site collections to be at one level down (not always 2 levels down). By default /sites/ is used, but in many situations companies might make paths that are more direct (for various reasons). Just a heads up that it’s not an all the time thing. For all the subsites references – This is if you use team site templates, or WSS features. If you use MOSS features such as publishing then it will have a seperate /pages/default.aspx reference as an example. This also can change (and seperate welcome pages can be assigned) so that it can point to pretty much any name for a page. This is why as a user, for links, or anything else you should ALWAYS reference the address of the site and let SharePoint redirect you to the appropriate page (for welcome). As an example: Reference /marketing/ as the address and not /marketing/pages/default.aspx. One last point: Above you see I reference it as /marketing/ and not http://intranet.contoso.com/marketing. Why is this? Because you want to reference relative URL paths. This is important as often you might have multiple addresses for your intranet for different user accounts, ways of accessing it, or other reasons. Hope this helps, Richard Harbridge
Thanks Richard! Yep, I totally forgot to mention publishing sites. I’ll have to add that.
Excellent summary. Thanks.
Pingback: Email Hyperlink to Form | @WonderLaura