The Complete HTTP Redirect Guide: Every Status Code, Method, and Best Practice

HTTP redirects are how the web handles change. When a URL moves, a redirect tells browsers and search engines where to go instead. Get them right and your users never notice. Get them wrong and you lose traffic, break bookmarks, and tank your search rankings.

This guide covers every redirect type, every implementation method, and every mistake worth avoiding. Whether you are moving a single page or migrating an entire domain, the answer is in here.

---

What is an HTTP redirect?

An HTTP redirect is a server response that tells the client to request a different URL. When your browser asks for a page and the server responds with a 3xx status code plus a Location header, the browser automatically follows that header to the new URL. [1]

The process is invisible to users. They click a link, the server responds with a redirect, and the browser fetches the new location. All of this happens in milliseconds. But behind the scenes, each redirect type carries different instructions about whether the move is permanent or temporary, whether the request method should change, and how search engines should treat the old URL.

GET /old-page HTTP/1.1
Host: example.com

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page

Understanding which status code to use, and when, is the difference between a clean migration and months of lost rankings.

How the redirect process works

When a redirect occurs, the full sequence is:

1. The browser sends an HTTP request to the original URL
2. The server responds with a 3xx status code and a Location header containing the new URL
3. The browser reads the Location header and automatically sends a new request to that URL
4. The new server responds with the actual page content (usually a 200 OK)

This can happen multiple times in a row, creating a redirect chain. The browser follows each hop until it reaches a non-redirect response or hits a limit (most browsers give up after 20 hops). The entire chain adds latency, which is why keeping redirects to a single hop matters for performance.

When to use a redirect

Redirects are the right solution when:

• A page has permanently moved to a new URL
• Your site has migrated to a new domain
• You are consolidating duplicate content (e.g., www and non-www versions)
• You are forcing HTTPS across your site
• A product or category URL structure has changed
• You are running A/B tests or geographic routing
• A form submission needs to redirect to a confirmation page

Redirects are not the right solution when:

• Two versions of the same content should remain accessible (use canonical tags instead)
• You want to completely remove a page with no replacement (use a 410 Gone or 404 instead)
• You want to serve different content to different users at the same URL (use server-side rendering or content negotiation instead)

The redirect status codes

The HTTP specification defines five redirect status codes in the 3xx range that are commonly used on the web. [2] Each one tells the browser something different about the nature of the move.

301 Moved Permanently

A 301 tells the browser and search engines that this URL has permanently moved to a new location. Browsers cache 301 redirects aggressively, and search engines transfer ranking signals from the old URL to the new one. [3]

Use 301 when:

• You have renamed a page and the old URL will never come back
• You have moved your entire site to a new domain
• You are consolidating duplicate pages into a single canonical URL
• You are forcing HTTP to HTTPS

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page

301 is the most common redirect and the default choice for any permanent URL change. For a deep dive, see What Is a 301 Redirect?.

302 Found (Temporary Redirect)

A 302 tells the browser that the URL has temporarily moved. The browser follows the redirect but does not cache it as aggressively, and search engines keep the old URL in their index. [4]

Use 302 when:

• You are running an A/B test and sending some users to a variant
• A page is temporarily unavailable (maintenance, seasonal content)
• You are doing geolocation-based routing that might change
• You want to preserve the original URL in search results

HTTP/1.1 302 Found
Location: https://example.com/temporary-page

The most common mistake with 302 is using it when you mean 301. If the move is permanent, a 302 tells search engines to keep indexing the old URL, splitting your ranking signals between two pages. See What Is a 302 Redirect? for common scenarios.

303 See Other

A 303 tells the browser to fetch the new URL using a GET request, regardless of the original request method. This is typically used after a form submission to prevent the user from resubmitting the form if they hit the back button. [2]

Use 303 when:

• Redirecting after a POST form submission (the Post/Redirect/Get pattern)
• Redirecting to a "thank you" or confirmation page after a write operation

HTTP/1.1 303 See Other
Location: https://example.com/thank-you

303 is rarely relevant for SEO because it is almost exclusively used for application flow, not URL changes. If you are building a web application and need to redirect users after form submissions, 303 is the semantically correct choice.

307 Temporary Redirect

