Redirect Mapping for Site Migration: Complete SEO Preservation Guide
Moderate 38 min 2026-03-20

Redirect Mapping for Site Migration: Complete SEO Preservation Guide

Quick Summary

  • What this covers: Master redirect mapping for site migrations. URL inventory, redirect logic, 301 implementation strategies, and post-migration validation to preserve rankings and traffic.
  • Who it's for: site owners and SEO practitioners
  • Key takeaway: Read the first section for the core framework, then use the specific tactics that match your situation.

Site migrations hemorrhage organic traffic when redirect mapping fails to preserve the link equity topology and indexing signals accumulated over months or years of SEO investment. A comprehensive redirect map functions as the architectural blueprint connecting every URL in the old site structure to its canonical equivalent in the new structure, ensuring search engines seamlessly transfer rankings, authority, and indexing status across the migration boundary without triggering ranking volatility or traffic loss.

This guide scaffolds the complete redirect mapping methodology: URL inventory extraction from the legacy architecture, destination URL identification using semantic mapping algorithms, redirect logic design for pattern-based rules versus individual page mapping, 301 implementation across Apache/Nginx/CDN infrastructure, pre-launch validation protocols, and post-migration monitoring to detect mapping failures before they crystallize into permanent ranking drops.

URL Inventory and Migration Scope Definition

The foundation of redirect mapping is an exhaustive URL inventory of the legacy site architecture. Incomplete inventories guarantee orphaned URLs—pages that receive backlinks or residual traffic but lack redirect rules, returning 404 errors post-migration and immediately hemorrhaging the authority those URLs accumulated. Three primary data sources surface the complete URL corpus: crawl data, server logs, and external backlink profiles.

Screaming Frog SEO Spider provides the most comprehensive crawl-based inventory. Configure a full site crawl with these settings: Configuration → Spider → Limits → disable all limits (unlimited pages, unlimited depth). Enable crawling of all subdirectories, subdomains if the migration encompasses them, and non-HTML resources (PDFs, images) if the migration strategy includes these assets. The resulting crawl exports every URL Googlebot could theoretically discover through internal link traversal.

Export the complete URL list via Bulk Export → Response Codes → All. This generates a CSV containing every URL the spider encountered, regardless of response code. Include 200 OK pages (active content), 301/302 redirects (existing redirect rules that may need updating), 404 errors (broken pages that may still receive external links), and server errors (pages that exist but currently malfunction and need migration mapping).

Server log analysis surfaces URLs invisible to crawlers—pages with no internal links but receiving direct traffic from bookmarks, external links, or historical citations. Parse Apache access logs (typically stored in /var/log/apache2/access.log) or Nginx logs (/var/log/nginx/access.log) using log analysis tools like GoAccess, AWStats, or custom scripts. Extract unique URL paths requested over the past 6-12 months, capturing seasonal content and periodically accessed resources that standard crawls miss.

The extraction command for Apache logs:

awk '{print $7}' /var/log/apache2/access.log | sort | uniq > log-urls.txt

This isolates the seventh field (requested URL path) from each log entry, sorts alphabetically, removes duplicates, and outputs a clean URL list. Cross-reference this log-derived list against the crawl inventory, adding any log-only URLs to the master inventory.

External backlink data identifies orphaned high-value URLs that neither crawls nor logs capture. Export your site's complete backlink profile from Ahrefs, Majestic, Moz, or SEMrush, filtering for only links pointing to your domain. The export should include the destination URL (the page on your site receiving the backlink) and linking domain metrics (Domain Rating, Citation Flow, or Domain Authority).

Sort backlinks by authority metrics descending, then extract unique destination URLs. Any URL receiving backlinks from domains with DR/DA above 30 merits inclusion in the redirect mapping inventory, even if the URL returned 404 in crawl data or appeared absent from logs. These URLs represent accumulated link equity that must redirect to semantically appropriate destinations to preserve authority transfer.

Google Search Console provides an additional validation layer. Navigate to Coverage → Excluded → Not found (404) and export the URL list. These URLs exist in Google's index despite returning 404 errors—evidence of recent deindexing or historical indexing that persists in Search Console reporting. Each indexed 404 demands a redirect rule to prevent search engines from treating the migration as mass content deletion.

