SEO migration: how to succeed with your redirect plan

Nils Talibart has been an independent SEO consultant since 2012. He supports major accounts (La Poste, Brico Dépôt, SeLoger) and SMEs in optimizing their visibility.

During a site redesign, a CMS change, or a simple structure modification, your site's URLs may change. On the surface, it seems like a mere technical detail. In reality, this change can have heavy consequences for your SEO - and therefore your revenue - if it isn't anticipated: drops in rankings for target keywords, loss of organic traffic, a fall in conversions or sales, etc.

It is precisely to avoid this scenario that the redirect plan comes into play during your SEO migration. It ensures continuity between your old URLs and the new ones, for both users and search engines. Provided, of course, that it is correctly prepared and implemented.

What is a redirect plan?

Website redesign, CMS change: many migration cases can result in changes to your website's URLs. However, without redirecting your old URLs to the equivalent new URLs, your organic traffic is likely to plummet. Hence the importance of the redirect plan.

A redirection from URL A to URL B allows traffic to be sent from URL A to URL B, whether it involves your users... or crawlers and other search engine bots.

The benefit? Maintaining your SEO performance and preventing your users from landing on error pages. Indeed, if your URLs have changed, then your old URLs now risk returning an error, which is why it is important to redirect them to their new address.

A redirection plan is the document that lists all the redirections or redirection rules to be implemented as part of your migration. It generally takes the form of a spreadsheet with three columns:

• The list of URLs to be redirected (source URLs)
• The list of URLs to redirect them to (target URLs)
• The expected redirect type

Old URL (Source URL)	New URL (Target URL)	Redirect Type
https://www.example.com/content-page.html	https://www.example.com/content-page/	301
https://www.example.com/product/12345-product-file.html	https://www.example.com/p/12345-product-file/	301
https://www.example.com/content/123-article.html	https://www.example.com/blog/123-article/	301

The redirect plan can also include redirection rules (using a wildcard or a regular expression), which allow for the coverage and simultaneous processing of a large number of URLs sharing the same structure.

Why implement a redirect plan?

Implementing a redirect plan serves several purposes.

For your SEO

Your content pages are likely currently ranked in search engine results for the keywords you target and are generating organic traffic. If their URL changes during your migration, the old URL will likely result in an error, and you will lose all the benefits of the optimization work carried out so far:

• Loss of visibility and drop in keyword rankings
• Drop in your organic traffic
• Decrease in revenue or leads generated through the SEO channel

By setting up a redirect from your old URLs to the equivalent new URLs, you inform search engine bots that your content has moved, and they should now index the new URL. Popularity signals are thus transferred from the old URL to the new one—provided you use 301 redirects.

In particular, if your current URLs receive external links (the famous "backlinks"), whether obtained naturally or purchased, setting up 301 redirects allows the popularity currently transmitted by these backlinks to your old URLs to be transferred to your new URLs. Without redirects, these backlinks would point to an error page... and would then lose all effectiveness (no popularity transfer).

A well-managed redirect plan is therefore an indispensable condition for maintaining SEO performance during a migration.

For your users

Failing to redirect when migrating your website also means risking your users landing on error pages. Indeed, many internal links on your site - especially links within your editorial content - may point to pages whose URL has changed, and thus now result in a 404 error.

While waiting - ideally - to correct all these internal links to point to the correct final URL, implementing redirects allows the user to arrive at the correct content seamlessly as they browse your site.

In addition to your own internal linking, you must also consider links over which you have no control:

• External links (received from other domains) pointing to a specific page on your site
• URLs bookmarked by your users
• etc.

Implementing redirections ensures that a user clicking on one of these links will arrive at the correct page, rather than an error page.

For your acquisition campaigns

You may be running paid acquisition campaigns (Google Ads or Facebook Ads, for example). You do your best to anticipate URL changes related to the migration, whether you are directly in charge of the campaigns or they are managed by a service provider. In an ideal world, the destination URLs of your campaigns change as soon as the new version of your website goes live.

However, for many reasons (unresponsive provider, other internal issues, new URLs known late, etc.), this change may occur much later, which can result in:

• Clicks - which you pay for - leading to error pages
• An interruption of your advertising campaigns, which is always damaging when they are performing well

Implementing a redirect plan thus ensures that users clicking on your ads will be redirected to the correct landing page, and that your campaigns will not be interrupted.

When should you plan for redirections?

Several frequent scenarios require the implementation of redirections - without always necessarily requiring a full redirect plan.

CMS change

A CMS change almost systematically comes with URL modifications. A redirect plan must then be established to match old URLs with the new ones.

