Website Redesign Checklist: Protect Your Rankings

A website redesign checklist should protect what already brings customers in, not just guide what the new homepage looks like. If your current site generates search traffic, calls, or quote requests, those assets need a migration plan. The goal is a website that works better without making Google or your customers start over.

Start with evidence, not design opinions

Before approving layouts, record how your current website performs. Without a baseline, a post-launch traffic drop becomes a guessing game, and a prettier site can hide a weaker sales funnel.

• Export search performance: Save Google Search Console data for clicks, impressions, queries, and landing pages. Review the last three months and compare with the same period last year where available.
• Record organic leads: Identify which pages generate form submissions, phone clicks, bookings, and purchases. Separate actual inquiries from softer actions such as button clicks.
• Crawl the existing site: Have your team export URLs, status codes, page titles, headings, canonical tags, and internal links.
• Find valuable backlinks: Identify pages other websites link to, including useful resources and older articles.

Keep these exports somewhere your business owns. Write down any tracking gaps before launch so nobody mistakes a measurement change for a performance change.

Your website redesign checklist starts with every URL

Create a spreadsheet listing existing URLs and their planned destinations. Include pages found in your sitemap, analytics, Search Console, and backlink reports, not just pages visible in the main menu.

Give each URL a decision: keep, improve, merge, or remove. Add its traffic, leads, relevant backlinks, new destination, and the person responsible for checking it.

• Keep: Preserve the URL when the page still serves the same purpose. A new design does not require a new address.
• Improve: Update the page while retaining the information and search intent that make it useful.
• Merge: Combine overlapping pages only when the replacement genuinely answers the same needs.
• Remove: Retire obsolete content deliberately. If no relevant replacement exists, a proper 404 or 410 response can be appropriate.

Do not redirect every deleted page to the homepage. Someone looking for a specific service should reach that service, not a generic welcome message. When URLs change permanently, use server-side permanent redirects, usually 301s, and avoid chains that bounce through multiple addresses.

Google's guidance for site moves with URL changes recommends keeping redirects for at least one year. Valuable old links may justify keeping them much longer.

Protect useful content while improving the experience

A common redesign mistake is replacing a detailed service page with a big photo, a short slogan, and a contact button. That may look cleaner, but it removes answers customers and search engines relied on.

For pages that attract qualified traffic, preserve the core subject, helpful explanations, meaningful headings, and supporting internal links. Keep strong page titles where they still fit. You can rewrite weak copy without stripping away the substance.

For a Michigan contractor, that might mean keeping installation details, project examples, service-area information, and pricing factors rather than reducing everything to “Quality you can trust.” Specific information builds confidence and helps visitors decide whether to call.

This is where website design and conversion planning should work together. Make the next step obvious, place proof near decision points, and keep forms short enough to finish. Improve clarity first, then test bigger messaging changes once the launch is stable.

Build technical safeguards into the project

Your staging site should stay out of search results. Password protection is a strong option; if your team also uses noindex directives, document exactly where they must be removed before launch. A robots.txt block alone is not a reliable way to prevent a URL from appearing in search.

Ask your developer to verify these items on the new build:

• Indexability: Important public pages return a 200 status and are not blocked by accidental noindex directives or crawling restrictions.
• Canonical tags: Pages identify the intended live URL, not a staging address or unrelated page.
• Internal links and sitemap: Both point directly to final URLs rather than old addresses that redirect.
• Mobile usability: Menus, buttons, text, and forms work on real phones.
• Structured data: Relevant existing markup remains accurate and matches visible content.
• Performance: Images, fonts, scripts, and animations do not make key pages sluggish.

Use Core Web Vitals guidance to understand loading speed, responsiveness, and visual stability. Test service pages and forms, not only the homepage. Prelaunch lab tests can catch problems, but real-user performance data needs monitoring after launch.

Make launch approval a business decision

Assign one person to approve launch, with named owners for development, content, search, and lead tracking. “Everyone checked it” is not a sign-off process.

Before launch day, run a small rehearsal covering the journeys that pay the bills:

1. Open your highest-value landing pages and confirm their content and calls to action.
2. Test planned redirects in the test environment, then verify them again on the live domain.
3. Submit every important form and confirm the right person receives the inquiry.
4. Test phone links, scheduling tools, payments, and CRM connections where applicable.
5. Check analytics and conversion events for missing or duplicate firing, accounting for consent settings.
6. Confirm backups, access credentials, and a workable recovery plan.

Schedule the release when your team can monitor it, not just before everyone leaves for the weekend. Avoid combining a domain move, CMS replacement, major content rewrite, and navigation overhaul unless there is a clear business reason. Fewer simultaneous changes make problems easier to diagnose.

Watch the right signals after launch

Immediately after launch, crawl the live site, test old URLs, inspect priority pages in Search Console, and submit the updated XML sitemap. Submission helps discovery; it does not guarantee indexing.

During the first week, check daily for broken pages, indexing restrictions, missing leads, and unexpected redirects. Then review weekly for at least the next month. Compare organic landing-page traffic, clicks, inquiries, and conversion rates with your baseline.

Some search movement can happen while Google reprocesses a redesigned site, especially when URLs change. Do not dismiss a sharp drop as normal. Check technical causes first, then examine whether content or internal links changed. Ongoing SEO support should connect those findings to qualified leads, not just ranking reports.

The Smash Take

A redesign should earn its keep: clearer messaging, easier action, and protection for the visibility you already built. No checklist can promise unchanged rankings, but a disciplined migration removes plenty of avoidable risk. Before approving the visuals, approve the URL map, testing plan, and definition of success.

Keep going: more Smash insights.