Ultimate Guide to Redirects and Broken Links (2026)

Redirects are where a site silently loses rankings. A migration, a URL cleanup, a platform switch, or a batch of deleted products throws thousands of 301s and 404s onto a domain, and every mistake in that stack costs either link equity, crawl budget, or both. This guide covers the four redirect status codes you actually need, when each belongs in your server config, how to collapse redirect chains, and a repeatable broken-link cleanup workflow for internal and external links. It corrects the outdated idea that 301 redirects leak PageRank, adds the 307 and 308 codes most guides skip, and closes with a 2026 view of how GPTBot, ClaudeBot, and PerplexityBot move through redirect chains. Every section is built to be checked rather than asserted: run a URL through the free redirect checker as you read and compare what the headers show against what the text claims.

HTTP Redirect Status Codes Decoded: 301, 302, 307, and 308 (and What Each Tells Google)

Every redirect is a server answering a request with a 3xx status code and a Location header that names the next URL. The client, whether that is Googlebot or a browser, then requests that URL instead. Which 3xx code you send is a signal. It tells Google whether the move is permanent or temporary, and it tells every client whether the request body can be rewritten. Get the code wrong and you either ask Google to index the wrong URL or you hand a POST request to a GET handler.

The four codes in one table

The permanent codes are 301 and 308, and the temporary codes are 302 and 307 (RFC 9110, 2022). The method and body distinction is the part most SEO articles leave out. RFC 9110 specifies that 307 and 308 preserve the request method and body, while 301 and 302 have historically allowed clients to rewrite a POST into a GET (RFC 9110, 2022). For a form submission that matters: a 301 on a checkout endpoint can silently convert the customer's POST into a GET and drop the payload on the floor.

A live header check for each

The fastest way to see what a redirect actually does is to ask for the headers yourself. Run this from a terminal, then compare it to the free redirect checker, which follows the whole chain and times each hop for you.

$ curl -I https://www.example.com/old-page
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page
Content-Type: text/html

A 302 returns the same shape with a different code and phrase:

$ curl -I https://www.example.com/spring
HTTP/1.1 302 Found
Location: https://www.example.com/spring-sale

Note that only the status code and reason phrase change. The status code is the signal; the phrase is cosmetic. If you want the full set of headers a page serves, not just the redirect line, run the URL through the HTTP header checker.

What Google actually reads

Googlebot follows redirects, and Google differentiates between permanent (301 and 308) and temporary (302 and 307) redirects when it decides which URL to index (Google Search Central, 2025). For a permanent move, Google recommends a 301 so the page's signals transfer to the target URL (Google Search Central, 2025). The practical rule is one question: should the old URL ever come back? If no, send 301 or 308. If yes, send 302 or 307 and put the real return date on your calendar, because Google will not wait forever.

Two small details catch people on the first deploy. The Location header should carry an absolute URL, because a relative path leaves the target up to the client's interpretation, and some clients resolve it wrong. And if a page is deleted with no replacement at all, prefer a 404 or a 410 over a 301 to a barely-related page; a 301 that lands on an irrelevant page is how a clean move becomes a soft-404 complaint. Check both in a single pass with the HTTP header checker and the redirect checker.

301 vs. 302 Redirects for SEO: Decision Table and When to Use Each

Choose the code with one test: will this URL need to rank and be indexed again in its old location? If the answer is no, it is a 301. If yes, it is a 302. Everything else is a detail of that single question.

Use a 301 when the move is permanent

• A migrated URL that now lives somewhere else.
• A page deleted or merged into another page.
• HTTP to HTTPS, or www to non-www, or vice versa.
• Trailing-slash and case canonicalization.
• A retired product or category pointed at its closest replacement.

Use a 302 when the old URL must come back

• A sale or seasonal campaign that ends on a known date.
• A maintenance or temporary stock outage page.
• An A/B or usability test variant.
• A login-gated or location-based temporary handoff.

The lazy choice is the expensive one. SISTRIX warns that using a 302 where a 301 is intended can confuse Google, since Google may eventually treat the 302 as permanent anyway (SISTRIX, 2020). You trade a clear, immediate signal for an ambiguous one, then hope Google guesses the direction you already knew.

For a large move, do not hand-write a thousand rules. Export the old-to-new mapping from your CMS or a crawl, generate the directives in bulk, and spot-check a sample by hand. Every platform has a preferred syntax for this, and the risk is never the syntax; it is a mapping that points a real page at a dead end because the destination slug changed after the export. Validate the sample with the redirect checker before you trust the rest.

