SEO redirect plan: a guide to preserving your traffic

A redirect plan is the operational document that ensures traffic continuity and the transfer of SEO signals during a redesign or migration. In practical terms, it is a row-by-row file — often a spreadsheet — mapping every old URL to a relevant destination and an HTTP code (usually 301 for a permanent change). Without this file, a migration produces hundreds of 404 pages, backlinks pointing nowhere and a drop in visibility that is difficult to recover from.

The four actions to take, in order:

A redirect plan is a structured file listing the new target address and the HTTP status code to return for every URL that will disappear or change. The most common format is a spreadsheet with at least four columns: old URL, new URL, redirect code and reason.

Its objectives are both technical and commercial. For search engines, it transfers accumulated authority (link signals, indexing history) to new pages, avoids fragmenting the index and preserves crawl budget. For users, it ensures a consistent experience: nobody lands on an error page after clicking a Google result or a shared link.

This document becomes essential whenever the site hierarchy or slugs change: a complete redesign, domain migration, a switch to HTTPS, content consolidation or a CMS change. The reference tools for building and validating it are Google Search Console (index coverage, crawl errors), GA4 (traffic and conversions by URL) and Screaming Frog (a complete crawl of the existing website).

Some projects make a plan indispensable; others simply make it useful. Here are the situations requiring rigorous preparation:

Choosing an HTTP code matters: it determines whether search engines transfer the source page's authority and update their index.

A 301 redirect is the standard for any permanent move: it generally transfers most of a page's SEO authority to its target. CMS platforms often use 302 by default, which is a mistake for permanent changes. Codes 307 and 308 are appropriate when the HTTP method (POST, PUT) must be preserved, particularly for API migrations.

Three rules never to break: always implement redirects on the server (never through JavaScript alone), avoid chains (A → B → C) and loops (A → B → A), and update internal links to point directly to the final destination.

A well-built plan preserves three critical assets: organic traffic, conversions and backlink authority. A page accumulating incoming links from third-party websites represents real SEO capital. Redirecting it correctly transfers that capital to the new URL rather than letting it disappear.

Conversely, a poorly planned mapping creates chains, loops and redirects to irrelevant pages — all errors that harm the user experience and the transfer of SEO signals. The practical consequences are falling visibility in the weeks after migration, index fragmentation (several versions of the same page indexed simultaneously) and excessive crawl budget spent on worthless URLs.

Google explicitly recommends server-side redirects, no chains, and submitting the updated sitemap after deployment. These recommendations are not mere suggestions: ignoring them slows reindexing and delays a return to the original traffic level.

Run a full Screaming Frog crawl to extract all active website URLs. Supplement it with an XML sitemap export, Google Search Console coverage reports and the most visited pages in GA4. Finally, add the list of URLs receiving backlinks (through Ahrefs, Majestic or Search Console). These four sources together provide a complete picture of what exists and what has value.

For each URL, record average monthly traffic (GA4), average position (Search Console), the number of incoming backlinks and its contribution to conversions. Combining GSC and GA4 lets you prioritise pages by traffic and conversions before mapping — a step many skip, at considerable cost during migration.

Every old URL must point to the page addressing the same search intent. A category page redirects to an equivalent category page, not the homepage. A discontinued product page redirects to a replacement product or the parent category, never to the homepage by default.

The mapping file must contain at least these columns: old URL, new URL, HTTP code, redirect reason, priority (P1/P2/P3), search intent, owner and status (to do / approved / deployed). Add a column for performance indicators (traffic, backlinks) to justify decisions during reviews.

Pro tip: When the old and new pages have different intents (for example, an informational page with no equivalent in the new architecture), create a suitable destination page rather than redirecting to a transactional page. A high bounce rate on the target is the first signal that intent has not been respected.

Pre-deployment checklist: every P1 URL has a defined target, no target is the default homepage, no chains detected, sitemap and robots.txt updated, and staging tests approved.

On Apache, redirects are configured in .htaccess or directly in the vhost. A simple rule looks like Redirect 301 /ancienne-page https://www.site.fr/nouvelle-page. For pattern-based rules, RewriteRule directives with regular expressions can cover hundreds of URLs in a few lines.

On nginx, a return 301 directive in the server or location block is more efficient than rewrite modules. Nginx processes redirects at server level without an interpreter, reducing latency.

On WordPress, extensions such as Redirection or Yoast SEO Premium manage redirects through a graphical interface and log 404s to make reactive mapping easier. Watch for duplicate rules: if a redirect is defined in both .htaccess and the extension, the resulting chain wastes resources.

On Shopify, redirects are managed under ‘Navigation → URL redirects’. The platform limits the number of redirects per store, making P1/P2/P3 prioritisation even more necessary.

For high-traffic websites, deploying redirects at CDN level (Cloudflare Workers, Fastly, etc.) eliminates latency at the origin server: the rule executes at the edge before the request even reaches the application infrastructure. This is the preferred solution for large-scale migrations.

Back up server configuration before any change. Test in staging with a Screaming Frog crawl of the staging environment. Prepare a documented rollback plan. Check Cache-Control headers to prevent browsers caching an incorrect redirect.

Rigorous staging acceptance testing prevents most post-deployment incidents.

During the first weeks, regularly monitor impressions and clicks in Google Search Console (the ‘Performance’ report), the 404 error rate (the ‘Coverage’ report), and organic traffic and conversions by page in GA4. Server logs complete the picture by revealing request volumes by HTTP code and any chains missed during QA.

