Website Redesign Checklist for Growing Businesses in 2026

Start with a written problem statement, not a mood board. 'The website looks dated' is a symptom. The problems underneath are more specific and more useful: the site describes services the business stopped selling, two new services have no pages, sales staff re-explain the same process on every call, a price change needs a developer, or the site cannot support a new city or language. Each implies different work, and some do not need a redesign at all.

Name the type of change you are making

'Redesign' covers very different levels of risk. Be explicit about which of these you are doing, because every one stacked on another adds things that can break.

• Visual refresh: new styling and components on the same pages, URLs and content. Lowest risk, and limited upside if the problems are structural.
• Structure and content redesign: a new sitemap, rewritten pages, merged or removed content. Most of the search and conversion risk sits here.
• Replatform: a new CMS or framework underneath, which can change URL patterns, metadata output, image paths and form handling without anyone deciding it should.
• Domain move: a new domain, a merged subdomain or a rename. It needs its own migration plan, not a line in the design scope.

Stacking all four is sometimes unavoidable. When it is optional, separating them makes problems traceable: if enquiries fall after a launch that changed only the design, you know where to look.

Write outcomes, guardrails and non-goals

Name two or three outcomes the redesign should change, such as qualified enquiries for one service line, fewer wrong-fit enquiries, or pages marketing can publish without a developer. Then name the guardrails, the things that must not get worse: organic clicks to pages that already rank, form completion, and existing clients' ability to find a login or support contact. Finally, list the non-goals. A website project that is also expected to fix pricing, hiring and a stalled ad account will fix none of them properly.

Give one person the final decision

Redesigns tend to stall in review, not in production. Name one decision-maker, agree who advises on what (sales on objections, operations on process claims, whoever owns compliance on legal wording) and set the approval path before the first wireframe. Feedback can then be judged against the problem statement and the page requirements instead of personal taste, which only works if both exist in writing.

A baseline is a dated snapshot of how the current site performs, captured before any change goes live, so that after launch you can tell a real loss from ordinary noise. Without one, every post-launch discussion becomes opinion: the new site feels quieter, the old one felt busier, and nobody can prove either.

Check the tracking before trusting it

Confirm the current measurement is honest before exporting anything. Submit each form and check that exactly one conversion is recorded. Tap the call and WhatsApp links on a handset and see whether they are counted. Look for internal visits that should be filtered, spam inflating enquiry counts, and events firing twice because two tags were installed years apart. Where tracking was broken, note when and how, and treat that period as unreliable rather than as history.

What to capture

• Organic clicks, impressions and queries by page from Google Search Console. It holds sixteen months of performance data, so export it instead of assuming it will be there later.
• Sessions, engagement and key events by landing page, channel and device from your analytics tool.
• Enquiries by type and source: each form, calls, WhatsApp chats, emails and bookings, plus how the team counts any channel the site cannot track.
• Lead quality from the CRM or the sales team: which enquiries became real conversations, by service and source.
• Indexed page counts from the page indexing report, and the current lists of 404 errors and redirects.
• Field performance data for key templates, and a lab test of a service page and an article on a mid-range phone.
• Internal site-search terms, if the site has search. They are a ready-made list of things visitors could not find.

Make the later comparison fair

Agree the comparison windows now. A seasonal business should compare the launch period with the same period last year as well as with the weeks before launch. Keep a dated log of campaigns, price changes, press coverage and outages, because any of them can move the numbers after launch and be mistaken for the redesign's effect. Store exports where the whole team can reach them, with the date range and filters in each file name.

The content inventory is the document every later decision depends on. The sitemap, the content plan, the redirect map and the launch checks all start from it, so it has to list every URL the site has, not just the pages in the menu.

Combine sources, because none sees everything

• A full crawl of the live site with a crawler such as Screaming Frog, following internal links.
• Every URL in current and old XML sitemaps.
• Analytics landing pages and Search Console pages with impressions, which expose orphan pages that nothing links to.
• A CMS export including unlisted campaign pages, drafts and pages hidden from navigation.
• Uploaded files such as brochures, price lists and application forms that people link to directly.
• Existing redirect rules in the server, the hosting panel or a CMS plugin, which reveal earlier migrations.

