The website redesign checklist for search, trust and conversion.

Define what the redesign must preserve and improve

A website redesign is a commercial transition. It changes how buyers understand the business, how they find relevant information and how they make contact. It can also change URLs, content, forms, measurement and the systems that receive enquiries. A visually improved site can still lose useful demand if those relationships are not preserved. The project brief should therefore describe the business outcomes and continuity requirements alongside the design direction.

Start with the pages and journeys that already matter. Which services generate qualified enquiries? Which case studies help sales establish credibility? Which articles attract relevant discovery or support a later decision? Which forms and integrations work reliably? Preserve that knowledge before creating the new information architecture. The purpose is not to keep every old page unchanged, but to understand what would be lost if it disappeared.

Agree the improvements the redesign is expected to deliver. These may include clearer service scope, stronger proof, fewer steps to enquiry, better mobile usability and more reliable attribution. Give each improvement an acceptance criterion. “More premium” can guide the visual language, while “a service enquiry can be completed on the service page and arrives with its source context” can be tested directly.

This guide is a working checklist for leaders managing a redesign with internal teams or an agency. It covers discovery, architecture, migration, conversion, testing and the first weeks after launch. It is designed to make responsibilities and decisions visible. Use it to commission a controlled transition that improves the buying experience while protecting the information and systems the business already depends on.

Inventory the existing site before changing its structure

Build a list of public URLs from the site, sitemap and available search or analytics records. Include service pages, case studies, articles, campaign destinations, downloadable assets and utility pages. Identify pages that are linked from advertising, email campaigns, professional profiles or important external sources. A page that is absent from the main navigation can still be commercially important.

For each URL, record its purpose, content type, current title, principal heading and intended buyer action. Add available performance evidence such as relevant visits, enquiries or search visibility, with the reporting period. Note whether the page contains unique expertise, client proof or information that should survive in another form. Do not decide solely on traffic volume; a low-volume page may be important to a high-value buying decision.

Inventory the assets and integrations separately. Collect logos, client portraits, screenshots, PDFs and the source of each public claim. Record the form destination, required fields, validation, consent, spam controls and notification recipients. Identify analytics, advertising tags, CRM connections and scheduling tools. A redesign project frequently inherits more operational dependencies than the visual mockup reveals.

Create an ownership map. Know who controls the domain, DNS, hosting, CMS, email delivery and third-party accounts. Confirm that the business has the required access before the launch window. Store backups and recovery information appropriately. The project should not discover at the final step that a former supplier controls an essential account or that the team cannot restore the previous working site.

Design the new architecture around distinct buyer needs

Give the homepage a clear role: explain the business, establish credibility and route the visitor to the most relevant service or evidence. Service pages should answer the commercial and practical questions specific to that engagement. Case studies should show the situation, work and properly scoped results. Insights should help the buyer understand a consequential problem and connect naturally to a relevant next action.

Keep the structure compact where needs overlap. A business does not need a separate page for every minor variation of “AI visibility” if one substantial service page can explain AEO, GEO and the practical scope clearly. Separate pages are justified when they serve meaningfully different services, audiences or decisions. This makes the site easier to maintain and reduces the chance of contradictory claims.

Use a URL plan with stable, readable paths. Choose a service name that can remain useful as specific tools evolve. Nest articles under Insights and client work under Case Studies where that reflects the actual hierarchy. Avoid unnecessary depth that makes a core service difficult to reach from the homepage. The URL is one part of the structure; navigation and internal links must make the relationship clear to the reader as well.

Write a page brief before design. Include the buyer, principal question, service scope, evidence, objections, primary action and related pages. This prevents an attractive template from becoming an empty container that the team later fills with generic copy. A good architecture makes every page responsible for a useful part of the buying journey.

Create a deliberate old-to-new URL map

Map every important old URL to its intended outcome: retained, redirected to a relevant replacement, consolidated into a stronger page or removed because it has no useful successor. Review the mapping with someone who understands the content and commercial context. Do not send every removed page to the homepage. A visitor following a specific link should reach a destination that meaningfully addresses the original need.

