HTTP 307 Temporary Redirect Explained for Website Owners

The 307 Temporary Redirect is an HTTP status code defined in RFC 7231 that signals a requested resource currently resides at a different URL. When your server sends this code, it instructs the browser to fetch content from an alternative location specified in the Location header, but crucially, it mandates that the browser must use exactly the same HTTP method and request body as the original request.

The process follows three distinct steps. First, a browser requests your original URL, perhaps sending a POST request with form data to yoursite.com/submit-form. Second, your server responds with a 307 status code alongside a Location header pointing to yoursite.com/temp-submit. Third, the browser automatically re-requests the new URL using the same POST method and includes the identical form data from the original request. This method preservation distinguishes 307 from older redirect codes where browsers might unpredictably change the request type.

The Location header contains the full URL where the resource temporarily lives. Modern browsers automatically follow this redirect without user intervention, creating a seamless experience. Your server logs will show two separate requests: the initial one returning 307 and the subsequent request to the new location returning the actual content, typically with a 200 OK status.

Method preservation means that when a user submits a form using a POST request, the 307 redirect ensures that form data travels intact to the new destination as another POST request. Without this guarantee, browsers might convert the POST into a simple GET request, transforming a data-rich form submission into an empty page visit that carries none of the information your customer just entered.

During the HTTP/1.0 era, redirect codes like 302 allowed browsers to behave unpredictably. Some browsers would preserve the POST method, whilst others would automatically switch to GET, causing form resubmission failures that frustrated users and lost business data. The HTTP/1.1 specification introduced 307 specifically to eliminate this ambiguity by requiring strict method retention across all compliant browsers.

Consider a customer completing your checkout form with payment details, shipping address and product selections. If your server redirects this submission and the browser converts POST to GET, all that form data vanishes. The payment processor receives an empty request, the transaction fails and your customer sees an error page. With 307, the browser re-sends the complete POST request with all form fields intact, allowing the payment to process successfully at the temporary endpoint.

This protection extends beyond e-commerce. Contact forms collecting enquiries, file upload interfaces transferring documents and API endpoints receiving JSON payloads all rely on method preservation. When you’re temporarily moving these endpoints during server maintenance or hosting migrations, using 307 instead of 302 prevents data loss that could damage customer relationships or break integrations with third-party services.

Login processes particularly benefit from this behaviour. Authentication systems often use POST requests to submit credentials securely in the request body rather than exposing them in URL parameters. A redirect that changes POST to GET would either fail the login entirely or potentially expose sensitive credentials in browser history and server logs.

Website owners encounter multiple redirect types during hosting migrations, CMS configurations and server maintenance. Each status code serves distinct purposes, and choosing the wrong one can break functionality or harm search rankings.

Both 307 and 302 indicate temporary redirects, telling search engines to continue indexing the original URL rather than the redirect target. The critical difference lies in method preservation. The 302 status code, inherited from HTTP/1.0, doesn’t guarantee that browsers will maintain the original request method. Some browsers historically changed POST to GET when following 302 redirects, whilst others preserved the method, creating inconsistent behaviour across different user agents.

The 307 code, introduced in HTTP/1.1, mandates strict method preservation. Every compliant browser must re-send the request using the same HTTP method and include the original request body. This makes 307 the safer choice when redirecting form submissions, API calls or any POST request where data loss would cause problems.

SEO tools often recommend 302 for simple page moves because it enjoys broader compatibility with older bots and crawlers. For modern websites handling user interactions, 307 provides the reliability needed to prevent functionality issues. Use 302 when redirecting simple page views where method doesn’t matter and use 307 when redirecting forms, APIs or any endpoint that receives POST data.

The fundamental distinction between temporary and permanent redirects determines how search engines treat your URLs. Temporary redirects like 307 and 302 signal that the move is short-term, instructing search engines to continue indexing and ranking the original URL. Permanent redirects using 301 or 308 tell search engines the move is lasting, prompting them to replace the old URL with the new one in their index and transfer ranking signals.

Within permanent redirects, the same method preservation split exists. The 301 Moved Permanently code may allow browsers to change POST to GET, similar to 302’s behaviour. The newer 308 Permanent Redirect guarantees method preservation, functioning as the permanent equivalent of 307. When you need a lasting redirect for a form endpoint or API, 308 provides the same data protection as 307 whilst signalling permanence to search engines.

Search ranking implications differ significantly. Temporary redirects preserve link equity on the original URL because search engines expect you’ll eventually restore the content to its original location. Permanent redirects transfer that ranking value to the new URL, which benefits your SEO when the move is genuinely permanent but harms rankings if you later reverse the redirect.