Do 301 Redirects Lose PageRank? What Google Actually Said (2016 and After)

The claim that a 301 leaks 10 to 15 percent of PageRank is still the most repeated SEO error about redirects. It is wrong, and it has been wrong since 2016. The correction is on the record, twice.

The myth and why it survives

The dilution figure predates Google's current behavior and survived on the strength of being easy to repeat. It still appears in fresh 301-versus-302 posts, and it misleads founders and marketers into treating a migration as a tax instead of a transfer. The number was never a stable, current Google statement; it is folklore that outlived its source.

What Gary Illyes said in 2016

In 2016 Gary Illyes of Google said 30x redirects no longer lose PageRank, so all 3xx redirects now pass full PageRank (Search Engine Roundtable, 2016).

"30x redirects don't lose PageRank anymore." Gary Illyes, Google, via Search Engine Roundtable (2016)

What John Mueller clarified in 2022

In 2022 John Mueller debunked the myth that Googlebot mishandles specific redirect types, confirming Google handles all standard redirects (Search Engine Journal, 2022). The engine does not fumble a 307 or misread a 302 the way some tooling blogs imply.

One nuance keeps this honest. Full transfer does not mean a redirect is free of consequences. If the new page is a poor match for the old query, rankings still drop because relevance, not PageRank, decides the result. And a long redirect chain still wastes crawls and adds latency. What changed in 2016 is only the equity question: the link equity survives the 301, and the myth should be retired.

You can verify the transfer rather than trust it. After a 301 consolidates, the old URL drops out of Search Console indexing and the new URL picks up the queries and positions the old one held. If the new URL flatlines while the old URL still shows impressions, the redirect is not being followed as permanent, and the usual cause is a leftover 302 earlier in the chain or a canonical that still points back at the old URL. The redirect checker exposes both in one trace.

When a 302 Becomes a 301: How Google Treats Long-Lived Temporary Redirects

A 302 is a promise that the old URL will return. If you break that promise long enough, Google stops believing it.

The 2016 change

Google announced in 2016 that a 302 redirect left in place for an extended period can be treated like a 301 by Google Search (The Drum, 2016). There is no published clock and no fixed number of days; the outcome depends on how consistently the redirect persists and how the page's other signals look.

What this means for your config

The danger is asymmetry. You call the move temporary, so you do not update your internal links, your sitemap, or your canonical. Google, meanwhile, has quietly promoted the temporary redirect to permanent and now treats the new URL as the real one, while your own pages still link to the dead old URL. You end up paying for a redirect you did not plan, with a canonical and a sitemap that disagree with the index.

The fix is boring and correct. When a move turns out to be permanent, change the 302 to a 301 and update every internal reference in the same pass, pointing your links at the final URL instead of the hop. The redirect checker shows the current code on each hop, so a 302 that has become a de facto 301 is visible in a single run.

HTTP Redirects vs. Meta Refresh and JavaScript Redirects: Which Does Google Follow?

Not all redirects are created by the server. A meta refresh in the HTML head and a JavaScript location change also move a visitor, but Google treats them differently and with less trust.

Meta refresh

A meta refresh is a line in the HTML head such as <meta http-equiv="refresh" content="0; url=https://www.example.com/new">. Google Search Central recommends HTTP redirects over meta refresh, treating an instant 0-second meta refresh as a redirect while a delayed meta refresh may not be followed at all (Google Search Central, 2025). A 5-second meta refresh is a page that stalls, not a redirect, and Google is right to distrust it.

JavaScript redirects

A JavaScript redirect changes window.location after the page renders. Google can render and follow it, but it is slower, it depends on Google executing the script, and it gives the crawler an extra page to process on the way to your content. For an SEO move it is strictly worse than a server-side 301. Keep JavaScript redirects for client-side app routing inside a single page experience, not for moving URLs between pages.

For anything that should rank, the order is clear: server-side 301 or 308 first, a 0-second meta refresh as a distant fallback, and a JavaScript redirect last, only when the server is genuinely out of your control.

Broken Links vs. Soft 404s: Two Different Problems That Both Burn Crawl Budget

A broken link and a soft 404 look different in a report but cost you the same thing: crawls spent on pages that produce nothing. One returns an error, the other pretends to be fine.

The difference