Keep redirects direct where possible. If an old page moves to a new path, avoid unnecessary intermediate hops created by several rounds of migration. Check that the final destination returns the intended page and that internal links point directly to it. Preserve the map as a project artifact so that future teams can understand why a redirect exists.

Google's site-move guidance recommends careful URL mapping, redirects and monitoring during a move. It also explains that migration can involve temporary fluctuations while systems process changes. Google Search Central: site moves with URL changes. Treat the migration as an implementation programme with a review period, not a single publishing click.

Include assets and campaign destinations in the map. A PDF linked from a sales email or an old landing page used in an active campaign may need a stable destination. Check fragments used for important page sections and forms where practical. Record exceptions rather than assuming that a successful homepage load proves the migration is complete.

Choose the platform around the operating model

WordPress, Webflow and Shopify can support different operating needs. Bootstrap is a front-end framework rather than a content management system. The decision should consider who publishes content, how the business sells, what integrations are required and how much technical support will be available. Do not choose a platform solely because a supplier is comfortable with it or because a single feature looks impressive in a demonstration.

For a content-led service business, evaluate the editing experience for service pages, case studies and long articles. Can the team update a testimonial without breaking the layout? Can it add evidence captions, tables and contextual CTAs consistently? Can it maintain titles, descriptions, headings and internal links? These daily operations affect the site's long-term quality more than a one-time animation on the homepage.

Review integration requirements early. Forms may need to preserve service interest, budget, message and source context. Guides may require delivery through an email provider. Advertising and CRM systems may depend on accepted-submission events and lead identifiers. Write these requirements before selecting a template or plugin so that the design can support the actual customer journey.

Ask what the business receives at handover. It should include account ownership, editable content, source assets, documented integrations, field mappings and a clear maintenance path. If a custom component is necessary, understand who will maintain it and how it can be changed. A premium implementation should improve the organisation's ability to operate the site confidently.

Preserve the evidence that makes the business credible

Review every client logo, testimonial and case-study claim before carrying it into the new design. Confirm the correct name, role and image. Keep quotations faithful and use the original portrait or company image where available. Place the feedback where it supports the buyer's evaluation, rather than repeating the same full block on every page without context.

For quantitative claims, preserve the source screenshot or export and the definition of the measure. Show the period, comparison and limitations. If a report contains key events, do not automatically label them unique leads or bookings. If a rankings report covers a fixed keyword set, do not describe it as universal market leadership. Clear captions allow the evidence to be impressive and interpretable at the same time.

Create a reusable evidence component with a concise result, context and a way to inspect the source. The component should work on mobile without making the screenshot unreadable. A visitor can view the summary first and open the original when they want detail. This supports both quick evaluation and a more careful procurement review.

Keep the evidence register connected to the site. Record which pages use each claim so that a later correction can be applied consistently. When source dates or definitions are incomplete, preserve the limitation internally and avoid strengthening the public claim beyond what the record supports. The redesign is an opportunity to improve the quality of the business's proof, not merely its presentation.

Build conversion into the page content

Each service page should make the next step available where the buyer understands the value. A hero CTA can take the visitor to an on-page form. A later diagnostic section can offer the same service-specific action after explaining the problem. A relevant case study can invite the reader to discuss a similar situation. These interventions should follow the content's logic and preserve the service context.

Avoid routing every visitor through a general audit page if they already know what they need. Someone seeking LinkedIn Ads support should be able to enquire about that service directly. A person still defining an AI systems project may prefer a practical guide before a conversation. Support both levels of readiness while keeping the primary action clear. The form and follow-up should match the promise that brought the person there.

Use qualification with respect. Explain the kind of engagement, the inputs required and how scope is agreed. A budget range can help the team prepare, but the wording should remain professional. Distinguish media budget from agency fees and project implementation from ongoing support. Invite a concise description of the business problem so that the first response can be useful.