A 307 is like a 302, but with one critical difference: it guarantees the browser will not change the request method. If the original request was a POST, the browser will POST to the new URL too. [2]

Use 307 when:

• You need a temporary redirect that preserves the request method
• You are redirecting API requests where POST/PUT/DELETE must stay intact
• HSTS (HTTP Strict Transport Security) uses 307 internally to force HTTPS

HTTP/1.1 307 Temporary Redirect
Location: https://example.com/temporary-endpoint

The distinction between 302 and 307 matters most for APIs. For regular website pages where the request is always GET, the practical difference is negligible. For more on when 307 is the right choice, see 307 Temporary Redirect Explained.

308 Permanent Redirect

A 308 is the permanent equivalent of 307. It tells the browser that the URL has permanently moved and the request method must not change. [5]

Use 308 when:

• You need a permanent redirect that preserves POST/PUT/DELETE methods
• You are permanently redirecting API endpoints

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

In practice, most website redirects use 301. 308 is primarily useful for APIs and applications where method preservation matters. It was introduced in RFC 7538 specifically to fill the gap where 301 did not guarantee method preservation. [5] See 308 Permanent Redirect Explained for details.

How to choose the right status code

The decision tree is straightforward:

1. Is the move permanent or temporary?
   • Permanent → 301 or 308
   • Temporary → 302, 303, or 307
2. Does the request method need to be preserved?
   • Yes (APIs, POST requests) → 307 (temporary) or 308 (permanent)
   • No (standard page redirects) → 301 (permanent) or 302 (temporary)
3. Is this after a form submission?
   • Yes → 303

When in doubt, use 301 for permanent moves and 302 for temporary ones. You will be right the vast majority of the time.

Quick reference

| Code | Name | Permanent? | Preserves method? | SEO transfers signals? | |------|------|:---:|:---:|:---:| | 301 | Moved Permanently | Yes | No (may change to GET) | Yes | | 302 | Found | No | No (may change to GET) | No (keeps old URL) | | 303 | See Other | No | No (always GET) | N/A | | 307 | Temporary Redirect | No | Yes | No (keeps old URL) | | 308 | Permanent Redirect | Yes | Yes | Yes |

Related status codes

Several other HTTP status codes work alongside redirects. Understanding when to use them instead of (or in addition to) a redirect is important.

404 Not Found vs 410 Gone

When a page no longer exists and there is no replacement URL to redirect to, you have two options. A 404 tells search engines the page was not found but might come back. A 410 explicitly says the page is gone permanently and search engines should remove it from their index faster. [6]

If you have a replacement URL, use a 301 redirect. If there is no replacement, choose between 404 and 410 based on whether the content might return. See 410 Gone vs 404 Not Found for guidance on when to use each.

200 OK with canonical tag

A canonical tag (rel="canonical") tells search engines which version of a page is the "main" one, without actually redirecting the user. Use canonicals when both URLs need to remain accessible (like paginated content, tracking parameter variants, or print-friendly versions). Use redirects when the old URL should no longer be visited at all.

The key difference: a redirect physically sends users to the new URL. A canonical tag leaves both URLs accessible but tells search engines to consolidate ranking signals to the canonical version. For a detailed comparison, see Redirect vs Canonical Tag: Which to Use.

URL rewrites vs redirects

A URL rewrite happens entirely on the server. The server internally maps one URL to another without the browser knowing. The user sees the original URL in their address bar, and no 3xx response is sent.

Redirects change the URL in the browser's address bar. Rewrites do not. Use rewrites for clean URLs (e.g., mapping /products/shoes to index.php?category=shoes). Use redirects when the URL itself needs to change publicly. See Redirect vs URL Rewrite for more.

Server-side implementation methods

Server-side redirects are the preferred method because they happen at the HTTP level, before the browser renders anything. Search engines handle them correctly, and users experience minimal delay.

Apache (.htaccess)

Apache uses mod_rewrite or Redirect directives in .htaccess files. The .htaccess approach is popular because it does not require access to the main server configuration:

# Single page redirect
Redirect 301 /old-page https://example.com/new-page

# Pattern-based redirect with mod_rewrite
RewriteEngine On
RewriteRule ^old-section/(.*)$ /new-section/$1 [R=301,L]

# Force HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# Redirect www to non-www
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]

