Posted by gbirch on July 15, 2010 at 12:56am
17 followers
| Project: | XML sitemap |
| Version: | 7.x-2.x-dev |
| Component: | User interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
When I add a content type or a menu to the sitemap, I am able to specify the relative priority for the included nodes. But I can't specify the changefreq. This would be nice, especially since the module seems to assign changefreq relatively randomly, and often applies "yearly" to content that should really be re-indexed more often.
Comments
#1
subscribe!
#2
It would be nice to have the option of leaving changefreq blank (or 'none', like custom links) for content types and menu items also.
#3
It would be nice, but since changefreq is just a suggestion, this is not a feature that will be implemented before 6.x-2.0.
#4
#5
Our SEO "expert" said we needed to specify weekly as our max change frequency.
So... here's a patch that implements a user-settable maximum change frequency globally, across all urls in the sitemap. For consideration for inclusion in 6.x-2.x
#6
Then your SEO "expert" is wrong. This value is only a suggestion to search engines and I would not be likely to ever accept this patch. But it might be useful for others so thank you for sharing.
#7
Hey no problem. I don't claim to know anything about SEO. We paid him to do an assessment and this was on the checklist.
#8
The perception for the term change frequency is that it should be important regardless of whether or not it is so I understand the feature request. Perhaps the implementation should dwell more toward settings.php and a conf variable element rather than a variable_get settings page item. Such settings items tend to give more credence toward the importance when there is really none that should be given.
#9
@dwightaspinwall, thank you for this! #5 applied beautifully and I think this feature is very important as Google *was* penalizing us for having yearly changefreq times on all of our content which was generated with views/panels.
#10
#5: xmlsitemap_max_changefreq.patch queued for re-testing.
#11
The patch in #5 is for 6.x-2.x. We need a patch for D7.
#12
subscribe!
#13
Hi, Shouldn't this patch (http://drupal.org/node/854632#comment-6632914) not first be committed on D6, and then D7 build from another issue?
I have set the version back to 6.2.dev because of queing for re-testing. If this is wrong please set it back to 7, but not without knowing the testing stuff.
greetings, Martijn
#14
No that is not the way the workflow works. We need a D7 patch, then we consider D6.
#15
Been using #5 in production for several months now and it considerably helped out incoming traffic despite only being a *suggestion* to search engines. Google loves fresh content, and even if some of the content didn't change, it was nice for Google to at least crawl the page and its links more frequently.
Can we get this in? It's a small patch and optional feature.
#16
#17
Attached.
#18
The last submitted patch, xmlsitemap-7.x-2.x-854632-17.patch, failed testing.
#19
#20
Dave Reid what do you think about the patch?
#21
I applied this patch to my 7.x-2.0-rc1 version, and seems work fine!
Thanks for the patch!
#22
7x and 6x both work. This is a must have for larger sites. Please add this!
#23
I think the patch is missing adding this variable to the xmlsitemap_variables() function so that it can be removed on uninstall.
$maximum_changefreq = variable_get('xmlsitemap_maximum_changefreq', XMLSITEMAP_FREQUENCY_NEVER);foreach (xmlsitemap_get_changefreq_options() as $value => $frequency) {
if ($interval <= $value || $value >= $maximum_changefreq) {
return $frequency;
}
}
Is there any possible way for this to not match any condition and still hit the end of the function, which now returns NULL rather than 'never'?
#24
Thanks Dave,
I made those changes.
I still have the slight concern what if XMLSITEMAP_FREQUENCY_NEVER which is PHP_MAX_INT changes in the same install when moving servers or php is upgraded in the future.
Perhaps it should be XMLSITEMAP_FREQUENCY_YEARLY + 1 or some arbitrary nasty sequence of 9's.
Attached.
- Sean
#25
I'm not sure if I did the patch wrong or are missing something else here.
I ran patch and then set "Maximum change frequency"* to weekly and rebuilt the sitemap but I'm still seeing yearly and monthly update frequencies.
Little help?
Thanks!
Side note: This was a confusing label as I thought it meant 'no more often than' rather than 'no less often than'... maybe it's just me.
#26
@micheleannj, use the rebuild links tab.
#27
I understand your concern. PHP_MAX_INT could change with the bitness of a system. Open a new issue for it. I think I prefer -1 as the value for XMLSITEMAP_FREQUENCY_NEVER.