There are lots places in msdn sharepoint forums and blogs where these terms are used and I am confused between them. Can anybody clarify?

up vote 23 down vote accepted

Let me see if I can explain pages in SharePoint without making you even more confused.

The difference between the different kind of pages very much depend on whether your view is as developer or as end user. As you're refering to MSDN I'll start with the developer view.

SharePoint Pages from a developer point of view

From a developer point of view there are three main kind of pages in SharePoint: Application Pages, Master Pages and Site Pages

Application Pages

Application pages are pages stored in a folder below {SharePointRoot}\Template\Layouts they are accessed through a Virtual directory _layouts which is present below all SharePoint sites. The behave as completely ordinary ASP.NET pages except that they know which SharePoint site they are accessed as part of. They should be/are used for things which should be available on all sites like different kind of settings.

Master Pages

Master pages are just ordinary ASP.NET master pages which can be used to control the part of the html which is common to all pages in a Site Collection, like overall layout and navigation. The contain ContentPlaceHolders which is then replaced by the content of Content controls on the individual pages.

Site Pages

Site Pages are a very special kind of pages. They are (at least initially) usually stored in the folder for the corresponding Feature/Site Definition. They become available through a <Module> element in a Feature/Site Defintion or though code like "add page", which when the feature is activated (or the Site Definition provisioned)(or the code runs) will create a record in the content database for the site linking a URL to the file in the file system.
At this point the site page is uncustomized (or Ghosted (old terminology)). But using SharePoint Designer, the object model or browser the end user may change the content of the page for a specific URL (in a specific site). The changed page is then stored in the content database and is now customized (or Unghosted) and has some limitations due to security (can't contain server side code in markup, may only inherit from safe base classes and may only contain controls which are safe).

Site Pages are the pages you'll normally let the end users use. They come in a number of variations:

Pure site pages

(My own term) Standard ASP.NET pages where the developer controls what's on the page. Very uncommon.

Web Part pages

Pages inheriting from Microsoft.SharePoint.WebPartPages.WebPartPage containing a number of WebPartZones where the developer/end user can add web parts to control what the page shows/can do. In previous versions of SharePoint very common and very powerful.

Wiki pages

The new way of creating content pages. Very similar to web part pages, but instead of having multiple web part zones it usually only have one which is hidden. It then has a Wiki field which can easily be edited and can contain markup which will make the web parts from the hidden zone appear inline in the content (as divs)

It can be combined with multiple WebPartZones to allow more control of placement of web parts.

Publishing Pages/Page layouts

From a developer point of view publishing pages isn't really pages, but listitems which is bound to a Page Layout. The Page layout on the other hand is almost what I call pure site pages, but can only be displayed by a corresponding publishing page listitem, they contain controls which allows display/editing of the columns in the listitem.

SharePoint Pages from a end user point of view

Settings pages = Application pages

Pages where they can change some settings, but have no control of what's on the page

Web Part pages

The standard type of page in a site which started as a blank site. Allows the end user to put web parts in different zone, which makes them ideal for building "mashup" application, but hard to create ordinary content in.

Wiki pages

The standard type of pages in collaboration sites. Allows very easy editing of content and the mix-in of web parts when needed. Very good for unstructured content.

Publishing pages

The standard type of pages in publishing sites. The structure of the content is very much controlled by the page layouts, usually very limited use of web parts. Very good for making the site look consistent.

  • As a user in SP 2010 when looking at Site Settings >> Site Content and Structure I see a Pages entry and a Site Pages entry. According to your definitions Pages == Publishing pages and Site Pages == Wiki pages, is that right? Or are 'pages' actually 'web part pages'? (screenshot: i.imgur.com/UEYyExA.png) – matt wilkie Feb 1 '13 at 17:17

Wiki page is like wikipedia pages. We allow user to edit the pages.

Application page is the page which we can use the same page in different site collections or websites. Suppose if we want to show custom error page with nicely designed interface in each of our site collection then we can create an application page and give the redirect url to that application page. Application page cannot be edited by user. We should edit with visual studio. Programming knowledge require to edit.

Webpart page is nothing but the where we can add webparts to a page. We cannot add webparts except this webpart page. It will internally take care of how the webpart should render in a page etc.

Publishing page Publishing pages are available only in publishing sites. In publishing sites, authors and approvers use the publishing feature to create content and then make it available for site visitors. Usually, a publishing site has an approval workflow enabled, so content is reviewed and approved prior to being published.

See this link You can find this link by googling.

  • can I upload a publishing page in site pages library? Can I convert a wiki page to web part page? can I upload wiki page to pages library? – Prashant Lakhlani Oct 30 '12 at 6:10

Here are a few more differences I've encountered when working with both Wiki Pages and Web Part Pages, from a more practical standpoint:

Wiki Pages

  • Can place web parts inline with text and freely drag and drop them anywhere, including, for example, within cells of an HTML table, providing a means for very precise layout.
  • Can choose from 8 "Text Layouts", which mainly differ in number of columns and presence or absence of header and footer.
  • Can change the Text Layout of an existing page at any time. When changing the Text Layout on a page that already has content in a region that is not included in the new layout you select, SharePoint will move that content to the beginning or end of another region; when layout changes add regions they will always be empty.
  • If versioning is enabled in the page library, a new version will be created whenever the page is saved.
  • Adding rich text content to the page is simply a matter of clicking and typing.
  • It is possible to accidentally make changes that partially or completely break the layout of web parts placed within the page. This is basically because each web part placed into a wiki page is represented by a pair of divs wrapped within another div, and sometimes when you click a spot you want to add text to the page, or when you drag and drop a web part, the insertion point SharePoint decides it thinks you wanted may wind up inside a web part's outer div. Once this happens you might have trouble getting at the "Edit web part" menu on that web part, or sometimes on all web parts on the page.
  • In SP2010 (don't know if this was fixed in SP2013), after placing an Excel Web Access web part on a wiki page and saving the page, subsequently clicking "Edit Page" will get stuck indefinitely on "Loading...", which can only be resolved by closing that web part via web part maintenance view.

Web Part Pages

  • Can place web parts into web part zones and change their relative order within those zones, but cannot easily make finer adjustments to their positioning.
  • Can choose from 8 "Layout Templates" when creating the page, most of which are a bit more complex than the Wiki page's Text Layouts. In most cases, web parts are restricted to vertical stacking within a zone, but a few layouts have one zone with horizontal alignment. Example: SP 2010 GIF for Web Part Page Layout Template: "Left Column, Header, Footer, Top Row, 3 Columns"
  • Cannot change the Layout Template once the page is created.
    • (For this reason, I usually choose one of the most "complex" layouts when creating a web part page; any zones with zero web parts will be collapsed to a few pixels of whitespace until/unless I add something to them later.)
  • Versions are not created when changing the contents of the page. (Note: there is a type of change that will create a version, but I don't know what it is. It isn't anything I commonly do though; one web part page I've edited many times has exactly two versions.)
  • To add rich text content to the page, must add a Content Editor Web Part (CEWP) to one of the web part zones. Cannot place a web part inside of the CEWP.
  • May be easier to update programmatically, since each web part has the integer properties "Zone" and "Index" which define their positions in the layout - in Wiki pages there is only one Zone, and Index is irrelevant because the web parts are inline with the wiki text.

The video series SharePoint pages I: An introduction on the Microsoft Office website describes the differences between wiki pages, web part pages, and application pages from the viewpoint of a business user. Note: Application pages are referred to as system pages in the video series.

To summarize the video series:

Application pages provide tools for working with the SharePoint site, but a business user cannot edit an application page. When looking at the URL, all application pages reside in the /_layouts/ folder.

A business user can edit wiki and web part pages. Wiki pages are newer and easier to edit; web part pages are older and more difficult to edit.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.