Redirects & Site Migrations: 301, 302, 308 & Blogger Redirects

Redirects are the bridge between an old URL and its new destination.

Used correctly, they preserve user access, consolidate signals, reduce broken links and help search engines understand a site move.

Used badly, they can create:

• Redirect chains.
• Redirect loops.
• Soft 404s.
• Incorrect canonical signals.
• Broken internal links.
• Temporary ranking volatility that lasts longer than necessary.

Last verified: September 27, 2026. Google and Blogger migration/settings documentation can change, so recheck platform-specific steps before a production move.

---

---

1. 301 vs 302 vs 308

Google currently recommends server-side permanent redirects such as 301 or 308 when a URL move is permanent. For a genuinely temporary move, Google's redirect documentation lists 302, 303 and 307 as temporary server-side options.

---

2. Permanent vs Temporary Redirects

Use a permanent redirect when:

• An old article URL has been replaced.
• A site permanently moves to a new domain.
• HTTP permanently redirects to HTTPS.
• One hostname variant permanently redirects to the preferred hostname, such as non-www → www or the reverse.
• Two pages were merged into one replacement.

Use a temporary redirect when:

• A campaign temporarily sends traffic elsewhere.
• A page is temporarily unavailable.
• You expect the original URL to become primary again.

---

3. Redirect Mapping Comes Before Implementation

Before changing URLs, build a mapping table.

Mapping first prevents accidental homepage redirects, missing destinations and avoidable chains. For a complex move, include important HTML pages plus image/video/download URLs that also receive traffic or links.

---

4. Avoid Redirect Chains

A chain looks like:

Old URL
   ↓
Intermediate URL
   ↓
Another URL
   ↓
Final URL

Prefer:

Old URL
   ↓
Final URL

Googlebot can currently follow up to 10 hops in a redirect chain, but Google's site-move guidance recommends redirecting directly to the final destination. If a chain cannot be avoided, Google advises keeping it low—ideally no more than 3 and fewer than 5. Long chains also add user latency and can fail in clients that tolerate fewer hops.

---

5. Avoid Redirect Loops

A loop occurs when redirects eventually send users back to a URL already visited.

URL A → URL B → URL A

Browsers and crawlers eventually stop following the loop.

Common causes include:

• Conflicting CMS redirects.
• HTTPS rules plus proxy rules.
• www/non-www redirects in both directions.
• Blogger Custom Redirects added on top of an already redirecting path.

---

6. Do Not Redirect Everything to the Homepage

Google explicitly warns against redirecting many old URLs to one irrelevant destination such as the homepage.

If no equivalent replacement exists:

• Let the old URL return a proper 404/410 where appropriate.
• Or redirect to a genuinely consolidated replacement page.

---

7. Blogger Custom Redirects

Blogger currently provides Custom Redirects under:

Settings
→ Errors and redirects
→ Custom redirects

You enter the deleted/old URL and the destination URL. Blogger's current Settings documentation describes Custom Redirects as redirects for URLs that point to pages of the same blog; this is not a substitute for a whole-domain migration strategy.

If the old article was permanently deleted/replaced, Blogger instructs you to enable Permanent.

---

8. Blogger Custom Redirect Example

Suppose the old URL is:

https://www.example.com/2026/08/old-guide.html

and the replacement is:

https://www.example.com/2026/09/new-guide.html

Use Blogger's Custom Redirects interface to map the old path to the new path, and mark it Permanent if the move is permanent.

---

9. Do Not Use Custom Redirects to Hide a Search Console Redirect Error

A Search Console redirect error can be caused by:

• A loop.
• Too many hops.
• A broken destination.
• Conflicting redirect rules.

Adding another redirect without diagnosing the existing path can make the problem worse. Check the current response code, each Location hop, the final status, hostname/HTTPS normalization and whether a Blogger Custom Redirect overlaps another platform/domain rule.

---

10. Hosting Migration Without URL Changes