Combine all sources—crawl data, log files, backlinks, and Search Console—into a unified master URL inventory. Use spreadsheet tools or database queries to deduplicate, removing redundant entries while preserving source attribution (which URLs came from which source). The final inventory should contain these columns: URL Path, Response Code (from crawl), Traffic Volume (from logs), Backlink Count (from backlink data), and Source Flags indicating whether the URL appeared in crawl/logs/backlinks/GSC.

Scope definition emerges from analyzing the inventory composition. Calculate the proportion of URLs in each category: active content pages (200 status), product/service pages, blog articles, category/taxonomy pages, pagination sequences, resource pages (PDFs, whitepapers), and utility pages (login, checkout, account pages). This distribution informs redirect mapping strategy—whether pattern-based rules can cover entire categories or individual page-by-page mapping is required.

Destination URL Mapping Methodology

Mapping legacy URLs to new site destinations requires semantic equivalence matching—connecting old URLs to new URLs serving functionally identical content, preserving topical relevance, keyword targeting, and user intent. The methodology scales from exact title matching for simple migrations to machine learning semantic similarity for complex restructuring.

Exact match migration occurs when the new site preserves the old site's URL structure with only domain or protocol changes. Example: migrating http://old-domain.com/page to https://new-domain.com/page. The redirect mapping becomes a simple find-replace operation on the domain component. Generate the mapping using spreadsheet formulas:

Old URL: http://old-domain.com/about
New URL: =SUBSTITUTE(A2,"http://old-domain.com","https://new-domain.com")

This formula-based approach scales effortlessly to tens of thousands of URLs, generating the complete redirect map in seconds with zero manual intervention.

Title-based semantic matching applies when URL structures change but page titles remain stable. Export titles from the old site (Screaming Frog: Bulk Export → Page Titles) and new site separately, then join on exact title matches using VLOOKUP or database JOIN queries. URLs sharing identical titles represent semantic equivalents, enabling automated redirect mapping:

SELECT old.url AS old_url, new.url AS new_url
FROM old_site_urls old
INNER JOIN new_site_urls new ON old.title = new.title

This SQL query returns paired old and new URLs where titles match exactly, covering typically 60-80% of standard migrations without manual intervention.

Content-based similarity scoring handles cases where titles changed but content remains semantically equivalent. Export the meta descriptions or H1 headings from both old and new sites, then calculate string similarity using Levenshtein distance or cosine similarity algorithms. Pairs scoring above 80% similarity threshold represent probable matches requiring human validation.

Python implementation using fuzzywuzzy library:

from fuzzywuzzy import fuzz

for old_url, old_desc in old_site_descriptions.items():
    best_match = None
    best_score = 0
    for new_url, new_desc in new_site_descriptions.items():
        score = fuzz.ratio(old_desc, new_desc)
        if score > best_score:
            best_score = score
            best_match = new_url
    if best_score > 80:
        redirect_map[old_url] = new_match

This loop compares each old URL's description against all new URLs, identifying the highest-scoring match and mapping old to new when similarity exceeds 80%.

Category and taxonomy mapping applies to hierarchical site structures. If the old site organized products under /category/subcategory/product and the new site uses /products/category/product, extract the category components from both URL patterns, map equivalent categories, then reconstruct new URLs using the mapped categories.

For e-commerce migrations, SKU or product ID matching provides definitive equivalence. If old URLs contain product SKUs (/products/widget-abc-123) and new URLs use the same SKUs, extract the SKU from old URLs using regex, then search new site URLs for matching SKUs to establish the mapping.

Regex extraction in spreadsheet:

=REGEXEXTRACT(A2,"-([A-Z0-9-]+)$")

This extracts the trailing SKU component after the last hyphen, enabling VLOOKUP against a new site URL list with similar SKU extraction applied.

Manual mapping workflow becomes necessary for content consolidation, restructuring, or deletion scenarios. When multiple old URLs consolidate into a single new URL (merging several blog posts into a comprehensive guide), the redirect mapping must direct all legacy URLs to the consolidated destination. Create a manual mapping worksheet with columns: Old URL, New URL, Mapping Type (1:1, many:1, deleted), and Notes justifying consolidation decisions.

