I've reviewed hundreds of website redesign RFPs over the years. Most of them are terrible. They obsess over color palettes and hero image animations while completely ignoring the thing that will tank their organic traffic: migration scope and SEO preservation. The result? A shiny new website that loses 30-60% of its search traffic within weeks of launch.

This isn't theoretical. We've been hired multiple times to fix redesigns that went sideways because the original RFP didn't include a single line about redirect mapping, URL structure preservation, or Core Web Vitals targets. One client lost $2.3M in annual organic revenue because their previous agency treated SEO as an afterthought.

If you already know you need help and want to skip ahead, submit your RFP and we'll review it with an SEO-first lens.

Here's the RFP template I wish every organization would use when planning a website redesign in 2026. It's built from real projects, real failures, and real recoveries.

Table of Contents

Why Most Redesign RFPs Fail at SEO

The typical redesign RFP reads like a wishlist for a design agency. It'll have pages about brand guidelines, stakeholder approval workflows, and mobile responsiveness. All important things. But SEO preservation? Maybe a bullet point that says "maintain current search rankings" with zero specifics on how.

Here's what goes wrong:

  • No baseline audit requirement. You can't preserve what you haven't measured. If your RFP doesn't require a pre-migration SEO audit, you're flying blind.
  • URL structure treated as a design decision. Information architects change URLs to match the new navigation without realizing they're breaking thousands of indexed pages.
  • Redirect mapping is an afterthought. It gets crammed into the last two weeks before launch, done by a junior dev with a spreadsheet.
  • No post-launch monitoring plan. The agency launches, celebrates, and moves on. Meanwhile, your rankings are cratering.

A 2025 study by Ahrefs found that 74% of websites that underwent a major redesign experienced significant organic traffic loss, with the average recovery time being 6-12 months. For sites that included detailed SEO migration specs in their RFP, that number dropped to 21%.

The difference isn't luck. It's planning.

The Complete RFP Template Structure

Here's an overview of what a proper redesign RFP should contain when SEO preservation is a priority:

Section Purpose Typical Page Count
Project Overview Business context, goals, KPIs 2-3 pages
Technical Migration Scope Platform, hosting, infrastructure 3-5 pages
SEO Preservation Requirements Redirects, schema, indexation 4-6 pages
Content Migration Specs Content types, taxonomy, metadata 3-4 pages
Performance Targets Core Web Vitals, load times 2-3 pages
Vendor Evaluation Criteria Scoring rubric, references 2-3 pages
Timeline & Acceptance Milestones, QA criteria 2-3 pages
Total 18-27 pages

Yes, it's more than most organizations write. That's the point. Every page you skip here costs you months of traffic recovery later.

Section 1: Project Overview and Business Context

This is where you set the stage. Don't just describe what you want. Explain why you're redesigning and what success looks like in measurable terms.

What to Include

## 1. Project Overview

### 1.1 Organization Background
- Company description, industry, target audience
- Current website URL and technology stack
- Annual organic traffic (sessions, users, revenue attribution)

### 1.2 Redesign Objectives (Ranked by Priority)
1. [e.g., Improve conversion rate from organic traffic by 25%]
2. [e.g., Reduce page load time to under 2 seconds]
3. [e.g., Migrate from WordPress to headless CMS architecture]
4. [e.g., Preserve 95%+ of current organic search traffic]

### 1.3 Success Metrics
- Organic traffic within 90 days of launch: ≥95% of pre-launch baseline
- Core Web Vitals: All pages passing on mobile and desktop
- Indexed pages: 100% of target pages indexed within 60 days
- Conversion rate: ≥ current baseline within 90 days

### 1.4 Budget Range
- Total project budget: $XX,000 - $XX,000
- Ongoing maintenance budget (monthly): $X,000 - $X,000

The critical thing here: put that organic traffic preservation metric right in the objectives. Make it a contractual obligation, not a nice-to-have. If a vendor reads your RFP and doesn't see SEO mentioned until page 15, they'll staff the project accordingly -- without SEO expertise.

