By SitemapFixer Team
Updated May 2026

307 Redirect: What It Means and When to Use It for SEO

Check all redirect chains and status codes across your site in one scan.Analyze My Site Free

HTTP status codes in the 3xx range all involve redirection, but the SEO implications of each code differ significantly. The 307 Temporary Redirect is one of the most misunderstood codes in the set — often confused with 302, frequently used incorrectly for permanent changes, and occasionally mistaken for an error when it appears in HSTS-related browser logs. This guide explains exactly what a 307 does, how Google treats it, and when it is — and is not — the right tool for the job.

What Is a 307 Redirect?

A 307 Temporary Redirect is an HTTP response status code that tells the requesting client — a browser, a crawler, or an API consumer — that the resource at the requested URL has temporarily moved to a different URL, specified in the Location response header. The key word is temporarily: the client is told to continue using the original URL for future requests, not to update its bookmarks or cached pointers to the new location.

The 307 code was formally defined in HTTP/1.1 (RFC 7231) to address a specific ambiguity that existed in the 302 code. The defining characteristic of a 307 is strict HTTP method preservation: whatever method the original request used — GET, POST, PUT, DELETE — the redirected request must use the same method. The browser or client is not permitted to switch to GET automatically.

In the Location header, the server returns the destination URL. The client follows this URL for the current request, then for all future requests continues to use the original URL — it does not update its stored reference.

307 vs 302: The Key Difference

Both 307 and 302 indicate a temporary redirect, so they are often treated as interchangeable. They are not. The difference lies in HTTP method handling.

The HTTP specification for 302 (Found) was historically ambiguous: it stated the client could follow the redirect using a different method, and in practice nearly every browser implementation changed POST requests to GET when following a 302. This became the de facto standard behavior. The result is that a 302 following a POST form submission will almost always turn that POST into a GET at the destination — which is often fine for simple page navigation, but can break APIs and form handlers that expect POST data.

The 307 code was introduced precisely to fix this. A 307 explicitly requires that the client use the same HTTP method at the redirect destination. If the original request was a POST with a body, the client must re-send that POST with the same body to the destination URL. This makes 307 the correct choice in any scenario where form data or request method semantics must be preserved through the redirect.

From a pure SEO perspective, both 302 and 307 are treated similarly by Google: both are temporary signals, neither consolidates ranking signals to the destination the way a 301 does. The method-preservation distinction matters for application behavior but does not change how Google evaluates the redirect for indexation purposes.

307 vs 301 for SEO

This is the comparison that matters most for search engine optimization. The 301 and 307 codes have fundamentally different signals for Google:

A 301 Permanent Redirect tells Google that the original URL has moved permanently to the destination. Google's crawler updates its index to replace the old URL with the new one, consolidates PageRank and link equity from the old URL to the new URL, and eventually stops crawling the old URL altogether. External links pointing to the old URL effectively pass their authority to the new URL. Rankings typically transfer within weeks to a few months.

A 307 Temporary Redirect tells Google that the move is temporary. Google follows the redirect and crawls the destination, but it keeps the original URL in its index, does not consolidate ranking signals from the original URL to the destination, and continues to crawl the original URL expecting it to return its content again in the future. External links pointing to the original URL continue to pass authority to that original URL — not to the temporary destination.

The practical implication: if you redirect example.com/old-page to example.com/new-page with a 307 and never restore the original URL, you have created a permanent redirect using a temporary signal. Google may eventually treat it like a 301 if the redirect persists long enough, but this is unreliable and can delay ranking transfer by months. Use 301 for permanent URL changes.

Does Google Follow 307 Redirects?

Yes. Googlebot follows 307 redirects and crawls the destination URL. The redirect does not block crawling or indexation of the destination page. However, Google's treatment of the destination differs from a 301 scenario in two important ways.

First, Google indexes the original URL, not necessarily the destination. Because the 307 signals that the original URL is the canonical location, Google typically keeps the original in its index rather than substituting the destination URL — even though users are being served the destination content.

Second, ranking signals (PageRank, link equity) are not fully consolidated to the destination. The original URL retains its authority. If the destination URL acquires backlinks of its own during the temporary redirect period, those signals accrue to the destination — but the original URL's existing authority does not transfer.

In practice, this means a long-lived 307 redirect can create a confusing split between the URL Google keeps in the index, the URL that accumulates backlinks, and the URL users actually see in their address bar. Monitoring your GSC Coverage report while a 307 is active is essential to understanding which URL Google is treating as canonical.

Real Use Cases for 307 Redirects

307 redirects are appropriate in a narrower set of scenarios than 301 or even 302 redirects. Genuine use cases include:

HTTPS migration testing. Before committing to a permanent HTTPS redirect, a 307 allows you to test that all pages render correctly, all mixed-content issues are resolved, and analytics and tracking are intact — without permanently signaling to Google that the migration is complete. Once testing is complete, upgrade to 301.

A/B testing URLs. Redirecting traffic temporarily to a variant URL for conversion rate testing, without permanently ceding rankings from the control URL to the variant. When the test concludes, the 307 can be removed with no lasting SEO impact on the control URL.

