How to Set Up Redirects: 301 vs 302, Domain Changes, and Broken URL Fixes

Overview

If you need a practical website redirect guide, start with one principle: a redirect tells browsers and search engines that one URL should send visitors to another URL. That sounds basic, but the details decide whether your change is clean or messy.

The two redirect types most people compare are:

• 301 redirect: use this when the move is intended to be permanent.
• 302 redirect: use this when the move is temporary and you expect the original URL to return.

In most site maintenance work, the right choice is a 301. That includes renamed pages, deleted pages with close replacements, domain changes, HTTP to HTTPS moves, and www to non-www canonicalization. A 302 is better for short-term maintenance, temporary campaign landing pages, limited tests, or situations where the original URL should remain the primary destination.

Here is the quick decision rule:

• If the old URL should stay gone, use 301.
• If the old URL will come back soon, use 302.

Redirects are usually configured in one of four places:

• Your web server, such as Apache or Nginx
• Your hosting control panel
• Your CMS or plugin, such as a WordPress redirect plugin
• Your CDN or reverse proxy

Where you implement redirects matters less than consistency. Pick one clear layer when possible, document it, and avoid stacking overlapping rules in multiple places unless you have a specific reason.

Before making changes on a live site, it is wise to create a backup and test plan. If your site runs on WordPress, pair this process with a safe workflow such as a staging environment and a recent backup. Helpful references include How to Create a Staging Site for WordPress and Test Changes Safely and How to Back Up a Website: Files, Databases, Restore Tests, and Backup Schedules.

How to compare options

When people ask how to set up redirects, they often mean two different things: which redirect type to choose, and where to configure it. Compare both before touching production.

1. Compare 301 vs 302 by intent

This is the most important comparison in any 301 vs 302 redirect decision.

• Choose 301 when a URL has been replaced, removed, consolidated, or moved long term.
• Choose 302 when the redirect is short-lived and the original URL should remain the main destination later.

If you are unsure, ask: “Will I want users and search engines to keep using the old URL next month?” If the answer is no, use a 301.

2. Compare redirect locations by control and simplicity

• Server-level redirects are usually fast and reliable. They are a strong choice for domain-wide rules.
• CMS or plugin redirects are easier for non-sysadmins and often ideal for page-level changes.
• CDN or proxy redirects work well when traffic passes through an edge layer and you want centralized control.
• Hosting panel redirects can be convenient for simple domain forwarding, though complex rule management may be limited.

For a few page changes on a content site, a plugin or CMS rule can be fine. For protocol and host normalization, such as forcing HTTPS or redirecting one domain to another, server or edge-level rules are often cleaner.

3. Compare redirect patterns by scale

• One-to-one redirects: old page to equivalent new page. Best for page renames and content migrations.
• Many-to-one redirects: several old URLs to one canonical page. Useful after content consolidation.
• Pattern-based redirects: rules that handle folders, slugs, or parameter formats. Useful for large migrations.
• Catch-all domain redirects: every path on an old domain maps to the same path on the new domain when structure is preserved.

The best redirect keeps intent and destination close. Redirecting a removed article to an unrelated homepage is usually weaker than redirecting it to the closest matching category or replacement article.

4. Compare success criteria before launch

A redirect setup is not finished when the rule is saved. Compare your options against a short checklist:

• Does the old URL return the correct redirect status?
• Does it land on the most relevant destination?
• Does it avoid multiple hops?
• Does the final page return 200 OK?
• Does the final page use the preferred protocol and host?
• Are internal links updated so users do not rely on redirects forever?

This matters especially during a migration. If you are moving hosts as well as domains, review How to Migrate a WordPress Site to a New Host Without Downtime.

Feature-by-feature breakdown

This section gives you a practical tutorial for the redirect jobs most site owners and admins face repeatedly.

301 redirect: the default for permanent URL changes

Use a 301 when:

• You changed a page slug
• You merged two articles into one
• You deleted a page and have a close replacement
• You moved from HTTP to HTTPS
• You changed from one domain to another
• You standardized www or non-www

Step by step guide:

1. List all old URLs that will stop working.
2. Choose the best matching new URL for each old one.
3. Create one-to-one 301 rules where possible.
4. Test each redirect manually and with a header-checking tool.
5. Update internal links, sitemaps, canonicals, and navigation.
6. Monitor logs, analytics, and crawl reports for misses.

A 301 is not just a convenience for visitors. It is also a clean signal that a resource moved permanently.

302 redirect: useful, but only for temporary moves

Use a 302 when:

• A page is temporarily unavailable during maintenance
• You are running a short campaign that should not replace the original page permanently
• You need a temporary holding page while final content is being prepared

Common mistake: leaving a 302 in place for months after a migration. If the move becomes permanent, replace it with a 301 and update internal links.

Redirect old domain to new domain

This is one of the most common redirect tasks. If your URL structure stays the same, the cleanest setup usually maps every old path to the same path on the new domain.

Example:

• olddomain.com/about → newdomain.com/about
• olddomain.com/blog/post-1 → newdomain.com/blog/post-1

Step by step guide:

1. Point the old domain to a place where it can serve redirects.
2. Install SSL on the old domain if HTTPS requests must be handled.
3. Create a domain-wide 301 rule that preserves the path and query string when appropriate.
4. Test both HTTP and HTTPS versions.
5. Test both www and non-www versions.
6. Update DNS, canonical tags, sitemap files, and key backlinks where you control them.