A broken link points at a URL that returns a 4xx or 5xx status, most often a 404 Not Found. The destination is gone and the server says so. A soft 404 returns HTTP 200 but the page has no real content: an empty search results page, a filtered list with zero rows, or a deleted product page that now renders an empty template. The server claims success while serving nothing.

Google confirmed that soft 404s still consume crawl budget despite the 200 status code (Search Engine Journal, 2025). The 200 is exactly why they are dangerous: nothing flags them as errors in a basic link checker, so they accumulate quietly.

Where crawl budget enters

Google describes crawl budget as the combination of crawl rate limit and crawl demand, and says wasted crawling, including on redirects and soft 404s, should be minimized (Google Search Central, 2024). On a small site this rarely matters. On a site with tens of thousands of URLs, a stack of soft 404s and redirect chains quietly reserves crawl for pages that will never rank, while your real pages wait in line.

Spotting a soft 404 in the wild

A soft 404 rarely announces itself. The pattern is a URL that returns 200, has a thin or empty body, and shows up in Search Console under Soft 404 in Page Indexing. Google is the authoritative detector here, so that report is the fastest place to find them, and your own crawl only confirms the page is technically alive. Cross-reference the report against the broken link checker: a page that the checker reports as fine but Google lists as a soft 404 is the classic case.

Broken Link Audit Walkthrough: Screaming Frog From Crawl to Export

Screaming Frog SEO Spider is the standard tool for finding broken links because it crawls the way a bot does and reports the response code of every URL it touches. Here is the walkthrough from setup to a fixable export.

Crawl setup

1. Open SEO Spider and enter your root URL in the bar.
2. Under Configuration, Spider, confirm that Crawl Internal Links is on and scope the crawl to your domain so it does not wander off-site.
3. Under Configuration, API Access, connect Google Analytics or Search Console if you want the crawl weighted by traffic, but the 4xx report works without it.
4. Run the crawl and let it finish before exporting.

Reading the Internal Client Error (4XX) report

Screaming Frog reports Internal Client Error (4XX) response codes in crawls to surface broken internal links and blocked resources (Screaming Frog, 2025). Go to Response Codes, then Client Error (4XX). The list is every URL on your site that returned a 404, 410, or another 4xx.

An annotated slice of the export looks like this:

Address,Status Code,Status,Indexability,Inlinks
https://www.example.com/blog/old-guide,404,Not Found,Non-Indexable,14
https://www.example.com/products/discontinued,404,Not Found,Non-Indexable,31
https://www.example.com/category/renamed,404,Not Found,Non-Indexable,8

The two numbers that matter

The Status Code tells you the problem; the Inlinks column tells you how urgent it is. A 404 with 31 internal links is a broken doorway that 31 of your own pages are pushing visitors and crawlers through. Fix the highest-inlink URLs first. Export to CSV from the Export button, then sort by Inlinks descending.

The same dead URLs will show up in the free broken link checker when you scan the pages that link to them, which is the quick way to verify a fix after you make it.

After the first pass you have a working list, not a finished one. A 404 audit is only done when you re-crawl and the same URLs come back clean. Some 404s are expected, like a discontinued product you chose to let die, and those should return 404 or 410 deliberately rather than be force-redirected into irrelevance. The export's value is the ordering it gives you: by inlinks, then by traffic, then by backlinks, in that order.

Internal Link Audit: Finding Pages That Point at 4xx and 5xx URLs

A broken link has two ends: the dead URL and the page that still links to it. Fixing the dead URL is only half the job. The source page keeps sending signals into the void until its href changes.

Source pages, not just targets

Ahrefs Site Audit flags Page has links to broken page when internal pages link to URLs returning 4xx or 5xx status codes (Ahrefs, 2024). That report flips the view: it lists the healthy page that is carrying the broken reference. In Screaming Frog the equivalent is the Inlinks tab on any 4xx URL, which shows every internal page linking to it.

The audit order

• Export the broken URLs with their inlink counts.
• Sort by inlinks so the busiest dead ends come first.
• Open each source page and find the anchor text of the broken link. The anchor tells you what the link was supposed to mean.
• Decide the fix per link: update the href to the live URL, point it at the redirected destination, or remove the link.

Working from the source page matters because a bare list of 404s hides intent. A broken link whose anchor is pricing should go to the pricing page, not be deleted because its target 404'd. Run the source page through the broken link checker after you edit to confirm the reference is clean.

