Sitemaps and Site Indexes: What They Are and Why You Should Have Them

Sitemaps and site indexes are forms of supplemental navigation. They give users a way to navigate a site without having to use the global navigation. By providing a way to visualize and understand the layout and structure of the site, a sitemap can help a lost or confused user find her way. Sitemaps are more widely implemented than site indexes, but both have their place and fulfill a unique information need.

Can you see it? A sitemap is a model of the structure of a website on a single page. At a glance, the user can see the main categories and subcategories on a site. This visualization can be a literal graphical map or be text-based. Text-based sitemaps (really a table of contents) are easier to maintain than graphical ones due to production overhead. Dynamic sitemaps that require users to manipulate the page to see the content (e.g., hyperbolic trees) are not as successful as simple, uncluttered outlines. The most important thing about a sitemap is that it be accurate, easy to scan, and easy to understand.

Sitemaps provide a high-level or top-down view of the site. The items included in the sitemap should correspond to the items in the global navigation. In this example from L.L. Bean (figure 1), the yellow items match the main global navigation categories on the site: “Home,” “Shop,” “Explore the Outdoors,” “My Account,” and “Customer Service.” Not only is the wording identical, but the order of the items match. Each of these categories contains subcategories, indicated in blue on the map (e.g., “Men’s,” “Outdoor Tips & Gear,” “FAQs”). The third level of the site is indicated by the individual text links.

The L.L. Bean sitemap does a very good job of displaying the different sections of the website. The visual design reinforces the site hierarchy. It is easy to understand that “Men’s” is part of “Shop” and “Log In/Register” is part of “My Account.” It is clean and uncluttered even though it is displaying three levels of hierarchy. The individual links further clarify what the subcategories mean. For example, the categories “Footwear,” “Active Clothing,” and “Casual Clothing” further define what is meant by the term “Women’s.”

In contrast, the sitemap on the Harvard University website (figure 2) does not match the site’s structure or navigation. Only two sections in the sitemap (“Campus Life” and “Admissions”) appear exactly as they are in the global navigation. Two other items are variations of the items in the global navigation. “Admissions” appears in the global navigation as “Admissions & Financial Aid” and “Libraries and Museums” is broken into two separate categories in the navigation. The rest of the items use variant names or do not appear in global navigation at all.

The first section of the sitemap, “About Harvard,” is actually an item in the footer of the site. The subcategories in the “About” section do not match the subcategories found on the actual “About Harvard” page. In fact, of the 10 links listed on the sitemap in the “About Harvard” section, half of them lead back to the top of the “About Harvard” page itself rather than to a discrete page.

The Harvard University sitemap does little to help the user understand the Harvard site. It mixes global navigation and footer elements, making it difficult for users to understand the priority of items. The map also makes it difficult for the user to find the elements again once she has left and is deep in the site. Was that link in the global navigation or the footer? The labels vary among the sitemap, the global navigation, and sometimes even the page itself. This makes it difficult for a user to be sure that she is on the correct page. Link names that are similar, but not exact, require the user to have to think about the terms to determine if she is in the correct place. This is added mental processing that the website should not impose upon the user.

It’s as easy as A-B-C Unlike a sitemap whose purpose is to illustrate the structure of the website, a site index provides direct access to specific areas of the site. Site indexes are best suited for known item browsing. As Fred Leise writes, site indexes “provide entry points to content using the users’ own vocabulary and they provide access to concepts discussed, but not named, in the text.” Site indexes also allow for finer granularity than sitemaps since they can point directly to specific mentions of people, places, and things, rather than whole subsections. Site indexes provide a bottom-up, or content-centric, view of the content on the site.

A website index should function in a similar manner as a back-of-the-book index. In fact, modeling your site index on back-of-the-book indexes will help improve the usability and usefulness of your index. If your audience understands how to use one, they will understand how the use the other. Following graphic design standards for book indexes, such as indenting sub-entries under main entries, will also help improve the readability and usability of your index.