Record the fields you will use

For each URL, capture the status code, template, title, meta description, main heading, canonical, indexability, organic clicks and impressions for the baseline period, enquiries started, referring sites, internal links pointing in, the date it was last meaningfully updated and its content owner. Leave three columns empty for later: the decision (keep, improve, merge or remove), the destination URL and the reason.

Expect surprises. Inventories regularly surface campaign landing pages still receiving paid clicks, duplicate service pages written by two different people years apart, tag archives creating thin indexable pages, and PDFs that rank for terms no HTML page covers. Each needs a decision, and a decision is only possible once the URL is on the list.

Some URLs matter far more than their place in the menu suggests, and they are the easiest to damage because their value is invisible on the page itself. It lives in search results, on other people's websites and in places the business put the link years ago.

Pages with search demand

Sort the inventory by organic clicks and impressions, then read the queries behind each strong page. Note what the page actually answers: its sections, its questions, the terms it uses. That is what earned the visibility. A page ranking for a specific question that gets rewritten into a short brand statement has lost the very thing search engines were sending people to read. Mark these pages as search-sensitive in the inventory.

Pages with links and offline references

The Links report in Search Console and a backlink tool show which URLs other sites point to. Then look for the references no tool can see:

• Brochures, packaging, vehicle graphics and signage with a printed URL or QR code.
• Email signatures, newsletter templates, proposals and invoices.
• Google Business Profile, marketplace and directory listings, and social profile links.
• Final URLs in active ad campaigns.
• Partner, supplier, association and event websites that list the business.

Every one of these needs a destination in the redirect map, even when its page is being removed. A link that lands on an error wastes the reference and whatever trust came with it.

Know when the migration needs a specialist

If the audit uncovers years of blog content, several earlier migrations layered on top of each other, more than one language or a planned domain change, bring in migration planning from an SEO specialist now, while the sitemap is still a draft. Correcting a URL structure on paper is cheap; correcting it after launch means running a second migration.

A journey map shows how real people move from arriving to acting: where they enter, what they need to confirm, where they act and where they give up. The audit version should come from evidence, not from how the team hopes the site is used.

Sources that show real behaviour

• Landing pages and the pages viewed next, split by device.
• Form analytics showing the field where people abandon.
• Session recordings of mobile visits, watched against a specific question.
• Conversations with whoever answers enquiries: what callers ask first, what they misunderstood, what they could not find.
• WhatsApp chats, emails and support tickets that begin with some version of 'I couldn't find'.
• A short task test with a handful of people who resemble your buyers: find a service, decide whether you fit, make contact.

Include the visitors who are not buying

Prospects are not the only people who use a business website. Existing clients look for a login, an invoice or a support contact. Candidates look for careers. Suppliers look for a procurement contact, journalists for a press page. These paths are rarely in anyone's brief, which is exactly how they get broken: the careers link drops out of the new footer and applications quietly stop.

Write down problems, not solutions

The output is a list of observed breaks, each tied to evidence: mobile visitors from service pages reach the form and leave at the budget field; callers ask whether you work outside the city because no page says so. Resist solving them in the audit. Fixes belong in the strategy and design work, and a separate guide covers five conversion leaks and their fixes in detail. The job here is to make sure the redesign answers the breaks you actually found rather than the ones someone assumed.

The preserve list is a short, signed-off record of what the redesign is not allowed to lose. It turns audit findings into constraints that designers, writers and developers can see, and it is where search preservation is decided, because a URL or section nobody wrote down is the first thing to vanish in a rebuild.

Keep URLs by default

A URL that exists, ranks or is linked should stay exactly as it is: same path, same trailing-slash convention, same letter case. Change it only with a stated purpose, such as a page merging into another, a URL naming a service you no longer offer, or an old platform that produced paths no person can read. Tidier folders are not a purpose on their own. Any change that does happen gets a permanent redirect and a row in the redirect map, with the reason beside it.