Website redesign

If the redesign is purely graphical (UI/UX changes with no content impact), you may not need redirects. However, if it involves a structure change or content deletion, a plan is necessary.

Deleting obsolete pages

Are you deleting pages from your site that are now obsolete? If these pages generate traffic and/or receive backlinks, it is recommended to redirect them.

Warning: not every deleted page needs to be redirected. Redirecting pages with no traffic or popularity is not necessarily useful if you redirect to an unrelated page. You must ensure you redirect to a page with equivalent or semantically close content. Making mass 301 redirects to the site's homepage is also not recommended.

Content merging

Have you accumulated content over time, with several pages targeting the same search intent? You may need to redirect one to the other to consolidate your SEO signals on a single URL and avoid cannibalization in search results.

Product evolution on an e-commerce site

Are products and categories on your e-commerce site evolving (seasonality, discontinued product, etc.)? You can then set up 301 redirects to an equivalent product sheet or to the higher-level category - if you don't already have automatic rules to manage this.

Domain name change

If your brand name changes, you must redirect all old URLs to the equivalent ones on the new domain. If only the domain changes (no structure changes), a single global rule can often handle the entire migration.

Moving from HTTP to HTTPS

It is imperative to have an HTTPS site today. To manage the redirection of HTTP URLs to their HTTPS equivalent, a redirect plan is not necessary either: a single rule is enough. redirection.io actually offers a ready-made recipe to handle this easily.

Shortened URLs

For their campaigns (print, SMS, email), some advertisers sometimes use shortened URLs, which are easier for a user to remember and copy, or simply more elegant than the long URLs with tracking parameters they redirect to. If you have configured such URLs, notably directly from a CMS, remember to keep these redirections in place in case of migration.

What are the different types of redirection?

There are several types of redirection... and they are not all equal for maintaining SEO performance! To put it briefly: use 301 redirects.

JavaScript redirection

JavaScript redirection is a client-side (browser) redirection. A JavaScript function modifies the URL of the page to be displayed, but without modifying the HTTP header of that page - meaning without modifying the response code.

This type of redirection is generally ignored by search engine crawlers and is therefore totally discouraged in the context of an SEO migration.

Meta refresh tag

Redirecting via a meta refresh tag is also a client-side (browser) redirection. A meta refresh tag is added to the page to tell the browser to redirect the user after several seconds (or immediately) to the specified URL.

Google takes it into account but does not recommend it, notably because the processing time is too long.

302 redirection

A 302 redirection is a server-side redirection. It is a temporary redirection: it allows users and search engine crawlers to be redirected to the correct URL, without this redirection being taken into account in the search engine index:

• The old URL remains indexed
• There is no popularity transfer from the old URL to the new one

However, these last two points tend to become less true over time: a 302 redirection that stays in place for a long time will eventually be considered by Google as a 301 redirection and will behave as such.

Despite this, 302 redirections should generally not be used during an SEO migration (except in rare cases for redirections that are truly temporary).

307 redirection

Like the 302 redirection, the 307 redirection is a temporary redirection introduced with the HTTP/1.1 protocol. The difference is primarily technical, with the preservation of the request method (GET, POST, etc.).

Google treats it like a 302 redirection.

301 redirection

A 301 redirection is also a server-side redirection. This is the correct method - recommended by Google - for making "SEO-friendly" redirections whenever a page's URL changes permanently: it helps search engines understand that the page has moved and that the new URL should now be used.

With a 301 redirection:

• The search engine automatically updates its index to replace the old URL with the new one
• The popularity acquired by the old URL is transferred to the new one: if links were made from other sites to the old URL, the popularity transmitted by those links is transferred to the new URL with the 301 redirection

Generally speaking, when a redirection needs to be implemented, it should be a 301.

Note: in the absence of explicit instructions via HTTP cache management headers (Cache-Control, Expires, ...), a 301 redirection can be cached indefinitely by browsers, which will no longer request the original URL after the first visit (unless the cache is cleared).

308 redirection

The 308 redirection is to 301 what 307 is to 302: it is a permanent redirection that does not modify the initial request method during redirection.

Although much rarer than 301 redirects, 308 redirects are treated the same way by Google, which updated its official documentation several years ago to indicate that these redirects are indeed considered permanent.

How to implement a redirect plan?

Now let's get into the heart of the matter! How to establish your redirect plan and how to implement it? We will proceed step by step, in order to:

• Retrieve all the URLs of our site
• Sort our existing URLs to keep only those to be redirected
• Associate these old URLs with the equivalent new URLs
• Test our redirect plan
• Put it online