The site index by the World Wide Web Consortium (W3C) (figure 3) has all the elements that make up a good index. The visual design facilitates scanning. The alphabet letters at the top let the user skip down to entries beginning with that letter, since the index is all on one page. This is preferable to dividing the index into separate pages as it allows the user to easily scan the entries for multiple letters without having to wait for pages to load.

This index includes main entries for all of the important topics on the W3C site. Main entries (e.g., “architecture”) are broken down into sub-entries (e.g., “Design Issues”) to help users focus their browsing. See references are included to help users find the items they are looking for. See references “translate” the user’s vocabulary into that of the site. In the W3C example in figure 3, there are no entries for the term “annotations,” but there are three entries for programs related to annotation: “Annotea,” “Amaya,” and “Ruby Annotation.” This tells the user the topic she is interested in is included on the site, but under a different term. The W3C index also includes see also references. These direct the user to additional information related to the item she looked up. In Figure 3, you can see under the entry for “Annotea” there are two see references for the “Semantic Web” and “Amaya.” See and see also references are an important component to include in your index. But they should be used sparingly, so they do not overpower the main entries in the index.

While the W3C site index is well done, there are things within it that could be improved. For example, the page includes a scope note, or explanation of what is included in the index, at the bottom of the page. This note should be moved to the top of the page, so users know from the beginning what is covered by the index. The W3C should also complete their cross-references. Since “Annotea” has a see reference to “Amaya,” “Amaya” should also have a see reference back to “Annotea.” It is only logical that if one is related to the other then the relationship is reciprocal, and users would be interested in both.

Indexes come in a variety of flavors. One type is an index of the entire site that covers all of the topics included, such as in the W3C example. Alternatively, there are product indexes that take the form of alphabetical listings of product names or a numerical listing of part numbers. These are especially helpful for sites with a lot of products or complex product lines. University sites such as Harvard University and Yale University may have indexes of their subsites—the individual department, schools, and club sites that are part of the university.

The corporate PeopleSoft, Inc. website uses both a site index and product index. The site index, which won the Australian Society of Indexers Web Index Award for 2002-2004, covers all of the main topics included on the site, including information about PeopleSoft and contact information. Individual product names are not included in the site index since there is a separate product index. However, the site index does include the names of the main product lines since not all users will see that a separate product index exists.

Because PeopleSoft offers over 200 different enterprise software products, we decided to have a separate product index (see figure 4). A combined site and product index would be too unwieldy. The product index includes the product lines, suites, modules, and solutions the company offers. The current name of the product is listed along with any past names the product may have had listed as see references. This allows customers who knew a product under one name, such as “MarketPlace,” to still find it under its new name “eSettlements.” Note that the scope note clearly states that only product information is included in the product index and references the site index for other site content.

But how do I choose? How do you know if your site needs a sitemap or a site index, or both? On very small sites, it is unlikely that either would be needed. Most likely the global navigation can provide direct access to all areas of the site. Most medium- and larger-sized sites should probably include at least a sitemap. Text-based sitemaps require few resources to create and maintain and can provide big benefits for your users. Unless your site is a directory like Yahoo!, a sitemap is the only place where a user can see all the categories and top subcategories in a single place. This is especially important if your site navigation uses expanding and collapsing menus that hide options until a mouseover. Ecommerce as well as informational sites can be improved with a sitemap.

Most medium- and larger-sized sites can also benefit from an index of some type. For extremely large sites, it would be unrealistic to include absolutely everything in the site index. It would simply be too large to use efficiently. Only the most important and most used information should be included. Informational sites benefit more from a site index than the average ecommerce site because the content is generally richer on an informational site. However, ecommerce sites with complex product lines should consider whether a product index would be appropriate and helpful for their audience.

