Plan a website redesign around content, design, development and testing. Follow an illustrative eight-week schedule and see what can change the date.
A website redesign can take several weeks or several months. Updating the look of a few pages is a very different job from reorganizing a bilingual site, moving its content and reconnecting its forms.
That's still a pretty wide answer, so let's make it concrete. I'll walk through an eight-week planning example for a small business website, then explain what would change that schedule.
The example uses a hypothetical schedule. We'd confirm your project's timeline after reviewing the scope and the team's availability.
Start with what actually needs to change
Open your current site and write down what you want to keep, replace and add.
Maybe the structure works, but the photos and design feel dated. That gives you a fairly contained job. Keeping the pages, content and existing platform removes decisions from the project.
Now imagine adding a second language, separate pages for every service, and a quote form that sends information into your CRM. You need to decide what those pages say, who approves each language and what happens after someone submits the form. Those decisions belong in the schedule too.
Those features also affect the budget. Our website cost calculator can help you estimate the build while you decide what belongs in the first release.
For a real example of scope, look at the Grupo Domo website. It brings together bilingual service and industry pages, a guided customs quote and a cargo calculator. Each feature needs its own content and testing. Counting it as one website tells you very little about the work involved.
An example website redesign timeline
Let's assume we're planning a site with about eight pages, one language, an ordinary contact form and no store or customer accounts. Existing text and photos are available, one person can approve decisions, and the team building it has reserved the time.
Here's how an illustrative eight-week plan could work:
| When | Work to complete | What lets the next step move forward |
|---|---|---|
| Week 1 | Review the current site and agree on pages, features and responsibilities | An agreed scope and a list of content to keep or replace |
| Weeks 2 and 3 | Edit content, organize pages and design the main layouts | Approved page structure, copy and design direction |
| Weeks 4 through 6 | Build the pages, add content and connect the form | A working preview with the agreed features |
| Week 7 | Review the full site, test it and fix issues | Approval of the finished pages and successful form tests |
| Week 8 | Complete launch checks, publish and check the live site | A working site and clear responsibility for follow-up fixes |
The work can overlap. A developer can build an approved layout while another page's copy is being finished. But building a service page before deciding what the service includes can mean doing that work twice.
Also, week one means the agreed start of work. If the agency isn't available until next month, that waiting time comes before the schedule.
Content and reviews need their own dates
"We'll send the text later" leaves a hole in the plan. Someone has to write it, check the details and approve it before the page is ready.
I would put a name and a due date beside each piece of content. That includes photos, service descriptions, testimonials you have permission to use and any legal text your business needs.
For a bilingual site, decide who writes the original and who reviews the translation. Translating an approved page is much simpler than trying to keep two versions aligned while both are changing. Buttons, forms and confirmation messages need that review too.
Agree on review rounds and how feedback will arrive. One consolidated list is easier to act on than separate messages from five people. If a review takes a week, that week still counts, even if nobody is writing code during it.
Adding a new feature after approval also changes the plan. Ask what it does to both the delivery date and the website redesign budget before making it part of the launch.
Give migration and testing enough room
Before changing page addresses, list the old URLs and decide where each will go. Keep useful addresses where possible and prepare redirects for pages that move. Google's site migration guidance recommends mapping old URLs to their new destinations and testing the new site before the move.
This takes more work when the site has lots of articles, documents or language versions. Allow time for it alongside the design work.
Then try the site like a customer would. Read it on your phone. Open the menu. Follow the links. Send a test enquiry.
For the form, check the whole journey:
- Required fields and error messages work.
- The visitor gets the correct confirmation.
- The enquiry reaches the right inbox or CRM record.
- The team receives enough information to respond.
If there's a calculator or booking flow, test its rules and unusual inputs as well. Leave room to fix what you find before launch, then repeat the essential checks on the live site.
Google may take time to process changed URLs after publication. Launch day and settled search visibility are different milestones; a build schedule can't promise when rankings will stabilize.
Work backward from your launch date
If you need the site for a campaign or event, bring that date into the first conversation.
Work backward through final testing, full-site review, development and content approval. Check whether the people responsible are actually available. A review scheduled during someone's holiday doesn't help much.
If everything won't fit, choose a useful first release. That could mean publishing the essential service pages and contact journey first, with a larger resource library later. Keep testing and the necessary migration work in the launch plan.
You can see how we approach website design and development, or tell us about your site. Include the current URL, your target launch date and the main things you want to change. That gives us a much better starting point for a realistic schedule.