How to Replace an Existing Website: A Step-by-Step Guide
Replacing a website safely means planning the new experience while protecting useful content, URLs, data, domains and customer journeys.
To replace an existing website safely, first document what must be protected, then design and build the replacement away from the live site, map old URLs to new destinations, test the complete journey and monitor it after launch. The project is a controlled migration, not simply a visual redesign.
The existing website can usually remain live while the replacement is developed. Customers keep using the current service until the new site has passed its checks and the domain is deliberately switched.
Step 1: Define why the website is being replaced
List the problems the project must solve. These may involve slow performance, difficult editing, unclear services, inaccessible components, fragile plugins or a structure that no longer reflects the business.
The short guide to five questions before rebuilding a website can help business stakeholders prepare this discussion before technical planning begins.
Separate evidence from preference. Analytics, customer questions, failed tasks, maintenance records and technical audits can identify real problems. Visual dislike alone does not explain what the replacement must achieve.
Set measurable acceptance criteria without promising outcomes outside the site’s control. You can test page speed, form delivery, responsive layouts and redirect coverage. You cannot guarantee a particular ranking or number of enquiries.
Thinking about your own rebuild?
Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.
For scope and dependencies, review how long replacing a business website can take.
Step 2: Establish ownership and access
Confirm who controls the domain, DNS, hosting, content management system, analytics, Search Console, business profiles, email services and third-party integrations. Store access securely and remove obsolete accounts.
Do not wait until launch week to discover that a former supplier controls the domain account. Record renewal dates and identify who can authorise changes.
Keep email separate in the migration plan. A website hosting change does not have to change mail service, but careless DNS edits can interrupt it. Record the current mail records before touching DNS.
Step 3: Inventory the existing site
Crawl or list every public URL, including pages, articles, downloads and images that attract visits or links. Record the title, purpose, status, traffic, backlinks and intended action.
Identify forms, search, payments, booking tools, feeds, structured data and tracking. Note integrations and the business process behind each one. A form is not working merely because it shows a confirmation page; the message must reach the right person.
The guide to upgrading an outdated business website provides a broader assessment framework.
Collect the information your web designer needs so ownership and content questions are resolved early.
Step 4: Decide what to keep, improve or remove
Evaluate content by usefulness and accuracy. Keep material that supports real customer tasks, earns relevant links or contains business knowledge worth preserving. Improve unclear pages and merge substantial duplication.
Remove obsolete material carefully. A page with little recent traffic may still support a contractual, support or niche customer need. When a removed URL has a close replacement, plan a permanent redirect.
Use the guide to what to keep when replacing an old website to assess content, branding, data and functionality rather than assuming everything must start again.
Step 5: Design the new information structure
Map services and customer tasks into a clear hierarchy. Give each page a distinct purpose. Keep navigation focused on durable, high-value destinations and use contextual links for deeper material.
Plan URLs early. Preserve strong existing URLs where the subject remains the same. A redesign does not require every address to change. Stable URLs reduce migration risk.
Create a page map showing every existing URL, its new destination and its status. This becomes the foundation for content work, redirects and testing.
Step 6: Plan content before layouts are fixed
Draft or outline the real headings, evidence, calls to action and page relationships. Placeholder copy can hide difficult content decisions and produce layouts that fail when real words arrive.
Verify service claims, prices, team details, qualifications and local coverage. Gather approved photographs and testimonials. Avoid copying the old site automatically when its content is one reason for the replacement.
The customer-focused content guide explains how to build pages around questions and decisions.
Check which existing words and assets can be reused before approving them for migration.
Step 7: Set technical requirements
Define performance, accessibility, browser support, security, privacy, editing and hosting expectations. Record which functions are essential at launch and which can wait.
Choose technology according to the site’s needs and the team’s maintenance capacity. The WordPress alternatives guide and Astro guide for business owners explain different approaches without assuming one platform suits every organisation.
Specify backups, deployment, updates and support. Ownership after launch matters as much as the initial build.
Step 8: Build away from the live website
Use a development or staging environment that is not indexed as the public site. Protect sensitive previews appropriately and avoid placing real customer data in test systems.
The current website can continue serving customers while design, content and code are reviewed. Keep production changes under control so late updates are not lost during migration.
Use version control and repeatable deployments where appropriate. Maintain a clear route for urgent fixes to the live site throughout the project.
See how to build a new website while the old one stays live for the separation and handover checks.
Step 9: Prepare a complete redirect map
Map each changed or removed URL to the closest relevant new page. Use permanent redirects for lasting moves. Do not send every old address to the homepage, which often fails to meet the visitor’s original need.
Preserve query handling where integrations or campaigns depend on it. Include common variants such as trailing slashes and old file extensions when the platform requires explicit rules.
The guide to redesigning without losing Google rankings explains redirects, canonicals and monitoring in more detail.
If redirects are new to you, read what URL redirects do before completing the map.
Step 10: Migrate metadata and search signals
Give every public page a unique, accurate title and description. Preserve valuable headings and relevant structured data, while correcting information that no longer matches the page.
Set canonical URLs to the public destinations. Generate an XML sitemap from the final routes and ensure the live robots rules allow appropriate crawling. Keep private, status and administrative pages out of search.
Do not copy obsolete keyword fields or duplicate metadata simply because the old system contained them.
Step 11: Test content and functionality
Review every page for accuracy, headings, links, images and responsive behaviour. Submit forms and verify both customer confirmation and business delivery. Test search, downloads, consent controls and third-party integrations.
Check keyboard navigation, visible focus, zoom, colour contrast, text alternatives and error messages. Automated tools can find some issues, but task-based human testing is still necessary.
Test on real phones and representative browsers. Check slow connections and missing JavaScript where the site promises a resilient core experience.
Step 12: Test the migration itself
Run the redirect map against the built site. Confirm that each old URL returns one direct redirect to the intended new page without loops or chains.
Compare the new crawl with the inventory. Find orphaned pages, accidental drafts, duplicate titles, broken fragments and missing images. Validate structured data and inspect canonical tags.
Review high-value entry pages individually. A technically valid redirect is still wrong if it lands on an unrelated subject.
Step 13: Prepare the launch plan
Choose a launch window with the people needed to make and verify changes. Avoid an unnecessary high-risk deadline. Record the order of deployment, DNS or proxy changes, cache clearing and checks.
Lower DNS time-to-live in advance only when the hosting plan requires a DNS switch and the responsible person understands the effect. Back up the current site and configuration before launch.
Prepare a rollback plan. Define what would justify reverting and who can make that decision. A rollback is safer when it has been considered before pressure begins.
Work through the pre-launch checks with a named owner for each outstanding item.
Step 14: Launch without disrupting email
Change only the records required for the website. Preserve mail exchange, SPF, DKIM and other email-related records unless the mail service is intentionally changing.
Deploy redirects with the new site and make sure HTTPS works on all public hostnames. Confirm the preferred domain variant and prevent duplicate copies.
Test the site from outside the development environment. Cached or internal views can conceal a public failure.
Treat the domain arrangements and email continuity as separate checks, even when one supplier manages both.
Step 15: Complete immediate checks
Open the homepage, main services, contact route and several old URLs. Submit a form, inspect mobile navigation and verify analytics or consent behaviour. Check the public robots file and sitemap.
Use Search Console’s URL inspection for important pages where appropriate. Submit the new sitemap after confirming that it contains only intended public URLs.
Look for server errors and redirect failures. Repair customer-blocking issues before cosmetic refinements.
Step 16: Monitor after launch
Watch Search Console coverage, page performance, crawl errors, analytics and real enquiries. Compare like-for-like periods and account for normal variation.
Keep redirects in place for the long term where old URLs may still receive visits or links. Do not remove them immediately after search results begin updating.
Ask customer-facing staff about new questions or failed journeys. Technical dashboards will not reveal every misunderstanding.
Use the post-launch checklist to verify public behaviour and organise follow-up.
Step 17: Close the old system responsibly
Do not cancel old hosting until the new site, redirects, backups and access have been verified. Export any records the business must retain and follow data-protection obligations.
Remove obsolete administrator accounts, API keys and integrations. Document the new hosting, renewal, deployment and support arrangements.
Keep an archive where appropriate, but do not leave an accidentally public copy of the old website on another hostname.
Common website replacement mistakes
Changing every URL without need creates avoidable migration work. Launching before content is ready leads to placeholders and broken journeys. Treating forms, email and analytics as late additions risks operational failure.
Other mistakes include blocking the live site from crawling, forgetting image files, redirecting everything to the homepage and deleting useful articles because they do not fit the new navigation.
A checklist is valuable, but ownership matters more. Every launch task needs a named person and evidence of completion.
Frequently asked questions
Can the old website stay live while the new one is built?
Yes. This is normally the safest approach. Develop the replacement separately and switch only after testing.
Will replacing a website affect Google rankings?
It can. Content, URLs, internal links, performance and technical signals may change. Careful preservation and monitoring reduce risk but cannot guarantee identical positions.
Do all old URLs need redirects?
Redirect URLs that move and still have a relevant replacement. Some obsolete or unsafe content may correctly return a not-found or gone response after careful review.
Will my email stop when the website changes?
It should not if mail records and services are preserved. Record DNS first and change only what the website launch requires.
How long should redirects remain?
Keep important permanent redirects for the long term, especially where old URLs have links, bookmarks or continuing traffic.
Plan the replacement and its ongoing care
A safe website replacement protects the value already built while improving what customers experience next. Inventory first, make deliberate content and URL decisions, test the migration and keep monitoring after launch.
Afterworks approaches website rebuilds as managed replacements, bringing structure, content, performance and launch planning into one accountable process.
