WordPress – How to Fix Home Page Caching Issues by setting the Last-Modified response Header to the most recent post An effective workaround to overcome a common WordPress problem that might cripple your SEO efforts

Wordpress - How to Fix Home Page Caching Issues by setting the Last-Modified response Header to the most recent post

If you’re reading this, it probably means that you are experiencing an odd behaviour on your WordPress home page: you are often unable to see your most recent posts, as if the browser is serving a cached version of your web page instead of the updated one. Such issue is also particularly common when visiting the web site from mobile devices.

What’s the root cause of the problem, and what can we do to fix that?

Nine times out of then, the problem is due to caching issues: either your web server has a server-side cache – be it a reverse-proxy, a PHP-CGI based proxy, a caching plugin or anything else – which is not working properly, or it’s sending some (or all) the pages with wrong response headers… or both. As a matter of fact, the former scenario is fairly common because most caching mechanisms – expecially the reverse-proxies – can be hard to configure properly: just to be sure, try to temporarily disable all of them and see if the problem persist. However, if the home page is the only affected page, it most likely means that you’re dealing with the latter: more precisely, a rather obscure WordPress problem which is related to the Last-Modified response header.

The Issue

To fully understand the root cause of the problem, it can be useful to quickly recap what the Last-Modified response header is and why we should handle it properly.

As you might already know, the Last-Modified response HTTP header contains the date and time at which the origin server believes the resource was last modified. It is used as a validator to determine if a resource received or stored is the same: conditional requests containing If-Modified-Since or If-Unmodified-Since headers make use of this field.

What you probably don’t know (yet) is that WordPress doesn’t handle such response header properly: as a matter of fact, it doesn’t deal with it at all, meaning that your WordPress pages – including the Home Page – do not have it at all. That’s not an issue for post and pages, as they don’t get modified frequently – in terms of SEO, either they do exist or not: however, the absence of such header can be troublesome for an Home Page, expecially for a blog or a news-based web site when it’s most likely updated each and every time a new post is published.

There are a number of plugin – Clearfy being the most popular one – that provide a fix for that, by setting a Last-Modified response header accordingly to some given parameters: unfortunately, most of them – including Clearfy, at least as of today – tend to set it considering the actual post/page last modified date: again, although it can decently work for post and pages, it’s definitely NOT a good choice for the Home Page for the aforementioned reasons.

As a matter of fact, in most Worpdress Home Pages are made of templates and/or widgets that gets updated each time a new post gets published – meaning that the last modified date of the actual page/template is absolutely meaningless and should not be taken into account. Conversely, we should find a way to retrieve the date of the last published post – aka the most recent post – and use that value instead.

The Fix

Luckily enough, this StackExchange thread comes to the rescue by providing a great way to set the Last-Modified response header of the Home Page in a suitable way – which is, as we wrote early on, getting the date of the most recent post.

Here’s the relevant snippet: just place it in your WP’s function.php file and you’ll have a good chance to get rid of your home page caching issue.

IMPORTANT: If you’re also using a plugin (such as the aforementioned Clearfy) that handles the Last-Modified response header in any way, remember to change its configuration settings to prevent it from doing that anymore to avoid the risk that the snippet’s header settings will be overwritten during the WordPress response life cycle.

That’s it for now: I sincerely hope that this workaround will help most WordPress developer that experienced this nasty issue!

 

RELATED POSTS

About Ryan

IT Project Manager, Web Interface Architect and Lead Developer for many high-traffic web sites & services hosted in Italy and Europe. Since 2010 it's also a lead designer for many App and games for Android, iOS and Windows Phone mobile devices for a number of italian companies.

View all posts by Ryan