What else goes on the list

• Substance on search-sensitive pages: the questions answered and the sections that match their queries, even as the writing improves.
• Working metadata: titles and descriptions on pages that perform, unless a rewrite has a reason.
• Structured data that validates today, and the business details it describes.
• Earlier redirects, updated to point straight at final destinations.
• Measurement continuity: the same analytics property, tag manager container, ad conversion tags and call tracking, so history continues instead of restarting.
• Search Console and Bing Webmaster Tools verification: a verification tag in the old theme's header disappears with the theme, while DNS verification survives a rebuild.
• Enquiry plumbing: form recipients, CRM field mappings, autoresponders, WhatsApp numbers and call routing.
• DNS records if hosting changes, including mail and email-authentication records, copied before the nameservers move.
• Legal pages and consent settings, changed only with their owner's approval.
• Permissioned proof: testimonials, client logos and case studies you have written consent to use.

Have the decision-maker sign the list. When a design proposal later conflicts with it, the conversation becomes whether changing a preserved item is worth it and how to protect what it carries, not whether it mattered in the first place.

Strategy only helps a redesign once it becomes something a page can be checked against. A positioning slide changes nothing. A page requirement stating what the page must prove, to whom, and what the reader should do next shapes every wireframe, paragraph and component after it.

Audiences and the question each arrives with

List audiences by what they are trying to decide rather than by demographics. A growing services business might serve a founder comparing providers, a marketing manager building a shortlist to present upward, a procurement contact checking credentials and an existing client considering a second service. Each arrives with a different first question, and a page trying to answer all of them at once tends to answer none clearly.

Positioning in a form writers can use

Write it as four plain lines: who the business is for, what it does for them, why a buyer would choose it over the realistic alternatives (including doing nothing or hiring in-house), and what proof supports that. Add the objections the sales team hears, word for word. They become section headings, FAQs and proof requirements later.

The page requirement card

Before design starts, every page in the new sitemap gets a short card:

1. Purpose: the one job the page does.
2. Primary audience, and the question they arrive with.
3. The answer the page gives in its opening lines.
4. Primary action, plus one secondary action for people not ready yet.
5. Proof required: which case study, credential, process detail or example.
6. Search target from the audit: the queries it should satisfy, or none for utility pages.
7. Content status: exists, needs improving, or must be written.
8. Owner and URL, keeping the existing URL wherever the page continues.

Scope the budget from the requirements

Cost follows complexity more than page count: the number of distinct templates, how much content is written from scratch, the size of the URL migration, integrations with CRM or booking systems, and the number of review rounds. Ask any provider to price those drivers separately. For Branditify's own scope, the published starting prices are the reference point; whoever quotes, the migration and testing work should appear as line items rather than being folded into a design fee.

Build the new sitemap from three inputs: the content inventory, the page requirement cards and the journey problems. Starting from the old navigation tends to reproduce its mistakes in a better typeface.

Group pages the way buyers decide

Buyers do not think in your internal departments. Group services by what the buyer is trying to get done, give each separately bought service its own page, and create industry or location pages only where the content genuinely differs: different problems, different proof, a different process. City pages that swap only the place name give visitors nothing new and give search engines a reason to ignore the set.

Give every page a status

Next to each page's parent and URL, record its status:

• Continues: an existing page on the same URL, content kept or improved.
• Moves: an existing page on a new URL, allowed only with a recorded reason and a redirect.
• Merged: absorbed into another page, with its URL redirected to the survivor.
• Split: the old URL stays with its closest successor, and the sibling pages are new.
• New: a gap identified by the requirements or the journey work.
• Removed: no replacement, and no redirect unless a genuinely equivalent page exists.

That status column makes the migration stage manageable. By the time development starts, half the redirect map has already been written.

Test the structure before designing it