Beyond the primary temporary and permanent redirects, you might encounter the 303 See Other status code. This code explicitly instructs browsers to always change the request method to GET, regardless of the original method. It’s useful after processing a POST request when you want to redirect users to a confirmation page without risking form resubmission if they refresh the browser. Unlike 307, which preserves POST, 303 deliberately converts it to GET.

• 303 See Other: Always changes to GET, used after form processing to prevent resubmission
• 304 Not Modified: Tells browser to use cached version, not actually a redirect
• 305 Use Proxy: Deprecated, instructs access through specified proxy
• 300 Multiple Choices: Presents list of resource options, rarely used in practice

Knowing when to implement 307 redirects helps you maintain functionality during temporary changes whilst protecting user data and search rankings. Different scenarios call for this specific status code rather than alternatives, particularly when method preservation becomes critical for your website’s operation.

During planned server maintenance, hosting platform migrations or major updates, you can use 307 redirects to send all visitors to a maintenance page whilst preserving the original URLs for search engines. This approach maintains your SEO standing because search engines see the redirect as temporary and continue indexing your actual content pages rather than the maintenance page.

Imagine you’re migrating your website to a new hosting platform over a two-hour maintenance window. Rather than letting visitors encounter error pages, you configure your server to redirect all requests to yoursite.com/maintenance.html using 307 status codes. Search engine crawlers visiting during this window receive the 307 response, understand the situation is temporary and return later to index your actual content. Your hosting uptime metrics might show the maintenance period, but your search rankings remain protected because you’ve signalled the temporary nature correctly.

The method preservation aspect matters less for simple page views during maintenance, but using 307 consistently across your site ensures that any form submissions or API calls that somehow reach your server during the maintenance window won’t lose data.

Protecting user data during temporary endpoint changes represents the primary use case for 307 redirects. When you need to move a contact form, payment processor or file upload handler to a temporary location, 307 ensures that submitted data reaches the new destination intact. This scenario commonly occurs during payment gateway updates, server load balancing or phased rollouts of new functionality.

Consider an e-commerce site updating its payment processing system. You want to redirect yoursite.com/checkout to yoursite.com/temp-checkout whilst the main checkout undergoes database schema changes. Using a 307 redirect guarantees that when customers submit their payment information via POST, the browser re-sends that complete POST request to the temporary endpoint. The payment processes successfully and customers never realise they’ve been redirected. Using 302 instead might cause some browsers to convert the POST to GET, losing all payment data and failing the transaction.

File upload forms particularly benefit from this protection. When users upload documents, images or other files, the browser sends a POST request with the file data in the request body. A redirect that doesn’t preserve the method would lose the uploaded file entirely, forcing users to restart the upload process.

Hosting providers sometimes use 307 redirects to temporarily route traffic between servers during high load periods or failover situations. When one server reaches capacity, the load balancer can redirect incoming requests to alternative servers using 307 to preserve request methods and data. This happens automatically at the infrastructure level and website owners rarely configure it manually.

Modern browsers implement a security feature called HTTP Strict Transport Security (HSTS) that automatically redirects HTTP requests to HTTPS. When your website has HSTS enabled, browsers internally generate “307 Internal Redirect” responses to force secure connections. This appears in browser developer tools as a 307 redirect from http://yoursite.com to https://yoursite.com, but it’s not configured by you as the website owner; it’s a browser security mechanism.

Chrome, Edge, Firefox and Safari all implement HSTS with 307 internal redirects. You’ll see these in the Network tab of developer tools, often with response times of 0ms because the browser handles them internally without contacting your server. Whilst you can’t configure these redirects directly, enabling HSTS on your server through headers or hosting control panel settings triggers this browser behaviour.

Search engines treat 307 redirects as temporary signals, continuing to index and rank your original URL rather than the redirect target. This behaviour protects your search visibility during short-term changes but requires understanding the timeframe limitations and proper implementation to avoid ranking issues.

When Googlebot encounters a 307 redirect, it interprets this as a temporary situation and returns to crawl the original URL in future visits. The redirect target doesn’t replace the original page in Google’s index and link equity remains associated with the original URL. This differs fundamentally from 301 permanent redirects, where Google transfers rankings and link value to the new URL, eventually removing the old URL from its index entirely.

The critical question becomes: how long is “temporary” in search engine terms? Google’s guidelines suggest that redirects lasting beyond six months should use 301 permanent status codes instead. If you implement a 307 redirect and leave it in place for a year, search engines may begin treating it as permanent regardless of the status code.

