Quick answer: A website rebuild goes well when you write the brief before the design. The brief should cover what the site must do for the business, which pages and URLs exist today, what must be kept for SEO, what the content plan is, and how you will measure success. Skipping the brief is why rebuilds run late and lose rankings.
Start with the decision the website should help a visitor make
A website brief becomes useful when it describes the visitor's job. A service buyer may need to understand the scope, see relevant work and send an enquiry. An existing customer may need to find documentation. Write those journeys down separately. 'Make it modern' is a design preference. 'Help the right buyer understand and enquire' is a goal the team can review.
Choose a small set of outcomes that you can observe. These might include completed enquiry forms, qualified meeting requests or fewer support questions about a confusing service. Record the current baseline where data exists. If there is no reliable measurement yet, say so, and do not present the redesign as a proven conversion fix.
Inventory what exists before writing the new page list
List the current URLs and identify the pages customers use, the ones receiving search visits and the ones your team still maintains. For each, decide whether to keep it, improve it, combine it with another page or retire it. A page can be visually dated and still contain information that customers need.
Then assign an owner to every new page. That person should be able to provide accurate service details, product information and evidence for claims. Content readiness affects the build. Nobody can review a template properly without knowing whether it needs two paragraphs, a comparison table or a product catalogue.
Define the editing experience as part of the product
Decide who will add a project, replace an image, publish a post and change a service description. Ask the developer to demonstrate each of these tasks. A promise that the site has a CMS is not enough. An editor should understand which fields are required and what happens when an image or excerpt is missing.
WordPress may suit a content-led business site. A custom application can need a different frontend and content model. Weigh ongoing skills, hosting and maintenance in the platform decision. Choose the system your team can operate, even if another one looks better in the first presentation.
List integrations and the information they exchange
For each form, booking tool, CRM or payment connection, record the source of the data, its destination and the person responsible for the receiving account. Include failure cases. If the CRM is down, should the site store the enquiry locally, retry, or flag it for manual entry?
This is also the time to review sensitive information. An initial enquiry usually does not need passwords, identity documents or customer databases. Keep public forms focused on the information needed to start a conversation, and agree a separate access-sharing process for delivery.
Plan the URL transition before launch day
When URLs change, prepare a mapping from important old pages to their relevant replacements. Do not send every retired URL to the homepage by default. Google's site-move guidance covers URL mapping, redirects and post-move monitoring. Use it as a technical reference alongside the project's own page inventory.
Google's guidance on site moves.
The launch plan should name who changes DNS, who checks the live forms and who makes the rollback decision if a critical journey fails. Agree a period after launch during which a named person checks the new site.
A brief you can send to a development partner
Bring the current domain, the priority audiences, the desired page list, example designs and a list of connected systems. Add who owns content, who approves the work and any real deadline. If part of the brief is unknown, say so. A short discovery phase is more useful than an estimate based on hidden assumptions.
At Wasevo, we turn this information into a scoped website plan with review points and launch responsibilities. The aim is a website that works for visitors and that your team can maintain after the initial build.
Discuss your rebuild with Wasevo
Explore Wasevo's Web design & development that your team can manage, or send a project brief with your current setup and the outcome you need.
Frequently asked questions
Four to eight weeks for a business website once content is ready. Stores, portals and sites with many pages to migrate take longer.
Written by
Founder & CEO of Wasevo. Builds SEO, software and AI automation for clients in the US, UK, Canada, Australia, Sweden and Pakistan since 2020.