Section 2: Technical Migration Scope

This section defines the boundaries of what's changing. Be explicit about the current state and desired end state.

Platform and Architecture Requirements

## 2. Technical Migration Scope

### 2.1 Current State
- CMS: [e.g., WordPress 6.x with WooCommerce]
- Hosting: [e.g., WP Engine, Growth plan]
- CDN: [e.g., Cloudflare Pro]
- Total pages: [e.g., 4,200 indexed pages per Google Search Console]
- Total URLs (including parameters): [e.g., ~12,000]
- Third-party integrations: [list all]

### 2.2 Desired End State
- CMS: [e.g., headless CMS (Sanity, Contentful, or equivalent)]
- Frontend: [e.g., Next.js or Astro with SSR/SSG]
- Hosting: [e.g., Vercel, Netlify, or AWS]
- CDN: [e.g., Vercel Edge Network or Cloudflare]

### 2.3 Migration Type
- [ ] Same domain, same platform (visual redesign only)
- [ ] Same domain, new platform (re-platform)
- [ ] Domain change + new platform (highest risk)
- [ ] Subdomain consolidation

If you're considering a move to headless architecture -- which is increasingly common for performance-focused redesigns -- you'll want a vendor experienced with that transition. We've written extensively about our approach to headless CMS development and the specific SEO considerations it involves.

Infrastructure Specifications

Include server-side rendering requirements, edge caching strategy, and how dynamic content will be handled. A headless setup with a framework like Next.js or Astro can dramatically improve Core Web Vitals, but only if the rendering strategy is right.

Section 3: SEO Preservation Requirements

This is the heart of the RFP. Don't be vague here. Spell out exactly what you expect.

3.1 Pre-Migration SEO Audit

### 3.1 Pre-Migration Audit Requirements

The selected vendor must complete and deliver the following before 
any development begins:

1. **Full crawl of existing site** using Screaming Frog, Sitebulb, or 
   equivalent (minimum 50,000 URL capacity)
2. **Top-performing page inventory**: All pages generating organic 
   traffic (minimum threshold: 10 sessions/month over trailing 12 months)
3. **Backlink profile export**: All pages with external backlinks 
   (Ahrefs, Semrush, or Majestic)
4. **Current ranking positions**: Target keywords with current SERP 
   positions (minimum top 100)
5. **Technical SEO baseline**: Crawl errors, orphan pages, canonical 
   issues, hreflang tags, structured data inventory
6. **Internal linking structure map**: Visualization of current 
   internal link equity distribution

3.2 Redirect Mapping Requirements

We hit this at a Fortune 500 client last year. Their previous agency had used wildcard redirects to map an entire /resources/ subfolder to a single landing page. Looked tidy in the spreadsheet. In practice, it killed 340 indexed pages that were generating $18K/month in organic-attributed revenue. Every one of those URLs needed a 1:1 redirect to its actual counterpart on the new site.

Be ruthlessly specific:

### 3.2 Redirect Mapping

1. **1:1 redirect map** for every URL returning a 200 status code 
   on the current site
2. Redirect map must be delivered as a CSV with columns:
   - Source URL (current)
   - Destination URL (new)
   - HTTP status code (301 or 308)
   - Page type (product, blog, category, etc.)
   - Monthly organic sessions (trailing 12 months)
   - Number of referring domains
3. **No redirect chains**: Maximum one hop from old URL to new URL
4. **No wildcard redirects** without explicit approval. Every pattern 
   redirect must be documented with example URLs.
5. Redirect map must be **tested in staging** with automated tooling 
   before production deployment
6. All redirects must be implemented at the **server/edge level**, 
   not via JavaScript

3.3 On-Page SEO Requirements

### 3.3 On-Page SEO Preservation

1. **Title tags**: Migrate existing title tags for all indexed pages. 
   Any changes must be documented and approved.