For related setup concerns, see How to Fix Mixed Content Errors After Enabling HTTPS and XML Sitemap Guide: How to Create, Submit, and Troubleshoot Site Maps.

Fix broken URLs with redirects

When visitors or crawlers hit removed URLs, a redirect can often recover the experience. The key word is relevant. Redirect broken URLs only when there is a logical replacement.

Good examples:

• Old product page → updated version of the same product
• Deleted tutorial → equivalent new tutorial
• Old category slug → renamed category page

Less helpful examples:

• Every missing URL → homepage
• Unrelated content → a random high-traffic page

Step by step guide:

1. Find broken URLs in analytics, logs, crawl reports, or search console tools.
2. Group them by pattern: typo, renamed slug, deleted section, migrated folder.
3. Create targeted rules for recurring patterns first.
4. Add one-off redirects for valuable backlinks or frequently visited pages.
5. Leave truly gone, irrelevant content as 404 or 410 rather than forcing a poor redirect.

Redirects are not a replacement for fixing your internal links. If links inside your site still point to dead pages, update them directly.

Canonicalization redirects: HTTPS, www, trailing slash, and index files

Many websites also need redirects for consistency:

• HTTP → HTTPS
• www → non-www, or the reverse
• /page → /page/, or the reverse
• /index.html → /

These rules reduce duplicate entry points and keep your site structure cleaner. They should work together, not fight each other. A common problem is creating separate rules that cause multiple hops, such as HTTP → www HTTP → www HTTPS → final URL. The better outcome is one hop to the final preferred URL.

If you are adjusting robots or sitemap behavior during cleanup, pair this work with robots.txt Guide for Beginners: What to Allow, Block, and Test.

WordPress redirects

In WordPress, redirects can be managed through plugins, server rules, or hosting tools. A plugin is often the fastest beginner friendly tutorial path for post and page changes, especially if you need logging and easy editing. Server rules are often better for domain-level and protocol-level redirects.

Use WordPress redirects when:

• You changed post slugs
• You consolidated content
• You removed attachment or archive URLs
• You need easy redirect management without editing server config

Keep plugin-based redirects organized. Name rules clearly, remove temporary entries when finished, and avoid duplicate logic between plugin and server layers.

Best fit by scenario

If you want the short version, use this comparison table in prose form whenever you are deciding what to do.

Scenario: you renamed a page

Best fit: 301 from old URL to new URL. Then update internal links and the sitemap.

Scenario: you removed a page but published a better replacement

Best fit: 301 to the closest replacement page.

Scenario: content is gone and there is no relevant replacement

Best fit: no forced redirect. Serve a proper 404 or 410 and improve your 404 page.

Scenario: temporary maintenance page

Best fit: 302 while the original page is expected to return.

Scenario: old domain to new domain migration

Best fit: domain-wide 301 redirect that preserves paths where possible. Keep the old domain active long enough to continue serving redirects.

Scenario: switch to HTTPS

Best fit: site-wide 301 from HTTP to HTTPS, followed by fixes for mixed content and updated canonicals.

Scenario: you merged multiple thin pages into one stronger page

Best fit: 301 each old page to the consolidated destination if the topics closely match.

Scenario: campaign page for a limited time

Best fit: 302 if the original page will return as the main URL after the campaign.

In every scenario, the same practical rule applies: redirect to the most relevant live destination, not just the easiest one.

After migrations and cleanup work, also review performance and crawlability. Related guides that fit well after redirect work include How to Speed Up a WordPress Site: Performance Checklist You Can Reuse and Subdomain vs Subdirectory for SEO and Site Structure: When to Use Each.

When to revisit

Redirects are not set-and-forget. Revisit them whenever the underlying site structure changes, and use this section as your action checklist.

Review redirects when:

• You change domains or subdomains
• You redesign your URL structure
• You move from HTTP to HTTPS
• You migrate to a new host, CDN, or reverse proxy
• You delete, merge, or rename content at scale
• You notice rising 404 errors or crawl anomalies
• Your CMS, plugin, hosting panel, or edge platform changes how redirect rules are managed

Practical maintenance routine:

1. Export or document your current redirect rules.
2. Check for redirect chains and loops.
3. Verify that temporary 302 rules are still truly temporary.
4. Find old redirects that can be simplified after internal links are updated.
5. Review 404 logs for new broken URLs worth fixing.
6. Retest preferred canonical rules: HTTPS, host, trailing slash, and index-file behavior.
7. Update your XML sitemap and internal navigation after major changes.

What to avoid:

• Using redirects to hide poor site structure indefinitely
• Redirecting every missing page to the homepage
• Keeping multiple competing rule sets in plugins, server files, and CDN settings without documentation
• Leaving old domains to expire while they still receive useful traffic or backlinks

If your site includes transactional elements such as contact forms, test those after migrations too, since URL and protocol changes can reveal unrelated issues. A useful companion article is How to Fix a Website Contact Form That Is Not Sending Emails.

The simplest long-term habit is this: every time you change a URL, ask what should happen to the old one. If the answer is not written down and implemented, you probably need a redirect, a proper 404, or an internal-link update. That one habit prevents a surprising number of broken experiences.