The [L] flag means "last rule." Without it, Apache continues processing additional rules, which can cause unexpected behavior. The [R=301] flag specifies the status code; omitting it defaults to 302.

For a complete reference including regex patterns, conditional redirects, and troubleshooting, see .htaccess Redirect Rules Guide.

Nginx

Nginx uses return or rewrite directives in the server configuration. Unlike Apache, Nginx does not use .htaccess files. All redirects are configured in the Nginx config (usually /etc/nginx/nginx.conf or a site-specific file in /etc/nginx/sites-available/):

# Single page redirect
location = /old-page {
    return 301 https://example.com/new-page;
}

# Pattern-based redirect
location /old-section/ {
    rewrite ^/old-section/(.*)$ /new-section/$1 permanent;
}

# Force HTTPS
server {
    listen 80;
    server_name example.com;
    return 301 https://$server_name$request_uri;
}

# Redirect www to non-www
server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

Nginx return is faster than rewrite because it does not require regex processing. Use return for simple redirects and rewrite when you need to capture and transform parts of the URL.

See Nginx Redirect Configuration Guide for advanced patterns including map-based redirects for large migrations.

IIS

Internet Information Services uses URL Rewrite rules, configured in web.config:

<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Redirect old page" stopProcessing="true">
          <match url="^old-page$" />
          <action type="Redirect" url="https://example.com/new-page"
                  redirectType="Permanent" />
        </rule>
        <rule name="Force HTTPS" stopProcessing="true">
          <match url="(.*)" />
          <conditions>
            <add input="{HTTPS}" pattern="off" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}/{R:1}"
                  redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

The stopProcessing="true" attribute is equivalent to Apache's [L] flag. See IIS URL Redirect Guide for details on conditions, pattern matching, and outbound rules.

CDN and hosting platforms

Major platforms handle redirects through their own interfaces rather than server configuration files:

• Cloudflare uses Page Rules (legacy) or Bulk Redirects (newer, supports thousands of rules at the edge). Cloudflare redirects happen before the request reaches your origin server, making them extremely fast. See Cloudflare Redirect Rules Guide.
• WordPress uses plugins like Redirection, Yoast SEO Premium, or Rank Math. These store rules in the database and execute them in PHP, which is slower than server-level redirects but easier to manage. See WordPress Redirect Guide.
• Shopify has a built-in URL redirect manager under Settings > Navigation. Shopify automatically creates redirects when you change a product or page URL. See Shopify Redirect Guide.
• Squarespace supports URL redirects in Settings > Advanced > URL Mappings. See Squarespace Redirect Guide.
• Vercel and Netlify use configuration files (vercel.json and _redirects respectively) to define redirect rules at the edge.

Framework-level redirects

Modern web frameworks handle redirects in application code:

• Next.js supports redirects in next.config.js and via middleware. See How to Redirect in Next.js.
• PHP uses header('Location: ...') before any output is sent. See PHP Redirect Guide.
• Flask (Python) uses redirect() from the Flask module. See Flask Redirect Guide.

For most sites, server-level redirects (Apache, Nginx) are preferred over framework-level redirects because they execute earlier in the request lifecycle and do not require your application to boot up.

Client-side redirect methods

Client-side redirects happen in the browser after the page has loaded. They are slower than server-side redirects and less reliable for SEO, but sometimes they are the only option available.

HTML meta refresh

The <meta> refresh tag tells the browser to navigate to a new URL after a specified delay:

<!-- Immediate redirect -->
<meta http-equiv="refresh" content="0;url=https://example.com/new-page">

<!-- Delayed redirect (5 seconds) -->
<meta http-equiv="refresh" content="5;url=https://example.com/new-page">

Setting the delay to 0 makes it as fast as possible, but search engines still treat meta refreshes as less authoritative than server-side 301 redirects. [7] Google can follow meta refresh redirects, but they introduce unnecessary uncertainty.

Use meta refresh only when you cannot configure server-side redirects, for example on a static HTML page hosted on a service that does not support server configuration.

JavaScript redirects

JavaScript can redirect using window.location:

// Replaces current entry in history (back button skips this page)
window.location.replace("https://example.com/new-page");

// Adds to history (back button returns to this page)
window.location.href = "https://example.com/new-page";

