How to Set Up 301 Redirects for a Website Migration Step by Step

How to Set Up 301 Redirects for a Website Migration Step by Step

A website migration is never just a technical move. One wrong URL, and a page that used to rank, convert, or get linked from a newsletter lands nowhere useful. That is why 301 redirects need a plan before launch day, not after.

This guide shows how to set up 301 redirects for a website migration step by step, without making the redirect layer do all the work. You will map the old site, decide what deserves a redirect, and check the results before search engines and users find the gaps.

1. Map the migration type and redirect goals

Start with one simple question: what kind of website migration are you doing? A domain change needs different thinking from a platform swap, and a URL structure change is its own animal. If all three are happening at once, write that down first. Not later.

For example, a brand move from oldsite.com to newsite.com may need almost every live page redirected, while a CMS change from one template system to another may keep the same URLs and only change how pages are rendered. Those are not the same job. If you treat them as the same job, the redirect plan gets messy fast.

Set one goal for the redirect layer: preserve the value of pages that already matter. That means traffic, links, and user intent. A product page should land on the closest product page. A blog post should land on the closest post, not the homepage.

Write the migration rules in plain language. Keep them short. “Old category pages move to new categories.” “Retired promo pages do not need redirects.” “Thin archive pages can be dropped.” Those decisions save hours later, because 301 redirects should follow the site’s real structure, not guesses made during launch week.

If the migration also changes content ownership or analytics setup, make that visible to the team. A site move often touches more than one group, and the redirect map has to match the business plan as much as the URL plan. For a broader view of the support work around a move, see how much does website maintenance cost.

2. Inventory only the URLs that need redirect coverage

Do not list every historical URL unless you truly need it. That sounds neat on paper, but it wastes time and creates noise. Start with pages, folders, and files that still have value: landing pages, service pages, blog posts, category pages, images if they are publicly linked, and PDFs that still get visits.

Pull URLs from more than one place. Use your current sitemap, analytics, server logs, and any old crawl exports you already have. A URL with no visits and no links may not deserve attention. A URL with outside links does. That one may still matter six months after the move.

Exclude pages that should intentionally retire. A seasonal campaign from 2021 does not need a new home just because it exists. Neither does an old internal test page. This is the part where discipline helps. Fewer redirects can be better than too many, as long as the important ones are covered.

Break the inventory into simple groups: pages, folders, files, and special cases. Numbers help here. A list of 12 URLs can be handled one way. A list of 1,200 URLs needs pattern rules, not hand-built rules for every line. If you skip this step, the redirect map becomes hard to audit.

Keep the inventory focused on the old site, not the new one. The old site is the source of truth for what exists today. The new site is the target. Mixing both too early makes it harder to spot missing pages and accidental duplicates.

3. Match old URLs to the correct new equivalents

Now build the mapping. A clean one-to-one redirect map is the easiest case: one old URL goes to one new URL, and the relationship is obvious. A blog post about pricing moves to the new pricing article. A service page about audits lands on the new audit page. Straightforward.

Real migrations are rarely that neat. Sometimes one old page becomes two new pages, or three old pages collapse into one stronger page. In those cases, decide what the user probably came for. If the old page covered both “setup” and “support,” but the new site splits them into separate pages, choose the best fit for the main intent and link the rest internally afterward.

Do not redirect everything to the homepage. That feels easy for one afternoon and expensive for months. Search engines dislike weak relevance, and users notice it even faster. A person looking for a pricing page does not want a generic landing page. They want the pricing page, or the closest working substitute.

For removed content, make a call. If there is no replacement and no meaningful equivalent, leave it out of the redirect map. That is cleaner than forcing a bad match. A page about an event from 2019 does not need a fake destination just to fill a row in the spreadsheet.

Write notes beside tricky URLs. Use a short explanation for merged pages, split pages, and retired content. Those notes matter when someone reviews the plan two days before launch and asks why page A goes to page B. The answer should be visible in the map, not hidden in chat.

4. Choose the right 301 redirect implementation method

Where you place the 301 redirects depends on how the migrated site is hosted. On some stacks, server config is the cleanest path. On others, the CMS, CDN, or app routing layer is a better fit. Pick the place that can serve the redirects reliably without adding extra moving parts.

If the site runs on a traditional web server, server-level rules may be the most direct option. If the site is managed inside a CMS with built-in redirect tools, that may be enough for smaller moves. If the traffic passes through a CDN, edge rules can help, especially when you need fast updates across many URLs.

Each option has a tradeoff. Server rules can be powerful, but they need careful handling. CMS plugins are convenient, but they can become cluttered. CDN rules are fast, but you need to know exactly how they interact with caching and path matching. Choose based on the migrated site, not habit.

If your migration also changes security settings, hosting, or tracking, coordinate that work in the same window. A redirect layer that depends on the wrong host name or an unfinished certificate setup can fail in strange ways. For related planning around site protection, see website security.