For deleted content with no semantic equivalent in the new site, identify the most relevant alternative destination. Never redirect deleted pages to the homepage—this dilutes link equity across an overly broad target and degrades user experience. Instead, redirect to the nearest topical equivalent: deleted product pages redirect to the relevant category page, deleted blog posts redirect to the blog index or topically related surviving article.

Wildcard pattern-based mapping scales efficiently for predictable URL transformations. If all old blog URLs follow /blog/yyyy/mm/dd/post-title/ and new URLs use /articles/post-title/, implement a pattern-based redirect rule that extracts the post slug and reconstructs the new URL dynamically:

RedirectMatch 301 ^/blog/[0-9]{4}/[0-9]{2}/[0-9]{2}/(.+)$ https://newdomain.com/articles/$1

This Apache regex rule captures the post slug ((.+)) and substitutes it into the new URL structure, covering all historical blog posts with a single redirect rule rather than thousands of individual mappings.

Redirect Logic Design and Rule Hierarchy

Redirect rule architecture demands hierarchical logic—broad pattern-based rules handling predictable transformations, layered beneath granular individual URL mappings for exceptions. Proper hierarchy prevents rule conflicts where multiple rules could theoretically match a single URL, causing undefined behavior or redirect chains.

Rule execution order varies by server platform. Apache processes redirect rules sequentially from top to bottom in .htaccess files, applying the first matching rule unless the [L] (Last) flag instructs termination. Nginx processes location blocks by specificity, prioritizing exact matches over regex matches over prefix matches. Understanding platform-specific execution prevents unintended rule interactions.

Structure redirect hierarchies using this priority sequence:

  1. Protocol enforcement (HTTP → HTTPS)
  2. Domain canonicalization (www vs non-www)
  3. Trailing slash normalization
  4. Individual page-level redirects (highest specificity)
  5. Wildcard pattern rules (lower specificity)
  6. Fallback catch-all (category or homepage redirect)

This ordering ensures protocol and domain corrections execute first, establishing the canonical domain/protocol context before page-level redirects. Individual page redirects take precedence over patterns, allowing exceptions to override general rules when specific mappings require it.

Apache .htaccess example with proper hierarchy:

RewriteEngine On

# 1. Force HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

# 2. Force www
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

# 3. Individual page redirects
Redirect 301 /old-specific-page https://www.example.com/new-specific-page
Redirect 301 /another-old-page https://www.example.com/another-new-page

# 4. Pattern-based redirects
RedirectMatch 301 ^/blog/[0-9]{4}/[0-9]{2}/[0-9]{2}/(.+)$ https://www.example.com/articles/$1

# 5. Deleted category fallback
RedirectMatch 301 ^/old-category/(.*)$ https://www.example.com/new-category/

The [L] flag on protocol and domain rules prevents further processing after those foundational redirects execute, forcing the browser to make a new request that then processes through subsequent rules.

Nginx configuration requires different syntax but identical hierarchical principles:

server {
    listen 80;
    server_name example.com www.example.com;

    # 1. Force HTTPS
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;

    # 2. Force www
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name www.example.com;

    # 3. Individual exact matches
    location = /old-specific-page {
        return 301 https://www.example.com/new-specific-page;
    }

    # 4. Pattern-based redirects
    location ~ ^/blog/[0-9]{4}/[0-9]{2}/[0-9]{2}/(.+)$ {
        return 301 https://www.example.com/articles/$1;
    }

    # 5. Prefix matches for deleted categories
    location ^~ /old-category/ {
        return 301 https://www.example.com/new-category/;
    }
}

Nginx separates protocol and domain enforcement into distinct server blocks, providing cleaner separation than Apache's conditional logic approach.

CDN-level redirect implementation offers performance advantages by handling redirects at edge nodes before requests reach origin servers. Cloudflare, Fastly, AWS CloudFront, and similar services provide redirect rule configuration in their management interfaces. Implement identical hierarchical logic at the CDN layer, ensuring protocol and domain rules execute before page-level redirects.

Cloudflare Page Rules example:

  1. Rule 1: http://example.com/* → Always Use HTTPS
  2. Rule 2: http://www.example.com/* → Always Use HTTPS
  3. Rule 3: https://example.com/* → 301 redirect to https://www.example.com/$1
  4. Rules 4-N: Individual URL redirects via Bulk Redirects feature

Cloudflare's Bulk Redirects feature (available on Pro and higher plans) accepts CSV uploads of redirect mappings, scaling to 100,000+ individual rules without performance degradation.

Query parameter preservation requires explicit configuration in redirect rules. When redirecting /old-page?param=value, ensure the rule preserves query strings to maintain tracking parameters, session IDs, or functional parameters:

Redirect 301 /old-page https://www.example.com/new-page  # Query strings preserved automatically

Apache's Redirect directive preserves query strings by default. For RewriteRule, append the [QSA] (Query String Append) flag:

RewriteRule ^old-page$ https://www.example.com/new-page [R=301,L,QSA]

Fragment identifiers (anchor links like #section) are not transmitted to servers, so server-side redirects cannot preserve them. When migration changes page structure such that old fragment IDs no longer match, implement client-side JavaScript on destination pages to detect and remap fragments:

if (window.location.hash === '#old-section-id') {
    window.location.hash = '#new-section-id';
}

Implementation Across Server Architectures

Redirect implementation methods vary dramatically across hosting environments, from direct server configuration file editing to CMS plugin interfaces to programmatic API-based deployment for enterprise CDN networks.

Apache shared hosting typically restricts access to server configuration files, limiting redirect implementation to .htaccess files in the site's document root. Create or edit .htaccess in the root directory (public_html/, www/, or htdocs/ depending on host):

# Redirect rules for site migration
# Implemented: 2026.02.08

Redirect 301 /old-page-1 https://newdomain.com/new-page-1
Redirect 301 /old-page-2 https://newdomain.com/new-page-2
# ... continue for all individual mappings

For large redirect maps (1,000+ rules), .htaccess file size can impact server performance. Monitor memory usage and consider moving redirects to the main httpd.conf configuration file if you have server admin access—this loads redirects into memory once at server start rather than parsing .htaccess on every request.

Nginx server block configuration provides superior performance for large rule sets. Edit the site's configuration file (typically /etc/nginx/sites-available/yourdomain.com) and add redirect rules within the appropriate server block:

server {
    listen 443 ssl;
    server_name www.newdomain.com;

    # Individual redirects
    location = /old-page-1 { return 301 https://newdomain.com/new-page-1; }
    location = /old-page-2 { return 301 https://newdomain.com/new-page-2; }

    # Pattern-based redirects
    location ~ ^/old-category/(.+)$ { return 301 https://newdomain.com/new-category/$1; }
}

After editing, validate configuration syntax (nginx -t) before reloading (nginx -s reload) to prevent server errors from malformed rules.

WordPress migrations benefit from redirect plugins that provide GUI-based rule management. Redirection (free plugin with 2M+ installations) offers the most robust feature set: bulk imports via CSV, redirect hit logging, 404 monitoring, and regex pattern support. Install via Plugins → Add New, then navigate to Tools → Redirection → Import/Export.

Prepare redirect CSV in this format:

source,target,type
/old-page-1,https://newdomain.com/new-page-1,301
/old-page-2,https://newdomain.com/new-page-2,301

Upload the CSV via Import → CSV → Upload, then verify imported rules appear in the main redirects list. Redirection stores rules in the WordPress database, handling execution via PHP before WordPress loads—less performant than server-level redirects but dramatically more accessible for non-technical users.

Shopify platform migrations use the built-in URL Redirects feature (Online Store → Navigation → URL Redirects). Shopify accepts CSV bulk uploads with this format:

Redirect from,Redirect to
/products/old-product,/products/new-product
/collections/old-collection,/collections/new-collection

Upload via Import, then review imported redirects. Shopify limits redirects to the first 10,000 rules in free plans; Shopify Plus accounts support significantly more. For migrations exceeding limits, consider Shopify's API for programmatic redirect creation.

JavaScript-based redirects serve as absolute last resort when server-side implementation is impossible (static hosting without redirect support, legacy systems locked down). Implement via <meta> refresh tags or JavaScript:

<script>
window.location.href = "https://newdomain.com/new-page";
</script>

Search engines follow JavaScript redirects but treat them as inferior signals compared to 301 server redirects. Link equity transfer is less reliable, and crawl efficiency degrades. Use only when no server-side alternative exists.

Enterprise CDN deployment via API enables automated redirect rule provisioning at scale. Cloudflare's Bulk Redirects API accepts JSON payloads:

curl -X POST "https://api.cloudflare.com/client/v4/accounts/{account_id}/rules/lists/{list_id}/items" \
  -H "Authorization: Bearer {api_token}" \
  -H "Content-Type: application/json" \
  --data '[
    {"redirect": {"source_url": "example.com/old-page", "target_url": "https://newdomain.com/new-page", "status_code": 301}}
  ]'

Script this API interaction to loop through your redirect map CSV, programmatically creating thousands of redirect rules in minutes.

Pre-Launch Validation and Testing Protocol

Pre-launch validation prevents redirect mapping failures from reaching production, where they immediately hemorrhage traffic and authority. Comprehensive testing covers redirect rule syntax, destination URL accuracy, redirect chain prevention, and performance impact measurement.

Staging environment deployment enables risk-free validation. Provision a staging server or subdomain (staging.newdomain.com) replicating production server configuration, deploy redirect rules, then systematically test without affecting live traffic. Configure staging DNS to point to the staging server, ensuring tests don't accidentally redirect production traffic.

Redirect testing tools automate validation across the complete redirect map. Screaming Frog SEO Spider functions as the primary validation tool. Import your redirect map CSV, then use List Mode to test redirects:

  1. Configuration → Mode → List
  2. Upload CSV containing all old URLs (source URLs from your redirect map)
  3. Configuration → Spider → Crawl → Enable "Check Redirects" and "Always Follow Redirects"
  4. Start crawl

Screaming Frog requests each old URL, follows the redirect sequence, and logs the final destination. Export results via Bulk Export → Redirect Chains, then compare the "Final Destination" column against your redirect map's intended destination URLs. Discrepancies indicate implementation errors—incorrect destination URLs, typos in rules, or missing redirect rules entirely.

HTTP status code validation ensures 301 permanent redirects rather than 302 temporary redirects were implemented. Filter Screaming Frog results by status code, verifying all redirects return 301 rather than 302. 302 redirects signal temporary moves, potentially delaying link equity transfer and indexing consolidation.

Redirect chain detection during validation prevents multi-hop redirects from reaching production. Review Screaming Frog's Redirect Chains report (Response Codes → Filter → Redirect Chains). Any old URL appearing in this report indicates the destination URL is itself a redirect, creating a chain. Remediate by updating the redirect rule to point directly to the final destination URL.

Command-line testing provides lightweight validation for spot-checking critical redirects. Use curl with -I flag to fetch headers without downloading content:

curl -I https://olddomain.com/important-page

Output displays HTTP status code and Location header showing redirect destination:

HTTP/1.1 301 Moved Permanently
Location: https://newdomain.com/new-important-page

Script this for batch validation across high-priority URLs:

while IFS=, read -r old_url new_url; do
  actual=$(curl -Ls -o /dev/null -w '%{url_effective}' "$old_url")
  if [ "$actual" != "$new_url" ]; then
    echo "FAIL: $old_url → $actual (expected $new_url)"
  fi
done < redirect-map.csv

This bash script loops through redirect map CSV, fetches the final destination using curl, and reports any mismatches between expected and actual destinations.

Performance impact testing measures redirect latency and server resource consumption. Use Apache Bench or wrk to load test the server with redirect requests:

ab -n 1000 -c 10 https://olddomain.com/redirected-page

This sends 1,000 requests with 10 concurrent connections, measuring requests per second and response time. Compare redirect response times against direct (non-redirected) page responses. Single-hop redirects should add minimal latency (<50ms); excessive latency indicates server configuration issues or resource constraints.

Browser-based testing validates user experience and client-side behavior. Open key redirect URLs in browser DevTools with Network tab enabled, verifying:

Test across multiple browsers (Chrome, Firefox, Safari) and devices (desktop, mobile) to surface browser-specific redirect handling differences.

Google Search Console validation provides search engine perspective. Add both old domain and new domain to Search Console, then implement redirects and request crawling of high-priority old URLs. Monitor Search Console for redirect-related errors in Coverage reports, which would indicate Google encountered issues following redirects.

Post-Migration Monitoring and Adjustment

Post-migration monitoring detects redirect failures manifesting as traffic drops, ranking volatility, or increased 404 errors. Immediate response protocols minimize authority loss and traffic hemorrhage before failures crystallize into permanent ranking degradation.

Google Analytics traffic comparison establishes baseline metrics. Compare traffic week-over-week and year-over-year for:

Segment by traffic source (Organic, Direct, Referral) to isolate migration impact. If organic traffic drops but referral traffic remains stable, the issue resides in SEO implementation rather than general site availability.

Google Search Console monitoring surfaces indexing issues invisible in Analytics. Track these metrics daily for 30 days post-migration:

Navigate to Coverage → Excluded → Expand error categories. Any spike in "Not found (404)" errors represents old URLs receiving traffic but returning errors rather than redirecting—immediate redirect map gaps requiring emergency fixes.

Server log analysis exposes 404 errors before they accumulate enough volume to surface in Search Console. Parse logs daily post-migration, extracting 404 status codes:

grep ' 404 ' /var/log/apache2/access.log | awk '{print $7}' | sort | uniq -c | sort -rn

This command isolates 404 requests, counts occurrences, and sorts by frequency. URLs appearing repeatedly represent high-impact redirect map gaps. Cross-reference against your redirect map to identify missing rules, then implement emergency redirects for these URLs.

Rank tracking tools (Ahrefs, SEMrush, Moz, SERPWatcher) detect ranking position changes for target keywords. Configure tracking for:

Ranking drops >3 positions for multiple keywords signals systematic issues—poor destination mapping, redirect chains, or new site technical problems requiring immediate investigation.

Backlink monitoring ensures external links continue resolving correctly post-migration. Export your backlink profile from Ahrefs or Majestic post-migration, filtering for links to old domain URLs. Run these URLs through your redirect validator to confirm backlinks correctly traverse redirects to new domain destinations.

Contact high-authority linking domains for manual link updates when feasible. While redirects preserve most link equity, direct links eliminate redirect latency and guarantee permanent equity transfer. Prioritize outreach for links from DR/DA 50+ domains pointing to your most valuable pages.

Redirect hit logging via WordPress plugins or server logs quantifies redirect usage over time. Redirection plugin's Logs feature records every redirect execution, showing which old URLs still receive traffic weeks or months post-migration. URLs with sustained redirect traffic (100+ hits monthly) merit manual internal link updates to eliminate redirect dependence.

Incremental redirect map updates address discovered gaps. Maintain the redirect map as a living document, adding newly discovered old URLs requiring redirects as they surface through 404 monitoring, log analysis, or user reports. Document each addition with discovery date and source to inform future migration planning.

Advanced Migration Scenarios and Edge Cases

Complex migrations introduce scenarios requiring specialized redirect mapping approaches beyond standard one-to-one URL replacement.

Multi-domain consolidation merging several domains into one demands careful redirect mapping preserving topical relevance. When consolidating domain-a.com, domain-b.com, and domain-c.com into unified-domain.com, map each old domain's URLs to semantically appropriate sections of the unified site:

This preserves topical clustering and prevents link equity dilution across overly broad destinations.

Subdomain to subdirectory migrations (blog.example.com → example.com/blog/) require protocol and domain changes in redirects:

RedirectMatch 301 ^/(.*)$ https://example.com/blog/$1

Place this rule in the blog.example.com virtual host configuration, redirecting all subdomain URLs to their subdirectory equivalents on the main domain.

Protocol migrations without URL structure changes (HTTP → HTTPS only) still require redirect mapping to preserve query parameters and fragments. Implement HTTPS enforcement globally:

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

This catches all HTTP requests regardless of path, redirecting to HTTPS equivalent while preserving the full URI including query strings.

International site migrations with hreflang implementations require redirect mapping preserving language targeting. When migrating example.com/es/ to es.example.com, ensure redirects maintain language context and update hreflang annotations in the new site to reference new URL structures.

Parameter-based dynamic URLs (example.com/page?id=123) may not have direct equivalents if the new site uses clean URLs (example.com/page-name). Extract parameters from old URLs, query the new site's database for corresponding content IDs, then generate redirect mappings using the discovered new URLs:

SELECT
    CONCAT('https://oldsite.com/page?id=', old.id) AS old_url,
    CONCAT('https://newsite.com/', new.slug) AS new_url
FROM old_database.products old
INNER JOIN new_database.products new ON old.sku = new.sku

This SQL join maps old parameter-based URLs to new slug-based URLs via shared SKU identifiers.

Content deletion with 410 Gone responses applies when pages are permanently removed with no semantic equivalent. For truly deleted content receiving minimal traffic and backlinks, implement 410 status codes rather than redirecting to loosely relevant pages:

Redirect 410 /permanently-deleted-page

The 410 Gone status signals permanent removal, helping search engines purge the URL from indexes faster than 404 errors while preventing forced redirects to irrelevant destinations that degrade user experience.

FAQ: Site Migration Redirect Mapping

How long should I maintain redirects after migration? Maintain redirects indefinitely if possible. While most link equity transfers within weeks, external sites may update links slowly or never, and users may access bookmarks years later. If server constraints require redirect removal, maintain for minimum 12 months before considering deletion.

Should I redirect all 404s found in Google Search Console? No. Review each 404 for relevance and traffic. Redirect only URLs receiving organic traffic, backlinks, or indexed status. Orphaned test pages, admin URLs, or spam URLs appearing in 404 reports should remain as 404s rather than waste redirect resources.

Can I use 302 temporary redirects during migration testing? Avoid 302 redirects even during testing. Search engines may index redirected content under the temporary redirect, delaying final indexing consolidation. Use 301 permanent redirects in staging environments, or block search engines entirely from staging via robots.txt or password protection.

Do redirects pass anchor text relevance to destination pages? Yes. Redirects preserve the anchor text of incoming links, passing both link equity and anchor text relevance signals to destination URLs. This makes accurate semantic destination mapping critical—irrelevant destinations dilute anchor text relevance even while preserving raw authority.

How do I handle pagination after migration? If new site uses different pagination parameters (?page=2 vs /page/2/), implement pattern-based redirects extracting the page number and reconstructing new pagination URLs. Ensure rel="next" and rel="prev" tags in new site reference new pagination URL formats.

Should I redirect images and media files? Yes if they receive backlinks or traffic. Export image URLs from old site crawl data, check backlink profiles for image links, then redirect valuable images to their new locations. This preserves image search rankings and external hotlinks embedded on third-party sites.

What's the impact of redirect speed on SEO? Slow redirects (>200ms response time) compound with destination page load time, degrading Core Web Vitals. CDN-based redirects executing at edge nodes minimize latency. Server-level redirects should complete in <50ms; WordPress plugin redirects may add 50-100ms due to PHP execution overhead.

How do I preserve UTM parameters through redirects? Apache Redirect and RewriteRule directives preserve query strings automatically. Nginx requires explicit $args inclusion in redirect destinations: return 301 https://newsite.com/page$is_args$args;. Test with a redirected URL containing UTM parameters to verify preservation.

Can I redirect a domain without changing nameservers first? Yes using hosts file testing. Edit your local hosts file to point old domain to new server IP, then test redirects locally before DNS cutover. This validates redirect logic without exposing the incomplete migration to search engines or users.

When This Fix Isn't Your Priority

Skip this for now if:

Frequently Asked Questions

How long does this fix take to implement?

Most fixes in this article can be implemented in under an hour. Some require a staging environment for testing before deploying to production. The article flags which changes are safe to deploy immediately versus which need QA review first.

Will this fix work on WordPress, Shopify, and custom sites?

The underlying SEO principles are platform-agnostic. Implementation details differ — WordPress uses plugins and theme files, Shopify uses Liquid templates, custom sites use direct code changes. The article focuses on the what and why; platform-specific how-to links are provided where available.

How do I verify the fix actually worked?

Each fix includes a verification step. For most technical SEO changes: check Google Search Console coverage report 48-72 hours after deployment, validate with a live URL inspection, and monitor the affected pages in your crawl tool. Ranking impact typically surfaces within 1-4 weeks depending on crawl frequency.

This is one piece of the system.

Built by Victor Romo (@b2bvic) — I build AI memory systems for businesses.

See The Full System View Repo
← All Fixes