These SiteMap-related tips include another way around the Google page-priority warning, places to submit your sitemap and thoughts on creating page-priority-value "rules".  This post fills the void between the Improve Page Prioirty Feature of DNN's Google SiteMap and our upcoming release (free!) of an enhanced sitemap that enables per-page sitemap priority settings without changing any core code (are you feeling giddy, yet?) 

Warning:  All the URLs in your sitemap have the same priority
This is the Google webmaster tools warning that perked my interest in the current state of affairs of DNN's sitemap.  You can partially address this issue by making a few super-simple updates as detailed in my previous post, but if you really just need this message to not show up (because you have clients who get nervous when they see such things) you can change the default page priority value from "0.8" to "0.5" (or less).  Fortunately, starting with DNN version 5.0.1, the default value is now "0.5" so no worries for all you early-adopters who have already moved to using DNN 5.0.1 as your production environment...

To change the default page priority value:  
Look inside SiteMap.aspx.vb for the line that sets SITEMAP_PRIORITY to a value of "0.8". Change the value from "0.8" to "0.5" and save the file.  All done!

 

Submitting Your SiteMap:  Where To?
So you have your sitemap but don't know if the search engines know about it?  Here are links to direct sitemap-submital pages of some of the bigger search engines:

Google:
http://www.google.com/webmasters/tools/ping?sitemap={your sitemap URL here}

Yahoo!:
http://search.yahooapis.com/SiteExplorerService/V1/ping?sitemap={your sitemap URL here}
 
Live Search (Microsoft):
http://webmaster.live.com/ping.aspx?siteMap={your sitemap URL here}
 
Ask.com:
http://submissions.ask.com/ping?sitemap={your sitemap URL here}

 

Page Priority -- Applying Basic Rules to Determine Values
This topic comes up due to a recent DNN user submission (an official submission to Gemini) asking the DNN team to update the default sitemap to apply a rule to give greater priority to pages that appear "higher" (closer to the root) in the menu structure.  At first blush this may seem correct, and for some sites it may work well, but in general this is not a good idea...  

The Problem with Setting Priority Based on Menu Hierarchy
Suppose your site is a collection of products for sale.  If you are selling a super-duper garden growth fomula, you want someone searching for "garden growth" to hit your "Super Growth Formula" product page, not any of the category menu pages above it such as "landscaping", "garden", "fertilizer", etc.  In your case, you want the actual product pages to get greater priority than any of the parent menu tabs that serve mainly to group together similar product pages.

Of course, the reverse can be true.  What if you are selling bolts of various sizes?  When someone searches for "bolt", you may prefer to direct them to a general parent page for "bolts" rather than a child page for a particular bolt size (unless, of course, the person specified the size when searching).  For this site, you may prefer to give priority to parent pages rather than child pages.

A Thinking-Man's Approach
Ok, let's agree for the moment that, generally speaking, predicting priority values based on where pages fall within the menu structure simply does not make sense for all sites.  Is there anything else that makes sense...always?  Remember -- if we "bake in" the logic (force it upon all users) it should always make sense.  If you read my previous post, you already know the two basic rules I settled on and posted a solution to -- rules that always make sense for all sites (assuming individual site authors are generally consistent with setting up content site-wide):

RULE 1:  If you care enough to DESCRIBE it...
If a page has a DESCRIPTION then that page is probably more important than a page that has no description.  So, for pages with descriptions we bump up the priority value slightly over pages with no descriptions.  Make sense?
 
RULE 2:  If you care enough to TAG it...
Ok, same idea as #1.  If a page has keywords defined for it then it is probably more valued by the page author than a page with no keywords set.  We can bump up the priority value slightly for these pages. 
 
RULE 2.5:  If you care enough to keep typing...
A reader (Ronny Bartsch) of my previous SITEMAP post commented that a natural extension to rules #1 and #2 would be to give weight based on the length of the DESCRIPTION and KEYWORD fields.  Or, put another way, the more description and  keywords you have the more important the page.  I agree that it is very likely that, in a broad sense, more important pages will probably have at least as much, if not more, descriptive text and keywords.  If we assume that more important pages are not likely to have less text in these fields, we can safely apply an additional priority rule (I'll call it "Ronny's Rule") as follows:
 
  Give additional priority (+0.1) for every set of 40 characters:
 
  ((DESCRIPTION.length / 40) * 0.1) + ((KEYWORDS.length / 40) * 0.1)
 
Giving weight based on 40-character increments (i.e., large increments instead of small ones) helps avoid falsely giving wieght to less-important pages due to a few extra descriptive words or a few keywords that happen to have more characters.that the keywords on more important pages.  (Thanks for the comments, Ronny!)
 

These rules all work well except in cases where content managers are zealous (set descriptions and tags for all pages) or are lazy (never set descriptions or tags).  What then?
 

The Ultimate Solution
The ultimate solution?  Well, provide every rule as a user-specified option and give the user the ability to have it any way they like.  Ultimately you also want to give the user the ability to set an overriding page priority value for any particular page in order to address exceptions to the applied rule(s).  This "ultimate solution" is exactly what I'm currently doing with the default DNN sitemap and is what I'll make available (for free) as soon as all the kinks are worked out.  Best of all, it won't write to the database or change any core DNN code at all.

Stay tuned!