The decision whether or not to include an index also depends upon the type of content on your site. Does your site make sense in an alphabetical arrangement? For the L.L. Bean site, a site index would not be very helpful for their users. Users tend to look for clothing and outdoor gear via categories (e.g., “Men’s,” “Camping,” “Active wear”), not by browsing an alphabetical listing. Since the content lends itself to categories, a sitemap better serves the users’ needs.

Location matters Whether you include a sitemap, site index, or both on your site, your users should be able to access them no matter where they are on your site. Place the link in a consistent spot such as the footer or with other utility navigation. If your site has a help section, include the link there as well, since lost users may have overlooked the links in the primary location. Consider including a link to the sitemap and site index from the search results page and the no search results found page as well.

The most appropriate name for a sitemap link is simply “Site Map.” In the Nielsen Norman Group study on sitemaps in January 2002, the sitemap “label worked well … and is one used by 63% of the sites with site maps,” included in the study. Don’t call it a “Site Index” unless it is truly an alphabetical index. If you have a product index, be sure to differentiate from the site index in both the label and the scope note.

On the PeopleSoft site, the usage metrics for the site index and product index are consistently higher than those for the sitemap. There are a couple of hypotheses as to why this is the case. First, the site index is a more complete view of the site than the sitemap, and it includes links to more things than just the top-level categories on the site. Items are cross-referenced and double-posted so users can find items by looking up their term, for example “jobs” and the PeopleSoft preferred term “careers.” Second, the customer support team refers users to the site index if they are having trouble locating an item on the site. In this way, the site index acts as a list of shortcuts, since a user doesn’t have to drill down through the hierarchy of the site to find what she is looking for. Lastly, the reason may simply be link placement and visibility. There are links to both the sitemap and the site index in the footer on every page, in the help section, and on the search tips and no results found pages. But there is also a link to the site index next to the search box on the left-hand navigation bar. This often raises the link above the fold, increasing its visibility.

Making it easy on yourself Sitemaps are relatively easy to create and maintain since they generally do not contain any unique content. The terms and items included come straight from the primary and secondary global navigation of the site. Indexes are a bit more complex however, since the entries must be careful chosen. A site index really requires a person trained in indexing to analyze the content to determine the appropriate entries and relationships between terms. A product name index, on the other hand, could be generated automatically using a database, metadata, XML, or other similar technology.

At PeopleSoft, our content management system, Interwoven’s TeamSite, enables us to use the same sitemap, site index, and product index pages on all of our corporate sites. This is important since the information architecture is the same for the corporate website and our customer and partner extranets. All of the information on the public site is available on the customer site, and the partner site includes the customer and public information, plus additional partner program information. We tag each entry in the indexes and map with an audience tag. The system then displays the appropriate entries for each audience, depending on how they log into the site. This allows support information to appear on the customer and partner site index but not on the public site index, which in turn reduces the amount of maintenance required since there are only three pages to update instead of nine.

In December 2002, PeopleSoft expanded its public website to include 21 country sites. These sites are built on the same information architecture as the corporate site, but are translated into the language of the country and include localized content. The product index is localized to only include the products that are offered for sale in that country. We are in the process of updating the templates used to create the product index so we can tag each product name with the country it is appropriate for. This will allow us to go from 22 separate product indexes (one for each site) to just 10 (one for each language). The product index will be updated to include both the English name of the product and the appropriate translated name. This will allow users looking for a product to find it in either language.

Conclusions As we have seen, both at PeopleSoft and in examining other real-world examples, effective uses of sitemaps and site indexes can provide a quick and easy way for users to move around a site, and they provide in-depth information about the content and structure of the site. As more sites adopt them, users will become more familiar with their benefits and make use of them as a navigational tool within a site.

NOTE: Screen shots captured June 13, 2003. Chiara Fox is the Senior Information Architect in PeopleSoft’s web department. Before joining PeopleSoft, Chiara was an Information Architect at the pioneering consultancy Argus Associates.

Re-architecting from the bottom-up