Gather all URLs to be redirected

To prepare your redirects plan, you must start by listing all your current URLs. To do this, you can rely on different sources, which will provide different types of data that you can consolidate into a single file, with the following for each URL:

• Organic traffic
• Global traffic
• Current response code
• SEO visibility (ranked keywords and/or estimated organic traffic)

Site crawl

First step: start by performing a full crawl of your site. This crawl will allow you to list all the URLs linked to your site structure, i.e., those receiving internal links.

To do this, you can use the crawler of your choice, for example:

• Screaming Frog
• OnCrawl
• Botify

You can also, of course, use redirection.io's crawler, which works with a credit system based on the number of URLs to explore.

Be sure to properly configure your crawler's options to retrieve all URLs:

• XML sitemap crawl
• Google Search Console data integration
• Google Analytics data integration (or other analytics tool)
• Etc.

You can then export the list of URLs obtained, associating at least each URL with its response code - and ideally traffic data (Google Search Console clicks, traffic from your analytics tool) if your crawler allowed you to retrieve them.

XML sitemap

If you were not able to retrieve the list of URLs from your sitemap at the time of the crawl, you must also add it, with the response code associated with each URL. Indeed, although a sitemap should only contain URLs that respond with an HTTP 200 (OK) code, in practice, this is far from always being the case.

Taking the XML sitemap into account helps identify potential orphan URLs not linked to the site structure by internal linking, which might not appear in your initial crawl.

Google Search Console data

Google Search Console allows you to see the list of URLs on your site that generate traffic and impressions. This list is important for:

• Associating organic traffic data (clicks from Google search results) with your URLs to more easily prioritize and sort them later
• Identifying new orphan URLs

Ideally, traffic data (clicks and impressions) should be taken over a 12-month period to avoid any seasonality effects.

Warning: the Google Search Console interface only allows you to export a list of 1,000 URLs, which can be largely insufficient for sites with higher volume. Several solutions are available:

• Use the Google Search Console API
• Use Google Looker Studio, creating a report with Google Search Console as the data source
• Use a Google Sheets extension like Search Analytics for Sheets, which allows you to export up to 10,000 rows per request for free (and the total in its paid version)

Analytics data

Google Search Console data only concerns SEO. However, many URLs on your site may generate traffic without it being organic traffic (or without this traffic appearing in Google Search Console):

• Noindex pages
• Acquisition campaign landing pages
• Customer area or environment requiring a login - and thus inaccessible to search engine crawlers
• etc.

This is why you should also retrieve the list of your URLs that generate traffic from your analytics tool (for example, Google Analytics). Again, it is recommended to take data from the last 12 months.

SEO visibility analysis tools (keywords)

To ensure you don't miss any URLs, you can supplement this data by looking at an SEO tool for the list of your pages with visibility in Google search results, i.e., your pages ranking for keywords.

Many tools allow you to see, for each URL of your site, the number of keywords it ranks for (overall, but also in the top 3 or top 10), with an estimated traffic indicator:

• HaloScan
• SEMrush
• Ahrefs
• Sistrix
• etc.

This is the guarantee of not missing a URL that might have visibility on Google.

SEO popularity analysis tools (backlinks)

Similarly, you can look at the URLs of your site that receive backlinks (external links from other domains). It will be important to properly redirect these URLs as well during your migration, as they receive popularity - which risks being lost if your page subsequently returns an error.

Several tools allow you to retrieve the list of pages on your site that receive backlinks:

• Babbar
• Majestic
• SEMrush
• Ahrefs
• etc.

Logs

Final data source to ensure all your site's URLs are taken into account in your redirect plan: server logs. They allow you to:

• Obtain the list of all your URLs generating traffic (without being dependent on tracking reliability)
• Identify all URLs explored by Googlebot, Google's crawler

redirection.io's log analysis tool is perfect for this, allowing you to group your URLs, sort them by descending hit count, and filter them by user-agent.

Filter your URLs

Once you have a consolidated list, it's time to filter them, because not all of them will necessarily need to be redirected. And a redesign or migration is precisely the opportunity to do a big clean-up!

To perform this filtering, you should notably rely on the data you collected alongside your list of URLs:

• Organic traffic (Google Search Console data)
• Global traffic
• Visibility in Google search results
• Popularity (backlinks received)
• Response code

Consolidate all this data within a single document, carefully deduplicating your URL list. You can then proceed with sorting to prepare your redirect plan.

