What Is a 308 Status Code?

The 308 Permanent Redirect is an HTTP response status code defined in RFC7538 Section 3, designed to signal that a requested resource has been permanently moved to a new location — and that all future requests for that resource should go to the new URI provided by the server.

What makes the 308 special (and distinct from older redirects like 301) is that it explicitly requires the client to preserve the original HTTP method and body when following the redirect.
For example:
If the original request was a POST, the client must resend the redirected request as a POST.
If it was a PUT, it must stay a PUT.
This eliminates the ambiguity seen in older redirect codes (like 301), where many clients (especially older browsers) would switch non-GET requests to GET after being redirected.

Key Characteristics of 308 Permanent Redirect

Permanent move
The 308 status tells the client that the resource has permanently shifted to a new address, and clients (including browsers, crawlers, and APIs) should update any saved links, bookmarks, or references.

Method preservation
Unlike 301 (which can downgrade POST to GET), 308 guarantees the method and body are preserved, making it safe for sensitive operations such as:

Form submissions (POST).
Resource updates (PUT).
Data deletions (DELETE).

Location header
The server response must include a Location header pointing to the new URI:

HTTP/1.1 308 Permanent Redirect  
Location: https://new.example.com/resource

Cacheable by default
Unless explicitly overridden by cache-control headers, the 308 response is considered cacheable, allowing clients and intermediaries (like proxies and CDNs) to store the redirect mapping for future requests.

Example Scenario

Imagine an API provider reorganizes its endpoint structure and wants to permanently shift:

POST https://api.example.com/v1/upload

POST https://api.example.com/v2/upload

To ensure that:

Clients permanently update their endpoints.
The POST method and body are preserved (since a file upload is involved).

The server responds with:

HTTP/1.1 308 Permanent Redirect  
Location: https://api.example.com/v2/upload

Clients, respecting the standard, will:

Automatically resend the POST request to the new location.
Update their internal references to point to the v2 endpoint.

The 308 Permanent Redirect provides developers and systems with a precise, method-preserving tool for implementing permanent redirects. It improves upon older 3xx codes by eliminating method-change ambiguity, making it ideal for modern web services, APIs, and applications that rely on complex HTTP operations beyond simple GET requests

How Does a 308 Redirect Work?

A 308 Permanent Redirect works through a clear, standardized flow between the client and the server, ensuring that both the permanent nature of the redirect and the preservation of the original HTTP method are honored.

Let’s break it down step by step.

Step 1: Client Sends an Initial Request

The client (which could be a browser, API client, or web crawler) sends a request to the server.
This request can use any HTTP method, such as:

GET (fetching a page or resource)
POST (submitting form data or uploading files)
PUT (updating a resource)
DELETE (removing a resource)

Example:

POST /old-path HTTP/1.1  
Host: example.com  
Content-Type: application/json  
Content-Length: 200

Step 2: Server Responds with 308 and a Location Header

The server determines that the requested resource has permanently moved and responds with:

HTTP/1.1 308 Permanent Redirect  
Location: https://example.com/new-path  
Cache-Control: public, max-age=86400

Key parts:

308 status line indicates a permanent redirect.
Location header specifies the new permanent URI.
Cache-Control allows clients and intermediaries (like CDNs) to store the redirect mapping.

Step 3: Client Follows the Redirect with the Same Method

Unlike older codes (like 301), where many clients switch non-GET methods (like POST) to GET after redirection, the 308 explicitly requires:

The same HTTP method to be used in the redirected request.
The same request body to be included if present.

Example:

POST /new-path HTTP/1.1  
Host: example.com  
Content-Type: application/json  
Content-Length: 200

This ensures that sensitive operations like form submissions or API calls are handled correctly after redirection.

Step 4: Client Updates Bookmarks, References, or Links

Because the redirect is permanent, clients that can store or modify saved links (such as browsers, bookmark managers, or crawlers) are expected to:

Update future references to the new URI.
Stop sending requests to the old URI and go directly to the new one.

Step 5: Future Requests Go Directly to the New Location

For all subsequent interactions, the client should now use:

https://example.com/new-path

This reduces unnecessary redirect chains, improves performance, and ensures consistency across systems.

The 308 redirect flow works by:

Receiving an original request.
Sending a 308 response with a Location header.
Having the client follow the redirect using the same method and body.
Updating all future requests to use the new, permanent URI.