2. **Meta descriptions**: Migrate existing meta descriptions. 
   CMS must support per-page customization.
3. **H1 tags**: One H1 per page, matching target keyword intent
4. **Schema markup**: Migrate all existing structured data. 
   New pages must include appropriate schema types.
   Minimum: Organization, BreadcrumbList, Article/Product as applicable
5. **Open Graph and Twitter Cards**: All pages must have complete 
   social metadata
6. **Canonical tags**: Self-referencing canonicals on all indexable pages. 
   Vendor must document canonical strategy for filtered/paginated content.
7. **XML sitemaps**: Auto-generated, split by content type, 
   maximum 50,000 URLs per file, submitted to Google Search Console 
   within 24 hours of launch
8. **Robots.txt**: Must be reviewed and approved pre-launch. 
   No accidental noindex/nofollow on production.

I can't stress that last point enough. I've personally seen three major launches where someone left a noindex meta tag from staging in the production build. One site lost its entire Google index for 11 days.

3.4 International SEO (If Applicable)

If you have a multi-language or multi-region site, add specific requirements for hreflang implementation, ccTLD vs. subdirectory strategy, and how the new CMS will handle locale-specific content.

Section 4: Content Migration Specifications

Content Type Inventory

Create a table of every content type and its migration status:

Content Type Current Count Migration Action Priority
Blog posts 847 Migrate all with organic traffic >0 High
Product pages 234 Migrate all, redesign template High
Category pages 45 Migrate, consolidate where noted High
Landing pages 32 Migrate with updated designs Medium
Help/FAQ pages 120 Audit and consolidate Medium
Press releases (pre-2023) 200+ 301 to relevant category page Low
Author pages 15 Migrate with updated bios Low

Taxonomy and URL Structure

### 4.2 URL Structure Rules

1. **Preferred URL structure**: Match existing structure where possible
   - Blog: /blog/[slug]
   - Products: /products/[category]/[slug]
   - Pages: /[slug]
2. **URL conventions**:
   - Lowercase only
   - Hyphens as separators (no underscores)
   - No trailing slashes (or always trailing slashes -- pick one)
   - No file extensions (.html, .php)
   - No session IDs or tracking parameters in indexable URLs
3. **Any URL structure changes** must be accompanied by updated 
   redirect map and approved by [designated stakeholder]

Section 5: Performance and Core Web Vitals Targets

Google's page experience signals continue to matter in 2026. Your RFP should set specific, measurable performance targets:

Metric Target (Mobile) Target (Desktop) Measurement Tool
Largest Contentful Paint (LCP) ≤ 2.0s ≤ 1.5s CrUX / PageSpeed Insights
Interaction to Next Paint (INP) ≤ 150ms ≤ 100ms CrUX / PageSpeed Insights
Cumulative Layout Shift (CLS) ≤ 0.05 ≤ 0.05 CrUX / PageSpeed Insights
Time to First Byte (TTFB) ≤ 400ms ≤ 200ms WebPageTest
Total Page Weight ≤ 1.5MB ≤ 2.0MB Lighthouse
Lighthouse Performance Score ≥ 90 ≥ 95 Lighthouse CI 
### 5.2 Performance Testing Requirements

1. Lighthouse CI must be integrated into the deployment pipeline 
   with minimum score thresholds as gate checks
2. Real User Monitoring (RUM) must be implemented pre-launch 
   (e.g., Vercel Analytics, SpeedCurve, or equivalent)
3. Performance budget must be documented and enforced for:
   - JavaScript bundle size (total and per-route)
   - Image optimization pipeline (WebP/AVIF with fallbacks)
   - Font loading strategy (preload, font-display: swap)
4. Vendor must provide performance comparison report: 
   current site vs. new site across 20 representative pages

Modern frameworks make these targets achievable. We routinely hit sub-1s LCP on Astro builds and sub-1.5s on Next.js projects with proper optimization. But you need to set these expectations in the RFP, or you'll get whatever the vendor's default is.

