The practical answer
A useful website redesign project plan assigns an owner, a dependency and a completion check to each stage. Set dates around the work and access required, rather than treating an unconfirmed launch date as a complete plan.
A redesign can stall even when the design work is moving quickly. Photos are missing, two people are approving different versions or nobody knows who controls the domain. A simple project plan makes those dependencies visible. It should be short enough to use during a call and specific enough that everyone knows what is waiting on them.
Download the project-plan CSV. Open it in your spreadsheet app, replace the example roles with names and add dates appropriate to your project. The stages are a suggested workflow, not a promise that every website takes the same amount of time.
Stage 1: Agree the goal and the scope
Start with the customer action the website should support. Write down the pages, features and content included in the project. Separate required launch work from improvements that can wait. A custom integration, online store or extensive migration can materially change the work, so identify those requirements before setting the schedule.
- Owner: business decision-maker and builder.
- Dependency: business goals, current website and required functionality.
- Completion check: both parties understand the included pages, responsibilities and open questions.
Stage 2: Inventory content and accounts
Create a list of existing URLs and identify which content must be retained. Record who controls the domain, website, email and relevant reporting accounts. Keep credentials out of the spreadsheet. Request only the access needed for the agreed work, and leave existing services active while the transition is being planned.
Use the redesign questionnaire to gather business information and the content audit to record page-level decisions. These are separate tasks: knowing what you want is not the same as knowing what you already have.
Stage 3: Prepare and approve the content
Assign someone to supply accurate service descriptions, contact details and permitted images. Record missing items explicitly. "Waiting on photos" is less useful than "owner to supply three approved installation photos before the services page review." Decide who checks factual claims, prices and credentials before they reach the final layout.
Stage 4: Review the preview as a customer
Review on a phone as well as a larger screen. Follow the main navigation and the primary inquiry path. Check that the text describes your actual services and that the form asks for useful information. Consolidate feedback into one list with the page, issue and requested change. Avoid replacing clear feedback with a general instruction to make it pop.
| Review item | What to check | Who confirms |
|---|---|---|
| Content | Accurate services, prices and contact details | Business owner |
| Mobile layout | Readable text, usable buttons and no sideways scrolling | Owner and builder |
| Inquiry path | Form, receipt and expected follow-up | Person handling inquiries |
| Existing pages | Retained URLs and relevant replacement mapping | Builder with owner approval |
Stage 5: Prepare the launch decision
Agree who authorizes the switch and who is available afterward. Record the previous configuration and a practical recovery option. Confirm the domain and email responsibilities, the important page list and the checks that must pass before launch. A working preview is not enough if inquiry delivery or the domain connection has not been reviewed.
Where URLs change, Google recommends preparing a mapping, testing the new site and monitoring the move. See Google Search Central’s site-move guidance for the technical process. Your builder should apply the parts relevant to the actual change.
Stage 6: Check the live result
After launch, check the real domain, important pages and inquiry delivery again. Record the release date so later reporting can be interpreted in context. Keep a short issue list with an owner and status. Do not change multiple major elements repeatedly because one day of traffic looks different.
How this fits a Tech Turtle project
Our standard-build target begins after the required information is complete; custom features and migrations may need a different schedule. Review the redesign scope and website plans before treating a sample timeline as a delivery commitment. A useful plan makes the handoffs visible and leaves room for honest decisions when something is not ready.
Frequently asked questions
It depends on content readiness, access, scope and review time. Build the schedule around those dependencies and confirm it with your provider.
Choose a business decision-maker who can confirm the offer and consolidate feedback. The builder should confirm technical readiness separately.
Yes. Remove migration-specific rows and keep the scope, content, preview, launch and follow-up stages.
Written by
Tech Turtle
Website planning resources
Practical website planning guidance from Tech Turtle, a Wausau, Wisconsin team serving small businesses across the United States.
