Last Modified Header Test

Understanding the Last-Modified Header and HTTP Caching

Every time a browser or search engine crawler requests a page, the server has an opportunity to say exactly when that resource was last changed. This is the job of the Last-Modified header, one of the oldest and still most widely used caching signals on the web. When present, it tells a client the precise date and time a file was updated, which allows future requests to ask a simple question: has anything changed since then? If the answer is no, the server can skip sending the full page again and instead reply with a lightweight HTTP 304 Not Modified response, saving bandwidth for both the visitor and the hosting server.

A 304 status code is not an error; it is actually a sign of a healthy, well-configured website. It means the browser already has a valid cached copy and the server has confirmed nothing new needs to be sent. This exchange happens through conditional requests, typically using the If-Modified-Since header, which carries the previously known Last-Modified value back to the server for comparison. Many sites also use ETag alongside or instead of Last-Modified, since an ETag is a unique fingerprint of the content itself, offering stronger validation when exact timestamps are unreliable, such as on dynamically generated pages.

Cache-Control works hand in hand with these validators but serves a slightly different purpose. While Last-Modified and ETag support revalidation, Cache-Control defines the freshness rules, for example how many seconds a browser can use a cached copy before checking back at all. A page with a long max-age combined with a valid Last-Modified header gets the best of both worlds: fast repeat visits from cache, and efficient revalidation once that cache window expires. Missing or misconfigured cache headers are a common technical SEO issue, often quietly slowing down page speed scores and increasing unnecessary server load, especially on image-heavy or resource-heavy websites.

So how do you actually check whether your server is doing this correctly? The most reliable method is to send a real HTTP request and inspect the response headers directly, exactly what a cache checker tool like this one does. First, a HEAD request retrieves the current Last-Modified and ETag values without downloading the full page body. Then, a second conditional request is sent using those exact values, and the tool watches for an HTTP 304 code in response. If the server plays along correctly, that confirms revalidation is working as intended. If it instead returns a full 200 response every time, it usually indicates missing or broken cache validation logic on the origin server or CDN.

Testing this manually with browser developer tools is possible but tedious, especially across many pages at once. A dedicated last modified header test tool makes the process practical at scale, letting you paste a batch of URLs and get immediate answers about caching health across an entire site. This kind of check is particularly valuable after a CDN migration, a server software upgrade, or when troubleshooting why a search engine crawler seems to be re-downloading unchanged pages more often than expected, since crawl efficiency and caching correctness are closely linked in modern SEO and site performance work.