Section 6: Vendor Evaluation Criteria

Here's a scoring rubric you can adapt:

Criteria Weight Scoring (1-5)
SEO migration experience (case studies with traffic data) 25%
Technical architecture approach 20%
Performance optimization track record 15%
Content migration methodology 15%
Team composition (dedicated SEO resource?) 10%
Timeline and milestone realism 10%
Pricing transparency 5%

Notice that SEO migration experience carries the highest weight. That's intentional. A beautiful website that hemorrhages traffic is a liability, not an asset.

Questions to Ask Vendor References

  1. "What percentage of organic traffic was preserved 90 days post-launch?"
  2. "Were there any unexpected ranking drops? How were they handled?"
  3. "How was the redirect mapping process managed?"
  4. "Did the vendor provide post-launch SEO monitoring?"

If a vendor can't provide at least two references where they can answer these questions with specific numbers, that's a red flag.

If you're actively writing your RFP right now and want expert eyes on it before it goes out, send us your RFP and we'll give you honest feedback on what's missing.

Section 7: Timeline, Milestones, and Acceptance Criteria

A realistic redesign with proper SEO migration takes 12-20 weeks for a mid-size site (1,000-10,000 pages). Anyone promising less is cutting corners somewhere.

### 7.1 Milestone Schedule

| Phase | Duration | Deliverables | Acceptance Gate |
|-------|----------|-------------|------------------|
| Discovery & Audit | 2-3 weeks | SEO audit, content inventory, technical assessment | Stakeholder sign-off |
| Strategy & Architecture | 2-3 weeks | IA, URL mapping, redirect plan, wireframes | SEO review + approval |
| Design | 3-4 weeks | Design system, key page templates | Brand + UX approval |
| Development | 4-6 weeks | Functional staging site | Technical QA pass |
| Content Migration | 2-3 weeks | All content migrated to staging | Content + SEO QA |
| Pre-Launch QA | 1-2 weeks | Full redirect test, crawl comparison, performance audit | SEO sign-off required |
| Launch | 1 day | DNS cutover, redirect activation | War room monitoring |
| Post-Launch Monitoring | 4-8 weeks | Weekly traffic reports, crawl monitoring, index coverage | 90-day traffic comparison |

### 7.2 Pre-Launch Checklist (Must-Pass)
- [ ] All 301 redirects tested and verified (automated)
- [ ] XML sitemap generated and validated
- [ ] Robots.txt reviewed (no accidental blocks)
- [ ] All pages render correctly without JavaScript (for crawlers)
- [ ] Schema markup validated via Google Rich Results Test
- [ ] Canonical tags verified on all indexable pages
- [ ] Core Web Vitals passing on representative pages
- [ ] Google Search Console property verified for new site
- [ ] Analytics tracking verified on all page templates
- [ ] No noindex tags on production pages

That last checklist should be a contractual requirement. Launch doesn't happen until every box is checked.

Common RFP Mistakes That Kill Organic Traffic

After years of doing this, here are the patterns I see repeated:

1. "We'll handle redirects after launch." No. Redirects must be in place at the moment of launch. Every hour without them, Google is discovering 404s and devaluing your pages.

2. "We're only changing the design, not the content." Changing templates changes how Google sees your content. Different heading structures, altered internal links, new JavaScript rendering -- it all affects rankings.

3. "Our developer knows SEO." Maybe. But knowing SEO and having executed a site migration are very different things. Ask for specific migration experience.

4. "We'll just redirect everything to the homepage." This is functionally the same as a 404 in Google's eyes. It's a soft 404. Don't do this.

5. "We want to clean up our URL structure while we're at it." This dramatically increases migration risk. If you must change URLs, fine. But understand you're adding weeks of redirect mapping work and accepting higher risk.

Technology Stack Considerations for 2026

The technology you choose affects SEO migration complexity directly. Here's what we're seeing:

