Website design & development
A new website can quietly discard the traffic, content and workflows the old one earned.
The short answer
A safe website rebuild begins with an inventory of URLs, content, forms, integrations and search performance. Decide what stays before designing replacements, map every valuable old address to its final destination, migrate structured content through repeatable transforms and launch with redirect, analytics, form, metadata and indexation checks already prepared.
A rebuild changes more than the appearance of a site. It changes addresses, templates, publishing rules, forms, analytics and the assumptions people have built around them. The safe process treats the existing site as a working system with assets to preserve, not as a visual reference to throw away after screenshots are taken.
Inventory the site before deciding what deserves a replacement.
Collect every indexable URL from the sitemap, analytics, search data, backlink reports and a crawl. Add forms, gated files, campaign destinations and pages that may not appear in navigation. Each source sees a different part of the site, which is why copying the menu is not an inventory.
For each URL, record its purpose, traffic, links, conversions, content owner and whether an equivalent page belongs in the new structure. Keep, combine, replace or retire it deliberately. A low-traffic page with a useful external link or a form embedded in an old campaign can matter more than its visit count suggests.
Inventory integrations as well as pages. Newsletter signups, contact routing, scheduling, search, consent, analytics and CRM fields often depend on names or endpoints the visual brief never mentions. A rebuild that preserves the page and drops the business process is not complete.
Design the new information architecture against the old addresses.
Create the new page hierarchy and content types, then map the old URLs while those decisions are still flexible. If several old pages become one stronger page, select the destination that actually covers their intent. If one old page becomes several, choose the closest primary destination rather than redirecting every visitor to a generic hub.
Keep URLs readable and stable. Avoid carrying implementation details, campaign language or a temporary organisational structure into addresses meant to last. A shorter URL is not automatically better if it removes the words that explain what the page is about.
1. Build the old inventory
Combine crawl, sitemap, analytics, search and known campaign sources. Record the current status and canonical address.
2. Approve the new page model
Name the content types, hierarchy and page jobs before redirect destinations are finalised.
3. Map every old address
Assign a direct new destination, an intentional retirement or a reason the address remains unchanged. Do not use the homepage as a catch-all.
4. Test the map automatically and by hand
Check status codes, redirect chains, final content and a sample of the most important paths before and after launch.
Migrate content as structured information, not pasted pages.
A rebuild is the chance to separate content from presentation. Define fields for titles, summaries, authors, services, dates, images and relationships instead of copying one page's HTML into a generic rich-text box. Structured content can power templates, related links, metadata and future redesigns without being rewritten each time.
Automate repeatable transformation where the source is consistent, then review the exceptions. Preserve meaningful dates, image descriptions and internal links. Remove obsolete styling and tracking fragments that belonged to the old renderer rather than the content itself.
Freeze or control editing during the final migration window. If the old site keeps changing while data is moved, define a delta process that captures new and updated records. Otherwise the last week of publishing disappears between exports.
| Asset | What to preserve | What to verify |
|---|---|---|
| URLs | Address, canonical intent and redirect destination | No chains, loops or irrelevant catch-all redirects |
| Content | Fields, relationships, dates and ownership | Templates render complete records and exceptions |
| Media | Original files, useful filenames and alternative text | Images load at the right size and remain understandable |
| Forms | Fields, consent, routing and attribution | Submissions reach the correct system and person |
Prepare the launch as a reversible operating change.
Lower domain and caching settings before launch when a faster change may be needed, and make sure the responsible person can access the domain, hosting and analytics accounts. Take a final backup of the old site and keep a read-only copy available long enough to investigate missing content.
Run the production build against a checklist covering forms, navigation, metadata, canonical URLs, structured data, analytics, cookie behaviour, redirects, error pages, sitemap, robots controls, images and the primary paths on mobile. Launch checks should use the public addresses, not only a preview environment.
A rollback plan needs a trigger and an owner. Some problems can be corrected forward quickly. Others, such as widespread broken forms or an incomplete content import, may justify restoring the previous site while the migration is repaired. Decide that boundary before everyone is tired and watching the same dashboard.
Watch the rebuilt site for mismatches, not only outages.
After launch, monitor missing pages, redirect errors, search crawl reports, form delivery, analytics events and the visibility of important content. Compare the new URL inventory with what the site serves. A page returning a successful status with an empty shell is as harmful as a missing page and harder to notice.
Review search queries and landing pages over the following weeks. Some movement is normal while a new structure is processed. Investigate sharp changes around important pages, wrong canonical addresses, blocked resources or content that no longer answers the intent the old page earned.
We keep the redirect map and route inventory as maintained sources rather than one-time launch sheets. New pages and later URL changes then pass through the same checks instead of slowly rebuilding the migration risk the project removed.
Close the migration only after the content owners, marketing team and people receiving enquiries have checked their own paths. A crawler can confirm that a page exists. It cannot confirm that the right person receives a form, that a campaign promise survived the rewrite or that an editor can publish tomorrow's update.
Worth knowing before you start
Build the old URL inventory from several sources. Navigation alone misses campaign, orphaned and externally linked pages.
Map every useful old address to a relevant final page and test the content at the destination, not only the status code.
Control edits during the migration window or define a repeatable delta import for late changes.
Keep the old site available privately after launch so missing content can be investigated without guesswork.
Related work
Common questions
It can if useful content disappears, URLs change without relevant permanent redirects, metadata or canonical addresses are wrong, or the new pages are harder to crawl. A complete inventory, content review, redirect map and post-launch monitoring reduce that risk and make any mismatch easier to diagnose.
No. Keep pages that still serve a reader, carry useful links or support a business process. Combine overlapping pages and retire content that no longer has a job. Every retired address still needs an intentional response so visitors and crawlers do not land on a generic or confusing destination.
Create a row for every old address and assign the closest relevant final page or an intentional retirement. Use permanent redirects, avoid chains and test both the status and destination content. Do not send unrelated old pages to the homepage simply to avoid a missing response.
Check redirects, forms, analytics, metadata, canonical URLs, structured data, sitemap, robots controls, primary navigation, images, mobile paths and missing-page logs. Then compare search and enquiry behaviour with the old site while crawlers and users encounter the new structure.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.