Keep important pages a short click path from the homepage and reachable through ordinary links, not only through site search or a filtered listing. Write navigation labels in buyer language rather than internal names. A simple tree test, asking a few people where they would look for a particular service using only the menu labels, catches confusing groupings while they still cost nothing to change. Plan breadcrumbs that mirror the hierarchy; they help visitors orient themselves and help search engines understand how pages relate.

A conversion path runs from the page someone lands on to the moment a person at the business replies. Most briefs specify only the button. The path is the button, the form, what happens on submit, where the data goes and who picks it up.

Match the next step to readiness

• Ready to talk: a quote request, call or WhatsApp chat, easy to find from every service page.
• Still evaluating: case studies, process detail, pricing direction and FAQs, each leading back to the same primary action.
• Researching: guides that link into the relevant service page instead of ending at the last paragraph.
• Existing clients: a direct route to login, support or billing that never passes through a sales form.

Decide what happens after the click

Settle these before the form is designed, because they change the fields:

1. Which details sales genuinely needs to route and qualify an enquiry, and which can wait for the first conversation.
2. Hidden fields that record the page, the service and any campaign parameters.
3. A thank-you page explaining what happens next, with a response time only if the team can honour it.
4. A confirmation email to the enquirer, and a notification to a named person or a monitored shared inbox.
5. A CRM record carrying source and service, with one person responsible for the first reply.

Phone and WhatsApp links need the same care: the number in full international format, a pre-filled message where it helps, a tracked event, and someone available to answer during the hours the page implies.

Every page in the inventory gets one of four decisions, recorded with a reason. Deciding page by page is slower than rewriting everything, but it protects what already works while clearing out what does not.

The four decisions

• Keep: accurate, performing content that migrates faithfully to the new template on the same URL.
• Improve: the right page on the right URL with a weak answer, thin proof or outdated detail, rewritten in place without changing its topic.
• Merge: two or more pages competing for the same question, folded into the stronger URL (usually the one with more clicks and links) with the others redirected to it.
• Remove: no traffic, no links, no enquiries and no ongoing purpose.

Then add a fifth list: content to create, drawn from gaps in the page requirements and from the questions sales answers by hand.

Rewriting a page that already ranks

Improvement is where good intentions cause losses. Before rewriting a search-sensitive page, list the queries it receives and the headings and questions it currently covers; after the rewrite, compare the two. The new version can be shorter, clearer and better organised, but if a section matching an important query has gone, restore it or accept the risk knowingly. Keep dates honest, changing the updated date only when the content has meaningfully changed.

Moving content is real work

Someone has to carry over body copy, image alt text, tables, embedded video, downloads and in-body links, many of them hard-coded to old URLs. Assign the work, size it from the inventory, and check each migrated page against the original rather than trusting that an import worked.

Write content, or at least a solid draft, before high-fidelity design. Layouts built around placeholder text break when real headings, real proof and real caveats arrive, and they hide the fact that some pages have nothing to say yet. If the internal team cannot produce this volume of writing alongside their day jobs, plan specialist copywriting support from the start rather than discovering the gap halfway through the build.

Service pages

A service page has to let someone confirm quickly that you do the specific thing they need for someone like them, then give them enough to act. The opening lines should name the service and who it is for in plain words. Below that, a strong service page covers what is delivered, how the work runs, what is and is not included, what affects cost, proof related to this service rather than the business in general, the questions buyers ask before committing, and the next step. A dedicated guide goes deeper on service page structure for search and conversion.

Proof a sceptical reader could check

Case studies need permission, specifics (the brief, the work, the deliverables) and restraint about outcomes you cannot evidence. Testimonials need a real name and role or a traceable source. Certifications and memberships should be current. Place each piece of proof beside the claim it supports rather than in a logo strip at the bottom. Where a service is new, show the process and deliverables in detail rather than inventing a result.

FAQs taken from real conversations

Collect questions from sales calls, enquiry emails, WhatsApp chats and support tickets, in the words customers use. Answer each so it makes sense without the rest of the page. Put the answers in the page's HTML rather than loading them only after a click, and keep them on the page they belong to rather than on one catch-all FAQ page.