Put the interventions inside long-form articles. A guide about tracking can introduce the relevant service after explaining a measurement gap, then continue with practical instruction. Keep the broader related-services section and final conversation form where they help the reader. The article should remain valuable even if the person does not enquire; that is part of how it earns trust.

Specify semantic structure and accessible interactions

Use one clear primary heading for the page and a logical sequence of section headings. FAQ questions should be actual headings in the document, with interactive controls that remain usable by keyboard. Do not rely on bold text alone to communicate the structure. The heading hierarchy should help a reader navigate the content and help maintain consistency across templates.

Use descriptive labels for form fields and visible, useful error messages. Ensure that focus is apparent when navigating with a keyboard. Buttons and links should describe the action they perform. Images need appropriate alternative text; decorative images should not create unnecessary noise. A testimonial portrait can identify the person, while a data screenshot needs a nearby textual explanation of the evidence.

Check the layout at narrow widths and with enlarged text. Tables need a readable responsive approach, such as a labelled horizontal scroll region when the comparison cannot fit. Long URLs and form content should not force the whole page wider than the viewport. Keep logos at their natural aspect ratio. A stretched footer logo is a small visual fault that can weaken the impression of care across an otherwise polished site.

Use motion sparingly and preserve control. A manual testimonial row lets the visitor inspect feedback at their own pace. Avoid movement that interrupts reading or makes a form difficult to use. The design should feel composed and responsive, with hierarchy and spacing doing most of the work.

Connect forms and measurement before accepting the build

Document every form type and its backend mapping. Preserve required field names, consent, validation and spam controls when adapting the new frontend. Include the service, budget, message, form identifier, submission page and available internal CTA context. A form that looks correct but loses these fields can leave the sales team with less information than the old site provided.

Test the accepted submission in the destination system. Verify storage, routing, notification and the visible success state. A frontend success message is not proof that an email arrived or a CRM record exists. Separate those checks and record the result. If email delivery is paused in staging, keep that limitation explicit until the chosen provider and recipient have been tested.

Define the measurement success event at server acceptance, with deduplication appropriate to the form system. Do not count a button click, failed request or success-page refresh as a new lead. Preserve guide requests as a separate offer type. The redesign should make it easier to compare forms and content later, rather than creating another collection of unconnected conversion events.

Inspect the analytics payload for personal information. Names, emails and messages should remain in authorised operational systems, not ordinary event parameters or URLs. Use controlled identifiers for pages and CTAs. Verify that a visitor can still submit an enquiry when optional analytics is disabled. The business journey and the optional measurement journey should work together without being confused.

Use staging as a complete rehearsal

Build and review the new site in an isolated staging environment. Keep its content out of search while it is being prepared. Confirm that links, assets, canonical settings and form destinations correspond to the intended environment. A staging page should not accidentally send a visitor to an unrelated production form, and a production launch should not retain staging-only links or noindex directives.

Review representative journeys, then apply systematic checks across the whole site. Representative visual review should include the homepage, a service page, a case study, an article, a guide landing page and the contact form at desktop and mobile widths. Systematic checks should inspect internal links, assets, unique titles, primary headings, duplicate IDs, form labels and intended metadata. The two forms of review address different risks.

Invite the people who will use the site internally to test it. Sales should submit a realistic enquiry and inspect the resulting context. Marketing should edit a case study and an article. The executive sponsor should follow the main buying journey without instructions. Their observations can reveal gaps that a purely technical review misses, such as unclear scope or an unnecessary step before contact.

Maintain a launch issue list with severity, owner and acceptance evidence. Distinguish blocking faults from later improvements. Broken enquiry delivery, missing redirects and inaccessible important pages deserve immediate attention. Minor stylistic preferences can be scheduled without delaying the resolution of consequential issues. The launch decision should be based on an agreed standard rather than fatigue at the end of the project.

Prepare the cutover and recovery plan

Before launch, take the required backups and verify that the team knows how to restore them. Record the current configuration, the planned changes and who can execute each step. Identify the dependencies that might delay the cutover, such as DNS access, certificate readiness or email configuration. Do not assume that the person who approved the design also controls the infrastructure.

