Engineering · 8 min read
Website rebuild checklist: how to launch without losing what you earned
A new design is the visible part of a rebuild. The risk lives in URLs, redirects, forms and DNS, so here is the checklist we run before, during and after every launch.
A rebuild usually starts with a fair complaint. The site looks older than the business, and the sales team has quietly stopped sending the link. So the brief says “new website”, and everyone pictures new screens.
The screens are the easy part. An old website is also a record of years of publishing: URLs that rank, PDFs distributors still link to, forms wired to an inbox nobody checks, and a DNS record only one former employee understood. A rebuild moves all of that at once. That makes it a migration, whatever the brief calls it.
This is the checklist we work from at D&C Studios. I still write the launch version by hand, in a notebook I refuse to digitise, because crossing off a line with a pen forces you to read it. Use it to hold any team to account, including us.
Why rebuilds lose traffic
Most rankings lost after a relaunch come from a few avoidable mistakes. None of them is a design problem.
| What goes wrong | What it costs | How to prevent it |
|---|---|---|
| Old URLs return 404 | Rankings and backlinks earned over years | A complete URL inventory and a tested 301 map |
| Every old page redirects to the home page | Search engines treat them as dead pages | Redirect to the nearest equivalent, or retire honestly |
| Useful content is cut to fit the new design | Pages that answered real questions vanish | A decision per URL, made with data |
| The staging noindex tag ships to production | The whole site drops out of search | A launch check on the live domain, not the preview |
| Analytics changes on launch day | No clean before and after | A baseline exported and the same property kept |
Before design begins
Inventory every URL
List every public URL, not just the ones in the menu. A crawler finds most of them. Search Console, analytics, server logs and backlink reports find the rest: old campaign pages, PDFs, tag archives and pages only search engines remember.
For each URL, record the title, status code, organic clicks over the last 12 months, backlinks, an owner and a decision. There are only five decisions: keep, rewrite, merge, redirect or retire. Export 16 months of Search Console data now, the most it keeps, so there is a baseline to compare against later.
Archive the old site
Take full page screenshots of the important routes and export the text, images and documents. It sounds like housekeeping, until someone asks three weeks after launch what the old pricing page actually said.
Agree what the site must do
Write down the priority audiences and the two or three actions that matter most for each. The page list follows those decisions, not the old CMS. A rebuild is the one moment you are allowed to stop inheriting the old sitemap.
Find out who holds the keys
Before launch week, name the person who controls each of these: domain registrar, DNS, hosting, CDN, SSL certificates, email records, analytics, Search Console, form endpoints, payment gateway, third party scripts, and image and font licences. The worst launch calls we have joined were forty minutes of hunting for the one person with the registrar password.
During content and design
Write the real words first
Placeholder copy produces placeholder layouts. A seven word headline behaves differently from a twenty word one. Write enough final content to test hierarchy, line length and the phone view before the design is signed off.
Keep URLs that earned their place
A tidier URL is not automatically better. If an old address ranks or has links, keep it where you can. When it must change, point it at the most relevant new page with a single permanent 301 redirect. Avoid chains, where one redirect leads to another, and never send every retired page to the home page.
Design the awkward states
Long names, missing images, empty search results, validation errors, slow connections, the 404 page, keyboard focus, reduced motion and 200 percent zoom. A design system is only credible when it covers what happens outside the perfect screenshot.
During the build
Set performance budgets early
Agree the limits before pages get heavy, then check them on every change. Google’s Core Web Vitals give the targets, measured at the 75th percentile of real visits.
| Measure | What it tracks | Good |
|---|---|---|
| Largest Contentful Paint (LCP) | How fast the main content appears | 2.5 seconds or less |
| Interaction to Next Paint (INP) | How fast the page responds to a tap or click | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | How much the layout jumps while loading | 0.1 or less |
Test on a mid range Android phone over mobile data, not only on a laptop in responsive mode. That is how many visitors will meet the new site.
Make every form tell the truth
A form that says “thank you” without delivering the message is worse than no form. Test the destination, spam protection, privacy wording and receiving inbox, from a phone on mobile data.
Ship the unglamorous files
Each indexable page needs a unique title, description, canonical URL, Open Graph data and honest structured data. Around the pages sit robots.txt, an XML sitemap, the redirect rules, a 404 page, security headers, icons, legal pages and a record of asset licences. These live inside our web design and development process as a standing list, so nobody has to remember them on the night.
Redirects and SEO: a worked example
Here is how the numbers typically fall. Take a B2B manufacturer with a nine year old WordPress site. The crawler finds 311 URLs. Search Console, analytics and server logs add another 175, mostly tag archives, expired campaigns and PDFs. That is 486 addresses, and each one needs a decision.
| Decision | URLs | Rule of thumb |
|---|---|---|
| Keep, same URL | 38 | Ranks or has links, and the content is still right |
| Rewrite, same URL | 44 | Right topic, stale words |
| Merge into 22 new pages | 126 | Thin pages competing for the same topic |
| Redirect to the nearest equivalent | 71 | Section moved or product renamed |
| Retire with a 410 | 207 | No traffic, no links, no reason to exist |
The new site launches with 118 pages: the 104 that survive, plus 14 written for questions the old site never answered. A few rows from the redirect map show the thinking.
| Old URL | New URL | Status | Why |
|---|---|---|---|
| /services/amc/ | /services/maintenance-contracts/ | 301 | Renamed, 40 backlinks |
| /products/press-200t.html | /products/hydraulic-presses/200-tonne/ | 301 | Same product, clearer path |
| /downloads/brochure-2017.pdf | /products/brochures/ | 301 | Distributors still link to it |
| /diwali-offer-2019/ | (none) | 410 | Expired campaign, no links |
Before DNS changes, a script requests all 486 old URLs against the new build and checks that each one lands where the map says in a single step: a 200 for kept pages, one 301 straight to a live page, or a deliberate 410. Expect impressions to wobble for 2 to 4 weeks after launch while search engines recrawl. A steady decline past week six is not a wobble: something in the map is wrong, and the 404 log will usually say what.
The last fortnight before launch
- Crawl the deployment, not the preview. Serve the exact build that will go live and follow every link. A site that works in the editor can still 404 in a different folder structure.
- Review at four widths. Phone, tablet, laptop and large desktop, looking for overflow, tiny tap targets and images cropped around the wrong subject.
- Tab through everything. Menus, dialogs, filters and forms, with visible focus in a sensible order.
- Sweep the words. Placeholder text, dummy email addresses, old company names, unapproved claims and dates that were meant to change.
- Lower the DNS TTL. Drop it to five minutes 48 hours ahead, so the switch, and any rollback, travels fast.
- Prepare the rollback. A full backup of the old site and a written trigger for using it.
After launch: the first 90 days
| When | What to check |
|---|---|
| Launch hour | HTTPS on the real domain, robots.txt, sitemap, forms, redirects, analytics firing |
| First week | The 404 log daily, form delivery, sitemap submitted, crawl errors in Search Console |
| Weeks 2 to 6 | Clicks and positions for the top 50 URLs against the baseline |
| Day 90 | Core Web Vitals from real visits, conversions, and a list of next improvements |
Once the site is stable, point business listings, social profiles and adverts at the new addresses directly. If search is a big part of how customers find you, the 90 day watch is where our growth and search team usually joins in.
The D&C launch habits
The checklist says what to check. These habits shape how the day runs, and most were learned at Hosting Seva, fixing DNS at two in the morning while a customer waited.
- Launch early in the week. Tuesday or Wednesday morning, never Friday afternoon. The exception is a platform that cannot pause, where the quietest hours win.
- Freeze 48 hours out. No new features and no content edits in the two days before go-live.
- Rehearse the cutover. On staging, with the real checklist, until it is dull.
- One reader, one pair of hands. One person reads each step aloud and another does it. Decisions go into the launch channel in writing.
- Agree the rollback trigger in advance. If forms or checkout fail for 15 minutes, we roll back. Nobody debates it in the moment.
- Keep the old site reachable. On a password protected subdomain for 30 days, for the questions nobody thought to ask.
When we moved Ekeeda’s learning platform to the cloud, we rehearsed the cutover three times and ran the weekend from a paper checklist of 64 steps in my handwriting. On Monday morning learners logged in to pages three times faster, and nobody called support. If launch day is exciting, something went wrong in the weeks before it.
The short version
- Every public URL listed, each with a decision
- Search Console baseline exported
- An owner named for DNS, hosting, email and analytics
- Real content in the designs
- A 301 map tested for single hops
- Performance budgets checked on every change
- Forms tested from a phone to a real inbox
- Staging noindex removed on the live domain
- DNS TTL lowered, rollback trigger written down
- A 90 day search watch in the calendar
A rebuild is a migration
The design is what everyone sees on launch day. The quieter work decides whether the rebuild worked: keeping what earned its place, retiring what did not, and making sure every route, form and record survives the move. Get that right and the new site starts with the old one’s reputation instead of starting from zero.
Our rebuilds and migrations follow this list line by line, and it works just as well in house. For a second pair of eyes on a plan, send us your current site and we will tell you what we would check first.