A 304 Not Modified is an HTTP status code that tells a browser the resource it requested has not changed since the last time it was fetched. Instead of sending the full response again, the server instructs the browser to load the page from its local cache instead.

Despite being grouped in the 3xx status code family, a 304 is technically not a redirect in the traditional sense. No URL change is involved and the user is not sent anywhere new. It is a caching mechanism, a way for servers and browsers to communicate efficiently and avoid transferring data that has not changed.

How a 304 works

Every time a browser requests a resource, a web page, image, stylesheet, or script, the server can include response headers that describe when the resource was last modified and assign it a unique identifier called an ETag. The browser stores this information alongside the cached copy of the resource.

On the next request for the same resource, the browser sends conditional request headers back to the server, typically If-Modified-Since with the date of the last fetch, or If-None-Match with the stored ETag. The server checks whether the resource has changed since that date or whether the ETag still matches.

If nothing has changed, the server responds with a 304 and an empty body. The browser receives this, understands the cached version is still valid, and loads it locally without downloading anything new. If the resource has changed, the server responds with a 200 and sends the full updated content.

304 and web performance

The 304 response is one of the core building blocks of web performance. By avoiding unnecessary data transfer, it reduces latency, saves bandwidth, and speeds up page load times for returning visitors.

For websites with heavy assets (large images, JavaScript bundles, stylesheets) effective use of 304 responses and HTTP caching can dramatically reduce server load and improve page speed. This has a downstream effect on Core Web Vitals metrics like LCP, which measures how quickly the largest visible element on a page loads.

The cache-control header works alongside 304 responses to define how long a resource should be considered fresh before the browser needs to revalidate with the server.

304 vs other 3xx status codes

The 304 stands apart from every other code in the 3xx family because it does not involve a URL change. Every other 3xx code: 301, 302, 303, 307, 308 sends the browser to a different location. The 304 simply says: stay where you are and use what you already have.

This distinction matters for SEO as well. A 304 has no effect on how search engines index a URL or how SEO equity flows between pages. It is purely a performance and caching signal between client and server.

304 and SEO

From an SEO perspective the 304 is largely invisible. Googlebot and other web crawlers support conditional requests and will receive 304 responses when crawling pages that have not changed since their last visit. This is actually beneficial, it means crawlers are not wasting crawl budget re-downloading content that has not been updated.

Where it becomes worth paying attention is during site migrations or major content updates. If a page has been significantly changed but caching headers are misconfigured, crawlers may receive a 304 and serve an outdated version from cache. After any significant change to a page, it is worth verifying that cache headers are set correctly so crawlers and browsers fetch the updated version.

Is a 304 ever a problem?

In most cases a 304 is a sign that caching is working correctly. However there are scenarios where it can cause issues:

• Stale content being served: if a resource has been updated but the ETag or last-modified header was not updated correctly, browsers and crawlers may continue receiving 304 responses and serving outdated content.

• During development: developers frequently encounter 304 responses when testing changes locally and finding the browser is serving a cached version rather than the updated file. A hard refresh or clearing the browser cache resolves this.

• After a site migration: if old cache-control headers set aggressive caching, some users may continue to see old content after a migration until their cache expires or is invalidated.

How 304 relates to redirect management

If you are managing redirects across multiple domains, the 304 sits in a separate layer from your redirect rules entirely. Your 301 and 302 redirects handle URL routing. The 304 operates at the caching layer, it only comes into play once a request has already resolved to its final destination URL and the browser is checking whether the content at that URL has changed.

A well-configured redirect setup combined with proper caching headers means visitors and crawlers get fast, accurate responses at every step, routing handled by your redirects, performance handled by 304 caching.