Jake Young
A redesign is supposed to make the site better, yet plenty of them launch to a quiet drop in search traffic that nobody can explain for weeks. The causes are almost always mechanical: URLs changed without redirects, pages that earned links were deleted, or a staging “noindex” tag went live. This website redesign checklist exists to stop that from happening to you.
It runs in five phases. Decide whether you need a redesign at all. Record a baseline and an inventory of every URL before anything is designed. Build around real content with clear targets. Launch with a tested redirect map. Then watch the numbers closely for several weeks. We spend more time on inventory and launch than on colour, because that is where redesigns are won or lost.
Redesign or Refresh? How to Tell
A refresh changes the surface: type, colour, imagery, a few templates. A redesign changes the structure: which pages exist, how they connect, what the site is for, and often the platform underneath.
You probably need a redesign if your business has changed and the site still describes the old one, if your team avoids editing because the CMS fights them, or if Core Web Vitals fail on most templates and every fix runs into the same theme. The same goes when the site can’t support something you now need, like a second language or proper case studies.
A refresh is probably enough if the structure still matches how customers shop and the pages that bring in traffic are healthy. Keep the URLs and the information architecture, and put the effort into visual design and copy. You carry far less SEO risk when nothing moves.
Website Redesign Checklist: Before You Design Anything
Write down goals you can check
“Modernise the site” is a wish. “More demo requests from organic visitors” or “a product page an editor can publish without a developer” are goals. Pick two or three, name the metric for each and agree who owns it. Every later decision gets tested against them.
Record an analytics baseline
Export at least twelve months of data so seasonality doesn’t fool you later: sessions and conversions by landing page, organic clicks and impressions by page and query from Search Console, and field Core Web Vitals per template.
Crawl the site and build a URL inventory
Combine a crawl of the live site with your sitemaps, server logs, analytics landing pages and a CMS export. Google’s site move guide recommends this mix because a crawler only finds linked pages. Orphaned landing pages, old campaign URLs and PDFs often show up only in logs and analytics, and they still carry links and traffic.
Audit the content
Give every URL one of four labels: keep, rewrite, merge or remove. Merging thin pages on the same topic usually helps. Removing a page is fine too, as long as you decide where its visitors and links should go.
Flag the pages you cannot afford to break
Sort the inventory by organic clicks, conversions and referring domains. The short list at the top holds most of your search value. Keep those URLs the same if at all possible, change their content only on purpose, and check each one by hand on launch day.
Settle stakeholders and the brand
Name one decision-maker and a small review group before design starts. If the brand itself is shifting, settle the identity first. A site designed around a logo and voice that are still moving gets designed twice.
During: Build the Site Around the Content
Plan the information architecture
Group pages the way customers think, which is rarely the way the org chart is drawn. Keep URLs short, readable and stable, and change them only when the old structure is wrong. Every URL you change adds a line to the redirect map and a small risk at launch.
Write content first, then build a system
Design with real copy. Real headlines run longer than placeholders, real product names wrap in odd places, and real pages have a proof point the layout must make room for. Then design the parts (type scale, colour tokens, buttons, cards, section patterns) and assemble pages from them. A system keeps the site consistent when editors start adding pages nobody designed.
Set a performance budget and hold it
A performance budget caps the things that slow a page down: image weight, script size, font files. Tie it to Core Web Vitals, where Google defines good as Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less. Check it on every pull request so problems surface while they are small.
Meet WCAG 2.2 AA
WCAG 2.2 added nine success criteria, and several land squarely on redesign work: focus must not hide behind sticky headers, pointer targets need to be at least 24 by 24 CSS pixels or spaced to match, drag interactions need a single-pointer alternative, and help links should sit in the same place on every page.
Carry structured data across and write for AI search
List the schema the old site had (Organization, Product, Article, FAQ, Breadcrumb) and make sure each type exists on the matching new templates. Nothing visible breaks when it goes missing, which is why it gets lost. AI answer engines also quote pages that state things plainly in server-rendered HTML, so write specific claims under clear headings. Our guide to designing pages that get cited by AI search covers the details, and our comparison of Next.js, Webflow and Framer helps if you are also changing platform.
Launch: The Website Migration SEO Checklist
Build and test the 301 redirect map
Point every changed URL to the single most relevant new URL with a permanent server-side redirect (301 or 308). Google reads a permanent redirect as a signal that the target should be canonical, and a temporary one as a signal that it shouldn’t. Avoid sending everything to the homepage, avoid chains, and test the full list on staging before launch. Keep the redirects live for at least a year, and ideally for good.
Check canonical tags
Each new page should declare itself canonical with an absolute URL on the production domain. A common launch bug is templates that still point canonicals at staging or at old URLs.
Remove staging blocks
Google lists leftover noindex tags and robots.txt blocks among the common migration mistakes. Check robots.txt, the meta robots tag on key templates and the X-Robots-Tag header within minutes of launch.
Submit sitemaps and confirm tracking
Submit an XML sitemap of the new URLs only in Search Console, and use the Change of Address tool if the domain itself is changing. Then check that analytics fires on every template, that forms and purchases still record as conversions, and that consent settings behave as before. Some post-launch “traffic drops” are just a missing tag.
After: Watch Closely, Then Keep Improving
Google says a medium-sized site can take a few weeks or more for new URLs to replace old ones in results, with some ranking movement along the way. Your job is to tell normal movement from a real problem.
Check Search Console’s page indexing report and your server logs daily for the first two weeks. New 404s usually mean a URL was missed in the redirect map. Add the redirect, then look for others like it, because missed URLs tend to come in families.
Compare the flagged pages against your baseline first, by URL and by query. A drop across the whole site points to a technical cause, such as indexing or canonicals. A drop on a handful of pages usually points to their redirects, or to content that changed more than intended. Once a few weeks of field data build up, compare Core Web Vitals template by template and fix the worst first. Review your goals after a month and again after a quarter.
What Affects Redesign Timeline and Cost
We won’t quote a typical number, because the spread between projects is too wide to be useful. The size and messiness of the current site matter most, followed by how much content has to be written, which is the most underestimated task. Platform changes add migration work, custom functionality adds build and testing time, and every extra approver adds calendar time to each review round. When you compare proposals, ask each studio who owns the URL inventory and redirect map. Our guide on how to choose a web design agency has more questions to ask.
Frequently Asked Questions
How do you redesign a website without losing SEO?
Record a baseline and a full URL inventory before you start, keep URLs the same wherever you can, and map every changed URL to its closest new equivalent with a permanent redirect. At launch, remove staging blocks, check canonicals and submit a new sitemap. Then monitor 404s and rankings for several weeks.
How long does a website redesign take?
It depends on the size of the current site, how much content needs writing and how many people approve each stage. Content and approvals cause more delays than design or code, so ask for a phased plan with dates.
How long should 301 redirects stay in place after a redesign?
As long as possible. Google’s site move documentation says to keep them for at least a year, and old links on other sites keep sending visitors long after that. Treat the redirect map as a permanent part of the site.
Is it normal for rankings to drop after a website redesign?
Some fluctuation is normal while Google recrawls the new URLs. A sharp drop that doesn’t recover usually has a specific cause: missing redirects, a leftover noindex tag, wrong canonicals or important content that was removed. Compare against your baseline page by page to find it.
If you are planning a redesign and want a second opinion on the plan, the inventory or the redirect map, we are happy to look. Read about our web design and development work or get in touch to talk it through.
