What Does an HTTP 304 Response Do for Crawling Your Site?

What does an HTTP 304 response actually do when Googlebot crawls your site?

A 304 Not Modified response tells a crawler that the page has not changed since its last visit, so the server sends no page body and the crawler reuses its cached copy. Google says its crawlers support this through ETag and Last-Modified headers. The result is cheaper, faster recrawls of pages that rarely change.

Most marketing teams never think about this. They think about content, links, and maybe Core Web Vitals. But every time a crawler visits a page that has not changed, your server either sends the whole page again or answers with a short, cheap 304. On a large site with thousands of stable URLs, that difference adds up.

I work on B2B sites with large CMS archives, including this one, and caching headers are one of the least understood technical details in a typical audit. Here is what a 304 does, how crawlers ask for one, and what you should check on your own site.

What is a 304 Not Modified response?

A 304 is an HTTP status code that means the resource has not changed since the version the client already has. It only happens in response to a conditional request, where the client sends a validator from its previous copy. The server compares that validator with the current version and returns 304 with no body if they match.

Browsers have used this mechanism for decades. When you revisit a page, your browser may ask the server whether its cached copy is still good. If the server says yes with a 304, the browser shows the cached version almost instantly.

Crawlers can do the same thing. Instead of downloading every page on every visit, a crawler that supports caching can ask, has this changed, and skip the download when the answer is no.

A 304 is not an error and it is not a redirect. It is a normal, healthy response. It only becomes a problem when a server sends 304 for a page that really did change, which can leave crawlers holding an outdated copy.

How do crawlers ask for a 304?

Crawlers send a conditional request that includes a validator from their last visit. With ETag, the crawler sends the old value in an If-None-Match header. With Last-Modified, it sends the old date in an If-Modified-Since header. If the server's current value matches, it should return 304 with no body.

Google explained this mechanism in its Search Central post "Crawling December: HTTP caching," published on December 9, 2024. The post says Google's crawling infrastructure supports heuristic HTTP caching through the ETag response header with the If-None-Match request header, and the Last-Modified response header with the If-Modified-Since request header.

The ETag is an identifier for one specific version of a page, often a hash of its content. Last-Modified is a timestamp. Both answer the same question in different ways: is the copy the crawler holds still current?

Google's post recommends ETag because it is less prone to errors, since its value is not a structured date. It also suggests setting both if you can. For Last-Modified, the post says the date must follow the HTTP standard format, and it suggests a max-age value in the Cache-Control header to hint how long content will stay unchanged.

Why does a 304 matter for your site and for crawling?

A 304 saves work on both sides. Your server does not have to generate or transfer the page body, and the crawler retrieves the content from its own cache. Google's post says that for a large site with rarely changing content, allowing caching may help the site be crawled more efficiently.

Google framed the benefit plainly in that post. The empty body matters because your server does not spend compute generating content and does not spend bandwidth transferring it. On the crawler side, the cached content is retrieved quickly because no data transfer is involved.

The same post also shared a striking figure. According to Google Search Central in December 2024, about 0.026 percent of Google's total fetches were cacheable ten years earlier, and that share had fallen to 0.017 percent. In other words, very few sites were giving crawlers a chance to reuse anything.

I would not oversell this. A 304 does not improve rankings, and it will not rescue a site with weak content. What it does is reduce wasted fetches on pages that have not changed, which matters most when your site is large and your important pages compete for a crawler's attention.

Which pages on a B2B site benefit most from 304 responses?

Pages that rarely change benefit most: older blog posts, documentation, glossary pages, case studies, legal pages, and archived resources. These pages get recrawled repeatedly even though nothing has changed. Answering those revisits with 304 frees crawl activity for new and updated pages that actually need attention.

Think about a B2B blog with a thousand posts. Most of those posts will never change again after publishing. Every recrawl of an unchanged post that returns a full page is work that tells the crawler nothing new.

Pages that change often, like a homepage with rotating content or a pricing page under active testing, benefit less. They will return full responses most of the time anyway, because their validators keep changing.

If you want to see how crawlers actually spend their visits on your site, the Crawl Stats report in Google Search Console is the place to look. My guide on what the Crawl Stats report tells a small site walks through how to read it.

How do you check whether your site returns ETag or Last-Modified headers?

Request a page and look at its response headers. In a browser, open developer tools, load the page, and inspect the main document's headers. From a terminal, run curl with the head option against the URL. Look for an ETag header, a Last-Modified header, and a Cache-Control header in the response.

If you see an ETag, you can test the conditional request yourself. Copy the ETag value, then send a second request with that value in an If-None-Match header. A server that supports it should answer with 304 instead of 200. If it answers 200 every time, conditional requests are not being honored.

Repeat the check on a few page types: the homepage, a blog post, a CMS template page, and a static asset. Behavior can differ between them, especially if your site sits behind a CDN or proxy that adds or strips headers.

While you are in the headers, confirm the basic status codes are right too. A page that should be live returning a redirect, or a deleted page returning 200, is a bigger problem than a missing ETag. My checklist for checking HTTP status codes on a Webflow site covers those basics.

What if you run your site on a hosted platform like Webflow?

On hosted platforms, the hosting layer usually controls response headers, so you may not be able to set ETag or Cache-Control yourself. Check what your pages currently return, then read your platform's official hosting documentation or ask its support. Your job is to confirm the behavior, not to fight the platform.

This is a common situation for Webflow, Framer, and similar hosted builders. The platform and its CDN decide most caching behavior. Some platforms expose settings, and some do not. Because those details can change, rely on the vendor's current documentation rather than a blog post, including this one.

What you can control is content behavior. Avoid needless changes to stable pages, such as rotating widgets, timestamps that change on every load, or random elements in the HTML. Anything that makes the page different on every request makes validators change too, which defeats caching even when the server supports it.

Google's post makes a related point: deciding what counts as a meaningful change is up to you. It suggests requiring a cache refresh on significant content changes, and notes that only updating a copyright date is probably not significant.

Can 304 responses ever cause problems?

Yes, when validators are wrong. If a server returns 304 for a page that did change, crawlers keep an outdated copy. This can happen with a misconfigured cache, a Last-Modified date that never updates, or an ETag based on something other than the actual content. Accurate validators matter more than having them at all.

The fix is to make sure validators change whenever meaningful content changes. If your ETag is a hash of the page body, it updates naturally. If it is tied to something unrelated, such as a deploy version that does not change when CMS content updates, it can go stale.

The same principle applies to sitemap dates. A lastmod value that never changes, or that changes every day for no reason, teaches crawlers to ignore it. I covered that in what a sitemap lastmod date actually does, and the logic is the same for cache validators: be accurate or be ignored.

What should you do next?

Pick five URLs of different types and inspect their response headers. Note whether each returns an ETag, a Last-Modified date, and a Cache-Control value. Test one conditional request with If-None-Match. If your platform controls headers, check its documentation, and focus on keeping stable pages truly stable.

This is a small, technical check, and it will not transform your traffic. But on a large archive, letting crawlers skip unchanged pages is one of the quieter ways to make sure your new work gets noticed sooner.

If you want help reviewing the technical side of a large Webflow or CMS site, reach out at pravinkumar.co. Let's chat.