Choose a launch window that fits the business's operations and support coverage. Coordinate active advertising destinations and any campaigns that depend on the changed pages. Prepare a short verification sequence that begins with the most valuable customer journeys. The team should know what it will check immediately and what evidence would trigger a rollback or a targeted correction.

Keep the scope of the cutover controlled. Avoid adding unrelated account, email or domain changes simply because the team is already working in the control panel. A migration is easier to diagnose when the intended changes are documented and limited to the project. Preserve the original website until the replacement has passed the agreed acceptance checks.

Define the recovery decision. Some issues can be corrected quickly without undoing the launch; others may prevent the business from receiving enquiries or serving important pages. Assign the person who decides and ensure the required access is available. A recovery plan is a normal part of professional delivery, not a sign that the team expects the work to fail.

Monitor the first month with commercial priorities

Immediately after launch, verify the homepage, principal services, enquiry forms, important redirects and downloadable assets. Confirm that intended public pages are eligible for indexing and that staging restrictions have not carried over. Check analytics and operational records using controlled tests. Record the launch time so later reporting can distinguish pre-launch and post-launch behaviour.

During the first week, review errors, missing pages, form failures and lead routing daily at a cadence appropriate to the site's activity. Inspect actual enquiries to confirm that service and source context arrive correctly. Ask sales whether the new form information helps the first response. Resolve practical faults before drawing conclusions about conversion performance from a short period.

Over the following weeks, review search visibility and traffic alongside the migration map and content changes. Investigate significant movements by page and purpose. Avoid attributing every fluctuation to the redesign without considering seasonality, campaigns or reporting changes. Maintain a record of corrections so the team can understand what happened after launch.

Use the first monthly review to assess both reliability and early commercial signals. Which journeys now work as intended? Which pages attract relevant enquiries? What remains uncertain because the sample or sales cycle is incomplete? Agree a small next scope. The first month should establish a disciplined operating rhythm rather than begin another unstructured redesign.

Run a practical acceptance workshop

Choose six journeys that represent the business. A buyer discovers the homepage and selects a service. A visitor arrives directly from a service ad. A prospect inspects a case-study screenshot. A reader follows an in-article CTA. A guide requester receives the correct asset. A returning buyer uses Contact with a specific service in mind. Assign someone to perform each journey and someone else to verify the resulting record.

Ask the tester to narrate what they believe will happen before clicking. This reveals whether labels and promises are clear. If a button says “Get your report,” the next step should explain the report request rather than unexpectedly becoming a general sales form. If a link offers source evidence, it should open the actual evidence at a readable size. The interface should fulfil its own language.

Use a simple acceptance record: journey, device, expected outcome, observed outcome, issue, owner and retest result. Keep screenshots for visual faults and record identifiers for form tests. Do not include real prospect details in a general project document. The workshop should leave the team with specific corrections and a clear record of what has passed.

End by asking whether the business can operate the site without the original developer present. Can the team edit an Insight, update a testimonial, inspect an enquiry and identify its source? Can it find the redirect map and measurement definitions? If the answer is no, the handover needs more work. Launch readiness includes the organisation's ability to use and maintain the site after the project meeting ends.

Use a page-by-page content acceptance sheet

For each core page, record the intended buyer, primary question and action. Confirm that the first screen names the service or subject clearly. Check that the main explanation answers the questions a serious buyer would need resolved before a conversation. Verify that the evidence belongs to the claim and that the next step is available where the reader is likely to be ready. This content review should happen alongside visual inspection, not after the design is considered finished.

Review headings as an outline. Read only the heading sequence and ask whether it tells a coherent story. A service page might move from the business problem to scope, evidence, implementation, measurement and questions. An article might move from diagnosis to practical steps, examples and a decision worksheet. If the outline is repetitive or vague, the reader will have difficulty finding value even when the paragraphs are well written.

Check the consistency of the offer. The page title, hero, CTA, form heading and first response should describe the same request. A free guide, a visibility report and a paid implementation discussion are different offers. When the labels drift, the business may receive more submissions but begin the relationship with mismatched expectations. Resolve that inconsistency before judging conversion performance.

