Skip to content

RFP pack 10 min read Updated September 23, 2026

SEO-safe website redesign RFP: the pack that protects your rankings during a rebuild

In short

Use this RFP when your site already ranks and you cannot afford to lose that traffic during a rebuild. It forces every bidder to commit, in writing, to a redirect map, a URL crawl, a content-parity check, and a rankings recovery test before final payment, so protecting your traffic is a paid deliverable, not a hope.

Key facts

  • A site that already earns organic traffic loses rankings after a redesign almost always for one of three reasons: missing redirects, thinner content on the new pages, or a URL structure change that was never mapped, so each of these needs its own line in the RFP.
  • A full crawl of your current site, capturing every indexed URL, its title, and its ranking keywords before the rebuild starts, is the baseline every redirect map should be checked against, and the RFP should name who runs that crawl and when.
  • Google can take anywhere from a few weeks to a few months to fully recognize a site migration, so the RFP should set a rankings check at a fixed point after launch, not on launch day itself, as the real test of whether the move was safe.
  • Structured data (schema markup) that feeds review stars, FAQ boxes, or product details in search results has to be rebuilt page by page on the new site; losing it is invisible in a design review but shows up in search results weeks later.
  • Core Web Vitals (Google's page speed and stability metrics) are compared before and after a redesign, so the RFP should require a written speed benchmark on the old site before teardown, since there is no way to prove a slowdown after the old site is gone.

Scope boundaries

Name the exact set of URLs the SEO-safety work covers: is it every indexed page on the current site, or only the pages that currently rank for a keyword you care about? A small site can usually afford to protect every URL; a large site with thousands of thin or outdated pages may choose to protect only the pages that already earn traffic and let the rest be retired on purpose.

State whether the new site keeps the current URL structure or changes it. Changing from, for example, a flat structure to folders by category is a legitimate design choice, but it multiplies the redirect and content-parity work, and a bidder needs to know this before quoting.

State whether new content is being written for existing pages, or whether existing copy is being kept and only the design and code change. Rewriting copy on a page that already ranks is the highest-risk move in a redesign, because search engines re-evaluate the page as if it were new; if you want new copy on ranking pages, say so and ask the vendor how they plan to manage that risk specifically.

What the vendor must be given

Give the vendor read or export access to your Google Search Console and GA4 properties before the project starts, not after launch. Search Console holds the list of indexed URLs, click and impression data by page, and the crawl errors Google is already seeing; a bidder cannot protect what they cannot see.

Supply a full export or crawl of the current site's URLs, or agree in the contract that the vendor will run that crawl themselves in week one and you will review the list together. Either way, the list has to exist as a written artifact both sides sign off on before any page is rebuilt.

Give the vendor access to any existing schema markup, XML sitemap, and robots.txt file, and to your CMS's redirect tool if one exists, so the new redirect rules can be checked against what is already in place rather than built from a blank slate.

Ownership and exit clauses

Confirm you retain ownership of your Search Console and GA4 properties throughout the project, with the vendor added as a user rather than an owner, so historical ranking and traffic data stays under your account no matter what happens with the vendor relationship.

Require the vendor to hand over the full redirect map, the pre-migration crawl, and any schema templates they built as separate, portable files, not locked inside a proprietary tool only they can open. If the vendor uses a paid crawling or migration tool, ask whether the output can be exported in a plain format like a spreadsheet.

Add a clause that if rankings drop beyond an agreed threshold within the recovery window after launch, the vendor is responsible for diagnosing the cause and fixing it at no additional charge, since redirect and content mistakes made during a migration are the vendor's error to correct, not new billable work.

Milestones and acceptance tests

Set a pre-migration benchmark milestone: the full URL crawl, current rankings for your top keywords, and current page speed scores, recorded and signed off before any old page is taken down. This is the record you will compare against if something goes wrong.

The staging review is where the real test happens: every URL from the old crawl has a mapped destination on the new site (a 301 redirect or a documented reason it was dropped), every page that had schema markup has equivalent markup on the new page, and the XML sitemap for the new site is generated and ready to submit.

Set a post-launch milestone at a fixed point, for example four to eight weeks after launch, where you and the vendor review Search Console together: indexing status of the new URLs, any new crawl errors, and rankings for your top keywords against the pre-migration benchmark. Tie a portion of final payment to this milestone specifically, since it is the only point at which you can actually confirm the move was safe.

Scoring rubric

Weight technical SEO process heavily here, more than on a typical redesign RFP: 30 percent the vendor's written migration and redirect process, 25 percent price and payment terms, 20 percent references from past migrations where you can verify rankings held or recovered, 15 percent timeline, and 10 percent design and general fit.

Score the migration process on specifics: does the vendor name the tools they use to crawl a site and build a redirect map, do they mention checking Search Console for crawl errors after launch, and do they describe a recovery window rather than promising an instant, risk-free switch.

Ask every reference for the domain of a site the vendor migrated, and check that site's organic visibility yourself using Search Console data if the client will share it, or simply confirm the site is still online and ranking for its business name and core terms months after the migration.

Questions every bidder must answer

Every bidder should answer these before you sign anything: How do you build the redirect map, and will I see it and approve it before launch? What is your process if organic traffic drops after launch, and how long is a normal recovery window? Will structured data (schema) be rebuilt page by page, and who checks that it is valid?

Also ask: Have you migrated a site of a similar size before, and can I see the before-and-after Search Console data if the client agrees to share it? Will the new site keep my current URL structure, or are you recommending a change, and why? Who is responsible, and at whose cost, if rankings do not recover within the agreed window?

A bidder who cannot describe their redirect process in specific terms, tools, checkpoints, a written map, is not equipped to protect existing rankings, no matter how strong their design portfolio looks.

Related questions

SearchPod is a vendor for this kind of work and would answer this RFP; the acceptance tests here are the ones we agree to.

Want this scoped and priced for your business?

Get a free, no-obligation proposal within one business day. We look at your site and your market and tell you plainly what we would do, and what we would not.

Get your free proposal

Keep reading

More in RFP packs

All 40 in RFP packs