If the public URLs remain exactly the same and only hosting infrastructure changes, you generally do not need page-level redirects. Google treats this as an infrastructure move rather than a URL-changing site move.

The migration flow is more like:

Same URL
   ↓
New server / platform
   ↓
DNS updated
   ↓
Same public page

For DNS-side planning, use our DNS Configuration Best Practices Guide.

---

11. Site Migration With URL Changes

A URL-changing migration requires more than DNS.

Google's current guidance also recommends reducing migration complexity where practical: avoid combining a domain move, CMS migration and major redesign into one simultaneous change if they can be separated. For large sites, a smaller test section can help expose problems before the full migration.

Google's current site-move process includes:

1. Prepare and test the new site.
2. Verify old and new Search Console properties.
3. Create an old-to-new URL mapping.
4. Implement server-side permanent redirects where possible.
5. Update canonicals, indexing controls and hreflang where used.
6. Update internal links and structured-data URLs.
7. Submit the new sitemap.
8. For a domain-to-domain move, submit Search Console Change of Address after redirects are active.
9. Monitor both old and new properties, server logs and crawl errors.
10. Make sure the new server/platform has enough capacity for temporarily heavier crawl activity during the transition.

Google says a small-to-medium site can take a few weeks for most moved URLs to be processed, while larger sites can take longer. That is a general observation, not a guaranteed recovery timetable.

---

12. Update Canonicals After the Move

New pages should use self-referencing canonicals on the intended new URLs unless a different canonical is deliberately required.

Do not leave:

New URL
   ↓
Canonical still points to old URL

For canonical troubleshooting, use our Canonical URLs & Indexing Guide.

---

13. Update Sitemaps and Crawl Controls

After a URL migration:

• Submit a sitemap containing the new canonical URLs in Search Console.
• If you temporarily keep/submit the old-URL sitemap in the old property to monitor processing, redirect warnings for those old URLs can be expected during the move; do not treat redirected old URLs as current canonical sitemap entries on the new site.
• Keep migration-related robots blocks from accidentally blocking the new site.
• Remove temporary noindex rules used during staging.
• Make sure redirected old URLs are not being treated as active canonical sitemap entries.
• Monitor Page Indexing, Sitemaps and URL Inspection for unexpected failures.

For sitemap and crawl-control implementation, use our Blogger Robots.txt & XML Sitemap Guide.

---

14. Update Structured Data URLs

If your Article or BlogPosting JSON-LD includes:

• mainEntityOfPage
• image URLs
• author URLs
• publisher URLs
• sameAs or other URL-valued properties where they changed

make sure any migrated URL references are updated where appropriate.

For implementation, use our Blogger JSON-LD Schema Guide.

---

15. Update Internal Links

Do not use redirects as a permanent substitute for updating your own internal navigation.

After the move, update internal links to point directly to new URLs.

This:

• Reduces redirect hops.
• Improves user experience.
• Reduces unnecessary server work.
• Sends clearer canonical signals.

---

16. Update Important External Links Where Practical

Google recommends updating important external references where practical so users avoid an unnecessary redirect and high-value links point directly to the new URL. Prioritize links you control and high-traffic external references where an update request is realistic.

Prioritize:

• High-traffic backlinks you control or can request changes for.
• Social profiles.
• Email templates.
• Paid campaigns.
• Partner pages.

---

17. Keep Permanent Redirects Long Enough

Google currently recommends keeping permanent redirects in place for at least one year.

This gives Google time to:

• Recrawl old URLs.
• Discover the new URLs.
• Transfer signals.
• Reprocess external links pointing to old URLs.

For users, Google suggests considering useful permanent redirects indefinitely. Even after the first year, old bookmarks, external links and long-tail references may still send people to legacy URLs.

---

18. Redirects and PageRank

Google's current migration documentation says 301 and other permanent redirects do not cause PageRank loss simply because they are permanent redirects.

The bigger practical problems are usually:

• Wrong destinations.
• Broken chains.
• Irrelevant redirects.
• Missing internal-link updates.
• Robots/noindex mistakes.