• URLs that return an error (HTTP 404 or 410 codes in particular) will not need to be redirected - unless they receive backlinks
• URLs that have generated no clicks from Google search results over the last 12 months (Google Search Console data) should be examined more closely. Are you going to keep these pages? You can also set a slightly higher click threshold to study content that doesn't reach it and decide whether to keep it or not
• Are there duplicate content URLs? URLs from a "spider trap"? "Technical" URLs generated by your CMS that have no interest (neither for SEO nor for the user)?
• etc.

Warning: remember to keep your existing redirections (resulting, for example, from a previous redirect plan or URL changes made as your content evolved).

Associate your old URLs with the new URLs

Now that you have the list of URLs to be redirected, you will need to associate each of these old URLs with its equivalent new URL. In practice, if you are preparing your redirect plan on a spreadsheet, with the list of your old URLs to redirect in column A, then you can associate the new URL to which you will redirect in column B.

Of course, this implies knowing your future URLs beforehand. To do this, a crawl of the future version of your site in staging may be necessary, provided of course that it is finalized - i.e., all content is properly online. Otherwise, you will need to do another crawl to complete your redirect plan later.

In some cases (an e-commerce site with a high volume of products, for example), only part of the content might be online on a test environment, but you can then generally rely on a redirection rule to redirect all content of the same type. In other words, you don't need to know all your future URLs; a rule will easily establish the correspondence between these future URLs and your current URLs (for example, based on an ID).

As a reminder, avoid changing your site's URLs as much as possible. Try to keep your existing URLs if you can and build on them in the long term.

If you have no choice and your URLs must change, the matching work between old and new URLs can sometimes be quite tedious if you have to do it manually URL by URL. Here is how to make the job easier and save time.

Use the redirection.io automatic redirect plan generator

Good news: redirection.io offers a tool to automatically generate your redirection plan in just a few minutes.

• Enter your website's URL in its current version
• Enter your future site's URL in staging
• redirection.io crawls both versions, extracting every URL and all content from each page
• redirection.io evaluates semantic similarity between content and URL matching to suggest the best possible correspondences between old and new URLs
• Export your redirect plan in CSV format

You can then import it directly into redirection.io or any other tool of your choice - or even deploy the redirections directly from the redirection.io interface.

redirection.io uses AI models based on several factors (URL structure, page content, metadata, etc.) to automatically generate your redirect plan, and displays a confidence score for each match between source URL and target URL. Several quality checks also ensure that the generated redirection plan:

• Does not contain loops or redirection chains
• Properly includes all old URLs

Use Screaming Frog

If you use Screaming Frog as your daily crawler, you can also use it to make the matching work between old and new URLs easier for your redirect plan.

Warning however: unlike the tool offered by redirection.io, the functionality used by Screaming Frog is not directly designed for creating a redirect plan and may therefore provide imperfect results - but they can still save you precious time. It will also require a bit more configuration.

Screaming Frog relies on vector embeddings to identify semantically similar pages between your current production version and your future staging version. The different steps are detailed in a very comprehensive guide.

You will first need - in order to generate the vector embeddings of the crawled pages - to provide an API key for an LLM like OpenAI, Gemini, or Ollama, use list mode to crawl old and new URLs, and then - after launching the crawl analysis - study the proposed semantic matches. You can then export the results to work on your redirect plan, being sure to manually check the proposed matches, especially those with a low semantic similarity score.

Rely on common elements to associate old and new URLs