Google Search Console may display 307 redirects in the Coverage reports under “Page with redirect” status. This isn’t an error; it’s informational, showing Google detected the temporary redirect and will continue monitoring the original URL. Bing and other search engines follow similar temporary treatment, though their crawl frequencies and re-evaluation timelines may differ slightly from Google’s approach.

A common concern among website owners is whether 307 redirects hurt rankings. Properly used 307 redirects for genuinely temporary situations don’t harm rankings because search engines understand the temporary nature and maintain the original URL’s position. However, misusing 307 for permanent moves prevents search engines from transferring ranking signals. Similarly, creating redirect chains where URL A redirects to URL B, which redirects to URL C, dilutes link equity and increases crawl complexity.

Use 307 redirects for changes lasting days or weeks. Monitor the situation. If the change becomes lasting, switch to 301 permanent redirects to consolidate SEO value. During hosting migrations or maintenance windows, 307 provides the right tool to maintain functionality without risking SEO penalties. Many hosting providers can handle redirect configurations during migrations, implementing appropriate status codes based on whether moves are temporary or permanent.

Implementation methods vary depending on your hosting environment, control panel access and technical comfort level. Most website owners use one of several common approaches, from editing configuration files to using WordPress plugins or control panel tools.

Apache servers, which power most shared hosting environments in the UK, allow redirect configuration through the .htaccess file. This text file sits in your website’s root directory and controls various server behaviours, including redirects. You can access it via FTP clients like FileZilla or through your hosting control panel’s File Manager.

The simplest syntax uses Apache’s Redirect directive. To redirect a single page, add this line to your .htaccess file: Redirect 307 /old-page.html https://yourdomain.com/new-page.html. The first parameter specifies the status code, the second defines the path you’re redirecting from and the third provides the complete destination URL.

For more complex scenarios involving pattern matching or conditional redirects, Apache’s mod_rewrite module offers greater flexibility. The equivalent rewrite rule looks like: RewriteEngine On followed by RewriteRule ^old-page.html$ /new-page.html [R=307,L]. The RewriteRule uses regular expressions to match the incoming URL pattern, with the caret symbol marking the start and dollar sign marking the end. The [R=307,L] flags specify a 307 redirect and tell Apache to stop processing further rules.

Testing your redirects before deploying them widely prevents breaking your website. Open your browser’s developer tools, navigate to the Network tab and visit the URL you’re redirecting. The status column should show 307 and the Location header should display your target URL. Syntax errors in .htaccess files can break your entire website, showing a 500 Internal Server Error, so always keep a backup copy before making changes.

Most UK shared hosting uses cPanel-based Apache servers, making this method widely applicable. The .htaccess approach requires no server restart and takes effect immediately.

VPS and dedicated server users running Nginx configure redirects differently because Nginx doesn’t use .htaccess files. Instead, you edit the server block configuration files, typically located in /etc/nginx/sites-available/ on Linux systems. This requires SSH access and root or sudo privileges, making it less accessible for shared hosting customers but standard for VPS management.

