Add ability to override changefreq

subscribe!

It would be nice to have the option of leaving changefreq blank (or 'none', like custom links) for content types and menu items also.

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.

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

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.

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.

@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.

#5: xmlsitemap_max_changefreq.patch queued for re-testing.

The patch in #5 is for 6.x-2.x. We need a patch for D7.

subscribe!

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

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.

Attached.

I applied this patch to my 7.x-2.0-rc1 version, and seems work fine!
Thanks for the patch!

7x and 6x both work. This is a must have for larger sites. Please add this!

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'?

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

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.

@micheleannj, use the rebuild links tab.

#17: xmlsitemap-7.x-2.x-854632-17.patch queued for re-testing.

Is there any reason to not just change the frequency to actually store the protocol's strings rather than an arbitrary value that we're now having to work around because we can't shoehorn the 'never' value into it?

Would it be possible to tweak this to add the frequency to the XML settings per Content type?

We recently worked on a project, where the previous patch was used. Recent releases for this project, include security updates and we were required to reapply the patch with the most recent version.

thought the recent discussion recommends alternative methods for providing the frequency, in interest of time we needed to recreate the patch with the most recent version.

The patch in #31 contains the absolute paths, which causes the error when the module in alternative places:

git apply xmlsitemap-7.x-2.x-854632-31.patch
error: sites/all/modules/xmlsitemap/xmlsitemap.admin.inc: No such file or directory
error: sites/all/modules/xmlsitemap/xmlsitemap.module: No such file or directory

However, even after moving the module to hardcoded directory it fails to apply:

git apply xmlsitemap-7.x-2.x-854632-31.patch
error: patch failed: sites/all/modules/xmlsitemap/xmlsitemap.module:19
error: sites/all/modules/xmlsitemap/xmlsitemap.module: patch does not apply

The one previous patch also failed, apparently because it's too old while dev branch has gone ahead since then.

I see many moved to 8.x, but there are still tons' of 7.x websites, so would be nice if the module maintainers made clear which is the recommended path, especially if the light of new recommendation pointed in #29 and #31: https://www.sitemaps.org/protocol.html

Here is the patch file that should be applied against the last 7.x-2.x version. Hopefully, this will get in before any other changes in dev, as there are still many Drupal 7 websites which badly needs this feature.