Advocacy FAQ

Two things are needed:

1. More sites with sitemaps
2. More surfers who can use them

For more sitemaps, you need to persuade lots of webmasters to add them to their sites, and maintain them. Any you can persuade would help, but it might be more rewarding initially to get developers of site-building software, especially CMSes and documentation generators, to make that software generate sitemaps automatically. Not only does that remove the maintenance work from webmasters, but it will result in hundreds of new sitemaps with just one persuasion!

For more surfers, first become one yourself. Try to install some software for your own use (if any is available for your browser), and demonstrate to friends and colleagues. When there are plenty of sitemaps out there, you’ll be able to make a strong case to browser developers to add sitemap support.

What sitemaps.org defines is not a site map, but rather a simple page list. There is no information about the site’s hierarchy or information architecture included whatsoever. sitemaps.org contains only 3 pieces of information (besides the page’s URL):

• The date of the last modification of the page (<lastmod>): This can easily (and more accurately) be found out via a short HTTP request. Besides, it’s not very important to the user. But if the need really does arise, we can include it into our format later on.
• The frequency of changes to the page (<changefreq>): This is totally uninteresting to the user, since it doesn’t tell anything about actual changes, but only about the webmaster’s presumption. Besides, as a webmaster, it’s often hard to guess when a page is likely to be updated in the future.
• The importance of the page, in relation to other pages in the website (<priority>): This, at last, does make sense, and we’ve therefore included it in our format (using the very same value range).

Summing up, the main difference is that sitemaps.org doesn’t do anything for the site visitor – it just serves the needs of search engines. In contrast, the Standard-Sitemap Protocol was designed explicitly to meet the visitors’ needs.

If Google (and the other search engines endorsing sitemaps.org) is willing to cooperate, we could easily include the <lastmod> and <changefreq> information into our format too, thereby integrating the entire scope of sitemaps.org.

In principle, <link rel> and the Standard-Sitemap Protocol both address the very same issue: describing a website’s structure. But <link rel> suffers from two major flaws:

1. <link rel> is a relict from the early days of the web (established with HTML 2.0 in 1995). It is a system for describing the structure of books, but not websites: Nobody knows how to apply link types like “chapter”, “section”, “subsection”, “bookmark” or “appendix” (!) to today’s common websites.
2. There’s no valid specification available. Even the official information from the W3C itself is contradictory; see HTML 4.01 Specification — 6.12 Link types and Proposed Relationship Values. Besides, there’s a plethora of unofficial sources, e.g. Link Type Definitions.

So it’s no big surprise that <link rel> has failed. But does this mean that nobody is interested in improving website navigation? We say no – quite the contrary: If you consider how awkward a concept <link rel> is, the fact that numerous web masters actually do make use of it gives clear evidence of their tremendous interest in navigation issues, as otherwise they certainly wouldn’t have bothered to fiddle about with <link rel>.

Finally, <link rel> isn’t suited for rendering a navigation system, because since the <link rel> tag resides inside of each HTML page, the browser would have to download every single page to get a comprehensive overview of the website’s structure.

Actually, the idea for the Standard-Sitemap Protocol was born when Christoph Müller (author of the cmSiteNavigation Toolbar extension for Firefox) and Thomas Landauer were thinking about ways to promote the usage of <link rel>. However, it soon became clear to them that the concept was flawed from the outset – so they started from scratch.

Indicate that your site supports a sitemap. Display the sitemap logo and the message “Sitemap Supported”, and link them to our site. You should be able to use the following:

<div class="feature"><a title="Standard-Sitemap Protocol" href=
"http://www.standard-sitemap.org/"><span class="icon"><img title=
"This page supports a sitemap!" border="0" hspace="1" vspace="1"
src="http://www.standard-sitemap.org/files/logo32x32.png" alt=
"The Standard-Sitemap Protocol" align="left" width="32" height="32"></span>
<span class="text">Sitemap Supported</span></a></div>

Your CMS software might already embed navigation into each page. Make it generate and serve an XML sitemap too. Keep the in-band navigation, but use class-based styling to disable it automatically for sitemap-aware clients.

If the browser is Firefox, we already have an extension for it. However, it will require maintenance from time to time.

If you have experience with another browser, please study the developer guide, and combine that knowledge with your own expertise with browser X to write a new extension, add-on or plug-in for it.

Raise the issue of navigational sitemaps with standards bodies, or in their discussion forums. Give an honest assessment of their benefits and problems, with a view to solving those problems.

We also encountered some implementation difficulties, and envisaged solutions based on extentions to HTML/CSS:

• Namespaces for Media Features

Do you carry any weight in the community of Web standardization? Can you promote such ideas? Can you devise more (and more compelling) use cases that would help to convince others of the general utility of such features? Can you propose anything better?

You shouldn’t have to switch to another browser, and SSP sitemaps are designed to be cross-platform. Politely ask your browser vendor, or a community that develops add-ons for it, to add sitemap-rendering functionality. Point them to this site for further information, especially the developer guide.

It’s not so bad, because the cost of participation is quite low. For surfers, any piece of sitemap software installed in a browser can sit there benignly until a sitemap is encountered. For webmasters, a sitemap can sit there benignly too. As for maintenance, many webmasters will already be maintaining an in-band sitemap which they simply have to translate into an OOB one. Additionally, many sitemaps could be generated automatically, especially in Content Management Systems (CMSs).