In December 2001 PeopleSoft, a large enterprise software company, relaunched its public website, and customer and partner extranets, Customer Connection and Alliance Connection. It took 11 months and more than 60 people to redesign and build the information architecture and graphic identity, build the technical infrastructure, migrate and rewrite existing content for the new content management system, test it, and finally publish the new site live.

All information architectures have a top-down and a bottom-up component. Top-down IA incorporates the business needs and user needs into the design, determining a strategy that supports both. Bottom-up methods look for the relationships between the different pieces of content, and uses metadata to describe the attributes found.

We undertook the re-architecture of the PeopleSoft web properties for a number of reasons. First, the three sites all had their own user experience, different architectures, and varying core goals. The sites also had overlapping content and users. Partners, who had to navigate all three sites to get all the information they needed, had the worst experience because they had three sites to navigate and understand.

Content was often duplicated across the three sites. This made updating the site time-consuming and difficult because files had to be updated in many places. It wasn’t uncommon to find different versions of a document on each of the sites, or even within the same site. Each site had its own style guide, which added to the varying experiences.

The sites also differed in their technical back-ends. Each site had its own search engine and content management system. Many types of databases were employed on the sites, and the structure of the data varied from database to database. Different information systems teams, as well as content development teams, supported the sites.

In February 2001, we started a project seeking to create a single site, with a unified technical infrastructure and three distinct user experiences. This new system would use Interwoven’s content management system, TeamSite, to store and generate the files for all three sites. The sites could share the same content assets where possible, reducing creation and maintenance overhead. Users would have the same type of experience on all of the sites, due to the shared graphic identity, branding, style guide, and information architecture. Once users learned one site, they would be able to transfer that learning to the others.

While we used many methods and tasks as part of this enormous project, this case study will focus on just one small piece of the bigger picture: the bottom-up information architecture methodologies. We did extensive user and stakeholder research, usability testing, and top-down IA, but a thorough discussion of them is beyond the scope of this article. The architecture portion was the first part of the project to be completed. PeopleSoft hired Lot21 and Adaptive Path to help with the architecture development.

Information architecture has a bottom?

All information architectures have a top-down and a bottom-up component. Top-down IA focuses on the big picture, the 10,000-foot view. It incorporates the business needs and user needs into the design, determining a strategy that supports both. Areas of content are tied together for improved searching and browsing. It determines the hierarchy of the site, as well as the primary paths to main content areas. Top-down IA can be as large as a portal or as small as a section home page.

In contrast, bottom-up IA focuses at the lower levels of granularity. It deals with the individual documents and files that make up the site, or in the case of a portal, the individual sub-sites. Bottom-up methods look for the relationships between the different pieces of content, and uses metadata to describe the attributes found. They allow multiple paths to the content to be built.

Both top-down and bottom-up methods are necessary to build a successful site, and they are not mutually exclusive. They work together to take the users from the home page to the individual piece of information they need.

Content inventory

Before we could do any designing, we had to first understand what we were dealing with. The first step we took was conducting a content inventory, which counted and documented every page on the site. It recorded specific information about each page that would later be used during the content analysis.

We created a separate Microsoft Excel spreadsheet for each site’s inventory. Each main section or global navigation point got its own workbook or “tab” in the spreadsheet. This made it much easier to work with the large files. The name of the page, URL, subject type, document type, topic, target user, and any notes about the page were manually recorded. There was room allotted in the spreadsheet for PeopleSoft to record the content owner, frequency of updates, and whether the page was a candidate for ROT removal. (ROT stands for Redundant, Outdated, and Trivial content.)

The final inventory consisted of more than 6,000 lines in the spreadsheets. Only HTML pages were recorded. Pages in Lotus Notes databases were excluded, though the different views were documented. Of the information recorded, link name, URL, and topic were the most useful and we referred to them again and again throughout the project. The other fields were still useful though. By filling those fields out, we were able to think more critically about each page, and get a better feel for and internalize what the sites had to offer. If we had just captured the page name and URL, or used an automatic method for gathering the information, this depth of knowledge would have been lost.

