First confirm that you own, or have permission to reproduce, every asset you plan to carry over. Then inventory the live pages, content, forms, breakpoints and third-party services; capture the states that matter; rebuild reusable components; reconnect analytics and business logic; and test the new site on a private URL before changing DNS. Keep the old site and a rollback plan until the replacement has handled real traffic cleanly.
Reviewed for material changes on August 13, 2026
Start with ownership and a page list
This guide is for a site you own or have written permission to reproduce. Owning the domain does not automatically mean you own every photograph, font, illustration, testimonial or piece of agency-created code on it. Check the contracts and licences before copying assets into a new project.
Make a plain spreadsheet of every public URL and label each page keep, rewrite, merge or retire. Add the page owner, conversion goal, traffic value and anything that must keep its URL. This turns a vague cloning job into a controlled migration.
- List pages, downloadable files and language or regional versions.
- Record forms, checkout steps, logins, search and gated content.
- Mark licensed fonts, stock media and third-party embeds for review.
- Export titles, descriptions, redirects and analytics events before the old platform disappears.
Capture behaviour, not just the desktop homepage
A screenshot records one viewport at one moment. A working reference also needs the mobile header, open menus, validation errors, hover and focus states, cookie choices, empty search results and the confirmation shown after a form succeeds.
Capture the site at a few representative widths and walk through its main customer journeys. Save the original text and assets separately from screenshots. When a detail is already broken, write down the intended behaviour instead of faithfully preserving the bug.
Rebuild the system underneath the look
Pull the recurring decisions out of the old pages: type scale, colours, spacing, container widths, button styles, card shapes and image treatment. Build those as shared tokens and components before reproducing every route. A site assembled from twenty near-identical one-off pages is only a screenshot collection with a deployment button.
Use semantic HTML and preserve a sensible heading order. Recreate brand character, but take the chance to improve contrast, keyboard focus, tap targets and reading order. W3C recommends using the latest WCAG version; at the time of review that is WCAG 2.2.
Reconnect the parts that make the site a business tool
Forms need delivery, spam controls, error handling and a real success state. Analytics need consent-aware loading and named events. Search, account areas, checkout, scheduling and CRM handoffs should be treated as separate integrations with an owner and a test case.
Do not assume a visual clone has preserved SEO. Carry over canonical URLs where they still make sense, write redirects for retired addresses, restore page metadata and regenerate the sitemap. Google's site-move guidance recommends changing one major thing at a time where practical and monitoring the move after launch.
Run the same journeys before and after the switch
Put the replacement on a private staging URL and test it with real content. Check the top pages on a narrow phone, a large screen and at least one keyboard-only pass. Submit every form, follow every primary call to action and inspect the result—not just the click.
At launch, keep a copy of the old site, lower DNS risk where your provider allows it and have a named person watching errors, form delivery, payments and search-console reports. A rollback is not pessimism; it is what lets you make a clean decision when launch-day evidence is mixed.
Sources and checks
Product limits and prices came from the companies themselves:
- Google Search Central: site moves with URL changes
- W3C Web Accessibility Initiative: WCAG overview
- U.S. Copyright Office: website content
Plans move. We date every check so you know when to verify again.