Website Redesign Checklist: What to Do Before You Start

Work through this website redesign checklist before anyone writes a line of code, because the expensive mistakes in a redesign happen in planning, not in production. The most common one is changing the design and the URL structure in the same release with no redirect map, which throws away rankings the old site spent years earning.

Google’s own guidance on moving a site recommends making one major change at a time, for example moving to a new domain before changing the layout. When everything changes at once, any drop in traffic is harder to trace and slower to fix. Plan accordingly.

Start by measuring what you have

You cannot protect performance you never recorded. Before the new design exists, capture a baseline you can compare against after launch:

• Export your organic landing pages from Search Console, with clicks and impressions, so you know which URLs actually earn traffic.
• Crawl the full site and save the complete list of URLs.
• Record your Core Web Vitals, your conversion rate, and your top ten converting pages.
• Note your best-ranking keywords and the pages that earn them.

Teams that skip this cannot answer the only question that matters three months after launch: is the new site performing better or worse than the old one?

Decide what problem the redesign solves

“It looks dated” is a symptom, not a brief. A redesign with no measurable goal produces a prettier site with the same business results.

Pick one primary outcome and write it down. More qualified leads. Higher average order value. Fewer support calls because the site answers the question. Faster publishing because the current CMS fights the team. Everything else in the project gets judged against that sentence.

If the honest answer is that the site works fine and leadership wants a refresh, say so. A targeted redesign of a few templates costs a fraction of a rebuild and carries far less risk. Our guide to the signs your website needs a redesign helps separate a real problem from a cosmetic one.

The checklist: settle these before design starts

Everything below should be decided, with a named owner, before a designer opens a file. If you cannot fill in a row, that is the next conversation to have, not a detail to sort out later.

Area	What to confirm before design work begins
Baseline data	Search Console export, full URL crawl, Core Web Vitals, conversion rate
Goal	One measurable outcome, written down and agreed
URL strategy	Keep the existing URLs, or build a complete old-to-new redirect map
Content inventory	Which pages stay, get rewritten, get merged, or get deleted
Platform	Staying put or replatforming, decided on a real requirement
Analytics	Tracking plan and conversion goals specified, not left for later
Integrations	CRM, email, booking, payments, each with an owner
Accessibility	Target standard set before design, not audited after
Rendering	Important content confirmed to load without JavaScript, for search and AI crawlers
Launch plan	Staging site, QA checklist, rollback option, and who signs off
Post-launch	Who monitors what, for how long, and against which baseline

Handle URLs deliberately

This is where redesigns lose money, so it deserves its own decision rather than being discovered halfway through development.

The safest redesign keeps every URL exactly as it is and changes only the design. If URLs must change, you need a complete map from old to new, with a 301 redirect for every URL that has traffic, backlinks, or both. Map each old page to its closest match. Do not send everything to the homepage: Google treats mass redirects to the homepage as soft 404s, which means the old pages’ authority is simply lost.

Keep those redirects in place longer than feels necessary. Google’s John Mueller has recommended keeping them for at least a year, because Google needs to see a redirect repeatedly before it treats the move as permanent.

Audit the content before you design around it

When design comes first, designers lay out pages for content that does not exist yet, writers fill boxes sized before anyone knew what needed saying, and the result reads like a template. Inventory first, design second.

Go through every page and mark it: keep as is, rewrite, merge into another page, or delete. Pages with traffic and conversions are keepers even if they look dated. Pages with no traffic, no links, and no strategic purpose can go, and deleting them is usually better than redesigning them.

Then write or gather the real headlines, service descriptions, and page copy before the layout is finalized. Design built around real content holds up. Design built around placeholder text falls apart the moment the real words arrive.

Plan the structure and navigation

A redesign is the chance to fix a menu that grew one page at a time. Map the new site’s pages and how they connect before designing any of them. Group related pages, cut the ones that duplicate each other, and keep the path to your most important pages short, for visitors and for search engines trying to work out what matters.

Six things teams forget until launch week

These rarely make it onto a project plan, and they always surface at the worst moment:

• Analytics and conversion tracking, which break silently when templates change and can go unnoticed for weeks.
• Integrations with your CRM, email, and booking systems, each of which needs a real test submission on the staging site.
• Form notifications, which often point at an inbox nobody checks anymore.
• Image and PDF URLs, which also need redirects if the media library structure changes.
• The 404 page, which will get traffic no matter how good the redirect map is.
• Whoever controls the DNS and SSL certificate, because launch day is a bad time to discover nobody has the login.

Every item on that list is cheap to handle in planning and expensive to discover after launch.

Plan the first thirty days after launch

Launch is the midpoint of the project, not the end. Expect some movement in rankings while Google reprocesses the site, and resist the urge to change things during it.

For the first two weeks, have someone check Search Console daily for coverage problems and crawl errors. Watch for redirect chains and loops. Compare organic traffic to your baseline weekly rather than daily, since daily numbers swing too much to read. Confirm that conversion tracking is recording real events, not zeros. And keep a private copy of the old site for a month, so you can check anything that looks wrong.

Get your redirect map checked before launch

The most valuable hour in any redesign is the one spent comparing the old URL list against the new one. If you are mid-project, pull your landing pages from Search Console and your new sitemap, and check that every URL with traffic has a destination.

If you would like a second pair of eyes, OgreLogic can crawl your current site, compare it against your planned structure, and send back the URLs with traffic or links that have no destination yet. Send us your domain and your new sitemap, or call +1 (512) 861-8471. If you want the redesign itself handled end to end, that is our web development work, and what a website costs in 2026 lays out the budget ranges.

If your redesign includes a platform change, read Magento vs Shopify first. LLM SEO explains why content that loads without JavaScript matters more than it used to.

FAQs

How long does a website redesign take?

For a typical small business site, about four weeks once the content is ready, which is how we run most of our builds. It runs longer when content arrives late, which is the most common cause of delays. A larger site with content rewriting, integrations, or a platform change usually takes three to six months. The planning in this checklist is the stage most often rushed, and it is the stage that causes the overruns.

Will a redesign hurt my SEO?

It can, and the cause is almost always changing URLs without a complete redirect map. A redesign that keeps its URLs, its content depth, and its page speed usually holds its rankings and sometimes improves them. One that changes the structure without mapping redirects loses traffic that can take months to recover.

Should I redesign or rebuild on a new platform?

Redesign if the current platform is not actually the problem. Rebuild if the platform is blocking something your business needs, such as speed you cannot fix, functionality it will not support, or a publishing process that costs your team hours every week. The honest test is whether you can name the specific limitation.