Plan a website rebuild without losing the work your site already does

Write down the problem a rebuild must solve

Start with examples rather than a preferred theme. Perhaps editors cannot update key pages without help, a product catalog is difficult to navigate, or an important form loses information between systems. Name the people affected and describe the task they cannot complete. Separate a visual preference from an operational problem so both can be discussed honestly.

A rebuild is only one possible response. A focused refactor, content cleanup or new editor control may solve the issue with less disruption. Use the brief to compare those options. The WordPress development service covers implementation; this guide helps establish what that implementation should be responsible for.

Inventory the content and URLs you are keeping

Create a list of public pages, documents, images and important landing URLs. Record which content stays, changes, combines with another page or is retired, and assign an owner for reviewing it. Include pages that are absent from the main navigation but still receive visitors or support a campaign. Analytics and Search Console can help prioritize that review.

If URLs must change, map each old address to its appropriate destination before launch. Google’s site-move guidance recommends accurate URL mapping and redirects to final destinations. Avoid treating the home page as a universal replacement for removed content. Keep useful existing URLs where the new structure allows it.

Walk through the editor’s real job

Ask someone who maintains the site to demonstrate a normal update: editing a service, adding a team member or publishing a new trip. Record the fields, previews, approval steps and repeated work involved. A design can look excellent while making that job harder. The rebuilt editing experience needs acceptance checks alongside the public pages.

For WordPress, consider roles and capabilities, structured fields and reusable blocks together. Decide who can change content and who can change site-wide structure. Revisions can help editors review or restore changes, while complete site and database backups address a different recovery need.

List every handoff beyond the page

Forms, booking tools, payments, search, email delivery and imported content need an owner and a test case. Write down what happens after a visitor submits something, including where the record should appear and who receives it. Test the destination as well as the confirmation message. Identify integrations that depend on credentials, account settings or a separate supplier.

AdventureSmith provides a relevant example of why this inventory matters. During the five-year Duffion engagement, my work included Widgety integrations, custom loaders, refactors and ACF-backed blocks on an inherited website. The later solo rebuild belonged to my full-time AdventureSmith role. Those are separate engagements with distinct scopes.

Define launch checks before scheduling launch

Choose representative pages and tasks for review on mobile and desktop. Check navigation, keyboard operation, forms, content layout, images, redirects and editorial updates. W3C recommends planning and evaluating accessibility throughout delivery; it should not appear as a surprise task at the end.

The launch plan should identify the backup, content-change cutoff, deployment steps, rollback decision and person responsible for each. After launch, review actual submissions and integration outcomes, indexing signals and broken links. A working home page is useful evidence, but it does not establish that the whole site has transferred successfully.

Turn the inventory into a brief someone can estimate

Your brief should now explain the problems, retained content, changed URLs, publishing workflow, integrations and acceptance checks. Mark unresolved decisions clearly instead of hiding them inside a fixed specification. That gives a developer a basis for discussing scope, dependencies and cost without guessing what the site really does.

Agree on responsibility after launch as well: updates, editorial help, monitoring and future improvements. If the main need is to improve an established site progressively, ongoing development may be the better starting point.