When should you use a 301 instead of a 302?

Choose 301 when the move is permanent and 302 when it is temporary. A URL is a page's web address; the status code is the server's short response explaining what happened to a request. Cloudflare's status code reference.

The distinction also matters to Google. A permanent redirect signals that the destination should become the canonical URL, meaning the main address Google chooses for that content. Google's explanation of redirect types.

Write down whether the move will be reversed

Before asking someone to configure anything, finish this sentence: “We intend to use this replacement address permanently because…” If the team cannot agree, resolve that decision first.

For more context on Google's choice of a main address, read the canonical tag guide. Keep your redirect brief focused on the actual move and the page customers should see.

What should go into your redirect map?

Create a simple table with an old address, a replacement address, a reason, and a person responsible for checking it. For a single page, one row is enough. For a larger change, review the rows before anyone applies rules.

Hypothetical example: a small furniture shop

Imagine a shop combines two delivery information pages into one clearer guide. Ask the owner to check that the new guide covers the delivery questions customers previously answered on either page. Then assign that destination to each relevant old address.

Do not choose the homepage merely because it is easy to find. Read the old page's purpose and select the closest useful replacement. If there is no suitable destination, mark the row for a content decision instead of guessing.

• Copy each old address from an existing link or page record.
• Open the proposed replacement before approving it.
• Check the language and service described on both pages.
• Record who approved the match.
• Keep unresolved matches separate from ready-to-implement rows.

Include links in navigation, articles, and buttons in your review. Use the internal linking guide to plan those updates, then give the implementer one approved list.

How do you create the redirect on your website?

Use the configuration method supported by your website environment. Google explains that implementation depends on the host, server, or underlying software, so there is no universal dashboard path. Server-side implementation guidance.

Start with your hosting or website dashboard

Ask your provider where redirects for this website should be managed. Send the actual old and new addresses, and specify a permanent 301. Request confirmation of whether the rule applies to one page or a wider group of addresses.

1. Open the approved redirect map.
2. If the dashboard provides a redirect form, enter the old address in its source field.
3. Enter the replacement in its destination field.
4. Select 301 or permanent when that option is available.
5. Save the rule and test the old address.

For a WordPress website

First ask whether your team already manages redirects through hosting or an installed plugin. Use that established route if it meets the task. Avoid choosing another plugin before checking what is already responsible for the rules.

If your existing tool offers a redirect form, use the source, destination, and status fields described above. Follow its field instructions: enter a path when it asks for a path, and a complete address when it asks for a complete address. These are implementation checks, not a claim that every WordPress installation has the same screen.

For an Apache server using .htaccess

Apache is server software, and .htaccess is one of its configuration files. Google's documentation includes a basic permanent redirect using Redirect permanent. Google's Apache example.

Redirect permanent "/old-services" "[FULL REPLACEMENT ADDRESS]"

This is a template, not a finished rule. Replace the bracketed text with your real destination and change the old path to match your site. Ask your host to confirm that this configuration method is appropriate before editing.

Keep a copy of the existing configuration. If rules already exist, have the implementer review their interaction and scope before adding another. Include related addresses in the test list so the review covers more than the intended page.

If someone else will implement it

Give them a clear acceptance requirement: “The approved old address must return a permanent 301 to this replacement, and the replacement must show the expected content.” Ask them to return the tested address list with their results.

How can you check that the redirect works?

Check both the destination and the response from the old address. A 301 response typically identifies its destination in the Location header, a field in the server response that supplies the new address. Cloudflare's explanation of 301 responses.

Ask the implementer to record the old URL, observed status, destination, and final page. That gives you something concrete to review even if you never open a technical inspection tool yourself.

• Open the old link and confirm the expected destination.
• Ask for confirmation that the old address returns 301.
• Read the final page as a customer would.
• Try the important enquiry, booking, or shopping action.
• Check nearby pages that should remain unchanged.

Hypothetical example: a consultant's booking page

Suppose a consultant renames a booking page. Test the saved old link, then complete the journey up to the point where a real booking would be submitted. Check the service description, available contact route, and any instructions the visitor needs.

If the test passes through several intermediate addresses, ask for a direct route to the approved destination. Keep your own links consistent with that destination too. Record failures by address rather than reporting that “the website redirect is broken.”

What changes when the whole domain moves?

Complete the move and redirects before using Search Console's Change of Address tool. This tool tells Google that your site has moved to another domain or subdomain. Google's Change of Address instructions.

Follow these requirements: own both the old and new Search Console properties under the same Google account, prepare the redirects, and open the tool from an eligible old property. Fix any critical checks that prevent submission. Ownership and pre-move checks.

Separate a page move from a domain move

Do not use Change of Address for a page moving within the same site, an HTTP-to-HTTPS change, or a switch between www and non-www on the same domain. For internal page moves, Google says to add redirects and update sitemaps as appropriate. When the tool should not be used.

A sitemap is a list of site pages supplied to search engines. Review the XML sitemap guide when preparing your updated page list.

For a broader move, use the domain migration guide as your planning companion. Avoid adding a major redesign to the same job unless necessary: Google warns that combining structural and content changes with a move can lead to traffic loss. Google's migration advice.

Also review how search engines will access the affected addresses with the robots.txt setup guide. Put that review on the migration checklist rather than making unrelated access changes while configuring redirects.

What should you finish before calling the job done?

Keep an approved map, a test record, and a named owner. I recommend treating these as the handover package for a small business website.

1. Approve: confirm every replacement with the person responsible for the content.
2. Implement: use the agreed configuration location.
3. Test: record the observed result for each old address.
4. Update: review your own navigation and content links.
5. Hand over: document where rules live and who maintains them.

Do not close the task with only a screenshot of the new page. Keep the original addresses and observed responses so someone else can repeat the checks later.