In addition, each page was assigned a unique link ID. At the beginning of the inventory, we envisioned using the link IDs as a way to refer to the pages since the page titles were often inconsistent and unreliable. In reality, the link IDs were too complex and numerous to use. No one could remember that meant the volunteer request form. The link IDs did prove to be helpful in other ways. By simply scanning a page in the spreadsheet, it was quick and easy to determine how broad or deep a section of the site was. They were also helpful during content migration in mapping the content on the old site to the architecture of the new site.

Unified content map

The content inventory spreadsheets were highly useful for detailed information about individual pages. But more than 6,000 lines of information are a bit hard for people to get their arms and brains around. The spreadsheets were not very good at giving a high-level view of the content on the site. For that we created the unified content map. Once the inventory spreadsheets were completed, we were able to pull out the different document types and content types we had found. We identified the larger content areas (e.g., general product information, customer case studies) and then listed out the individual examples that existed on the site (e.g., component descriptions, functionality lists).

The content areas of all three sites were mapped together in the same document, forming the unified map. We then identified content types that were duplicated between the sites. These overlapping items indicated areas that we wanted to investigate further to understand why they were duplicated. Was the document modified slightly to better serve a particular audience? We found out that in most cases, the documents were identical. Usually the content owner simply didn’t know that the document already existed elsewhere, or the technology used made it difficult to share assets. These overlaps were a driving force for structuring the content management system so a single asset could be used in multiple ways, for multiple audiences.

Classification scheme analysis

Beyond understanding the types of content that were on the PeopleSoft web properties, we also had to understand the organizational schemes that were in place on the sites. By looking at how the content was currently structured, we would have more insight on how it could be improved.

Classification scheme analysis was done on the products and industry classifications of all three sites. The names of the industries and products appeared in different places throughout the site, beyond the products section. For example, in the “Events” and “Customer Case Studies” sections documents are classified by product and industry. Each instance of the classification was recorded in a table, so the terms could be compared.

The first thing we looked for in the table was inconsistencies in wording from list to list. Inconsistencies illustrate the need for controlled vocabularies on the site because there are so many ways to describe the same thing. These inconsistencies were used as the basis for variant terms in the product and industry vocabularies. We also looked for “holes” in the classifications – places where terms were not used. Holes could indicate places where content needed to be developed, or needed to be removed because it was out of date. These sections were flagged so they could be examined during content migration.

Content analysis

Once the content inventory was complete and we had created the unified content map and classification scheme analysis tables, we had the daunting task of analyzing what we had documented. We used these tables and maps to help us find the patterns and relationships among the different types of content.

We looked for ways the content could be better tied together. On the previous site, content lived in discreet silos and there was very little interlinking. We discovered that there was actually a lot of information that could help prospective customers better understand our products and services or processes, such as implementing a PeopleSoft solution. For example, there are consulting services offered by PeopleSoft, as well as our Alliance Partners, which are specifically focused on the task of implementation. Training classes are available for both the technical implementation team, and the end users who will be using the new software. Once we saw these connections, it became clear that we needed a new section of the site devoted to implementation. User testing confirmed this, and we also learned of other types of information users needed, like a listing of supported platforms PeopleSoft software runs on.

Through content analysis we were also able to create the metadata schema to use on the new site. Some attributes such as products or services were obvious from the beginning. Others, like language and country, became obvious only when we saw how many documents we had that were non-English or appropriate for only North America. Twelve attributes in total were identified, and they are used to describe content on all three sites.

Creating the product lens

Information about the different products was spread out across the sites. This was especially true on the Customer Connection and Alliance Connection sites, where there are support documents in addition to sales and marketing information. Users had to go to multiple sections of the site to find all the information they needed. High-level marketing material could be found in the “Products” section, but support information was in its own area. Documentation was separate from support, and upgrade information was separate from both support and documentation. This model supported users who came to the site knowing what they wanted – support information for Global Payroll. The model didn’t work for users coming to site wanting to see all information related to Global Payroll. There was no central place that aggregated the links to the various resources together.

