Redirects

Prevent Browser From Caching a 301 Redirect: Leverage Cache-Control Headers

June 18, 2024
5 minute read

There maybe times where you want to redirect a URL using HTTP 301 status code, which signifies a permanent redirect. However, what if you don't want this redirect to be cached by the browser? This is where the use of the Cache-Control header comes in handy.

This article will explain how to use the Cache-Control header to prevent browsers from caching 301 redirects. Additionally, we will discuss how to implement the various directives on popular web servers.

Why Prevent Browser Caching of 301 Redirects?

While the caching of 301 redirects is a good thing in most scenarios - it helps speed up navigation to commonly visited URLs - there may be circumstances where this is not the desired result. For instance, if you're in the process of developing a site and are frequently changing urls and redirects, caching can lead to confusion and erroneous results. Another use-case might be when your site has implemented temporary URL structures that may change over time, and you don't want your users to be stuck with the outdated structures.

Using the Cache-Control Header

The Cache-Control HTTP header is used to specify directives for caching mechanisms of http requests and responses. The directives specify who can cache the response, under which conditions, and for how long.

To prevent browsers from caching a 301 redirect, you can add the Cache-Control header with the no-store directive to your HTTP response. This tells the browser not to store a copy of the document in its cache.

Let's go through a basic example:


HTTP/1.1 301 Moved Permanently
Location: http://www.new-website.com
Cache-Control: no-store

In this example, the server sends back a 301 Moved Permanently status code, indicating that the requested resource has been assigned a new permanent URI and any future references to this resource should use one of the returned URIs. The Location field holds the new URI where the resource resides. The Cache-Control header with the no-store directive tells the client (the browser) not to cache this redirect.

Implementing the Cache-Control Header in Different Web Servers

The way you add the Cache-Control header will depend on your server software. Below are brief tutorials on how to do this in some popular web servers:

Apache

In Apache, you can use the .htaccess file to add headers to your HTTP responses. Lets look at how to implement this below:


<IfModule mod_headers.c>
    Header set Cache-Control "no-store"
</IfModule>

Nginx

In Nginx, you can add headers within a server or location block in your server configuration file. Lets look at how to implement this below:


location / {
    add_header Cache-Control "no-store";
}

Remember to reload or restart your server after making these changes for them to take effect.

Exploring Other Important Cache-Control Directives

The Cache-Control header has several other directives that allow you to control how, by whom, and for how long a resource can be cached. Let's look at a few more of these directives.

no-cache

Unlike no-store, the no-cache directive doesn't prevent the caching of a resource. Instead, it specifies that the stored response must be validated with the server every time before it's served. This ensures that users always receive the most up-to-date version of a resource, while still benefiting from caching.

In other words, no-cache allows a response to be cached, but tells the browser that it must not use the cached response without first checking with the server to see if there are any changes.

max-age

The max-age directive specifies the maximum amount of time (in seconds) a resource is considered fresh. Once this time has passed, the cached copy of the resource is considered stale, and the client will re-fetch the resource from the server.

For example, Cache-Control: max-age=3600 means that the resource can be cached, and that cache is valid for one hour.

public and private

public and private directives control where a resource can be cached.

If a response is marked public, it can be cached by any cache, including those that are shared among multiple users, such as a CDN. This is useful for resources that are the same for all users.