Redirect Chain Audit: Spotting and Collapsing Multi-Hop Redirects

A redirect chain is a URL that bounces through one or more intermediate URLs before reaching its destination. The visitor asks for A, and A sends them to B, B to C, and C finally lands on D. Each hop is a full round trip that no one needed.

How the tools flag it

Ahrefs Site Audit flags a Redirect chain error when a URL bounces through one or more intermediate URLs before reaching its destination (Ahrefs, 2024). In Screaming Frog the Redirect Chains report under Response Codes lists the same thing hop by hop.

Collapse the chain

The rule is one hop to the final URL. Google Search Central advises avoiding redirect chains because each hop adds latency, and recommends pointing internal links directly at the final URL (Google Search Central, 2025). Two fixes happen together: rewrite the server rule so the old URL redirects straight to the final destination, and update your internal links so nothing points at the old URL or the intermediate one anymore.

Before and after on a four-hop chain: the visitor asked for A, waited through A to B, B to C, and C to D. On a mobile connection where each round trip can take a few hundred milliseconds, that is several hundred milliseconds of dead time before the final page even starts to download. Collapse it to A to D and the same visitor is loading the page on the first hop. The redirect checker shows each hop and its time, so you can see the collapse as a before-and-after number rather than a guess.

How to Fix Broken Links: Update, Redirect, or Remove — a Decision Framework

Every broken link resolves to one of three actions: update the link, redirect the URL, or remove the link. The choice depends on where the value lives.

Update the link

When the content still exists at a new URL and the link is on your own site, update the href to the final URL. This is the highest-quality fix because it removes the redirect entirely. No hop, no latency, no ambiguity.

Redirect the URL

When the old URL carries value you want to keep, meaning it has backlinks, rankings, or bookmarks, put a 301 on the old URL pointing at the closest matching live page. This is the fix for external links you do not control: you cannot edit someone else's href, but you can catch their traffic and their equity with a 301.

Remove the link

When the content is gone and there is no close replacement, remove the link and let the old URL return 404 or 410. A 410 Gone is the honest version of a 404: it says the page is gone and will not return, which lets Google drop it from the index faster than a 404 that might just be a mistake.

• Content exists at a new URL and the link is internal: update the href.
• Content exists at a new URL and the link is external: 301 the old URL.
• Content is gone but a close replacement exists: 301 to the closest match.
• Content is gone and nothing matches: remove the link and return 404 or 410.

Order the work by inlink count, not by alphabetical URL. A 404 with 30 internal links is worth ten 404s with one link each. The broken link checker and the redirect checker together close the loop: the first finds the dead ends, and the second confirms the 301 you put up lands on a live 200.

Google Search Console Redirect Reports and Crawl Stats: What to Check

Search Console tells you how Google, rather than your own crawler, sees your redirects and your 404s. Two places matter: the Page Indexing report and Crawl Stats.

Page Indexing report

Under Pages, open Page Indexing. Look for Page with redirect and Not found (404). Page with redirect means Google saw the redirect and chose not to index the source URL, which is correct for a 301. The problem is when a page you intended to index sits in that bucket because you sent a 302 by mistake, or when a redirect chain ends somewhere you did not expect.

The fix workflow for a redirect problem in Page Indexing:

1. Click the Page with redirect reason and open a URL.
2. Use Inspect URL to see the chain Google followed and the final URL.
3. If the final URL is wrong, fix the server rule and re-request indexing.
4. If the source URL should be indexed, replace the redirect with a canonical or with the actual content.

Crawl Stats

Under Settings, Crawl Stats shows the response codes Google got while crawling your site. A rising share of 301 and 404 responses means Google is spending its crawl on hops and dead ends instead of pages. Cross-check what you see there against your own crawl and against the HTTP header checker output. The goal is a crawl graph where Google mostly fetches 200 pages directly, with redirects as a small, planned minority.

There is one number worth pulling out of Crawl Stats directly: the share of total responses that are 3xx and 4xx. A healthy site spends almost all of its crawl on 200s. If redirects and not-founds are climbing month over month while your page count is flat, something in the site is generating URLs you never planned for, usually pagination, faceted filters, or case and slash variants. Fix the generator, not the symptoms.

Redirects vs. rel=canonical vs. hreflang: Picking the Right Signal

Three signals solve three different problems, and using one where another belongs is the most common consolidation mistake. A redirect moves the visitor. A canonical names the preferred version without moving anyone. Hreflang selects a language or region variant. They are not interchangeable.