The 0–8-week period is critical: this is when Google recrawls and reindexes new URLs. A review at 3 months validates ranking stability. At 6 and 12 months, check that 301 redirects remain active for URLs still receiving traffic or backlinks.

Keep 301 redirects for at least 12 months for every URL still generating visits or incoming links. Removing a redirect too early risks recreating the 404s you eliminated.

If impressions drop sharply in Search Console, check index coverage first: URLs with errors or excluded URLs often indicate an incorrectly configured redirect. For permanently deleted pages without an equivalent, return 410 (Gone) rather than 404: Google understands the content was intentionally removed and stops crawling the URL sooner.

Document every mapping change with a date and reason. A versioned file (Google Sheets with revision history, or a Git repository for server configurations) lets you trace an anomaly's origin months after deployment.

An A → B → C chain slows loading and dilutes SEO signals at every hop. The fix is simple: point A directly to C. An automated crawl script detects these chains across the website in minutes.

Redirecting all URLs without an equivalent to the homepage is the easy option and the most damaging. Google interprets these redirects as ‘soft 404s’: the page returns 200, but its content does not match the original URL. Always seek the closest page in terms of content and intent.

A page returning 200 with ‘product unavailable’ or ‘page not found’ misleads engines. Use Search Console's ‘Coverage’ report to identify URLs flagged as soft 404s, then decide: redirect to a relevant equivalent, or return 410 if the content is permanently removed.

On a multilingual website, an incorrectly configured redirect can send an English-speaking user to the French version or remove hreflang tags from the destination page. Check that every language version redirects to its equivalent in the same language and that the destination's hreflang tags match the geographical logic.

URLs receiving quality backlinks are the first to handle as P1. If a deleted URL receives links from third-party websites, redirecting it to the most relevant equivalent takes priority over the rest of the mapping.

URL mapping is more than a technical match between old and new addresses. Redirecting an informational page to a commercial page harms the user experience and conversion rate: someone seeking a practical guide lands on a sales page, bounces, and the negative signal reaches search engines.

The principle is simple: the source page's intent must match the target page's intent.

To support mapping decisions, combine intent data with performance metrics: an informational page with high organic traffic deserves an informational target, even if the new architecture has no exact equivalent. In that case, creating the missing page is often more profitable than redirecting to an approximate target.

Pro tip: Add an ‘intent’ column to your mapping file (values: informational / navigational / transactional / local) and require editorial approval for every P1 URL before deployment. This step takes an hour and prevents the most costly mapping errors.

For more on intent-based content strategy, the resources on SEO content strategy and internal linking usefully complement this guide.

A successful redirect plan rests on prioritising SEO value and respecting search intent in every mapping row, not just technically matching URLs.

SEO literature on migrations focuses heavily on technical details: HTTP codes, chains, loops and sitemaps. This is necessary but insufficient. The most common mistake we observe is not poor server configuration. It is mapping decided too quickly, without intent analysis, by teams trying to tick a box before deployment.

Redirecting a guide page to a sales page because ‘it is the closest page in the new architecture’ seems reasonable on paper. In the data, it produces a higher bounce rate, fewer conversions and a negative signal Google gradually incorporates. Traffic returns, but conversions do not follow, and the team does not understand why.

The other underestimated aspect is the plan's lifespan. A mapping file created for a migration and never updated becomes technical debt. Every new page and every URL changed after migration accumulates without documentation. Six months later, nobody knows why a particular redirect exists or whether it is still needed. Versioning the file, dating every change and assigning an owner to each row is not perfectionism. It maintains the website's consistency over the long term.

Building a rigorous redirect plan takes time: crawling, Search Console and GA4 data analysis, row-by-row mapping, staging tests and post-deployment monitoring. For a microbusiness or SME managing its migration alongside a complete redesign, the risk of overlooking a critical URL is real.

Pharelia handles the entire process: a free visibility audit to establish the baseline, building an intent-focused mapping file, technical deployment on your infrastructure (WordPress, Shopify, Webflow, Framer or a custom stack), and post-migration analytics through Search Console and GA4. Results for clients such as Applewood (+300 % in SEO) illustrate what a well-prepared migration delivers. For teams wanting to go further with visibility in generative engines after migration, the AI search optimization resources complement this approach.

Contact us to start with a diagnosis based on your actual data.

Inventory all your URLs through crawling (Screaming Frog), Search Console and GA4, assess their SEO value (traffic, backlinks, conversions), then map every old URL to a destination respecting the same search intent. Formalise everything in a spreadsheet with these columns: old URL, new URL, HTTP code, priority and status.

A redirect is a server instruction that automatically sends a visitor (and search engines) to a new address when the original URL has changed or no longer exists. It preserves traffic and SEO signals during migration.

A 301 redirect indicates a permanent move from one URL to another and transfers almost all SEO authority to the destination. Use it for any lasting change: domain migration, redesign, a switch to HTTPS or content consolidation.

Keep 301 redirects for at least 12 months for every URL still receiving organic traffic or incoming links. Removing them too early risks recreating 404 errors and losing transferred authority.

Yes. Pharelia builds the mapping file, deploys rules on your infrastructure and provides post-migration monitoring through Search Console and GA4. Every engagement starts with a free visibility audit available on pharelia.com.