Passages that can be quoted

Search engines and AI answer tools often surface a passage rather than a whole page, so write important sections to stand alone: a heading that names the question or topic, a first sentence that answers it, then the detail, conditions and exceptions. Define terms once, name things consistently, and keep the business name, services and locations identical across the site and external profiles. The same discipline underpins answer engine optimisation, which a separate guide explains for business owners.

Judge design at this stage on whether each template does the job its requirement card describes, on a phone, for everyone who might use it. Visual quality matters because people read it as a sign of care, but it is the final layer, not the foundation.

Hierarchy that follows the requirement card

Read only the headings of a template, in order. If they tell the page's story (what it is, who it is for, the proof, the next step), the hierarchy works. If a decorative section outranks the answer, the hierarchy is wrong however polished it looks.

Phone first, then wider

Design key templates at phone width first and expand from there. Keep primary actions within thumb reach, make tap targets generous, give each field the right keyboard (numeric for phone numbers, email for email addresses) and support autofill. Nothing important should depend on hover. A sticky call or WhatsApp bar can help on service pages, provided it never covers content or the buttons of the consent banner.

Trust designed in, not added later

Trust signals are layout decisions: real photographs of the team and the work instead of stock imagery, visible contact details, a physical address only if customers can actually visit it, identical business details in the footer and on the contact page, and proof placed where decisions happen.

Accessibility basics that belong in the design

• Text contrast meeting WCAG AA, which is 4.5:1 for normal-size text, including text over images and in brand colours.
• A visible focus state on every link, button and field, in a logical keyboard order.
• Visible field labels rather than placeholder text that disappears when typing starts, and error messages that say what to fix without relying on colour alone.
• A real heading outline with one main heading per page, and meaningful alt text on informative images.
• Captions or transcripts for video, respect for reduced-motion settings, and layouts that survive enlarged text.

Components before pages

Build a component library before building pages: buttons, cards, form fields, proof blocks, FAQ blocks, section headers, navigation and footer, each with defined states for hover, focus, error, disabled and loading, plus written rules such as maximum heading length. Base them on shared tokens for colour, type and spacing. A system keeps the fortieth page consistent with the first, lets marketing assemble new pages without inventing patterns, and turns later changes into a single edit.

Development is where search, conversion and measurement decisions become real, or quietly disappear because nobody wrote them into a ticket. Treat each item below as a requirement with an owner and a test.

A CMS the team can actually run

Configure the CMS around who edits the site and how often. Editors need roles, previews and structured fields for what matters to search: title, meta description, canonical override, an index control, a social sharing image, and fields that generate structured data instead of hand-pasted code. Redirects should be manageable without a deployment. If you commission the work externally, ask for a website build scoped around these requirements, covering templates, fields, redirects, forms and events, rather than a page count and a number of design revisions.

Build and review on a staging site behind a password. Tie noindex and robots settings to the environment so production cannot inherit them by accident.

Performance budgets per template

Set a budget for each template and test it on a mid-range Android phone over a throttled connection, not only on an office laptop. The usual culprits are predictable:

• Images served oversized or in older formats, without responsive sizes or explicit dimensions to stop the layout jumping.
• Lazy loading applied to the main hero image, delaying the largest element on screen.
• Web fonts loaded in too many weights, without subsetting or a fallback that keeps text visible.
• Chat widgets, heatmaps and several ad pixels loaded on every page whether needed or not.

Lab tools diagnose problems. Google's Core Web Vitals reports use field data from real visitors, which takes time to accumulate after launch.

Forms that cannot lose an enquiry

• Validation on the server as well as in the browser, with each error shown beside its field.
• Spam protection that does not punish people: honeypot fields and rate limits before any puzzle.
• Notifications sent through an authenticated email service so they are not filtered as spam.
• Every submission also stored in the CRM or a database, so a failed email never means a lost lead.

Integrations and analytics

