Cache & Redirects

When a short link destination is updated, new visitors see the change immediately. Returning visitors may not — because their browser cached the old redirect.

---

Definition

Caching in the context of redirects refers to a browser or intermediary (CDN, proxy) storing a redirect response locally so that future requests to the same URL are fulfilled without contacting the origin server. When a browser caches a 301 redirect, it maps the original URL to the destination URL in its local cache — subsequent visits to the original URL go directly to the cached destination.

For URL shorteners, redirect caching creates a specific behaviour: when a destination is updated, visitors who have a cached version of the old redirect continue to go to the old destination until their cache expires. New visitors — who have no cached version — see the updated destination immediately.

How Browser Caching of 301 Redirects Works

1. Visitor clicks a short link for the first time → browser sends request to shortener server
2. Server returns 301 response with the destination URL in the Location header
3. Browser follows the redirect to the destination
4. Browser stores the mapping (short link → destination) in its local redirect cache
5. Visitor clicks the same short link again → browser uses cached redirect, goes directly to old destination without contacting the server
6. If the destination was updated in Cuttly between visits, the browser cache prevents the visitor from seeing the update

How long the browser caches a 301 redirect depends on the Cache-Control header in the redirect response and the browser's own caching policies. Modern browsers generally cache 301 redirects more aggressively than other response types — treating "permanent" as a strong signal to cache.

Practical Implications for Link Management

In most real-world link management scenarios, redirect caching is not a significant problem:

• Most clicks come from new contexts. Links shared in emails and social posts reach recipients who may click once or twice. Repeat visits to the same short link are rare in campaign contexts — so cached redirects affect a small proportion of actual traffic.
• Cache duration is finite. Redirect caches do expire. A destination update becomes effective for all visitors eventually, even without intervention.
• The issue is most significant for permanent reference links. A short link used as a permanent reference — in an email signature, on a business card, in a presentation template used repeatedly — may be clicked many times by the same visitors over months. For these links, a destination update may take longer to propagate to all repeat visitors.

Workarounds for Destination Updates

When a destination update must propagate immediately to all visitors including those with cached redirects:

• Create a new link with a different slug. The new slug has no cached version in any browser. Update distributed materials to use the new link. The old link can be updated or expired.
• Clear your own browser cache when testing destination updates — browser-cached redirects affect testing as much as real visitors.
• Use incognito / private browsing when testing updated destinations to see the current server-side state without local cache interference.

CDN and Proxy Caching

In addition to browser caching, CDNs and transparent proxies between the visitor and the shortener server may cache redirect responses at the network level. Cuttly manages its own infrastructure caching — destination updates made in the dashboard take effect on the server side immediately. Any CDN caching at the network level uses short TTLs to ensure updates propagate quickly.

Related Terms

• Redirect Types
• HSTS
• HTTPS & SSL
• Link Expiration