For larger teams, document the method in one place. Put the owner, platform, and deployment path beside the redirect map. That way, the person changing the rules knows whether they belong in Nginx, Apache, a CMS table, a CDN panel, or app code.

5. Write and organize the 301 rules

Now convert the map into actual 301 redirects. Keep the rules neat. One pattern should do one job. If a rule tries to catch too many URL shapes, it can capture the wrong pages and send users somewhere odd.

Watch for loops. A loop happens when page A redirects to page B and page B points back to page A, or when two pages keep sending each other in circles. That is a dead end for crawlers and users alike. It also wastes crawl budget, which is one of those boring phrases that becomes very exciting when nothing gets indexed properly.

Avoid chains too. A chain means one redirect leads to another redirect, then another. Page A goes to B, then B goes to C. It works badly and slows everything down. If you can point A directly to C, do that instead.

Use consistent naming and grouping inside the file or interface. Group rules by section: old blog paths, old service paths, old product paths, retired assets. A tidy list is easier to test. It is also easier to hand to another developer at 6 p.m. on launch day without long explanations.

Keep one eye on exceptions. A broad rule such as “redirect everything in /blog/ to /insights/” may look efficient, but it can break tags, author pages, or old media links. If a pattern has exceptions, carve them out before release. That saves cleanup later.

6. Verify redirect behavior before and after launch

Testing should happen before launch, not after the first user reports a broken page. Check a sample of individual URLs from the map, then test grouped patterns, then test odd cases such as trailing slashes, uppercase paths, query strings, and files with extensions. A redirect that works for one URL can fail on a close cousin.

Confirm the response code is a true 301, not a 302 or a soft rewrite that only looks like a redirect in the browser. That distinction matters. Search engines treat a permanent move differently from a temporary one, and users should not have to guess what happened. Check the status code with a tool that shows the actual response.

Test more than the obvious paths. Old PDFs, image URLs, and nested folder URLs often get overlooked. One missing file path can create a trail of 404s that keeps growing after launch, especially if those assets were embedded in pages or shared on social media years ago.

Run the checks in two phases: one before launch in a staging environment, and one immediately after launch on the live site. The second round catches deployment issues, caching surprises, and any rule that behaves differently once the real host is in play. That second round is where many teams find the one URL they forgot.

If the migration includes new analytics or monitoring, confirm the redirects do not break those systems. A move is easier to trust when you can see traffic, response codes, and crawl behavior together. For teams comparing measurement tools during this kind of project, how much does website analytics cost is a useful reference.

7. Update supporting signals after the migration

301 redirects should not carry the whole migration alone. Update internal links so the new site points to itself. If your navigation still links to old addresses, every click creates one more unnecessary hop. That is extra delay for users and extra work for crawlers.

Refresh XML sitemaps with the new URLs. Submit them where needed. Remove old URLs from the live sitemap if they now redirect, and keep only the destination URLs there. A sitemap full of outdated addresses sends mixed signals, even if the redirects work perfectly.

Check canonical tags. They should point to the new page, not the old one. This is a small line of code, but it matters. A canonical tag that still references the old URL can muddy the message you send to search engines, especially during the first crawl cycle after launch.

Update external references where possible. That might mean partner sites, social profiles, email templates, or a directory listing that you control. You will not catch everything, and that is fine. The goal is to reduce avoidable traffic through the redirect layer, not to fix the internet.

If your migration is part of a larger redesign, it helps to compare the redirect work with the broader content and budget decisions. The page titled website redesign budget vs maintenance budget can help frame the difference between change work and upkeep.

8. Monitor crawl and traffic issues in the first post-launch window

The first post-launch window is where problems show themselves. Check for missed URLs, unexpected 404s, redirect anomalies, and spikes in requests to old paths. Do this daily at first if the site is large. Twice a day is not overreacting when the migration is fresh.

Look at server logs, analytics, and search console data together. One source will miss something the others see. A 404 in logs may be a broken internal link. A crawl error may be a redirected URL with a typo. A traffic drop on a key page may mean the old path is still being shared somewhere important.

Patch gaps quickly. If a URL was missed, add it. If a pattern is too broad, narrow it. If a chain appears, collapse it. The redirect map is not finished at launch; it is a live document for at least the early days after the move.

Track the pages that matter most in the first 7 days, then again after 30 days if the migration is large. That gives you two checkpoints: one for immediate breakage and one for slower crawl and indexing effects. If the numbers look wrong, do not wait for them to self-correct.

Keep the team informed with concrete examples, not vague status notes. “Four product URLs still return 404” is useful. “Some issues remain” is not. If a marketing campaign, a press mention, or a top-linked page still points to an old address, fix that path first. One missed URL can have a bigger consequence than a dozen low-value pages.

Once the first wave is stable, review the redirect layer again against real traffic. Some old URLs will prove more important than the inventory suggested. Some others will never be hit. That evidence helps you tighten the redirect plan and keep the site cleaner as the migration settles.