List each integration (CRM, WhatsApp Business, booking engine, payment gateway, email marketing, call tracking) with its trigger, the data it moves, its owner and how a failure alerts someone. Write the analytics event plan before development: event names, parameters, which events count as key events and where consent applies. Test events on staging in debug mode without letting staging traffic pollute production reports, and set up cross-domain measurement wherever booking or payment happens on another domain.

The redirect map is the working document of the migration: each old URL that matters, the new URL it should reach, the redirect type and the reason. It grows out of the inventory and the sitemap statuses, and it should be complete and tested before launch day rather than improvised during it.

Which URLs belong in the map

Include every URL that returns a page today, every URL with search impressions or visits in the baseline period, every URL with external links, every URL listed in current or old XML sitemaps, linked PDFs and images, campaign landing pages, and the old addresses behind existing redirects. That last group matters: when a URL redirected in an earlier migration now points at a page that is moving, update the old rule to reach the final destination directly instead of creating a chain.

Rules for choosing each destination

• Send each URL to the page that meets the same need (the same service, question or product) even if the wording differs.
• Do not default to the homepage. A visitor who followed a link about one service lands on a page that does not mention it, and search engines can treat an irrelevant redirect much like a missing page.
• Use permanent redirects (301 or 308), set on the server or at the edge rather than with JavaScript or a meta refresh.
• Make it one hop from old URL to final page, with no chains and no loops.
• Resolve http and https, www and non-www, trailing slashes and letter case within that same hop.
• Use pattern rules only where a whole section moves intact, then test a sample from every pattern.
• Where no equivalent exists, return a 404 or 410 as recorded in the sitemap statuses, with a helpful error page.

Leave redirects in place for as long as you can. Links, bookmarks and printed codes do not expire when the project closes.

Test the map twice

Deploy the rules to staging and run the full old URL list through a crawler in list mode against the staging host. Every row should return one permanent redirect to a page that returns 200 and matches the map. Run the same list against production within the first hour of launch, because server configuration, CDN rules and caching can differ between environments.

When the domain changes too

A domain move adds steps. Every old-domain URL redirects to the matching path on the new domain, the old domain stays registered and serving those redirects, both properties stay verified in Search Console, and the Change of Address tool is used once the redirects are live.

Redirects tell search engines where pages went. Metadata, canonicals, structured data, internal links and the XML sitemap tell them what the new pages are and which version counts. A migration can get every redirect right and still send mixed signals through any of these.

Titles, descriptions and headings

Carry over titles and meta descriptions for preserved pages unless there is a reason to rewrite them, and record that reason. Make sure new templates cannot generate duplicates; one default title repeated across every page is a familiar rebuild fault. A crawl of staging sorted by title and description shows duplicates and blanks quickly. Each page needs one main heading that matches its purpose.

Canonicals and indexing directives

Every indexable page should carry a self-referencing canonical using the absolute production URL. Watch for canonicals pointing at the staging domain, at an old URL that now redirects, or at the homepage from every page, and for a second canonical tag injected by a plugin. Decide deliberately which pages are noindexed, such as thank-you pages and internal search results, and confirm no template applies noindex by default. Multilingual sites also need hreflang annotations that reference final URLs in both directions.

Structured data that matches the page

Validate structured data once per template with the Rich Results Test and the Schema Markup Validator. A service business typically needs Organization, BreadcrumbList, Article markup on guides, and LocalBusiness only with a real, public business address. Mark up FAQs only where the questions and answers are visible, and never mark up ratings, prices or reviews readers cannot see. For anyone new to the vocabulary, a primer explains structured data in plain language.

Internal links and the XML sitemap

Update navigation, footer, buttons and every in-body link to final URLs rather than old addresses that redirect. Imported body copy is the usual source of stale links, because it stores them as fixed text. Crawl staging and export every internal link that returns a redirect or an error. Generate the XML sitemap automatically, listing only live, indexable, canonical URLs with no redirects, noindexed pages or thank-you pages, and reference it in robots.txt. Then read the production robots.txt line by line: a rule written to keep crawlers off staging does exactly the same on the live site.