On the other hand, a response marked private is intended for a single user and must not be cached by a shared cache. A private browser cache (i.e., the cache on a user's local machine) can store such a response.

Combining Cache-Control Directives

These directives can be combined to achieve more specific caching policies. For example, Cache-Control: private, max-age=600 means that the response is specific to a single user and can be stored in the user's browser cache for up to 600 seconds.

It's important to remember that while using these directives provides you with greater control over how your responses are cached, not all browsers and caches respect all directives, and the exact behavior can sometimes depend on the specific browser and its version.

Final Thoughts:

Understanding the Cache-Control directives and their respective behaviors can greatly enhance your control over how your web resources are cached. While the no-store directive is particularly useful for preventing caching of 301 redirects, other directives like no-cache, max-age, and public/private provide also additional flexibility for managing web resource caching policies.

Ready To Manage Your Links More Effectively?

Our team is ready to help you manage your links more efficiently so you can get back to what it is you do best!

URL Redirect Link Management
Redirects

Prevent Browser From Caching a 301 Redirect: Leverage Cache-Control Headers

April 3, 2023
5 minute read
301 Redirection

A redirect is a tool used by websites for “rerouting” or sending a visitor to an alternative webpage. An example of a redirect would be when you type “example.com” in your web-browser, but are taken to a different website, like “new-example.com.”

URL redirects are an extremely common practice employed by webmasters and content managers to ensure visitors to their website are reaching their desired content.

When would I use a redirect?

  1. A page has been relocated within your site
    Let’s say your website has a page by the path “/t-shirts” – The “t-shirts” page has been a part of your website sitemap for years, and is one of your most frequently visited pages. Suddenly, you need to build out a more general page on your site that has t-shirts, and dress shirts. Your goal is to have the new page be accessible by a shorter, more general path, like “/shirts”. In this situation, you would want to use a URL redirect to ensure that traffic for the page “/t-shirts” is successfully rerouted to the new “/shirts” page of your website. Without a redirect in place, you could run the risk of visitors still accessing the old /t-shirts page, even though you want to drive all traffic to the new /shirts page. Due to the nature of SEO, it’s possible that there are many links throughout the Internet that still point visitors to the old URL, and it is the job of the URL redirect to ensure visitors still make it to the appropriate page.
  2. Your domain name is changing!
    Changing a website’s domain name is a drastic decision which must be handled with the utmost care. Let’s say your website has always been www.abc-brand.com. Due to a rebranding effort, you are changing your brand from “ABC” to “XYZ”, and thus your website’s URL will need to be adjusted to reflect the change. In this scenario, it would be critical that you 301 redirect all traffic requesting “abc-brand.com” to the new and improved “xyz-brand.com”. Furthermore, you would want to ensure that all pages within the abc-brand website are also redirected, like abc-brand.com/my-page being redirected to xyx-brand.com/my-page
  3. You have alternative domains that you wish to serve as “shortcuts” into your website
    It is a common practice for businesses to buy dozens of domain names that:
  • Are spelled similarly to their business name – consider “gogle.com” that redirects to google.com
  • Are variations of their name that visitors may otherwise know them as – consider “joes-tees.com” that redirects to the main business website, “joes-shirts.com”
  • Are shortened, easily typed versions of the primary domain name – consider “shirtsale2019.com” redirecting to “joes-shirts.com”. It is common to find this shorter, more memorable URL variation on physical advertisements because people are more likely to remember them. As such, a URL redirect would be used to reroute the alternative domain name to your primary domain name of your website.

How does a redirect actually work?

When you request a web-page from your browser, there is a server somewhere on the Internet that is receiving your request and responding with the appropriate content. Fundamentally, a redirect occurs when a web-server's response contains a special piece of data (an HTTP response header) instructing the browser to reroute the visitor to an alternative location.

The technical details aside, a browser works by requesting a URL and rendering the page that is returned by the website. If the website wishes the user to be redirected, the server will respond differently than if it was serving a page; it will send an extra piece of data indicating that the visitor should be redirected to a specified location.

Without going into too much of the technical details – a redirect is a behavior performed by a web-browser whenever it receives a response containing a flag (an HTTP header) to do so.

What are the types of redirects available?

301 Redirect

Commonly referred to as a “permanent” redirect.

Indicates to search-engines and web-browsers that the requested page has permanently relocated to a new location.

Note: permanent redirects are often cached by web-browsers like Chrome and Firefox. Therefore, it may be tricky to retroactively update a 301 redirects target location once it has been established. Any visitors who have already received the 301 redirect response for a URL will likely be served a cached response from their web-browser when visiting the same URL again.

Suggestion Only use a 301 redirect when you know that the target location will not change.

Common Uses

  • A 301 redirect is appropriate when a website is changing it’s domain name. In this scenario, the site should be 301 redirecting all traffic for it’s old domain name to the new website URL.
  • Another common use-case for a 301 redirect is for pages within your website that have been permanently moved to a new URL

302 Redirect

Commonly referred to as a “temporary” redirect.

Useful for general-purpose redirects within your website, where you do not want visitor’s to cache the redirect response permanently.

Suggestion Use 302 redirects for pages that have changed URL, but are subject to be updated in the future

Common Uses

  • A page is temporarily being moved to a new URL
  • Conditions where the destination location of the redirect is subject to change
  • Navigating the user away from a page during an error

307 Redirect

Uncommon due to legacy browser support

Used for technical scenarios when a visitor’s HTTP request method should be persisted when they are redirected. For example, if a user submits a form, the browser normally issues a POST request to the form’s action URL. If the server responds with a 302 redirect response, the client’s web-browser would typically issue a GET request when handling the redirect. However, if the server responds with a 307 redirect response, the client’s web-browser will POST request to the redirect destination. Please note, form-data is typically lost when redirecting via POST request.

When do I need a redirect?

The most common use-cases that would require a redirect are:

  1. Changing your domain name
  2. Restructuring website pathing, resulting in URL changes for content within your website
  3. URL shortening – having a shorter, more memorable alternative to your primary domain name.
  4. Sending traffic from additional/alternative domain names (Example: gogle.com redirects to google.com)
  5. Sending traffic from your DNS zone apex / naked domain name to your “www” sub-domain (Example: domain.com 301 redirects to www.domain.com)

Important considerations when redirecting a URL

  1. Ensure your URL supports HTTPS connections! Otherwise you may have visitors who are receiving broken links.
  2. When redirecting a specific path within your website, you may want to match paths based on a pattern or Regular Expression, as opposed to a single path.
  3. Seriously consider whether you should use a 301 or a 302, based on the information above.

There maybe times where you want to redirect a URL using HTTP 301 status code, which signifies a permanent redirect. However, what if you don't want this redirect to be cached by the browser? This is where the use of the Cache-Control header comes in handy.

This article will explain how to use the Cache-Control header to prevent browsers from caching 301 redirects. Additionally, we will discuss how to implement the various directives on popular web servers.

Why Prevent Browser Caching of 301 Redirects?

While the caching of 301 redirects is a good thing in most scenarios - it helps speed up navigation to commonly visited URLs - there may be circumstances where this is not the desired result. For instance, if you're in the process of developing a site and are frequently changing urls and redirects, caching can lead to confusion and erroneous results. Another use-case might be when your site has implemented temporary URL structures that may change over time, and you don't want your users to be stuck with the outdated structures.

Using the Cache-Control Header

The Cache-Control HTTP header is used to specify directives for caching mechanisms of http requests and responses. The directives specify who can cache the response, under which conditions, and for how long.

To prevent browsers from caching a 301 redirect, you can add the Cache-Control header with the no-store directive to your HTTP response. This tells the browser not to store a copy of the document in its cache.

Let's go through a basic example:


HTTP/1.1 301 Moved Permanently
Location: http://www.new-website.com
Cache-Control: no-store

In this example, the server sends back a 301 Moved Permanently status code, indicating that the requested resource has been assigned a new permanent URI and any future references to this resource should use one of the returned URIs. The Location field holds the new URI where the resource resides. The Cache-Control header with the no-store directive tells the client (the browser) not to cache this redirect.

Implementing the Cache-Control Header in Different Web Servers

The way you add the Cache-Control header will depend on your server software. Below are brief tutorials on how to do this in some popular web servers:

Apache

In Apache, you can use the .htaccess file to add headers to your HTTP responses. Lets look at how to implement this below:


<IfModule mod_headers.c>
    Header set Cache-Control "no-store"
</IfModule>

Nginx

In Nginx, you can add headers within a server or location block in your server configuration file. Lets look at how to implement this below:


location / {
    add_header Cache-Control "no-store";
}

Remember to reload or restart your server after making these changes for them to take effect.

Exploring Other Important Cache-Control Directives

The Cache-Control header has several other directives that allow you to control how, by whom, and for how long a resource can be cached. Let's look at a few more of these directives.

no-cache

Unlike no-store, the no-cache directive doesn't prevent the caching of a resource. Instead, it specifies that the stored response must be validated with the server every time before it's served. This ensures that users always receive the most up-to-date version of a resource, while still benefiting from caching.

In other words, no-cache allows a response to be cached, but tells the browser that it must not use the cached response without first checking with the server to see if there are any changes.

max-age

The max-age directive specifies the maximum amount of time (in seconds) a resource is considered fresh. Once this time has passed, the cached copy of the resource is considered stale, and the client will re-fetch the resource from the server.

For example, Cache-Control: max-age=3600 means that the resource can be cached, and that cache is valid for one hour.

public and private

public and private directives control where a resource can be cached.

If a response is marked public, it can be cached by any cache, including those that are shared among multiple users, such as a CDN. This is useful for resources that are the same for all users.

On the other hand, a response marked private is intended for a single user and must not be cached by a shared cache. A private browser cache (i.e., the cache on a user's local machine) can store such a response.

Combining Cache-Control Directives

These directives can be combined to achieve more specific caching policies. For example, Cache-Control: private, max-age=600 means that the response is specific to a single user and can be stored in the user's browser cache for up to 600 seconds.

It's important to remember that while using these directives provides you with greater control over how your responses are cached, not all browsers and caches respect all directives, and the exact behavior can sometimes depend on the specific browser and its version.

Final Thoughts:

Understanding the Cache-Control directives and their respective behaviors can greatly enhance your control over how your web resources are cached. While the no-store directive is particularly useful for preventing caching of 301 redirects, other directives like no-cache, max-age, and public/private provide also additional flexibility for managing web resource caching policies.