A goal for the new site was to support both types of users. We began by combing through the content inventory and the sites themselves to find all information related to products, no matter where they lived in the sites. Examples of content we found are support information, consulting services, training classes, and industry reports. We wrote each item down on a sticky note.

Working together with the Customer Connection team, we organized these sticky notes into different groupings. The sticky notes worked very well in this exercise. The “unfinished” nature of the notes encouraged people to be more critical and they felt freer to make changes. The whole team participated by moving the sticky notes around and discussing the reasons behind the movement and connections among notes. While coming up with the groupings, we didn’t think about final nomenclature. We instead focused on capturing a name that described the essence of the group. We ended up with titles like “What Others Are Saying About Product” and “Working Beyond the Product.” Things you would never want to see in a global navigation bar. We refined these labels later on once we built out the product pages.

These groupings formed the basic structure of the product module pages. Because there was so much information related to the products, we decided to divide the module pages into different tabs. The public would see three tabs— “Features,” “Technical Information,” and “Next Steps.” Customers and partners would see two additional tabs—“Support” and “Upgrade”—once they had logged into the site.

The information available on these tabs is supposed to be specific to the individual product. Ideally, a link to release notes on the “Global Payroll Support” tab would take the user to just the Global Payroll release notes. Unfortunately, due to technical limitations with our current database structure, we have to link to the release notes area in general. Users must then drill down to the information for Global Payroll. As we update the databases, we will be making these links more specific. Until then, we feel it is an improvement from before, when the user would have to backtrack out of the products area and drill into the documentation area to find these notes. We are at least getting them to the right neighborhood.

Site comparison tables

Not all of the bottom-up work occurred at the beginning of the redesign project. Once the new architecture was determined, we still had to populate that structure with the content. To aid in the migration and creation of content for the new site, we turned again to the content inventory.

The content inventory was performed in May 2001. Planning for the site migration didn’t take place until September. Even though specific pages on the sites had changed since the inventory, the bulk of the inventory and the structure it represented were still correct. We modified the inventory spreadsheets to include the new site structure, complete with new link IDs.

These tables began as a means to double-check that all the content had been accounted for in the new architecture. It also allowed us to see holes where we would have to create new content. As plans for migration continued, the use of the tables expanded. They provided a means for estimating the number of pages that had to be migrated. A column was added to indicate if the page was part of a database not scheduled for migration. Columns for the content approver and the migration team member names were also added to the spreadsheet. This made it clear to everyone who was responsible for which sections. This also helped in balancing out the workload among the whole team.

Once migration started, the usefulness of the comparison tables quickly faded. On-the-fly changes to the architecture occurred at the lower levels of the site as we worked with the migration team to slot the individual pieces of content. The tables quickly became out of date, and it took too much time to keep them updated.

State of things today

The new, Customer Connection, and Alliance Connection sites launched on December 21, 2001, on time and on budget. Since the launch, site inquiries, one of our major success indicators, are up significantly over last year.

But just because the site is live and successful doesn’t mean our work is done. We are continuing to refine and tweak the site. We are conducting various user testing and usability sessions to see how customers and prospects like the new site, and where they are having difficulty. We are retiring older databases and migrating the content into Interwoven TeamSite. There are areas of the site that we simply didn’t have the time to examine in detail during the redesign. We are now tweaking the architecture of these sub-sections such as “Training” and “Assess Your Needs” to better support the content we have and make it easier for users to find what they need.

Later this year we will be implementing PeopleSoft’s portal software so customers will be able to better log and manage their support cases and have more control over their site experience. The work is really just beginning.

Chiara Fox is the Senior Information Architect in PeopleSoft’s web department. Before joining PeopleSoft, Chiara was an Information Architect at the pioneering consultancy Argus Associates.