// Alternative assignment syntax
window.location.assign("https://example.com/new-page");

window.location.replace() is preferred because it does not create a history entry, so the user's back button works correctly. JavaScript redirects are the least reliable method because they require JavaScript to be enabled and executed. Search engines can usually follow them, but not always. [7]

Google's JavaScript rendering pipeline processes JS redirects, but there can be a delay. Googlebot's initial HTML crawl sees no redirect; only after rendering does it detect the JavaScript redirect. This means JS redirects may take longer to be recognized by search engines.

For more on client-side approaches, see Meta Refresh and JavaScript Redirects Explained.

Ranking the methods

From most to least preferred for SEO:

1. Server-side 301/308 — fastest, most reliable, universally supported
2. Server-side 302/307 — for genuinely temporary moves only
3. Meta refresh (0 delay) — acceptable fallback when server config is unavailable
4. JavaScript redirect — least reliable, use as last resort

Redirect chains and loops

A redirect chain happens when URL A redirects to URL B, which redirects to URL C (or further). Each hop adds latency and dilutes SEO value. Google follows up to 10 redirects in a chain, but recommends keeping chains as short as possible. [3]

How chains form

Redirect chains usually build up over time through accumulated changes:

1. In 2020, you moved /blog/post-1 to /articles/post-1 (301 redirect)
2. In 2023, you restructured to /content/articles/post-1 (another 301 redirect)
3. Now /blog/post-1 → /articles/post-1 → /content/articles/post-1 (two-hop chain)

The fix is to update the first redirect to point directly to the final destination: /blog/post-1 → /content/articles/post-1.

The cost of chains

Each redirect hop adds 50-300ms of latency depending on server response time and geographic distance. A three-hop chain can add nearly a second to page load time. For users on mobile networks, this is significant.

For SEO, Google has said that 301 chains pass full ranking signals, [8] but longer chains increase the chance of Googlebot giving up or encountering errors along the way. There is no reason to keep unnecessary hops.

Redirect loops

A redirect loop happens when URL A redirects to URL B, which redirects back to URL A. The browser detects the loop and shows an ERR_TOO_MANY_REDIRECTS error. Common causes include:

• Conflicting redirect rules (one rule sends HTTP to HTTPS, another sends HTTPS back to HTTP)
• CDN or proxy misconfiguration (Cloudflare's SSL mode set to "Flexible" when the origin also forces HTTPS)
• CMS plugin conflicts (two plugins trying to manage the same redirect)
• Load balancer terminating SSL and the app behind it forcing HTTPS

For diagnosis and fixes, see How to Find Redirect Chains, What Is a Redirect Loop?, and How to Fix ERR_TOO_MANY_REDIRECTS.

Redirects and SEO

Redirects have a direct impact on search rankings. Here is what Google has confirmed about how they handle them. [3] [8]

Ranking signal transfer

301 and 308 redirects pass full ranking signals (historically called "PageRank") to the destination URL. Google has confirmed that no ranking signal is lost through a 301 redirect. [8] This was not always the case: before 2016, Google applied a small dampening factor to redirected signals, but this is no longer true.

302 and 307 redirects do not transfer ranking signals by default because they signal a temporary move. If Google detects that a 302 has been in place for a long time, it may eventually treat it as a 301, but relying on this is risky. If the move is permanent, use a 301.

Crawl budget

Every redirect consumes a crawl request. If your site has thousands of redirect chains, Googlebot spends its crawl budget following redirects instead of indexing your actual content. [9] This is particularly important for large sites with hundreds of thousands of pages. For smaller sites (under 10,000 pages), crawl budget is rarely a concern.

Keep redirects to a single hop where possible. Run periodic audits to find and collapse chains. For sites managing many redirects, see Redirect Management Strategy.

Indexing timeline

When Google encounters a 301, it removes the old URL from its index and replaces it with the new one. This process is not instant. It can take days to weeks depending on how frequently Google crawls your site. During this period, both URLs may appear in search results.

You can speed up the process by:

• Submitting the new XML sitemap with the updated URLs
• Using Google Search Console's URL Inspection tool to request re-crawling
• Ensuring the old URL is not still referenced in your internal links

Redirect SEO myths

Myth: "301 redirects lose 15% of PageRank." This was true before 2016 but Google changed it. 301 redirects now pass full signals. [8]

Myth: "You can remove 301 redirects after a year." Google recommends keeping redirects in place indefinitely. [10] External backlinks pointing to the old URL will continue arriving for years. Removing the redirect means losing that link equity.

Myth: "302 redirects hurt SEO." A 302 does not hurt your rankings. It simply tells Google to keep the old URL indexed. This is the correct behavior for temporary moves. The problem arises only when you use 302 for what should be a permanent move.

For a detailed look at SEO implications, see How Redirects Affect SEO Rankings and Do 301 Redirects Hurt SEO?.

HTTPS migration redirects

One of the most common uses of redirects is forcing all HTTP traffic to HTTPS after installing an SSL certificate. This is a permanent change, so use 301 redirects.

The requirements

1. Every HTTP URL must redirect to its HTTPS equivalent. Not just the homepage. http://example.com/page must redirect to https://example.com/page, preserving the path and query string.
2. Avoid double redirects. If you are also redirecting www to non-www (or vice versa), combine both into a single redirect. Do not redirect http://www.example.com → http://example.com → https://example.com. Go directly to https://example.com.
3. Update internal links. After setting up HTTPS redirects, update all internal links in your site to use https:// directly. This avoids unnecessary redirect hops on every page load.
4. Update external references. Submit the HTTPS version of your sitemap to Google Search Console. Update your canonical tags. Update any links in social profiles and directory listings that you control.

HSTS (HTTP Strict Transport Security)

After you have confirmed that HTTPS works correctly on your site, implement HSTS by adding this response header:

Strict-Transport-Security: max-age=31536000; includeSubDomains

HSTS tells browsers to always use HTTPS for your domain, even if the user types http://. On the first visit, the browser follows your 301 redirect to HTTPS. On subsequent visits, the browser upgrades to HTTPS automatically before making any request, using an internal 307 redirect. This eliminates the round-trip to your server for the HTTP-to-HTTPS redirect.

For a step-by-step implementation guide covering Apache, Nginx, IIS, and Cloudflare, see HTTP to HTTPS Redirects: The Complete Guide.

Site migration redirects

Site migrations are the highest-stakes redirect scenario. Whether you are changing domains, restructuring URLs, or merging sites, the redirect mapping determines whether you keep your search traffic or start over.

Planning the redirect map

1. Crawl the old site to get a complete list of indexed URLs. Use your sitemap, Google Search Console, or a crawler like Screaming Frog.
2. Map every old URL to its new equivalent. One-to-one mapping is ideal. If pages are being merged or removed, map them to the closest relevant page on the new site.
3. Handle pages with no equivalent. If a page is being removed with no replacement, return a 410 (Gone) rather than redirecting to the homepage. Mass-redirecting unrelated pages to the homepage is a soft 404 in Google's eyes. [3]
4. Prioritize by traffic and backlinks. Start with the pages that receive the most organic traffic and the most external backlinks. These are the redirects where mistakes cost the most.

Execution

• Use 301 redirects for all permanent URL changes
• Keep old redirects in place for at least one year. Google recommends keeping them indefinitely. [10]
• Monitor for 404 errors in Google Search Console after migration
• Update your XML sitemap to reflect the new URL structure
• Update your robots.txt to ensure the new URLs are crawlable
• Verify your hreflang tags still point to the correct URLs if you have a multilingual site

Post-migration monitoring

After the migration:

• Check Google Search Console daily for the first two weeks. Watch the Coverage report for spikes in 404 errors.
• Monitor organic traffic in your analytics. Expect a temporary dip (typically 10-20%) that should recover within 4-8 weeks. [11]
• Test a sample of high-traffic old URLs to confirm they redirect correctly.
• Check that external backlinks are being followed correctly by spot-checking in a redirect tracer.

For the complete migration checklist, see Site Migration Redirect Checklist. For cautionary tales, see Famous Redirect Failures and SEO Disasters.

Testing and monitoring redirects

Setting up a redirect is step one. Verifying it works correctly and monitoring it over time is step two.

Manual testing methods

• Browser DevTools: Open the Network tab, navigate to the old URL, and check the status code and Location header. You will see each hop in the chain as a separate network request. See How to Check Redirects in Your Browser.
• cURL: Run curl -I -L https://example.com/old-page to follow the entire redirect chain from the command line. The -I flag shows only headers, and -L follows redirects. See How to Trace Redirects with cURL.

$ curl -I -L https://example.com/old-page
HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page

HTTP/1.1 200 OK
Content-Type: text/html

Automated and bulk testing

• Bulk checking: For large migrations with hundreds or thousands of URL mappings, manual testing is impractical. Use tools that can validate entire spreadsheets of redirect mappings at once. See How to Check Redirects in Bulk.
• Redirect Tracer: Paste any URL to instantly visualize the full redirect chain, status codes, and response headers. Useful for detecting chains, loops, and mixed-protocol redirects.
• Google Search Console: The URL Inspection tool shows how Google handles redirects on your site. The Coverage report flags redirect errors, soft 404s, and redirect loops.

Ongoing monitoring

Redirects can break over time. Server configuration changes, CMS updates, CDN rule changes, and certificate renewals can silently alter redirect behavior. A redirect that worked yesterday might loop today because someone changed the Cloudflare SSL mode.

For why one-time checks are not enough, see Why One-Time Redirect Checks Aren't Enough and Redirect Monitoring Explained.

Common redirect mistakes

Using 302 when you mean 301. This is the most common mistake. If the URL change is permanent, use 301. A 302 tells search engines to keep the old URL, which splits your ranking signals. See 301 vs 302 Redirects for a detailed comparison.

Redirect chains. Every unnecessary hop adds latency and risk. Audit regularly and collapse chains to single hops. When you add a new redirect, check whether the destination is itself a redirect. See Redirect Chains Explained.

Redirecting everything to the homepage. When pages are removed, some site owners redirect them all to the homepage. Google treats this as a soft 404, meaning the redirect effectively does nothing for SEO. [3] Redirect to the most relevant replacement page, or return a 410 if no replacement exists.

Not redirecting all URL variants. Remember to redirect both http:// and https://, both www and non-www, both with and without trailing slashes. Missing any variant means some users and crawlers hit a dead end.

Forgetting query strings. If your old URLs included query parameters (?id=123), make sure your redirect rules handle them. Some server configurations strip query strings by default. Test with real URLs including their full query strings.

Not updating internal links. After setting up redirects, update all internal links on your site to point directly to the new URLs. This eliminates unnecessary redirect hops on every page load and reduces server load. Internal links should never point to URLs that redirect.

Removing redirects too early. External backlinks to your old URLs will keep arriving for years. Google recommends keeping redirects in place indefinitely. [10] Storage is cheap. The cost of a missing redirect is lost traffic and link equity.

Not testing after deployment. Always test redirects after deploying them. A typo in a regex pattern or a missing trailing slash can turn a redirect into a 404 or a loop. Test the actual URLs, not just the rules.

---

References

1. IETF, "RFC 9110 - HTTP Semantics, Section 15.4: Redirection 3xx," June 2022. https://httpwg.org/specs/rfc9110.html#status.3xx
2. IETF, "RFC 9110 - HTTP Semantics, Section 15.4: Status Code Definitions," June 2022. https://httpwg.org/specs/rfc9110.html#rfc.section.15.4
3. Google, "Redirects and Google Search," Google Search Central, 2024. https://developers.google.com/search/docs/crawling-indexing/301-redirects
4. Google, "HTTP status codes and how Googlebot handles them," Google Search Central, 2024. https://developers.google.com/search/docs/crawling-indexing/http-network-errors
5. IETF, "RFC 7538 - The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)," April 2015. https://datatracker.ietf.org/doc/html/rfc7538
6. Google, "Remove a page or site from Google's search results," Google Search Central, 2024. https://developers.google.com/search/docs/crawling-indexing/remove-information
7. Google, "JavaScript SEO basics," Google Search Central, 2024. https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics
8. Gary Illyes, Google, "30x redirects don't lose PageRank anymore," Twitter/X, July 2016.
9. Google, "Large site owner's guide to managing your crawl budget," Google Search Central, 2024. https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget
10. Google, "Change page URLs with 301 redirects," Google Search Central, 2024. https://developers.google.com/search/docs/crawling-indexing/301-redirects
11. Google, "Site moves overview," Google Search Central, 2024. https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes