URL Mapping and 301 Redirect Setup for Site Migration

URL Mapping and 301 Redirect Setup During Migration

When migrating a site to a new engine or domain, every old URL left without a 301 redirect is lost traffic. A mapping error can crash rankings overnight. For an e-commerce store with 10,000 pages, missing just 5% of redirects reduces organic traffic by 15–25% in the first weeks. We create a precise redirect map and automate the setup for your stack—whether Nginx, Apache, or Cloudflare. This saves up to 40% of the SEO recovery budget and avoids prolonged downtime.

What Problems Does URL Mapping Solve?

Without properly configured redirects, a site loses up to 30% of organic traffic in the first weeks after migration. Users and search bots encounter 404 errors, increasing bounce rates and worsening Core Web Vitals. The link equity of old URLs is not transferred to new addresses, causing rankings to drop. Google Search Console shows thousands of "Crawled – currently not indexed" errors. Even a single missed redirect on a high-traffic page can cost hundreds of visitors per day.

Google Search Central recommends keeping redirects for at least 6 months. We go further: after deployment, we monitor logs and GSC for an additional 2–4 weeks to catch anomalies early. With over 5 years of experience and more than 50 migrations completed, we guarantee that no old URL with traffic remains without a redirect.

How We Create the Redirect Map

The process starts with a full crawl of the old site. We use Screaming Frog or wget to collect all URLs. Then we map them to the new structure using several strategies:

• Slug transformation rules: If only the prefix changed (e.g., /2020/01/ → /articles/), we apply regular expressions.
• Manual mapping for changed pages: For renamed categories, products, contact pages.
• Automatic generation from sitemap or database: Import old URLs from CMS.

All redirects are consolidated into a single table—a single source of truth:

Status 410 (Gone) for deleted pages is preferable to 404, as it signals permanent removal.

How to Set Up 301 Redirects in Nginx?

For servers on Nginx, we generate configuration using the map directive. This is a high-performance solution—the map directive works 3 times faster than a chain of ifs or using rewrite with regular expressions. Example automatic generation:

import csv, re

def generate_nginx_map(mapping_csv, output_file):
    lines = ['# Auto-generated redirects',
             'map $request_uri $redirect_target {',
             '    default "";',
             '    hostnames;']
    with open(mapping_csv) as f:
        for row in csv.DictReader(f):
            old = row['old_url'].rstrip('/')
            new = row['new_url']
            code = row.get('status_code', '301')
            if code == '410':
                continue
            lines.append(f'    "~^{re.escape(old)}$"  "{new}";')
            if old != '/':
                lines.append(f'    "~^{re.escape(old)}/$"  "{new}";')
    lines.append('}')
    with open(output_file, 'w') as f:
        f.write('\n'.join(lines))

In the Nginx config, we include the map and handle redirects:

include /etc/nginx/redirect_map.conf;

server {
    listen 80;
    server_name site.com www.site.com;
    if ($redirect_target != "") {
        return 301 $redirect_target;
    }
    location ~* ^/(old-promo|deleted-category) {
        return 410;
    }
}

Why Redirect Verification Matters?

After deploying the config, every URL must redirect correctly. According to 301 redirect, each redirect should return the proper status and Location. We use a script that walks through the CSV mapping and verifies status codes and headers.

import requests

def verify_redirects(mapping_csv, base_url):
    errors = []
    with open(mapping_csv) as f:
        for row in csv.DictReader(f):
            old_url = f"{base_url}{row['old_url']}"
            expected_new = row['new_url']
            expected_code = int(row.get('status_code', 301))
            resp = requests.get(old_url, allow_redirects=False)
            if expected_code in (301, 302):
                if resp.status_code != expected_code:
                    errors.append(f"Expected {expected_code}, got {resp.status_code}: {old_url}")
                elif not resp.headers.get('Location', '').endswith(expected_new):
                    errors.append(f"Wrong target: {old_url} → {resp.headers.get('Location')}, expected {expected_new}")
            elif expected_code == 410 and resp.status_code != 410:
                errors.append(f"Expected 410, got {resp.status_code}: {old_url}")
    return errors

A common mistake is forgetting a trailing slash. The script automatically checks both versions (with and without /), so we catch such issues before deployment.

Redirect Performance Comparison

How to Guarantee Migration Success?

We use additional Google Search Console monitoring for 2–4 weeks after launch. We track spikes in 404 errors and pages excluded from the index. If new 404s appear, we quickly add missing redirects. We also recommend keeping the old sitemap and checking its full coverage with redirects.

How Long Does Setup Take?

For a site with up to 1,000 URLs, creating the mapping, generating the config, and verification takes 2 to 5 business days. The cost is calculated individually—depending on the structure complexity and need for manual mapping. The investment pays off within 2–3 months through preserved traffic.

Why Order This Service from Us?

We have completed over 50 site migrations across different CMS—WordPress, Laravel, Django, 1C-Bitrix. Our engineers have over 5 years of experience with redirects on high-load projects. We provide a guarantee: if any missed redirects are found after deployment, we fix them free of charge within a month.

Contact us for a free scope assessment. Get migration advice, and we will prepare a preliminary mapping for your project.

Website Redesign and Migration: CMS Change, SEO Preservation

A client came to us 6 weeks after a self-attempted redesign: 'We moved from WordPress to Tilda, traffic dropped by 70%.' I opened Google Search Console — 847 pages returned 404, the URL structure had completely changed, not a single 301 redirect was in place. Yandex hadn't reindexed the new site yet, positions collapsed. Recovery took 4 months and resulted in significant revenue loss for the quarter. Our experience — over 7 years and 80+ successful migrations, we guarantee position retention with the right approach.

Why Do Migrations Break SEO?

Search engines have indexed specific URLs. If /catalog/shoes/nike-air-max-270 turned into /products/nike-air-max-270 without a 301 redirect — all the link equity, traffic, and rankings go nowhere. Google says 301 passes ~99% of PageRank, but in practice positions recover over 2–8 weeks, not instantly.

Commonly, SEO gets broken not out of malice, but because a developer doesn't view the URL structure as a public API. Here are typical breakages:

How to Recover Traffic After a Failed Migration?

If traffic dropped, act immediately:

1. Crawl the new site for 404s and compare with the pre-migration URL list.
2. Create redirects for all lost pages with traffic >0.
3. Check structured data and meta tags on a test sample.
4. Daily monitor Coverage in Search Console and positions for top 50 queries.
5. If after 2 weeks traffic does not recover — deep audit of redirects (transitivity, chains, loops).

In our practice, a large e-commerce site lost 50% of traffic when moving from Bitrix to React + Strapi. We restored 95% of redirects in three days, and within 3 weeks traffic returned to 90% of original.

What Does a Pre-Migration Audit Include?

Before starting development on the new site:

1. Full crawl of current site via Screaming Frog or Sitebulb. Get list of all indexable URLs with traffic from Google Search Console.
2. Export all pages with organic traffic >0 over the last 6 months — these are priority for redirects.
3. Record all external backlinks to specific pages — Ahrefs, Semrush.
4. Snapshot current positions for key queries — baseline for post-migration comparison.
5. Save Core Web Vitals from Search Console for the previous 90 days.

Table for recording:

Contact us for a detailed pre-migration audit — we will help identify all risks and create an action plan.

URL Mapping and Redirects

For projects with 200+ pages, we create a mapping table: old URL → new URL → status (301, merged with another page, deleted). Each row is verified: does the content actually migrate here?

In Laravel, redirects are handled via configuration file and middleware, not .htaccess — faster and more manageable. For WordPress → Next.js: redirects are set in next.config.js (static) and at the Nginx/CDN level for dynamic ones. Old .htaccess on shared hosting with 500+ lines of redirects is a special hell. Each redirect is checked sequentially, performance suffers. We move to Nginx map directive or Redis cache for dynamic lookup. More at Wikipedia: HTTP 301.

How to Migrate Content from Different CMSs?

WordPress → Headless CMS (Contentful, Strapi, Sanity): WordPress REST API or WP All Export to export posts, meta fields, media files. Migration script in Node.js: parse export, transform structure, upload via CMS API. Media files are reuploaded to new storage, links updated in content. Typical problem — shortcodes in WordPress content ([gallery id="123"]): need parser and transformation to new format.

1C-Bitrix → modern stack: Bitrix stores content in non-standard tables with IBLOCK_ELEMENT_PROPERTY. Direct SQL export via phpMyAdmin or Bitrix API. Transformation is the longest part due to specific Bitrix data structure.

Heavy WYSIWYG → structured content: Years of editing in FCKEditor/TinyMCE leave inline styles, non-standard tags, broken attributes. HTML sanitize + transformation to Markdown or Portable Text (Sanity) with manual check of problematic pages.

How to Preserve Technical SEO Elements During Migration?

Structured data (Schema.org) — if the old site had Product, Article, BreadcrumbList markup, they must be on the new site too. Google Search Console → Enhancement reports will show loss of rich snippets.

Sitemap XML: generated automatically, submitted to GSC a day after launch. Old sitemap remains until full reindexing.

hreflang for multilingual sites: if tags are lost during migration, conflicts between language versions in search results will start within weeks.

Open Graph and Twitter Card meta tags — often forgotten when changing template, pages stop displaying correctly when shared on social networks.

Launch and First Weeks Monitoring

DNS propagation: DNS switching takes up to 48 hours, plan launch with buffer. Cloudflare as DNS provider — propagation takes minutes, not hours.

After launch, monitor daily: Search Console → Coverage (indexing errors), Analytics → organic traffic, year-over-year comparison, crawl site for 404 errors.

First 2 weeks are critical. If traffic drops more than 30% — immediate audit of redirects and comparison with pre-migration crawl.

What the Service Includes

Results you receive:

1. Migration plan with URL mapping and redirects in Excel/Google Sheets format.
2. Configured 301 redirects at server level (Nginx/Cloudflare/Vercel).
3. Migrated content with integrity check: images, meta fields, links.
4. Structured data (Schema.org) on the new site, identical to old or improved.
5. SEO report: position trend at 1, 3, and 6 weeks after launch.
6. Coverage monitoring in Search Console with error notifications.
7. Guaranteed position retention: if traffic drops more than 15% within the first month — free audit and correction.

Timelines and Estimates

• Redesign with migration for a small site (up to 100 pages): 4–8 weeks.
• E-commerce migration with 500+ product pages: 8–16 weeks.
• Only technical migration part (redirects, metadata) without redesign: 1–3 weeks.

Cost is calculated individually based on scope.

Get a consultation for your project — we will respond within a day. Order a pre-migration audit of your site and receive a detailed proposal with a redirect plan. Contact us to discuss details.