Canonical tags consolidate signals without a redirect, which is why they are right for parameters and near-duplicate URLs you want to keep serving. But a canonical on a page that also 301s is wasted: the redirect already told Google the URL is gone. Pick one. Hreflang, in turn, never moves equity; it only routes users to the right language version, and it must be reciprocal or Google ignores the pair.

If you are unsure which consolidation is live on a page, the HTTP header checker shows the redirect, and the raw HTML shows the canonical and hreflang tags. For a site with many variants, the sitemap checker confirms which URLs you declared as the canonical set. The technical SEO guide covers canonicalization in more depth.

Copy-Paste Redirect Rules: .htaccess, nginx, and Cloudflare

Here are working rule sets for the three most common stacks. Change the example domains and paths to your own, then test one URL before deploying.

.htaccess (Apache)

Apache reads mod_rewrite and mod_alias directives from .htaccess. The Redirect directive is the simplest form for one-to-one moves.

# One-to-one redirects (mod_alias, no rewrite needed)
Redirect 301 /old-blog/post-slug https://www.example.com/blog/post-slug
Redirect 301 /blog/old-slug https://www.example.com/blog/post-slug
Redirect 302 /sale https://www.example.com/spring-sale
Redirect 307 /api/legacy-submit https://www.example.com/api/submit

# Collapse the chain: send the oldest URL straight to the final URL
Redirect 301 /blog/2019/old-title https://www.example.com/blog/post-slug

# Force HTTPS and non-www in a single hop instead of three
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

The chain-collapse line is the important one: it maps a URL that previously bounced through two intermediate slugs straight to the final destination.

nginx

nginx uses rewrite and return inside server blocks. The migration example in the next section uses these exact rules.

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

server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;

    # Permanent one-to-one redirects
    rewrite ^/old-blog/post-slug$ /blog/post-slug permanent;
    rewrite ^/products/old$ /products/new permanent;

    # Temporary redirects
    rewrite ^/sale$ /spring-sale redirect;

    location / {
        try_files $uri $uri/ =404;
    }
}

Cloudflare

Cloudflare does redirects before the request reaches your origin, which is why it is the fastest place to put them. Bulk Redirects handle a long list, and Page Rules handle protocol and host canonicalization.

# Cloudflare Bulk Redirects list (CSV): source, target, status
"example.com/old-blog/post-slug","https://www.example.com/blog/post-slug","301"
"example.com/blog/old-slug","https://www.example.com/blog/post-slug","301"
"example.com/products/old","https://www.example.com/products/new","301"
"example.com/sale","https://www.example.com/spring-sale","302"

After you deploy any of these, verify with the redirect checker that each URL lands on a 200 in one hop, and re-run the HTTP header checker to confirm the status code is the one you intended.

Full Site Migration With URL Changes: A Page-by-Page 301 Plan

When a site moves domains or changes its URL structure, Google recommends page-by-page 301 redirects from old to new URLs, plus updating internal links and sitemaps (Google Search Central, 2024). The plan is not redirect the homepage and hope. It is a mapping of every old URL to a new one.

Build the mapping first

Crawl the old site and export every URL. For each one, decide the new URL. Where content moved one-to-one, map directly. Where content was merged, map to the merged page. Where content was deleted with no replacement, map to a relevant category, and only if the page had value; otherwise let it 404.

Ship it in the right order

1. Deploy the 301 map on the old domain or old paths.
2. Update every internal link on the new site to point at the new URLs, so nothing points at a redirect.
3. Generate a new sitemap listing only the new URLs and submit it in Search Console. The sitemap checker validates it before you submit.
4. Use the Change of Address tool if the domain itself changed.
5. Watch Page Indexing for a few weeks and re-crawl with Screaming Frog to catch stragglers.

Do not bulk-redirect every old URL to the homepage. A destination that does not answer the query the old page served is how a move turns into a pile of soft 404s. A direct match beats a category fallback beats a homepage catch-all beats a dead 404, in that order.

Redirect Latency, Redirect Chains, and Core Web Vitals

A redirect is a request that produces another request. Every hop delays the moment the final page starts loading, and that delay lands in your Core Web Vitals.

The arithmetic of a hop