The pre-launch checklist is a go or no-go gate, not a formality. Run it on staging when the build is complete, then repeat the search, form and tracking checks on production straight after launch, because hosting, caching and environment settings change between the two. Every item needs an owner and evidence, whether a crawl export, a screenshot or a test submission, so that 'checked' means someone can show it.

Search signals

Test the whole redirect map, not a handful of favourite pages, and confirm every destination is a live page. Compare titles, descriptions and canonicals for preserved pages against the inventory export row by row. Validate structured data on one page of each template. Crawl for internal links that hit redirects or errors, and confirm the sitemap holds only live, indexable URLs from the new structure. Finally, search the production HTML, sitemap and image paths for the staging hostname, which hides in places a visual review never reaches.

Enquiries and tracking

Submit every form, and every variant of it, with a clearly labelled test entry. Confirm the email reaches the real recipient rather than only the developer, and check spam folders. Confirm the CRM record, the source fields and the autoresponder. Tap each phone and WhatsApp link on a handset. In analytics debug mode, confirm every key event fires exactly once, and that consent choices change what loads in the way you intended.

Devices, content and errors

Check key templates on real phones, including at least one iPhone and one mid-range Android, in more than one browser. A resized desktop window does not reproduce touch, on-screen keyboards, real network speeds or how a handset renders type. Search the site for placeholder text, test links and dummy copy. Run a broken-link check across every page, and request a made-up URL to confirm the error page returns a genuine 404 status and helps the visitor onward.

Indexing controls and the launch itself

Confirm the staging noindex, the password protection and any blanket robots.txt block are gone from production, and that the certificate covers every hostname variant. Take a full backup of the old site, keep a browsable archive of it, and agree a rollback plan. Freeze edits on the old site between the final content export and launch. Choose a launch time when the people who can fix redirects, forms and hosting are available for the days that follow, not the evening before a holiday or the start of your busiest season. Then hold a short go or no-go call with the owners of search, forms, tracking and the business decision.

Launch opens the verification stage rather than closing the project. The first weeks show whether search engines have understood the move and whether enquiries still arrive through every path, while problems are still cheap to fix.

On launch day

• Re-run the old URL list against production and fix every row that does not match the map.
• Check robots.txt, the absence of noindex on key templates and the live XML sitemap, then submit the sitemap in Search Console and Bing Webmaster Tools.
• Inspect the most important URLs in Search Console to confirm Google can fetch them and sees the intended canonical.
• Send a real enquiry through each primary form and follow it to the inbox and the CRM.
• Update Google Business Profile, ad final URLs, social profiles and email signatures that pointed at changed URLs.

The first weeks

Watch the page indexing report for rising numbers of pages not found, URLs reported as redirects that should be live pages, and duplicates where Google chose a different canonical from yours. Review a 404 log or monitor daily at first; each genuine old URL returning an error is a missing row in the redirect map, and adding it is quick. Ask the sites behind your most valuable links to update them. Expect some movement in search positions while changed URLs are recrawled. What matters is the direction over the following weeks and whether losses cluster on particular pages.

Compare against the baseline, page by page

A steady site total can hide real damage, such as one valuable service page losing its main query while blog traffic rises. Compare each search-sensitive page against its baseline using the windows agreed before launch. Do the same for enquiries by form and source, and ask sales about lead quality, because a redesign can hold the enquiry count steady while changing who sends them. When a page drops, check in order: is it indexed, does it return 200, is the canonical right, did the rewrite or title lose what matched the query, did internal links to it fall away, and did tracking change? A fall in conversions is sometimes a fall in measurement.

Keep one backlog after the launch

Once results settle, run a single prioritised list: post-launch fixes, pages deferred from the launch set, tests suggested by the journey problems and improvements for pages trailing their baseline. Review search-sensitive pages and forms on a fixed schedule. A new site begins to decay the day it goes live unless there is ongoing maintenance with a named owner covering platform updates, backups, broken-link checks, form tests and small content corrections.