Approach SEO Pros SEO Cons Best For
Next.js (App Router) SSR/SSG, great CWV, built-in Image optimization Hydration can affect INP if misconfigured Dynamic sites, e-commerce
Astro Near-zero JS by default, excellent CWV Less ecosystem for complex interactivity Content-heavy sites, blogs
WordPress (headless) Familiar CMS, huge plugin ecosystem Performance depends heavily on frontend Teams invested in WP workflows
Webflow Visual builder, fast launches Limited SEO customization, vendor lock-in Marketing sites with small teams
Traditional WordPress Mature SEO tooling (Yoast, Rank Math) Performance ceiling, security overhead Budget-constrained projects

We've found that headless architectures with Next.js or Astro paired with a headless CMS like Sanity or Contentful give the best combination of editor experience and SEO performance. But the migration from a traditional CMS to headless adds complexity your RFP needs to account for.

If you're evaluating vendors for this kind of project, we're always happy to talk through the technical considerations. You can check our pricing or reach out directly -- no obligation, we genuinely enjoy nerding out about this stuff.

FAQ

How long does a typical website redesign with SEO preservation take?

For a mid-size site (1,000-10,000 pages), expect 12-20 weeks from kickoff to launch, plus 8-12 weeks of post-launch monitoring. Sites with more than 10,000 pages or complex e-commerce functionality can take 6-9 months. Rushing the timeline is the single biggest predictor of traffic loss.

What percentage of organic traffic should we expect to retain after a redesign?

With proper migration planning, you should retain 90-100% of organic traffic within 90 days. Some temporary fluctuation (a 10-15% dip) in the first 2-4 weeks is normal as Google recrawls and reindexes. If you're seeing a 30%+ drop that persists beyond 4 weeks, something went wrong with the migration.

Should we include SEO requirements in the main RFP or create a separate document?

Include them in the main RFP. When SEO requirements live in a separate document, they get treated as optional. Vendors need to see these requirements alongside the design and development scope so they can staff and budget accordingly.

How much does a website redesign with proper SEO migration cost?

Budget varies wildly, but here's a rough guide: a mid-market site redesign with proper SEO migration typically runs $50,000-$200,000 for the initial build. Enterprise sites can exceed $500,000. The SEO migration work specifically (auditing, redirect mapping, QA, monitoring) adds roughly 15-25% to the total project cost. That's money well spent when you consider the revenue at risk.

What's the biggest risk in a website redesign from an SEO perspective?

Broken or missing redirects. Full stop. Every other SEO issue -- missing meta tags, changed heading structures, slower page speed -- can be fixed post-launch with manageable impact. But if Google crawls thousands of 404 pages because redirects weren't in place, the damage compounds quickly and recovery is slow.

Should we freeze content changes during the migration?

Yes, implement a content freeze 2-3 weeks before launch. Any new content published during this window needs to be manually added to both the old and new sites, which creates extra work and room for error. Plan your editorial calendar around the migration timeline.

How do we monitor SEO health after launch?

Set up daily monitoring for the first 30 days. At minimum, track: Google Search Console index coverage report (watch for spikes in "Excluded" pages), crawl stats (crawl rate should increase post-launch as Google discovers changes), organic traffic vs. baseline (compare same day-of-week, not sequential days), and ranking positions for your top 50-100 keywords. Tools like ContentKing or Lumar can automate real-time monitoring.

Can we change our domain name during a redesign?

You can, but understand this is the highest-risk migration scenario. A domain change plus a redesign means Google has to process two major signals simultaneously. If possible, separate the two: redesign on the existing domain first, stabilize for 3-6 months, then migrate to the new domain. If you must do both at once, add at least 4-6 additional weeks to the timeline for extra QA and monitoring.

Ready to get started?

If you've got a redesign on the horizon and don't want to gamble with your organic traffic, get a proposal in 48 hours. We'll review your requirements and tell you exactly what a migration-safe redesign looks like for your site.