Verify every factual detail carried into the new page. Company names, roles, dates, service capabilities and platform descriptions should be accurate. If the source material contains conflicting numbers, resolve the conflict or use the narrower supported measure. Preserve the original evidence internally. A redesign is a useful moment to improve the precision of the site's claims instead of copying old inconsistencies into a more polished layout.

Write the launch runbook in executable steps

The launch runbook should identify the person responsible for each change and the person who verifies it. Include the backup reference, intended release version, infrastructure changes, redirect deployment, indexing settings and the first customer journeys to test. Use steps that can be completed and recorded, rather than broad statements such as “check SEO” or “test forms.” The document should be usable by the team in the actual launch window.

Separate prerequisites from cutover actions. Required access, approved content, working email configuration and the redirect map should be ready before the window begins. The cutover should not become an improvised discovery session. If a prerequisite is missing, record the consequence and decide whether the launch can proceed safely with a defined limitation. Do not allow an unresolved dependency to remain invisible until customers encounter it.

Include the exact acceptance evidence for the most important forms. Identify the test request, the destination record, notification status and analytics check. State how test records will be labelled and removed or retained according to the business's policy. Verify both the happy path and the recovery path. A test that only clicks Submit and sees a green message is incomplete.

Record the rollback trigger and the person authorised to act. The trigger might be a critical enquiry failure or widespread unavailability of important pages. Distinguish it from a minor issue that can be corrected during the monitoring period. Keep the recovery path practical: the team needs the access, files and configuration required to execute it, not merely a sentence saying a backup exists.

Review the handover as an operating demonstration

Ask the delivery team to demonstrate a routine content update. They should edit a paragraph, add an FAQ heading, replace a testimonial image and update a case-study caption without breaking the layout. Ask them to show how the change is reviewed and published. This reveals whether the site is maintainable by the people who will actually operate it, rather than only by its original builder.

Next, demonstrate an enquiry investigation. Begin with a form record and identify the service, page, placement and available source context. Follow it into the responsible person's workflow. Show how a failed guide email or notification is identified and retried. The business should know where to look when someone says that an enquiry was submitted but not received.

Review the technical documentation at the level needed for continuity. The business should know the platform, important plugins or custom components, hosting arrangement, account owners and maintenance responsibilities. Store source files and approved assets in an organised location. Keep sensitive credentials in the appropriate secure system rather than embedding them in a general handover document.

Finally, agree the first maintenance and performance review. Clarify which support covers defects, which covers routine updates and which requires a new scope. A transparent handover reduces uncertainty for both the client and the supplier. It also gives the business a realistic plan for keeping the site useful after the excitement of launch has passed.

Evaluate the redesign against the original business brief

Return to the outcomes agreed at the start. Can a relevant buyer understand the service more quickly? Is the evidence easier to inspect? Can the person enquire on the page where the need is understood? Does the resulting record carry the context that sales needs? Are the important old destinations preserved through appropriate mapping? These are concrete improvements that can be verified before enough traffic exists to estimate conversion performance.

Then define the later commercial review. Choose a suitable period and compare like-for-like journeys where possible. Account for changes in traffic sources, campaign spending and service mix. Show enquiry quality and progression alongside volume. A redesign that filters out poor-fit requests while improving useful opportunities may be successful even if the headline number of submissions does not rise.

Keep a short backlog of evidence-led improvements. The launch will reveal real behaviour that no mockup can fully predict. Use that information to refine the site in controlled steps. Preserve the premium design by maintaining a clear hierarchy and purposeful content, while allowing the customer journey to improve as the business learns.

References and scope

The acceptance workshop, page brief and release sequence are proposed operating tools. Adapt them to the platform and infrastructure in use. For migration-specific search guidance, consult Google Search Central's site-move documentation. For content principles, consult Google's helpful content guidance. For measurement events, consult Google Analytics documentation. Verify the current implementation requirements before launch.