308 Code References Across Frameworks

When implementing a 308 Permanent Redirect, developers typically rely on the constants, symbols, or helper functions provided by their frameworks and programming languages rather than hardcoding the number 308 into their code.

Using these predefined references ensures:

Better readability and clarity
Fewer risks of typos or inconsistencies
Compatibility with framework features like logging or redirect helpers

Here’s how the 308 status code is referenced across popular development environments.

Common 308 References by Language or Framework

Environment / Language	Code Reference
Symfony (PHP)	`Response::HTTP_PERMANENTLY_REDIRECT`
.NET (C#)	`HttpStatusCode.PermanentRedirect`
Rust	`http::StatusCode::PERMANENT_REDIRECT`
Ruby on Rails	`:permanent_redirect`
Go (Golang)	`http.StatusPermanentRedirect`
Python 3.5+	`http.HTTPStatus.PERMANENT_REDIRECT`
Apache HttpComponents (Java)	`org.apache.hc.core5.http.HttpStatus.SC_PERMANENT_REDIRECT`
Angular (TypeScript)	`@angular/common/http/HttpStatusCode.PermanentRedirect`

Example Code Snippets

Python (Flask)

from flask import redirect

@app.route('/old')
def old_route():
    return redirect('/new', code=308)

Go (Golang)

http.Redirect(w, r, "/new", http.StatusPermanentRedirect)

Symfony (PHP)

use Symfony\Component\HttpFoundation\RedirectResponse;

$response = new RedirectResponse('/new', Response::HTTP_PERMANENTLY_REDIRECT);
$response->send();

Node.js (Express)

app.post('/old', (req, res) => {
    res.redirect(308, '/new');
});

Why Use Constants Instead of Raw Numbers?

Using the built-in framework constants:

Improves code readability (any developer can understand PermanentRedirect without memorizing numeric codes).
Reduces the chance of introducing typos like accidentally writing 380 or 3080.
Integrates smoothly with framework-specific tools, middleware, or helpers.

No matter which programming language or framework you’re using, you can rely on clear, standardized 308 references to build permanent, method-preserving redirects cleanly and safely.

Differences Between 308 and Other Redirect Codes

To fully understand the role of the 308 Permanent Redirect, it’s important to compare it directly with the other major HTTP redirect codes — particularly 301, 302, and 307. While all these codes signal redirection, they differ in whether the redirect is temporary or permanent and whether they preserve the original HTTP method.

Let’s break this down carefully.

1. 301 Moved Permanently

Purpose:
Tells the client the resource has permanently moved to a new URI, and future requests should go directly to the new address.
HTTP Method Behavior:
Clients are allowed (and often do) change the HTTP method — for example, a POST may become a GET.
Typical Use:
For permanent SEO-safe redirects, website migrations, or consolidated resources.
Key Difference from 308:
308 guarantees the original method is preserved; 301 does not.

2. 302 Found (Temporary Redirect)

Purpose:
Indicates a temporary move, where the client should use the original URI for future requests.
HTTP Method Behavior:
Historically ambiguous, but most implementations allow changing the HTTP method, such as turning POST into GET.
Typical Use:
Temporary page moves, testing redirects, or load balancing.
Key Difference from 308:
302 is temporary and does not preserve the HTTP method, while 308 is permanent and explicitly preserves it.

3. 307 Temporary Redirect

Purpose:
A temporary redirect that must preserve the HTTP method.
HTTP Method Behavior:
Enforces method preservation (e.g., POST remains POST).
Typical Use:
Temporary maintenance or rerouting while keeping sensitive methods intact.
Key Difference from 308:
307 is temporary; 308 is permanent.

Summary Table

Code	Name	Temporary/Permanent	Preserves HTTP Method?
301	Moved Permanently	Permanent	No (method may change)
302	Found	Temporary	No (method may change)
307	Temporary Redirect	Temporary	Yes
308	Permanent Redirect	Permanent	Yes

When Should You Use 308?

Choose 308 when:

You need a permanent redirect.
You want to guarantee the original HTTP method and body are preserved during the redirect.
You’re dealing with sensitive operations like form submissions, file uploads, or API calls where changing the method could break functionality.

FAQs About 308

What Is the Difference Between a 308 Status Code and a 307 Status Code?

Both 308 and 307 require the client to preserve the original HTTP method and request body when following the redirect.

The key difference is:

308 is a permanent redirect: clients should update saved links, bookmarks, and future requests to point to the new URI.
307 is a temporary redirect: clients should continue using the original URI for future requests.

In short:

Use 307 for short-term rerouting.
Use 308 when the move is final and long-term.

What Is the Difference Between a 308 Status Code and a 301 Status Code?

While both 308 and 301 signal a permanent move, they differ in how they handle the HTTP method.

301 allows the client to change the request method (for example, a POST may be turned into a GET).
308 explicitly instructs the client to use the same HTTP method as the original request when following the redirect.

If method preservation matters — especially for non-GET operations — 308 is the safer, standards-compliant choice.

What Is the Difference Between a 308 Status Code and a 302 Status Code?

The main differences:

302 is temporary: the client should keep using the original URI for future requests.
308 is permanent: the client should update to use the new URI.

Additionally:

302 often allows (or causes) the HTTP method to change (especially in older implementations).
308 guarantees the HTTP method stays the same.

Does a 308 Status Code Affect SEO?

Yes, and in a positive way — when used correctly.

Like a 301, the 308 Permanent Redirect passes SEO link equity (ranking signals) to the new URL, telling search engines that the content has permanently moved.
Because it preserves the method, it’s especially useful for:

Migrating API endpoints.
Redirecting forms or transaction pages.
Moving non-GET resources where method changes could break user flows.

Proper implementation ensures you maintain search engine rankings, reduce crawl errors, and provide a seamless user experience.

When Should I Use a 308 Over a 301?

Use a 308 when:

The move is permanent.
You need to preserve the original HTTP method (for example, POST, PUT, DELETE).

If you only care about GET requests and aren’t worried about method preservation, a 301 may be sufficient.

Best Practices for Using 308

Implementing the 308 Permanent Redirect correctly is crucial to ensure both human users and automated systems (like search engines, crawlers, and API clients) handle your redirects smoothly, safely, and as intended.

Here’s a detailed set of best practices to help you apply 308 effectively.

1. Use 308 Only for Permanent Redirects

The 308 status code explicitly signals that:

The resource has been permanently moved to a new URI.
Clients should update saved references, bookmarks, and future requests to use the new location.

If your redirect is temporary (for example, during maintenance or testing), you should use:

307 Temporary Redirect (method-preserving)
302 Found (method-change-allowed, though less predictable)

Using 308 for short-term or temporary moves can create confusion, outdated bookmarks, and even SEO issues.

2. Preserve the Original HTTP Method

The defining feature of 308 is that it guarantees the client must preserve the original HTTP method when following the redirect:

A POST must remain a POST.
A PUT must remain a PUT.
A DELETE must remain a DELETE.

This makes 308 particularly useful for:

API migrations.
Form submission pages.
File upload endpoints.

Make sure your destination endpoint is ready to handle the same method and body as the original request.

3. Provide a Valid Location Header

The server must include a clear, valid Location header pointing to the new permanent URI:

HTTP/1.1 308 Permanent Redirect  
Location: https://new.example.com/resource

Without a proper Location header, clients won’t know where to redirect, leading to errors and broken flows.

4. Update Internal Links and Documentation

Once you implement a 308 redirect:

Update all internal links on your site or application to point directly to the new URI.
Update API documentation, developer portals, or public references.
Notify any external partners or clients who may have hardcoded the old endpoint.

Relying solely on redirects adds unnecessary hops and complexity — better to point links directly where possible.

5. Monitor and Test Redirect Behavior

After deploying a 308:

Use tools like curl, browser DevTools, or Postman to confirm that the redirect works as intended.
Check that the client preserves the HTTP method.
Monitor server logs and analytics to catch any unexpected traffic patterns or errors.

Testing ensures that the user experience remains smooth and that automated systems (like search engine crawlers) process your redirects properly.

By following these best practices:

You apply the 308 Permanent Redirect only where appropriate.
You ensure method integrity across all redirected requests.
You maintain a clean, efficient, and SEO-friendly redirect strategy.

Common Mistakes with 308

While the 308 Permanent Redirect is a powerful tool, it’s easy to misuse if you’re unfamiliar with its specific rules and behaviors. Let’s break down the most common mistakes developers, site managers, and system architects make when implementing 308 — so you can avoid them.

1. Misusing 308 for Temporary Redirects

One of the most frequent errors is applying a 308 when the redirect is only temporary.
Remember:

308 = permanent; instructs clients and search engines to update references.
307 = temporary; tells clients to follow the redirect just for now, but continue using the original URI later.

If you mislabel a temporary move as permanent, you risk:

Search engines updating their indexes prematurely.
Users’ bookmarks pointing to the wrong long-term destination.
Clients caching the wrong location.

2. Assuming It’s Interchangeable with 301

While both 308 and 301 indicate permanent moves, they behave differently regarding HTTP methods:

301 may allow method changes (like POST → GET) — older clients often do this.
308 explicitly forbids changing the method or request body.

If you blindly swap 301 with 308 without considering whether method preservation matters, you may break:

Form submissions.
File uploads.
Sensitive API operations.

3. Not Updating Internal References

A common oversight is leaving old internal links pointing to the original (now redirected) URI.
Even though the 308 handles the redirection, maintaining unnecessary hops:

Slows down user experience.
Adds extra server load.
Creates messy analytics with mixed paths.

Always update your internal links, sitemaps, API documentation, and partner references after deploying a 308.

4. Forgetting to Test Method Handling

Because 308 preserves the HTTP method, you must ensure:

The destination endpoint is ready to handle the exact same method and body.
Any system components, middlewares, or load balancers between the client and server respect and properly pass through the method.

Failing to test this can result in:

Server errors.
Broken user flows.
Unreliable API integrations.

5. Ignoring Cache Behaviors

By default, a 308 response is cacheable unless overridden by explicit cache-control headers.
If you don’t want clients, CDNs, or proxies to cache the redirect, you need to explicitly set:

Cache-Control: no-cache, no-store

Otherwise, stale or unintended caching could cause long-term routing problems.

How to Troubleshoot 308 Issues

If you’re encountering unexpected 308 Permanent Redirect responses — or if things aren’t behaving as you expect after deploying a 308 — here’s a structured troubleshooting process to help you diagnose and resolve the issue.

Step 1: Confirm Server-Side Configuration

Check the system or application where the 308 is being set:

Review server configuration files (like .htaccess for Apache, nginx.conf for NGINX, or routing rules in frameworks like Express or Django).
Ensure the redirect rule is properly defined as a 308, not accidentally using a different code like 301 or 307.
Double-check that the Location header points to the correct, valid destination.

Misconfigured rules or typos can easily generate incorrect or broken redirects.

Step 2: Test with the Right Tools

Use tools like:

curl (command line):
```
curl -I -L -X POST https://example.com/old-path
```
This lets you see the status codes, headers, and final destination.
Browser Developer Tools (Network tab) to inspect redirect chains and responses.
Postman or similar API testing tools to verify the behavior for non-GET requests.

Look for:

Whether the redirect occurs.
Whether the HTTP method is preserved.
Whether the destination returns the expected result.

Step 3: Check Client-Side or Integration Handling

Sometimes the issue isn’t on the server but in how the client handles the 308.
For example:

Outdated or non-compliant clients may not respect method preservation.
Some libraries or integrations may mishandle or block permanent redirects.
Automated scripts or tools might follow the redirect incorrectly or break on certain HTTP methods.

Make sure your clients, apps, or partners are equipped to handle 308 properly.

Step 4: Verify Destination Endpoint Behavior

Once the redirect happens:

Is the destination endpoint configured to handle the original HTTP method (especially for POST, PUT, DELETE)?
Are there any authentication, validation, or CORS issues that are stopping the redirected request?
Does the destination return the right success or error codes?

It’s not enough for the redirect to work — the target also needs to accept the incoming request correctly.

Step 5: Monitor and Log

After applying fixes:

Monitor server logs to check for continued 308 responses or any error patterns.
Use monitoring tools (like Google Search Console for SEO or API monitoring tools for backend services) to ensure traffic flows are working smoothly.

Make sure:

SEO crawlers are interpreting the permanent redirect properly.
Human users are landing on the right pages without loops or dead ends.
APIs and integrations are consistently reaching the correct resources.

Additional resources

Return to Glossary

Return to SEO Firm Dubai