Generally, depending on the nature of your site (e-commerce, editorial content, etc.), you can also rely on several common elements between your old and new URLs to associate them in your redirect plan (provided these elements haven't changed):

• Page title tags
• H1 title
• ID in the URL (product, category, content)

This also implies performing a crawl of both versions of your site (current and future) with your favorite tool beforehand, sometimes using the functionality that allows you to directly extract data from page content:

• Custom extraction on Screaming Frog
• Data scraping on OnCrawl

This functionality can indeed sometimes allow you to extract an ID (if not present in the URL) or a SKU code for products directly from the page content, which will then be useful for matching old and new URLs.

Testing your redirect plan

Have you finalized your redirection plan? Now it's time to test it! Ask your technical team to deploy your redirect plan in staging.

If you use redirection.io and have activated "test mode", you can implement the redirections yourself and handle the QA - thus making adjustments if necessary without depending on internal or external resources. No more back-and-forth with an external provider or your IT team to ask for corrections.

Crawl your redirect plan - once deployed - on your staging environment. Ensure:

• That each source URL correctly responds with a 301
• That each source URL redirects to the target URL in a single step (no redirection chain)
• That the target URL redirected to matches the expected URL and responds with a 200
• That there are no redirection loops

If you use Screaming Frog to crawl your redirect plan, use list mode and the redirection-related report.

Similarly, on redirection.io, the crawler tool allows you to upload a list of URLs to explore to verify their response code and the URL you are redirected to.

Also, remember to perform a full crawl of your site in staging to ensure non-redirected URLs behave correctly.

Note: redirection.io allows you to test all your rules in one click. This doesn't replace a crawl in staging or production, but it's very useful for checking the consistency of your redirection plan - especially if it is being added to existing rules.

Monitoring your redirect plan once live

Has your migration taken place and is your redirect plan live? Even if you validated it in QA, check it again in production. For safety, you can also crawl your top URLs (URLs that generated the most clicks in Google Search Console, URLs with the most visibility in your favorite SEO tool, pages generating the most conversions/turnover, etc.) to ensure they return the expected response code.

If everything is OK, your work doesn't stop there. From now on, you can:

• In the short term, check server logs to ensure your migration is going smoothly
• In the long term, verify that URLs in your redirect plan continue to respond correctly with a 301

Tracking your migration with server logs

A site migration or redesign is never insignificant from an SEO perspective. To ensure everything is going well, you can consult server logs, looking particularly at URLs returning errors (404 error, 500 error, etc.).

This could help you identify certain issues, especially pages that might not have been redirected, keeping in mind that a page returning an error isn't necessarily a problem. Indeed, as we saw earlier, you may have thinned out your content and thus chosen to return a 410 error on some URLs.

With redirection.io, you can track your logs in real-time, and thus monitor your traffic and Googlebot's crawl in the minutes following the migration going live. With the ability to react immediately and autonomously if you notice an oversight or error in your redirect plan, by completing or correcting it directly from the interface.

The "weekly digest" sent every Monday with key site traffic figures also allows you to ensure everything is OK, as does the ability to configure alerts in case of traffic anomalies.

Monitoring your redirect plan to avoid regressions

Your 301 redirects should be kept in place for as long as possible. This is your insurance that they continue to fulfill their role. However, I regularly notice that this isn't always the case.

Recently, a client changed hosting. The operation was carried out by their current technical provider... and resulted in the deletion of 301 redirects implemented a few months earlier during the site migration with another provider. Result: the old redirected URLs now returned a 404 error. However, these URLs received backlinks. The popularity transmitted by these backlinks was thus no longer passed on to the new URLs.

Another example, in the screenshot below. An entire section of a site had been redirected. But there was a regression on the redirections. The old URLs, once again accessible, were re-indexed by Google, ranked in its results, and continued to generate organic traffic (these are the visible peaks on the solid curve at the bottom). This led to a very poor user experience, as these were pages not adapted for mobile viewing - which accounted for the majority of the traffic.

How to avoid this? By ensuring, every day, that the URLs in your redirection plan continue to respond with a 301 response code.

For my part, I use the Oseox Monitoring tool for this, which has a feature to daily check the response code of a list of URLs. Thus, if all or part of the URLs in my redirect plan stop responding with a 301, I am notified by email within 24 hours (or even within an hour if enhanced monitoring is desired for certain URLs). Useful for reacting before the impact is felt on traffic.

With redirection.io, the combination of real-time traffic logs and notifications also allows you to be alerted in case of anomalies. You can:

• Create a "log view" with a few examples of URLs to monitor that should be redirected but whose response code is not 301
• Configure a notification if this "log view" ever contains items

You will thus be notified as soon as one of your normally redirected URLs returns a response code other than 301.

Finally, you can also use redirection.io's scheduled crawl function to set up a regular crawl on the list of URLs that make up your redirect plan, thus verifying they still correctly respond with a 301.

Tracking your rankings and organic traffic

After your migration and the implementation of your redirect plan, closely monitor your usual SEO indicators:

• Evolution of rankings on your keywords, especially those targeting pages affected by the redirect plan
• Evolution of your organic traffic, segmenting your URLs to focus specifically on sections affected by the migration, and comparing to last year (to account for seasonality effects)

Conclusion

A migration is one of the classic milestones in a website's life. In almost all cases, it must be accompanied by a redirect plan, an indispensable condition for maintaining SEO performance... provided, of course, that it is correctly defined and implemented.

Several tools can help you with this, from matching old URLs with new ones to monitoring the redirect plan once live, as well as its implementation and QA.

redirection.io can notably intervene at different stages:

• Defining the redirect plan thanks to the automatic redirect plan generator
• Implementation on a test environment and then in production
• QA thanks to the crawler
• Monitoring with the log tracking tool

This is your opportunity to save time, reduce the risk of error, and work autonomously, without depending on internal or external resources.