Hi Eric, Sebastian from Jetpack here. I hope you are doing well.
Thank you for reaching out and sharing your concern with us. I have reach out to our developers for more details on this.
We’ll get back to you shortly. In the mean time, could you please post your site URL here so that we can have a look? If you want it to remain private, you can also contact us via this contact form:
https://jetpack.com/contact-support/?rel=support&hpi=1
If you choose to reach out directly, please include a link to this thread.
Thanks!
Thank you, Sebastian. The site is: https://www.wind-watch.org/news/
(The WordPress module is for that subdirectory, not the site as a whole.)
An example request is: "GET /news/feed/ HTTP/1.1" 304 - "https://www.wind-watch.org/news/feed/" "WordPress.com; https://stopthesethings.com"
There’s no way to tell a feed reader to visit less often. They visit on their own schedule.
and including is_feed()
Do you mean you’ve checked is_feed in the “Do not cache the following page types.” section of the settings page? The feed isn’t being cached then.
The 304 status means your server is telling the visitors hitting your feed that the feed hasn’t changed so very little information is sent and the request happens really fast. They are caching the feed, and on each request they’re asking if the feed has updated. If there isn’t an update, then it’s a 304 reply.
is_feed is not checked (hence the 304 responses instead of 200).
It seems to me that if they are caching the feed anyway, they should be able to be told for how long before checking if it’s been modified. But then after that time, they might still check. Would Cache-Control and ETag (which WP Super Cache sets) conflict? Maybe it’s a standard for feed readers to always validate?
I just noticed that I never turned off an experiment I started when I was having trouble with SImplePie (which I use to compile a weekly newsletter): simply directing a feed request to a static xml file. I just downloaded Monday’s sample, and it has the Cache-Control header as set in htaccess for xml files.
I’m just a dilletante here, and I can’t begin to grasp the intricacies of WP Super Cache’s workings, but I’m finding this interesting nonetheless. Thanks for your indulgence!
Hi @ericr23 –
Since the feed readers visit on their own schedule, there isn’t anything that can be done in WP Super Cache to affect that behavior.
I am going to mark this thread as resolved, but if you have questions about WP Super Cache in the future, feel free to open a new thread.
I added the following to robots.txt, and that has brought it under control.
User-agent: WordPress
Crawl-delay: 8
Hi there, @ericr23,
Thanks for sharing the solution you found out – I trust that solved the issue, is that correct?
If so, you should be all set, and we’d like to thank you again for reporting this here: other users may have your same need, and this info will save them some time 🙂