The Nginx syntax for a 307 redirect uses the return directive within a location block. To redirect a specific page, add: location = /old-page.html { return 307 https://yourdomain.com/new-page.html; }. The equals sign creates an exact match for that specific path. For pattern-based redirects, you can use regular expressions: location ~ ^/old-section/ { return 307 https://yourdomain.com/new-section$request_uri; }.

After editing Nginx configuration files, you must test the syntax and reload the server. Run nginx -t to check for configuration errors, then systemctl reload nginx to apply changes without dropping existing connections. Syntax errors prevent Nginx from reloading, protecting your live site from breaking.

Some managed WordPress hosting providers use Nginx for performance benefits, but they typically restrict direct configuration file access. In these environments, you’ll need to contact support to implement server-level redirects or use plugin-based solutions instead.

WordPress powers a significant portion of websites and many site owners prefer managing redirects through the dashboard rather than editing server configuration files. Several plugins provide redirect management interfaces, with Redirection and Simple 301 Redirects being popular choices. These plugins create database entries that WordPress processes on each request, generating appropriate redirect responses without touching .htaccess or server configs.

Most redirect plugins default to 301 permanent redirects because they’re the most common use case. To create a 307 redirect, you must manually select the status code from a dropdown menu when creating the redirect rule. In the Redirection plugin, you’ll find this option under the redirect creation form labelled “HTTP code” or similar. Select 307 from the list, enter your source and target URLs and save the redirect.

Plugin-based redirects offer advantages for non-technical users: visual interfaces, redirect history tracking and easy modification without file editing. However, they add processing overhead because WordPress must load and check redirect rules on every page request. Server-level redirects in .htaccess or Nginx configs execute before WordPress loads, providing faster response times.

Other content management systems like Joomla, Drupal and Magento offer similar redirect extensions or built-in redirect managers. Look for status code selection options and choose 307 when method preservation matters for your use case.

Many UK shared hosting accounts use cPanel or Plesk control panels, which include redirect management tools in their interfaces. However, these tools present a limitation: cPanel’s built-in “Redirects” feature typically offers only 301 permanent and 302 temporary redirect options, omitting 307 from the dropdown menu. This reflects the tool’s age, as it was designed before 307 became widely adopted for method-preserving temporary redirects.

When you need a 307 redirect on cPanel hosting, you’ll need to use the .htaccess method described earlier instead of the Redirects tool. Access the File Manager, navigate to your website’s root directory, edit the .htaccess file and add your Redirect 307 or RewriteRule directives manually. Plesk faces similar limitations in its redirect interface, though some newer Plesk versions may include 307 support depending on the hosting provider’s configuration.

Some managed hosting providers, particularly those specialising in WordPress or application hosting, offer redirect configuration through support tickets or built-in tools that do support 307.

Even correctly configured redirects can cause problems when combined with other server rules, caching layers or conflicting settings. Recognising common issues and knowing how to diagnose them helps you resolve problems quickly without extended downtime.

A redirect loop occurs when page A redirects to page B, which redirects back to page A, creating an infinite cycle. Browsers detect this situation after approximately 20 redirect attempts and display an error message like “Too many redirects” or “ERR_TOO_MANY_REDIRECTS”. Visitors can’t access your content and search engines may stop crawling the affected URLs entirely.

Common causes include conflicting redirect rules in your .htaccess file, where multiple RewriteRule directives inadvertently create circular references. WordPress plugins can also create redirect loops when multiple redirect plugins operate simultaneously or when plugin redirects conflict with server-level rules. HTTPS enforcement rules sometimes create loops if configured incorrectly, particularly when combined with other redirects.

To fix redirect loops, start by checking your redirect chain using online tools like Redirect Checker or HTTP Status Code Checker. These tools follow redirects and display the complete chain, making loops immediately visible. Next, review all redirect rules in your .htaccess file, looking for patterns that might create circles. Comment out rules one at a time by adding a hash symbol at the line start, testing after each change to identify the problematic rule.

Clear your browser cache and cookies after making changes because browsers cache redirect responses, sometimes continuing to follow old redirect paths even after you’ve fixed the server configuration. In Chrome or Firefox, open developer tools, right-click the refresh button and select “Empty Cache and Hard Reload” to ensure you’re seeing current server responses rather than cached redirects.

If you’re using WordPress, deactivate all redirect plugins temporarily to determine whether they’re causing the loop. Reactivate them one at a time, testing between each activation. Check for duplicate rules where both a plugin and .htaccess file implement the same redirect, potentially with slightly different configurations that create loops.

For persistent loops you can’t resolve, temporarily rename your .htaccess file to .htaccess.backup via FTP or File Manager. This disables all .htaccess rules, allowing you to access your site and methodically rebuild the configuration.

Website owners frequently encounter unexpected 307 redirects after migrating to new hosting providers. The old server may still have redirect rules in place or DNS propagation delays mean some visitors still reach the old server, which then redirects them using outdated rules. This creates confusion because the website works for some visitors whilst others see redirects to incorrect locations.

DNS propagation typically takes 24 to 48 hours after changing nameservers or A records. During this period, different visitors may reach different servers depending on which DNS servers their internet provider queries. If your old hosting account remains active with 307 redirects configured, visitors hitting the old server will follow those redirects even though you’ve moved the site.

To resolve this, first verify your DNS has fully propagated using tools like WhatsMyDNS.net, which checks DNS records from servers worldwide. If propagation is incomplete, wait for it to finish before troubleshooting further. Once DNS points to your new server, check the .htaccess file on the new hosting account for any redirect rules that shouldn’t exist. Hosting migration tools sometimes copy .htaccess files including temporary redirects that were only meant for the old server.

Contact your old hosting provider to remove any redirect rules from the old server once DNS has propagated. Some providers automatically add redirects when accounts are suspended or closed, which can interfere with your migration.

Browser developer tools provide the most direct method for diagnosing redirect issues without installing additional software or using online services. Every modern browser includes these tools, making them universally accessible for troubleshooting.

In Chrome, Firefox, Edge or Safari, press F12 to open developer tools. Navigate to the Network tab, which displays all HTTP requests your browser makes when loading a page. Reload the page you’re testing and the Network tab populates with a list of requests showing the URL, status code, type and other details.

Look for entries with 307 status codes in the Status column. Click on any 307 entry to view detailed information including the Response Headers section, which contains the Location header showing where the redirect points. This reveals the exact redirect target without following the redirect yourself, helping you trace redirect chains or identify incorrect destinations.

The Waterfall view in the Network tab shows timing information, revealing how long each redirect takes and whether redirect chains are impacting page load performance. Multiple redirects appear as separate entries, allowing you to count how many redirects occur and identify whether you’ve created unintentional chains.

For persistent redirect issues where browsers cache responses, use the Network tab’s “Disable cache” checkbox, which forces the browser to request fresh responses from your server rather than using cached redirects.

Every redirect adds an extra HTTP request to the page loading process, introducing latency that affects user experience and search engine performance metrics. Understanding this impact helps you minimise redirects where possible and implement them efficiently when necessary.

A single redirect typically adds 100 to 300 milliseconds to page load time, depending on server response time and network distance between the user and your hosting server. This delay occurs because the browser must complete the initial request, receive the 307 response, parse the Location header and then initiate a second request to the redirect target. For users on fast connections with nearby servers, this delay barely registers. For mobile users on slower connections or visitors geographically distant from your server, the impact becomes more noticeable.

Redirect chains compound this delay. If URL A redirects to URL B, which redirects to URL C, you’ve added two redirect hops and potentially 200 to 600 milliseconds of latency before any actual content loads. Search engines particularly dislike redirect chains because they waste crawl budget and slow down indexing. Google’s PageSpeed Insights tool explicitly penalises excessive redirects, flagging them as opportunities for improvement.

Core Web Vitals, Google’s user experience metrics introduced as ranking factors, include redirect time in the Largest Contentful Paint measurement. LCP measures how long it takes for the largest visible element to load and redirects delay this by postponing when the browser can even begin requesting the actual content. Sites with multiple redirects may struggle to achieve good LCP scores, particularly on mobile devices where network latency is higher.

Server response time significantly affects redirect performance. Hosting servers with solid-state drives, optimised web server software like LiteSpeed or Nginx and adequate resources respond to redirect requests faster than overloaded shared hosting servers with mechanical drives. Faster server response times reduce redirect latency, making each redirect hop less impactful on overall page load times.

To minimise performance impact, audit your redirects regularly using tools like GTmetrix, Pingdom or Google PageSpeed Insights. These services trace redirect chains and report total redirect time, helping you identify problematic chains or unnecessary redirects. Eliminate redirect chains by updating links to point directly to final destinations rather than intermediate URLs. When implementing new redirects, always redirect to the final destination in a single hop rather than creating multi-step chains.

Content Delivery Networks can’t eliminate redirect latency entirely, but they can reduce it by serving redirect responses from edge locations closer to users. However, this only helps if the redirect target is also served through the CDN.

The 307 Temporary Redirect serves as the safest choice for short-term page moves where preserving HTTP methods matters, particularly for maintenance pages, form submissions and temporary API changes. Its strict method preservation guarantee prevents data loss during redirects, ensuring POST requests with form data, file uploads or API payloads arrive intact at the redirect target. Unlike the older 302 code, which allowed browsers to unpredictably change POST to GET, 307 eliminates this ambiguity and protects functionality.

Distinguishing between temporary and permanent redirects determines your SEO outcomes. The 307 tells search engines the change is temporary, protecting your original URL’s rankings whilst the redirect remains active. This differs fundamentally from 301 permanent redirects, which transfer ranking value to the new URL and eventually remove the old URL from search indexes.

Implementation varies by hosting setup. Most website owners use .htaccess configuration on shared hosting, Nginx server blocks on VPS environments or WordPress plugins for dashboard-based management. Testing redirects before deployment prevents breaking functionality and browser developer tools provide immediate feedback on redirect status codes and chains. Regular audits catch redirect chains that accumulate over time, maintaining optimal performance.

For website owners uncertain about their hosting provider’s redirect capabilities or needing assistance with server configurations during migrations, consulting your hosting support ensures smooth transitions. Hosting providers can implement appropriate redirect strategies that protect both user experience and search visibility during temporary changes.