---

19. Expect Temporary Ranking Fluctuations

Google explicitly warns that rankings may fluctuate during a significant site move while URLs are recrawled and reprocessed.

That does not automatically mean the migration failed. Google says URL processing happens per URL and depends on the number of URLs plus the speed/capacity available for crawling.

Monitor:

• Old-property impressions and clicks.
• New-property impressions and clicks.
• 404/redirect errors.
• Indexed URL counts.
• Sitemap processing.

---

20. Domain Moves and Search Console Change of Address

A domain move changes the visible hostname, for example:

oldexample.com/article
        ↓
newexample.com/article

That requires coordinated:

• DNS.
• Redirects.
• Canonicals.
• Sitemaps.
• Internal links.
• Search Console verification and monitoring.

For a domain-to-domain migration, Google's current process says to verify the relevant old and new Search Console properties and submit a Change of Address after the redirects are active. Google specifically says to submit requests for the old domain's relevant subdomains plus www/non-www variants and ensure those variants are verified. If you are only moving from HTTP to HTTPS on the same hostname, the Change of Address tool is not required.

---

21. Blogger Custom Domain Moves

Blogger supports custom domains and a naked-domain redirect setting.

When moving to or reconfiguring a custom domain, verify:

• The Blogger-required CNAME values.
• The current A records for the naked-domain redirect where applicable.
• HTTPS availability.
• HTTPS redirect.
• The preferred www/non-www hostname.

Use current Blogger-provided values rather than stale copied DNS records. Blogger's current custom-domain documentation lists the chosen subdomain (commonly www) → ghs.google.com plus a second blog/account-specific security CNAME. For the naked-domain redirect, it currently lists these four A records:

216.239.32.21
216.239.34.21
216.239.36.21
216.239.38.21

After those records are in place, Blogger's Redirect domain setting can send the naked domain to the configured custom hostname.

---

22. Redirect HTTP to HTTPS

If HTTPS is the permanent version, redirect HTTP to HTTPS consistently.

For Blogger custom domains, use the platform's HTTPS availability and HTTPS redirect settings rather than trying to emulate server-level redirect configuration you do not control. Blogspot addresses are already HTTPS. Blogger also notes that custom domains using CAA records must allow letsencrypt.org or Blogger cannot create/renew the certificate.

Then update:

• Canonicals.
• Internal links.
• Sitemaps.
• Structured data.

---

23. Redirect www and non-www Consistently

A clean hostname setup should have one preferred version.

example.com/page
   ↓
www.example.com/page

or the reverse.

Do not configure both directions.

---

24. Merge Two Articles Correctly

If two old articles are consolidated into one stronger page:

1. Choose the final replacement URL.
2. Merge genuinely useful content and preserve the search intent that still matters.
3. Redirect each old URL directly to the consolidated replacement.
4. Update internal links, canonicals and structured-data URLs.
5. Remove old URLs from active sitemap listings.
6. Test each old URL and confirm the final page returns 200.

This is appropriate only when the consolidated page genuinely replaces the old intent and gives users a relevant destination.

---

25. Deleted Content With No Replacement

If a page is permanently removed and there is no meaningful equivalent:

Do not redirect it to an unrelated page merely to avoid a 404.

A proper 404 or 410 can be more accurate than an irrelevant redirect; Google includes correct 404/410 responses for content that is not being moved as part of site-move preparation.

---

26. Redirect Testing

Test with browser DevTools, command-line tools or a crawler.

Example:

curl -I https://www.example.com/old-url

For a chain:

curl -I -L https://www.example.com/old-url

Check:

• Status code.
• Location header.
• Number of hops.
• Final response code.
• Whether the final URL is indexable.
• Whether its canonical points to the intended final URL.
• Whether the redirect preserves the intended request method where 307/308 semantics matter.

For individual URLs, Google's current site-move documentation recommends Search Console's URL Inspection tool. For larger migrations, test mappings in bulk with a crawler or script, then monitor server access/error logs after launch rather than checking only a few browser examples.

