A website rebuild often begins with a sensible concern: the current site feels outdated, difficult to use or smaller than the business it represents.

The risk is treating the old website as a design problem only. It is also a collection of URLs, content, search history, forms, tracking decisions, integrations, permissions and habits inside the company.

This checklist covers the work that should happen around the new screens.

Before design begins

Record the current site

Create an inventory of every public URL. Include pages that are not in the navigation, old campaigns, downloadable files and routes that appear only in search results.

For each URL, record:

  • current title and purpose;
  • status code;
  • organic traffic or backlinks where available;
  • owner;
  • whether the content should be kept, rewritten, merged, redirected or retired.

A crawler can find most pages. Search Console, analytics and server logs may reveal others.

Save a visual and content archive

Take full-page screenshots of important routes. Export or copy the text. Download approved images and documents. Record the current navigation and footer.

This is not nostalgia. The archive helps resolve questions after launch and protects content that may be difficult to recover once the old system is removed.

Decide what the website is expected to do

Write down the priority audiences and actions. For an agency site, that may be understanding services, seeing relevant work and starting a qualified conversation. For a member organisation, it may include registration, payment and secure access.

The page list should follow those decisions, not the structure of the old CMS.

Confirm ownership and access

Before the build reaches launch week, know who controls:

  • the domain registrar;
  • DNS;
  • hosting;
  • CDN;
  • SSL;
  • email;
  • analytics;
  • Search Console and Bing Webmaster Tools;
  • social-platform verification;
  • form endpoint;
  • payment gateway;
  • third-party scripts;
  • image and font licences.

Do not wait until the launch call to discover that the only DNS administrator left the company two years ago.

During content and design

Write the real content early

Placeholder copy creates placeholder layouts. A headline that is seven words behaves differently from one that is twenty-seven. A case study with real evidence needs different pacing from a card with three generic sentences.

Write enough of the final content to test hierarchy, line length, mobile behaviour and visual rhythm.

Protect useful URLs

A cleaner new URL is not automatically better than a well-established old one. Keep useful routes where practical. When a route changes, map it to the most relevant new page with a permanent 301 redirect.

Do not redirect every retired page to the homepage. That is unhelpful to visitors and search engines.

Design the awkward states

Include:

  • long names and headings;
  • missing images;
  • empty search or filter results;
  • validation errors;
  • unavailable services;
  • slow connections;
  • a disabled integration;
  • a 404 page;
  • keyboard focus;
  • reduced motion;
  • browser zoom at 200 percent.

A design system is more credible when it accounts for what happens outside the perfect screenshot.

Use real mobile priorities

Mobile design is not a desktop page stacked into one column. Decide what belongs first, which images can crop differently, how navigation behaves and whether a large interaction still makes sense on touch.

Test with a mid-range phone profile and a slower network, not only a modern laptop in responsive mode.

During development

Build semantic structure

Use headings in a logical order, real navigation landmarks, buttons for actions, links for navigation and form labels that remain visible. Semantic HTML improves accessibility, resilience and search understanding.

Keep JavaScript in proportion

Core content and navigation should exist in HTML. JavaScript can enhance menus, filtering, motion and form assistance. It should not be required to reveal the entire page.

Set performance budgets

Agree limits before the page becomes heavy.

A practical target for a focused marketing site might include:

  • a compressed hero image appropriate to the viewport;
  • limited font files;
  • no autoplay video;
  • small vanilla JavaScript;
  • no unused framework bundle;
  • no third-party marketing scripts until their value and consent model are clear.

Measure Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. Current “good” thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1 at the seventy-fifth percentile of real visits.

Validate forms honestly

A form with no endpoint should not display “Thank you, your message has been sent.” Use a working provider, a static-host form feature, or an explicit email and WhatsApp composer. Test the destination, spam protection, privacy copy and recipient inbox.

Add metadata page by page

Each indexable page needs a unique title, description, canonical URL, Open Graph data and useful internal links. Structured data should describe what is visible rather than claim categories the page cannot support.

Create the operational files

At minimum:

  • robots.txt;
  • sitemap.xml;
  • favicon and app icons;
  • web manifest where useful;
  • 404 page;
  • redirects;
  • security headers or host configuration;
  • privacy, terms, cookie and accessibility pages;
  • verification insertion points;
  • an asset licence record.

Before launch

Crawl the final deployment structure

Serve the exact folder that will be uploaded and follow every internal link. Check status codes, canonicals, images, CSS, scripts, downloadable files and redirect targets.

A local source folder can work perfectly while the cPanel folder structure still produces 404s. Test the deployment shape, not only the editor preview.

Review every page visually

Capture the main routes at phone, tablet, laptop and large desktop widths. Look for:

  • horizontal overflow;
  • text collisions;
  • accidental empty space;
  • tiny tap targets;
  • images cropped around the wrong subject;
  • fixed elements covering content;
  • headings with single orphan words;
  • inconsistent footer or contact information.

Test keyboard and assistive behaviour

Tab through the navigation, dialogs, filters, accordions and form. Ensure focus is visible and follows a sensible order. Check that menus close with Escape and return focus correctly. Review page landmarks and image alternatives with a screen reader where possible.

Review the words one final time

Search for:

  • placeholder text;
  • “TBD”;
  • dummy email addresses;
  • empty links;
  • old company names;
  • unapproved client claims;
  • repeated AI-style phrases;
  • spelling variations;
  • dates that were meant to be updated;
  • policy statements that no longer match the actual scripts on the site.

Prepare rollback

Keep a complete backup of the previous public site and know how to restore it. A launch plan without a rollback plan assumes the one thing production never promises: nothing unexpected will happen.

After launch

Verify the public site

Check the real domain over HTTPS. Confirm the homepage, navigation, forms, redirects, sitemap, robots file, social previews and analytics decision.

Watch the first days closely

Review 404 logs, form delivery, Core Web Vitals when data becomes available and feedback from the people actually using the site. Fix defects first. Put larger ideas into a planned improvement list.

Update external properties

When the site is stable, the owner can update Search Console, Bing, social profiles, business listings and advertising destinations. This is also the point to request platform reviews or verification, using the exact public identity shown on the site.

A rebuild is a migration

The design is the most visible change. The quality of the rebuild is often determined by the less visible work: preserving what matters, removing what does not, and making sure every route, form and decision survives the move.