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:
| Old URL | New URL | Status | Priority |
|---|---|---|---|
| /blog/2020/01/old-slug | /articles/old-slug | 301 | high |
| /category/news | /blog/news | 301 | high |
| /wp-content/uploads/img.jpg | /media/img.jpg | 301 | medium |
| /contact-us | /contacts | 301 | high |
| /product/old-name | /shop/new-name | 301 | high |
| /old-promo-page | (empty) | 410 | low |
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
| Method | Throughput (requests/sec) | Maintenance Complexity | Flexibility |
|---|---|---|---|
| Nginx map directive | 15,000+ | Low | Medium |
| Apache RewriteRule | 5,000–7,000 | Medium | High |
| Cloudflare Page Rules | 10,000+ | Low | Limited |
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.