Maintenance pages. Redirecting a URL to a maintenance page while the actual content is being updated or a server is being maintained. The original URL retains its index position and returns to serving its content when maintenance ends.

Login and authentication flows. POST-based login form submissions that redirect to a dashboard or success page should use 307 (or 303 See Other) to preserve method semantics correctly. In most web frameworks, the POST-Redirect-GET pattern uses a 303 See Other, but 307 is appropriate when the POST must be re-submitted at the destination.

When NOT to Use 307

The majority of redirect scenarios in SEO work call for a 301, not a 307. Do not use 307 in these situations:

Permanent URL changes. If you are consolidating URLs, migrating to a new domain, reorganizing a site's URL structure, or retiring an old page in favor of a new one — use a 301. A 307 on a permanent URL change delays index updates and wastes the link equity of the original URL.

Canonical URL enforcement. If you want to consolidate multiple URL variants (with and without trailing slash, with and without www) into a single preferred URL, use a 301 redirect combined with a canonical tag. A 307 does not reliably consolidate duplicate URL signals.

SEO-critical link equity transfer. Any scenario where preserving and transferring the PageRank accumulated on the original URL matters — site migrations, domain changes, page merges — requires a 301. A 307 does not reliably transfer link equity to the destination.

Long-term redirects with no plan to restore the original URL. If the original URL will never serve content again, a 307 is the wrong signal. Google will continue crawling and expecting content at the original URL indefinitely. Use a 301 or, if the content is genuinely gone permanently, a 410 Gone.

How to Implement a 307 in Common Stacks

Implementing a 307 redirect varies by server and framework. Here are implementations for the three most common environments:

Apache (.htaccess)

# Apache .htaccess — 307 Temporary Redirect
RewriteEngine On

# Redirect a specific page temporarily
RewriteRule ^old-page/?$ /new-page [R=307,L]

# Redirect an entire directory temporarily
RewriteRule ^old-section/(.*)$ /new-section/$1 [R=307,L]

Nginx

# Nginx — 307 Temporary Redirect
server {
    listen 80;
    server_name example.com;

    # Redirect a specific location temporarily
    location = /old-page {
        return 307 /new-page;
    }

    # Redirect a path prefix temporarily
    location /old-section/ {
        return 307 /new-section$request_uri;
    }
}

Next.js Middleware

// middleware.ts — Next.js 307 Temporary Redirect
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl;

  // Temporary redirect during maintenance
  if (pathname === '/old-page') {
    return NextResponse.redirect(
      new URL('/new-page', request.url),
      { status: 307 }
    );
  }

  return NextResponse.next();
}

export const config = {
  matcher: ['/old-page'],
};

Note that in next.config.js redirects, the default status code is 307 when permanent: false is set (or omitted). Set permanent: true to issue a 308 (the permanent equivalent of 307) or explicitly pass statusCode: 301 via middleware for maximum SEO compatibility.

Checking if a Redirect Is a 307

Two quick methods to verify what status code a URL is returning:

Using curl in the terminal — the -I flag fetches only the response headers, and -L follows redirects so you can see each hop in the chain:

# Check redirect status without following the chain
curl -I https://example.com/old-page

# Follow the full redirect chain and show all hops
curl -IL https://example.com/old-page

# Check how Googlebot sees the redirect
curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/old-page

The response will include the status line (HTTP/2 307) and the Location: header showing the redirect destination.

Using browser DevTools — open DevTools (F12), navigate to the Network tab, enable "Preserve log", and reload the URL. Look for the initial request in the waterfall; its status column will show 307 and the Response Headers panel will show the location header. Note that most browsers follow redirects automatically, so you need "Preserve log" enabled to capture the 307 response before the browser moves to the destination.

307 in HSTS (HTTP Strict Transport Security)

One of the most common places you will see a 307 in the wild is in browser network logs for sites that have implemented HTTP Strict Transport Security (HSTS). When a browser visits http://example.com and the site has previously set a Strict-Transport-Security header, the browser intercepts the request internally and issues a 307 redirect to the HTTPS version — before even sending a request to the server.

This is an internal browser redirect, not a server response. It shows up in DevTools as a 307 from a cached HSTS policy, often labeled as "307 Internal Redirect" with the initiator marked as the browser's security layer. No actual network request reaches the HTTP server.

This HSTS-internal 307 is expected behavior and has no negative SEO implications. Google understands HSTS and does not penalize sites for it. Googlebot handles HSTS correctly — if the crawler has seen the HSTS header previously, it upgrades future requests to HTTPS automatically. The internal 307 you see in browser DevTools is not visible to Google at all; Googlebot makes direct HTTPS requests once it has cached the HSTS policy.

If you see widespread 307s appearing in your server logs or in a crawl audit tool, and they are not from HSTS, investigate them directly. Unexpected 307s from your application code may indicate misconfigured redirect rules, middleware conflicts, or authentication flows redirecting search engine bots incorrectly. Use SitemapFixer or Screaming Frog to map all redirect chains on your site and identify any 307s that should be 301s.

Find Redirect Chains and Status Code Issues Instantly
Free sitemap and SEO analysis in 60 seconds
Analyze My Site Free

Related Guides