---

27. Migration Validation Checklist

• Old-to-new URL mapping complete.
• Server-side permanent redirects implemented where possible.
• No loops.
• No unnecessary chains.
• No irrelevant homepage redirects.
• New pages return 200.
• New server/platform has enough capacity for the temporary crawl increase.
• New canonicals use intended new URLs.
• hreflang updated where used.
• Internal links updated.
• Sitemap updated.
• Temporary noindex/robots blocks removed.
• Structured-data URLs checked.
• Old and new Search Console properties verified.
• Change of Address submitted for applicable domain-to-domain moves and required old-domain variants.
• Redirects tested with URL Inspection / crawler / command-line checks.
• Server logs, crawl errors and old/new traffic monitored.

---

28. Common Redirect Mistakes

• 302/307 used indefinitely for a move intended to be permanent.
• Redirecting everything to the homepage.
• Creating long chains.
• Creating loops.
• Redirecting to a URL that itself redirects.
• Leaving old canonicals on new pages.
• Leaving old internal links unchanged.
• Blocking the new site with robots/noindex.
• Removing permanent redirects before Google and users have had enough time to transition.
• Using Blogger Custom Redirects as a blind fix for Search Console errors.
• Relying on JavaScript redirects when a server-side/platform redirect is available.
• Combining a domain move, CMS change and major redesign into one unnecessary simultaneous migration.

---

29. Final Redirect Decision Framework

Permanent URL move?
   ↓
301 or 308

Temporary move?
   ↓
302 / 307 (or 303 when appropriate)

Old URL has equivalent replacement?
   ↓
Redirect directly to it

No meaningful replacement?
   ↓
404 / 410 may be better

Whole-site URL migration?
   ↓
Map → redirect → update canonicals/links/sitemaps → Search Console → monitor

A durable migration depends on accurate old-to-new mapping, direct redirects, consistent canonicals/internal links/sitemaps and post-launch monitoring—not on adding redirect rules as quickly as possible.

---

Frequently Asked Questions

Should I use 301 or 308 for a permanent move?

Google supports both and recommends server-side permanent redirects such as 301 or 308 when technically possible. At the HTTP level, 308 preserves the request method; for ordinary GET-based page migrations, either can represent a permanent move.

What is the difference between 302 and 307?

Both are temporary redirects. A 307 explicitly preserves the request method, while a 302 is the long-established “Found” temporary redirect. For SEO, the key point is that both are temporary rather than permanent signals.

Does a 301 lose PageRank?

Google's current site-move documentation says 301 and other permanent redirects do not cause PageRank loss simply because they are permanent redirects. Correct destination mapping still matters.

How long should I keep 301 redirects?

Google recommends keeping them for at least one year. Keeping useful permanent redirects longer can also help users and old external links.

Can I redirect all deleted posts to my homepage?

No. Large groups of irrelevant homepage redirects can confuse users and may be treated as soft 404s.

How do I create a permanent redirect in Blogger?

Use Settings → Errors and redirects → Custom redirects, add the old and new paths, and mark the redirect Permanent when the move is permanent.

Should I use Blogger Custom Redirects to fix a Search Console redirect error?

Not blindly. Diagnose the existing redirect path first because another redirect can create or worsen a loop.

Do I need redirects when only the hosting server changes?

Not if the public URLs remain identical. That is primarily a hosting/DNS migration rather than a URL migration.

What should I update after a domain move?

Update redirects, canonicals, internal links, sitemaps, structured-data URLs where necessary, Search Console properties and important external references.

When should I use Search Console Change of Address?

Use it for an applicable domain-to-domain move after redirects are active and old/new properties are verified. Google says to account for old-domain subdomains and www/non-www variants; it is not required for an HTTP-to-HTTPS-only migration.

Are redirect chains bad?

They add latency and complexity. Googlebot can follow up to 10 hops, but Google's site-move guidance says to redirect directly to the final destination and, where unavoidable, keep chains low—ideally no more than three and fewer than five.