If you like the idea of out-of-band sitemaps to support visitor navigation and other functions, please make others aware of this project, and encourage them to take part.
Advocacy FAQ
How should I promote SSP sitemaps?
Two things are needed:
- More sites with sitemaps
- 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.
How is the Standard-Sitemap Protocol related to Google’s Sitemaps Protocol, sitemaps.org?
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.
Isn’t this the same as the HTML
<link rel>element?
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:
<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.- There’s no valid specification available. Even the official information from the W3C itself is contradictory; see this and that. Besides, there’s a plethora of unofficial sources, e.g. here.
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. Because 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 Mueller (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.
I want to encourage visitors to take advantage of my sitemap. As a webmaster, what can I do to support sitemaps?
Indicate that your site supports a sitemap. Display the sitemap logo and the message “Sitemap Supported”, and link them to our site.
I maintain the software for a Content Management System. As a CMS developer, what can I do to support sitemaps?
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.
I’m just an ordinary websurfer, and my preferred browser doesn’t support sitemaps. As a websurfer, what can I do to support sitemaps?
You shouldn’t have to switch to another browser, and SSP sitemaps are designed to be cross-platform. Politely ask your browser vendor to add sitemap-rendering functionality. Point them to this site for further information, especially the developer guide.
Webmasters won’t deploy sitemaps because very few people will be using software to read them. People won’t install software because there are very few sitemaps out there. Increasing the popularity of sitemaps is a bit of a chicken-and-egg problem, isn’t it?
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).