Each hop is a round trip plus the server's redirect response. A single 301 on a fast desktop connection might resolve in well under a second; on a mobile network a round trip can take several hundred milliseconds. The delay is the number of hops times the round trip, which is why a chain, not a lone redirect, is what hurts. The fix is structural: collapse chains to one hop and link to final URLs so most traffic never redirects at all.

Core Web Vitals

Largest Contentful Paint (LCP) measures when the largest element paints. A redirect chain delays LCP by delaying the entire page download, because no content can paint while the client is still chasing redirects. Google has folded redirect time into the page-load story, which is why redirect chains show up as a performance issue in Lighthouse and in Google's own guidance to avoid chains (Google Search Central, 2025).

Worked before-and-after: a URL at /old-blog/post ran through http to https to www to trailing slash, four hops, before landing. On a throttled mobile profile each hop added roughly a quarter of a second, so the final page started loading about three quarters of a second late and LCP sat in the poor band. After collapsing the chain to a single 301 straight to the canonical URL, the same page started loading on the first hop and LCP dropped back into the good band. The redirect checker prints the per-hop times, so you can measure the same number on your own chain.

The same logic applies to the other Core Web Vitals. Redirect time sits in front of first paint and LCP, but a slow chain also pushes the browser's request waterfall later, which can inflate Time to First Byte on the final document and delay when interactivity becomes available. Google's guidance is consistent across the board: keep redirects to a minimum, and when you need one, make it a single hop to the final URL. Latency is the one redirect cost you can measure directly, and it compounds exactly as the number of hops grows.

AI Crawlers and Redirects in 2026: GPTBot, ClaudeBot, and PerplexityBot

Google is no longer the only crawler that reads your redirects. GPTBot, ClaudeBot, and PerplexityBot fetch pages to train models and to answer questions with citations, and they follow redirects the same way any HTTP client does. A clean redirect stack now decides not just rankings but whether an assistant lands on your content at all.

Who they are

GPTBot is OpenAI's crawler, ClaudeBot is Anthropic's, and PerplexityBot is Perplexity's. Each identifies itself with a user-agent token you can allow or block in robots.txt. OpenAI documents GPTBot and its related bots in its bot documentation, Anthropic explains ClaudeBot in its crawler help center, and Perplexity lists PerplexityBot in its crawler reference.

robots.txt still gates the door. If you block GPTBot or ClaudeBot, redirects are irrelevant because the crawler never fetches the first URL. The robots.txt guide covers which bots to allow and which to block. On the redirect side, the same rule that serves Google serves the AI crawlers: one hop, final URL, stable content.

The practical takeaway for 2026 is that redirect hygiene has a second audience. A broken or chained redirect that Google tolerates may still cost you an AI citation, because an assistant that times out on your chain simply quotes someone else. Treat the crawl budget of GPTBot, ClaudeBot, and PerplexityBot the same way you treat Google's: give each bot a one-hop path to a stable canonical page, and confirm the result with the redirect checker.

Redirect and Broken-Link Troubleshooting Checklist: 25 Pre-Launch Checks

Run through this list before you launch a migration, a URL restructure, or any batch of redirects.

1. Every old URL in the migration map has a matching 301 rule.
2. Every 301 points to a live 200 URL, not another redirect.
3. No redirect chain is longer than one hop.
4. HTTP and HTTPS resolve to a single canonical host.
5. www and non-www resolve to the same host with one 301.
6. Trailing slash is canonicalized one way and stays consistent.
7. Internal links point at final URLs, not at redirects.
8. The sitemap lists only canonical 200 URLs.
9. No redirect or noindex URL is left in the sitemap.
10. Canonical tags agree with the redirect target.
11. Hreflang pairs are reciprocal.
12. Deleted pages return 404 or 410, not 200 empty shells.
13. Soft 404 pages are given content, noindexed, or turned into real 404s.
14. Form and API endpoints use 307 or 308 for POST moves, never 302.
15. Temporary 302s have a real end date and a plan to flip or revert them.
16. No internal page links to a 4xx or 5xx URL.
17. External links that 404 are replaced, redirected, or unlinked.
18. Redirect rules are tested with curl -I before launch.
19. The redirect checker shows one hop and a 200 final target for every mapped URL.
20. The HTTP header checker shows the intended status code, not a cached one.
21. Analytics and Search Console still fire on the final URL.
22. Old URLs are verified live after DNS propagation.
23. The new sitemap is submitted in Search Console.
24. Change of Address is filed if the domain changed.
25. Crawl Stats is watched for a rising 301 or 404 share after launch.