Decide what the redesign needs to change

A WordPress website redesign should begin with a list of what must keep working: useful content, important URLs, editing tasks, enquiries and connected services. Agree those requirements alongside the new design, then test them before and after release.

Write down the problem behind the project. Is the information hard to find, the mobile layout difficult to use, or the editing workflow too fragile? Separate those problems from requests to change the domain, hosting, page builder or content structure. A focused improvement may be enough; a new visual design does not automatically require new URLs.

Use this as a planning and acceptance checklist for a proposed project. It is not a record of a completed client migration or a guarantee that search traffic will stay unchanged.

Record what the current site does

Bring a page list, the current sitemap and any permitted Search Console or analytics exports to the scope review. Record the date and reporting period. Identify the pages people use to understand the offer, make contact or complete a purchase, even when traffic is too low to draw a reliable trend.

  • Content: pages, articles, images, downloads and any custom records such as projects or locations.
  • Editing: who changes each content type, which fields they use and what depends on a theme or plugin.
  • Journeys: enquiries, bookings, purchases, searches and account functions that are actually in use.
  • Connections: forms, email delivery, stock or customer systems and the person responsible for each one.

Save approved examples of important pages and tasks so reviewers can compare the replacement with the agreed requirements. Keep customer records, passwords and access keys out of the planning document.

Give each existing URL a decision

Keep a useful URL when its purpose remains the same. If a page moves, map its old address to the closest relevant replacement and test the permanent redirect. If content is removed without a suitable replacement, agree an appropriate not-found response. Sending every retired page to the homepage can be misleading.

Google’s site-move guidance explains URL mapping and redirects in more detail. The map should also include valuable downloads and media whose addresses will change.

A small URL decision register

Copy one record per page or file into your project document:

  • Current URL and purpose: [add the address and what it helps a visitor do]
  • Decision: keep, move, combine with relevant content, or retire
  • Destination and reason: [record the exact destination, or why there is none]
  • Expected response: [agree the status and redirect behavior]
  • Actual result and evidence: NOT TESTED
  • Owner, reviewer and date: [name who resolves and checks the decision]

Illustrative example: changing the layout of /services/ does not by itself require renaming it. If an old service page is combined into a genuinely equivalent service page, record that specific destination. These are planning examples, not instructions to create redirects on your site without reviewing its content.

Review the replacement in a protected staging site

Agree who can access staging and how it is separated from production. A noindex instruction controls search indexing; it is not an access restriction for private material. Google also needs to crawl a publicly reachable page to see that instruction, as explained in its noindex documentation.

Before copying the site, identify anything that can send real email, collect payments, create bookings or synchronize records. Use suitable test accounts and approved sample data. Record what is disconnected or replaced in staging, and who will restore and verify the production configuration.

Ask an editor to perform real tasks in the proposed build: change a heading, replace an image, edit a shared project and preview the result. Our Elementor versus ACF guide includes an editing trial that can help assess the workflow.

Rehearse content migration and recovery

A WordPress migration needs an approach suited to the site’s files, database and stored URLs. The WordPress migration handbook explains why URL changes and serialized data require care. Agree the method with the person responsible for the implementation rather than treating a database text replacement as a universal solution.

Review a representative sample before moving everything. Check custom fields, relationships, images, downloads and formatting as well as record counts. Name who reconciles edits made on the old site after the sample was copied.

Record the backup location, restore access, recovery owner and conditions for rolling back. A completed export is evidence that an archive was created; a restore rehearsal is a separate check. For stores, include the handling of new orders, stock changes and customer records in the cutover plan. The WooCommerce planning checklist provides a starting point for store-specific dependencies.

Test the paths that lead to an enquiry

Give each agreed journey a short acceptance record: prerequisite, steps, expected result, actual result, evidence, reviewer and unresolved issue. Start every outcome as NOT TESTED. A screenshot of a finished page does not prove that its form or integration works.

  • Mobile enquiry: open the keyboard, check labels and validation, read the privacy note and reach the submit control.
  • Delivery: for an agreed labelled test, confirm the on-screen response, expected inbox receipt and any downstream record. Exclude the test from commercial lead totals.
  • Content: follow navigation, contextual links and downloads, including the important addresses in the URL register.
  • Measurement: check the agreed consent behavior and analytics setup without duplicating tags or treating staff activity as customer demand.

Assign an owner and retest date to a failed check. Decide which unresolved issues prevent launch before the final review meeting.

Check the public site after release

On the live domain, check the agreed URL responses, internal links, canonicals and sitemap. Confirm that intended public pages do not retain staging indexing restrictions. Review the public versions of important pages, because a working authenticated preview does not establish the visitor experience.

Keep a dated launch record and compare later Search Console periods with the baseline. Significant changes can cause search fluctuations while Google processes them. Publication, successful fetching and a sitemap entry do not establish indexing or rankings; use the actual reports and investigate specific unexpected failures.

Confirm who handles post-launch issues and which support is included. The WordPress website handover checklist covers the account, editing, renewal and ongoing responsibility record.

Bring the decisions to a scoped redesign review

Send the current website, the problems you want to solve, examples of important pages and a list of required integrations. Mark unknowns instead of guessing. Your proposal should identify content migration, URL work, testing, launch responsibilities and any ongoing costs separately from the visual design.

Use the WordPress project brief to organize the inputs. For an existing custom-field website, our ACF WordPress development service explains how we review a focused change versus a rebuild. Discuss an agency redesign or share your business website for a scope review.